Microchip RN4020 Certified Bluetooth® Low Energy OEM Module User Guide 1. Introduction Microchip RN4020 Certified Bluetooth Low Energy (BTLE) OEM module is a single mode Bluetooth Smart module that complies with Bluetooth Core Specification 4.0. Through its high speed UART interface, it could be configured to act as either central or peripheral role when establishing connection. It supports 13 public profiles and 18 public services, which are adopted by Bluetooth Special Interest Group (SIG).
while user self-defined private UUID must be in long form. For the details of Bluetooth SIG adopted services and characteristics, please refer to https://developer.bluetooth.org/gatt/profiles/Pages/ProfilesHome.aspx. The accessibility of each characteristic is defined by 8-bit characteristic property in bitmap format, as shown in table 1. Table 1.
interface will not be responsive in deep sleep mode. When the module is in deep sleep mode, GPIO 9 will output low. GPIO 4 is used to control RN4020 when Microchip private MLDP profile is used. Once get into MLDP mode by setting GPIO 4 at high, all data from UART will be sent to the peer device as data stream. To exit MLDP mode, user needs to put GPIO 4 low, so that module is back to command mode by outputting “CMD” to UART. Setting pin BT_WAKE high is used to wake RN4020 module from dormant mode.
All commands could be divided into five groups: Set/Get commands, Action commands, characteristic access commands, private service configuration commands and Microchip MLDP commands. 3.2.1 Set/Get commands This group of commands is used to configure the functionality of RN4020 module. The set command starts with letter ‘S’ and follow by one or two letters as the command identifier. The set command parameter is mandatory and it is separated from the command by comma.
3.2.1.3 SB,<0-7> This command set the baud rate of the UART communication. The input parameter is single digit number in the range of 0 to 7, representing baud rate from 2400 to 921K, as shown in table 3. Notice that when baud rate is set to 2400, there is no need to wake up RN4020 for UART communication. Table 3: UART Baud Rate Settings Setting 0 Baud Rate 2400 1 2 3 4 5 6 7 9600 19200 38400 115200 230400 460800 921600 3.2.1.4 Comments RN4020 does not need to be waken up.
Cadence Current Time Next DST Change Reference Time Update Link Loss Immediate Alert TX Power Alert Notification Phone Alert Status Scan Parameters Location & Navigation User Defined Private Service Default: Example: 3.2.1.
Default: Example: 3.2.1.8 RN4020 SDM,RN4020 SDN, This command set the value of manufactory name characteristics in Device Information Service. Default: Example: 3.2.1.9 Microchip SDN,Microchip SDP, This command set the value of PnP ID characteristics in Device Information Service. Default: Example: N/A SDP,N/A 3.2.1.10 SDR, This command set the value of software revision characteristics in Device Information Service. Default: Example: 1.0 SDR,1.0 3.2.1.
When input parameter is 1, majority of the settings will be restored to factory default, but some settings, such as device name, device info, script and private services, stay the same. When input parameter is 2, all parameters are restored to factory default. Example: SF,1 3.2.1.13 SM,<1,2>, This command starts one of the application timers.
Auto Advertise 0x2000 Support MLDP 0x1000 Auto MLDP Disable 0x0800 No Direct Advertisement 0x0400 UART Flow Control 0x0200 Run Script After Power On 0x0100 Enable Battery Monitor 0x0080 Enable Authentication 0x0040 This setting applies to peripheral device only. If set, device starts advertisement after power cycle, reboot or disconnection. If cleared, device starts advertisement after receiving command “A” from UART in command mode.
Enable Remote Command 0x0020 Do not Save Bonding 0x0010 IO Capabilities 0x000E Default: Example: The-Middle (MITM) attack. When authentication is enabled, IO capability is set to be keyboard and display. Refer to table 2.5 in Bluetooth Core Spec v4.1 Vol 3, Part H, section 2.3.5.1 for details. This setting is only effective if MDLP feature is enabled. This setting enables local device to receive remote command from remote device and send command output to remote device through MLDP data stream.
Blood Pressure Running Speed Cadence Cycling Speed Cadence Current Time Next DST Change Reference Time Update Link Loss Immediate Alert TX Power Alert Notification Phone Alert Status Scan Parameters Location & Navigation User Defined Private Service Default: Example: 0x04000000 0x02000000 Blood Pressure Running Speed Cadence 0x01000000 Cycling Speed Cadence 0x00800000 0x00400000 0x00200000 Time Time Time 0x00100000 0x00080000 0x00040000 0x00020000 0x00010000 0x00004000 0x00001000 0x00000001 Proximit
Table 6 Connection Parameters Parameter Range Interval 0x0006 – 0x0C80 Latency Timeout Default: Example: Description The time interval of communication between two connected devices. (unit: 1.25ms) 0x0000 – 0x01F3 The number of consecutive connection must less than events that the peripheral does not (Timeout*10/Interval*1.25- need to communicate with central. 1) 0x000A – 0x0C80 The maximum time between raw communications before the link is considered lost.
3.3.2.2 A,, Command “A” is only available to device that operates as peripheral or broadcacster role. Command “A” is used to start advertisement. When the device acts as broadcaster role, enabled by command “N”, the advertisement is undirected, un-connectable manufacture specific broadcast message. The payload of the message is set by command “N”.
After bonded connection is lost due to any reason, reconnection does to provide secured link automatically. To secure the connection, another “B” command should be issued. However, this command is only for securing link other than saving connection information. Default: Example: Not bonded B // bond with connected peer device 3.3.2.4 D Command “D” is used to display critical information of current device over UART. Following information will be shown after issuing command “D”.
Default: Example: Bonded MAC Address E,0,00035B0358E6 // Connect to peripheral with // public address 00035B0358E6 3.3.2.6 F,, Command “F” is only available to device as central or observer role. For central device, it is used to inquiry the peripheral devices before establishing connection. For observer, it is used to receive broadcast messages.
3.3.2.8 K Command “K” is used to disconnect the active BTLE link. It could be used as a central or peripheral role. Command “K” does not have any parameter. Example: K // Kill the active BTLE connection 3.3.2.9 M Command “M” is used to get the signal strength of last communication with peer device. The signal strength could be used to estimate the distance between the device and its peer. Command “M” does not expect any parameter. The return value of command “M” is the signal strength in dBm.
connected device supports those services as server role. Command “Q” lists the UUIDs of services that current device support as client role and connected peer support as server role. Default: Example: No Connection Q // Display the connection status 3.3.2.12 R,1 Command “R” forces a complete device reboot (similar to a power cycle). It has one mandatory parameter of “1”. After rebooting RN4020, all prior setting change takes effective. Example: R,1 // Reboot RN4020 3.3.2.
Command “U” not only removes the bonding, but also changes advertisement method. If a peripheral is advertising when command “U” is issued, RN4020 will remove the bonding, stop the directed advertisement, and then start undirected advertisement. Example: U // remove existing bond 3.3.2.15 V Command “V” displays the firmware version. Example: V // display firmware version 3.3.2.16 X Command “X” is only available to central or observer device. For central device, it stops inquiry process.
3.3.3.1 Definition of Characteristic Access Commands RN4020 could be configured to act as server and client at the same time. When it performs dual roles as server and client, two sets of services and characteristics are known to RN4020. For services that RN4020 acts as server, it is called server services, where all values and configurations of characteristics are stored locally.
Peer device supports services as server role. The output of command “LC” follows format below: The first line is primary service uuid The second line starts with two spaces and then follows the characteristic uuid, handle and characteristic property. The property for characteristic value follows definition in table 1.
When command “LS” has no parameter, it displays all server services along with their characteristics. Command “LS” could optionally take one or two parameters. If one parameter is given to command “LC”, it must be UUID of server service. Then only the server service with input UUID along with all its characteristics will be displayed. If two parameters are given to command “LS”, the first parameter is the UUID of server service and the second parameter is UUID of its characteristic.
property. The content value is written to remote peer device. The writing method depends on property of the characteristic. When writing to a configuration handle to the remote device, Bluetooth specification defines the format to be 0x0000, 0x0001 or 0x0002. Value 0x0001 (01 00 over the air in little endian) starts notification, value 0x0002 (02 00 over the air in little endian) starts indication and value 0x0000 stops both of them.
According to command interpolation method described in section 3.3.3.1, command “CURV” reads value of a characteristic in client service from remote device by addressing its UUID. This command expects one parameter, which is the UUID of the characteristic in client service. The UUID could be either 16-bit short UUID for public characteristic, or 128bit long UUID for private characteristic.
is hex value of the contents to be written. The format of public characteristic is defined in Bluetooth SIG specifications. The user defines the format of private characteristic. This command is only effective if an active link with peer exists, the UUID parameter is valid and the characteristic is writable according to its property. The content value is written to remote peer device. The writing method depends on property of the characteristic.
This command is effective only if the handle is valid in server service. Characteristic in server service is always writable regardless of its property. Characteristic property is only for remote access. The content of a configuration handle, which starts or stops notification/indication, is usually set remotely. We highly recommend not writing to configuration handle, although such operation is not prohibited. When Buffered Read feature (See section 3.2.1.
the configuration of a local characteristic, command “SHR” should be used to retrieve such information. This command is effective with or without an active link. Reading value of a characteristic locally is always permitted regardless of characteristic property. Characteristic property is only used for remote access. The value returned is retrieved from local device and equal to what is written at most recent time. Example: SUR,2A19 // Read the local value of characteristic with // UUID 0x2A19 3.3.3.
Notification or indication service for the corresponding characteristic has been started by the remote device Example: SUW,2A19,64 // Set local value of characteristic Battery // Level with value handle 0x001A to be // 100%. If notification service has been // started on Battery Level before, local // device will notify the new value of // 100% to the remote peer device 3.3.
Command “PC” expects three or four parameters. The first parameter is 128-bit UUID for private characteristic. There are many ways that user could generate 128-bit UUID with little possibility of confliction. Please refer to Wikipedia for details (http://en.wikipedia.org/wiki/Universally_unique_identifier). The second parameter is 8-bit property bitmap of the characteristic. Please check table 1 for characteristic property.
The effect of command “PS” could only be shown after a valid “PC” command and after power cycle. Command “PS” expects one parameter, which is 128-bit UUID for private service. The UUID generation process is the same as that of private characteristics. Please refer to Wikipedia for details (http://en.wikipedia.org/wiki/Universally_unique_identifier). Example: PS,010203040506070809000A0B0C0D0E0F // Define a private service with UUID 0x010203040506070809000A0B0C0D0E0F 3.3.4.
power and shortens battery life. If battery life is the priority of the application, the expectation of MLDP throughput may be lowered. Once MLDP is enabled, connection parameters are decided and an active link has been established between central and peripheral, setting GPIO 4 high enters MLDP mode. In MLDP mode, any data input from RN4020 UART will be sent wirelessly to the peer device. To get out of MLDP mode, GPIO 4 must be set low.
If the parameter is 2, MLDP data over the air will be authenticated. If this mode is enabled, Enable Authentication bit must be set for command “SR”, RN4020 must have I/O capability and bonding must be made before MLDP service starts. Default: Example: 0 SE,1 // Secure MLDP data over the air 3.3.6 RN4020 Standalone Scripting Commands 3.3.6.1 RN4020 Standalone Scripting Capabilities In typical set up, a host MCU via AT commands drives RN4020 BLE module over UART interface.
followed by one or more logic operations or AT commands. Once an event is triggered, if an event label is defined, then control is passed over to the script engine. The script engine starts executing the commands that are listed below the event label until the end of script or encountering another event label. Table 7.
$VAR2 = G@,1 After assigning a value, variables then could be used in an AT command. For instance, following AT command assign value of variable $VAR1 to the server characteristic handle 0x0019. SHW,0019,$VAR1 The range of variables could be defined so that if value of variables is not in the defined range, corresponding AT commands with variables would not prosecuted. The range of variable could be single condition such as following script line, which defines variable $VAR1 must be larger than 0x0100.
analogue port and digital port PIO 11 could be associated with a handle. The associated handle could be identified by proceeding identifier “%”. For instance, following script line associates server characteristic handle 0x0021 with read operation of analogue port AIO 2, so that whenever the peer device wants to read handle 0x0021, AIO 2 is read and the value will be returned to the peer device.
// module 3.3.6.3.3 WP Command “WP” stops script execution. It expects no parameters. Default: Example: N/A WP // Stop running script 3.3.6.3.4 WR,<0-9> Command “WR” starts script running. If no parameter is provided, script runs normally by starting @PW_ON event. In the case that a parameter in the range of 0 to 9 is provided, script starts running corresponding event in debugging mode.
Default: Example: N/A WW // Enter script input mode 3.3.7 Remote Command 3.3.7.1 Introduce RN4020 Remote Command Feature RN4020 has the capability of execution AT-Command remotely from connected devices. Remote command feature is built on top of MLDP, so it is prerequisite to support MLDP before using remote command feature. Remote command feature enable user to execute command on connected peer device.
3.3.8 Device Firmware Upgrade 3.3.8.1 Introduce Device Firmware Upgrade Device Firmware Upgrade (DFU) feature allows RN4020 to upgrade its firmware in the field. As any DFU process, firmware upgrade should be handled very carefully to avoid unrecoverable damage to the device. RN4020 supports two ways of doing DFU: wired solution through UART or wireless solution Over The Air (OTA). Both solutions provide firmware integrity support.
Once DFU finishes and verified successful, message “Upgrade OK” will be displayed and module reboots to use the new firmware. If DFU is not successful, message “Upgrade Err” is displayed and RN4020 stays in DFU mode. User should NOT reset or power down the module, but try to stream valid and signed Microchip RN4020 image again until the upgrade is successful. Typical DFU over UART lasts less than 1 minute. If the input parameter is 2, DFU mode is set to be OTA upgrade.
Before connection RN4020 to Apple device, users may need to setup RN4020 by following way: 1. Set GPIO 3 to low to enter command mode 2. Open a terminal emulator that connects to the serial port of RN4020 with following parameters: a. baud rate: 115200 b. data bits: 8 c. parity: none d. stop bits: 1 3. Issue command “+” to turn on echo 4. Issue command “SF,1” to reset to factory default configuration 5. Issue command “SS,C0000000” to enable support of Device Information and Battery services 6.
Tap the icon of RN4020, the two devices should be connected. From LightBlue window, service “180A” and “180F”, UUIDs of Device Information and Battery services respectively should be seen. From terminal emulator, type command “B” to bond two devices. Apple device will ask if pairing is permitted. Allow pairing to bond two devices together. Bonding is optional. Tap the icon with label “180A” should display 7 additional UUIDs for characteristics of Device Information service.
Now tap the UUID “180F” that will show one characteristic Battery Level with UUID “2A19”. After tapping icon “2A19”, characteristic windows shows that this characteristic’s property: readable and notification could be started. Now go back to terminal emulator to control RN4020 directly. We need to set the battery level to be 99% by either of these following commands: SUW,2A19,63 SHW,001A,63 The first command sets value of characteristic Battery Level to be 99 (0x63) by addressing its UUID 0x2A19.
Now from LightBlue window, if we tap the “Read” button for UUID 0x2A19, the returned value should show 63 in hex and 99 in decimal. Figure 5 shows the reading of Battery Level in Battery Service: Figure 5: Reading Battery Level in Battery Service LightBlue could also start notification on Battery Level characteristic by click button “Start Notify” within LightBlue window.
Now we could try to update the battery level to be 50% on RN4020 by typing either of following commands: SUW,2A19,32 SHW,0019,32 After issuing either of above commands, user could notice that the value of UUID 2A19 in LightBlue window, running on Apple device automatically updates to 0x32 (50 decimal). This is because with an active notification, any update to the value of a characteristic on the server side will be notified to the client side. Figure 6 shows automatic update results on LightBlue.
We could test the private services that user may define on RN4020. The command procedures and their description could be found below: SS,C0000001 //Enable private service support. PZ // Clear the current private service and characteristics PS,11223344556677889900AABBCCDDEEFF // Set private service UUID to be 0x11223344556677889900AABBCCDDEEFF PC,010203040506070809000A0B0C0D0E0F,02,05 // Add private characteristic 0x010203040506070809000A0B0C0D0E0F to // current private service.
Figure 7: Private Service Discovered by BlueLight The same as public services such as Device Information and Battery service, those characteristics could be read, write and get notification by issuing commands as follows: SUW,010203040506070809000A0B0C0D0E0F,1234 // Set value 0x3412 to characteristic // 0x010203040506070809000A0B0C0D0E0F SHW,001E,5678 // Set value 0x7856 to handle 0x001E, which is associated // with characteristic // 0x010203040506070809000A0B0C0D0E0F LightBlue could then read the valu
Figure 8: Reading Private Characteristic LightBlue could also write or start notification on characteristic 0x111213141516171819101A1B1C1D1E1F. The effect is the same as operating on a public characteristic. The only difference to RN4020 user is that public characteristic has short 16-bit UUID, while private characteristic has long 16-byte UUID. Figure 9 shows writing value 0x3412 (little endian) to private characteristic 0x111213141516171819101A1B1C1D1E1F from LightBlue.
WV,111213141516171819101A1B1C1D1E1F,0020,1234. Figure 9: Writing Values to Private Characteristics Notification on private characteristic could also be enabled by pressing “Start Notify” button within LightBlue window. RN4020 should notify the host the start of notification by following status message, which means the configuration of characteristic 0x111213141516171819101A1B1C1D1E1F has been written as 0x0001 (little endian), therefore, notification has been started.
SHW,0020,EFCD // Set value 0xCDEF to handle 0x0020, which is associated // with characteristic // 0x111213141516171819101A1B1C1D1E1F User should see that the value of private characteristic 0x111213141516171819101A1B1C1D1E1F is updated automatically to 0x90AB and 0xCDEF respectively, as shown in snapshot in Figure 10. Figure 10: Notification to Private Characteristic 4.3 Demonstration between two RN4020 Modules BTLE functionality could also be demonstrated between two RN4020 modules.
First we need to configure a RN4020 module to be in central role. For simplicity, we call it Module A.
00035B0358E6,Public,MCHP-LE X E,0,00035B0358E6 // Stop scanning // try to establish connection with device of public MAC // address 0x00035B0358E6. See section 3.3.2.5 for // details of command “E”. Once connected, message “Connected” will be shown on the terminal emulators of both devices.
User should notice that the server services on Module A match client services on Module B and vice versa. So that data exchange between Module A and B could follow client-server module where server maintains the data and client access to the data.
characteristic has been set value before, a notification will be sent to Module B automatically. Once notification is successfully started, and Battery Level characteristic has been set value before, a notification will be received by Module B with following format: Notify,180F,2A19,64. It means that the value of characteristic 0x2A19 (Battery Level) in primary service 0x180F (Battery Service) has been updated to be 0x64.
so they will stay low if not pull high). Then try to disable notification on Battery Level by either of following commands: CHW,001B,0000 CUWC,2A19,0 On Module A, status change should be notified to the host. However, Module A currently is in MLDP mode, only output MLDP data to the UART. Instead, GPIO 6 will be set high (Red LED lights up on RN4020 EVB board) to indicate status message pending to output. Once GPIO 4 is put to be low to enter command mode, the status message will be output to the UART.
123456789012345678901234567890FF 12345678901234567890123456789011,000B,02,02 12345678901234567890123456789011,000C,10,02 12345678901234567890123456789022,000E,02,02 4.4.2 Script Input Then we start to write the script by clearing the script and enter script input mode with following commands: WC WW // Clean script // Enter script input mode We need to input following script. After finish entering script, type “ESC” key to exit.
Once timer 1 is expired, event @TMR1 is generated. AIO0, which is the light sensor, is read and the value is assigned to $VAR1. If the reading is within the predefined range (less than 0x0300), then the value is written to handle 0x000B; otherwise, handle 0x000B is not updated. If user would like to debug the script, command “WR,<0-6>” could be used. 4.4.
All transmitters regulated by FCC must comply with RF exposure requirements. KTB 447498 General RF Exposure Guideline provides guidance in determining whether proposed or existing transmitting facilities, operations or devices comply with limits for human exposure to Radio Frequency (RF) fields adopted by the Federal Communications Commission (FCC).