Wi-Fi TimeSync | Hacker News Reader

Wi-Fi TimeSync

wi-fi.org

110 pointsphr4ts58 comments

This is huge news to me. Standardized microsecond level wireless time sync available on cheap commodity hardware. We could've used this at the startup I was at 4 years ago. I see lots of uses in the AR space, along with device tracking algorithms.

Not entirely relevant, but I'm curious about that startup... is it still around? Did the company ever find a way around the need for this?

Hah yes we did. Wires. Of course everyone wants wireless though and while it would've improved the overall experience I'm not sure it would've saved the company. Other market factors were making more of a problem than just delivering good tech :/

In further thinking about the idea, once the wifi devices are time synced like this, you can also begin to use that signal for localization in addition to the traditional optical or electromagnetic tracking. Fun!

You need better sync than ~1 microsecond to do time-of-arrival localization for Wi-Fi style signals, though... since RF waves travel at around 1 ft per nanosecond.

Ultra-Wideband devices can get this synchronization though, and can be used for localization.

How can you use UWB for this? Doppler?

The Doppler effect would only help with a moving source or target, so probably not.

I would guess that what was meant was using two (or more) frequencies at the same time would produce harmonics that reinforce and cancel the combined signal at set distances from the source that can be used to get distance info, and if you can get distance to three different points, you get a 3D location[0]. The technique dates back to WWII.

Further, I think it works best if the frequencies are each a different prime (otherwise you get many beats). There are probably additional tricks you can do by varying the precise frequency combination to extract very fine-grained location data.

[0] Technically, you get two solutions, one on each side of the plane connecting the three points, but they can be disambiguated as long as direction can at least crudely be determined within 180°.

DecaWave sell UWB modules that perform real-time location to ~10cm in a controlled environment: http://www.decawave.com/

I imagine that they use a system which is not too different to the way GPS combines the signals from multiple satellites to calculate the receiver location.

When you receive have a receive lock against multiple receivers, the spreading code allows you to determine time of flight to the nearest carrier cycle, and the carrier phase can provide even more precise timing. See also: https://en.wikipedia.org/wiki/Multilateration

A long time ago I wondered why home routers didn't run (or include, at least) an instance of ntpd in broadcast mode on the internal interface that clients could sync to.

You can run an NTP instance on your own, of course, and point clients at it via DHCP options but I thought something like that would be kinda handy for easily keeping time synchronized across all one's devices.

That doesn't really fit this use case, of course, but it reminded me of it. With more and more "home devices" being network-enabled, something like that would be extremely useful (and could put to an end "12 o'clock flashers").

Mine does, but I suppose we're talking about standard CPE devices. They indeed only do the minimum and are often locked down to prevent you from adding or changing anything. All in the name of stability and customer experience. The reality is, of course, that it is way too expensive to support millions of home users when they start relying on the CPE for more services or start changing the settings.

And to allow the manufacturer to use a lower-power (and cheaper) processor with half the RAM and less storage.

Software (something like the OSS ntpd at least) is free, parts on a board, physical board size, routing etc. not so much.

Why run your own instance when you can just flog the crap out of the public pool for free? [1]

Digging into the internals of a few "high end" consumer modem/routers, I wouldn't trust any manufacturer to provide a secure ntpd, so we'd probably just end up with NTP amplification attacks [2] on a Mirai scale.

1: https://www.lightbluetouchpaper.org/2006/04/07/when-firmware...

2: https://blog.cloudflare.com/technical-details-behind-a-400gb...

I wanted to read the stuff on the wi-fi.org website, but due to the many cases of the capitalized word "CERTIFIED" I ran away...

I'm not sure why, but somehow it feels like walking into the lion's den if a page has that many occurrences of that word.

How does this work? I assume it's not just ntp over TCP/IP/Wi-Fi...

Probably just the wifi TSF: https://en.wikipedia.org/wiki/Timing_Synchronization_Functio...

Notably used by the Wii U: https://patchwork.kernel.org/patch/5865651/

TSF is not scalable[0].

[0] http://web.cse.ohio-state.edu/~lai/788-Au03/2-scalibility.pd...

