I’ve added a new page for this project with the build instructions, Eagle files, and Arduino code. It can be found under “projects”.

Got the boards in yesterday, was feeling pretty confident about the design, so I ordered 20 this time.  Lucky, the boards look good, and the first one I built fired up right away – whew!

Here it’s fully populated and mounted on an Arduino Duemilanove.

The new boards are a bit more packed than version 1 as they have a few more features.  There’s a 5V 7805 regulator option, 2, 6-pin headers for an external LCD (with a contrast pot), and 4 mounting holes that match up to the Arduino boards.  Quality looks good, these are from Accutrace here in the US – see www.pcb4u.com for info.  Only 2 weeks as opposed to 4 or so from China.

With the boards packed, the clearances between the Arduino and the DG5 shield are tight – too tight in areas as is a usual issue with shields.  I put a piece of electrical tape over the top of the USB connector, and trimmed the mounting tabs for the RCA connectors that protruded thru a little too far.  I also covered the ICSP connector to keep it from touching.

Here’s the layout.

The 6 pin jumper cables I had are a little long, 12″ I think.  I’ll be ordering up some 4″ jumpers that will make it easy to mount in a case.

If you’re interested in a board, leave me a note here and I’ll get in touch with you!  I am working on the Bill of Materials for the complete kit – I had a lot of parts in my parts bin so I haven’t sourced everything, but most parts are available from Mouser, and a couple are from SparkFun (RCA connectors, LCD Jumpers, shield headers).

While I am waiting for the new DG5 boards to arrive (they shipped yesterday – yay!), I decided to see if I could get the AD9850 DDS module I got on eBay to work as an external VFO.  If you search “DDS AD9850” on eBay you should find lots.

This is mine.

The module is being controlled with an Arduino UNO – it sends the desired frequency serially to the DDS chip.  The Arduino is also attached to a rotary encoder for frequency input, as well as an LCD display.  In this prototype, the LCD display is showing the DDS frequency, not the VFO frequency.  I don’t really need a display on the VFO since the DG5 emulator already displays the dial frequency.  An additional advantage to this is I don’t have to worry about the radio Carrier/BFO and Heterodyne oscillators warm-up drift as the dial frequency is being calculated using these actual frequencies by the DG5 emulator.

I put a 0.01uF cap between the output of the DDS and the VFO signal input on the TS-520 to block any DC component present on the output from the module.   The stock output was a little low, but worked – signals were a bit low- 3-4 S units as compared to my K3.  Looking at the datasheet for the DDS module, there is a 3.9k ohm resistor called “Rset”, which sets the DAC’s full scale output current.  I put a 2.2k resistor in parallel with it (just soldered it on top of the existing 3.9k SMD part, you can see it in the pic above) to lower the Rset value and increase the DAC output – bingo!  Signals are on par with the K3, and signal reports are good.  I’ll need to make sure I am not saturating the output or causing any distortion – I might need a buffer amplifier if there are any problems. Looked OK on the scope.

Next steps will be to get it in a case on a protoboard, and establish communications between the DG5 emulator and the VFO – the DG5 is connected to the computer, and I can have the computer tell the DDS what frequency to go to, and I might be able to use one display.  At this point I am leaning to independent boxes as the DG5 box is best on top of the TS-520, and the VFO would be best off to the side with the VFO knob and at the same general height as the existing VFO knob.  The rotary encoder I am using is a cheap mechanical type with detents, I’ll need to get a higher resolution, smoother encoder (probably optical) for the final design.

Let me know what you think!

Steve – KV6O

P.S. – I have been in touch with Todd at ToddFun, I sent him a couple of the first run PCB’s for the DG5 emulator – he’s building it and will be posting a new video with the DG5 emulator soon!  Keep your eye out for it!

