Wireless sensor streaming maximum amount of data possible?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am wondering if Wireless AVR technologies can fit my research application.

We are trying to simultaneously stream from multiple wireless sensors and receive that data on a PC.

There must be at least 6 sensors but likely up to 12 each sensor samples 100 times a second and each sample contains at least 12 bytes of information.

The ideal situation is connecting one wireless transceiver to the PC through USB and an ftdi board and having all the sensors sending data to that transceiver. The transceiver will only send simple commands to the sensors, eg (start stream),(stop stream).

Will technologies such as 802.15.4 LwMesh be able to handle that much data? I'm wondering what happens at the transceiver connected to the PC, with only 6 sensors it should be reliably receiving 6*100*12 bytes = 57.6 kbps with 12 sensors 12*100*12 bytes = 115.2 kbps. In case of more than 12 bytes of data we will definitely want to be able to have more than 250 kbps of data coming into the PC reliably.

The current commercial solution we use are Bluetooth sensors connected to a USB Bluetooth dongle. Each sensor is seen as a COMM port on the PC. Unfortunately from my understanding of Bluetooth this limits us to 7 sensors. Furthermore it appears that the internal drivers swap between reading each device, for each sensor we run in a separate thread waiting for data on the COMM port we will get packets from one sensor and then 6 packets from another instead of getting 1 packet from sensor 1 then 1 packet from sensors 2 and so on.

Thank you in advance.

Last Edited: Fri. Oct 16, 2015 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

100 samples/sec.. can work if the samples taken over time can be sent in batches.

plan on 8 bit samples.

I've 8 years of 802.15.4 experience w/wireless sensors and know what's viable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Luco wrote:
In case of more than 12 bytes of data we will definitely want to be able to have more than 250 kbps of data coming into the PC reliably.
Most PC operating systems have too much latency to meet that throughput.
Open Kernel Labs (OKL) has a microkernel RTOS for the first stage of stream processing that would then complete the subsequent stage(s) in your preferred operating system.
OKL is dual licensed (GPL, commercial); iow the OKL part of your application is GPL unless purchase the commercial version.
An alternative is to apply a low latency Linux kernel patch.
https://rt.wiki.kernel.org/index.php/Main_Page
IIRC that patch, or an older version, is at Linux4SAM for SAM9 (also SAMA5D3?) if one wants total Atmel.
Another alternative is bare or RTOS on a MCU then USB into the PC.
Atmel has a gateway application note that uses a mega128RF model with a WIZnet to get the Ethernet TCP/IP; that AVR might not be compute capable enough for the required data aggregation and processing.
The new Atmel wireless SAM is likely capable.
On that line of thought, dresden elektronik has gateway, node, and USB radio stick products; the USB radio sticks are SAM3 plus an Atmel wireless transceiver.
http://www.dresden-elektronik.de/funktechnik/wireless/white-papers/?L=1
LS Research also has a gateway.
http://www.lsr.com/wireless-products/protocols/zigbee-802-15-4
A low latency application in the gateway can buffer and/or process the data stream(s) with the greater latency functionality on the PC (database, operator interface, content management interface).
Luco wrote:
Unfortunately from my understanding of Bluetooth this limits us to 7 sensors.
Bluetooth 4 (Bluetooth Low Energy (BLE), Bluetooth Smart) has some relief on that.
A star network and maybe a mesh network is possible.

