Hi

They may have some odd setting deep in the scpi to get the log over to this or that time frame. I’d have thought that UTC would be the obvious choice. It also could just be a bug.

Bob

On Sun, Dec 7, 2014 at 9:25 AM, Bob Camp kb8tq@n1k.org wrote:

Initially they were in sync.  I hope this power "accident" didn't break
anything beyond causing time to briefly jump backwards.

Log 037:20141201.00:25:47:  GPS reference valid at 20141202.01:47:41
Log 038:20141202.01:48:45:  Locked mode entered
Log 038:20141201.00:00:00:  Power on
Log 039:20141201.00:00:00:  Power on
Log 040:20141201.00:00:17:  Power settings ok, Int: 17 dBm, Ext: 17 dBm
Log 041:20141201.00:02:13:  EXT reference valid
Log 042:20141201.00:03:14:  EXT lock started
Log 043:20141201.00:25:42:  GPS reference valid at 20141202.01:47:36
Log 044:20141202.01:48:41:  Locked mode entered

Hi

Oh, ok.

Any time you have a power “burp” the clock will start back at what ever it thinks was the time was last.

That sounds simple. It’s not.

If you want to save your eeprom or flash from burnout, you don’t write “it’s now ..” once a second. If you do, things die fairly quickly. I have empirical data (and a pile of 53131’s) to prove this. You write your magic bytes much less often. What likely happened is you are inside the granularity of that write process.

Bob

On Sun, Dec 7, 2014 at 10:26 AM, Bob Camp kb8tq@n1k.org wrote:

I understand this.

I was referring to:

These two events were at least an hour apart.  The second one (1:47:36)
does not precede the first (1:47:41).

If "GPS reference valid" doesn't mean the Oncore thinks time is valid
that's okay but it only happened once and there have been multiple power
resets.  Just no others that (accidentally) happened within ~20 seconds
(the POST window I assume) of each other.

I'll wait a few days and do another power reset now that I'm ready for
concurrent monitoring of both units.

By the way the time glitch was only logged on REF 1.

Snippet showing the system adopting the bad time stamp:
Log 037:20141201.00:25:47:  GPS reference valid at 20141202.01:47:41
Log 038:20141202.01:48:45:  Locked mode entered
Log 043:20141201.00:25:42:  GPS reference valid at 20141202.01:47:36
Log 044:20141202.01:48:41:  Locked mode entered

Hi

If the magic “write the time to flash” routine runs once every 2 hours, then that would explain the log. Numbers like 4 or 8 times a day are not uncommon for this sort of thing.

Bob

On Sun, Dec 7, 2014 at 2:05 PM, Bob Camp kb8tq@n1k.org wrote:

I'm being unclear.  If you look at a Z3811 log you'll see that the
timestamps immediately after [GPS valid] are now GPS time -- prior to [GPS
valid] they're deltas from the previous midnight.  This happens with
various power reset intervals (I've fiddled) unless, at least in one case
for me, the power reset happens less than ~20 seconds after the last one
i.e. before [Power settings ok].  Also based on my experience the "bad"
[GPS valid] message, unlike the others, isn't propagated to the Z3812 log.

I'm not sure I want to conduct the rapid reset experiment to see if this
was a glitch, bug or feature.

Hi

Here’s what I’m suggesting:

The local time is updated after the GPS Valid hits the log. Put another way, the time used for the log is not corrected to GPS time until after the valid message is logged.

Bob

On Sun, Dec 7, 2014 at 3:07 PM, Bob Camp kb8tq@n1k.org wrote:

And I completely agree with you.

My point is the [GPS valid] timestamp that's part of the [GPS valid]
message was at least 50 minutes off.  Just the one time.  Maybe the
timestamp associated with this message:

GPS reference valid at 20141202.01:47:41

(01:47:41 in this case)  as opposed to the Log timestame (00:25:47 in this
case) is a random time that just happens to typically appear to be the
current GPS time but that seems odd.  However the system makes it just a
bit tricky to compare box time to UTC so maybe all the timestamps are bogus.

Log entry split into two lines:

Log 037:20141201.00:25:47  (00:25:47 is current Z3810 time)

GPS reference valid at 20141202.01:47:41 (01:47:41 is what I thought was
current GPS time.)

But if it is GPS time then this is a glitch:

Log 043:20141201.00:25:42 (00:25:42 is current Z3810 time, this log entry
is about 50 minutes after Log 037 above)

GPS reference valid at 20141202.01:47:36 (01:47:36 is obviously not current
GPS time)

Hi

That (and other log timestamp entry errors) is what leads me to believe that it is being “conservative” when it generates the timestamps. The log gets written before anything actually gets done.

Bob