Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Low Latency Wireless Comms


  • Please log in to reply
1 reply to this topic

#1 Andy J

Andy J

    New Member

  • Members
  • Pip
  • 5 posts

Posted 28 October 2012 - 10:22 PM

I would like to achieve low latency (<5 ms) wireless communication directly between a MCU and computer. To to this, I first thought about using Bluetooth as there have been a couple suggested solutions mentioned on these forums. What I'm finding is Bluetooth has an inherent built-in latency, especially at lower packet-sizes (1 - 25ms). So then I thought, ok, I'll just use RF between two netduinos (have the GO, ordered the mini yesterday) with one talking to a computer via rs232 comms. After a bit more research, I found that there may be more latency than I would have guessed between hardware and the TinyCLR framework. Some suggest using an Arduino instead as it has lower-level access to the pins. Finally, I see solutions like Pololu Wixel which removes one netduino from the equation to interface with the computer directly instead. Might one of you have thoughts/suggestions on this; am I asking too much? Thanks

#2 Nobby

Nobby

    Advanced Member

  • Members
  • PipPipPip
  • 70 posts

Posted 29 October 2012 - 10:39 AM

You're going to find that most wireless comms use a burst approach for data transfer. The hardware protocol will usually try to send a data burst of a minimum to maximum size and at deterministic intervals. This is because free-space(air) is an indeterministic transmission medium which causes time varying scew in the carrier and data(phase distortion) and all sorts of other nasties. It places a constraint on the continuous length of time you can transmit data before the probability of data error becomes too high. So essentially synchronised, continuous data streams between wireless devices is impossible without substantial overhead. There is also a fair amount of overhead for sending/receiving data in general, especially with multiple devices which places a constraint on optimal minimal packet size as well as burst interval. Having said all of this, it's still quite possible to achieve a ping of under 5ms. I have a wireless bridge in one of my outdoor systems which is line-of-sight and spans 400m with a ping of no more than 1ms. -It runs at 5GHz instead of the 2.45GHz band -The devices don't use a proprietary protocol -They have adjustable high-gain antennae and high base power level -Can operate at up to 75km appart Those are the kind of extents you have to go to in order to meet requirements. You're going to have to dodge 2.45GHz devices unless you know your operating environment is going to be well shielded from other terrestrial noise. If you live in america, they're laws permit 2-3 times the maximum broadcast power of 2.45GHz transmitters than a lot of other countries so your signal-to-noise ratio(SNR) can suffer a lot more increasing overall latency. Once you've got a decent wireless architecture then you can start looking at .Net runtime overheads etc etc.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.