+/-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.
Tim N3QE On Tue, May 20, 2014 at 10:36 AM, Brett Owen Rees <bre...@gmail.com> wrote: > 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 > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.