Topics

TCXO for U3S CPU clock #u3s #clock


HF
 

I posted on this topic 1.5 years ago.  There were some thoughtful responses, some containing terminology I couldn't understand because I have so little knowledge of what actually happens when I connect a computer to the '328 and try to talk to it.  Now there are many more members and more experience has accumulated since then, so I'll raise the questions again to find out if there's some new knowledge out there.
I would like to put a TCXO in place of the crystal that controls the '328's clock frequency.  This is because the start time for its WSPR transmissions varies with temperature and I don't wish to use a GPS to update the frequency.  I have learned that to "do it right", one has to modify "fuses" in the '328 to tell it to use an external clock instead of a crystal.
The trouble is that I don't understand how to modify fuses in the '328; the instructions I've found contain terminology I don't understand.  I understand I'll have to connect a computer to it, maybe an intermediary circuit, and run a special program.  I don't know how to get that program or if it's built in to the Arduino IDE.  Would I connect to the USB connector on the U3S, or do I have to have some sort of adapter and connect it some other way? 
I'm also concerned that if I try to modify the fuses, it will interfere with other programming on the chip or ruin it in some other way.  I now see that some people have succeeded, so ruining the programming is not guaranteed.  But are there special steps that must be taken to protect it? 
I'm also not sure if I understand how fuses inside the '328 work.  Almost all fuses I've seen can be blown, but can't be "unblown".  If I "blow" the fuses (that I can't see) in the '328, will it be possible to restore them to their original state if I goof it up or if something else pertaining to the TCXO idea doesn't work?
The data sheet's block diagram says that XTAL1 feeds an inverter with the output of that inverter going to XTAL2, which forms the oscillator.  The inverter's output would supposedly go on to be the system clock. It seems like one would then be able just connect the oscillator to XTAL1 and leave XTAL2 unconnected and not mess with the fuses.  The inverter would act as a buffer on the signal from the TCXO.  If this is the case, then changing the fuses might not be needed.  But if the fuses don't have to change, why do the fuses even exist for this part of the circuit? 
One responder suggested that I just try it and see what happens.  Another is quite sure that I will have to change the fuse.  Has anyone actually tried to do it without fuse changes?
Some have discussed the clever idea of running the '328 from the same TCXO that runs the transmitter.  In some other projects with TCXOs, I have come across an inexpensive but extremely stable 10 MHz TCXO and a circuit that can convert that signal to 27 MHz.  If I clock the '328 at 10 MHz instead of 20 MHz, would I just have to tell it that its Sys. Frq. is 10 MHz instead of 20 MHz?  Or will some other timing-related functions then fail?
Does anyone have the '328's internal clock circuit diagram?
Halden VE7UTS


Alan G4ZFQ
 

I would like to put a TCXO in place of the crystal that controls the '328's clock frequency.  This is because the start time for its WSPR transmissions varies with temperature and I don't wish to use a GPS to update the frequency.  I have learned that to "do it right", one has to modify "fuses" in the '328 to tell it to use an external clock instead of a crystal.
Halden,

This is not necessary.
All that is required is to send the output of the TCXO to one of the (ex) crystal pins.
I'd have to check which one.

Some have discussed the clever idea of running the '328 from the same TCXO that runs the transmitter.  In some other projects with TCXOs, I have come across an inexpensive but extremely stable 10 MHz TCXO and a circuit that can convert that signal to 27 MHz.  If I clock the '328 at 10 MHz instead of 20 MHz, would I just have to tell it that its Sys. Frq. is 10 MHz instead of 20 MHz?
Over to Hans for that one..

73 Alan G4ZFQ


DL2ARL
 

Hello Halden VE7UTS, hello group,
I have had a similar discussion some years ago, interested in using a commercialy available 10MHz TCXO instead of the 27MHz for the U3S. Hans has very kindly answered all my questions, but I was too shy to ask more, so my understanding is only half of what he was trying to tell me. I finaly gave it up an bought a TCXO from qrp-labs and now I am in the prospect of gaining a yet better version also from qrp-labs custom made for the brand new qcx+ but working with other rigs too (if wired in).

This is what I understood at that time from the discussion: if you would NOT care about WSPR, only being interested in traditional modes and qrss, nothing would speak against using a TCXO with another frequency, whatever this frequency might be. But for the computation of the WSPR Tx, the only feasible TCXO frequencies would be 27 and (maybe) 25MHz, especially on 2m for some reason. I think, if you would search after my callsign and+and the one from Hans on this group you might have the chance to find the original conversation and understand more than I did. Or wait until Hans finds time to answer this question again. The search function is ante-deluvial on this forum.

Regarding your message above:
"I have come across an inexpensive but extremely stable 10 MHz TCXO and a circuit that can convert that signal to 27 MHz"

I suspect this must be some kind of miracle gadget built of that unobtainium stuff everybody looks for nowadays. I have no idea how one could convert 10 to 27 MHz, but would be very eager to learn how. On the contrary, making 10MHz to say 20 or 30MHz (or even to 25) should be a breeze, but not to an odd frequency like 27 without mixing it with something containing a "7" and thus sacrificing the temperature compensation of the 10MHz clock and getting a forest-full of cross-modulations.

Tell me more about that!
yours friendly, Razvan DL2ARL


HF
 

Hi Razvan,
Thanks for shooing me away from changing the CPU clock frequency.  I do like WSPR. Alan just encouraged me to try putting the 27 MHz TCXO signal right into the CLK1 input.  That should keep my timing correct for at least a few weeks at a time.
A TCXO enabled me to make U3S WSPR work on 2 metres.  I'd like to see if I can push it up to 220 MHz.  I'd like to go higher, but that will require different hardware, as the U3S can't shake any faster than 230 million times per second.
I considered using a DDS like the one in the U3S to obtain a 10.24 MHz reference oscillator for my IC-271H.  But one has to tell the DDS what frequency to go to every time it turns on; that means I'd have to put a microcontroller in there, too.  Too complicated.  With some research, I found a 1-chip solution.  The frequency conversion uses a field-programmable PLL IC from Cypress.  Here's an article that describes how that works starting with the same type of 20 MHz TCXO I put in my U3S for the synthesizer reference.

https://groups.io/g/icomclassic/files/IC-271H,%20IC-471H/TCXO%20for%20IC-271H%20summary%20v2.pdf

Phase noise from this conversion might matter in this application whereas it didn't seem to matter on the -271H. 
Here are 2 articles about using the TCXO I found that's even more stable than the one I used for the IC-271H.  In this case, I didn't need to convert the frequency because the stock TCXO had the exact reference frequency I needed.

https://kenwood-hybrids.groups.io/g/main/files/TS-830S%20stability%20and%20accuracy%20improvement%20modifications

My experience with this TCXO was less than 0.5 Hz drift as the TS-830S and VFO-230 warmed up from 13C to a few degrees above ambient in a room at 20 C.  That's much better than the 20 MHz TCXO I had used before.
The next project might be to use this 10 MHz TCXO and the PLL chip to make a 10.24 MHz reference oscillator for the IC-471H.  Up there, the stability improvement would probably be noticeable.
You're mostly right about the unobtanium - the only place I know of to get the programming dongle for these is on the shelf in my radio room.  They show up on ebay from time to time.  I'm not aware of anyone else looking for them though.  At least one other company offers a similar product - their version might be readily available though more expensive.
There is yet another potential solution that doesn't involve receiving a GPS signal from time to time.  One can get a rubidium oscillator.  Then, either change its programming to give the frequency you want, or use it as the input to a field-programmable PLL.  That should drift less than any TCXO!  .
Cheers
Halden VE7UTS


Allan Nelsson
 

Halden,

Instead of using the U3S you could concider the RFzero https://www.rfzero.net for WSPR use on 23 cm but also as a GPSDO LO for your IC-271H. The RFzero will do that and much more when you don't use it for either WSPR or GPSDO. Plus no fumbling with post mounting a TCXO etc. :-)

Allan OZ5XN

 


HF
 

Okay, I have the TCXO ready.  I'll give it a try per Alan's suggestion.  But I just realized that calibrating it might raise an interesting issue.
For a while, I was using the U3S to transmit alternately on 2 different bands.  Then I resumed transmitting on just one band.  I noticed that my timing drift was greater when making 2 transmissions in a 10-minute period than it was when I only made one.  I guess this means that during a transmission, the CPU's internal clock doesn't increment the same amount as it does when not transmitting.  I suppose the internal clock raises an interrupt from time to time (so to speak) and during a transmission the interrupts have to be masked so that the timing of the transmission is correct.  Am I right?  Has anyone else noticed this?
The consequence I anticipate is that once I install the TCXO to run the CPU and measure its frequency ( I think I can get it within 4 Hz), entering its exact frequency into the software might not work.


Hans Summers
 

Hi Halden

No. It is not correct that interrupts are masked during transmission to get timing correct. A possible explanation for your more drifting CPU clock during more transmissions is that greater amounts of heat from the PA are reaching the 20MHz crystal and causing the frequency to change slightly. 

73 Hans G0UPL
http://qrp-labs.com

On Thu, Jun 11, 2020 at 5:20 AM HF via groups.io <incorridge=yahoo.com@groups.io> wrote:
Okay, I have the TCXO ready.  I'll give it a try per Alan's suggestion.  But I just realized that calibrating it might raise an interesting issue.
For a while, I was using the U3S to transmit alternately on 2 different bands.  Then I resumed transmitting on just one band.  I noticed that my timing drift was greater when making 2 transmissions in a 10-minute period than it was when I only made one.  I guess this means that during a transmission, the CPU's internal clock doesn't increment the same amount as it does when not transmitting.  I suppose the internal clock raises an interrupt from time to time (so to speak) and during a transmission the interrupts have to be masked so that the timing of the transmission is correct.  Am I right?  Has anyone else noticed this?
The consequence I anticipate is that once I install the TCXO to run the CPU and measure its frequency ( I think I can get it within 4 Hz), entering its exact frequency into the software might not work.


HF
 

Hi Hans,
Thanks for that definitive information!
Last night and this morning, I measured the 20 MHz oscillator.  It's running at 20,005,717 kHz at the beginning of the transmission, dropping to 20,005.414 at the end of the transmission.  Then it shifts up to 20,005.419.  It then drifts down to 20,005.418, turns around and drifts up to 20,005.423.  Then it shifts back down to 20,005.717 when TX starts.  Summarily, the heat causes downward drift on the frequency and being in TX mode shifts it down by 5 Hz.  I'm guessing that the supply voltage drops in TX mode, causing the 5 Hz shift.  I've also seen about 1 Hz drop in frequency when the display backlight is on - also presumably a supply voltage drop.
Looking at the characteristics of the drift during TX, I'm guessing that adding the second transmission to the cycle would drop the average frequency by about 4 Hz.  That's 0.2 ppm and would change the timing drift by 1 second in about 58 days if I calculated that right.  I'm seeing much more than that.
So...anyone have other ideas on what could cause this?
FYI, the average measured frequency is 20,005.718.  The setpoint I determined experimentally and entered into the U3S many months ago is 20,005.470.  The 248 Hz difference is 12.4 ppm, corresponding to a drift on 1 second per day.  I'll enter that in to the U3S now and see what happens.
But before I go, I have a related question.  I have found that every time I go into the menus and change something other than the time, I seem to lose about a half a second on the internal clock. Is anyone else seeing this?  Is there a programmatic reason for this?
Cheers
Halden


 

Halden,

I believe I saw something of this nature on the QCX when I first stared playing with WSPR. As I understand it there is some common code between the two products.

Julian N4JO.

On 6/11/2020 10:57 AM, HF via groups.io wrote:
Hi Hans,
Thanks for that definitive information!
Last night and this morning, I measured the 20 MHz oscillator.  It's running at 20,005,717 kHz at the beginning of the transmission, dropping to 20,005.414 at the end of the transmission.  Then it shifts up to 20,005.419.  It then drifts down to 20,005.418, turns around and drifts up to 20,005.423.  Then it shifts back down to 20,005.717 when TX starts.  Summarily, the heat causes downward drift on the frequency and being in TX mode shifts it down by 5 Hz.  I'm guessing that the supply voltage drops in TX mode, causing the 5 Hz shift.  I've also seen about 1 Hz drop in frequency when the display backlight is on - also presumably a supply voltage drop.
Looking at the characteristics of the drift during TX, I'm guessing that adding the second transmission to the cycle would drop the average frequency by about 4 Hz.  That's 0.2 ppm and would change the timing drift by 1 second in about 58 days if I calculated that right.  I'm seeing much more than that.
So...anyone have other ideas on what could cause this?
FYI, the average measured frequency is 20,005.718.  The setpoint I determined experimentally and entered into the U3S many months ago is 20,005.470.  The 248 Hz difference is 12.4 ppm, corresponding to a drift on 1 second per day.  I'll enter that in to the U3S now and see what happens.
But before I go, I have a related question.  I have found that every time I go into the menus and change something other than the time, I seem to lose about a half a second on the internal clock. Is anyone else seeing this?  Is there a programmatic reason for this?
Cheers
Halden


HF
 

Hi Hans and anyone else who tried to make sense of my June 11 post,
I have made some more progress regarding running the U3S clock on a TCXO.  Before I describe that, I need to fix the incorrect frequencies I described in my June 11 post.  I mixed numbers in the 700s with numbers in the 400s because I was using a receiver tuned to 20.005300 MHz and watching the beat tone in a Spectrum Labs display.  When the display indicated 414 Hz, for example, I have to add that to the radio's frequency display to get the signal frequency.  Some frequencies I reported somehow omitted the 300 Hz part of that.  I apologize to all readers.  Here's that paragraph again with the correct frequencies:
"Last night and this morning, I measured the 20 MHz oscillator.  It's running at 20,005,717 kHz at the beginning of the transmission, dropping to 20,005.714 at the end of the transmission.  Then it shifts up to 20,005.719.  It then drifts down to 20,005.718, turns around and drifts up to 20,005.723.  Then it shifts back down to 20,005.717 when TX starts.  Summarily, the heat causes downward drift on the frequency and being in TX mode shifts it down by 5 Hz.  I'm guessing that the supply voltage drops in TX mode, causing the 5 Hz shift.  I've also seen about 1 Hz drop in frequency when the display backlight is on - also presumably a supply voltage drop."
I'm still curious for answers to the questions that were in the rest of that post, which I've included here for reader convenience:
"I have found that every time I go into the menus and change something other than the time, I seem to lose about a half a second on the internal clock. Is anyone else seeing this?  Is there a programmatic reason for this?"
Cheers
Halden


HF
 

Thanks, Alan, for your encouragement.

I cut the trace to the crystal at pin 9 and connected the TCXO output to pin 10.  I monitored the output of the inverter that serves as an oscillator when a crystal is present.  There was a little wiggle in its output, but not enough to clock the MCU.  I tried a few amplifier transistors, including a 2N7000 FET and a 2N4403.  The highest voltage I could obtain for these when applied to the inverter input at pin 9 oscillated between 1.6 and 4.0V and produced a signal from 1.0 to 2.6 V at the inverter output, which was not enough to clock the MCU.  I found a few 2N4995s in the bin, looked them up, and found that they are meant for RF and IF circuits.  Using one, I got a range of 1.2 to 3.5V at the inverter input and 1.0 to 3.2 at the inverter output which was enough to clock the MCU.  The circuit is below.  It seems that 2N4995s are not readily available.  But 2N3904s also have good gain at low collector current, plus high GBP, so they should work.

I made some observations about this oscillator’s stability, anticipating that it will enable the U3S to provide on-time WSPR transmissions for weeks at a time once I enter the oscillator’s frequency into the U3S settings.  I used my FT-890 in USB mode, providing the beat tone to a laptop running Spectrum Lab software to measure the frequency and assess its stability.  The FT-890’s frequency is accurate due to installation and calibration of a TCXO a few months ago.  After about a half hour of warmup, this radio’s reference oscillator is within 2 Hz of its nominal value, and better than that after an hour or two.  I determined this by watching the beat tones from WWV and WWVH over time. 

I watched the U3S’s new clock oscillator frequency change as the U3S ran several TX cycles.  It is set to transmit once every 10 minutes on 6 meters.  There are 4 other transmission configurations in the setup list, but they are disabled.  The clock frequency shifts up abruptly about 0.1 Hz during a transmission.  Spectrum Lab reveals a couple Hz drift which could be in the FT-890 since it hadn’t been on for very long.  The nature of the drift doesn’t change between TX and idle.  After some stability observation, the frequency converged to 19,999,923 Hz which I entered in the U3S. 

I’ll write a separate post describing the on-time performance of the U3S with this new oscillator.

Cheers,

Halden NR7V


HF
 

Hi all,

Equipped with a TCXO as the MCU’s clock oscillator, I observed the “DT” parameter in the WSPR reports for a few days.   The receiver’s computer synchronizes itself to NIST once per hour.  As mentioned in another post, I measured the oscillator and entered its frequency into the U3S’s setup program.  WSPR’s “DT” parameter shows how late or early the WSPR transmission is relative to the even minute at which it’s expected to start.  Over 4000 minutes (2 ¾ days), it had shifted about 3.4 seconds.  This represents 14.2 ppm, ~284 clock cycles missed per second, 17,040 per minute, and 170,400 per 10-minute transmission cycle.  There is slight diurnal variation in the DT vs. time chart, showing slightly lower DT in the mornings when the U3S is a few degrees cooler.  It seems that at cooler temperatures, the U3S’s clock seems to be off about 13.3 ppm whereas the error averaged over ~3 days is 14.2 ppm.  This difference of 0.9 ppm for a 5 degree temperature change is probably reasonable for the low-tier TCXO which I used.

Back when I had the unit running on a 20 MHz crystal and I determined the frequency setting for the U3S by watching DT over several days and making corrections, the frequency entry derived by this method was 12.2 ppm below the frequency later measured by the FT-890 with Spectrum Lab.  This error has the same sign and similar magnitude to the error when running on the TCXO.

I’ll enter a frequency 284 Hz below the measured frequency into the U3S and see how its timing drifts.

Any ideas why the U3S internal clock would miss a tiny fraction of its ticks?  Could there be a computation error relating to resolution when working with large numbers? (Hans, that one's for you.)  Or, could some other factor be responsible?  My U3S firmware is version 3.12a.

Cheers

Halden


HF
 

An update:
In late July or early August, my U3S had a few periods of much stronger clock drift than the 1.24 seconds/day described in my previous post.  I have verified that there was no power outage during this time.
It occurred to me that perhaps the TCXO amplification was barely enough to make the MCU recognize the pulses, so maybe it missed some because of variations in amplitude.  So I changed the V+ on the TCXO signal's amplifier from the regulated +5V to the PA voltage which is around 8V now.  This increased the amplitude of the clock signal after the inverter.  So now I'm certain that the MCU doesn't miss ticks because they're too weak.
I set the clock frequency in the U3S 284 Hz lower than the actual clock frequency as mentioned in my previous post.  I also verified that my frequency-measurement scheme is accurate per WWV and WWVH.  It's probably off by about 1 Hz and certainly within 3 Hz at 20 MHz.
Now, after about 4 days after setting the clock, the drift is about 0.6 seconds in the other direction.  It looks like I should have set it about 249 Hz low instead of 284.  Because the drift is so much less than before, I'll probably be able to get drift data for a week or more, depending on WSJT-X's ability to decode early WSPR transmissions.  And, if a period of rapid drift occurs again, I should get more precise information about the nature of that drift and when it occurred relative to when I last cycled the power and reset the time on the U3S.
Hans said earlier that the U3S's code does not mask the interrupts involved in updating the MCU's timer value. Could it be a library that his code calls?  What sort of library functions would mask interrupts?  Does anyone know if there's some other reason that the Atmel 328P would miss about 14 out of a million of its clock pulses?  Has anyone else here tried to make a U3S keep track of time without having a GPS set it right from time to time (heh, heh)?
Cheers
Halden VE7UTS


HF
 

BTW, when I raised the voltage at the 1k resistor connected to the 2N4995's collector from 5 to 8 volts, I also inserted a capacitor between the collector and the MCU to prevent excessive voltage at the input.
Halden VE7UTS


HF
 

Another update:
First, a brief summary.  Details are in prior posts here:  I wish to run WSPR on my U3S (firmware 3.12a) for long periods and without a GPS DO to keep it on time.  I installed a TCXO in place of the MCU's 20 MHz crystal and measured its frequency to be 19,999,923 Hz.  I entered this into the U3S.  After several days, the start time had drifted so much that decodes would no longer occur.  After that, there were periods of much greater drift, too, with occasional decodes when it drifted through an even minute.  I calculated and applied an adjustment to the frequency I declared to the U3S based on the first few days of linear drift.  I also raised the TCXO amplifier’s power supply voltage and changed the coupling between the TCXO’s amplifier and the MCU in case the signal amplitude had been so near the detection threshold that some pulses were being missed.  Perhaps the clock signal amplitude had been changing relative to the detection threshold as the unit’s temperature rose and fell. 

The next test showed 4.4 seconds of drift in the other direction over 24 days.  The drift was very even – the periods of accelerated drift observed before did not occur.  So, I applied another adjustment.  The net adjustment was to enter a frequency 243 Hz lower than actual into the U3S.  A day later, the time was still correct relative to the WWV broadcast.

Back when I ran this unit with a crystal, I had noticed that the drift was different when I had more than one transmission in a 10-minute period.  Also, I speculated that the code was more likely losing clock ticks during a transmission than while waiting for the next transmission because the MCU is much busier then.  So, I added another transmission to the sequence so that it now transmits first on 2 metres, then 6 metres, then waits for 6 minutes before doing it again.  I also subtracted another 243 Hz from the frequency declared to the U3S. 

After 31 hours, the U3S stopped because I inadvertently disconnected its battery charger.  But the decodes during that period show no detectable drift.

My conclusion:  Enter a MCU clock frequency that’s 243 Hz lower than the measured clock frequency if transmitting WSPR once per 10-minute period.  Scale the offset accordingly if you’re transmitting more or less often than that.  Of course, if using a GPS DO, one doesn’t have to think about this at all.

Cheers

Halden VE7UTS