[time-nuts] jupiter-t tu60-d120 (maybe d125), pinguino and GPSDO

Brett Owen Rees breree at gmail.com
Tue May 20 10:36:24 EDT 2014


Hello,

I have been experimenting with a 10Mhz OCXO and a number of GPS units and
arduino/pinguino boards in order to build a gpsdo. The pinguino micro is
interesting, with it being a 32bit microchip pic32mx440 chip with a USB
interface to the computer. Based on arduino code I have seen on this list,
I have an interrupt routine which runs on the pps pulse and which checks
the value of a counter running from the 10Mhz ocxo (Morion MV89A), giving
me a nice frequency counter. I initially had it hooked up to a trimble
resolution t but the res t seems to have died (:<  I have to investigate
it's death further ... it appears to work but never sees any SVs when
hooked to my outside antenna, but worked on an inside antenna.  I removed
it from my ugly-style board.

As all of the above is 3.3V logic, I then tried it with a ublox neo6m
board. This works ok as well. However, even on an external antenna I kept
getting randomly  off by 1 on the frequency counter, which would then catch
up on the next reading. I take it that if the pps signal is off by more
than 100ns that this would cause this behaviour, or is it maybe my code? As
it is not a timing receiver is this to be expected? In the end I had the
OCXO trained via the 10bit DAC on the pinguino to the point where my old hp
5328A would show 10,000,000.0 or .1 or 9,999,999.9. I also tried to
replicate something I saw on here with the PPS and 1MHz (divided down by a
74hc390) being passed through a 4046, and then into an adc on the pinguino.
The idea was to use the frequency counter to get in the ballpark and then
use the 4046 to try to lock into the phase. But it all seemed very noisy.
All I could really see was that if the ADC output was increasing that the
OCXO was slow. I later worked out that I was dividing by 2 and then by 5
and so I did not have a 50/50 pulse. I have now fixed that. I also set the
ublox neo6m to a 0.001 ms timing pulse. Then I accidently touched the PPS
wire to ground and fried the PPS output. I though I had it powered off.
Doh. It still works at outputting NMEA so it has found a home in my APRS
setup in my car. These neo6m modules are very easy to use. I would love to
have a play with a neo6t but where to get one - they all look expensive.

Frustrated with this, I ran up a jupiter-t marked as TU60-D120 on the board
from ebay which came on a psu/74144/rs232 converter board marked www.amoj.cn.
However, on the board I could never get any serial output from it. I probed
with my CRO and could see serial data on the tx pin, so have rigged up a
TTL-rs232 board to my pc. Turned it on and get a ###Ea (or close to that
anyway)  output in putty. Some success! I then found the tac32 software via
this list and have that working. OK, so now I know that it uses Motorola
binary format, and that it has to be polled. Maybe that on-board serial
port was working??? I checked the receiver ID message and it tells me that
it is a TU60-D125 - which I can find no reference to when googling:

@@Cj
COPYRIGHT 1995-2004 NAVMAN LTD.
SFTW P/N # 0000
SOFTWARE VER # 93
SOFTWARE REV # 07
SOFTWARE DATE  01/16/2004
MODEL #    R01
HDWR P/N # TU60-D125
SERIAL #   307153696
MANUFACTUR DATE 301//42070
OPTIONS LIST    5843
---------------------------------
@@Ha Timeout - not a 12-channel Rcvr
@@Ea OK - must be an 8-channel Rcvr
@@Bh Timeout - must be a non-DGPS Rcvr
@@Aw Time Correction Mode UTC
@@At Position Hold Mode DISABLED
@@Ag Elevation limit set to 5 degrees
@@Ea OK - must be an 8-channel Rcvr
@@En - RAIM (8-ch) DISBLED, limit = 1000 nsec, 1PPS is ON always. Sawtooth
= 00.00, One-Sigma Accuracy = 10
@@En OK - must have T-RAIM

I put it via the tac32 sw into precision timing mode, and then started a
self survey. After 24 hours it went into position hold mode. So, now I
should have a better pps with which to work. When this completed I set the
reference position from current.

I then powered it off and then started it up again. I expected that it
would go back to position hold mode based on the stored reference position?
But it seemed to start, go to position hold for about a minute and then
went back to 'navigating'? Am I going to have to tell it to do a
self-survey each time it is powered on in order to get it to enter position
hold mode 24 hours later? It seemed to remember the reference position ok.
Or if I leave it long enough will it eventually switch to position hold
mode?

My plan with the jupiter-t is to use the 10KHz output to phase lock against
the divided down 10MHz with a 4046 - I think it is described as the 'super
simple' gpsdo. I consider this a 'back to basics' approach.  I will use the
pinguino for system monitoring - it has various 10bit ADCs and DACs etc,
and to place the GPS into position hold mode. At least then I should end up
with a 10MHz reference to start my time nut journey.

If anyone else wants to have a go with a pinguino I am happy to elaborate
more. It is not the most robust/best documented/easy to set up dev env
platform but does seem to have horsepower, running at 80Mhz, and is cheap.
I would also be interested in meeting up with anyone in Perth who may be a
fellow time nut.

Thanks,
Brett VK6EZ


More information about the time-nuts mailing list