On 29/04/2014 09:41, Rob wrote: []
Of course that is what we have. E.g. on a prototype here at home:ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oPPS(0) .PPS. 0 l 2 16 377 0.000 0.000 0.000 xSHM(0) .GPS. 0 l 1 16 377 0.000 7.682 0.152 *SHM(1) .PPS. 0 l 16 16 377 0.000 0.008 0.001 PPS(0) is a PPS input from a professional GPSDO connected to a COM port, SHM(1) is another GPS receiver interfaced via gpsd. Just to see how close they get and remain. Not Raspberry Pi (yet) but normal PC systems, but I know it is possible to get the system time within the desired 12 microseconds. Unfortunately that is not the same as performing some task like outputting audio at an accuracy of 12us, but that is the next challenge :-)
Indeed, and you will likely want to look at very matched systems (PCs and transmitters - the whole chain), and having the minimum latency in the OS. I'm not familiar enough with Linux to know which variant to recommend, or whether FreeBSD or some other OS might be better.
When comparing, be aware that there can be significant delays in things like RS-232 level converters etc., especially if they have rise-time limiting. Not to mention any delays in the COM port control lines!
It sounds an interesting project. -- 73, David GM8ARV Web: http://www.satsignal.eu _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
