FreeTrak progress

I have made some progress with the FreeTrak PIC based APRS tracker. I found a slightly newer version of the PICFlash programming software. At first this gave exactly the same warning message as the original version. But after a bit of random clicking I tried again and this time the software reported that it was writing to the chip. It verified OK as well. I don't know exactly what I did, but at least that hurdle was now passed.

FreeTrak configuration

I set the DIP switches on the EasyPIC board to link the PIC pins used for serial I/O to the serial output. That didn't seem to work the first time, either, but at the second attempt at powering up I saw the configuration prompt appear in the terminal window. I was able to complete the FreeTrak configuration with the PIC in the development board.

Next, I changed a DIP switch to put the chip in Run mode. Using a utility called NMEAGen I began sending simulated GPS messages to it using the same serial connection I used for configuration. The LED began flashing at 1 second intervals and using a crystal earpiece on the output pin I could hear the familiar sound of 1200baud packet bursts. I don't know why it appears to be transmitting at 1 second intervals, but perhaps it is something to do with the simulated GPS data.

FreeTrak schematic

So FreeTrak appears to be working. All I need to do now is build it on to a circuit board and attach it to my GPS module and a radio. Here's where I could use a little help from readers. The AFSK audio output of the FreeTrak uses an obsolete op-amp which is unobtainable. I presume I could just replace this with a simple transistor amplifier stage using a 2N3904 or similar, but do I really need anything at all, given that the audio will drive a sensitive microphone input? Could I get away with just a DC blocking capacitor and a trimpot to set the level?

The other thing I'm unsure about is how to interface the FreeTrak to my GPS module. I think the circuit shown is intended to work with GPS devices that use 5V TTL or even RS-232 signal levels. The data sheet for my bare GPS module states quite clearly that the absolute maximum voltage on any of the pins is 3.3V. The serial lines on the PIC measure close to 5V. How to connect them?

Mistaken identity

A couple of weeks ago I came across FreeTrak, a PIC based APRS tracker developed by N0QBH. I have wanted to build a small 'grab-and-go' tracker for a while now. The FoxTrak works fine but is too big and bulky by the time it is paired with an HT. The TH-D72 is too much hassle as I need strong reading glasses to see the LCD screen and inevitably go out with some essential menu option disabled. Consequently these days I rarely bother taking APRS with me when Olga and I go for a walk around town.

I sent off for a couple of PIC 16F628A microcontrollers, thinking that I could program them in my EasyPIC5 development board. But when I tried, I immediately hit a snag.

My PICFlash programmer detects a PIC 12F508 instead of a PIC 16F628A.

I don't think I've been sold a fake MCU. If I remove the 16F628A so there is no micro plugged in at all I still receive the same warning. So I don't know what to do. I've bricked too many PIC chips by programming them with the wrong settings to try crossing my fingers and clicking Yes. So it looks like my FreeTrak project is not going to get off the ground.

A cheap LCD

A packet arrived from China this morning containing a 16x2 LCD module which I purchased for the absurd sum of £1.93 including shipping. That wouldn't cover the postage from a UK supplier. I don't know how the Chinese do it and make a profit.

I bought the module with the intention of using it to make a user interface for my Parallax Propeller beacon. Having ordered it I was not sure how to interface the LCD to the Propeller so I chickened out and ordered an LCD UI module from Gadget Gangster. This is rather more expensive (though still a reasonable $29.99) but it includes a 4-way + depress button for menu navigation, plus a separate red button. It plugs straight into the Gadget Gangster board.  I reasoned that even with the hardware sorted the software would be enough of a challenge.

I have rather ambitious plans for this beacon. Perhaps over-ambitious. After reading Alex G7KSE's blog post about his Arduino based MSF 60kHz receiver I'm interested in interfacing one of the inexpensive MSF receiver modules to the Propeller. I could use this to display an accurate clock and also to control the start of WSPR beacons. As I'm a bit of an accurate time nut and have two radio controlled clocks in the shack (and a radio controlled watch) it is really no trouble to press a button to start the beacon at the beginning of an even minute and then keep time from there. But that isn't the point really, is it? What could be cooler than a shack clock that is also a WSPR beacon?

This microcontroller stuff is new to me and I have a lot to learn about it. One question I have is what do constructors who use Arduino boards or similar things like the Gadget Gangster do when they want to make a finished project? Do you just buy another development board to use for the next project, or are there simpler boards with just the microcontroller and its essential ancillary components which you use for the final version? I guess I'd still want the ability to update the software (firmware?) so there isn't much of the Propeller Platform board that I wouldn't be using.

