[time-nuts] FE-5680A performance -- 5125

Bob Camp lists at rtty.us
Thu Jan 5 17:16:09 UTC 2012


Hi

I have seen a 5125 do random reboots on a "every few weeks" basis. I suspect
it's either a problem box or we have a power glitch that it's uniquely
sensitive to.

Bob

-----Original Message-----
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of John Miles
Sent: Thursday, January 05, 2012 10:35 AM
To: 'John Ackermann N8UR'; 'Discussion of precise time and frequency
measurement'
Subject: Re: [time-nuts] FE-5680A performance

> To get around this, you can use the TSC's frequency counter output which
> gives 14 or 15 digit measurements.  However, you need software to
> manually poll for the fcounter data, and you can't get precise tau from
> it since the updates don't seem to happen synchronously.  I ended up
> writing a perl script that grabs and logs the fcounter data every 10
> seconds by default, and that has worked well.

My guess is that their phase-difference output is a filtered version of the
full-bandwidth phase data generated for the PN display, as opposed to being
generated by running the raw I/Q data through a separate filter path and
doing the atan() operations at the final ENBW.   These strategies yield
similar but not quite identical results.  Any frequency calculations based
on sending the full-bandwidth phase data through the ENBW filter will be
off-kilter.  

It's true that their frequency counter display seems to be correct in all
cases, though -- if I'm right about the problem with the phase/freq
difference displays, they must be using a separate, correct filter path to
drive the frequency count chart.
 
Since TimeLab's frequency chart relies solely on the phase data stream, it
is vulnerable to the same error that you're talking about.  I don't attempt
to correct the data by reading the frequency counter or anything like that,
so yes, that's something to watch out for.  It caused me some
head-scratching.

Fortunately the error doesn't seem to be severe enough to distort the
phase-difference trace visibly, or to affect the ADEV and other plots.  It's
only an issue if you need accurate frequency readings.

> John, could you expand on your comment about the ethernet connection?  I
> have seen random instances where the TSC seems to lose its TCP/IP
> settings, but so far it's never happened during a measurement run, so
> has been annoying but manageable.

When I first wrote the code for Tom's 5120A, I noticed that the TCP
connection would sometimes get really sluggish, and occasionally be dropped
altogether.   Later TSC firmware allowed the data rate to be slowed down to
1, 10, or 100 readings per second instead of 1000, and I imagine that fixes
the problem entirely.  However, the TimeLab driver is still hardwired to
assume the data is coming in at 1000 samples/second.  

-- john
Miles Design LLC




_______________________________________________
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.




More information about the time-nuts mailing list