• State Verified Answer
  • Replies 4 replies
  • Subscribers 73 subscribers
  • Views 1294 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 124830
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Possible solution for battery sensor network

erltot

Would it be possible to use BLE for a sensor network with aprox. 40 battery peripherals measuring a float at 100hz? 50hz? For one central unit, or how many if needed.. The data is to be relayed to a cloud service..

Data could be transferred in bulk but would need timestamps e.g. per bulk

Could it work? How can it be organized?

Parents
  • 0

    Hi,

    That sounds a bit ambitious.

    1. Our most advanced BLE stacks so far support 20 concurrent links. You might be able to implement some sort of "Round-Robin" scheme though, and let every node connect, transfer data, and disconnect again, so that every node get the chance to establish a link.
    2. With 20 concurrent links you will not be able to transfer data at 100 Hz. The way BLE works only allows you to reach 20 Hz at best. Please refer to the Softdevice Specification and the chapters about scheduling links for more details.
    3. Given the facts in point 2 you will have to bulk your data. If you then have one float variable, a 4 byte timestamp, and transfer at 100 Hz you get 8 bytes * 100 Hz = 800 Bps = 6.4 kbps. (I bet you can also figure out some way of using only a single reference timestamp and then assume that every consecutive sample is spaced so an so far apart to save some bandwidth). Anyway, looking at the thorughput chapters here you can see that there is plenty of bandwidth left so throughput shouldn't be a problem. If you transfer between two nRF52s, still with 20 concurrent links, you can reach 1327.5 kbps / 20 = 66 kbps. Note however, that other chipsets might not support the same throughput and/or number of links, so you cannot expect to reach these values between any given BLE devices.

    Bottomline: It should be possible, and the greatest challenge will probably be the number of nodes.

Reply
  • 0

    Hi,

    That sounds a bit ambitious.

    1. Our most advanced BLE stacks so far support 20 concurrent links. You might be able to implement some sort of "Round-Robin" scheme though, and let every node connect, transfer data, and disconnect again, so that every node get the chance to establish a link.
    2. With 20 concurrent links you will not be able to transfer data at 100 Hz. The way BLE works only allows you to reach 20 Hz at best. Please refer to the Softdevice Specification and the chapters about scheduling links for more details.
    3. Given the facts in point 2 you will have to bulk your data. If you then have one float variable, a 4 byte timestamp, and transfer at 100 Hz you get 8 bytes * 100 Hz = 800 Bps = 6.4 kbps. (I bet you can also figure out some way of using only a single reference timestamp and then assume that every consecutive sample is spaced so an so far apart to save some bandwidth). Anyway, looking at the thorughput chapters here you can see that there is plenty of bandwidth left so throughput shouldn't be a problem. If you transfer between two nRF52s, still with 20 concurrent links, you can reach 1327.5 kbps / 20 = 66 kbps. Note however, that other chipsets might not support the same throughput and/or number of links, so you cannot expect to reach these values between any given BLE devices.

    Bottomline: It should be possible, and the greatest challenge will probably be the number of nodes.

Children
Related
Terms of service