Android Question Packet loss with BLE

[SteveTerrell]

This is really for information and to invite comments.

I have a B4A app which uses BLE 2 to communicate with a piece of test equipment. The test equipment uses the AdaFruit LE Uart friend. The tablet is the master and sends commands and data read requests to the test equipment. A transaction occurs about every 500ms. Commands are acknowledged and data read requests result in messages ranging from a few characters to 22. All replies are terminated with c/r.

The BLE 2 Manager_DataAvailable routine generally gets called two or three times before the longer reply messages are fully assembled/received. This is possibly due to the test equipment not sending characters as fast as it could or perhaps because it uses 9600 baud between the LE friend and the control uP. This is not really an issue. I assume each call back corresponds to a received BLE packet.

What i am finding is that when the equipment is used in WiFi dense area there seems to be an occasional loss of packets (perhaps every 10-20 minutes) from the equipment to the tablet. The Android literature suggests this is a relatively common problem. The "lost" packets could be in the middle of a reply message or at the end (including the terminating c/r). In a WiFi quiet area there us usually no loss of packets.

The evidence is that the serial data to the LE Uart can be seen to include all characters but the DataAvailable routine does not get called enough times or with enough characters to assemble the complete message. Looking at the call back timing it is possible to see the gap where a call back with a packet should have occurred. The next call back that does happen has more of the message but after a gap.

I am beginning to think about protecting the messages with a checksum to spot missing segments in the middle and a timeout to spot the loss of the c/r packet. This will have to be supported with a "please send again" command.

Comments and thoughts of others invited.

 

[JordiCP]

My two cents:

Regarding Wifi, as you can never know when this (or any other interference) may occur, communications should have some kind of integrity check when possible, specially when in UART mode.

Also, for UART mode BLE, I have seen reccomendations to use hardware flow control. I don't know if the Adafruit BLE board allows this, but have seen it in RN4020 MLDP mode.

I have made a couple of master/slave BLE-enabled projects, and at the end I decided to forget uart-mode and write directly to the private services/characteristics on the microcontroller side. This is only possible if you can have access to the source code on that part and your BLE module allows it. It adds a small overhead, but that allows to have control on how your raw data is "packetized".

 

[SteveTerrell]

My two cents:

Regarding Wifi, as you can never know when this (or any other interference) may occur, communications should have some kind of integrity check when possible, specially when in UART mode.

Also, for UART mode BLE, I have seen reccomendations to use hardware flow control. I don't know if the Adafruit BLE board allows this, but have seen it in RN4020 MLDP mode.

I have made a couple of master/slave BLE-enabled projects, and at the end I decided to forget uart-mode and write directly to the private services/characteristics on the microcontroller side. This is only possible if you can have access to the source code on that part and your BLE module allows it. It adds a small overhead, but that allows to have control on how your raw data is "packetized".

Thanks for your input. The Adafruit module does have RTS so can hold up transmission if it needs to. Adafruit suggest this is not necessary at 9600 baud so we have monitored that and it never goes active even during packet loss.

Interestingly enough we have never had any suggestion that the equipment end has not received packets, although the comms in that direction are relatively short and only a few characters long (i.e. Rc/r to read data, M2c/r to set the multiplexer value etc.).

The reply to Rc/r is much longer; V12345,23456,34567c/r. Generally the first packet (4 or 5 characters) are received then perhaps the middle 4 or 5 are lost but the last group arrives.

The time between packets is typically around 30ms. When say the middle one is missing the time between first and last is 60ms.

It is possible that my use of the term packets is not correct. What i should be saying is that part of the sent message does not arrive at the DataAvailable routine.

 

[Arf]

I was having trouble with a RN4677 module, what was happening was the module is supposed to go into comand mode after receiving 3x '$' (or whatever the command mode escape charcter was, can't quite remember), however in receiving the first '$', it would wait for a second one, and when the second character was not a '$', it would discard whatever chunk of packet it had received the original '$' in.

This essentially made the module unusable. This was in BTC mode but I bet the same problem was in BLE mode. After much discussion with Microchip, they provided a firmware upgrade and everything works now.

So what I'm saying is, check if there is a firmware update for that module, especially if it is a microchip part. Pretty inexcusable to market a module with such a glaring error in what could be a really simple, robust algorithm for detecting command mode excapes!

 

[SteveTerrell]

I was having trouble with a RN4677 module, what was happening was the module is supposed to go into comand mode after receiving 3x '$' (or whatever the command mode escape charcter was, can't quite remember), however in receiving the first '$', it would wait for a second one, and when the second character was not a '$', it would discard whatever chunk of packet it had received the original '$' in.

This essentially made the module unusable. This was in BTC mode but I bet the same problem was in BLE mode. After much discussion with Microchip, they provided a firmware upgrade and everything works now.

So what I'm saying is, check if there is a firmware update for that module, especially if it is a microchip part. Pretty inexcusable to market a module with such a glaring error in what could be a really simple, robust algorithm for detecting command mode excapes!

I must say that it seems like sometimes the manufacturers have never tried using their own chips!

 

[SteveTerrell]

Update. Using a Samsung Tab A7.

We have now implemented a simple checksum feature together with a re-transmit command.

In about 1 day of running we are getting up to 10 re-transmit requests. This is often due to a checksum fault (some of the start or middle characters missing from the message) and sometimes it is due to a missing c/r terminating character timeout.

The missing c/r timeout is set to occur about 1.2 seconds after the first character of a reply is received. We have occasionally seen the c/r arrive after 1.2 second.

Generally the reply message will arrive in three blocks of characters about 30ms apart. Where there is a missing mid-message block the gap between the start and last block is typically 60ms.

BLE documents suggest that the Bluetooth level should keep trying to get each internal packet through by re sending and handshakes. The long timeout for the last block does suggest this is happening but at some point it appears that either Adafruit or Samsung (Android) give up.

Our checksum and resend appears to give us a reliable system for now!

 

[techknight]

Samsung Tab A series, that's your problem.

The bluetooth in those devices are downright horrible. Last Samsung Tablet that had awesome bluetooth stability was the Tab 4.

They integrated the bluetooth and wifi in the same IC, so every time the wifi fires off with its beacon check, or etc.. it interrupts the bluetooth traffic.

Using the Tab A series in SPP mode on a 2.1 device is awful. the throughput isnt as good as it use to be, and connection stability is about as good as a yacht on hurricane waters.