I work with Shimmer3 devices under Linux and interface directly with them via the serial Bluetooth interface. I noticed that there appears to be some kind of race condition that occurs when the Bluetooth interface sends responses to Bluetooth commands while streaming data.

For me, this issue specifically occurs when I stream data from the device to the host and try to stop this stream with the STOP_STREAMING_COMMAND. The command is successfully received by the Shimmer but the acknowledgment 0xFF is sometimes lost and not transmitted to the host, which throws of my state machine on the host side. I believe that the reason for this is the initial conditional check in the BT_write routine (LogAndStream/shimmer3_common_source/Bluetooth_SD/RN42.c:750) which returns immediately if another transmission is still in progress.

I was able to successfully recreate the bug using the following steps. I used Wireshark to dissect the Bluetooth data stream between Shimmer and Host.

• Set the baud_rate config parameter for communication between main CPU and Bluetooth to the lowest possible value (1)
• Configure the Shimmer to stream data. Here it was sufficient to send a single 16bit channel, i.e. a total of 6 bytes for the DataPacket
• Send the START_STREAMING_COMMAND, wait for several seconds and then send the STOP_STREAMING_COMMAND
• The acknowledgment byte 0xFF will likely not appear in the stream response