F and C confusion

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.

Successful outcome

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!

Incommunicado

I have spent a frustrating couple of hours trying to make a PC cable to communicate with the VX-8GR. In the VX-8 Yahoo group it was stated that the cable is the same as for the Kenwood TH-D7AG a diagram of which is given in YO3HJV's blog. It was also pointed out to me that there is a diagram in the back of the manual - the one place I never thought to look!

It is easy enough to make up. No level shifting components needed. Just a 2.5mm stereo jack for the radio end and a 9-pin D plug for the PC end. But the damn thing refuses to work.

I have tried a Prolific USB to serial adapter and an FTDI one. I've tried the FTBVX8G software and I've tried a terminal program to see if I can detect any data. Nothing. Nada. Incommunicado. I know the cable is OK because if I short between tip and ring of the jack plug I can type in the terminal program and see the text I typed echoed back over the connection.

The only thing I can think of is that the standard 2.5mm stereo plugs I have here are a bit too short. It seems to me that the  plug isn't locking firmly into place, more that the radio is trying to push it back out again. It's as if the tip needs to be a bit longer to get past the spring loaded contact in the socket. I measure 7/16in from the base of the plug to the tip of it. I had a similar problem trying to make a cable to send audio from my FoxTrak APRS tracker into my Motorola GP300. Then I had a plug from a speaker mic to compare it with and I could see that it needed to be longer.

Perhaps someone who has a VX-8G PC cable that works could measure the plug on theirs. Or perhaps someone will spot the stupid wiring mistake I've made from the photo I've posted.

Underwhelming update

I see that on Christmas Day (though of course it wasn't Christmas Day in Ukraine) the developers of the MixW sound card digital modes software released the long awaited MixW version 3. I couldn't find much information on the website about what new features it contained. "MixW3 is a next step on the way to the upcoming multiplatform MixW project. It proposes a new Telnet dialog with talk over DxCluster support and a possibility to have a backup copies of your log on our server, dx.mixw.net." Nothing about what's new in the version available now. None of these "proposals" are things that I personally want, and I'm not even sure that chat over the DX Cluster will be welcomed by many users - there are enough non-spots cluttering it up already."

I decided to download the new version to see what I could find. As the screenshot above shows, it looks pretty much like MixW 2.19 which has been looking dated for years. I didn't see any new modes, nor support for RSID. What is even more disappointing, given the apparent lack of new features, is that this upgrade is not free. The website states "MixW3 upgrade is free for those who stay with us 10 years or more." I registered MixW a long time ago but not long enough, it seems. An upgrade to MixW3 will cost me the equivalent of $20 plus VAT.

At the time I paid for MixW It really was the premier digital modes software and I felt it was well worth the money. But after a few years it seemed as if MixW was neglected. In the intervening time new, more modern looking full featured competitors came on to the scene like Ham Radio Deluxe and Fldigi, which were also free. I switched to Fldigi a couple of years ago as MixW never properly supported the K3. And nothing I can see in the new version gives me any inclination to switch back, even if I could use the new version for free.

There is nothing wrong with charging for ham radio software. But charging for an upgrade in which the only apparent change is the version number and then expecting buyers to hang on patiently while new features are added won't work in a market where so many good products are free. Perhaps the multiplatform MixW 4 will be a must-have upgrade. I'm happy to wait and see.

Installing APRSISCE/32

I have just added a new article, Installing APRSISCE/32, to my website G4ILO's Shack. It is a pictorial tutorial showing how to install the APRS client written by KJ4ERJ and get it running.

Over the next couple of months I hope to add several more tutorials covering different aspects of using the program and connecting it to a radio, in the hope that they will encourage more people to get on to APRS or at least use the information that it can provide.