experimental_ble_app_multiactivity_beacon\hrs_scanner Issues

[Mark J]

I realize that this code is "experimental", but we are trying to utilize it as a reference and having problems with its stability and scan results.

Specifically, we are just compiling and running the project at: \examples\ble_peripheral\experimental_ble_app_multiactivity_beacon\hrs_scanner

We are building and running on an nRF51 DK with S130 2.0.

We are using nRF5 SDK (ver 11).

We are logging the MAC address retrieved from within decode_advertising() (within scanner_beacon_timeslot.c)

for (i = 0; i < 6; i++) { sprintf(tmpString, " %02X ", adv_packet->addr.addr[i]); SEGGER_RTT_WriteString(0, tmpString);

} SEGGER_RTT_WriteString(0, "\r\n");

return NRF_SUCCESS;

We have inserted our Segger logging at the end of decode_advertising()

This is showing us MAC addresses with errors. See this portion of our log.

0> BB 9C 91 CF E5 E0 0> F9 09 B3 5E B8 F4

0> 5D 86 91 CF FE EC <------

0> 5D 86 91 CF E5 E0 <------

0> BB 9C 91 00 00 00 00 00 00

0> 10 96 10 7E FE EC

0> 10 96 10 7E FE EC

0> DF D1 69 4F 8D C7

0> 90 95 10 7E FE EC

0> 5D 86 91 CF E5 E0

0> BB 9C 00 00 00 00 00 00

0> F9 09 B3 5E B8 F4

0> F9 09 B3 5E B8 F4

When we can scan these devices with other peers, we can see that one of the returned addresses is correct and the other is not. It appears that the MAC address data is being corrupted.

The other issue is that the device continually restarts (shown by 00 bytes in the log).

This problem should be easily reproducible as it is just a compile of the example project with a few SEGGER_RTT_WriteString() calls added (see above).

[Mark J]

We were able to fix the stability issue discussed by moving "ble_scan_beacon_evt_t evt;" out from m_timeslot_callback() and making it a static global.

Still working on the other issue relating to incorrect address returns.

[Mark J]

We were able to dramatically reduce the number of erroneous scan records when qualifying results and throwing away records with a bad CRCSTATUS flag. Scan records with CRC errors were coming through. We are getting far fewer scan records for unidentified peers and we are beginning to wonder if these records are legit as they are completely unique. Bad records previously encountered had MAC addresses that were very close to our test devices (a few bits or bytes that differed from the MAC address of one of our test beacons). Scan records now show MAC addresses that are completely different from the MAC addresses of our test beacons. They may simply be advertisers that are beyond our control (i.e. someone with a Fitbit walking by our lab). So, our issue relating to getting bad scan results may be solved.

Testing results did uncover another possible issue. RSSI values within these records vary much more than expected. We found another Nordic reference that exercises more control over the radio when scanning: github.com/.../observer Testing of this reference shows more stable RSSI values. We are incorporating code changes from this new reference in an attempt to improve RSSI stability.