AmateurRadio.com

This is my latest eBay acquisition: a Dymo LabelManager 210D. Clearly there is not a big demand for these things on eBay – I got it for £5.50, though the postage was nearly as much again. So the total cost was less than a third what it would have been to buy a new one. That is about what it is worth to me as I only wanted it to make front panel labels for my home-brew projects.

The labelmaker was used and didn’t come with a manual or power supply but that wasn’t a problem. Google quickly located a PDF manual to print out and I have plenty of power sources in the shack. The one thing I will have to watch is that although the DC input uses a standard barrel type connector the centre pin is negative which is the opposite of everything else that uses that type of connector. So I will have to remember to check the polarity before plugging it in.

The label tape that came with the machine produces black text on white. But you can buy cassettes of tape in different colours. This particular model accepts cassettes that include a choice of white on transparent, which will look better on painted front panels.

Black on transparent would look better on bare metal than these labels which I made for the front panel of my 10MHz rubidium frequency standard but they still look better than the old embossed Dymo labels we used to use in the 70s. (I also have none too fond memories of trying to label front panels using Letraset.) Life is much easier for those constructors who don’t care what their projects look like but I always like to try to make them look professional even if the construction itself is definitely amateur!

My homebrew WX-1 weather station, which transmits data directly on 144.800MHz APRS using a PIC based packet modulator and a 10mW VHF transmitter module, is decoded by my VX-8GR and my Kenwood TM-D710 but not my TH-D72 or my homebrew TNC. This is annoying. A week ago I looked at the packet modulation from various devices and found that the tone frequencies of the WX-1 were about 50Hz too high. So I thought I would try to fix it.

The PIC source code for the weather station is available for download. The program code that generates the packet modulation is a bit beyond me, but I think it works by executing a loop and pushing binary values out of 4 ports which are connected to 1K0, 2K0, 3K9 and 5K1 value resistors in such a way as to produce a stepwise approximation of a sine wave. It seemed to me that to lower the tone frequencies I needed to slow the loop down a tad. After a bit of trial and error inserting a nop (no-operation) instruction in various likely-looking places I managed to get the tones nicely symmetrically positioned around the 1200Hz/2200Hz nominal frequencies for 1200baud packet. But the TH-D72 and homebrew TNC still refused to decode any packets!

Wondering what to try next, it occurred to me that the tone frequencies were not the only parameters of a packet signal. There is also the baud rate. I also remembered that the MixW sound card software prints out the measured baud rate next to each decoded packet. So I hooked MixW up to a transceiver and sound card and gave it a selection of signals to decode. I found that whilst my two Kenwood transceivers and the Yaesu VX-8GR all measured 1200 or 1199baud, the WX-1 recorded a value of 1208 baud. That had to be the cause of the problem.

Unfortunately I can’t find a solution. I thought that slowing down the PIC processor’s clock might make the necessary adjustment, so borrowing an idea from a PIC frequency counter circuit I replaced one of the fixed capacitors on the oscillator crystal with a variable one. This made a whole 1 baud of difference! Clearly that approach isn’t going to get me anywhere unless I get myself a 19.867MHz crystal. If I’d done the math in the first place I’d have realized I wasn’t going to pull the oscillator that far with a trimmer.

The solution, if there is one, has to be in the code. But I don’t understand it nor can I find any comments that would point to a routine or value that affects the baud rate. Give me a circuit with discrete components any day. If this is the future of electronic experimentation I don’t think there’s a place for me in it.

Roger G3XBM has started a new project: a simple sideband transceiver for the 10m band. Roger’s projects are always interesting so this page will be one to keep an eye on. If it can be made small enough to fit into a hand held case this could make a great portable radio capable of DX contacts during the sporadic-E conditions during the summer.

Regular readers will know that last year I worked the Czech Republic using a hand-held Intek H-520 FM transceiver with a telescopic whip. The Intek, despite being a nice looking radio, is actually a horrible piece of kit with a PA that sucks the power out of the rig’s batteries, especially if the antenna presents anything other than a perfect SWR. And the trouble with 10m FM in the summer is that too many people are trying to use too few frequencies so there is terrible QRM and the “capture effect” means that only the strongest station is heard.

