Hello everyone! This thread is similar to Indoor BLE Range Improvements , as same system is used. There we discuss about S140 Soft Device scheduling conflict and here we want to talk about problem caused by device out of range. Background We are in development phase for indoor household appliances with many wireless connected entities. There is a requirement to support following topology: 8 battery powered devices and single mains powered device. As the target environment is indoor and low rate of data exchange (low bandwidth) is needed, we agree to test out BLE5 LE CODED PHY (S=8, 125kbit/s) aka. LongRange, using Minew MS88SF3 module that features nRF52840 chipset. So, we prepare a simple mock-up test application to check out how the system will behave in real-life scenarios. Test application was very simple, central BLE device scans continuously and stops after all 8 connections are established. Peripheral BLE devices advertise when not in connection. With such approach system shall always converge to have all devices connected, as if one device gets disconnected advertising/scanning shall re-started and the drop connections should re-establish. Every second 64 bytes of dummy data were exchange between central and peripheral device based on server-initiate update (notification type). Tx power for advertising and connection was set to 8dBm. Connection interval was set to 1500ms, SlaveLatency to 2 and Supervision Timeout to 15000ms. Well, it works perfectly on a desk! BLE settings Platform description: IC: nRF52840 Module: Minew MS88SF3 SDK: nRF5_SDK_17.1.0_ddde560 Softdevice: s140_nrf52_7.2.0 IDE: SEGGER Embedded Studio for ARM Release 7.10a Build 2022121504.52072 OS: Windows 10 "Out of range" problem We done a couple of test and found out that: If we take Device A (one of the 8 peripheral devices, all in connection) out of range, it disconnects. If then moved back to range, it connects back without any problems - NORMAL EXPECTED OPERATION , If we take Device A (one of the 8 peripheral devices, all in connection) out of range, it disconnects. If we then move Device B ( one of the 8 peripheral devices, all beside Device A in connection) out of range, it disconnects. Then Device B does not re-connect when moved back to range. Only after moving Device A back to range, both Devices A & B gets re-connected. It is like Device A is blocking Device B from re-connectiong, regardless Device B is in range! - ABNORMAL OPERATION , We observe that only first disconnected device (due to out of range) blocks other from re-connecting . Moving first disconnected device back to range triggers all other devices to re-connect, We suspect that Device A (goes out of range first) block Device B in context of advertisement, as both devices are peripheral. But that is not the case as we done separate tests to eliminate that possibility, where the first disconnected device did not start advertising at disconnection. Same effect was observed, other devices did not re-connect and thus conclude that advertisement do not play role in that effect, meaning that the problem lives on Central device . If we disable data transmission on Central Device and Device A and repeat point 2., Device B gets re-connected when moved back to range. In that test case Device A did not blocked Device B from re-connection. We done a couple of tests addressing "blocking problem" and there was a consistent outcome. Following picture shows the above described problem on real test mock-up system with 9 peripheral devices. For that test we disable data transmiting for Central device, Dev#6 and Dev#16 . During that test following events takes place: 1. Dev#14 lost connection (not on purpose, might cause moving people around it, closing doors) and was automatically reconnected back - Not expected, but NO PROBLEM! 2. Dev#6 lost connection on purpose, to test that central device is working OK. Reconnected OK! 3. Dev#16 was moved out of range and gets disconnected - OK, expected! 4. Dev#6 remove battery to test if will reconnect on putting battery back - OK, RECONNECTS! 5. Repeate point 4. - RECONNECTS! 6. Repeate point 4. - RECONNECTS! --> Consistent reconnection-OK! 7. Moving Dev#16 back to range and device reconnects! It disconnects and reconnect 2x due to moving the device! - OK, expected! 8. Moving Dev#15 out of range. That device do not have tx disabled. Device disconnects. - OK, expected! 9. Repate point 4. - DOESN'T RECONNECTS! ABNORMAL BEHAVIOUR! 10. Moving Dev#15 back to range. It connects back! - OK, expected for Dev#15 to re-connect! 11. Dev#6 connect back right after Dev#15 reconnects! STRANGE BEHAVIOUR, as it Dev#15 blocked Dev#6 from re-connecting! 12. Dev#15 lost connection (not on purpose, might cause moving people around it, closing doors) and was automatically reconnected back. - Not expected, but NO PROBLEM! All events are shown on the picture: Therefore, following questions arise: Why does the Device A block Device B from re-connection as described at point 2. (As said, we think it is a Central Device issue)? What is the rational explanation for that? Why is there a different behaviour between point 2. & 3.? As transmission is the only difference it must be the source of problems, or?! How can we mitigate that "blocking problem", where Device A blocks Device B from re-connection within a valid range? Do you receive any similar reported problems? If so, how do they solve it? Thank you for all the help! BR, Žiga

