Over the last couple of years I have looked at the LEA M8F, it is a GPSDO with 1 pps. not needing Saw Tooth correction. How ever its frequency output is not time-nut friendly. 10 MHz is only 5 E-9. An ebay post showed an 8F board with intriguing 24 MHz data. Juerg did some tests with an SI 5351 at 24 MHz. Spec is 25 to 27 MHz but his tests at 24 MHz shows 10 MHz at 1 E-12. So I bought some, one on the way to Switzerland. Also made some of our heavies aware of our work. The seller initially was not going to make more boards but changed his mind. I suspect the parts a pulls and he has to make boards to make sure the F8's work. My goal is to use it for aging tests always use 24 to 48 hour average testing. See my attached results exceed my expectations. 2.39 E-13 mean! Will update once Juerg has his unit and uses a SI 5131 to generate 10 MHz. I can use the 24 MHz it is a true representation of the GPS signal. Can also use other GNS signals. Leave that up to others. Bert Kehren
One more comment thank you Juerg for all the data analysis. Bert Kehren In a message dated 1/27/2021 7:33:09 AM Eastern Standard Time, time-nuts@lists.febo.com writes:
Over the last couple of years I have looked at the LEA M8F, it is a GPSDO with 1 pps. not needing Saw Tooth correction. How ever its frequency output is not time-nut friendly. 10 MHz is only 5 E-9. An ebay post showed an 8F board with intriguing 24 MHz data. Juerg did some tests with an SI 5351 at 24 MHz. Spec is 25 to 27 MHz but his tests at 24 MHz shows 10 MHz at 1 E-12. So I bought some, one on the way to Switzerland. Also made some of our heavies aware of our work. The seller initially was not going to make more boards but changed his mind. I suspect the parts a pulls and he has to make boards to make sure the F8's work. My goal is to use it for aging tests always use 24 to 48 hour average testing. See my attached results exceed my expectations. 2.39 E-13 mean! Will update once Juerg has his unit and uses a SI 5131 to generate 10 MHz. I can use the 24 MHz it is a true representation of the GPS signal. Can also use other GNS signals. Leave that up to others. Bert Kehren_______________________________________________
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi Bert --
That's very interesting. Can you explain a bit more about how you are
generating the 24 MHz and the role of the Si5351?
I took a close look at the M8F a year or so ago, looking at PPS and the
30.72 MHz output it makes directly available:
PPS jitter is very, very good compared to other single-frequency
receivers -- it's about the same as the dual frequency ZED-F9. However,
there is no sawtooth correction available to deal with the jitter that
remains. When you look at the M8F PPS vs. M8T with sawtooth correction,
the results are about the same.
The internal 30.72 oscillator seems to be adjusted with a sort of
PWM control -- it does a bang-bang of about +/- 3e-10 around the true
frequency, getting the average frequency correct by spending more or
less time above or below nominal. (See attached.)
It's an interesting question whether you could get better results
disciplining an external oscillator, but I think that would depend on
the DAC sensitivity and whether the PLL time constant was appropriately
set (see point 4).
One considerable disadvantage to using the M8F as a GPSDO is that
there doesn't seem to be any way to adjust the loop time constant (or
even to know what it is). The only adjustable parameter I've been able
to find is the EFC sensitivity.
On 1/27/21 7:27 AM, ew via time-nuts wrote:
Over the last couple of years I have looked at the LEA M8F, it is a GPSDO with 1 pps. not needing Saw Tooth correction. How ever its frequency output is not time-nut friendly. 10 MHz is only 5 E-9. An ebay post showed an 8F board with intriguing 24 MHz data. Juerg did some tests with an SI 5351 at 24 MHz. Spec is 25 to 27 MHz but his tests at 24 MHz shows 10 MHz at 1 E-12. So I bought some, one on the way to Switzerland. Also made some of our heavies aware of our work. The seller initially was not going to make more boards but changed his mind. I suspect the parts a pulls and he has to make boards to make sure the F8's work. My goal is to use it for aging tests always use 24 to 48 hour average testing. See my attached results exceed my expectations. 2.39 E-13 mean! Will update once Juerg has his unit and uses a SI 5131 to generate 10 MHz. I can use the 24 MHz it is a true representation of the GPS signal. Can also use other GNS signals. Leave that up to others. Bert Kehren
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hello,
I have been playing lately with the M8F, but did not had a detailed look
to the 30.72MHz frequency as John did. I have used it along with a
Zynq-based board (a very unexpensive surplus EBAZ4205, that can be get
for ~10 EUR) to made an ntp server, replacing the kernel clocksource
from the ARM timer with an external timer implemented at the FPGA
running from the 30.72MHz output (multiplied inside the FPGA to 250MHz),
and using that counter to provide the PPS timestamps, in order to
eliminate any software jitter due to interrupt latencies.
I have been using chrony instead of ntp. The PPS timestamps are almost
ever ending in .000000000:
1611817180.000000000#94736
The result of chornyc sources is:
210 Number of sources = 8
MS Name/IP address Stratum Poll Reach LastRx Last sample
---=============
#* GPS 0 0 377 1 +0ns[ +0ns] +/-
901ns
^- 10.0.2.24 1 3 377 6 +124us[ +124us] +/-
1335us
10.0.2.24 is a RPi-based ntpd. Both the adjusted offset and the measured
offset are ever 0ns, and the estimated error stucks at 901ns, that I
think that is something like a chrony floor (I have seen it drop to zero
along time with other chorny version)
After a short time from boot, the results of the tracking command are:
Reference ID : 47505300 (GPS)
Stratum : 1
Ref time (UTC) : Thu Jan 28 06:53:36 2021
System time : 0.000000000 seconds fast of NTP time
Last offset : +0.000000000 seconds
RMS offset : 0.000000000 seconds
Frequency : 0.000 ppm slow
Residual freq : +0.000 ppm
Skew : 0.000 ppm
Root delay : 0.000000001 seconds
Root dispersion : 0.000002380 seconds
Update interval : 1.0 seconds
Leap status : Normal
All offsets 0 :)
So although it does not seem optimal for a GPSDO, it looks nice for
applications like this (only caveat is that the M8F price is around 8x
the FPGA board price... :) )
Regards,
Javier, EA1CRB
On 27/1/21 16:09, John Ackermann N8UR wrote:
Hi Bert --
That's very interesting. Can you explain a bit more about how you are
generating the 24 MHz and the role of the Si5351?
I took a close look at the M8F a year or so ago, looking at PPS and
the 30.72 MHz output it makes directly available:
1. PPS jitter is very, very good compared to other single-frequency
receivers -- it's about the same as the dual frequency ZED-F9.
However, there is no sawtooth correction available to deal with the
jitter that remains. When you look at the M8F PPS vs. M8T with
sawtooth correction, the results are about the same.
2. The internal 30.72 oscillator seems to be adjusted with a sort of
PWM control -- it does a bang-bang of about +/- 3e-10 around the true
frequency, getting the average frequency correct by spending more or
less time above or below nominal. (See attached.)
3. It's an interesting question whether you could get better results
disciplining an external oscillator, but I think that would depend on
the DAC sensitivity and whether the PLL time constant was
appropriately set (see point 4).
4. One considerable disadvantage to using the M8F as a GPSDO is that
there doesn't seem to be any way to adjust the loop time constant (or
even to know what it is). The only adjustable parameter I've been
able to find is the EFC sensitivity.
On 1/27/21 7:27 AM, ew via time-nuts wrote:
Over the last couple of years I have looked at the LEA M8F, it is a
GPSDO with 1 pps. not needing Saw Tooth correction. How ever its
frequency output is not time-nut friendly. 10 MHz is only 5 E-9. An
ebay post showed an 8F board with intriguing 24 MHz data. Juerg did
some tests with an SI 5351 at 24 MHz. Spec is 25 to 27 MHz but his
tests at 24 MHz shows 10 MHz at 1 E-12. So I bought some, one on the
way to Switzerland. Also made some of our heavies aware of our work.
The seller initially was not going to make more boards but changed
his mind. I suspect the parts a pulls and he has to make boards to
make sure the F8's work. My goal is to use it for aging tests always
use 24 to 48 hour average testing. See my attached results exceed my
expectations. 2.39 E-13 mean! Will update once Juerg has his unit and
uses a SI 5131 to generate 10 MHz. I can use the 24 MHz it is a true
representation of the GPS signal. Can also use other GNS signals.
Leave that up to others.
Bert Kehren
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
On Thu, Jan 28, 2021 at 1:34 AM Javier Herrero jherrero@hvsistemas.es wrote:
I have been playing lately with the M8F, but did not had a detailed look
to the 30.72MHz frequency as John did. I have used it along with a
Zynq-based board (a very unexpensive surplus EBAZ4205, that can be get
for ~10 EUR) to made an ntp server, replacing the kernel clocksource
from the ARM timer with an external timer implemented at the FPGA
running from the 30.72MHz output (multiplied inside the FPGA to 250MHz),
Would this mean any timestamps generated via
clock_gettime(CLOCK_MONOTONIC_RAW) are going to be directly derived
from the value of your FPGA timer? Because if that is the case, then
isn't the PPS phase offset from the system clock effectively the phase
offset of the GPS to the GPS? I.e., it's zero because the same clock
is being compared to itself?
Hello,
On 28/1/21 11:05, Trent Piepho wrote:
On Thu, Jan 28, 2021 at 1:34 AM Javier Herrero jherrero@hvsistemas.es wrote:
I have been playing lately with the M8F, but did not had a detailed look
to the 30.72MHz frequency as John did. I have used it along with a
Zynq-based board (a very unexpensive surplus EBAZ4205, that can be get
for ~10 EUR) to made an ntp server, replacing the kernel clocksource
from the ARM timer with an external timer implemented at the FPGA
running from the 30.72MHz output (multiplied inside the FPGA to 250MHz),
Would this mean any timestamps generated via
clock_gettime(CLOCK_MONOTONIC_RAW) are going to be directly derived
from the value of your FPGA timer? Because if that is the case, then
isn't the PPS phase offset from the system clock effectively the phase
offset of the GPS to the GPS? I.e., it's zero because the same clock
is being compared to itself?
Basically yes, the CLOCK_MONOTIC_RAW is derived from the counter, but
this counter starts at zero and increases at the clock rate, so it is
relative to the boot time. The 30.72MHz ciock from the M8F is
disciplined to the GPS, so it is expected that the timestamps for the
PPS signal from the GPS are each 250e6 counts exacty (and they are,
sometimes one count more or less as far as I have looking to it). Chrony
takes initailly the time from other source (e.g. a ntp server - because
I have not yet implemeted to take the time from the GPS), so initially
calculates an offset from the monotonic clock to the realtime clock
based on the time gathered from the external server, and then uses the
PPS timestamping to align the realtime clock to the PPS timestamps - as
usual in any ntp/chrony based GPS ntp server. But since the oscillator
is disciplined, there is no drift (at least no long term drift), so the
drift calculated by chrony converges to zero, and ends applying only an
offset in the conversion from the monotonic raw clock to real time. I
was playing with this concept mainly to avoid the jitter and error in
the SW PPS timestamping, since I had the board and the M8F at hand, and
some spare time to play with (that is not very usual...).
Best regards,
Javier
Javier Herrero
Chief Technology Officer EMAIL: jherrero@hvsistemas.com
HV Sistemas S.L. PHONE: +34 949 336 806
Teide 4, Núcleo 1 Of. 0.1 FAX: +34 949 336 792
28703 San Sebastián de los Reyes - Madrid - Spain WEB: http://www.hvsistemas.com