I finished up on the changes and tweaks I wanted to make to the design, new schematic below.  I think I have found a US based PCB house (in Nor Cal, no less!) that can do a run for not much more that what I would pay for the China based house I used last time.  I should have the boards in less than 2 weeks as opposed to close to 4 weeks.  Since I just finished it up today, and it’s Friday, I’ll wait till Monday to submit the design, giving me 2 days to look it over for any problems.

Few things I addressed in this version:

• Rotated the board on the shield so the inputs are on the same side as the Arduino USB port.
• Fixed 3 wiring errors.
• Added headers for attaching an LCD display with contrast potentiometer and optional dropping resistor for LED back-light. This will use 2, 6 pin jumpers to connect to the LCD.
• Corrected some of the cap and resistor solder pads, should be easier to solder.
• Fixed silkscreen errors on shield headers.
• Added optional 7805 regulator and 2.1mm power jack for running standalone (no USB power). 7805 WILL need heatsink as it’s dissipating around 2W, almost twice what the board, LCD and Arduino uses since it’s dropping 14V (from the back of the TS-520) down to 5V.

I looked at using a triple gang RCA jack, but couldn’t find one with an Eagle footprint, so I am sticking with the single jacks from Sparkfun for now. There is too much risk designing the footprint off the datasheet, part unseen.

Download (PDF, 34KB)

New schematic.  Only difference from the one below should be the addition of the 7805 and supporting components.

Yippie!  The boards arrived last week and it was a few day’s before I could get to them.  They sure looked nice!

I was working on version 1.1 of the layout before these boards even arrived as I realized that the inputs for the VFO/CAR/HET were on the opposite side of the board from the USB connector – not convenient if you want to mount the assembly in a chassis.  But I was anxious to get this first version up and running to see if I got the schematic correct in Eagle.  And as is usual, I found a couple of minor problems.

Here’s a view of the bottom of the populated board – note the 3 jumpers. Turns out I made a few mistakes – one was bringing a NET on the Eagle schematic over the pin and near the chip – missing the intended connection to the pin.  Another one was missing an air wire – a ground “island” was created without a connection to ground.  And lastly, I wired to the wrong output pin on the 74LS93 counter, winding up dividing by 4 rather than 8.  All three errors were corrected with jumpers.

There is also some silkscreen mistakes, I somehow incorrectly labeled the Arduino shield pins in two areas – not critical.

Here’s the board fully populated from the top.

Few other issues with this version that I have corrected with version 1.1:

• Some of the Eagle parts used solder pads that are pretty small, making soldering a little more difficult.
• I had 2 LED’s for showing which input was selected on the LS74153, which I have removed in version 1.1 to save board space, they weren’t really necessary.

As I work on the new version in Eagle, I am trying to keep in mind a few other things now that I have an actual, working shield.

• Arduino to shield clearance – putting the RCA connectors on the same side as the USB connector makes it easy to short things out.  A little bit of electrical tape on top of the USB connector should prevent this.
• Need to keep the PLL output signals as short as possible as they are 5V TTL level representations of the original, low level signals – a potential RFI issue.  Using the shield design this isn’t really possible as the signal exits the shield to the main Arduino board on Pin 5.  A better design would put everything on one PCB, keeping HF signals nets as short as possible. Another way of reducing this issue as a good, shielded enclosure.
• Might need to add an LM7805 so it can run without being connected to the computer via USB.  I added one to my original prototype since it has an LCD display and isn’t dependent on a computer.  The LCD’s backlight and the Arduino draw enough current that a good heat sink is required to drop the 13.8VDC (provided at the back of the TS-520 for the DG5) to 5VDC.

Arduino’s with shields don’t lend themselves well to enclosures, so one possibility might be to make a larger shield that an Arduino plugs into that can slide into an extruded aluminum enclosure.  The Arduino would be a “daughter card” in this scenario, plugged in up side down on the main board.

My TS-520 still uses the prototype shown below since it’s already mounted in an enclosure and has the LCD display added, which was something I added after I sent in the version 1.0 PCB design.

