A few DG5 updates

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;

USB = false;
LSB = false;
CW = true;

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!


21 thoughts on “A few DG5 updates

      1. charlie cheng

        what I am asking is can I buy a working one already with instructions on how to tap it into my TS-520

  1. Robert Adams

    Hi Steve i got my dg5 board built
    and runs just fine with lcd but i
    would like to try the led display.
    I am new to arduino and need
    help as i am getting an error when
    i try to verify the led code. I have
    the same led display as yours
    and a uno board thank you
    This is the error
    Arduino: 1.6.9 Hourly Build 2016/05/06 05:33 (Windows 7), Board: “Arduino/Genuino Uno”

    C:\Users\robert\Desktop\arduino-nightly\arduino-builder -dump-prefs -logger=machine -hardware “C:\Users\robert\Desktop\arduino-nightly\hardware” -tools “C:\Users\robert\Desktop\arduino-nightly\tools-builder” -tools “C:\Users\robert\Desktop\arduino-nightly\hardware\tools\avr” -built-in-libraries “C:\Users\robert\Desktop\arduino-nightly\libraries” -libraries “C:\Users\robert\Documents\Arduino\libraries” -fqbn=arduino:avr:uno -ide-version=10609 -build-path “C:\Users\robert\AppData\Local\Temp\build9e3ae2344af543c2b0e55f153fb89c1e.tmp” -warnings=none -prefs=build.warn_data_percentage=75 -verbose “C:\Users\robert\Desktop\520 vfo\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2.ino”
    C:\Users\robert\Desktop\arduino-nightly\arduino-builder -compile -logger=machine -hardware “C:\Users\robert\Desktop\arduino-nightly\hardware” -tools “C:\Users\robert\Desktop\arduino-nightly\tools-builder” -tools “C:\Users\robert\Desktop\arduino-nightly\hardware\tools\avr” -built-in-libraries “C:\Users\robert\Desktop\arduino-nightly\libraries” -libraries “C:\Users\robert\Documents\Arduino\libraries” -fqbn=arduino:avr:uno -ide-version=10609 -build-path “C:\Users\robert\AppData\Local\Temp\build9e3ae2344af543c2b0e55f153fb89c1e.tmp” -warnings=none -prefs=build.warn_data_percentage=75 -verbose “C:\Users\robert\Desktop\520 vfo\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2.ino”
    “C:\Users\robert\Desktop\arduino-nightly\hardware\tools\avr/bin/avr-g++” -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10609 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR “-IC:\Users\robert\Desktop\arduino-nightly\hardware\arduino\avr\cores\arduino” “-IC:\Users\robert\Desktop\arduino-nightly\hardware\arduino\avr\variants\standard” “C:\Users\robert\AppData\Local\Temp\build9e3ae2344af543c2b0e55f153fb89c1e.tmp\sketch\TS_520_DG5_LED_v1_6_2.ino.cpp” -o “nul”
    “C:\Users\robert\Desktop\arduino-nightly\hardware\tools\avr/bin/avr-g++” -c -g -Os -w -std=gnu++11 -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -w -x c++ -E -CC -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=10609 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR “-IC:\Users\robert\Desktop\arduino-nightly\hardware\arduino\avr\cores\arduino” “-IC:\Users\robert\Desktop\arduino-nightly\hardware\arduino\avr\variants\standard” “C:\Users\robert\AppData\Local\Temp\build9e3ae2344af543c2b0e55f153fb89c1e.tmp\sketch\TS_520_DG5_LED_v1_6_2.ino.cpp” -o “C:\Users\robert\AppData\Local\Temp\build9e3ae2344af543c2b0e55f153fb89c1e.tmp\preproc\ctags_target_for_gcc_minus_e.cpp”
    C:\Users\robert\Desktop\520 vfo\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2\TS_520_DG5_LED_v1_6_2.ino:81:24: fatal error: LedControl.h: No such file or directory

    #include “LedControl.h”


    compilation terminated.

    exit status 1
    Error compiling for board Arduino/Genuino Uno.

      1. Robert Adams

        Thanks Steve i did have the ledcontrol library
        i had to use an older version of arduino ide and
        that did the trick, it works fine
        cheers Rob.


    Hi Steve,

    Waiting for my Chinese Arduino uno r3 clone to arrive. Have noted your comments re. crystal quality, will check it out and act accordingly. What email address do I use to contact you directly should I require help?

    Regards, Russell Flagg ZS2AHF

  3. Rich GD3YEO

    I built up one of the boards and on running tests I realise the UNO clone I have is not up to the job, as it’s a bit of a poor clone, although it has a crystal it is 12MHz, not the 16MHz as in the genuine version.
    Doing a little calculation I think it’s not close enough to alter the timers and get an accurate result, so I’ll just get a genuine UNO board with a 16MHz xtal !.
    Tests with a scope and frequency counter show the pll and divider is working fine.

    1. admin Post author

      Not sure what using a 12Mhz crystal would yield, I changed out the code to a library that you might be able to modify, but using the correct board would probably be best!

      Fun stuff, huh? 🙂


      1. Rich GD3YEO

        tried to figure out a formula but seems to be odd fractions to get near the right timing, found a suitable 16MHz version to order, – got fouled up with a couple of faulty pin leads joining the lcd but now have display working ok now.
        My plan is to try and hitch it into a FT221R which looks possible with slight change in code, when I dig in the diagram again for the figures,
        also a 1980’s Shimizu SS105s I use with transverters for VHF, the HFO pll and divider seems to cope with the pre-mixed HFO-VFO ~40MHz input (42.5-5.5MHz) without taking 3 separate feeds, just LO-IF.
        now back waiting for postie 🙂

        1. Rich GD3YEO

          Now have a genuine UNO with 16mhz crystal but I have a couple of issues in testing, one is that with no input one of the PLLs seems to be oscillating with a waveform on pin2, and the display reads 4289 (or there abouts) with no inputs, but when a known 10MHz is into the HET input it reads 3.8KHz low (9.996.2) so must be missing a few clicks in the mux. Reading out of the /8 divider gives me exactly 1.250000MHz
          Maybe need a ‘wait’ before counting each burst ?
          Still trying to figure out how to get the debug serial monitor screen to work, if I type DEBUG1 nothing happens so can’t see what it is counting 🙁

          1. Rich gd3yeo

            Ah ! found I need to enter “DEBUG1;” – missed the ‘;’ until I looked at the prog to see what it was expecting 🙂
            chasing errors in the counts now
            doesn’t seem to like no input
            and vfo + car only give reliable counts up to 7.5mhz
            and I still get this strange 4289.969 readout !

          2. admin Post author

            My troubleshooting steps:

            With an oscilloscope, make sure you have a good signal on the output of each of the PLL’s (Pin 2), then trace it to the Arduino Pin 5 (the counter pin) – nothing is going to work if you don’t have the signal.

            If you have a signal generator, you can use that to test each of the inputs and make sure you’re getting the correct (or pretty close) reading. The HET signal path is a little different, it goes thru a divide by 8 IC (IC4) before hitting the input selector (IC5).

            If you don’t have a good signal on pin 2 of a PLL, check the input (pin 14) – perhaps there is a short to ground or similar.

            Let me know how it goes!


  4. Rich gd3yeo

    Tests so far :
    test conditions : generator and counter both have off-air 10mhz frequency reference.
    UNO crystal is 800hz high.

    PLL1 PLL2 both behave with correct output on pin 2 up to 17MHz.
    PLL3 works happily up to 40MHz giving 5.000000mhz output from the /8 divider
    40MHz input to HET gives a readout of 39.984.8 on the LCD
    The MUX seems to be selecting each PLL correctly (each input on its own produces an output), so as far as I can see the shield is working correctly so must assume it’s a code issue, and that’s where I’m looking now.
    I note in one of the references that another counter program uses a correction factor for the crystal,
    but also counts overflows (as missed counts) and adds them to the timer count to make the total.

    Tests with 5MHz input yesterday in debug mode gave steady listings for VFO and CAR of 4.997960,
    and HET 4.997952 so all three are missing counts somewhere.

    head scratching continues 🙂

    1. admin Post author

      I had some weird problems occasionally, and changing the gate time could fix it…

      Find the line ” startCounting (100); // how many mS to count for” and fiddle with the 100 – try 125, for example. I didn’t like this solution, so I rewrote the code with a different counting method using a library and it seems to give better results on my Nixie version, I just need to sit down and port it to the LED and LCD version!

      Let me know how it goes!


      1. Rich gd3yeo

        Most accurate readings on the debug counts seems to be with “startCounting (5);”
        on a 5MHz common input I get counts of vfo 5000200 car 5000200 het 5000000

        (altering delay up or down doesn’t help except the last digit flicker, left at 100)

        off for dinner, more later 🙂


    Hi Steve,
    You will recall my RG5 was running 5khz high on 40 metres.Unable to correct the problem.I have a daily sched. with a friend, John Fielding ZS5JF, a professional electronics engineer,who requested I send him all the relevant information. Within 48 hours he sent me the following: Remove the ceramic resonator and the 1megohm resistor on the Arduino UNO, take a lead from the 16meg xtal output to pin 9 (input) of the Atmega328. this I duly did, and to my amazement, the DG5 Emulator is spot on frequency without any adjustment to the code being necessary. John Fielding`s brief comment was; for accurate counting a ceramic resonator is a no-no and to have two 16 meg. xtals clocking together on the same board is not good practice in our application. Better to “daisy-chain them from one oscillator clock.
    Using the second board I have of yours ,I would like to build the LED version DG5 EMULATOR,using the Kenwood led display from the original Kenwood DG5. Any help would be greatly appreciated.

    Best wishes and thanks for a fine project, Russell Flagg ZS2AHF.

    1. admin Post author

      Glad to hear you got it working! I’ll have to see where I go into this on the website, I don’t recommend the UNO because of the ceramic resonator issues. The original Duemilanove board uses a crystal, and it much better suited to the task. Found some of my comments on this in my last post: https://www.kv6o.com/wordpress/2016/05/08/a-few-dg5-updates/

      I go further into ceramic resonators here: https://www.kv6o.com/wordpress/2016/01/18/dg5-update-switched-to-leds-and-prepping-for-nixies/

      I’ll see about updating a build page and stress this issue to avoid this in the future.


  6. Derrill Hartley


    I got the board built and then realized I have no idea how it connects to my Kennwood. What pins do I connect to the VFO, CAR and HET. It seems like that is assumed knowledge and I have not found any good pinouts for the VFO connector.

  7. Jim

    I bought your dg5 emulator on E-BAY a few months ago. It works very well. I have only been on 80,40, and 20 meters SSB. I went on 15 meters SSB and the digital readout just flips around and does not settle down on the frequency that i am on. There is no control with the main vfo dial. It also does this on 10 meters. What would cause this unstable condition.

    1. Stephen Leander

      I think I replied to your message on eBay as well, but wanted to post it here as it might help others.

      The HET levels could be too low – these radios are 35+ years old now… Do you have an oscilloscope? I would have to compare the levels to my radio, or fins what they should be in a service manual.

      If you have a USB to TTL converter, you can put the board in debug mode and verify that it’s the HET that’s wandering around, not something else. The Adafruit FTDI friend can be found on Amazon (or Adafruit) and plugs directly into the board for debugging, programming, and logging – the board can emulate a TS-790 and works with DXLab to read the VFO frequency.

      Any TTL/USB should work, you’ll just have to pay attention to the RX/TX/GND connections. In the debug mode, it will output the VFO, CAR, and HET measured frequencies, and the computed displayed frequency. IF it is the HET frequency that’s wandering, an oscilloscope is probably going to be needed to see what the levels are in 15 and 10.

      That would be the next steps.



Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.