Proximity scan doesn't handle more than 5 devices well

[OrenLederman]

When 6 or more badges appear in the scan, badge sends incorrect packages to the hub, casing an error. It seems that the first package (20 bytes) is correct - 4 bytes for each of the first 5 devices. The next package is 5 bytes long, where the first 4 appears to contain a valid scan data, and the 5th byte is an error.

Looking at the badge debug logs, it seems that the problem is in storing: SCANNER: Saving scan results. 6 devices seen C:8 bdg ID#0000, rssi -98, count 34 bdg ID#DFE4, rssi -63, count 7 bdg ID#5F7D, rssi -65, count 6 bdg ID#2EB6, rssi -76, count 5 bdg ID#2660, rssi -88, count 3 bdg ID#A7F9, rssi -72, count 6 SCANNER: Done saving results. used 1ADV: advertising paused, src 0. STORER: writing SCAN chunk 8 to EXT chunk 616

The storer should have allocated the 6th device to a second chunk. Instead, it appears to add it to the first chunk. The log shows that only one chunk is being stored.

It seems to be a memory leak of some kind. If you compare the log to a 5 badges log, you can see that the SCANNER:Done line gets cut off:

SCANNER: Saving scan results. 5 devices seen C:7 bdg ID#0000, rssi -96, count 35 bdg ID#5F7D, rssi -66, count 6 bdg ID#2660, rssi -96, count 2 bdg ID#DFE4, rssi -62, count 7 bdg ID#2EB6, rssi -71, count 5 SCANNER: Done saving results. used 1 chunks. ADV: advertising paused, src 0. STORER: writing SCAN chunk 7 to EXT chunk 625

[OrenLederman]

Correction - each chunk can hold 29 devices. But there's still something funny going on there.

[OrenLederman]

The printouts don't seem to indicate a problem - they seem to just get messy if we write too many logs, or if the bluetooth stack kicks in in the wrong time. Closer inspection shows that the problem seems to be in the sending code (and not the storing code). When printing the size of the buffer the badge sends, we see that the size of the first data buffer sent (after the 9 bytes header) is 5, instead of 20:

SENDER: sending scans since: s:P c:887 SENDER: sending buffer size: 9 SENDER: sending buffer size: 5 SENDER: sending buffer size: 5 SENDER: sending buffer size: 20 SENDER: sending buffer size: 20

[OrenLederman]

Wrong calculation for buffer size when the number of stored scan results was more than 5. Fixed in merge #59