I should have mention this only applies to IBSS (ad-hoc), not to (infra) BSS, where the AP sends the beacon

>On a commercial level, industry vendors assume the 802.11 TSF's synchronization to be within 25 microseconds.

Meh. Still cool, but a far cry from the sub-MICROsecond accuracy the page suggest, which would indeed be quite revolutionary.

I'm curious which are the use cases for sub-microsecond time sync. Entertainment can probably do with millisecond accuracy. Other use cases mentioned by the Wifi Alliance preso are healthcare, industrial, automotive, and IoT. Do you know any precise use cases?

Lovely to see. Is this just a spec? What does it need for me to use it as a developer? Drivers? Hardware support? Kernel support?

Most likely all of them.

I'm completely ignorant on the need for this technology. Can anyone explain a potential use-case? The website simply states "Home entertainment systems, automotive infotainment systems, and industrial sensor-based systems rely on precisely synchronized components to deliver optimum results."

What are "optimum results?"

I'm super hopeful this could simply be used in my microwave, stove, car, really anything with a cheap clock in it to sync the time between them to some accurate source, and automatically apply DST.

Most countries have radio signals that transmit the time (including DST). The issue is there has traditionally been no global standard on how it works - each country/region has their own implementation:

https://en.m.wikipedia.org/wiki/Radio_clock

Related: this post [1] from the other week on HN, describing a neat little project to build a low-power radio station which emulates the output of radio station WWVB (a fairly well-known station out of Colorado, which transmits the time signal to large parts of North America).

You could build one of those in case you aren't within range of one of the NIST-operated stations :-)

[1] https://news.ycombinator.com/item?id=13258631

If you're playing the same audio from multiple sources but slightly out of sync the effect can be pretty unpleasant depending on the delay and how sensitive you are to timing.

My friend was using wireless speakers for his projector. Noticeable lag between the speakers and the mouths on screen. Ended up throwing wires to the speakers to fix it.

Many systems (hell, even my almost ten year old mid-range Sony TV) have options to adjust audio offset. I'm surprised something like a projector or AV Amp wouldn't.

For home entertainment, if you have a wifi speaker in 1 room, another in another room and they're playing the same music, you'd want them to be playing the same part of the song at the same time, otherwise it's like hearing an echo.

Cars have their own network, although afaik their speakers are nowadays still wired. Maybe for a pimped van with 3 rows of seats and 6 seatback-screens (like on a plane), you'd want to be able to sync the video, if indeed there's a use case for that.

I see. Will this make a difference with streaming radio?

Great idea, but I'd say practical applications are limited..

Industrial sensors shouldn't rely on Wifi. Hospitals shouldn't rely on WiFi. In a car just run ethernet alongside power.

Since you can't guarentee wireless maximum latency on WiFi, I still wouldn't use it for multi-channel audio (only multi-room, which NTP is good enough for anyway probably). Especially a problem if you want to sync against Video.

So its a nice idea, but it will probably affect very few people..

The playback buffer size is usually much larger than the wi-fi latency. This should allow multi-channel and video to sync without issues.

That still introduces other issues though. You will probably need larger than 200ms to be safe, which will make the setup annoying for applications such as gaming.

Or it would need great error correction. Either way, wifi equipment needs to accept interference (nothing you can do)

Well, considering Sonos has multi channel and multi room capabilities wirelessly, it can work. That said I have no idea how this spec works vs whatever proprietary magic they've got going on.

I wonder if this can time-sync wifi and ethernet devices together, because I feel like a lot of installations will have a mix.

Does this require an access point or would it work with ad-hoc wi-fi or wi-fi Direct?

Says in the article, either.

Specs are not out yet? I couldn't find any on wi-fi.org.

Any chance we're going to see this result in TDMA?

I'm wondering how this compares to tsn (aka audio video bridge[0]). Their conclusion was wifi is not reliable enough for time sensitive applications. Great av networking is not only about clock sync anyway so this looks more like a half baked standard, nevertheless a good step towards lag free av.

[0] https://en.m.wikipedia.org/wiki/Audio_Video_Bridging

