AmateurRadio.com

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.

I think I may have discovered one of the best kept secrets in radio. I have been thinking, off and on, about how to make a very low power 2m FM transmitter in order to get weather data into my APRS system wirelessly. A circuit using the Motorola MC2833P chip is quite easy to build, and I even have one in my parts box, but a custom crystal to multiply up to 144.800MHz would cost about £25 to be made which just isn’t worth it.

One day I was browsing looking at various APRS articles and came across a tracker someone had built using a VHF transmitter module from Radiometrix. I had come across this site before but thought that a) these modules were only for transmitting digital data not the AFSK that we use, b) they were not manufactured for amateur frequencies and c) they were not available in one-off quantities for individual private purchasers. I submitted an enquiry, stating that I was interested in purchasing one TX1 low power (10mW) module on 144.800MHz if the price was within my amateur budget, and was amazed to be informed that they would be happy to offer the module for £13.00 plus carriage and VAT, with a lead time of five days. In total it came to not much more than £20 which is amazing considering many professional electronics suppliers specify a minimum order value greater than that.

The picture of the module is much larger than it actually is – the pins are the standard 0.1in spacing. As I am nowhere near actually needing to use it at the moment, I hooked it up on the breadboard to give it a quick test. The module does indeed accept an audio input: as described in the data sheet you should bias the input pin and then feed it with audio at a couple of volts amplitude via a blocking capacitor. I lashed it up to my FoxTrak APRS tracker and a braaap was received and decoded by my 2m APRS gateway which was enough of a test to be going on with.

There are several other products with interesting ham radio applications on the Radiometrix website. The HX1 is a high power (300mW) version of the module I bought. With the addition of a PA I could turn my FoxTrak into a standalone tracker. Even by itself it would probably have quite a decent range from the fell tops. Also of interest is the SHX1 which is described as “a small multi-channel 25kHz narrow band VHF transceiver with up to 500mW RF power output, usable for 144MHz band amateur applications.” I think you could build a little hand-held transceiver with one of these, just for fun.

Many of these products aren’t in the online shop so you can’t find out the price or buy online, which is probably just as well as I could see myself ordering some more of these toys for something to play with over Christmas. I would certainly be interested to hear from anyone who has used, plans to use or has some ideas for using any of these little radio modules from Radiometrix.

Today was one of those perfect days you sometimes get in winter. It was too good to stay indoors, especially as rain is forecast for tomorrow, so after lunch I packed my APRS tracker and Motorola GP300 in my rucksack and went for a short hike up Binsey, one of the Wainwright hills in the northern Lake District.

There had been a frost overnight and even now in the early afternoon the temperature was only a degree or two above freezing. Looking towards the central Lake District across Bassenthwaite Lake you could see the distant hills were covered with a light dusting of snow.

On the way up to the summit of Binsey I observed that my tracker was not transmitting. The tiny red LED on the GPS was flashing to say the receiver was working but the GPS OK light on the tracker itself was out. If I switched the unit off and then on it would send its position as soon as GPS lock was obtained, but that was usually all I got. When the beacon was sent I also heard a few noises from the Motorola receiver. None of this had happened during testing in the shack, but a cold fell-top is not the ideal place for troubleshooting. The lack of position reports received during my walk on Sunday was probably not due to conditions

On my descent I enjoyed the view of the snow-dusted Skiddaw range against an almost cloudless blue sky. To think, some people are stuck in an office on a day like this! (OK, I know, I don’t have to rub it in!)

Back home I connected up my tracker on the bench and it worked perfectly again. I then put it in my rucksack as it had been while I was out and it started to behave as it had while I was out. Some braaps were accompanied by a sort of farting sound that was probably RF feedback. I’m pretty sure RF is getting in somewhere and causing the tracker board to misbehave, but the question is: where?

