Hi > On Jul 18, 2016, at 12:19 PM, David J Taylor <[email protected]> > wrote: > > I suppose it is one of those cases where, the GPS designers decided you > shouldn't ever use the serial data for sub-second timing, and consequently > spent no effort on serial latency and jitter. > > Most UARTs I have come across have been synthesized with a 16x baud clock > and included flow control. It would not have been too much effort to spec > latency as some mu ±100 ns and jitter of ±1/(16*baud). > > For 9600 baud, the jitter on the start bit would be ±6.5 us. > > If CTS was resampled a 1 full bit time (9600 baud), the jitter would > be ±104 us. > ============================== > > Scott, > > You're right about the design priorities (and we have had to take Garmin to > task on this, but they did fix the problem), but it's not the UART which is > the major problem, but that the tiny CPU inside is taking a variable amount > of time to have the serial data ready. We're talking tens, possibly hundreds > of milliseconds peak-to-peak jitter.
….. but …. It’s been a long time since 9600 baud was a fast baud rate. It is pretty common these days to run at 115K baud on something like this. Indeed a number of GPS modules will only run at that speed or faster if you want the full feature set to work. Most modern modules will run much faster than 115K if you want them to. The simple fact that they need the higher baud rate to get all the data out forces a better serial i/o approach in a modern module. In order for sawtooth correction to work, the relation of the serial message to the pps needs to be pretty well defined. It either is talking about the *next* pps or about the *prior* pps edge. If it is ambiguous relative to the pps, you can not be sure of what it is relating to. If the module has a pps out and has sawtooth correction (or uses the same code base as one that does), the serial timing string is not going to be all over the place. They no longer are running itty bitty CPU’s in these things. ARM’s running at >= 400 MHz are the typical approach these days. Running out of clock cycles to get it all done went away at least 5 years ago and more like 10 years for the “usual suspects” that you see in timing applications. Can you still find a 20 or 30 year old module on eBay that has issues? Sure you can. It’s not what I would call a modern part, even if it is being sold as “new in box”. Can you find modules that simply do not keep time at all? Sure you can. That’s not the serial port’s fault. It’s the fact that that specific module is broke. Don’t use that one, move on. Bob > > Cheers, > David > -- > SatSignal Software - Quality software written to your requirements > Web: http://www.satsignal.eu > Email: [email protected] > Twitter: @gm8arv > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
