Reference clocks.

[Amar Takhar]

On 2016-04-08 20:44 -0700, Hal Murray wrote:
> I haven't had any troubles with serial ports.  (other than not finding them 
> on modern systems)

Individually they're fine.  Once you start scaling and doing testing they can be 
pretty frail.  I spent a lot of time fighting bad serial ports, drivers and 
cables than I care to think about.


> There is a potential problem with feeding a "TTL" signal into a RS-232 
> receiver.  3V CMOS signals may not be high enough voltage to cross the 
> threshold.  I think the threshold is usually 1.4V, but I doubt if it's in the 
> specs.  It's clearly cheating and something to keep an eye on, but I haven't 
> had any problems.

I have plenty of parts here to solve those issues. :)  Thanks for the reminder.


> There is a problem with the typical 10 to 20 microsecond PPS pulses from 
> GPSDOs.  They aren't wide enough and/or the driver is buggy.  The GPIO code 
> may be simpler and cleaner and less likely to miss short pulses.  You can get 
> a pulse stretcher from TAPR.

I've never had an issue with short pulses using this method.  Keep in mind I'm 
using this as my 'cheap' method for deployment.  I want to scale this up to 50 
units if I can to do a lot of parallel testing and longterm testing.  I'll be 
using the cheaper GPS signal generator to generate a predictable signal to test 
for longtime usage of ntpd.  This is why I want something more robust that I 
won't have to spend a lot of time figuring out why it's not working.  Plugging a 
board directly into the GPIO pins of an RPI has proven to be very stable in the 
past.


> Even if you broadcast the same GPS data, there is noise in the system and 
> edge cases may not get the same results.  Even if the GPS unit spits out the 
> exact same text strings the timing may be slightly different in interesting 
> ways.

There can be quite a few differences actually.  The nice thing about repeatable 
tests is those differences express themselves in a pattern that you can account 
for.  When you have that you can pickup deviations and mark them as a failed 
test / further investigation.


> Going in at the GPS level lets you test the Kernel.  That's got to be worth 
> something.

That's the plan!  I don't think anyone has done this type of in-depth testing of 
different devices before.


> If you also run in record mode, we can save interesting patterns for 
> regression testing at places other than your site.

If someone wants me to record data I'm happy to do that.  The purpose of this 
testing system is allow for describing the tests in a database and track the 
results as development moves.  When you record data you make the assumption the 
data being recorded is correct I am working on covering all cases up to and 
after that point so it could be useful to record all the streams and archive 
them.


Amar.