I’ve tried moving cables about and clipping ferrites on the leads but so far I’m not sure what is the cause. I hate this kind of problem which can have you going round in circles thinking you’ve fixed it and then it recurs. I’m not sure yet if the RF is being picked up on one of the cables – both the PS/2 GPS cable and the curly Motorola cable are quite long for this application – or whether it is getting to the module directly since it is only in a plastic case. Perhaps I should try it in a die cast box. Any ideas?

Having an interest in weak signal narrow band modes, not to mention APRS which requires you to park your receiver on a specific frequency, I have always wished that the frequency readout on my radios could be relied upon. The QRSS band, for example, is only 100Hz wide. If your dial reading is out by that much, you’ll miss it completely.

Many people try to calibrate their transceivers using WWV but that is not often a very good signal over here, and what with all the other carriers around 10MHz – many of them locally generated – you can never be sure that you have tuned to the right signal. I have wanted an accurate frequency reference for some time so a couple of weeks ago, following a comment by QRSS enthusiast Steve G0XAR, I ordered an Efratom LPRO-101 rubidium frequency standard on eBay. It arrived in about a week.

The unit I bought cost about £50 and came with a plug for the 10-pin connector and a 24V switched-mode power supply. These second hand units are widely available. New, they cost over $1,000 even in quantity. They are used in cellular base stations and are manufactured to have a maintenance-free life of ten years. To ensure reliable service the cellphone network providers take the equipment out of service before the ten years is up after which it is presumably shipped to China for reclamation. The used units should have several years of life in them, especially in occasional amateur use.

Rubidium frequency standards work by locking a crystal oscillator to the very precise frequency at which the amount of light from a rubidium lamp dips due to a phenomenon known as the hyperfine transition. A synthesizer locked to a reference oscillator is swept through this frequency until the dip is detected. The LPRO-101 includes an oven for the reference crystal, circuits to detect the dip and lock the oscillator, an output that tells you when the unit is locked, and the frequency reference output at 10MHz. The connector also provides signals that can tell you the state of health of the rubidium lamp. Once that fails you may as well scrap the unit because it can only be replaced by the manufacturer at a cost far in excess of what you paid for it.

To use the LPRO-101 you could simply attach a 24V supply and connect a cable to the 10MHz output. However, it’s useful to have a circuit that shows you when the unit is locked on frequency. I used one shown in an article by KA7OEI built up on a piece of Veroboard, which uses a dual-colour LED to light red when the reference oscillator is unlocked and green when it is locked. You can see the circuit board inside the partially assembled case.

The voltage regulator and crystal oven inside the LPRO-101 generate a lot of heat so the unit is intended to be mounted on a heat sink. I purchased a Hammond extruded aluminium case to use for the project, which should provide reasonable heat sinking for the module.

One thing I learned from researching on the internet is that the LPRO-101 will run cooler when operated from its minimum recommended supply of 19V. This just so happens to be the output voltage of the power supply for an old Toshiba laptop whose screen failed so I decided to use that instead of the 24V supply that was sent by the seller.

The other thing I learned is that the rubidium lamps wear out with time. When they are made, the manufacturer ensures that they contain sufficient rubidium to achieve the stated maintenance free life of ten years, so the expected life in continuous use would be ten years less the use it has already had.

If I ran the unit all the time my rig is on – for example as an external frequency reference for a transceiver – then it is going to fail sooner or later. If I only use it for frequency calibration purposes, switching it on only when needed, then it will probably outlast me. The TCXO in my K3 is pretty stable so I should be able to obtain adequate accuracy for my purposes by manually calibrating the master oscillator using the rubidium standard and repeating this as often as necessary. How often that turns out to be, we’ll see.

Here is the finished unit. Annoyingly, I messed up the front panel of the rather expensive Hammond case. Originally I had intended to use an SMA socket for the output but I didn’t get the holes for its two mounting screws in the right place and after filing to fit it looked unsightly. So I fitted a BNC socket instead which is what I should have done in the first place. Unfortunately you can see the two holes for the SMA mounting screws either side of the BNC socket. So my frequency standard doesn’t look quite as professional as this one built by DL2MDQ. Oh well, it’s only a piece of test equipment!

