Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Benchmarking latency across common wireless links for microcontrollers

electricui.com

Post reply on HN
Print view View original

21–30 of 36 posts

Re: Benchmarking latency across common wireless links for microcontrollers

#21

Post by byb »

skywal_l wrote: post #10

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.

I've had the same desire to extend USB HID devices, but I want to take it a step further. Once a USB device USB host technology is available, then a wireless USB switch should be possible. The research in this article is critical to understanding the impact of latency on the experience.

Several months ago, I built a project using USB host mode on a Raspberry Pi Pico, which uses a USB numpad to pass messages to an MQTT server. This uses the Rp2040's USB host mode https://gitlab.com/baiyibai/pico-w-usb-host-mqtt-numpad

https://github.com/adafruit/Adafruit_TinyUSB_Arduino

My implementation plugs in much higher into the stack and doesn't read the full USB bit mask output, which indicates how many keys are pressed/released.

From my limited understand ing, it should be possible to pass these USB messages from HID client to HID host and vice-versa. Then it's only a matter of sending this information over a TCP/UDP interface. However, from my research, it seems the TinyUSB library doesn't provide the full bitmask resolution necessary for all devices. The YouTuber Wendell from LevelOneTechs has also talked about the troubles of getting some devices working with his KVM products, so it may not be as simple as I'm suggesting here.

Overall though, a $15/endpoint is very attractive.

Re: Benchmarking latency across common wireless links for microcontrollers

#22

Post by polishdude20 »

utopcell wrote: post #16

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…

With guitar, how would the latency stack up when you add a/d conversion?

Re: Benchmarking latency across common wireless links for microcontrollers

#23

Post by zh3 »

polishdude20 wrote: post #22
utopcell wrote: post #16

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…

With guitar, how would the latency stack up when you add a/d conversion?

A/D conversion itself wouldn't add much at the sample level (say 48KHz sample, it's about 50us per sample). However, packetisation will - a 256 byte packet of 128 samples is 128*50us = 6.4ms right there at the transmitter, and the receiver won't notify until the full packet is received. So a naive digital approach would be 12.8ms (2x6.4ms) even before anything else.

A pure analogue approach (modulated RF) on the other hand shouldn't have any human-detectable delay - it's effectively distance/speed of light with a bit of a phase shift (addtional delay) introduced by the electronics - should be only a handful of microseconds in total.

Re: Benchmarking latency across common wireless links for microcontrollers

#24

Post by skywal_l »

byb wrote: post #21
skywal_l wrote: post #10

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.

I've had the same desire to extend USB HID devices, but I want to take it a step further. Once a USB device USB host technology is available, then a wireless USB switch should be possible. The research in this article is critical to understanding the impact of latency on the experience. Several months ago, I built a project using USB host mode on a Raspberry Pi Pico, which uses a USB numpad to pass messages to an MQT…

> Several months ago, I built a project using USB host mode on a Raspberry Pi Pico, which uses a USB numpad to pass messages to an MQTT server. This uses the Rp2040's USB host mode https://gitlab.com/baiyibai/pico-w-usb-host-mqtt-numpad

Maybe I read the README a little to quickly, but you seem to be using standard WiFi for communication. As stated in other comments in this thread, this solution already exists. USB through Ethernet extension are well established and you can already connect this to a WiFi extender.

What I was thinking was to achieve this with a simple radio connection that do not need configuration or even a WiFi network to function. Just plug it in and it works. Here's a sketch of the high level concept I had in mind: https://ibb.co/VD2d9XM

Is your point that once you can do that with Wi-Fi it is trivial to do it with any type of radio connection?

> From my limited understanding, it should be possible to pass these USB messages from HID client to HID host and vice-versa.

Someone did this here using Etherkey and an ATmega32u4: https://www.sjoerdlangkemper.nl/2022/11/16/running-etherkey-...

> it seems the TinyUSB library doesn't provide the full bitmask resolution necessary

If my understanding is correct, Arduino already provides low level USB controls: https://shorturl.at/joSWZ.

All in all, it seems to me that there is an opportunity here but unfortunately this requires skills in electronic, radio and USB protocol that I do not possesses and seems fairly rare.

Re: Benchmarking latency across common wireless links for microcontrollers

#26

Post by utopcell »

zh3 wrote: post #23
polishdude20 wrote: post #22

Earlier quoted context omitted.

With guitar, how would the latency stack up when you add a/d conversion?

A/D conversion itself wouldn't add much at the sample level (say 48KHz sample, it's about 50us per sample). However, packetisation will - a 256 byte packet of 128 samples is 128*50us = 6.4ms right there at the transmitter, and the receiver won't notify until the full packet is received. So a naive digital approach would be 12.8ms (2x6.4ms) even before anything else. A pure analogue approach (modulated RF) on the othe…

