Revision history:
20141010: original write-up
20141011: updated with additional power measurements
20141024: further info on MLDP
20141109: update re-write
20150821: BLE advertising packet Pandora's Box

I originally published a write up on my RN4020 experiences on 20141010. To my surprise, it generated quite a few hits. Lots of people seem to be searching for more documentation and/or examples. In my opinion (and I believe others' as well), what Microchip has published so far in documentation is not sufficient.

For those searching for better RN4020 documentation, be sure to dig around for the "RN4020 User Guide Addendum.pdf" that is hidden inside the firmware update. It is utterly perverse, but rather than fix the existing User Guide, Microchip has shoveled additional information into this pdf.

This firmware update zip file (containing the pdf) can be found by clicking on the "Release Notes" link under "Bluetooth Low Energy" section of this web page.

Kudos to Brandon Schell, who is apparently an app engineer for Microchip. He has published a YouTube video demonstrating the RN4020 sending a BLE advertising packets. I've documented here what I believe are the RN4020 commands to be equivalent to the YouTube video.

The more 'conventional' Bluetooth LE usage is to "bond" a peripheral to a central (smartphone/tablet). However, for the central to initially find a peripheral, the peripheral must advertise by transmitting messages on known frequencies. A good primer is available here.

By hijacking this mechanism, it is then possible to send very small amounts of data one-way (peripheral to central) without the need for bonding. This opens the door to connection-less information that becomes available when in range of the transmitter.

Note that this opens a Pandora's Box. Such BLE advertising packets don't require receiving or an elaborate protocol stack. As such, it may not be strictly necessary for something as complex or costly as a RN4020.

Here is an interesting effort by Dmitry Grinberg to generate BLE advertising packets with the less costly Nordic nRF24L01+.

IMPORTANT: One piece of information not made public is that there is a "known issue" with the device when MLDP and UUID 2A19 (Battery Service) are enabled at the same time. (An errata sheet from Microchip for customers would have been nice.) The RN4020 User Guide in Section 3.3 (MLDP DEMONSTRATION) actually directs the user to enable both at the same time as an example of the modules operation, and this is apparently bad.

Microchip announced the RN4020 Bluetooth Low Energy module in June 2014, and it looked promising. It has wireless certification for many countries and claims to have a custom protocol for encapsulating serial UART traffic. (Interestingly, module is based on silicon from CSR.)

The RN-4020-PICtail evaluation board is unobtainable and the ship date keeps getting pushed out (it was December 2014, and as of writing this it is now Jan 2015).

However, the module itself is stocked by distributors, so I did a quick-and-dirty PCB to try the module.

My testing was done with two modules that reported "MCHP BTLE v1.10.09 06/09/2014". I was told in October that Microchip had a new release of firmware that it would release soon, but as of this writing I have not seen it. I'm not going to waste my time re-testing the module until at least after the firmware has been updated.

My impression is that there are at least three distinct applications for the module:
1) serial bridge for an iOS device (given that iOS prevents support for Bluetooth CDC)
2) "machine-to-machine" serial bridge between two embedded devices
3) more traditional Bluetooth LE applications (primarily with iOS devices)

Of these three, I suspect the one which users might find the most traction is with #1. However, this was not the target application I was considering, so I have practically no information on this.

Something about the "MLDP" functionality that annoyed me was that the "Server" (aka Peripheral) module would automatically switch into MLDP mode without being locally directed to do so. I assume this is to be more friendly to application #1.

MLDP mode seems to happen in any of the following situations:
CMD/MLDP=1 *and* connection hasn't yet failed
CMD/MLDP=0 and "I" command issued and connection hasn't failed
CMD/MLDP=0 and MLDP enabled on the other side of the link

Despite the nomenclature of the "CMD/MLDP" pin, CMD mode appears to actually be controlled by the WAKE_SW pin.

The more generic Bluetooth Low Energy functionality (ala Application #3) looks a bit more promising.

The module can act as a proxy for a host. Simple values can be written into the module via the UART, and then the module serves them up to a Bluetooth LE "Client". The documentation serves up UUID 2A19 (Battery Service) as the token example of representing a value from 0-100 (representing a percentage).

This is potentially nice, as it means the host can spend the absolute minimum time awake and let the module do the Bluetooth LE work.

I collected power consumption numbers under two conditions (and these are links to graphs on a separate page):
RN4020 with Advertise enabled but without being Connected
RN4020 with Advertise enabled and Connected to by another RN4020 as Client

Note that power consumption is a function of the settings provided by the "ST" command, and the default settings may prioritize throughput and low-latency over power consumption. If the RN4020 is used as a "Client", it will honor the settings offered by the "Server". If the "Client" is something other than a RN4020, the "Client" may dictate its own Interval/Latency/Timeout settings.

I tried using gatttool (even with the latest source code) to connect to the RN4020. It was able to Connect (albeit with a inactivity timeout), but I had no success with Notifications. There are examples online of the same functionality working with the TI Sensor Tag, and it is not clear what the TI Sensor Tag does that the RN4020 does not.

.

back to main page contact