Reads:
https://github.com/NordicSemiconductor
https://devzone.nordicsemi.com/index.php/max-slaves-in-star-network-with-nrf51822
https://devzone.nordicsemi.com/index.php/what-is-the-most-efficient-way-to-transfer-data-over-ble
https://devzone.nordicsemi.com/index.php/is-there-a-serial-port-profile-for-ble
https://devzone.nordicsemi.com/index.php/cable-replacement-profile-uart
http://www.rfduino.com/documentation/
Comparing Low-Power Wireless Technologies by Phil Smith (Digi-Key, 08/08/2011)
Short-Range Low Power Wireless Devices and Internet of Things (IoT) by Mats Andersson (Digi-Key, 01/16/2014)
Bluetooth 4.0 Parts and Modules: Finally Ready For Prime Time by Jon Gabay (Digi-Key, 04/17/2014)
Bluetooth Low-Energy Technology Isn't Just Another Bluetooth Revision – It’s a Whole New Technology by Bill Saltzstein, Rolf Nilsson (Digi-Key, 09/13/2012)
http://www.slideshare.net/tuehaste/real-time-sensing-with-bluetooth-smart-24136341

O.T.
Cortex-M is capable of audio processing.
These data rates are roughly similar to your data rates.
Lossy audio codecs.
Your streams are likely loss-less though could be processed (reduction), compressed, error correction added (ECC or FEC), and encrypted before transmission.
Audio Processing on ARM® Cortex(TM)-M4 for Automotive Applications by Pradeep D (Ittiam Systems Pvt. Ltd) (ARM, PDF)

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

802.15.4 data rate fundamentals are similar to those of ethernet. At the hardware level both transmit variable-length packets through a half duplex channel using CSMA random backoff. Throughput is constrained not just by maximum data rate but also by the maximum packet rate based on header length, data length and the required silence between packets.

For 802.15.4 that's about 1000 shortest packets per second giving 1 kbyte/sec, or about 200 longest packets for 20 kbyte/second.

That is for a single transmitter or multiple transmitters using accurate time slicing. As soon as collisions occur expect the data rate to drop by a factor of two.

I'd say the only way 802.15.4 could work at your rates would be if each node used a different channel, using a separate receiver and serial port on the PC side. And that would be using the maximum data rate on each channel.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dak664 wrote:
That is for a single transmitter or multiple transmitters using accurate time slicing. As soon as collisions occur expect the data rate to drop by a factor of two.
Curious to know the collision reduction methods in the set of protocols.
"The purpose of the modification of the standard WiFi MAC is to make it suitable for long distance applications by replacing the CSMA Media Access Control with TDMA. The latter is better suited for long distance point-to-point links since it does not require the reception of ACKs. This eliminates the need to wait for the 2 ms round trip propagation time on a 300 km path."
Long Distance 802.11 in Venezuela at Wireless Networking in the Developing World, Case Studies.

802.11 -
There are WLAN modules that state useful life from lithium primary cells (and very likely lithium iron phosphate cells).
These are made by GainSpan; Murata (was RF Monolithics) uses a GainSpan SoC.
Atmel is also creating a product.
Atmel, Wireless / RF > Wi-Fi

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My experience is based on older slow ethernet but I expect it applies to newer CSMA. You can hog a channel and get maximum data rate from a single node. Round robin or token ring gives the maximum rate from multiple nodes if they all have something to transmit (monitoring a particle accelerator for example). TDMA gives reliable but slower data rates from all nodes. Event based transmission works until all hell breaks loose, then you lose communication with the devices you really really would like to control at that moment.

I think the best protocol would allow switching between all of the above, the decision of each node based on channel activity. The worst case in a jam can be all nodes doing nothing other than waiting for instructions from the coordinator. If a new node sees the clear channel and decides nothing is wrong it can block necessary traffic with low priority status information.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman, thank you for all the information. I have read up a lot on Bluetooth and 802.15.4 and realize that I'll have to reduce my requirements, maybe buffer and transmit multiple measurements at once, and lower sampling rate. I will most likely use Bluetooth for data transfer as it appears to support higher data rates.

I've found Bluegiga WT12 Bluetooth module and the datasheet says it supports Scatternet so perhaps that is the way to go. Also compared to other modules their documentation is rather impressive. I've posted in their forum in hopes that their developers will get back to me with feasibility of the project.

Again thank you all for your quick responses. I'll be back when I have more AVR related problems.