A little double-sideband rig, even with only a couple of watts output, ought to work much better. I shall be following Roger’s project with interest and intend to make this my next radio project too.

I have mentioned before that when I’m not in the shack I like to run a little program called aprsg to gate all the local APRS activity to a UHF frequency so I can see what is going on in the local APRS world using an APRS-capable HT. I have set up a system using sound card software, a USB sound device and my FT-817ND to do this. But I would like to make a standalone box for this. The first step in this project is to find a simple, cheap TNC.

There are products that would fit the bill from Byonics and Argent Data. Unfortunately they are not available in the UK and the cost of importing these kits from the US makes them less than cheap. I looked at the Fox Delta Mini TNC. But that is not a KISS TNC, as was confirmed by an email to Dinesh, the proprietor of Fox Delta.

Whilst searching around for possible solutions I came across a design for a TNC using a PIC16F88 microcontroller by WB8WGA that was originally published several years ago as an article in the ARRL experimenter magazine QEX. It has been modified by DJ7OO and ZL3AME, who had developed a stripboard layout for it. I had all the bits apart from the microcontroller and the clock crystal, which were quickly sourced on eBay. So I thought it would be an interesting project to build and experiment with.

ZL3AME’s stripboard layout results in some quite lengthy signal paths. Despite this, the TNC worked first time, with just a minor glitch caused by my mis-wiring the PTT connection on the transceiver connector. (I have a standardized interface that I use on all my projects, with an 8-pin mini-DIN connector for audio and PTT to the transceiver, and a 6-pin mini-DIN connector for serial and GPS connections. I can then have a standard set of cables to hook the projects up to any radio, connect to the computer or a GPS, etc.)

With all the bits of APRS kit I have it was easy to generate some test signals and I soon had packets being decoded on the terminal screen. I wondered how sensitive the TNC would be as it uses the PIC16F88 to do the decoding instead of a modem chip like the MX614. I have not seen any DX packets decoded yet, but it does seem that decoding success is dependent on the audio level into the TNC. All of my APRS generators were decoded with the exception of my weather station, which has rather low deviation. When using the old Kenwood TH-205E as a receiver I could increase the volume so the weather station was decoded, at the expense of reliable decoding of the other radios. That was not even an option when using the DATA output of a radio, which has a fixed level. I suspect that performance could be improved if you could add an audio ALC on the input.

The TNC can also send APRS beacons and work as a fill-in digipeater. To send a fixed position you can simply encode the position co-ordinates into the beacon text. There are also a couple of jumpers that allow you to connect a GPS to the serial port, which would allow the TNC to work as a standalone tracker. I haven’t tried that, since I already have a standalone tracker. There are no Connect or Disconnect commands so it cannot be used as it stands for packet radio.

This is not a KISS TNC, so it can’t be used with APRSIS32 or aprsg or any of the software I use. I installed UI-View which apparently has the ability to use a TNC for APRS in Converse mode, but it doesn’t work with that either. I think that is due to the fact that the TNC expects CR/LF at the end of each command instead of just CR, so fixing that will be the task of my first attempt at modifying the firmware. Other things I would like to try are making it work at 300baud (for HF packet) instead of 1200baud, and implementing KISS mode. In KISS mode the PC software provides the complete packet and the TNC just has to add a CRC and send it. So in theory it should be simpler to implement than the existing code which has to construct an AX.25 packet from the information entered plus parameters previously set in the configuration. We shall see. The TNC source code is written in assembler, and trying to understand assembler code is to me like not being able to see the wood for the trees. But it will be a good incentive for me to look “under the hood” at how APRS, packet and AX.25 really work.

Many of the links to original information about this project seem now to be dead and I had to do quite a lot of searching to collect the information I have. For the benefit of anyone else who would like to try building one of these TNCs I have assembled all the files and information I found into a zip file which you can download here.

What is one supposed to do with the BNC connector pictured right?