Download (PDF, 31KB)

My current schematic, with 2, 6-pin jumpers to go to a 16-pin LCD display (only the first 6, and last 6 pins are used on the display).

Latest Arduino code with LCD support (note the pins used for the LCD):

[wpdm_file id=3]

Note – I have only tested this with the Arduino UNO and Duemilanove boards.  There are probably issues with other Arduino boards, such as the Leonardo, as they use the internal TIMERs for USB emulation.

If you’re interested in the eagle files, drop me a line.

Here’s a quick video of my DG5 emulator prototype buttoned up in a project box.

Still waiting on my PCB’s to arrive on the slow boat from China.  I already have changes to make – the first version PCB has the 3 RCA jacks for the 3 signals from the TS-520S on the opposite side from the Arduno’s USB – not exactly the best for mounting in a box.  And I also have added the display since I sent in the design, so I’ll have to add that in as well.  The “shield” is getting a bit tight with the DIP IC’s and new requirements, I might either go to SMD devices (for the IC’s at least) or just make the shield bigger that an Arduino.  This might actually be an advantage, as a bigger shield would allow me to slide it in a Hammond type aluminum extrusion chassis, with the Arduino plugging in on top, upside down.

Got myself one of the AS9850 DDS modules that are available on eBay for around $10.  Looking at making an external VFO for the TS-520 with one of these, so a bigger box might be a good idea.

Today I added a display, so now my the DG5 emulator actually emulates a DG5 in function – a digital display of your frequency.  I also built some Arduino shield PCB’s using Eagle and have sent them off to Itead in China, should have them back in a couple of weeks.

Here’s the display in action:

Using a parallel LCD display because the frequency counter code uses an 8 bit Timer and the only 16 bit Timer on the 328 – most of the serial based libraries use the 16 bit timer as well, causing a conflict.

A few months ago, I bought a Kenwood TS-520S. The Kenwood hybrid’s are beautiful radios, and the TS-520 is the first radio I was on the air with (on amateur HF bands) while I was in High School in the early 80’s.  So when I had an opportunity to pick one up locally, I jumped at it.

I have had a great time playing around with it and ragchewing. It takes a bit more work than my K3 or TS-2000 (tuning, calibrating) but that’s the beauty – it’s like an older car with points, condensers, and a carburetor – takes some more tweaking, but you can fiddle with it easily. I replaced the HV caps, adjusted the calibrator, and cleaned the switches and pots, but that’s about it. It just works.

I came across a site called Toddfun.com while doing some TS-520 searches, and found a series of very well documented posts (with in depth videos) about  building a Kenwood DG-5 type display for the TS-520.  The Kenwood DG-5 was an optional digital display for the TS-520/820, and on the used market they go for more than I paid for the radio!  He was using the Arduino platform, something I have been using for a few years here.  I thought, “I can do this!”, but instead of a display, I wanted to have it talk to my computer so my logging program (DXLab) could read the frequency of the radio.

There’s lots I could do better, and the Mega 328 isn’t the best platform to be doing frequency counting, updating a display, and servicing a serial port at the same time.  The frequency counter needs the limited internal timers on the 328 which limits use of I2C, SPI, and software serial libraries as far as I can see.  Nevertheless, getting the TS-520 to talk to my computer is what I set out to do, and it works beautifully!

A quick and dirty demo of it:

I don’t have a schematic for it, if you watch Todd’s video’s you can figure it out.  Basically, the signals are buffered and conditioned by the TI PLL’s, the (HFO frequency needs to be pre-scaled as it’s outside the range of the Arduino counter), and the 3 are mux’ed into the Arduino on pin 5.

Arduino DG-5 code:

