When using BLE.scan(Vector) on a Tracker One or Monitor One, what is the maximum number of BLE tag advertisements that can be read/returned in a single call, assuming you had a large enough timeout to see them all?
The documentation suggests the only limit is the available memory on the device. The Beacon Scanner Library currently assumes you will never have more than 255, however, this seems arbitrary.
We are considering one use case where we would deploy these gateways in the vicinity of 500+ BLE tags in an isolated area, and another where there could be a couple thousand BLE tags in a warehouse.
Are these numbers in the realm of possibility with the latest versions of the edge firmware?
If not, would it make a significant difference if we coded a bare-bones version that had a very simple wake, GPS fix, BLE scan, publish, sleep cycle?
Is there a reason you need to accumulate them that way? You can do a shorter scan with a smaller receive vector, save the results to a secondary buffer, then start scanning again.
I'm not convinced the limiting factor will be the buffer size. Since beacon transmits are not synchronized, there's a very high likelihood that that many beacons will transmit at the same time and either obscure a farther beacon, or the radio will receive a combination and discard both advertisements as corrupted.
I don't see why I can't do that. We would have to reimplement the duplicate filtering logic, but that's not complicated.
I was also under the impression that any discarded advertisements due to corruption would, with a long enough scan timeout, eventually make it through due to the random 10ms delay between advertising intervals to prevent this. Are you saying that we need to validate the scan results and discard any existing corrupted ones ourselves?
The question remains with this approach though. Whether the buffer is managed by our own firmware or it's built-in to Device-OS, at some point that buffer will run out of memory and we will need to do a publish, discard new data, or overwrite unpublished data. Can you give me an idea how many scan results could reasonably be expected to fit into a secondary buffer before that happens?
The BLE stack will filter out any corrupted packets; you don't need to do that.
It depends how much stuff you're keeping for each beacon. If you're only keeping 50 bytes of data for each x 1024 beacons would be 50K of data, which would fit in RAM. Just de-dupe before you add to the list, because otherwise it would grow very fast.
If you miss a device's advertisement because of congestion in the airspace, you'll eventually pick it up on a later advertisement. You'll probably also need some logic to discard the ones you haven't seen in a long time.
Thanks. 50 bytes per beacon seems reasonable. It would be much less for storing the raw values in binary format, but when converting to JSON/UTF-8 for a publish call it's in the ballpark.
With publishes limited to 1K, we'll probably consider sending the data directly to our backend so we could send everything in a single request, but it seems the hardware would probably be capable of seeing the number of devices we want it to.
Is there anywhere online you can point me to where I can find max/usable RAM for different devices/firmwares?