I ordered 5x Crimp On BNC Plugs from eBay, expecting to get plugs with a narrow body and separate small piece of tube that you use to crimp the braid of the cable to the body of the plug. What I actually got was these, which I already had a couple of and didn’t know how to use. The only way I can see that you could use these is to crimp the large diameter barrel on to the braid itself, but with nothing but the nylon insulation beneath it you are not going to get a good contact. I think they are useless, though I did make a QRPP dummy load from one of the originals as two 1/4W 100 ohm resistors in parallel just fit inside the body of the plug and you can solder the ground ends to the outer.

I guess soldering the braid is the answer, but that isn’t what I bought crimp on plugs for and it isn’t going to make a very neat job.

A few days ago I got the urge to build a memory keyer into my MFJ Cub. There isn’t much of a practical reason for doing this as the noise level on 20m makes the band unusable without the MFJ Noise Canceler which is plumbed into my K3 and too much hassle to disconnect and use with anything else. But I thought it would be a fun thing to do.

I really wanted to use the SKC keyer that is in the DC20B transceiver as it has some nice features and is easy to use. It uses an Atmel ATTiny13 microcontroller. I happened to have a spare one in my parts box and I had managed to find a way to program it using a PICkit2 programmer designed for Microchip parts. Unfortunately my unorthodox programmer always fails trying to read the contents of the chip so I was unable to copy the code from the chip in the DC20B to my spare chip. Nor could I find a source or hex file for the SKC keyer or indeed any other keyer using an ATTiny13 chip. So I had to give that idea up.

I did find a couple of source files for Microchip PIC based keyers on K1EL’s website so I decided I would have to go with that. A couple of years ago I had bought a MikroElektronika EasyPIC5 development system with the intention of experimenting with microchips. Unfortunately I found PIC programming too difficult so I gave up. However I could compile the K1EL keyer code and use the EasyPIC5 to program it into a chip, which I could then build into a keyer that would go in the Cub. Perhaps I could even understand enough of the code to modify it to work the way I wanted.

My first problem was compiling the code. The compiler seemed to object to a label called CONFIG in the source code which caused a fatal error. Eventually I had a lightbulb moment that perhaps CONFIG was a reserved word in the current version of the MPLAB compiler, so I changed the label and the reference to it to CONF. That overcame that problem.

The other problem was that numerous lines in the program produced a message 306, “Crossing page boundary – ensure page bits are set.” I didn’t have a clue what that meant, and although Google turned up a few pages that mentioned the message I didn’t understand what I was supposed to do about it.

The keyer code on K1EL’s website was written for the PIC12C509A chip so I had ordered a couple from PIC Projects on eBay. They arrived in the post this morning. That was when I discovered the second problem. The EasyPIC5 development board does not support PIC12C509A chips. In fact, it doesn’t support any PICs that have C in the number, only ones that have F. It appears that the F chips have Flash memory and can be reprogrammed while the C chips can only be programmed once. So I have two 12C509A chips I can’t use.

I have now ordered some 12F509 chips which are supposed to be compatible with the 12C509 and which my programmer is supposed to be able to program. In a few days time I will discover if that is true and whether message 306 means anything important.

I finally solved the problem with the cable I was trying to make to interface my VX-8GR with the computer, as described in my last post. As I had begun to suspect, the trouble was caused by the 2.5mm jack plug not fitting properly in the VX-8GR data port socket.

As suggested by one of my readers, I tried the cable in the COM port of the TH-D72. Although I couldn’t figure out how to make data appear on this port, I did see some output when turning the TNC on and off which suggested my cable did work.

I then tried it back on the VX-8GR and used my oscilloscope to look for anything digital. I didn’t see anything. I then tried another 2.5mm jack with the sleeve off so I could get the ‘scope probe on the solder tags and with a firm press it went in with a click. I now saw -5.6 V on the TX pin – clearly an RS-232 signal level.

The jack I originally used had a plastic sleeve or cover and the diameter of the base was just a bit too much to allow it to go all the way in. One with a metal sleeve had a slightly smaller diameter base. The metal sleeve itself interfered with inserting the jack, but I could put the plastic sleeve on that jack and it would still go in. So that, finally, is what I did, and I now have a VX-8GR PC cable that works. It also works with the COM port of the TH-D72 should I find a use for that.

As a ham and electronics enthusiast I don’t believe in buying things I can make myself, but sometimes making it yourself can turn out to be more trouble than it is worth!