This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Acquiring 5.6kHz ODR samples from LIS3DH sensor using nRF52832

Hi -

I have 2 questions: 

1) I am looking for an example application that demonstrates acquiring acceleration data at high ODR of 5kHz from LIS3DH sensor using nRF52832 module. Are there any examples demonstrating this application ?

2) Are there any examples /demonstrations showing data throughput rates possible with above configuration in a Mesh mode. 

Thank you for your help. 

Regards

Parents
  • 1) I am looking for an example application that demonstrates acquiring acceleration data at high ODR of 5kHz from LIS3DH sensor using nRF52832 module. Are there any examples demonstrating this application ?

     We don't have an example doing exactly this, no. But we do have some simple SPI examples, if that is what this sensor is using. You must check the datasheet.

     

    2) Are there any examples /demonstrations showing data throughput rates possible with above configuration in a Mesh mode. 

    Unfortunately, we don't have any throughput examples in Bluetooth Mesh, no. However, I think you will be disappointed if you try to implement this on Mesh. Depending on the size of the samples, I would assume that you are looking at at least  3 bytes per sample (3 axis), so minimum 15kbps. This is too much for a Mesh network. It is difficult to say an exact number, because it depends on the number of nodes in your network and the settings for each node (how many times each message will be relayed). In general, Mesh is not intended for streaming sensor data at a high rate, but is very good at distributing few messages that are intended for several nodes.

    You can look at it the following way: Every node is a person. If one node is a light switch who wants to turn on the light bulbs in the network, this person would shout "ON" to the network. All the nodes/persons that can hear this first message will repeat/relay the message by shouting "ON" a couple of times. As long as all the nodes hears at least one message containing "ON", it will turn on the light (and shout "ON" to the rest of the network).

    Now, imagine that a node recording sensor data will shout a longer message 5 000 times every second, you will quite quickly flood this message. At least if there are several nodes recording their own sensor data and shouting it. If a simple "ON" message will be tranmitted N*M times in the network, where N is the number of nodes, and M is the number of times each node will relay the message, e.g.  10 nodes and M relays will be 30 messages. If you replace this with 5000 messages each second, it will be 150 000 each second. If there are two nodes, it will be 300 000. Of course, this is a bit simplified, but it gives a fair example on why Mesh networks doesn't have a high throughput.

    In Bluetooth Low Energy, however, connections are 1-to-1, instead of many-to-many. So you can have a much higher throughput (up to 1.3Mbps payload, using 2MBPS PHY).

    I am sorry, this is probably not the answer you were hoping for, but it is how Bluetooth Mesh works.

    Best regards,

    Edvin

  • Hi Edvin: 

    Thank you for your message and a detailed analogy of the Mesh network.

    So, just to clarify my use case - I am not looking to send data from each sensor very frequency. Perhaps one data csv file every 30 mins or so. So, the mode would be like - the processor reads the sensor data at high ODR but saves it in buffer and only pushes out in case of an anomaly (threshold hit) or every 30 mins or so. If no anomaly, it continuously dump the rewrites the new samples from the sensor. Is this achievable in a Mesh scenario?

    Also, however, to your point on the BLE 1-1 connection - are there any gateway/routers you may be aware of that can talk to multiple BLE devices and aggregate data, and push out the aggregated data over GSM or wifi network? 

    I appreciate your feedback. 

    Regards 

Reply
  • Hi Edvin: 

    Thank you for your message and a detailed analogy of the Mesh network.

    So, just to clarify my use case - I am not looking to send data from each sensor very frequency. Perhaps one data csv file every 30 mins or so. So, the mode would be like - the processor reads the sensor data at high ODR but saves it in buffer and only pushes out in case of an anomaly (threshold hit) or every 30 mins or so. If no anomaly, it continuously dump the rewrites the new samples from the sensor. Is this achievable in a Mesh scenario?

    Also, however, to your point on the BLE 1-1 connection - are there any gateway/routers you may be aware of that can talk to multiple BLE devices and aggregate data, and push out the aggregated data over GSM or wifi network? 

    I appreciate your feedback. 

    Regards 

Children
  • BobbySagoo said:
    the processor reads the sensor data at high ODR but saves it in buffer and only pushes out in case of an anomaly (threshold hit) or every 30 mins or so. If no anomaly, it continuously dump the rewrites the new samples from the sensor. Is this achievable in a Mesh scenario?

     That depends on the size of this file. For reference a DFU with a decent sized application takes perhaps 10-15 seconds on BLE, and about 1h with Mesh. 

     

    BobbySagoo said:
    are there any gateway/routers you may be aware of that can talk to multiple BLE devices and aggregate data, and push out the aggregated data over GSM or wifi network? 

     Well, a Raspberry pi can probably do that, but we don't have any "preferred" devices. I guess there are a lot. Either you can create it yourself using nRF for BLE and serial to a Wifi/GSM module, or you can look for something that is already on the marked.

    Multiple BLE connections are possible. The nRF52832 supports up to 20 concurrent connections (but remember that the BLE throughput will be distributed on the number of connections). The aggregation depends on the application on the gateway/router. I don't think you would find something pre-programmed that would do exactly this, but I may be wrong.

    Best regards,

    Edvin

Related