On Timeslot API, SoftDevice, and locked bytes

[leo_91]

Best Regards,

I am developing a firmware version for nrf51822 based on Softdevice S130 (old v8.1) and Timeslot API. Currently, I can freely transmit and receive packets while the softdevice is active, running, and actively utilizing the radio interface.

Issue: while sending packets via the Timeslot API, the 25th byte of the packet is never correctly set, it doesn't have a fixed value, and floats within a range of values (e.g. from 0xBB to 0xCC).

Question: Is the 25th byte of a timeslot packet maybe the CRC field?

Details:

The issue happens only when we send a packet via the timeslot API. The packet is configured on the fly on a vector of size (e.g.) 25, and is formatted following BLE standard, so that nRF Master Control Panel and a custom android application can receive and parse the packet successfully. Flags or scan response are not implemented yet, because they are not needed for now. The timeslotted radio is configured to send over advertising channels, with default advertising parameters (default CRCINIT, ADV_ADDRESS, WHITEEN enabled, so that we are practically sending custom advertising packets).

Guesses

• I ended up in that part of memory where the CRC field is computed/stored, or other fields used by the radio.
• I'm trying to send more bytes than what I actually am allowed to (even though if I recall correctly, the maximum amount of data that can be stuffed inside a packet is 31 bytes (8-byte header included).

Correct me if I'm mistaken somewhere, and if any of you could help me solve the issue, I would be thankful. Further notes below.

Thanks,

Leo.

Notes:

1. On further investigation, the issue does not depend on the length of the packet; we can send more bytes, but from the 25th onward never show correctly when received.
2. The data is written inside the Manufacturer Data field (type code 0xFF), and shows correctly up to the 24th byte.
3. Could not be related, but while trying to solve this we found another strange thing.

Edit:

Adding screenshots of nRF Master Control Panel (forgot to add it since the beginning).

[run_ar]

So, as you say; the maximum size of the advertisement data packet is 31 bytes. If you try to send longer ad packets than this I would not expect the scanner to understand it.