RN4020 to RN4871 Update 2

In this post and the follow on post, I discussed the changes I have made for this transition to the RN4871.   I am getting near the end of this being done.  After testing with a several Play Store Apps (Nordic, Silicon Labs, and Microchip) I found that the name I assigned to the RN4871 was not showing up in the scan.  Again in the RN4020 this was not an issue, the SDN command was sufficient.  But for the RN4871 or maybe the version of BTLE that is running, this is an issue.  Unless you know the MAC address, the user would have a hard time determining which device listed is the Brick Buddy.  It is not uncommon for me to see 10-15 BTLE devices in my lab.  Not sure where they are all coming from, but these is a lot.  

Well it became apparent from examining those devices I was seeing that had a name attached, they were placing this in the Advertisement.  The RN4871 has an Advertisement limit of 30 bytes (31 bytes in later firmware).  Fortunately I had 11 bytes left from 30. So I added the name and that brought me up to 27 bytes total.  But as with adding the service, you could not just put the name in as text, as here.

NA,09,B_Buddy  

The NA command requires the actual hex bytes that represent the name.  This is alluded to in the RN4871 documentation, but is not really clear.  The 09 is the command for the complete local name.  

NA,09,422D4275646479     

It seems that everything works now.  The Android App finds it, connects automatically and the name is displayed with the last two address octets attached.  The Android App does allow you to name the Brick Buddy device and then bind that name to the MAC address.  From then on, it shows the name instead of the MAC address.  A more user friendly approach when you have multiple Brick Buddy's in a MOC.

Final change will be a check to see if the  RN4871 Non Volatile Memory (NVM) is valid.  Not sure how to do this yet.  I am somewhat concerned that reloading the NVM on every restart will wear this out too soon.  Especially for the device(s) I use for development.  The easiest way is probably to place a flag in the PIC EEPROM (or I2C memory when it is installed) that indicated a valid NVM.  Thus when the NVM is written and all commands have been accepted, the flag would be updated.  I currently have a config word that is kept, I just need to add this to it.

 

 

 

 

Microchip BLE Module Comparison

 This shows the relative size comparison of the Microchip BTLE modules.  Numbers are nice, but a visual portrays much more information.  The RN4871 is the smallest.  The newer RNBD451PE is somewhat larger, but maybe all you need depending on what your device is doing.

Enjoy!

 

 

 

RN4020 to RN4871 Update

 

I have had my head down while trying to make this transition that I described briefly in this post.  I have had some success and learned a few things along the way.  

I am no BTLE expert and I have tried to slug through the specifications, but it is a tough read for those of us who don't do this on a daily basis.  The RN4020 was 4.2 and the RN4871 says it is 5.0 and beyond.  I am assuming that some enhanced features were added.  My Android code was quite dependent on this real time read feature of the RN4020.  Without this, getting data back was difficult.  

After some reading, I implemented the Notification feature for each characteristic.  I had done this with the Heartbeat characteristic, but now all of the characteristics have this enabled.  This will also enable me to continue to support existing Brick Buddy I controllers.  The Android APP tested to see if Notifications are enabled on the Brick Buddy.  If they are, the new code is implemented, otherwise the Android APP stays with the old methodology.  So now I write to the Characteristic, the 18F26Q71 performs the tasks, updates the characteristic value and then notifies the Android APP the characteristic has changed.  The APP is waiting (in a separate thread) for a few seconds for the 18F26Q71 to respond (plenty of time at 64MHz).

Next issue was finding the the Brick Buddy during scanning.  The Android APP had implemented a scan search on the MyMakerTools UUID.  While it continues to work for RN4020 devices, it failed on all RN4871 devices.  I could scan for it along with every other BTLE device in the house and the neighborhood.  Sometimes I would see 20 devices.  At first I thought this was an issue with the Delphi compiler.  After tracing deep into the library, I decided this was not the issue.  This must be something to do with advertising.  Again, not a BTLE expert and if the spec changed, then I was not seeing it.  I found a note in a RN4870/4871 firmware upgrade document that said:

This led to lots of reading on the NA command, which is about advertising.  So in the RN4871, you have to purposely advertise services.  If the Android APP is filtering on a specific service list, those services must be advertised.  If not filtering on a specific service list, then all reachable BTLE devices show up.  The system will still connect, but it is multi step process that should just happen.

So here is the initialization of the RN4871 across the ASCII UART interface.  Will another sequence work, probably, but I know this works.

• PZ
• NA,Z  

reboot here

• SS,80            ; setup
  
• SN,B-Buddy       ; device name
  
• SDN,MyMakerTools ; mfg name
  
• PS,3425a5cca67643629592a88e132b8b52       ;service
  
• PC,b67e3a3b15c941b6a9f2fbf379418d12,12,02 ;characteristic
  
• PC,f18e901af3254dfd8cdb68506676dc08,16,08 ;characteristic
• PC,9bac1d289fc14db097c4896089ad26bb,16,08 ;characteristic
• PC,39bb1bf917ec41d2b5e4b78551b45740,06,08 ;characteristic
• NA,01,06         ; set flags
  
• NA,07,528b2b138ea89295624376a6cca52534    ;advertised service
  
• A                ; turn on advertising
  

 The first two clear out the services/characteristics and the advertisement data, followed by a reboot.  The next are setup and naming, followed by the service and the characteristics.  The first NA command sets the flags.  The first hex value is the AD Type which is found in Table 2-14 of the RN4870/71 Users Guide.  The next is an 8 bit value that reflects which flags are active.  You will need to search the internet to find this, but 0x06 is the most common value.  The last NA command is the advertised service.  You will notice that is does not match the service.  For whatever reason, the NA, 07 command will not take the value as the PS command does, it needs to be completely byte swapped.  Not the most user friendly, but probably made sense to someone.  Finally I purposely started advertising.  This is supposed to be the default, but it costs very little.  I did not test the initialization without this, so I don't know if the default is works also.

I am back to where I was with the RN4020.  I still need to verify the Android APP with the original Brick Buddy, but that is a task for another day.