nrf9160 throughput

[Ben Li]

 I'm trying to build a proof of concept for a BLE gateway that captures data from BLE sensors and sends it to the cloud via LTE-M connection. I'm hoping that the gateway can support 20 concurrent BLE connections for the proof of concept. However, I'm concerned on nRF91's data rate. I am afraid it leave the throughput on the cellular side lacking compared to what it receives from the BLE peripheral. Is there anyway to get around this? Or should I use a third party GSM like sim7600?

My idea is to connect two NRF9160 together to handle the throughput. Or I can connect nrf52840 with a LTE CAT4 module like Maduino Zero 4G LTE. Both options need to be battery backed and runs without connecting to PC eventually.

Would that work?

Best,

Ben Li

[Albrecht Markus Schellenberger]

Hello Ben Li, 

My idea is to connect two NRF9160 together to handle the throughput. Or I can connect nrf52840 with a LTE CAT4 module like Maduino Zero 4G LTE. Both options need to be battery backed and runs without connecting to PC eventually.

Would that work?

I’m honestly not quite sure what your approach is here. Can you elaborate? 

However, I'm concerned on nRF91's data rate. I am afraid it leave the throughput on the cellular side lacking compared to what it receives from the BLE peripheral. Is there anyway to get around this? Or should I use a third party GSM like sim7600?

Why are you concerned about the nRF91 data rate and what do you mean by ‘throughput on the cellular side lacking’? 

Regards, 

Markus 

[Ben Li]

Albrecht Markus Schellenberger said:

I’m honestly not quite sure what your approach is here. Can you elaborate? 

My first approach is to use nRF52 that scans and initiate connections, and I will need another nrf52 as a peripheral to advertise 20 BLE signals in total using blood pressure profile, heart rate profile... etc. To send the data to the cloud, I will connect the central with another third party cellular module such as the madrino board via SPI or UART so that I can foward the data to the cloud via 4G/5G cellular

My second approach is just using two NRF9160 together. Since there are on board nrf52480 SOC and cellular modem. It will serves as a central. I will still use another nrf52 to serve as peripheral. 

Albrecht Markus Schellenberger said:

Why are you concerned about the nRF91 data rate and what do you mean by ‘throughput on the cellular side lacking’? 

My concern is that I'm not sure if there is going to be latency issue  since nRF9160 seems to be designed for low throughput use cases. As I'm having 20 concurrent BLE signals. I am afraid the network core will runs out of memory. Therefore I'm wondering if it is necessary to connect two nRF9160 together to solve this issue.

[Ben Li]

Hello Markus, 

Thank you so much for your input. 

Albrecht Markus Schellenberger said:

I’m still not sure if I understand what you mean by 'latency issues'. Could you think of a specific example or use case here? 

I think what I'm trying to say is that the throughput of the modem on nrf9160 seems to be very low. Just like what other people said  nRF9160 DK maximum throughput I'm not sure the UL rate of 50kbps is going to be enough for my case (20 concurrent BLE connections). I am afriad that when the application sends more data than how much the modem can transmit, I will experience the some issues with the data trasmission. (like it´s waiting to send the buffer to the cellular tower or the socket disconnects.) 

Albrecht Markus Schellenberger said:

What gives you the impression that the nRF9160 'seems to be designed for low throughput use cases'?

I've been told by Simon about this issue on my last ticket  nRF6943 or nRF9160 DK (BLE Cellular gateway) but I still want to consider using nRF9160DK because I'm not sure how to connect nRF52 with SIMCOM GSM. So I'm wondering if nRF9160 cellular modem is capable of supporting high throughput. I have also been told by my supervisor that LTE-CAT M1 doesn't have enough UL and DL rate, what's why I'm considering using LTE CAT4. What do you think about that?

Thank you,

Ben Li