Library for creating a local group of devices using BLE

If I remember correctly Particle was talking about increasing the BLE connection limit to something like 10 or 20 simultaneous connections vs the current 3 device limit.

@ScruffR Do you have any memory of seeing anything like that? I’m like 99% sure I did read it somewhere on here :thinking:

@mariano If Particle did increase this connection limit do you see any problem with your library being able to expand to handle 10-20 links vs 3?

Also the other question is about what drove you to create this library?

I can’t say I did - but that doesn’t mean it didn’t happen :blush:

1 Like

The issue I can see is performance. The way the library works is that the Central device relays all messages to all peripherals, as each peripherals is keep track of event subscription from the application to run the callback. The more devices linked to the Central, the lower the throughput.

I created this library to help with the issue where a mesh is not necessary, but publish/subscribe capabilities among a group of nearby Gen3 devices is.

1 Like

I doubt I would ever need 10 BLE devices connected at the same time but 5-6 sensor nodes I could see being useful.

1 Like

I plan to add BLE sensors to my current device. It currently has three “onboard” sensor jacks for temperature, water leak, float switch, etc. In my head I was thinking that more than 3-4 BLE sensors would probably consume too much RAM given the other code I have. I’m happy with 3 BLE peripherals if that’s the limit, at least for my current application.

@mariano I would like to dig into the performance issue a little bit further - is the total processing time purely related to the number of peripheral devices i.e. O(n) or is there something else limiting the peripherals to 3 per central device? If the central device was an Argon/Boron and was acting purely as a gateway to Particle Cloud then the application could be fairly small. How does your BLE group handle sleeping peripherals?

The limit of 3 links is the limit on connections that Device OS has. As for sleeping peripherals, if the BLE radio goes away, it’ll be removed from the list (and will call the onDisconnect callback), and then if you scan, it will reconnect when it comes back.

So could you have a bunch of “sleepy” BLE peripherals and service them as they appeared ?

1 Like

Yes, you could do something like that. Have the “sleepy” peripherals do a group->publish() in the onConnect() callback.

Probably want to stay away from having these peripherals subscribe to events, unless they are an immediate response to a publish, since they will miss anything that is published while they are sleeping.

I guess I didn’t ask my question clearly enough. The device OS has a limit of 3 but is there a specific technical limitation for this number?

The sleepy endnode part is easy to handle but requires a fast connection - is the BLE connection as fast as Mesh?

The limit of 3 is due to RAM limitations. To handle more connections, Device OS would have to allocate more RAM to the Bluetooth softdevice, leaving less for the application.

Understood and thank you for explaining that - it does beg the reply - couldn’t that be something/a parameter that could be changed via a Device API - if I have no need for BLE but want to have more RAM for a ML model then I set to 0 if I can do with less RAM and I need 5 or 6 BLE connection?

1 Like

That’s a very good question. Unfortunately the RAM for the softdevice needs to be allocated at Device OS compile time, so an API for changing that is not possible.

That’s disappointing.

Since the obit for Mesh went out, this has been my primary need. I spent a lot of time and effort converting a bunch of Photons to a Gen3 Mesh network in order to have low latency local sync, and right now I have an Argon as an orchestration device that then issues commands to a bunch of Xenons and keeps everything in sync.

This seems to be perfect for my needs, so THANK YOU!

@ScruffR Any more information on the chance of increasing the limit of devices? My setup already has 4 satellites (very small physical area) so this limitation is a real hurdle in recovering from the loss of Mesh functionality. I am going to expand to 5 but I doubt I’d ever even hit 8.

Have you seen this earlier response?

To manage any expectation - if Particle decide to increase the current limit of 3 peripherals this will only happen once the Mesh network stack is removed from the Device OS = post 1.6.X. and thus there should be more Flash and RAM available.

There is still the issue that the realistic range of BLE is 10-20 metres and most environments are now highly “polluted” with BLE devices and traffic plus there isn’t the security in data transfer. I am going to explore BLE as it stands to replace Mesh networks as such a short range is OK for my applications and I can live without OTA update.

According to Nordic, bluetooth 5 range is quite a bit more than what we’re used to seeing with previous bluetooth versions.

I suspect that 50-60m indoors mentioned was “under ideal conditions” - I would be very happy to get that in an office/school/university environment. If you have any “real-world” experience with the Particle Gen3 devices I would interested to hear it.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.