Hello lovely Nordic Semiconductor staff (and everyone else reading this),
I have recently been working on exploring the use of BLE via Nordic chips in my employer's products. We're hoping to be able to switch to using BLE with the UART service Nordic provides to transmit data from the company's devices to a smartphone app we have developed, but we expect that there will usually be tens of kB of data to transmit each time, and because we want the process to be quick and easy for the user, we need to have a reasonably high throughput. I have been able to consistently achieve rates of about 8-10 kB per second, which should be enough for our purposes. The problem is that when I have tested this by transmitting some sample files I created, the files are regularly becoming corrupted on the way (approximately 50-70% of the time I think). This is a problem because we need all the data to be totally correct. The apparent corruption seems to be somewhat unpredictable however (but see further below).
For the exploratory testing, I have been using an nRFR52 DK, running a slightly customised version of the ble_uart_app sample program provided in the SDK, incorporating modifications put forward by Petter Myhre in this thread to send the data, to stand in for one of the company's devices. Data is pumped into the DK using a Python script, originally based on one Adafruit made for their Bluefruit LE Friend - though the script I am using now is very heavily modified from that one. I have tested the Python script's reliability using a serial cable to connect two computers, and that appears to be totally rock-solid, so I don't think the problem is there.
For the receiving side of things I have adapted the UART part of the nRF Toolbox iOS and Android apps. Basically, the apps receive data, then store it in a file. That file is compared to a reference file stored on the phone, and I can check whether for each transmission the file was corrupted or not. I have repeated these tests numerous times, sending anywhere from 5 files, to 1000 of each of five different sized text files, using an iPhone 7, a Samsung Galaxy S4, and an ASUS Nexus 7 tablet. In every instance, a very significant number of the total received files (pretty much always 50%+) have come up as corrupted, regardless of file size.
I have used command line commands like cmp and FC (for Windows command prompt) to compare the files, and I have noticed that in every single file comparison I have made, it appears that the corrupted file only has a few bytes corrupted. Usually 1 or 2, and I haven't seen more than 5 at once. The other weird thing is that it is always within the first 100 bytes of the file, regardless of whether the file is 200 or so bytes, or about 70 kB, or anything in between. I looked at the size of the packets coming in to the phones from the DK, and I noticed that seemingly every time I send a file, the first 100 or so packets are always 1 byte each (never less than 100 for some reason), but later packets are usually the full mtu size that the phone and DK have agreed upon. I am honestly not sure why that should be happening, but I do wonder if that is connected to the errors I'm seeing.
In an effort to try to isolate where the problems appear to be occurring, I used the data logging capability of the J-Link RTT Viewer to check the data that is being provided to the softdevice in the app running on the DK. Immediately after each packet of data has been successfully passed to the softdevice (i.e. immediately after the function ble_nus_string_send() has returned with error code NRF_SUCCESS), the data_array is written out to the data logging channel with a SEGGER_RTT_Write() call. This technique has been a little finicky, but I have managed to get a repeated number of files of different sizes back out of the DK using it, and in every instance the file is uncorrupted as compared to the reference file that was being fed into the DK via the Python script. This leads me to think that the problem is occurring somewhere between the data being loaded into the softdevice buffer, and it's eventual receipt by the smartphone/tablet on the other end.
I'm honestly not sure what the problem could be. I have tried playing around with different parameters, such as setting the connection interval really high or really low, e.g. 7.5ms to 500+ms, and that doesn't seem to have made any difference. I have also used the default mtu size, as well as upping the mtu size to the maximum each phone will accept. I have used Data Length Extension on the iPhone (the Android devices I have to test on are a little old and don't seem to be advanced enough to do DLE). I increased the size of the Rx and Tx buffers for the application. Again, none of that seems to have made any difference. I did stumble across this other DevZone question today, which I thought might be having the same issue as me, but I'm not sure.
I'm reasonably confident it isn't the receiving devices (or at least, not totally them), because I was able to transmit files fine when using the Adafruit Bluefruit LE Friend - that was just much too slow for my purposes. The files are sometimes received fine with the nRF52 DK, just not nearly often enough for it to be considered reliable enough for us to progress to trying to put nRF BLE chips into some versions of our devices. At this point I am stumped about the problem, and I can't think of what else I can try to avoid it. Could you please advise? Thanks for your time and efforts.
