[HN Gopher] Benchmarking latency across common wireless links fo...
___________________________________________________________________
Benchmarking latency across common wireless links for
microcontrollers
Author : killcoder
Score : 119 points
Date : 2024-02-09 14:06 UTC (1 days ago)
(HTM) web link (electricui.com)
(TXT) w3m dump (electricui.com)
| killcoder wrote:
| We nerd sniped ourselves into testing the latencies of a whole
| bunch of wireless communication links and protocols for
| microcontrollers.
|
| We'll probably do a series of power consumption / range tests
| later on, let me know if there are any setups in particular that
| you'd be interested in seeing test cases for.
|
| Raw data, firmware and post processing scripts are here on
| GitHub:
|
| https://github.com/Scottapotamas/embedded-wireless-latency-e...
| pockybum522 wrote:
| Once there's decent embedded HaLow options, I would love to see
| analysis of this level on it.
| scottapotamas wrote:
| I _nearly_ did, but the write-up was getting pretty long.
|
| I'll try to find something for the planned range/interference
| tests. Morse Micro is also an Australian company so I'll
| probably look into their parts first unless there's any
| recommendation?
| pockybum522 wrote:
| This is one of the most thorough and well laid out analysis of
| useful hobbyist and low level research options out there. I'll be
| referencing this for years, thank you very much. Clearly a lot of
| effort has been put into this.
| jauntywundrkind wrote:
| If we had more great reviews like this we'd see hardware improve
| faster! Thank you! Shine that light!
| comboy wrote:
| Outstanding blog post. NRF24 had been my fav for a long time, I
| planned switching to LoRa but I didn't know the latency is that
| high.
| steve_gh wrote:
| You go for LoRa or NBIoT when you need the low power
| consumption, and especially for deep penetration. Generally, if
| you have a better option, you use it. LoRa and similar high
| latency networks can't easily run TCP due to the standard TCP
| timers (especially Ack timeouts).
|
| What I would like to see is better support from the cloud
| providers for UDP based protocols such as MQTT-SN.
| zh3 wrote:
| That is great stuff, many thanks for it. While not in such depth,
| for a precision timing network covering multiple sensors our
| analysis also showed that the delays and variation inherent in
| most higher-level radio protocols are far too high for
| microsecond-level synchronisation.
|
| For this reason, we use the nRF52 radio peripheral directly (i.e.
| barebones C) which means we know exactly when the packet was sent
| and - at the other end - when it was received. Details are in the
| Production Specification document, which also shows how long it
| takes for the transmit to spin up (turn on, transmit pre-amble
| and so on).
| skywal_l wrote:
| Something of a tangent but I couldn't find anywhere a way to
| wirelessly extend usb ports. Allowing you to plug a
| mouse/keyboard/Yubikey to a computer in another room with minimum
| latency and without the need of any software or particular
| drivers.
|
| If one wanted to do something like that one would probably start
| by reading that article I guess.
|
| Thanks for this very thorough work.
| zamadatix wrote:
| WiGig docks were promoted for a short while but the problem
| they ran into was having an e.g. keyboard in another room
| wasn't very practical unless the display was as well and that
| bumped the RF requirements. So it ended up in the 60 GHz range
| which wouldn't make it to the other room and people basically
| said "eh, what's the point I'll just plug the dock in and it
| works".
| justsomehnguy wrote:
| USBAnywhere + any WiFi AP
|
| You would need drivers on the computer and I don't know about
| latency.
| snovv_crash wrote:
| Super cool. I'd love to see 2.4GHz LoRA as well.
| andai wrote:
| Not a radio guy but, isn't the whole point of LoRa to use lower
| frequencies for greater range?
| davidw wrote:
| Years ago I was working on a system where an Android device
| communicated with a web server written in Erlang, and our Android
| guy was going off about how Erlang was "really slow" and that
| made no sense to me. So we looked at the interaction times, and
| it was certainly true that something was slow. Instead of the
| Erlang server, we swapped out Apache serving a static page. That
| was slow too. It turned out he'd been benchmarking the crappy
| wifi connection.
| utopcell wrote:
| Great article!
|
| Here's a perspective from a guitarist's viewpoint. Most wireless
| guitar systems boast latencies below 3ms, with the better ones
| being closer to 1ms.
|
| Latency is important here because even small delays can be felt
| by the player. Since sound travels at ~1 ft per 1ms, a delay on
| the order of BLE is equivalent to playing with the amplifier
| ~25ft away from you, which is pretty bad.
|
| It is surprising that the best system is actually nrf24, given
| how old it is (or maybe because of that ?). It also seems to have
| enough bandwidth to transfer a 24-bit/48kHz signal.
| nsasch wrote:
| Thanks for sharing your research!
|
| I've done some similar, but not as thorough, tests with 2.4ghz
| WiFi and 915MHz LoRa before. My goal is to sync time across
| multiple devices that go in and out of range of each other to
| play 60fps light animations and sound within half a frame of each
| other (8ms), with spare time for some computation.
|
| I've been surprised at how bad some oscillators (or voltage
| regulators) can be and their effect on consistent latency.
|
| I was having fun experimenting, but this will be really useful to
| get me back to actually implementing my project.
| nanomonkey wrote:
| This is a great breakdown, although it doesn't go into any detail
| on the distance trade offs of each transmission type, which is an
| important part of the comparison. I look forward to when they go
| into this part of the analysis.
___________________________________________________________________
(page generated 2024-02-10 23:02 UTC)