I think I got it! But there is still a lot to be tested before celebration PROBLEM WHAT : Central device did not end connection initiation procedure, no timeout was implemented! Calling " sd_ble_gap_connect " with scan timeout of 0 will never timeouted! WHY: After calling " sd_ble_gap_connect" additional advertising packet needs to be received before SD start to send connection request to peer device. In case of DevB adv packets were received very reliable and connection establishment was done immediately. In case of DevA that was on rangle limit its adv packet come very offset and very randomly. So between first and second adv packet it might pass couple of minutes or it might take indefinetly. Central was therefore blocked waiting for that second adv packet. And from outside it looked like it stop to scan. (Here I was misdirected...) SOLUTION : Implemented timeout for connection initiation (when first calling " sd_ble_gap_connect ") and at timeout event calling " sd_ble_gap_connect_cancel ". In picture below there is a sequence diagram of described scenarious for both devices: Similar issues were discussed on several Nordic Dev Zone post, but unfortunatelly I wasn't come across them before: 1. https://devzone.nordicsemi.com/f/nordic-q-a/63088/it-is-possible-to-set-a-timeout-between-sd_ble_gap_connect-till-ble_gap_evt_connected-event 2. https://devzone.nordicsemi.com/f/nordic-q-a/99516/sd_ble_gap_connect-times-out-but-ble_gap_evt_timeout-never-fires 3. https://devzone.nordicsemi.com/f/nordic-q-a/10386/sd_ble_gap_connect-timeout-in-s120-central What do you think of that? BR, Žiga

Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Out of range catastrophe

Ziga Miklosic over 3 years ago

Hello everyone!

This thread is similar to Indoor BLE Range Improvements , as same system is used. There we discuss about S140 Soft Device scheduling conflict and here we want to talk about problem caused by device out of range.

Background

We are in development phase for indoor household appliances with many wireless connected entities. There is a requirement to support following topology: 8 battery powered devices and single mains powered device. As the target environment is indoor and low rate of data exchange (low bandwidth) is needed, we agree to test out BLE5 LE CODED PHY (S=8, 125kbit/s) aka. LongRange, using Minew MS88SF3 module that features nRF52840 chipset.

So, we prepare a simple mock-up test application to check out how the system will behave in real-life scenarios. Test application was very simple, central BLE device scans continuously and stops after all 8 connections are established. Peripheral BLE devices advertise when not in connection. With such approach system shall always converge to have all devices connected, as if one device gets disconnected advertising/scanning shall re-started and the drop connections should re-establish. Every second 64 bytes of dummy data were exchange between central and peripheral device based on server-initiate update (notification type). Tx power for advertising and connection was set to 8dBm. Connection interval was set to 1500ms, SlaveLatency to 2 and Supervision Timeout to 15000ms. Well, it works perfectly on a desk!

BLE settings

Platform description:

IC: nRF52840
Module: Minew MS88SF3
SDK: nRF5_SDK_17.1.0_ddde560
Softdevice: s140_nrf52_7.2.0
IDE: SEGGER Embedded Studio for ARM Release 7.10a Build 2022121504.52072
OS: Windows 10

"Out of range" problem

We done a couple of test and found out that:

If we take Device A (one of the 8 peripheral devices, all in connection) out of range, it disconnects. If then moved back to range, it connects back without any problems - NORMAL EXPECTED OPERATION,
If we take Device A (one of the 8 peripheral devices, all in connection) out of range, it disconnects. If we then move Device B (one of the 8 peripheral devices, all beside Device A in connection) out of range, it disconnects. Then Device B does not re-connect when moved back to range. Only after moving Device A back to range, both Devices A & B gets re-connected. It is like Device A is blocking Device B from re-connectiong, regardless Device B is in range! - ABNORMAL OPERATION,
We observe that only first disconnected device (due to out of range) blocks other from re-connecting. Moving first disconnected device back to range triggers all other devices to re-connect,

