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

Michael Jensen mriisj at danamps.dk
Tue May 20 18:16:28 UTC 2014

Hi Bret

I did a design some years ago with the TU30/TU60/TU120 used as GPSDO for the
OZ7IGY beacon project, I have a software packet and instructions to turn the
Motorola output to NMEA I can email you.

If you chose to go on with the TUxx GPSDO I can supply you with a PCB.

OZ7IGY Project info: http://rudius.net/oz2m/ngnb/index.htm

Michael, OZ2ELA

-----Oprindelig meddelelse-----
Fra: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] På vegne
af Brett Owen Rees
Sendt: 20. maj 2014 16:36
Til: time-nuts at febo.com
Emne: [time-nuts] jupiter-t tu60-d120 (maybe d125), pinguino and GPSDO


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
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:

SFTW P/N # 0000
SOFTWARE DATE  01/16/2004
MODEL #    R01
HDWR P/N # TU60-D125
SERIAL #   307153696
@@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

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.

Brett VK6EZ
time-nuts mailing list -- time-nuts at febo.com To unsubscribe, go to
and follow the instructions there.

More information about the Time-nuts_lists.febo.com mailing list