/* 

Kenwood DG5 digital display emulator, sort of.

Stephen Leander, KV6O
August 22, 2014

No display in this revision, outputs Kenwood Commander commands on the Serial/USB port for a logging program (DXLab's Commander)
No idea if it will work with other programs because I haven't tested anything else!

Got the idea from Todd Harrison's website, Toddfun.com, where he outlined and built an Adrunio DG-5 emulator, with the plans of using this to display
the frequency, just like the DG-5.

http://www.toddfun.com/2013/02/07/arduino-frequency-display-for-kenwood-ts-520s-hf-ham-radio-part-1/

Counter code based on Arduino timer code by Nick Gammon
http://www.gammon.com.au/forum/?id=11504

Emulates a TS-790 for DX Commander, based on input from Dave, AA6YQ:

 From Dave AA6YQ, DXLab's author:
 From: dxlab@yahoogroups.com [mailto:dxlab@yahoogroups.com] Sent: Tuesday, August 05, 2014 10:42 PM To: dxlab@yahoogroups.com Subject: [dxlab] Kenwood

 >>>If your emulator responds to the ID; command with 

 ID007;

 >>>Commander will think its controlling a TS-790. The only other commands to which your emulator will then have to respond are IF; and FB;

 >>>Note: Commander pays attention to the following bytes of the radio's response to an IF; command:

 3-13: VFO A frequency
 29: RX vs TX status
 30: Mode
 31: VFO selection
 33: split status

 >>>Operation won't be convenient unless your emulator can correctly report the radio's mode.

See http://www.kenwood.com/i/products/info/amateur/ts_480/pdf/ts_480_pc.pdf for more on Kenwood command set.

8/22/14 - Version 1.0 Prototyped the circuit using 3 TI PLL's (74HC4046A's), a 74HC93 counter for prescaling the HFO, and 74HC153 for selecting the
signal (VFO, BFO, or HFO) to be counted by the Arduino on pin 5.

*/

//#define DEBUG //Uncomment for debugging

volatile unsigned long timerCounts;
volatile boolean counterReady;

// internal to counting routine
unsigned long overflowCount;
unsigned int timerTicks;
unsigned int timerPeriod;

unsigned long vfo = 0;
unsigned long bfo = 0;
unsigned long hfo = 0;

void startCounting (unsigned int ms)
 {
 counterReady = false; // time not up yet
 timerPeriod = ms; // how many 1 mS counts to do
 timerTicks = 0; // reset interrupt counter
 overflowCount = 0; // no overflows yet

 // reset Timer 1 and Timer 2
 TCCR1A = 0;
 TCCR1B = 0;
 TCCR2A = 0;
 TCCR2B = 0;

 // Timer 1 - counts events on pin D5
 TIMSK1 = bit (TOIE1); // interrupt on Timer 1 overflow

 // Timer 2 - gives us our 1 mS counting interval
 // 16 MHz clock (62.5 nS per tick) - prescaled by 128
 // counter increments every 8 µS.
 // So we count 125 of them, giving exactly 1000 µS (1 mS)
 TCCR2A = bit (WGM21) ; // CTC mode
 OCR2A = 124; // count up to 125 (zero relative!!!!)

 // Timer 2 - interrupt on match (ie. every 1 mS)
 TIMSK2 = bit (OCIE2A); // enable Timer2 Interrupt

 TCNT1 = 0; // Both counters to zero
 TCNT2 = 0; 

 // Reset prescalers
 GTCCR = bit (PSRASY); // reset prescaler now
 // start Timer 2
 TCCR2B = bit (CS20) | bit (CS22) ; // prescaler of 128
 // start Timer 1
 // External clock source on T1 pin (D5). Clock on rising edge.
 TCCR1B = bit (CS10) | bit (CS11) | bit (CS12);
 } // end of startCounting

ISR (TIMER1_OVF_vect)
 {
 ++overflowCount; // count number of Counter1 overflows
 } // end of TIMER1_OVF_vect

//******************************************************************
// Timer2 Interrupt Service is invoked by hardware Timer 2 every 1ms = 1000 Hz
// 16Mhz / 128 / 125 = 1000 Hz

ISR (TIMER2_COMPA_vect)
 {
 // grab counter value before it changes any more
 unsigned int timer1CounterValue;
 timer1CounterValue = TCNT1; // see datasheet, page 117 (accessing 16-bit registers)
 unsigned long overflowCopy = overflowCount;

 // see if we have reached timing period
 if (++timerTicks < timerPeriod)
 return; // not yet

 // if just missed an overflow
 if ((TIFR1 & bit (TOV1)) && timer1CounterValue < 256)
 overflowCopy++;

 // end of gate time, measurement ready

 TCCR1A = 0; // stop timer 1
 TCCR1B = 0; 

 TCCR2A = 0; // stop timer 2
 TCCR2B = 0; 

 TIMSK1 = 0; // disable Timer1 Interrupt
 TIMSK2 = 0; // disable Timer2 Interrupt

 // calculate total count
 timerCounts = (overflowCopy << 16) + timer1CounterValue; // each overflow is 65536 more
 counterReady = true; // set global flag for end count period
 } // end of TIMER2_COMPA_vect

String inputString = ""; // a string to hold incoming command date
boolean stringComplete = false; // whether the string is complete

void setup ()
 {
 pinMode(2, OUTPUT); // for signal select on the 74HC153. Using Pins 2 and 3.
 pinMode(3, OUTPUT);

 Serial.begin(9600);
 // reserve 200 bytes for the inputString:
 inputString.reserve(200);

 // end of setup

 }

void loop ()
 {
 for (int x=0; x < 3; x++){ // Loop thru the 3 signals to count the signals.
 if (x==0) { //Select VFO
 digitalWrite(2, LOW);
 digitalWrite(3, HIGH);
 }
 if (x==1) { //Select BFO
 digitalWrite(2, HIGH);
 digitalWrite(3, LOW);
 }

 if (x==2) { //Select HFO
 digitalWrite(2, LOW);
 digitalWrite(3, LOW);
 } 

delay (20); //settle time

 // stop Timer 0 interrupts from throwing the count out
 byte oldTCCR0A = TCCR0A;
 byte oldTCCR0B = TCCR0B;
 TCCR0A = 0; // stop timer 0
 TCCR0B = 0; 

 startCounting (100); // how many mS to count for

 while (!counterReady)
 { } // loop until count over

 // adjust counts by counting interval to give frequency in Hz
 float frq = (timerCounts * 1000.0) / timerPeriod;

// Serial.print (" freq: ");
// Serial.print ((unsigned long) frq);

 if (x==0)vfo=frq; // load frequency's into vfo, bfo, and hfo.
 if (x==1)bfo=frq;
 if (x==2)hfo=(frq*8);

#ifdef DEBUG // for debugging and monitoring the results.
Serial.print("VFO: ");
Serial.print (vfo);
Serial.print(" BFO: ");
Serial.print (bfo);
Serial.print(" HFO: ");
Serial.print (hfo);
Serial.print (" FREQ: ");
Serial.println (hfo-(bfo+vfo));

#endif

 // restart timer 0
 TCCR0A = oldTCCR0A;
 TCCR0B = oldTCCR0B;

 }

 // Check serial port to see if we have a command
 if (stringComplete) {

 if (inputString == "ID;") { //ID the radio as a "ID007" - Kenwood TS790. There is no TS-520S. ;-)
 Serial.print("ID007;");
 }
 else if (inputString == "FB;"){ // Probably not needed as Commander uses the "IF" command, used for debugging..
 Serial.print("FB00014195000;");
 }
 else if (inputString == "IF;"){

 if ((hfo-(bfo+vfo)) > 9000000){ // Used 9Mhz as the cutoff so I could properly format the string with the additiona digit returned above 10Mhz.
 Serial.print ("IF000");
 Serial.print (hfo-(bfo+vfo));
 Serial.print ("000000000000000020000000;"); // The "2" is the mode, above 9Mhz it returns "USB"
 }
 else
 {
 Serial.print ("IF0000");
 Serial.print (hfo-(bfo+vfo));
 Serial.print ("000000000000000010000000;"); // Mode set to 1 for "LSB".
 }
 } 

 // clear the string:
 inputString = "";
 stringComplete = false;

 // end of loop

 }
 } 

 /*
 SerialEvent occurs whenever a new data comes in the
 hardware serial RX. This routine is run between each
 time loop() runs, so using delay inside loop can delay
 response. Multiple bytes of data may be available.
 */