We suspect that Device A (goes out of range first) block Device B in context of advertisement, as both devices are peripheral. But that is not the case as we done separate tests to eliminate that possibility, where the first disconnected device did not start advertising at disconnection. Same effect was observed, other devices did not re-connect and thus conclude that advertisement do not play role in that effect, meaning that the problem lives on Central device.

If we disable data transmission on Central Device and Device A and repeat point 2., Device B gets re-connected when moved back to range. In that test case Device A did not blocked Device B from re-connection.

We done a couple of tests addressing "blocking problem" and there was a consistent outcome. Following picture shows the above described problem on real test mock-up system with 9 peripheral devices. For that test we disable data transmiting for Central device, Dev#6 and Dev#16. During that test following events takes place:

1. Dev#14 lost connection (not on purpose, might cause moving people around it, closing doors) and was automatically reconnected back - Not expected, but NO PROBLEM!
2. Dev#6 lost connection on purpose, to test that central device is working OK. Reconnected OK!
3. Dev#16 was moved out of range and gets disconnected - OK, expected!
4. Dev#6 remove battery to test if will reconnect on putting battery back - OK, RECONNECTS!
5. Repeate point 4. - RECONNECTS!
6. Repeate point 4. - RECONNECTS! --> Consistent reconnection-OK!
7. Moving Dev#16 back to range and device reconnects! It disconnects and reconnect 2x due to moving the device! - OK, expected!
8. Moving Dev#15 out of range. That device do not have tx disabled. Device disconnects. - OK, expected!
9. Repate point 4. - DOESN'T RECONNECTS! ABNORMAL BEHAVIOUR!
10. Moving Dev#15 back to range. It connects back! - OK, expected for Dev#15 to re-connect!
11. Dev#6 connect back right after Dev#15 reconnects! STRANGE BEHAVIOUR, as it Dev#15 blocked Dev#6 from re-connecting!
12. Dev#15 lost connection (not on purpose, might cause moving people around it, closing doors) and was automatically reconnected back. - Not expected, but NO PROBLEM!

All events are shown on the picture:

Therefore, following questions arise:

Why does the Device A block Device B from re-connection as described at point 2. (As said, we think it is a Central Device issue)? What is the rational explanation for that?
Why is there a different behaviour between point 2. & 3.? As transmission is the only difference it must be the source of problems, or?!
How can we mitigate that "blocking problem", where Device A blocks Device B from re-connection within a valid range?
Do you receive any similar reported problems? If so, how do they solve it?

Thank you for all the help!

BR, Žiga

Top Replies

Parents

0 Simonr over 2 years ago
Hi again

So, the only thing we can see that could be the issue, is that you seem to call the sd_ble_gap_connect() function manually in your project instead of our scan module, where it's called from nrf_ble_scan_connect_with_target(). You can see the nrf_ble_scan.c/.h files for reference.

It's hard to tell without being able to debug on our end, but there must be that your project doesn't want to call sd_ble_gap_connect() when what you describe with device B trying to reconnect before device A occurs. A few things you could try to narrow down the issue:

1. Enable logging that prints out scanned devices so you can see if device B is actually detected on the scanner side at all.

2. Remove the whitelisting altogether on the scanner, and check whether or not you're then able to capture advertising and connect to device B in this scenario. That way we should be able to pin point the issue to be either of the following:

Scanner can't scan for advertising packets from device B because of the whitelist implementation

Scanner finds advertising packets from device B but does not call sd_ble_gap_connect() due to some logic or filter (whitelist most likely)

Scanner calls sd_ble_gap_connect() for B, but the radio packet isn't sent for some reason.

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Ziga Miklosic over 2 years ago in reply to Simonr

Hi Simonr ,

Simonr said:
So, the only thing we can see that could be the issue, is that you seem to call the sd_ble_gap_connect() function manually in your project instead of our scan module, where it's called from nrf_ble_scan_connect_with_target(). You can see the nrf_ble_scan.c/.h files for reference.