My FoxTrak APRS tracker board is now installed in a plastic case, together with 4 x AA NiMH cells which provide near enough 5V to power both the tracker and the GPS. Two mini-DIN sockets on the side of the case allow connection to a PS/2 GPS or PC for configuration, and to the radio. Now I just have to make up interface cables to my radios and install the top half of the case after drilling it and installing the charger socket for the battery.

I purchased a GlobalSat BR-355 PS/2 GPS receiver on eBay and it works very well indeed with the FoxTrak, much better than the GPS in the Yaesu VX-8GR. It gets a fix within a couple of minutes when it is sitting on the shack window sill, unlike the VX-8GR which often never finds its position indoors at all, and the position remains rock steady unlike the Yaesu which tends to wander about.

I wanted to make a cable to use the tracker with my Motorola GP-300 hand-held. However I found that the jack plugs you can buy from component suppliers have too wide a body and can’t plug all the way in to the sockets on the top of the radio, which are a bit recessed. It appears that you need to use a proper moulded plug with the two pins. A cable for the Motorola GP-300 is available on eBay, so I’m waiting for one to arrive.

I was luckier with the old Kenwood TH-205E. The sockets for external mic, PTT and speaker are flush with the top of the case and the cable I made up using separate plugs works fine. Lacking a deviation meter I adjusted the audio output so the braaps sounded as loud as those from other APRS stations.

However, the TH-205E is a bit big and heavy for portable use, especially as it has a high capacity Ni-Cad battery pack (the original being as dead as a dodo.) I had expected the cable to work just as well with the little TH-F7E, because the Kenwood speaker-mic I have works with both radios. But although PTT works on the smaller Kenwood there is virtually no audio. I have to turn the audio up to maximum on the FoxTrak to get enough signal to be decoded by my gateway, and the deviation is still too low.

I am completely foxed by this problem. The only thing I can think of is that it is something to do with using two separate plugs and not the proper moulded two-pin connector used by the speaker-mic. Perhaps, as with the Motorola, the wide body of the plugs is preventing them from going far enough in to disconnect the internal microphone, which is shorting out the audio. Unfortunately the only way to prove this hypothesis would be to buy a cheap Kenwood speaker-mic or programming cable on eBay and cut the cable off. It’s a bit of a gamble, as I don’t know for sure if that’s the solution, and the cables in some of those cheap mics from China are very poorly screened so I could end up with an RF-induced problem.

Last night I received an email from Steve G0XAR to let me know that a replacement chip for the QRSS beacon had been programmed but not posted yet as he had been ill with a bad cold. However my impatience had got the better of me and I started wondering whether I could reprogram the chip myself. Perhaps this was the opportunity I needed to start playing with microcontrollers? The source code was on Hans G0UPL’s website, the development tools were all free. All I would need is a programmer, and I was sure I had seen circuits for microcontroller programmers knocked up from junk box parts on the web.

A bit of searching revealed that simple programmers for the AVR ATtiny13 chip can easily be made, such as this one built by Alan, VK2ZAY, but they require a parallel port, an antique piece of hardware that went out of use around the time Bill Gates made his first billion and is now as obsolete as the USB port will one day surely be.

However I also came across an article that described how to program AVR microcontrollers using a Microchip PICkit2 programmer. A couple of years ago I obtained a PICkit2 because it was being offered in an electronics magazine for just the cost of the postage. Apart from running a couple of demo programs I had never done anything with it. What more of an excuse did I need?

In less than an hour I had downloaded and installed the AVR Studio software, WinAVR which was also needed, PK2AVRISP (the program which makes the PICkit2 look like an AVRISP or STK500 programmer), soldered six short leads to a 6-way header to attach to the PICkit2 and wired up the connections to the chip on my solderless breadboard. I already had a pair of virtual serial ports set up on the shack PC to use with the TrueTTY packet TNC so I was good to go.

