5.1: "pseudo-random value in the range from 0 to X ms is added to the fixed advInterval"

[iBrake]

Hi,

I recently moved my sensors up from one of the 4.X version (I didn't note which) to 5.3 (above 5.3 seemed to give a blank screen).
I have a log of maximum minimum and average time between packets. As the BlueTooth advertising space is extremely busy in my area, and my solution can only handle so many packets at a time, I miss quite a lot of packets. However the maximum time between packets is generally less than 5 minutes.

On switching to 5.1, I notice that the maximum time between packets has shot up to over 10 minutes! I've been trying to figure out what could cause this and the only thing I can see is this change for 5.1

I would assume this just does a packet repeat every so often, after a few milliseconds, in order to ensure the sensors stay completely out of sync? That would explain why the minimum time between packets has now dropped to 0, from 10 seconds. However it doesn't explain why the maximum time has increased massively. Is there more to this setting than I'm getting from the read me, or must I have something else going on?

Thanks.

[pvvx]

Adding a pseudo-random value to the beacon interval is standard for BLE.
In the new version, the maximum value of this supplement is enabled for user customization.
Without this random interval addition, the interval could coincide, for example, with the fixed WiFi beacon interval (102.4 ms), which would result in constant jamming of all beacons.

[pvvx]

As the BlueTooth advertising space is extremely busy in my area,

This scenario doesn't happen.
Over 200 BLE devices worked in my room without any issues.
Theoretically, 1,500 BLE devices could work with a 5-second transmission interval. The loss on the receiving end would be no more than 30%.
Only Wi-Fi affects BLE and ZigBee signal loss, as it operates at high power and creates interference on all 2.4 GHz channels.

However the maximum time between packets is generally less than 5 minutes.

It looks like you're using an ESPHome with an ESP32 chip. That's how it typically works—losses of about 90% in a clean environment with a single BLE sensor.

[iBrake]

It's a node red module and even with my own external software customization to filter packets by MAC as soon as they arrive, I still can't can't handle (this is a guess) 30 advertisements a second.

So even if the USB RTL8761B can handle advertisements much faster, the NOBLE->JavaScript->Node red, chain can't.

I should have probably moved away from node-red by now, but I'm running it for nearly a decade, so I've lots of things I don't want to rebuild.
The system is a Ryzen 3700X, so it's a bit more powerful than the ESP32 :)