I have done some digging into frequency accuracy of the past few weeks, and discovered a few things that I want to share, as well as some code updates. Some background…
When the new run of boards came in, I built one to verify that they work OK. As I have two DG5’s already built and running (one LCD, one Nixie, mounted in cases) I decided to get this new board working on a clone Duemilanove board I ordered on eBay. It worked, but the frequency was 400 to 500 Hz off, and the calculated USB/LSB/CW was wrong. So, I tried the new board on one of my existing Duemilanove’s, and everything worked just fine. So, what was going on with these clones?
I measured the crystal on the clone board by holding an piece of insulated wire near the circuit when the board was running, and monitoring the signal on my HP 8924C – the crystal oscillator circuit was about 925Hz low from the desired 16Mhz, which translates to a 57ppm error. So, I ordered up some 10ppm crystals from Mouser, and replaced the crystal with the new one – it only measured 55-58 Hz off, or about 3.5ppm. Much better. When I hooked it up to the TS-520, the measured frequency was correct. The accuracy of your frequency measurements is only as good as your reference. The program measures the frequency by direct count of the sampled signal in a given time period, which is 100mS in the program. If your reference is off, your measurement is going to be off.
However, there were some other things I noted when troubleshooting this problem. I was using the DEBUG mode which is accessed by typing “DEBUG1;” in the Arduino serial monitor In this mode, the board will print all the measured frequencies – useful for figuring out what the program is seeing from each input. While troubleshooting, I wanted to make sure I had a stable, known frequency to measure, so I used the HP 8924C’s signal generator to give me 5.000000 Mhz and fed it into the VFO input while monitoring the readings in DEBUG mode. I was getting some errors that I couldn’t really account for, and as I changed the gate timing during troubleshooting I got even stranger errors. Increasing or decreasing the gate time by factors of 10 should only change the resolution / number significant digits, but it was changing the measurements as well.
So, I did some searching on the web and found a different frequency counter library, and I substituted it for the existing code, and things seemed to stabilize. I’ll post links to the new code as soon as I am done testing and porting it to the LCD version – I was working in the LED version to make the change.
But a few other things came up. The original DG5 did not compute the mode (USB/LSB/CW), I added that in as I wanted to be able to read the frequency and mode into logging software, and figuring out the mode was just a matter of looking at what the BFO frequency is. In the TS-520S Service manual on pg. 6, it describes the frequencies used by the BFO for the different modes. It states, “Frequencies are 3396.5 kHz for USB, 3393.5 kHz for LSB, and 3394.3 kHz (receive) and 3395.0 kHz (transmit) for CW.”
Here’s the piece of code that does the figuring:
// use the BFO (CAR) frequency to determine USB/LSB/CW
if (bfo > 3396500){
USB = true;
LSB = false;
CW = false;
mode = ‘U’;
}
else if (bfo < 3393500){
USB = false;
LSB = true;
CW = false;
mode=’L’;
}
else{
USB = false;
LSB = false;
CW = true;
mode=’C’;
The program tests a few conditions based on this information, and testing that I did on my TS-520S. On my unit, if the BFO measurement came in ABOVE 3396.5 kHz, it was in USB – so that’s what I had the program do. It’s never going to be sitting exactly AT the frequency stated by Kenwood – I needed to divide up the boundaries and see if it fell into one of these areas. The issue is, what worked for my TS-520S might not work for others, based on inaccuracies in the clock on the Duemilanove (one source of error) and inaccuracies in the TS-520S itself. (BTW – I used both a mode variable (U, L, or C) to track, as well as some boolean flags (true/false) – this would probably be cleaned up as only one is necessary.)
So, if your display is showing “c” no matter what mode the radio is in, enter the debug mode by typing “DEBUG1;” in the serial monitor (9600 baud) and press the “SEND” button. You screen should start streaming updates every 1/3 od a second or so, from here you can see the actual measured BFO frequency as you click thru the different modes. Adjust the section of code (shown above) to reflect the range for your TS-520. You might have to play with this to get it dialed in.
I’ll get an update posted here as soon as I port the new library to the LCD version. and do some testing. I hope you’re having fun and learning – that’s what this is all about!
Steve