Yes, but the program flow is the same. At advertising report checking for target device (whitelist), then performing connection by first calling sd_ble_gap_scan_stop() and then sd_ble_gap_connect(). After that continue scanning with sd_ble_gap_scan_start(NULL, ...) is called. Therefore our custom code and Nordic official scan module have a same sequence of SD API calls. So I would argue that custom implementation of that specific code shall not be a problem...

Simonr said:
1. Enable logging that prints out scanned devices so you can see if device B is actually detected on the scanner side at all

I have done that and capture all BLE related events on central side. There was very little code change, nothing that directly related to BLE. In following attachment you can find debug log:

Fullscreen OutOfRange_Central_DebugLog_ManyDevice_Error_2__13_06_2023.txt Download

 
********************************************************
        RND Central Mockup
********************************************************
 Software Version 0.0.4.0 (Builted on May 24 2023 11:35:03)
 Hardware Version 1.9.0.0
 
 Enter 'help' to display supported commands
********************************************************
Ready to take orders...
BLE_C: Change default connection parameters!
WARNING: Scanning disabled! Enable via "BLE Scan Control" parameter.
APP: Storing statistics OK!
APP: Storing statistics OK!
APP: PAIR button pressed!
BLE_C: Scanning started!
BLE_C: Connectable advertising report from F6:7C:55:2B:92:12
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 1
BLE_C:    Connection handle: 0
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: F6:7C:55:2B:92:12
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
APP: PAIR button releassed!
BLE_C: Connectable advertising report from E4:8E:30:81:78:D9
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 2
BLE_C:    Connection handle: 1
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: E4:8E:30:81:78:D9
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 0!
BLE_C: Writing to RX characteristics error on conn_handle: 1!
BLE_C: Connectable advertising report from E2:88:C0:EE:68:12
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 3
BLE_C:    Connection handle: 2
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: E2:88:C0:EE:68:12
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 0!
BLE_C: Writing to RX characteristics error on conn_handle: 2!
BLE_C: Connectable advertising report from FC:B4:D7:B8:28:4B
BLE_C: Writing to RX characteristics error on conn_handle: 0!
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 4
BLE_C:    Connection handle: 3
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: FC:B4:D7:B8:28:4B
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Writing to RX characteristics error on conn_handle: 0!
BLE_C: Writing to RX characteristics error on conn_handle: 3!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Writing to RX characteristics error on conn_handle: 3!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 128 bytes!
BLE_C: Connectable advertising report from CE:AA:75:A4:1C:F1
BLE_C: Msg received on connection handle 3 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 3 with size of 128 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 192 bytes!
BLE_C: Msg received on connection handle 3 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 192 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 5
BLE_C:    Connection handle: 4
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: CE:AA:75:A4:1C:F1
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 4!
BLE_C: Writing to RX characteristics error on conn_handle: 4!
BLE_C: Writing to RX characteristics error on conn_handle: 4!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Connectable advertising report from C8:B3:A5:1E:3B:30
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 6
BLE_C:    Connection handle: 5
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: C8:B3:A5:1E:3B:30
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 5!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 208 bytes!
BLE_C: Msg received on connection handle 5 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 5
BLE_C:   Connection handle: 0
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 4
BLE_C:   Connection handle: 1
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
BLE_C: Connectable advertising report from E4:8E:30:81:78:D9
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 5
BLE_C:    Connection handle: 0
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: E4:8E:30:81:78:D9
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 0!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Connectable advertising report from F6:7C:55:2B:92:12
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Scanning started!
BLE_C: ------------------------------------------------------------
BLE_C: New connection established! Link count: 6
BLE_C:    Connection handle: 1
BLE_C:                 Role: CENTRAL
BLE_C:             Peer MAC: F6:7C:55:2B:92:12
BLE_C:  Connection interval: 1000 ms
BLE_C:        Slave latency: 2
BLE_C:   Supervisor Timeout: 15000 ms
BLE_C: ------------------------------------------------------------
BLE_C: Writing to RX characteristics error on conn_handle: 1!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Connectable advertising report from D6:E7:74:FA:FE:0F
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 176 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 4 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 3 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 5
BLE_C:   Connection handle: 4
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 4
BLE_C:   Connection handle: 3
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
BLE_C: Msg received on connection handle 0 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 3
BLE_C:   Connection handle: 0
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 208 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 144 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 208 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 160 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 5 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: ------------------------------------------------------------
BLE_C: Connection lost! Link count: 2
BLE_C:   Connection handle: 5
BLE_C: ------------------------------------------------------------
BLE_C: Scanning started!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 224 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Rx buffer overflow! Increse buffer size via "BLE_C_RX_BUF_SIZE" macro!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 144 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 1 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 192 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
BLE_C: Msg received on connection handle 2 with size of 128 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 64 bytes!
APP: Storing statistics OK!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!
BLE_C: Msg received on connection handle 2 with size of 240 bytes!

