Black Lives Matter - Action and Equality. ... Adafruit is open and shipping.
0

BLE Advertisement strange, acute packet loss
Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.

BLE Advertisement strange, acute packet loss

by kevinjwalters on Mon Jun 15, 2020 2:01 pm

I've noticed a periods where I wasn't seeing BLE Advertisement packets sent from one device to another. I've been doing a lot of experimentation with 20ms interval sending for 15-20s periods between two and three devices.

I've just made a very simple example (clue-blue-adoddity.py) that does this for 30s periods triggered by left (verbose serial output) or right buttons. I did some runs earlier this afternoon with four devices; two CLUEs and two CPB (alphas) one with a TFT Gizmo attached. I had them in square configuration on my desk about 8in apart. I've noticed in the past the metal-heavy CPB + TFT Gizmo is a bit of a "blocker" when it sits in the line of sight.

Here's the results graphed out, I've turned all the mac addresses into K41 and K52 for CPBs, K51 and K52 for CLUEs and rXXX are any other random traffic in the neighbourhood. These little boards are fairly insensitive compared to a typical smartphone/tablet so don't pick up too much additional traffic. This is representative of what I've seen from a real application, a high degree of variable reception (packet loss somewhere). More importantly there's sometimes a whole 30 second period where nothing is heard from another device (note the stacked bars below that only have two colours, not three) but it must be transmitting because other devices do hear it.

clue-blue-adoddity-1-g1.png
BLE Advertisements including Scan Responses received during 30s runs of clue-blue-adoddity
clue-blue-adoddity-1-g1.png (63.89 KiB) Viewed 89 times


The maximum that would be expected is (1/(0.020+0.005) * 2) * 30 / 3 * 3 = 2400 plus any random packets. That's packets every 20ms interval with a 0-10ms uniform random addition, doubled for scan responses, for 30 seconds, divide by 3 for three channels where radio will only be receiving on one channel at a time, times 3 for three other devices.

Apple have 20ms as a recommend value for an initial burst of Advertisements and even at the default of adafruit_ble default of 100ms 20 devices in a room (i.e. a classroom) would be very similar to what I've been testing in volume terms.

kevinjwalters
 
Posts: 634
Joined: Sun Oct 01, 2017 3:15 pm

Re: BLE Advertisement strange, acute packet loss

by kevinjwalters on Tue Jun 16, 2020 4:22 pm

After raising this in yesterday's CircuitPyton meeting I was about to embark on an Arduino equivalent test but I thought it might be worth trying a CircuitPython workaround first so I can progress with my application.

I've now got another test program (clue-blue-ffsf.py) which can do the same as the previous one (pink background) or advertise in 1s periods with a random few milliseconds before resuming (pale green). Both run for 30 seconds advertising time, results below.

Some operator error messed up 19, 20, 21, hence lack of data.

Watching the chatter on a tablet (with WiFi disabled) I see the same surprising phenomena with the CP boards changing RSSI simultaneously suggesting something has synchronised their tx advertising channel hopping. This occurs every 5 seconds. Very x 3 odd.

clue-blue-ffsf-1-g1.png
BLE Advertisements including Scan Responses received during 30s runs of clue-blue-ffsf - pink background ones have a mild form of application induced jitter
clue-blue-ffsf-1-g1.png (95.19 KiB) Viewed 79 times

kevinjwalters
 
Posts: 634
Joined: Sun Oct 01, 2017 3:15 pm

Re: BLE Advertisement strange, acute packet loss

by kevinjwalters on Wed Jun 17, 2020 9:41 am

The other puzzle is the RSSI stepping (assumption is this is channel hops between 37, 38, 39) which appears synchronised. I made a video of a nearby tablet (wifi disabled) listening to the four devices. This is after they have just been powered up and have not sent or received anything over Bluetooth. They synchronise their stepping with a few seconds.

first-run-advertising-rssi.png
RSSI for 4 nRF52840 Adafruit boards sending Advertisement packets fo 30 seconds for the first time since randomly staggered power up
first-run-advertising-rssi.png (114.91 KiB) Viewed 71 times


The lower yellow and blue lines are just other random BLE in the vicinity.

kevinjwalters
 
Posts: 634
Joined: Sun Oct 01, 2017 3:15 pm

Re: BLE Advertisement strange, acute packet loss

by kevinjwalters on Wed Jun 17, 2020 3:54 pm

I tried two devices as if this was just a collision type phenomena then the effect would be reduced with less devices. It's still easy to get 30s where both devices cannot hear each other. One interesting thing about this simpler case is the received values are remarkably similar on both devices.

clue-blue-ffsf-5-g1.png
BLE Advertisements including Scan Responses received during 30s runs of clue-blue-ffsf, background BLE traffic filtered out - pink background ones have a mild form of application induced jitter
clue-blue-ffsf-5-g1.png (68.83 KiB) Viewed 64 times


clue-blue-ffsf-5-g2.png
BLE Advertisements including Scan Responses received during 30s runs of clue-blue-ffsf - pink background ones have a mild form of application induced jitter
clue-blue-ffsf-5-g2.png (38.15 KiB) Viewed 64 times

kevinjwalters
 
Posts: 634
Joined: Sun Oct 01, 2017 3:15 pm

Re: BLE Advertisement strange, acute packet loss

by kevinjwalters on Thu Jun 18, 2020 6:13 pm

I've played around with one other technique in clue-blue-stoc.py to get the variance down with an alternative workaround (pale green background). This does tx/rx for 900ms in a loop but also half the time throws in an extra 50-150ms period of rx only.

This is for 10 seconds with no scan requests, not 30s with. Green is workaround, pink is a simple, straight 10s of start_scan() + start_advertising(). The expected maximum is (1/(0.020+0.005)) * 10 / 3 * 3 = 400 but this will be reduced because of the workaround and also the variation in start times for each device.

clue-blue-stoc-1-g1.png
BLE Advertisements (no scan resquests) received during 10s runs of clue-blue-stoc - green background have very short random period where advertising is paused
clue-blue-stoc-1-g1.png (59.64 KiB) Viewed 58 times

kevinjwalters
 
Posts: 634
Joined: Sun Oct 01, 2017 3:15 pm

Please be positive and constructive with your questions and comments.