BLE advertising capabilities and beacon role, OTA FW upgrade support

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

I need some help in setting up architecture for the project I'm working on.

   

I have an monitoring battery powered embedded device with three physically separated boards (three batteries), like on the image attached.

   

Each one of them has one RF and one Cypress BLE module (CYBLE-022001-00). Firmware on microcontroller on each one of the boards must be updated via BLE module, i.e. via OTA (BLE module is via I2C connected to the microcontroller).

   

User must via mobile phone APP connect to Main BLE module which should provide two way communication (typical Client-Server, i.e. Central-Peripheral setup). Main board will further exchange all needed data (system related measurement) with the rest of the boards via RF, not via BLE.

   

I have BLE modules on the Peripheral boards mainly for the OTA FW upgrade support. But since they are there, I would like to use them for something else.

   

My questions are the following:

   

 - Can BLE modules on the Peripheral boards constantly advertise some data (once per second) both to the Mobile APP and MAIN board? This would be just some TRUE/FALSE bytes, and only a few of them.

   

 - If it is possible, can BLE modules advertise data to Main BLE and Mobile APP if the last two are connected and exchanging some data?

   

This raises additional questions:

   

- I don't want BLE modules on Peripheral boards to be beacons. As far as I understand, I will lose than possibility to connect to those modules and do the OTA FW update. Am I right?

   

- I would like BLE modules on Peripheral boards to do the advertising, but to be also connectable if I want so (although they Services would be only for the FW OTA). Is it possible to make Peripheral BLE modules in this "only advertise but also possible connectable mode", (if it is possible) to spend batteries as little the BLE beacons would?

   

Please point to other issues if I have missed some, which could jeopardize system architecture.

   

P.S. Also, these boards could be purchased separately, so I must ensure that I can introduce new board to the system, although the rest of the system doesn't know its BLE and RF addresses. Any ideas on this?

   

Thanks,

   

Vojislav

0 Likes
1 Solution
Anonymous
Not applicable

1) Yes, advertisement packets can be received by any number of BLE radios if they are Scanning for packets.

   

2) No, you can advertise while connected with another BLE chip, but I do not believe you can scan while connected with another device. (Might be a question for a cypress employee). This means that you wouldn't be able to have a BLE connection active and still be receiving advertisement packets from other radios. Since BLE is connectionless, you could try doing multiple "sessions", where you connect, read data, disconnect, read advertisement packets, then repeat until done.

   

3) I'm not sure about OTA updates, as I haven't played with them, but I know that having the chip behave as a beacon merely means that it advertises packets, and refuses all connections. Since this is a software setting, you can control it through your RF channel, and turn off the "beacon" mode to allow the OTA update?

   

4) Since the radio is configurable, you can change it from connectable to unconnectable as the software runs (I'm currently doing this in one of our products). You merely need to turn on and off the radio advertisement with different advertisement info settings set/cleared.

   

You can adjust the advertisement radio settings to reduce power consumption, but there will always be a tradeoff between latency, power-saving, and data rates.

   

Advice: Depending on whether you have physical access to the devices, you can pair the boards together on purchase/setup and have them proceed to use the boards they are paired with. Ultimately, if you want variable addresses on the boards, but only need to set them up together once, then you can do "Bonding", and save the boards once they connect the first time to automatically accept connections from the bonded devices at a later time.

   

Since you already have a BLE chip on each of the boards, from a battery perspective, it would probably be better to architect the devices to all communicate without using the OOB RF, but that is your prerogative if you feel it is necessary.

   

Using some timing mechanisms, you can setup the main ble chip to divide it's time between connecting to the peripheral boards and advertising data/connecting to the mobile phone/app. This would allow you to keep the data all centralized on the main board for the phone to read off of "one connection", rather than sending data through advertisement packets. This allows for better security methods should you choose to implement them as well. It also allows you to make the beacons unconnectable for OTA unless the main chip tells them to get ready for a OTA update.

View solution in original post

0 Likes
7 Replies
Anonymous
Not applicable

1) Yes, advertisement packets can be received by any number of BLE radios if they are Scanning for packets.

   

2) No, you can advertise while connected with another BLE chip, but I do not believe you can scan while connected with another device. (Might be a question for a cypress employee). This means that you wouldn't be able to have a BLE connection active and still be receiving advertisement packets from other radios. Since BLE is connectionless, you could try doing multiple "sessions", where you connect, read data, disconnect, read advertisement packets, then repeat until done.

   

3) I'm not sure about OTA updates, as I haven't played with them, but I know that having the chip behave as a beacon merely means that it advertises packets, and refuses all connections. Since this is a software setting, you can control it through your RF channel, and turn off the "beacon" mode to allow the OTA update?

   

4) Since the radio is configurable, you can change it from connectable to unconnectable as the software runs (I'm currently doing this in one of our products). You merely need to turn on and off the radio advertisement with different advertisement info settings set/cleared.

   

You can adjust the advertisement radio settings to reduce power consumption, but there will always be a tradeoff between latency, power-saving, and data rates.

   

Advice: Depending on whether you have physical access to the devices, you can pair the boards together on purchase/setup and have them proceed to use the boards they are paired with. Ultimately, if you want variable addresses on the boards, but only need to set them up together once, then you can do "Bonding", and save the boards once they connect the first time to automatically accept connections from the bonded devices at a later time.

   

Since you already have a BLE chip on each of the boards, from a battery perspective, it would probably be better to architect the devices to all communicate without using the OOB RF, but that is your prerogative if you feel it is necessary.

   

Using some timing mechanisms, you can setup the main ble chip to divide it's time between connecting to the peripheral boards and advertising data/connecting to the mobile phone/app. This would allow you to keep the data all centralized on the main board for the phone to read off of "one connection", rather than sending data through advertisement packets. This allows for better security methods should you choose to implement them as well. It also allows you to make the beacons unconnectable for OTA unless the main chip tells them to get ready for a OTA update.

0 Likes
Anonymous
Not applicable

Thanks a lot,

   

this was very useful! I'm still not aware of all the possibilities of BLE communication. Your idea to drop on the RF in favor of the BLE is the one that draw my attention the most.

   

So, just one question more. Peripheral boards should talk with the Central board via BLE. Central would talk with the App also via BLE, but only Central should be able to talk to the App. App shouldn't see Peripheral BLE boards.

   

(1) Is that somehow possible? (I guess it is for the App, but not for other mobiles scanning the area).

   

The perfect solution would be that Central BLE can exchange some data (in both directions) with Peripherals with whom he could automatically connect each time he detects them (if their advertise data starts with some preface or similar). This is possible of course only if he isn't already connected to the mobile App. But you mentioned that even then, I could periodically disconnect from the App, talk with Peripherals and then connect again.

   

(2) Is it possible for BLE module that plays Peripheral Role to do that? 

   

From your advices is seems that even when connected, BLE modules would spend very little (comparable with RF) (I guess because they would scan/listen in combination with sleep and deep sleep).

   

(3) This is your experience from earlier work? I would be more than happy to get rid of the RF modules 🙂

0 Likes
Anonymous
Not applicable

1) You can setup the peripheral chips to only send scan responses to whitelisted devices, and to only allow whitelisted devices to connect (either or). In effect, you can setup the peripherals to be bonded with the central, and once bonded they will be store the connection information for reconnecting in the future as the app runs. Unfortunately, "not seeing" the peripheral boards would be up to the mobile app to figure out which one is the central, and only connect to the central. Since the peripherals will be whitelist-protected, the mobile app won't accidentally connect to them, but it will still see them when "passively scanning". The active scanning is when the peripheral sends a scan response packet to the device scanning it (which can have customized data to indicate if it is a peripheral or not?). If you name the peripherals and central differently, or use some identification scheme, then it should be pretty easy to separate which ones to connect to for the mobile app.

   

