IRIG-B over IP
rickman
IP. I was asked to design the interface circuit to demodulate the
IRIG-B signal and pass the bits to the rest of the system. The same
module at the other end has to then modulate an IRIG-B signal from the
bits.
I believe the interface details are well understood and should not be
a problem. However, as I was discussing this with the customer, they
realized that they did not know how to transport the actual time stamp
across the network.
You can think of the IRIG-B signal as having two parts; a data part
which tells you which second this is and a timing mark that tells you
"NOW" is the beginning of the second being described in the data
fields. I don't see how they can ever expect to transport the "NOW"
across an IP network.
I feel bad because I pointed this out to them and now if they can't
figure out how to make the system work, I will lose the job... :^(.
I guess that is better than building a board that won't work because
of system issues.
larwe
> You can think of the IRIG-B signal as having two parts; a data part
> which tells you which second this is and a timing mark that tells you
> "NOW" is the beginning of the second being described in the data
How much delay can you insert in this timing information? I would look
at existing applications for synchronizing two realtime clocks. Your
box should sync its RTC up to the target computer. Once the source and
target have precisely synced RTCs, I would have your box look at the
IRIG stream and tell the target end "At exactly 01:23:45.1234567 it
will be the NOW moment for second #1234".
Your target will need to buffer the input stream(s) enough to account
for worst-case latency on the IP network, but this system seems at
least back-of-an-envelope-after-a-hard-night's-drinking doable.
