Badge sometimes sends way too much scan data (fw2.0, maybe master?)

[abartow]

There appears to be an issue where the badge will send way more scan chunks than it needs to.

For instance, in this log:

(Start of test, first chunk to be sent is stored to RAM chunk 0, then to EXT chunk 475) 

SCANNER: Saving scan results. 1 devices seen
  C:0
    bdg ID#0400, rssi -68, count 13
SCANNER: Done saving results.  used 1 chunks.
STORER: writing SCAN chunk 0 to EXT chunk 475

(... some time passes...)

SCANNER: Saving scan results. 1 devices seen
  C:3 <- Most recent scan goes to RAM Chunk 3
    bdg ID#0400, rssi -73, count 16
SCANNER: Done saving results.  used 1 chunks.
STORER: writing SCAN chunk 3 to EXT chunk 478 <- So the most recent chunk is here, 478.
  Read battery: 2842mV (raw: 2844mV).
  Read battery: 2842mV (raw: 2844mV).
� Read battery: 2843mV (raw: 2844mV).
  Read battery: 2843mV (raw: 2844mV).
�Read battery: 2843mV (raw: 2844mV).
  Read battery: 2841mV (raw: 2837mV).
SCANNER: Started scan.
SENDER: Got REQSCANS request.
SENDER: sending scans since: s:P c:475 <- Correct first chunk to send.
SENDER: sent s:P c:475 n:1
SENDER: sent s:P c:476 n:1
SENDER: sent s:P c:477 n:1
SENDER: sent s:P c:478 n:1 <- Should stop sending after this one.
SENDER: sent s:P c:479 n:1 <- It continues sending.
SENDER: sent s:P c:480 n:1
SENDER: sent s:P c:481 n:1
SENDER: sent s:Q c:0 n:1
SENDER: sent s:Q c:1 n:1
SENDER: sent s:Q c:2 n:1
SENDER: sent s:Q c:3 n:1
SENDER: sent s:Q c:4 n:1
SENDER: sent s:Q c:5 n:1
SENDER: sent s:Q c:6 n:1
SENDER: sent null header.  REQSCANS complete.

We get a bunch of duplicate scan chunks (scan chunks from RAM that have already been stored in EXT) as well as some scan chunks past what have been stored.

Still running down the cause of this bug. I'm not sure if it effects both master and fw2.0 or just fw2.0.

[abartow]

This is fixed by 28bee2236b5e.

[abartow]

@OrenLederman