nRF52 throughput demo blog post

Question

Hi Nordic team, 
 Very impressive demo posted on the blog zone this week! I'm trying to understand the details and sorry if I ask something what would be visible in the source code or project comments, but could you help me with few details (maybe worth amending the blog post)? Here they are: 
 
 I'm assuming that throughput mentioned in the end (1.365kbps for BT5.0 with 2Mbps data rate, 775kbps for BT4.2 at 1Mbps data rate etc.) are measured on APP layer running on top of GATT/ATT. Is that true? 
 Could you elaborate about ability to handover/store/process such stream of data on receiving side? Could you for instance enhance the demo to really process the stream and in the end send something in opposite direction so the stability would be proven with such high "streaming" throughput? 
 What about Security Manager and encrypted link. Would that influence these values or is AES HW block on nRF52 able to process this load on the fly? 
 Is demo using any channel map (restriction)? Have you tested influence of noise (e.g. BLE traffic caused by other devices in the background) and how "real" is such high throughput in the field? 
 
 Many thanks
Jan

ovrebekk · Accepted Answer

Hi Jan 
 I am glad you liked the demo/blog :) 
 
 
 That is correct. This is the app throughput that the user/app would see, not including ATT and L2CAP headers.
If you see higher numbers quoted anywhere it is very likely that the ATT and/or L2CAP headers are included in the calculations. 
 
 
 The obvious counter-question here is what kind of processing you are talking about ;)
Passing data on to serial interfaces is easy from a CPU standpoint, since all of them support DMA in the nRF52 series, but the serial interface in question would obviously need to support the same data rate. At the moment only SPI and I2S (+ QSPI and USB in the nRF52840) support data rates above 1Mbps.
Storing to internal flash would not be able to keep up, since writing to flash memory is a slow process and requires the CPU to halt in the mean time. Storing to an external flash over SPI/QSPI should work fine as long as the external chip can keep up.
Any kind of processing involving relatively simple arithmetic's, or instructions supported by the M4 DSP, should work fine, but at some point you will run out of CPU capacity.
As an example I had an idea of streaming JPG images to the nRF52 and decoding them on the fly, but have yet to find a JPEG decoder that can run quickly enough in the nRF52 to keep up with the data flow ;) 
I would say the main use case for these kind of data rates are things like file transfer, where you want to send bursts of data as quickly as possible (nice when doing firmware updates), or streaming applications, where data is passed on to a different system for processing over SPI, I2S or USB. 
 
 
 The encryption hardware in the nRF52 series is designed with BLE in mind, and allows you to enable encryption with very little impact on the CPU. Essentially the radio buffers incoming data in RAM (over DMA), and sends a signal to the AES CCM module. Then the AES CCM reads it out (again using DMA), decrypts it, and stores the result in RAM. Up until this point the CPU doesn't have to lift a finger, and could be processing old packets in the background.
I am not sure if we have done some benchmarking to measure the effect of encryption on CPU time, but as mentioned it should not have a big impact. 
 
 
 The demo uses standard channel map settings, and I don't think there is any active mapping of bad channels happening (AFAIK this is up to the application when using a Nordic device on the master side).
In my own experience you will see results around 1100-1360kbs in normal office testing scenarios (short range, moderate to high WiFi interference), but we haven't had the time to do more extensive testing of this.
Now you have the code, so you can test yourself rather than relying on our numbers ;) 
 
 
 Best regards 
Torbjørn

nRF52 throughput demo blog post

Top Replies