On nRF Master Control Panel and weird behaviors of nRF51822

[leo_91]

Best Regards,

while messing around with nRF51822 S130, timeslot API and nRF Master Control Panel, we noticed that:

Issue: if a packet is formatted correctly, but the declared Manufacturer Data size is larger than the manufacturer data inside the packet, the radio overflows and sends bytes stored in (probably) the successive parts of memory.

Question: Does the timeslot radio parse the packet while sending it?

Details : let uint8_t our_pkt[N] be our packet data, formatted following BLE standard. It ends with 0x04 (manuf_data_size), 0xFF (manuf_data_code), 0xB0, 0xFA. The last byte, 0x05, is, curiously the the first byte of a vector allocated right after our_pkt. We noticed that if we increase manuf_data_size, we can eventually send the whole packet as manufacturer data.

Thanks,

Leo.

Trivia: we saw what we reported inside nRF Master Control Panel. Once, but only once, the packet format was totally changed due to this issue, and we eventually read more than 40 bytes as additional manufacturer data. We at first thought that nRF Master Control Panel went in overflow, but at the light of this fact, we will try to further investigate.

[run_ar]

There area few things that confuses me. Length seems to be 22 bytes (0x16), while you only got 13 (14 if you add the extra manufacturer specific data byte). You are also missing the flags ad type. and I assume you have changed the address type sine you have 0x42 and not 0x40. Note that we have a timeslot advertiser example in nRF5_SDK_11.0.0-2.alpha_bc3f6a0\examples\ble_peripheral\experimental_ble_app_multiactivity_beacon\hrs_advertiser

[leo_91]

Thanks run_ar,

I naively mistook the 0x16 to be part of the non-connectable advertising specification. Apart from that, we send a non connectable advertising because we don't do scan response, therefore setting to 0x40 would have hidden the packet from nRF control panel.

I will check whether the overflow of data from the device fixes just with this or not, else I will research some more, double checking the specifications next time. Thanks!