Motion Only Broadcasting

I’ve configured our new proximity beacons (G1.8) to only broadcast packets when the beacon is in motion. The old beacons did this just fine, but the new ones broadcast a specific packet (which I cannot decipher) every 100ms regardless of whether the beacon is in motion or not.
However, the packet type that I configure through the Estimote app is only broadcasted when the beacon is in motion.

In short:
Beacon not in motion: Unknown packet type every 100ms
Beacon in motion: Unknown packet type + Eddystone UID.

I am under the assumption that the beacon takes less battery power when it’s not broadcasting anything and this is exactly what we want to accomplish with the Motion Only Broadcasting feature.

Hmm, in our 4th generation firmware (AKA 4.x), there’s a dedicated connectable packet used to connect to and configure the beacon. This packet is always broadcast, despite any Conditional Broadcasting going on (like Motion Only, Flip to Sleep, Dark to Sleep, etc.) It’s to make sure that no matter what, you can always connect to & configure your beacon—e.g., if you use Dark to Sleep and the beacon stops broadcasting non-connectable packets after dark, maintenance crew can still perform any updates, etc. Or a simple example, you accidentally set Scheduled Advertising to turn beacon off between, say, 3 am and 11 pm. B/c we still broadcast the connectable packet, you can connect to beacon and change that even outside that window, and not wait for the night (:

But, the connectable packet is broadcast every 1285 ms, so not sure what you could be seeing that’s broadcast every 100 ms.

Broadcasting a packet every 1285 ms uses very little energy, so there’s no need to worry about the impact on the battery life. If you want, you can always change the interval of the connectable packet with our SDKs, just keep in mind it might affect connection times.

Looking at the Wireshark logs, I can see that the connectable packet is broadcasted every 100 ms after powerup (placing battery). It keeps doing that for about 10 seconds and then it goes to broadcasting every 1285 ms.
This means that it takes the beacon 10 (!!) seconds to enter “normal” mode after powerup.
I’ve done firmware development for TV’s and other electronics and know that 10 seconds bootup is really an eternity…

Now for the real problem:
I have now configured the Eddystone UID packet to be broadcasted every 300ms and the Eddystone TLM packets every 2000ms. After powerup, the timing is correct (UID 300ms and TLM 2000ms). Then the beacon stops broadcasting because it’s not in motion anymore. After picking it up, it starts broadcasting again, but both packets at 2000ms and not 300ms - 2000ms! I kept shaking the beacon for 2 minutes, but it stays 2000ms for both UID and TLM.

The 10-second burst after bootup (note that bootup is almost immediate, it’s just the behavior shortly following the boot is slightly different) is a by-product of our QA process, and given that you don’t really reboot beacons often in production, it doesn’t affect things much.

The 2000 ms adv interval is result of our Smart Power Mode. If there are no devices around doing Bluetooth scanning (and sending SCAN_REQ packets as a result), the beacon goes to low-power mode where it reduces the advertising frequency to save battery. I assume Wireshark only passively observes the environment and doesn’t really send SCAN_REQs, hence the 2000 ms adv interval. If you do a regular scan with a smartphone or something like that, it should get the beacon out of the low power mode.

Alternatively, you can disable Smart Power Mode (: