Remco.org

Seductive serendipity / Verleidende serendipiteit

November 29th, 2013

CQWW CW 160m 2013

During 23/24 November I participated in the CQWW CW contest on 160m.

Look here for a report.

November 3rd, 2013

Raspberry Pi Time Keeping

Yes… a few weeks ago I bought a Raspberry Pi (Raspi) at a HAM radio flea market.

The Raspi + casing was offered for 49 Euro’s, and I couldn’t resist, despite the fact
that it may be obtained a little cheaper. I saw the Raspi and thought: “I got to have it!”
Why? It gave me the ZX-81 feeling : -)

In 2013 with modern technology, going 30 years back in time! Who experiences that?

Because of its power consumption the Raspi seems a good candidate to replace the FreeBSD
machine of ntp.remco.org, providing the internet stratum 1  NTP  packets for nearly 7 years.

I followed the Raspi cook book recipes here and/or here but encountered some issues as my
GPS locked PPS signal (delivered by ntp.remco.org) did not generate a lock on the Raspi.

My ‘externa’l PPS signal is inverted, i.e. epochs on the falling edge of the pulse, and the kernel
GPIO-patch does not implement this (yet). After ‘reinverting’ the signal with a transistor
I obtained remarkable good time stamps with +/- 3 usec drift using the ATOM driver (nr. 22).

My goal is to make the Raspi a standalone system which performs at least as good as my
FreeBSD machine. Thus, the Raspi had to be enriched with its own GPS receiver.
I found a spare Oncore UT+ and after some (software) fiddling I managed to get it work.

The following assumes that ntpd is compiled with –enable-oncore and –enable-atom in the ./configure string.


Hardware issues.

Well behaved as I am, I initially interfaced the Oncore to the Raspi using transistors both as inverters
and levelling devices (3.3 <> 5V). After running ntpd it simply refused to accept the Oncore driver (nr.30).

No traffic appeared on the serial interface (/dev/ttyAMA0) of the Raspi, verified with
Picocom and an oscilloscope. I had PPS stamps though, as verified with ppstest /dev/pps0.

I suspected a broke Oncore, or an improper configured serial interface.

After connecting a cheap NMEA device (through inverters) to the Raspi I saw
traffic. However, instead of understandable NMEA strings I got rubbish.

Connecting Raspi’s RXD and TXD with a jumper resulted in proper echoes in picocom,
thus the interface itself was okay.

Due to the NMEA-rubbish I suspected polarity of the signals.

Reconnecting the Oncore without inverters was the solution, and now ‘interfaces’ the Oncore
to the Raspi in a ridiculously simple manner, see picture below (click on image to enlarge).

Figure 1. Interfacing a Motorola Oncore GPS module to a Raspberry Pi.

No inverters or buffers are necessary, the only thing which has to be done is levelling the
outputs of the Oncore towards 3.3V, by resistors with a  ratio of 3.3 / 5 = 0.66, e.g. 1k5 vs 2k2.

TXD of the Raspi is fed directly into the RXD pin of the Oncore.

 

Ntpd issues.

There was another reason why ntpd refused to accept the Oncore driver (nr. 30).
It took me some time to find out why. I used a copy of /etc/ntp.oncore.0 from my other
machines, which are interfaced to Oncores through RS232-ports and inverters/drivers.

I overlooked an /etc/ntp.oncore.0 entry, defining the required PPS signal polarity to acknowledge interrupts.
It was CLEAR, but had to be ASSERT (because now I didn’t use inverters).

After fixing this, the Raspi was up and running with its own Oncore GPS.

Initially ntpd gave rubbish offsets, but after a while it locked, and I could keep track within +/- 4 usec.
My previous LinuxPPS systems (i386) were within +/- 10 – 15 usecs or so.

FreeBSD ‘off the shelf’ is comparable to what I got from this Raspi setup. Promising!

However, with ntpdc (ntp development team, please keep ntpdc in the ntp distribution!)
I saw that the ppsfreq and ppstime bits were not set:

ntpdc -c kern
pll offset:           -1.14e-07 s
pll frequency:        -37.303 ppm
maximum error:        0.001385 s
estimated error:      1e-06 s
status:               2001  pll nano
pll time constant:    4
precision:            1e-09 s

Status is ’2001′ instead of ’2007′. I am not that an expert, but I suspect that the
Oncore driver (nr.30) does not acknowledge the GPIO PPS stamps/interrupts?
But for whatever reason the kernel keeps on track relatively well, according to ntpq -p  (?) :

ntpq -p
remote           refid           st t when poll reach   delay   offset  jitter
==============================================================================
oGPS_ONCORE(0)   .GPS.            1 l   13   16  377    0.000   -0.001   0.002
+ntp.nmi.nl      .PPS.            1 u   45   64  377   19.272   -3.139   0.224
+chime6.surfnet. .PPS.            1 u   26   64  377   18.996   -2.960   0.329
*ntp1.nl.uu.net  .PPS.            1 u   14   64  377   18.963   -3.469   0.406

It’s the first time I see the Oncore driver (nr.30) with a preceding ‘o’, suspecting the Oncore driver not
assimilating my PPS time stamps properly. As I am more into hardware than software I contacted
(one of) the author(s) of the Oncore driver, but did not hear anything from him yet …

As I had good results (i.e. status is ’2007′) using a  PPS signal ‘borrowed’ from my FreeBSD machine,
I tried to use the ATOM driver (nr.22) in conjunction with the Oncore driver.

When the Oncore driver is ‘preferred peer’, ntpd gets confused. There is no lock within usec range,
and sometimes both the ATOM and Oncore drivers are considered ‘outliers’.

An alternative, at least suggesting that ppsfreq and ppstime are set, is using an external ntp server as
‘preferred supplier’ and downgrading the Oncore driver to a lower stratum. After some time this looks like:

ntpdc -c kern
pll offset:           -7.59e-07 s
pll frequency:        -38.533 ppm
maximum error:        0.003235 s
estimated error:      0 s
status:               2007 pll ppsfreq ppstime nano
pll time constant:    4
precision:            1e-09 s
frequency tolerance:  500 ppm

ntpq -p
remote           refid           st t when poll reach   delay   offset  jitter
==============================================================================
oPPS(0)          .PPS.            0 l    4   16  377    0.000   -0.001   0.002
xGPS_ONCORE(0)   .GPS.           15 l    7   16  377    0.000   -0.001   0.002
+ntp.nmi.nl      .PPS.            1 u   44   64  377   19.648   -2.940   0.166
+chime6.surfnet. .PPS.            1 u   36   64  377   18.947   -2.912   0.528
*ntp1.nl.uu.net  .PPS.            1 u    9   64  377   19.188   -2.872   0.172

For whatever reason ntpd considers the Oncore driver an outlier (?), indicating for me that there
might be an ‘issue’ with the Oncore driver in conjunction with the bcm2708 kernel GPIO patch.

 

Thermostat (1)

The processor clock crystal of my FreeBSD ntp machine is thermostatised to make the whole
clock generation (PLL) circuit, and thus ntpd, less sensitive to (ambient) temperature variations,
as I published five years ago. For the Raspi I initially thought of something very simple:

Heating the clock crystal (19.2 MHz) to around 36 ‘C with a ‘super glued’ PNP transistor to make
ambient temperature variations relatively ‘small’. I could not get higher than around 36 ‘C with 100 mA extra
current, which is significant ‘additional current’, relative to the total Raspi power consumption!
The circuit diagram and practical implementation are shown below (click on images to enlarge).

Note: base resistor in this picture is 21k5, later it was changed to 16k9 to obtain a crystal temperature of ~36 ‘C.
Note: last mentioned ntpdc/ntpq results are with heater, resulting in ca. 1 ppm lower PLL offset.

Stability of the PLL frequency looked good at first glance. However, when my central heating system becomes active,
ntpd has some difficulties keeping its frequency stable enough for me.

Below frequency responses of the Raspi (left) and FreeBSD (right) during the same period and environmental conditions are visualised.

 

The corresponding offsets are depicted below:

 

Although the results are relatively good, improvement is desired.

 

Thermostat (2)

Of course the former circuit is not a thermostat as it lacks feedback. The circuit and implementation on the Raspi below
depict a very simple thermostat. Around 110 mA current is drawn, resulting in ca. 38 ‘C crystal temperature (click on images to enlarge).

 

I just powered up the Raspi, let’s wait how performance is now.

Hopefully not ‘to be continued’ ;- )

|