XIAO nrf52840 ArduinoBLE 1 central, 2 peripherals


is it currently possible two have 2 concurrent bluetooth connections from one central to two peripherals (all being XIAO nrf52840)?

Whatever I’m trying, I can’t get it to work.


Hi raffiniert,
I have run a sketch that one central receives data from two peripherals.

Awesome, would you mind sharing it? Thanks!

I’m still debugging before posting. Some problems are that it takes a long time to connect and disconnections are not detected. I am not a software engineer so I may not be able to answer detailed questions. Please use it as a reference.
nRF52_mbed_AttitudeMonitor.zip (9.8 KB)

1 Like

You are my HERO!!
That is incredible. It straight away works.
I will now dig into the code and try to understand it.

If you make any progress on the reconnection-issue, would you mind sharing it?

Thank you so, so much. I would buy you a beer if you give me your Paypal or so.

Glad to help you.
There is a bug in analogRead() that reads battery voltage.
See also the link below.

To my luck, I will connect the battery to the pads on the backside anyway, so if that solves this issue, I’m a happy camper :smiley:

@msfujino it’s all up and running, thank you so much!
Only problem so far left is that I need to transmit float numbers, but you use int16 (if I read correct).

Think I would have to change

#define dataNum 8


union unionData {                   //Union for bit convertion 16 <--> 8
  int16_t   dataBuff16[dataNum/2];
  uint8_t   dataBuff8[dataNum];

however I do not yet know to what :slight_smile:
My desperate try to just change int16_t to float was not successful…

ok it did work simply by doing:

#define dataNum 32


union unionData {                   //Union for bit convertion 16 <--> 8
  float   dataBuff16[dataNum/2];
  uint8_t   dataBuff8[dataNum];

but if this is proper code I do really not know :smiley:

I think the float data is 4 bytes 32 bits.
If you are sending 4 float numbers,

#define dataNum 16                  // roll, pitch, yaw, Vbatt (4 float data 16 bytes)
union unionData {                   // Union for bit convertion 32 <--> 8
  float     dataBuff32[dataNum/4];  // float : 32bit
  uint8_t   dataBuff8[dataNum];

You can confirm this by sending and receiving an easy-to-understand number.

1 Like

hmm no, now the numbers are rounded to xx.00 … before that the numbers looked correct

This is float version. Try it.
nRF52_embed_AttitudeMonitor_float.zip (9.9 KB)

1 Like

Awesome, thank you.
I have everything up and running.

However, it randomly stops the loop:

while (peripheral_1.connected() & peripheral_2.connected()) {

sometimes after a few seconds, sometimes after minutes… but it always stops.

I need it to run reliably for 12h :-/

I “debugged” it by printing to Serial at certain points inside the loop, but it always seems to stop at the above line, not in the middle of the loop.
So that would mean something got disconnected (as you write)?

Any idea?

When either peripheral is disconnected, it will exit the while loop, display which peripheral was disconnected on line 162, disconnect everything once, return to the beginning of the loop, and start making connections. The serial monitor should display the following.
“01 disconnect, and scan_connect again”.
If the first digit is “01”, peripheral_1 is disconnected. 10" indicates that peripheral_2 is disconnected.

If lines 123 and 135 are uncommented, the signal strength can be viewed on the serial monitor. Is the signal strength sufficient?

The serial monitor message should give you some idea of the situation.

I still use a variant of your first code, did you change something according to this?
Because here it just stops without any further message on serial.

I will look into the signal strength now.

But in the comments you wrote “Sometimes Peripheral disconnections may not be detected” - is this still true?

disconnections are not detected

For example, if I press the reset button on a peripheral when it is communicating, I would think that the disconnect should be detectable, but for a while Central receives nonsense data, but the disconnect may not be detected.Even if Central can detect it after a couple of minutes, Central tries to reconnect but cannot.

I measure signal strengths of -50 (+/-10) so that doesn’t sound like the problem?

just to be sure: which hardware do you use?
For me it’s the XIAO nrf52840 (not “sense” in case of the central)

I just removed everything out of the main loop apart from a single


so I can see it’s still running on the Serial monitor, and guess what, it crashed after about 3 minutes…

I hope I do not write this too early, but the board is running perfectly fine since I connected it to a power source instead of having it attached on my MacBook Pro 16" (2019)
No crash since at least 10 minutes now, never ran for so long before.