Measurement was done with single central device (same FW as discussed above in the post) and 8 peripheral devices, to mimic the real life scenario problem. Two of peripheral devices was out of range from begging of the test, but that is not important at that point. What I found out that after the random time during test, scanner on central side stops. So debug log "Connectable advertising report" stops. The peripheral device was in fact advertise in that time, as this was confirm by nRF Sniffer! But on central device advertising report callback did not come as there was no debug log saying "Connectable advertising report".

Conclusion

Simonr said:
Scanner can't scan for advertising packets from device B because of the whitelist implementation

Scanner finds advertising packets from device B but does not call sd_ble_gap_connect() due to some logic or filter (whitelist most likely)

Scanner calls sd_ble_gap_connect() for B, but the radio packet isn't sent for some reason.

None of the above is true.

There is no filtering/whitelist problem at all. It is simple the central device stops to scan. The advertising report callback from Soft Device is not being invoked anymore. With the fact that peripheral device advertise correct packets with expected magic number for filtering, as inspected by nRF Sniffer + Wireshark.

So there we have it, central device stops to scan. That must be te problem here as all facts point to that issue.

The question now is, why does that happens? Do we have some scan related software issues? Can you find any anomaly in our code implementation to manifest in scan problems?

Thank you again with all the help!

BR, Žiga

0 Simonr over 2 years ago in reply to Ziga Miklosic

Hi Žiga

But if the central device stops scanning, it doesn't make sense that it is able to immediately reconnect if advertising device A moves back into range, which is still the case, correct? Putting device A back into range wouldn't restart the scanning in any way, so it's more likely that the scanner can't scan for advertising packets other than from device A when device A was first moved out of range, which is likely why you don't see advertising reports from device B in your log. It's definitely advertising (from the sniffer traces) and I think the central is indeed scanning (since it reconnects immediately to device A when it is moved back into range), so to me it sounds like it's just not picking up advertising packets from device B in this scenario for some reason.

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Simonr over 2 years ago in reply to Ziga Miklosic

Hi Žiga

But if the central device stops scanning, it doesn't make sense that it is able to immediately reconnect if advertising device A moves back into range, which is still the case, correct? Putting device A back into range wouldn't restart the scanning in any way, so it's more likely that the scanner can't scan for advertising packets other than from device A when device A was first moved out of range, which is likely why you don't see advertising reports from device B in your log. It's definitely advertising (from the sniffer traces) and I think the central is indeed scanning (since it reconnects immediately to device A when it is moved back into range), so to me it sounds like it's just not picking up advertising packets from device B in this scenario for some reason.

Best regards,

Simon
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 Ziga Miklosic over 2 years ago in reply to Simonr

Hi Simonr,

Simonr said:
But if the central device stops scanning, it doesn't make sense that it is able to immediately reconnect if advertising device A moves back into range, which is still the case, correct?

Yes, this is the case. I should have stated "central device stops to scan" in more precise way! It is more like: "Central device scan is blocked by out of range DevA". And from DevB perspective we can say: "Central device stops to scan", as effectively we observed that from DevB point of view.

Simonr said:
Putting device A back into range wouldn't restart the scanning in any way, so it's more likely that the scanner can't scan for advertising packets other than from device A when device A was first moved out of range, which is likely why you don't see advertising reports from device B in your log.

Correct.

Simonr said:
I think the central is indeed scanning (since it reconnects immediately to device A when it is moved back into range), so to me it sounds like it's just not picking up advertising packets from device B in this scenario for some reason.

Yes, I totally agree with you!

What can be the reason for that? And how can we mitigate that?

Overall, that is a major drawback to our products, so we would be very glad if we can come to the bottom of the problem.

BR, Žiga
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel