sd_ble_gatts_hvx() and extra data

[Charles Horkin]

Hello,

I'm using Win 8.1 BT LE stack to communicate with the NORDIC. I am using soft device s110. I use notifications to send data to windows which assembles a message based on it. I am seeing that every so often (and it is not every time), data gets sent over BT that is extra data.

For example, I am meaning to send a 60 bytes of data and instead, windows receives an extra 27 bytes (87) of data. This is not the exact situation, but is pretty close. Also, these 27 bytes seem to be random. The bytes also seem to come in the middle of the stream, so I get something like 40 good bytes, 27 garbage bytes, then the remaining 20 good bytes.

I'm 90% sure it's not my code because the code is just reading from the SPI bus and then sending the data. I've verified the SPI bus data with the logic analyzer is correct (60 bytes) and that the data Windows gets is the 87 bytes as described before.

Is this a know issue? Is there a workaround? Am I missing something?

Thanks.

[Stefan Birnir Sverrisson]

Hi Charles

Your situation sounds unfamiliar. You say that you have monitored the incoming SPI data. A more secure way would be to check the bytes sent on to the sd_ble_gatts_hvx function, which is the notification function that loads your data packets to the S110 softdevice, which are then sent over the BLE link. Try to check that, and report back your findings.

[Charles Horkin]

I looked at the data going into that function and it appears to be the same as on the SPI bus. I'm wondering if windows might be doing something strange with the data, but I can't prove one way or another that it's Windows and not the NORDIC chip.

I don't think the packet sniffer will work if I'm already connected to the BT with Windows BT driver, right?

[John]

I had a similar problem when moving 2K of binary data from UART0 to be transmitted to my iOS central device. It turned out my copy of data from the UART to my buffer for data to be transmitted was done in user level code called out of the main loop. However, my read of that buffer to send the data to the radio was being done in a low priority interrupt. I was able to protect my copy of UART data into the outgoing buffer with a critical section to prevent corruption and incorrect byte counts.

Without seeing your code, I have no idea if this is relevant to your problem. But I thought I'd mention it in case it might be helpful.