I tried to look something up but there is no mention of underlying tech... is this at all related to PTP?

Now how about adding a two way data/file transfer spec to WIFI Direct?

So basically what a Sonos does, as a standard.

...or Airplay.

Airplay works on top of wifi and it can't play multichannel audio. Not to mention the crappy experience when the video is "buffering". Hopefully this standard will fix such issues but I have big doubts.

I thought this too until recently, but Airplay does, in fact, support multichannel audio in sync–but only through playing music to speakers through iTunes Desktop [1], as its the only client to officially implement it. Of course, we don't see more multichannel Airplay clients because it is my understanding the standard is proprietary...

[1] https://support.apple.com/kb/PH19497?locale=en_US

Is there ANY multi channel client? I tell you: no! And it can't really be because Apple specifically limits AirPlay output to one single destination. It's because wifi sucks and as it is and it just can't work on multi channel(things will get out of sync, some channels will buffer while others will play etc). If you read the avb specs you will underatand why. Wifi needs hw changes.

https://en.m.wikipedia.org/wiki/Audio_Video_Bridging

Sonos was the first. But now everyone is doing it, so it's cool to see it standardized.

Sonos doesn't have the ability to sync audio with video, only audio with audio, correct? We recently acquired a Sonos Playbar and the interplay between HDMI/Optical Out/TV processing made the lip syncing a nightmare. Still not sure it's entirely solved.

Typically, you need to plug in any external speakers (including the Sonos Playbar) to the optical out on your TV itself. This port is intentionally placed at the end of the TV's (latency-inducing) processing chain, and will get you properly synced audio.

If you connect to the optical out on any other devices, you're pretty much guaranteed to have sync problems.

I thought sonos can't even do multi channel audio. It's just a kind of mesh network. Wisa was supposed to fix that but for some reasons it seems it failed to get mainstreem

No, you can have multiple speakers synced together with Sonos. It works very well; I've never noticed any drift. As I recall, this is why Sonos devices can't just run off a home wifi network and require a bridge.

Ok, but can you play multi-channel? Like a 5.1 system in a home theater ? As far as I know it's not possible. Multiple speakers playing the same content is not really multi channel.

They sell 5.1 systems:

http://www.sonos.com/en-us/shop/wireless-5-1-surround-sound-...

That's right but in my defence that's really a 3.1 system as you have lf, rf and center in a single speaker. It's also worth to note that lf, rf and center speakers are the most demanding/used channels so IMHO the problems were avoided not fixed. Putting all your channels into a single speaker is not really what I thought when I heard of wireless multi-channel audio. I also don't know what resolution they use because it's not mentioned in their specs but something tells me it's not 24 bit at least not for the separate speakers. I've tried multichannel wifi audio but it just doesn't work either due the buffering or the sync issues. I ended up with some proprietary technology with multiple antennas based on the 5GHz band but you need clear line of sight and that's not always convenient. Anything obstructing the line of sight may make your speaker fail to play. To sum it up: it's true that sonos has a 5.1 system but that's really a half backed solution. It's actually a 3.1 configuration. This may work for some people just like bluetooth speakers work for so many. Can they play in a real/native 5.1 configuration(6 separate speakers)? that's hard to say. What about real 7.1 or the latest configurations such Atmos/DTS:X ( 5.1.4 or 7.1.4)? That's impossible without hardware changes. Some would say that even standard ethernet is not good enough for multi channel audio(thus avb[0] or [1]powerlink) so I can't really see how standard wifi could work.

[0] https://en.wikipedia.org/wiki/Audio_Video_Bridging

[1] https://en.wikipedia.org/wiki/Ethernet_Powerlink

Play bar gives you the front 3, you can set up a pair of 1s as your rear left/right and then the sonos sub gives you the .1. So they do support 5.1 right now.

Sonos hasn't need a bridge for 2 years now. In my setup at least, it works just fine without it. See, e.g.:

http://www.techhive.com/article/2601036/sonos-speakers-now-r...

Ah, ours are at least two years old.

It was a software, not a hardware, update that enabled this feature

Reply on news.ycombinator.com