Propeller does WSPR

Through Eldon, WA0UWH I have discovered another blog to add to the blogroll: that of Jeff, KO7M. Jeff is interested in a lot of the same things I have been (including light aviation: an ambition of mine when I was in my 20s but which I could never afford to take up.) But what really piqued my interest was that he has just got a Parallax Propeller to generate a WSPR signal.

This is one of the things I was interested in trying. But I never got further than wondering how to implement the fractional frequency shifts of the WSPR signal, which uses 4 tones shifted by just under 1.5Hz from each other. Jeff has apparently found that a 2Hz shift is good enough to be decoded, allowing WSPR to be sent using the integer frequencies the Propeller chip can easily generate.

Once I have finished the Tiny Keyer project and can get back to the Propeller I will be trying this myself. My ambition at the moment is to make a multi-band multi-mode (OPERA, WSPR and perhaps QRSS as well) standalone beacon with an LCD panel to enable me to choose the band and mode. We'll see how far I get, but having two other people working on the same ideas should certainly make the task easier!

Trials and tribulations

I'm sorry if you are one of the many people who have sent me email expecting a reply, but unfortunately answering emails is one of the things I very often never get around to. Although it might seem from the blog that I am getting back to normal, everything I do still takes me a lot longer than it did when I was fit and well and I'm more prone to making stupid errors. I'm happy that I'm still able to do some of my ham radio activities but what I achieve is often accomplished only after a lot of frustration.

Today the Simple Keyer Chip from Steve Weber arrived in the post. I verified the behaviour of the chip I'd programmed, then replaced it with the new one. I was pleased to find that it now operated at the correct speed - the sidetone was now audible to humans rather than bats and the default speed was rather more sensible. Obviously I'd messed up some setting of the programmer - but the keyer still ignored the dot paddle. I began to suspect that this meant there was something wrong with my wiring, but between my limited field of focus and my shaky hands it took the entire morning - culminating in a lot of bad language - before it eventually dawned on me what was the trouble.

To cut a long story short, the cause of the problem was the 3.5mm socket I was using for a key jack. It had three terminals which I thought were for tip, ring and sleeve, dash, dot and ground. But it was a mono socket! There was no ring connection. One of the three terminals was linked to the other and disconnected when the plug was pushed in, intended to silence a speaker when phones were plugged in. It took me an entire morning including checking the wiring of two morse keys before I discovered my stupidity.

I hunted in my parts drawers and eventually discovered a proper 3.5mm stereo socket. After connecting that in place of the other one I confirmed that the keyer worked as expected. But the frustrating search for the solution had made me tired so I decided to leave the task of drilling the box and finishing the keyer for another day, thereby adding to the list of unfinished tasks alongside the unanswered emails.

Another thing that annoys me is my Rapid Electronics HY3003D bench power supply. It has a rather inconvenient fault for a power supply that is used in a radio shack. The voltage regulation circuit suffers from RFI. If any of my radios transmits, the voltage increases. In some cases it could increase to a level that could damage the circuit I am testing, though fortunately that hasn't happened yet.