128-sample buffers are already too large. To compare, the nRF24 has a max buffer of 32 bytes. However, even in your 128 samples, 16bit/48kHz example, latency is a bit better. It will take 1000/48000 * 128 ms to collect the 128 samples, or ~2.66ms. This amounts to 16*128 bits or 2k bits of information that the transmitter will have to send over. At the nRF24 2mbps rate, another ~1ms will be needed to send the buffer over. I'm not sure why you'd think that this time needs to be doubled at the receiver. Even if the nRF24 receiver started moving the buffer after it was fully received, it does so over a 10MHz serial connection, so that would be at most another 0.2ms, for a total of <4ms. For 16-sample buffers and 24bit/48kHz, the end-to-end latency is ~0.6ms.

Re: Benchmarking latency across common wireless links for microcontrollers

#27

Post by polishdude20 »

utopcell wrote: post #26
zh3 wrote: post #23

Earlier quoted context omitted.

A/D conversion itself wouldn't add much at the sample level (say 48KHz sample, it's about 50us per sample). However, packetisation will - a 256 byte packet of 128 samples is 128*50us = 6.4ms right there at the transmitter, and the receiver won't notify until the full packet is received. So a naive digital approach would be 12.8ms (2x6.4ms) even before anything else. A pure analogue approach (modulated RF) on the othe…

128-sample buffers are already too large. To compare, the nRF24 has a max buffer of 32 bytes. However, even in your 128 samples, 16bit/48kHz example, latency is a bit better. It will take 1000/48000 * 128 ms to collect the 128 samples, or ~2.66ms. This amounts to 16*128 bits or 2k bits of information that the transmitter will have to send over. At the nRF24 2mbps rate, another ~1ms will be needed to send the buffer o…

Wait so you can get the latency down to 0.6 ms end to end?

Re: Benchmarking latency across common wireless links for microcontrollers

#28

Post by polishdude20 »

zh3 wrote: post #23
polishdude20 wrote: post #22

Earlier quoted context omitted.

With guitar, how would the latency stack up when you add a/d conversion?

A/D conversion itself wouldn't add much at the sample level (say 48KHz sample, it's about 50us per sample). However, packetisation will - a 256 byte packet of 128 samples is 128*50us = 6.4ms right there at the transmitter, and the receiver won't notify until the full packet is received. So a naive digital approach would be 12.8ms (2x6.4ms) even before anything else. A pure analogue approach (modulated RF) on the othe…

Analogue would be nice in that regard but wouldn't it be pretty bad with interference, signal quality over distances etc?

Re: Benchmarking latency across common wireless links for microcontrollers

#29

Post by utopcell »

polishdude20 wrote: post #27
utopcell wrote: post #26

Earlier quoted context omitted.

128-sample buffers are already too large. To compare, the nRF24 has a max buffer of 32 bytes. However, even in your 128 samples, 16bit/48kHz example, latency is a bit better. It will take 1000/48000 * 128 ms to collect the 128 samples, or ~2.66ms. This amounts to 16*128 bits or 2k bits of information that the transmitter will have to send over. At the nRF24 2mbps rate, another ~1ms will be needed to send the buffer o…

Wait so you can get the latency down to 0.6 ms end to end?

That's what a 16-sample buffer would get you. In reality, there are many devices on the market that can get close to 2.5ms. For example, Line 6 claims 2.8 ms end-to-end, BOSS claims 2.3 ms [2], the NUX B8 is at 2.5ms [3].

[1] https://line6.com/support/page/kb/relay-d-v-digital-wireless...

[2] https://www.boss.info/global/support/by_product/wl-20_wl-20l...

[3] https://www.proaudiostar.com/nux-b-8-professional-2-4ghz-gui...

Re: Benchmarking latency across common wireless links for microcontrollers

#30

Post by polishdude20 »

utopcell wrote: post #29
polishdude20 wrote: post #27

Earlier quoted context omitted.

Wait so you can get the latency down to 0.6 ms end to end?

That's what a 16-sample buffer would get you. In reality, there are many devices on the market that can get close to 2.5ms. For example, Line 6 claims 2.8 ms end-to-end, BOSS claims 2.3 ms [2], the NUX B8 is at 2.5ms [3]. [1] https://line6.com/support/page/kb/relay-d-v-digital-wireless... [2] https://www.boss.info/global/support/by_product/wl-20_wl-20l... [3] https://www.proaudiostar.com/nux-b-8-professional-2-4ghz-g…

What's the drawback of a 16 sample buffer over 128 samples?
Post reply on HN