void serialEvent() {
 while (Serial.available()) {
 // get the new byte:
 char inChar = (char)Serial.read();
 // add it to the inputString:
 inputString += inChar;
 // if the incoming character is a newline, set a flag
 // so the main loop can do something about it:
 if (inChar == ';') { // Look for ";" - this is the Kenwood command terminator.
 stringComplete = true;
 }
 }
} 

[wpdm_file id=2 title=”true desc=”true”]

Back in the summer of 2013 I was looking for a replacement for my laptop that was sending weather updates from my Peet Bros U2100 to the CWOP network.  My laptop died, and I thought this would be the perfect application for my Raspberry Pi.  I found a script the the U800 (see post below for more) and got it working for the U2100, but it needed a few tweaks to work properly with the U2100.  Specifically, the changes I made were:

• Changed time to localtime() – be sure your rasperry pi is set to the correct timezone.
• Changed humidity as  the U2100 reports 3 digits.
• Changed wind reporting as U2100 reports in kph, not mph.
• Changed temp reporting to handle negative numbers.

This code has been working for my U2100 for over 6 months with few problems, such as
the negative temps not being handled correctly being the last thing fixed. I wasn’t
aware of the issue till it got cold enough!   See the original post for more on how to use it with the RPi, many thanks to CloudHopper who provided it.

My weather station’s data can be seen HERE. Every once and a while I see the local news show my stations data on the air – cool!

[wpdm_file id=1]

I have been playing around with my Raspberry Pi for a while here, my original plan was to use it as the high level control for a Arduino based repeater controller (handling the low level repeater stuff (timers, CWID, etc.), but I had my home Windows based server die on me and I needed something to update the CWOP network with my weather station data.   The server I had was a Windows 2003 server running on an old T42 IBM Thinkpad with an external USB drive. It died a somewhat noisy death as the CPU cooling fan finally seized (made an awful racket for about 24 hours before giving up the ghost).  I had performed surgery once before to replace the fan, but as I didn’t really need a full Windows server to perform a simple web update every 8 minutes, and I also have a 1TB LG-NAS device to act as a file server – so why have this power hungry machine to perform this simple task?  Enter the Raspberry Pi…

I found a post about using PHP on the Raspberry Pi to update the CWOP network from data collected from a Peet Bros U800 – I was using a Peet Bros U2100, so I figured I’d give it a try.
I made a few changes as the wind speed was being reported in kph, not mph, the humidity was being reported incorrectly at 100% (needs to report “00”), and I set it up to report local time.  Success!  The RasPi was now uploading my WX reports to CWOP every 8 minutes and taking a fraction of the power. It’s a low powered machine on 2 levels – doesn’t draw much current (about 2.5W), but it’s not a high performance workstation either.  But it’s perfect for this application – no need to tie up a power hungry computer 7/24 to perform a simple task.

Since this is barely using the RasPi capabilities, I am playing around with other tasks it can perform – currently it’s also hosting an inexpensive SDR module (Realtek RTL2832U based USB TV tuner) to receive some local FM data and decode it.  I am still not 100% on the legality here (it’s public safety POCSAG pages) – I need to clear this up before I take it much further. I am a subscriber to this paging system as a firefighter, and I have an application in mind (fire station paging “receiver”), so I am a legitimate user – but I still want to make sure this is OK.

More on how to do this can be found here.