For the BLE protocol, central and peripheral are the two sides for the connection establishment, while client and server are the data-handling. Any BLE chip can be central and/or peripheral, and client and/or server, but if you don't want the functionality associated with the "mode", then turning it off prevents accidental data writes/issues. 

   

If you want the mobile app to only see the central board, then you can setup the mobile app to include the central in the whitelist when it scans for devices, meaning that it will scan all BLE devices, but will only return an event/success on finding one of the devices in the whitelist (I havn't worked with mobile apps much, but I'm assuming it behaves similar to the embedded ble radio). 

   

2) Since you can have any ble chip be both central and peripheral, you can (in effect), set up the peripherals to connect to the central device, exchange data, then disconnect rather than having them wait until the central connects to them for data. The peripheral role means that it can "advertise" to other ble chips, and the central role means it can "scan, and connect" to other ble chips that are advertising.

   

If you wanted the "peripheral" chips to connect to the "central" chip, then you would need to have the ble chips on the peripheral modules set to central mode (and peripheral if you want them to advertise too).

   

Yeah; the BLE chips (emphasis on Low Energy) would spend most of their time asleep between packet transmissions, and hence would only use energy when: advertisement packet is send, scan packet is sent or received, or when data is sent or recevied (which takes multiple packets depending on what is going on).

   

3) I haven't spent much time working directly with RF modules, but based on the Bluetooth Low Energy chip (BLE) being architectured to use very little energy overall, my guess is that it would save on power if you are planning on using a bluetooth chip already. RF would allow for more customized protocol/data transmission, but I haven't worked with it before. I am currently working with the BLE PRoC chips however, and they are almost never actively running/transmitting data from what my tests show (although I'm only sending a few bytes for communications).

   

Unless you have a specific need for the RF modules besides communication between the three on-board chips/modules, since you are already planning on using the BLE chips to communicate with the mobile app, you should be able to reuse the BLE chips for communicating between the boards, and that makes the RF chip a redundancy as far as communicating data between the chips (not to mention the power specs might be worse, the board cost will be higher, and there will be more things that can go wrong).

   

From my perspective, it seems that using a BLE chip on all three boards, and setting up a behavior between the three chips to allow:

   
        
  • Data centralizing from the peripherals to the central device
  •     
  • Sending data from the central to the mobile device when mobile device is currently "active" or "connected" with the central
  •     
  • Being able to update the peripherals and the central from the mobile app
  •    
   

This would all involve some development indeed 😄

   

To get it all behaving properly would take some flags and data transmission between the peripherals, central, and mobile app dedicated specifically to the different points above.

   

Removing the RF modules would be my advice, but since I haven't done much work with RF modules in practice *shrug*, it would ultimately be up to your judgement call on whether you think they add more benefit than cost by being on the board 🙂

0 Likes
Anonymous
Not applicable

Thank you for these more than useful suggestions. They helped me clear my vision regarding the different aspects of BLE usage. I would definitely try to get rid of the RF modules, since they are, as you said, redundant. It will make later testing and certification less demanding, and price will be lower too. But the main gain I see here is the knowledge 🙂 Thanks once more. I need some time to clear up things and to sort everything in my head. Then, I will inform you about the conclusions I made, and maybe ask additional question 🙂

   

Cheers!

0 Likes
Anonymous
Not applicable

Good luck! And you're welcome 🙂

   

Definitely worth reading a bluetooth guide/tutorial/book on the subject matter, but alas not many have that much free time 😞

0 Likes
Anonymous
Not applicable

Hello Pratt. I started another thread here http://www.cypress.com/forum/psoc-4-architecture/ble-embedded-network-architecture-organization, now with more detailed observations and questions. Just for you to know if you are interested in how this will end up 🙂

0 Likes
Anonymous
Not applicable

It definitely looks like a fun project! I'll be sure to check out the thread 🙂

0 Likes