Hi Henrik,
I've been doing some more reading regarding the NMEA string from the Rockwell datasheets. (19 pages in one 142 in other !)
I've discovered two choice bits.
(1.) The string is always after the event, so is 1 second late as you said.
(2.) Standard laid down for time this way is up to +/- .9 seconds regardless of (1.) above.
Rockwell do a binary protocol at 9600 baud which is 'message' driven. So you can actually poll for time separately with far more accuracy but it would require a complete code rewrite.
I'm trying to keep code tight in the BigClock sub which only reads the h, m, s, part of string. This is at beginning of the string anyway. I update in reverse to display, s m h.
At the moment I've added 2 seconds before display and with the other code changes, it's as near as I can see visually using the PPS LED. It is almost on the PPS event. That is near enough for me. Checking against MSF radio time signal using Spectrum Lab software, it's very close.
Visually humans can discern a 250ms difference, so as I can hardly see any difference, it should be closer than 250ms diff.
I could load the output into SpecLab to compare both signals I suppose. I may eventually do that anyway as I'm curious to what the code timing is.
I have the frequency lock part spot on, so it would be nice to get the time part as well, but I don't think its possible.
For my sins, in my other life I am an official timekeeper, timing to hundredths of a second. I can see '100ths differences there ok
Amazing really how many times a day I see exactly the same time to the hundreth of a second, two competitors achieve.
Another idea, but I suspect will gain nothing is :-
Read string full time once at start up.
Display
loop:
Then read only seconds.
Increment software clock s m h
update display
loop
String read would be very quick. Approx 20ms.
EDIT:
Just realised that at 20ms I would have read h m s anyway, so pseudo code above is pointless.
Bookmarks