PK2AVRISP detected my PICkit2 and I assigned it to one of the pair of virtual serial ports. The QRSS keyer program compiled in a couple of seconds and I was ready to program the chip. I selected the AVRISP programmer on the other end of the virtual serial port pair. The programmer read the signature from the chip and reported it was correct – an encouraging sign. Then I wrote the hex code into the flash memory. The write appeared to work but the verification failed with “WARNING: FLASH byte address 0×0006 is 0xFF (should be 0xCF).”

I searched forums for solutions to this error and tried various suggestions such as reducing the SPI clock speed or trying the STK500 option but I could not get past this error. One person claimed that he had somehow managed to program the chip despite the error so I put it back in the QRSS keyer, but now I just got a steady carrier with no keying at all. Oh dear!

I tried programming the code again this time using the avrdude command line programming software which is included with WinAVR but can’t be run directly from AVR Studio. This appeared to work, no error was displayed when the code was verified, but the chip still did not work when put back in the keyer.

To avoid moving the chip back and forth to test it after each programming attempt I tried programming a simple LED flasher into it so I could test it on the breadboard (hence the LEDs in the photo.) This works fine if I simply ignore the flash verification error. So the chip isn’t bricked. But why the keyer program doesn’t work is a mystery. I assume it should flash the LED on pin 3 in time with the keying, but it doesn’t.

Obviously a new chip will get the QRSS keyer working again but having spent all this time on trying to do it myself I would like to know why I couldn’t. Usually when something doesn’t work it is because I have made a stupid error, but I can’t see what I have done wrong. It’s so frustrating.

The FoxTrak APRS tracker board is finished, and works, but I took the long way round getting there. Building the board was by far the easiest part of the project. Setting up and testing it was a trial of patience, ingenuity and lateral thinking.

After building the tracker it has to be programmed with your call and a few other options by connecting it to a computer and running some configuration software. The documentation was not specific and I was not sure if I could just connect it to a serial port. The tracker is just a 16F84A PIC which works at TTL logic levels, but a PC serial port produces RS-232 at +/- 12V. What’s more, the FoxTrak website mentions a null modem adapter with MAX232 chip which is a TTL to RS-232 level converter, suggesting this might be required. However I had a USB to TTL serial adapter module that I bought some time ago for another project so I decided I should be able to use that. I did, and the configuration software was unable to detect the tracker.

After thinking about it for a few hours I decided to take a chance and use a normal serial connection. I used a Prolific USB to RS-232 serial adapter. That worked, and I was able to program my settings into the tracker.

The next step was to calibrate the tones produced by the tracker. 1200baud packet uses mark and space tones of 1200 and 2200Hz. Due to some hardware limitation of the 16F84A PIC, the tones are actually spaced about 1050Hz apart and the calibration software uses a default setting that puts them as near equally spaced over a centre frequency of 1700Hz as possible so the error in the generated tone frequency is shared equally between mark and space. To generate constant tones so you can measure them using a frequency counter you must connect to the tracker using a terminal program and send Esc T 0 or Esc T 1. I tried this using Windows HyperTerminal and nothing happened.

I now wasted quite a lot of time as I didn’t know what was supposed to happen. I didn’t know whether the PTT LED would illuminate when the test tone was produced so I didn’t know whether the absence of a tone was because the PIC hadn’t received the command to send it or some other reason. Eventually I decided that perhaps HyperTerminal wasn’t talking to the tracker so I tried another terminal program called RealTerm. This time Esc T 0 immediately produced a nice waveform on my oscilloscope which also counted the frequency for me and told me the tones were within 1Hz of the documented frequency for the default calibration value. Good, or so I thought.

Now I wanted to feed the audio output into a radio and see if my Kenwood TM-D710 would decode the packets it produced. I had wired a push-to-make switch in the “Transmit Now” position but what I didn’t know was whether the tracker would transmit a packet when it had no GPS data. I don’t have a GPS I can use with it at the moment, but even if I had, I would have trouble getting a fix inside the shack due to the high electrical interference levels.

