[GPS_Standard] Problem with v4, where can I get v3 to try?

[Bert, VE2ZAZ]

Hi Glenn, 
 
Overnight, I ran a log capture session on my GPS_Standard running v4 firmware for more than 12 hours (2600+ samples) and did not see any deviation other than the usual sample-to-sample offset.
 
Regarding the Timer 1 configuration, the synchronous mode was tried when I originally designed the project but clearly showed that it did not work. Just for fun, I tried it again tonight and sampled values varied wildly all over the place.  When you think about it, you don't want any peripheral clock to re-synchronize the 10 MHz OCXO clock. I can see that you did your homework by looking into the documentation. The note you provided about Timer 1 in CCP mode indicates that it *may* not work in async mode, but it does works fine, and the large installed base is a good proof ofthis.
 
If you want to try out things, I can provide you with the v3 firmware file. Let me know.
 
Best Regards,
 
Bert, VE2ZAZ
 
----- Original Message ----- From: "Glenn Elmore" To: Sent: Tuesday, April 14, 2009 4:38 PMSubject: [GPS_Standard] Problem with v4, where can I get v3 to try? Hi all,I'm new to the list but have been struggling to get v4 to work as expected. The problem is that with a 10 MHz reference and GPS or even with an arbitrary waveform generator providing a 10 MHz reference clock and generating a 1 PPS 20% duty cycle square-wave, the frequency count wanders around the correct value and thus causes the board to go into holdoff. I see counts up to 2000 (decimal) either side of the correct 0x6800 count. These errors show up in groups and are not constant. Many times the count is pretty close. Averaging total counts over very long intervals shows that *all edges* are actually being counted as the average is essentially correct if taken over tens of minutes. This isn't an edge, noise or similar problem. It acts like there is extremely severe jitter in the 1 PPS sample clock even though there isn't.I've looked at the PIC code and do not yet understand how to resolve the admonition from Microchip:    PIC18F2220 data sheet, page 137:                                                               15.3.2       TIMER1/TIMER3 MODE SELECTION    The timers that are to be used with the capture feature (either    Timer1 and/or Timer3) must be running in Timermode or Synchronized    Counter mode. /*In Asynchronous Counter mode, the capture operation    may not*/    /*work*/. The timer to be used with each CCP module is selected in    the T3CON register.with line 433, where Timer1 (the reference clock) is set up by T1CON as:     MOVLW b'00000111'                           ;set timer1 and enable    it Used for CCP1 (Capture)     MOVWF T1CONwhich is asynchronous counter mode.I'm not at all certain that it anachronism is the problem but I *do* experience unstable counts which seems categorically wrong for a completely deterministic system.Has anyone seen this behavior and can someone help with an idea of what is going on and/or help by sending me v3 to try to see if it also has the problem?  Has anyone verified that v4 does in fact give perfect results (constant 0x6800 counts) when supplied with a perfect 10 MHz and 1PPS?Glennn6gn ______________________________________________________________GPS_Standard mailing listHome: http://mailman.qth.net/mailman/listinfo/gps_standardHelp: http://mailman.qth.net/mmfaq.htmPost: mailto:GPS_Standard at mailman.qth.netThis list hosted by: http://www.qsl.netPlease help support this email list: http://www.qsl.net/donate.html