International shipping costs skyrocket!

I don’t know what the USPS is thinking, but I can no longer ship international for the $2.50 I have been charging.  The USPS rate for a document is about $2.50 (for 1 ounce), but for goods it varies – I tried to ship to Australia and it was over $13!  Bottom line, if you want me to ship internationally, please send me an e-mail first with you address – I’ll have to see if Paypal can do the calculations, but in the mean time please ask first at my call @ my call.com (same as the website you’re on!)

New boards in stock!

I received another run of 100 PCB’s for the DG5 emulator, project info here.  Please read before ordering – this isn’t a kit – you will need additional components.

Same price, $8.00 + $2.50 shipping for as many boards as you like. In most circumstances, I can ship internationally for this price as well. Rather than having to find the link to order on the project page (which has gotten rather large!) you can use the link below:





Steve
KV6O

Another 100 PCB’s ordered!

UPDATE 7/6/17 – The last 2 boards shipped today, so I am officially out of stock for now, but more are on their way.

I placed another order for 100 PCB’s with the same PCB house that made the last batch, should be here in a week or two.  In the meantime, I am selling the remaining few boards I have to folks who have written me wanting a board.  I *think* that means ~180 boards shipped so far, I’ll have to look at my previous orders.  I hope folks are having fun with the project!

A lot of updates to the DG5 project

I finally had some time the past two weekends, and I made a lot of updates to the project – the code has been updated, I released code for the Nixie and LED versions, I finished off the LED version by mounting it in a chassis, I broke up the project into 3 separate pages for LCD, LED, and Nixie, and finally, I moved the code and PCB project files over to Github.  Whew!

The current version as of this writing is 2.0.2.  Updates will be directly published to the Github project page. Version 2.0.2 includes:

  • Stability Enhancement. Locks the values used for the HFO and BFO, updates then only if they have moved more than 500Hz and 100Hz, respectively.  This should help eliminate some wander/wiggle by keeping the two “fixed” frequencies stable.
  • Released the LED version, uses MAX 7219 based, 8 digit, 7-segment display.
  • Released the Nixie version, uses I2C SmartNixies.
  • Added correction factor (optional)
  • Added smoothing/averaging to reduce display jitter – averages over 4 readings (adjustable)
  • Code cleaned up and better documented
  • Changed frequency counter logic to the FreqCount Arduino library
  • Tested with latest Arduino IDE (1.8.2)

That’s all for now, click on the project pages to see more on the LED and Nixie versions. If you have a DG5 emulator running, give the new code a try!

Steve
KV6O

New DG5 code!

It’s been a while since I have updated the code, and I have been working on some improvements on and off over the past year as I have had time.  This is for the LCD version, which I think just about everyone is running.  I have made an LED and Nixie tube version as well, but haven’t updated the code for these versions just yet – let me know if you need it. Done, new pages have been set up for both and new code for all 3 version is on Github

Some of the improvements:

  • New/improved frequency counter routine.  The program now uses the “FreqCount” library that is available in the IDE environment.  You will probably need to download this, which can be done selecting “Sketch/Include Library/Manage Libraries..” in the Arduino IDE.
    Search on “FreqCount” and you should find Paul Stoffregen’s library. Install the latest version.
  • Correction Factor added.  If needed, you can correct the display.  This will not “fix” a poor frequency reference/source like the ceramic resonators found on UNO’s.
  • Better code documentation.  I hope it’s easier to read and understand if you want to get in there and make your own modifications.
  • Added smoothing, anti-jitter code to help stabilize the display. (smooths over 10 readings, this is adjustable)
  • Tested with latest Arduino IDE (1.8.2)

4/8/17 – Code has been moved to Github, LCD, LED, and Nixie versions published.

4/8/17 – Version 2.0.2 uploaded to Github. Stability Enhancement added. Tests the HFO and BFO to see if they have moved more than 500Hz and 100Hz, respectively.  If not, keeps the last reading. This should help eliminate some wander/wiggle but keeping the two “fixed” frequencies stable.  Also lowered the averageing to 4 samples (from 10), makes display a little more responsive

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;
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