During construction everything went well until I got to the Audible Frequency Announcer (AFA , U10), the little PIC chip that reads the frequency in Morse. I needed that since I opted for a 10-turn tuning pot and wide range. It's a dandy circuit using a little 8 pin DIP Microchip 12C508 and a tiny 100 KHz watch-type crystal in the clock oscillator.
It oscillated, just nothing came out. OK, says I, perhaps I did something wrong. So I went on and completed the rest of the transceiver. Hmmm! Still the AFA remained silent. A search of the Internet revealed a gaping void. Everyone has moved on. Well, then! The challenge is made. The game is afoot!
Micro-controllers can simplify the design of a kit, make it more capable and make it much cheaper. But what happens years later if the equipment needs repair and the manufacturer isn't around any more? Unlike most of the other components, programmed micro controllers are not universal. The programming is frequently held as proprietary and the source code unavailable to the public. Without the programming in it a new chip, by itself, is just nothing but possibilities. Without that pivotal chip either you have to add more boards, do without, or you have a parts rig.
Despite their pitfalls, I usually install sockets for IC s. I find myself trouble-shooting a lot and it helps to be able to slip an IC in and out or to substitute it. In fact, that is my primary engineering mode: Build it, then repair it until it works. So I had a socket already in place. Just needed a replacement chip.
The original chip was a One-Time-Programmable 8 bit microcontroller and has most of the same features as the 12F675 [2] that I have a bunch of. The main difference is that the 12F675 uses Flash EEPROM for program storage and can be re-programmed thousands of times. A check of the original schematic confirmed that the pins could all be compatible, the support circuitry remaining unchanged.
You can't see what is going on within the device. Register contents and such are pretty much a guess. So I decided to build the program from the hind-end first; Setting up the Morse read-out and work my way back to reading register contents, where measurement and computational results are stored, to the frequency counter at the input end.
Keeping with the original chip that only read kilohertz I figured that if I sampled the 5 MHz VFO RF for a one millisecond period then the counter would only need 14 bits. Since my operating range is less than 90 KHz then I would just need 7 bits and a 8 bit counter would be quite adequate.
The schematic revealed which functions should be provisioned to which pin. Power and ground went to pins 1 and 8 respectively, pins 2 and 3 are for the oscillator crystal, pin 4 is the pushbutton that activates the read-out, 5 and 6 are tied together (why?) as the input, and pin 7 is the audio output. Nice and tidy except for the two pins as input. The reason for that was revealed later as I got to the frequency counter section (deucedly clever, that!).
Producing a tone is the simplest part. You just take the pin to a “high” state for a while and then take it to a “low” state for a while, do that a few hundred times per second, making a square wave. Very non-critical. The NC20 has a bit of low pass filtering there to make it sound nice and a level adjustment. The period, thus the frequency, of the tone is determined by the length of delays that you program. Since this is a simple, very straightforward program, there are no interrupts or fancy stuff going on in the background. Just simple delay loops.
Since Morse is composed of five timing elements (the dit, dah, element space, character space, and word space) it is simple to figure the delays and to scale them for the speed and the system clock that you are using. I broke it into separate subroutines and attached the element spacing delay to the end of each element, the character delay on the end of each character. Each character (in this case numbers only) was then “spelled out” as dits and dahs to be called individually.
As a proof of concept, I first wrote the main program to just recite each character. I used that program to correct all of my errors up to that point and to adjust my tone and other timings to suit me. As in most construction projects, it is well worth the time to modularize and test each section as you progress.
Having gotten the chip to speak, I was ready to teach it to read. The easiest way that I could figure was to use what Microchip calls a “computed GOTO' where you load a reference number into the accumulator (called the “Working” register, W) and call a routing table that uses that number to jump to a particular routine. In this case we put in the number that we want announced and that table will route it to the corresponding output. Put in “4” and it will say “Dididididah”. That worked perfectly so I was all hyped...Only to have my comeuppances!
The output of the frequency counter, or most anything else, is stored in Random Access Memory registers as binary numbers. Fine, except we read the output as decimal: Counting by tens, hundreds, and such. Not just zeros and ones. That took a while but I finally got a simple binary-to-Binary Coded Decimal (BCD) routine working that reads an 8 bit binary number that can be passed to the routing table. Just 8 bits since I was just counting kilohertz and only needed 80 or 90 of those. 8 bits will let you count from 0 to 255 so that was enough. I didn't want to sit there all day listening to frequency readout. I just want the quick facts.
To test this section I just loaded a number in a test register and had the conversion results stored in the three interim registers, one for the hundreds digit, another for the tens digit, and the decimated leftover units digit in the temporary register that I was using. It is then read in sequence in that order, highest to least significant place. Having done this you can now use the program this far to read things like the output of the internal Analog-to-Digital converter so that you can read a voltage. Maybe use it to check battery voltage. I even thought that I might use it to read the tuning voltage on the NC20 and convert it to frequency if I couldn't get the counter to work. The A/D converter has a 10 digit resolution and would be very accurate.
I thought this would be easy. I mean, everybody and their brother has PIC chip frequency counter programs out there. How hard can it be! I soon found out.
The counter attached to the pin used in the NC20 will not count asynchronously without the prescaler (a simple 8-bit ripple counter). By that, I mean some undetermined input like that from the radio's VFO won't work. You have to use the prescaler. Thing is, you can't directly read that prescaler. Worse yet, you can't write to it! Then there is the timer/counter itself, no gate available!
That, right there, is the reason for tying two pins together for the input. One pin serves as a gate. There is a 1K resistor in series with the RF amplifier feeding the AFA chip inputs. During the sample period the gate pin is optioned as a high impedance analog input and appears as an open, allowing the prescaler pin to see the VFO RF. At the end of the gate period ( one millisecond long ) the gate pin is optioned as a digital output. It shorts out the signal to where the counter doesn't see it.
It gets trickier. If you write to the timer result register it will clear the prescaler and you lose the counter result in it. So you have to copy the timer result register to a temporary register for the next sneaky trick. We now toggle the gate pin which fools the prescaler into thinking that it has an incoming pulse and causes it to increment the internal count by one step. By keeping count of how many times we increment that count and checking the timer register each time for an output, then, when the prescaler output changes, we can tell how far the prescaler was from being full at the time we ended our frequency count. Got that? Talk about jumping through hoops!
By taking the count of that gate toggle we can subtract it from 256 to find what was in the hidden prescaler. Now that we are down to counting individual cycles then we can compensate for some timing differences in the program. Subtracting 83 did the trick. If we were using a higher speed clock for the microprocessor than that slow 100 KHz crystal then we could be more accurate. A longer sampling period would gain better resolution and accuracy but what I have is all that I was shooting for. Avoid Feature Creep! Keep it simple! And all that.
I purposefully avoided the original chips “automatic mode” since it held no attraction for me. My simple operation is keyed by taking the Master Clear Reset to ground which is a nice way to wake it up. Wire the option links LK1 and LK3 like you were wiring it for “automatic” operation. This sets it up as a simple manual mode. So at the end of the read-out operation I put a “Sleep” command which makes it go dormant until pin 4 goes to ground and wakes it up. While asleep the chip only draws a couple of nanoamperes but retains all provisioning and is prepared to start right up.
Upon power-up it gives an incorrect read but only because the radio is not ready. The radio needs a few minutes to settle anyway. If you are tuned below 14.00 then it will report “255” or less since the high-order byte isn't being converted. Yes, easily fixed with a bit more programming but why? If you hear three digits then you are below 14 MHz and out of band.
The program uses less than 200 bytes. Most of the source code is comments which isn't really part of the program but are notes for my future self. Perhaps it will help you, too. I am hoping that this will inspire someone to re-write the code, or at least swipe some of it for their own projects. I only ask that you share freely so that we can all profit from your efforts. Amateur radio is, after all, the ultimate open-source hobby.
Cost for this project was under a a dollar but I learned a lot. That NorCal 20 works wonderfully thanks to the hard work of Dave, AD6A and his team. Mike, K1MG certainly did an impressive job with that original AFA. No way would I attempt to do all the impossibly fancy stuff that he pulled off. I'm sure that this was the only chip that balked (who knows what it went through during those 15 years?).
You can download my program by clicking HERE.
Or download it in .pdf format by clicking HERE.
For me, the project was a total success. I managed to not only salvage a wonderful piece of equipment but got the opportunity to glimpse into the realm of some master designers and how they were able to turn imagination into one of the premier QRP rigs of the time. As much as I decry “re-inventing the wheel” I must admit (now that it's over) that the re-creation was fine recreation.
de ND6T
References
[1] The on-line manual for the NorCal 20: http://www.norcalqrp.org/files/NC20_Manual_1.pdf
[2] The link to the data sheet: http://ww1.microchip.com/downloads/en/devicedoc/41190c.pdf