The tracker wouldn’t transmit anything without a valid GPS fix, but it occurred to me that it must be possible to write a program that pretends to be a GPS and outputs NMEA packets to a serial port in order to test GPS applications. I didn’t want to write such a program, but other people had the same idea and Google found me several GPS emulators. Unfortunately the so called “free downloads” required a fee of $30 to $40 to use them. Blow that, I’d rather spend that money on a real GPS receiver.

An enquiry on the APRS Yahoo! group and another few hours wait and I was pointed in the direction of two free GPS simulators: gpsfeed+ and NMEA Generator. With these I was able to send fake GPS positions to the tracker board. The GPS light came on, as did the PTT light whenever a position was sent. At last!

Around this point I wanted to change a couple of the settings I had programmed in to the tracker. I re-ran the configuration software and found that when I tried to write the new settings back to the PIC it failed with a mismatch error. Reading back the settings they were now corrupt. I could not seem to clear the problem and wondered if I had blown something up.

I tried another USB to serial converter, one with an FTDI chipset which is normally more reliable in transceiver control applications. That could not even detect the tracker board. Oh dear! As a last hope I tried the Prolific adapter again and, having in the process switched both the computer and the tracker off and on again it worked this time. It seems that if you are going to configure the tracker it’s best to do it first before trying anything else. I was glad to have found a solution and that it was still working but I had wasted quite a lot of time getting to that point.

The next problem was getting the packets transmitted by the radio. I tried the Motorola GP300 first of all but for some reason it went into transmit as soon as I inserted the 2.5mm jack into the socket. So I tried the Kenwoods. Both the TH-F7E and its grandparent the TH-205E use the same type of connections. But on those I could not get PTT to work at all. I could really have done with some diagrams of how to wire up the tracker to these radios. I was, however, able to transmit some audio by manually pressing the radio PTT and then pressing the Transmit Now button on the tracker to send a packet. From this I was able to determine that no matter what audio level I used the TM-D710 would not decode the packets from the tracker.

I tried what must have been an infinite number of different level settings without success. Yet the tracker packets sounded exactly the same as ones I was receiving off-air which were being decoded. I remembered that I had the VX-8GR which also has a packet TNC so I decided to see if that could receive them. The Yaesu decoded the tracker packets over a wide range of audio level settings, even when the transmission was undermodulated. So what didn’t the Kenwood like about them?

I decided to set up AGW Packet Engine to decode packets via my FT-817 which was conveniently connected up to a sound card. That decoded nothing either. Clearly something was wrong with the AFSK output from the FoxTrak board. Even though my VX-8GR could decode it, it was going to be of no use to me if its packets would not be decoded by my gateway.

Finally, on the basis that there was nothing left to try, I decided to try different calibration settings to vary the tone frequencies. After another fight with the serial adapters I programmed in a calibration value of 36 which should result in a mark tone of 1200Hz and a space of 2250Hz and was rewarded by beeps from the TM-D710 indicating that packets were being decoded. They were also appearing in the monitor log of the AGW Packet Engine. The VX-8GR was still decoding them, too. Success at last!

I am relieved that it works after all this effort. Now all that remains to be done is to acquire a serial GPS, figure out the radio PTT connections and box the FoxTrak up with a suitable battery pack to make it into a usable unit. That will take a while, since some of the bits and pieces (including the GPS) will be coming from China.

It is interesting that the calibration setting which resulted in the best decoding is one farthest from the default, which does not place the mark and space tones so that the difference between the actual and the correct tone frequencies is equally spaced between them. A few months ago I heard a mobile drive through the area beaconing on APRS and none of its packets were decoded. I wonder how many people build or buy these trackers – either the FoxTrak or the original TinyTrak which it is a clone of – and leave the settings to default not realizing that they are unintelligible to many radios?