Hi Clint
There's a lot of information there, I have some things to comment/suggest etc.
Firstly, I think it would be wise to check that the clock divide-by-8 fuse problem isn't applicable to your chip. If you switch off the GPS (set it to Off in the menu), does the kit work Ok? When waiting for the time for a transmit WSPR frame, the clock should show on the LCD - does it count normally? If so, then clearly there is a problem only with your GPS unit not suiting the kit very well, and we have to address that problem only.
> - I was able to issue commands to the GPS receiver so that it outputs ONLY $GPRMC strings. ?I've tried setting it for updating once per second, or once every second - no difference.
Yes, I do no think that the problem is with too many sentences in the serial data stream.?
> - I've tweaked the 1pps voltage so that it's comfortably within the CMOS threshold of a device operating from a 5 volt rail - no difference.
3.3V should be Ok for an AVR directly.?
> - At some point, the seconds count will by synchronized to the 1 second interval: ?It may be 1 or 2 seconds off, but the change occurs right on the 1 second interval.
>?
> - Over a period of 10-20 seconds, I can visually watch the LCD's seconds-counter "walk" away from the UTC second, slowing down by about 1/2 second after that period.
>?
> - At some point, the LCD seconds will jump and re-synchronize.
>?
> Clearly, the "time" on the AVR isn't close enough to allow a free running clock and it looks like it drifts away from the window rather quickly. ?I let the unit run for several hours and not once was I able to get a valid WSPR decode.
Probably if your clock was really free-running, i.e. if you completely turn via the "Use GPS" setting, the unit should run for many days. The accuracy of the clock is limited only by how accurately you were able to tune the frequency - if it matches the value set in the "Frequency" configuration parameter, then the timing will be very accurate.
However I have a suspicion about what is going on here. The GPS 1pps input is not watching either the positive or the negative edge. It actually triggers an interrupt on BOTH edges. How it decides which one to attend to: it is looking for a change in signal level which arrives at the right time, to lock onto. I think the problem here is that your GPS unit has a 100ms pulse, which is exactly the threshold set in the code, for what is the "right time". A very short pulse would be Ok, and so would a longer pulse. But if the pulse length is exactly 100ms, then sometimes it will be triggering on the rising edge, and sometimes the falling edge - depending on whether it thinks it is more or less than 100ms long as timed by the kit.
> Thinking that the 100ms long 1pps pulse (rising edge coincides with the second)
> I put a series capacitor (0.05uF) with a 10k to ground on the UQRSS side to turn
> it into a brief rising pulse, but this hasn't changed anything, either.
When you added this circuit, I don't think it helped because you essentially created two brief pulses 100ms apart so the same problem was there.
I'm not explaining this very well nor can I think of a better way to explain it right now. But basically I think that your pulse is exactly the right length for the kit to be getting confused by it and I suspect that the symptoms you observe are consistent with my understanding of what would happen if a pulse of 100ms was applied. Less or more is fine, but exactly 100ms is a problem. There has to be a threshold somewhere, and I chose 100ms!
This is suspicion only. I may be wrong.?However I think we could prove it easily enough. In order to test my theory, you should try lengthening the pulse so it is more than 100ms. You could do it with a 74HC123 etc but I think the easiest way would be: a diode from the GPS module?1pps?signal to the "Ultimate" kit input, with a small capacitor to ground, and a resistor across the capacitor. Say 0.05uF and 100K. That should lengthen the pulse by a few ms, enough to get it away from 100ms. I would be very interested to see if this helps.
> I don't get any ERROR message, so this doesn't exactly fit the "slow clock" problem, but there's something amiss, here. ?I do have access to an Atmel AVR Dragon programmer, so if there's a fuse that can be flipped (assuming that it's not code-protected) I could try that?
Sorry, it is code-protected. Long story, I won't go over it again here. But we felt it necessary :-(
73 Hans G0UPL
