[time-nuts] jupiter-t tu60-d120 (maybe d125), pinguino and GPSDO
tshoppa at gmail.com
Tue May 20 16:42:40 UTC 2014
+/-1 error in last digit of a frequency counter is known as "bobble" and is
inherent when the counter's gate and measured frequency are asynchronous.
On Tue, May 20, 2014 at 10:36 AM, Brett Owen Rees <breree at gmail.com> wrote:
> 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:
> 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
> 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