Hacker News Reader

Comment by mbell | Hacker News Reader

> The toughest problem the program is having is matching the timing of the aircraft’s fusion software with its sensors’ software

I don't know if I'm interpreting that correctly but what I'm getting out of it is clock skew between sensors and the fusion system, which I assume to be referring to sensor fusion.

That makes sense, analogous to a typical distributed systems issue. I would imagine the skew needed for the type of sensing they do is quite small. I doubt they can just toss an atomic clock on the plane :)

View on HN

> I doubt they can just toss an atomic clock on the plane :)

They totally could. Some atomic clocks are quite small. The one pictured on the below wiki page doesn't look that much bigger than a 3.5" hard drive.

https://en.wikipedia.org/wiki/Rubidium_standard

> They totally could. Some atomic clocks are quite small.

Are they mil spec? In other words do they operate correctly over a very large temperature range, with large input voltage variance, under high G-forces, in high vibration environments, etc?

I don't know anything about atomic clocks past what I can read on wikipedia but, I can say there is generally a large difference between mil spec ICs and commercial or industrial grade ICs, I would assume this would extend to atomic clock scale devices as well, but just a guess.

Who needs atomic clocks on individual planes when the US government has spent billions of dollars to place a fleet of atomic clocks in orbit?

Someone whom wants their planes to work when the enemy jams GPS and/or shoots the satellites down. We're talking about war here after all.

So you freewheel once GPS goes down. You might drift a few microseconds. This is not necessarily a problem.

If you're traveling at high speeds and relying on this timing to adjust flight control surfaces, or trying to use radar to get position of combatants and/or the ground, a few microseconds clock skew would be a major issue.

I didn't say clock skew. I said drift. As in, you lose GPS timing signals so your own internal master clock freewheels. That has nothing to do with clock skew (different components within the jet 'seeing' different time due to delays or other issues). The jets are designed to function with degraded or no GPS functionality. But, if it's there, they will take full advantage of it.

For those downvoting, see my comment below, where I explain why this really isn't a problem.

Also, if I'm understanding the link properly you'd need an atomic clock for every sensor to make it work.

I wonder how something like that stands up to a gunfire vibration test.

That might have detection implications though.

I would imagine the skew needed for the type of sensing they do is quite small. I doubt they can just toss an atomic clock on the plane

I don't think a single atomic clock would do it -- sounds like they'd need a high accuracy clock for each separate subsystem.

But unlike distributed systems, it seems like an aircraft is small enough to have one clock that everyone uses - any idea why they don't do that? Single (or too much of a) point of failure? Disparate vendors can't agree on a standard? Too much extra wiring or other complexity?

The standard way to do timing in a system like this is for each subsystem to run its own binary clock, with the main system sending period time-of-day messages to keep everything externally synchronized. In that sense, all the systems do have one clock. Many do not need to worry about wall clock time or synchronization, though.

That is one explanation. I've worked in avionics telemetry & remote sensor fusion and there is actually a push to go from synchronous archs (using PCM on I2C buses) towards modular and networked archs (using some variant of IP/etc. protocols).

Problem is you need a reference time clock. On monolithic arch, is easy : the backbone bus timestamp the paquets it sees. On networked arch you need a time server a la NTP, otherwise you have time skew and loopbacks.

Even with a accurate time clock, you may also need to correct for timing issues due to cable length.

I'm curious what you mean by 'synchronous' here, for example an I2C bus is clocked by the master, ignoring clock stretching and that clock need not be in any way synchronous with the processor clock on the slave.

And to clarify, we're talking about PHY level protocol clocks here, not time clocks.

Check out PTP, and then the WhiteRabbit research project. It's not exactly easy to implement, but you can get down to ~10ns sync on an ethernet network using it.

I doubt they can just toss an atomic clock on the plane :)

As I understand it, an early variant of the TCAS system for collision avoidance did just that. Every aircraft would have a Cs or Rb standard that was synchronized to a master clock, and they'd broadcast their position and altitude at an assigned time slot.

This would have been very expensive at the time (late 60s-early 70s?) they were proposing it, and it would only have worked if everyone had the necessary equipment. So it didn't fly. But in later decades it was no big deal to put a high-quality atomic time/frequency standard onboard an aircraft, and I wouldn't be surprised if most large airplanes actually do carry a Rb standard for one reason or another.

Edit: the proposed system was called EROS: http://www.allstar.fiu.edu/aero/tcas.htm

I think the image a lot of us have is that an atomic clock is a PC-to-dishwasher-sized box. Rubidium standards are smaller than that but less accurate than the lab grade equipment.

You don't really need to toss an atomic clock on the plane. Just make the plane use GPS.

Where one of the tricky parts comes in, is in distributing this clock signal to all portions of the avionics system that need it. But that's beside the point.

It doesn't really sound like a timing skew problem (as in, a problem with making all systems recognize the same time simultaneously) but rather with making sure that all relevant information needed to construct a coherent 'picture' from all sensors reaches the core processors in a timely manner.

You can't provide a real time display if, say, your radar data is delayed for a significant period of time due to problems or instabilities with the radar's onboard processor.

> You don't really need to toss an atomic clock on the plane. Just make the plane use GPS.

These are warplanes - you don't want critical systems reliant on satellites that could be jammed, or downed, during wartime, which I suspect is why they don't do this already.

But fighters do use GPS. Daily. They use it for accurate navigation. But they do not absolutely depend on it.

> But fighters do use GPS. Daily. They use it for accurate navigation. But they do not absolutely depend on it.

But...

>>> Just make the plane use GPS.

...implies you would make them absolutely depend on it. Military aircraft use GPS daily, because it's cheaper and better. However, they also have accurate inertial navigation systems as a backup, so they can still operate effectively if the enemy makes GPS unavailable.

Reply on news.ycombinator.com