I don't always remember to put my APRS gateway or the WSPR (or Opera, which I have been testing today) beacon into receive-only mode whenever I'm working on something. (I've tried clamp-on RFI suppression ferrites on the mains lead and they made no difference.)

First spin of the propeller

A new toy dropped through the letterbox today. It is a Gadget Gangster Propeller Platform USB demo board for experimenting with the Parallax Propeller microcontroller. If you haven't heard of the Parallax Propeller before then it is an inexpensive micro chip that contains eight processors called cogs (as in gear wheels) that can run independently in parallel. It's quite a bit different from the Microchip PIC or Atmel devices which have a single processor architecture similar to an ordinary computer.

 I sent off for the board just after Christmas, after reading about it in Eldon Brown WA0UWH's blog. Eldon posted code showing how the board could be used as a QRSS beacon. I was quite excited by the idea of a device that with simple programs even I could understand could be made to emit RF.

I sent off for the board on 27th December choosing the low cost untracked USPS air mail shipping option and it arrived today, 4 January - much quicker than expected. What's more, there were no nasty customs charges! Gadget Gangster still has a special offer of $10 off for the board, so if you fancy getting one of these to play with now is the time to do something about it.

I was very impressed at the speed with which Gadget Gangster processed my order. What you get, though, is just the board. You will need to provide a power supply (7.5 - 12V with a 2.1mm barrel connector, centre positive) and a USB cable with a mini-USB jack at one end. These seem to breed in my junk box so that was not a problem. You will also find useful a small breadboard and some hookup wire to attach components to the board and test your programs.

I installed the Propeller Tool - a free download from the Parallax website, connected the board to my Samsung NC10 netbook. I then tried the Blinky Light tutorial from the Gadget Gangster site. It didn't work - until I connected the LED the correct way round (stupid newbie error!)

Over the next few days I'll be working through the tutorials to get the hang of the system. Then I'll take a look at Eldon's QRSS beacon code and adapt it to send my own call. I'd like to make a WSPR beacon. I don't know yet if that will be possible, but I'm looking forward to playing with this Propeller chip and using it in some radio-related project. Watch this space!

Simple keyer trouble

It should have been simple. I needed a basic CW keyer that would allow me to use a paddle with my homebrew QRP / QRPP rigs because my shaky hands make sending Morse with a straight key too difficult at the moment. I also needed to be able to record a message and play it once or repeatedly until I heard someone reply or was spotted on the reverse beacon network.

A couple of years ago I built a DC20B QRP transceiver. I didn't like it very much and eventually sold it on eBay but I did like the keyer built into it which used an ATTiny13 microcontroller. One day, I thought, I would build a keyer using this chip. I got two of the Atmel chips and Steve Weber KD1JV sent me the hex file so I could program them but I never got around to doing anything more until a couple of days ago.

The simple keyer circuit uses only a handful of components but due to my condition it took a lot longer than it would have done pre-tumour to work out a perf board layout and build it. So you can imagine that I was a bit upset when after all that effort the keyer didn't work. It responded to the dash key and the function button, but not the dot key. Also the sidetone was very high pitched and the Morse speed was about 100wpm!

Thinking I had made a mistake programming the clock setting in the chip I tried programming the other one. This ended up just the same. Unfortunately with the simple keyer program you have to disable the reset pin that is used by the programmer so you only get one chance to write the code to the EPROM. But as I don't have the source code and so can't try modifying it that shouldn't have been a problem. If I hadn't sold the DC20B I could have tried the keyer chip from that, but now I am now stuck with no idea what to try next.

I have the code for another keyer that uses a PIC12F509A - the K9 from K1EL's freeware page. But I'd have to start over with the circuit board as the pinouts of the Atmel and Microchip microcontrollers are not compatible. The functionality of the K1EL keyer program is not what I was after either, so I don't feel much like trying it at the moment.

WX-1 baud rate fix

On Thursday I wrote about how my WX-1 APRS weather station was not being received by my TH-D72 and the PIC TNC because the baud rate was slightly fast, and of my unsuccessful attempt to fix it. Glenn W9IQ offered to take a look at the PIC source code and see if there was an easy fix. I sent him a link to the code and a day later I got a reply back. Glenn's suggestion solved the problem perfectly. But he didn't just tell me what to change, he explained what the code did and how it worked. I thought that his explanation would be of interest to anyone trying to understand how packet tones are generated using a PIC, so with his permission I am copying it here.

"The baud rate is determined by an interrupt service routine. The interrupt is driven by Timer 0 (TMR0) that is configured to use the instruction clock as its input (frequency of Y1 divided by 4). The input of TMR0 is also initialized to have a divide by 32 prescaler (the code comment says 16 but that is wrong). So at this point the timer is being driven by the frequency of Y1 divided by 128 or (20 MHz / 128) =  156.25 kHZ or a period of 6.4 uS.

Now the math and routines get a little more complicated. The interrupt is serviced by the code in the "packet" file. This code sets the TMR0 count to start at a value of 127. This TMR0 count will tick up one count every 6.2 uS (the clock from the output of the prescaler). When the timer count rolls over from 255 to 0, the interrupt is triggered.

At first glance, it would appear that this would generate an interrupt every 129 counts or 825.6 uS (6.4 uS * 129). That would seem to put the interrupt at roughly 1211 Hertz ( 1/825.6 uS). But this is not correct due to the way the author wrote the interrupt routine plus a small nuance of how a PIC handles the reset of the prescaled interrupt timer.

The interrupt service routine in "packet" executes 6 instructions before resetting the interrupt timer to a value of 127. Each instruction takes 4 clock cycles so this adds another 1.2 uS to the time between interrupts. In addition, when the prescaled interrupt timer register is written, there are another 4 instruction cycles of delay before the timer starts to run again. This is another 0.8 uS added to the interrupt time. So we now have an interrupt cycle of 825.6 uS + 1.2 uS + 0.8 uS totaling 827.6 uS or 1208 Hz. I believe this is what you measured as the current baud rate from your board.

Improving this is fairly straight forward. The interrupt goal is 1200 Hz or 833.3 uS. If we change the TMR0 count to 126 instead of 127, this will add another 6.4 uS to the interrupt period. This would give us 827.6 uS + 6.4 uS = 834 uS. Then if we eliminate one instruction in the interrupt routine, we eliminate a 0.2 uS delay for a total interrupt time of 834 uS - 0.2 uS = 833.8 uS or 1199.3 Hz.

This change is effected in the code located in the "packet" file. Look for the following code fragment:

        movlw        0x80        ; 128 decimal

        sublw        0xFF        ; subtract 128 from 255 to get TMR0

        movwf        TMR0        ; move it to the TMR0 register

Change this code fragment to read like this:

        movlw        0x7E        ; 126 decimal

        movwf        TMR0        ; move it into the TMR0 register

Recompile everything and reload the processor and you should see the baud rate drop as described."

When I ran the modified code the baud rate dropped from 1207/8 baud to 1198/9 baud which is pretty much just as Glenn predicted. The weather station is now being received by the Kenwood TH-D72 as well as my other APRS radios. It can also now be received using the PIC TNC though the level of the receiver audio is critical and unfortunately not the same as that needed to decode the VX-8R. I think that is because the maximum deviation I can get out of the Radiometrix transmitter module is a bit on the low side.

I had an anxious couple of minutes when I found that although the D72 was decoding the packets it was rejecting them as invalid. This turned out to be because the position co-ordinates had a lower case n for North and w for west: In my haste to see what effect the changed code had I had entered the settings carelessly, though the other radios didn't seem to mind. That was soon fixed.

The WX-1 weather station is now back in position beaconing the temperature, humidity and pressure as G4ILO-5. I would like once again to express my thanks to Glenn W9IQ for acting in the finest spirit of ham radio and helping me out with this.

Baud with microcontrollers

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.

PIC TNC problem

I have been playing around some more with the WB8WGA PIC TNC that I built. While it was quite fun to see what it managed to decode and have it working as a digipeater, I eventually wanted to get it talking to some real software. UI-View is supposed to be able to work with TNCs in Converse mode, so that was going to be the easiest thing to try. But in order to do that I needed to solve the problem of the firmware expecting a linefeed to terminate a command.

That problem turned out to be fairly easy to solve, though I ran into some problems by trying to make some other changes. The trouble with working with microcontrollers, at least when using assembler, is not just that they don't have much memory but it isn't an a seamless block and you have to take care of memory management. Consequently I found that adding one line of code could make the difference between the program compiling and getting an error on the lines of "you are writing to a location that has already been written to." I'm a high level language kind of guy who expects the compiler to take care of all this for me. I suspect that major modifications to the code like adding KISS support is going to be beyond me.

Anyway, I managed to get it so that UI-View could make its various settings and put the TNC into Converse mode. I had to get rid of the message that comes up on entering Converse mode because it often clashed with UI-View sending a beacon. I then set some IS to RF gating options to generate a lot of traffic and found that the TNC kept going back into command mode. This appeared to be due to the timeout timer that throws you back into command mode if you start to type something and don't hit Enter. This was a pretty annoying feature, quite apart from interfering with reliable operation, so I had to take that out, too.

It seemed like the TNC was ready to go. But although it would transmit beacons from UI-View perfectly well, the program would not display any received stations. I could see the decoded packets in UI-View's Terminal window, but they never appeared on the map anywhere. I did some searching and found one complaint about this in the Fox Delta Yahoo! group (the Fox Delta Mini TNC is apparently based on the same firmware) but no solution.

There did not seem to be anything wrong with the packets and I spent a couple of hours trying various things to see if I could establish what the problem was. Eventually I hooked UI-View up to my Kenwood TM-D710 in packet mode and watched what happened. Packets were received and displayed as expected. So then I connected a terminal program to try to see what the received packets looked like. (This is Windows HyperTerminal with a special Terminal-Hex font that shows the hex value of non-printable characters.)

This is what the output from the Kenwood TNC looked like:

and this is the output from the PIC TNC:

As you can see, the only difference (apart from the fact that the PIC TNC is displaying the packets as it digipeated them while the Kenwood heard both the original and the digipeated versions) is the text UI or UI R in angle brackets before the colon that marks the start of the payload part of the packet. It doesn't look like something significant enough to make UI-View ignore the packet. It isn't something that appears in the raw packets listings at aprs.fi. I don't know what it means or how to generate it in the output from my TNC. So I'm stumped at the moment and am hoping that someone who knows the answer will read this and point me in the direction of a solution.

PIC16F88 TNC

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.

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.

Bricked chip

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.