tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pulse-per-second API status



Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>> * ucom(4) needs pps support
>
> It does?  I thought USB introduced delays which are both uncertain and,
> in this context, large, and thus doing PPS on a ucom "didn't work" (in
> that it inherently produces exactly the sort of symptom described -
> basically, a recipe for bad timekeeping).
>
> Am I wrong in thinking that?

Well, maybe not wrong but unnecessarily absolutist (shocking, coming
From you :-).  But seriously:

The delays introduced by USB are said to be on the order of 1 ms.  So it
depends on whether 1 ms of fuzz is "doesn't work".  I would say that if
the next best option is worse than that (nmea timecode over the same
USB, or asymmetic delays over the Internet), then it does work, even if
a real serial port would be better.

My situation is that I'm seeing goofy asmmetry over FIOS to various
places on the Internet, and thus don't know what to believe in terms of
time at the 10ms level.  So if PPS over ucom(4) had 1 ms error, that
would be a huge improvement.  That may then provoke me to warm up the
soldering iron and hook up a rs232 level converter from an old gps
evalkt I have that has pps.  But these GR601-W devices are awfully
convenient (ublox6 with PPS wired to DCD of a PL2303).





Attachment: pgp4pEDgMn1hV.pgp
Description: PGP signature



Home | Main Index | Thread Index | Old Index