This page documents an older version of the project that proved very unreliable. This is (still) an ongoing project when I get free time, so I post periodic updates here until I get a proper design/rig and eventually create a new page for it (with pictures of course...)

Current Status (January 2010): During the time off at Christmas I've made some real progress on my dsPIC superhet design. Still a fair way to go, but I have a test rig knocked up with a PIC-controlled VFO and LCD interface among other things. The next stages - when time permits - will be implementing a proper tuning mechanism and the Huff-Puff stabiliser for the VFO (both in firmware), and then designing the crystal filter and amplifier hardware blocks. Eventually, I will create a page for the project that will replace this one.

Current Status (October 2009): I have found a single-pole crystal filter to be unreliable - the bandwidth is far too narrow so the on-off transitions are so slow that the carrier never decays; this is no good for the double bit transmissions. I've also discovered that the transitions can be improved by lower crystal termination impedance, but that's more crystal drive and it wrecks the filtering properties. This is no good, especially when the receiver is supposed to operate in a noisy PC room; a better way needs to be found. I'm toying with the idea of a simple dsPIC-based superhet; two NE602 mixers (one for up-conversion for filtering, one for converting back to baseband) and a few higher frequency crystals (greater bandwidth and more design info available) come to about the same cost as the low-frequency crystals plus the number of inductors I was using for low-Q pre-crystal filtering. Besides which, the inductors tended to pick up a lot of noise and the filters needed even more poles to provide significant attenuation. Superhet here I come...

Current Status (June 2009): After various discussions on the PIC List, I have done a little work on this project since the last update. I have a working Octave model of a DSP algorithm which I intend to use with a dsPIC30F2010 once I design a suitable hardware front-end. I am hoping to use a simple crystal filter (single pole) to increase the initial selectivity and reduce the likelihood of overloading the gain stages due to out-of-band signals, but have yet to figure out how to get this to work. The design details of single pole crystal filters are a little hard to come by on the 'net. I also need to create a frequency counter and frequency standard so that the crystal parameters can be measured, since the datasheets are not terribly helpful in this regard.

Current Status (January 2009): Unfortunately the detector/TTL output stages need to be redesigned (or tweaked), since they are not working reliably now that the board has been assembled on a PCB. The project is on hold until a I obtain a better method of PCB production (possibly CNC). This should make it easier to produce boards, less error prone and more time efficient. Plus the health benefits of not having to spend time in a dark room coating boards with photo resist (even with a gask mask it's not nice...) Overall, it's a little disappointing that the board is not as good quality as I'd hoped and that the detector works significantly differently than on the breadboard - I'll improve on these factors in due course.

• The Project
• Why a Radio Clock ?
• Overview of the Receiver
• Receiver Front-End and Mixer
• Filter and Amplifier
• Detector
• TTL Output
• Pictures
• Downloads

This is my first stab at a radio receiver - in fact it's pretty much my first proper electronics project, and also my first PCB (so please don't laugh too hard at the design...) This page details Version 2 of the receiver, as Version 1 stopped working once I assembled it onto a PCB (although the damn thing worked continuously for 3 months on the breadboard in my noisy computer room...) I think the failure was due, in part, to not having enough trimmable elements to tune it once assembled; and the other part due to a poor front-end design.

This new circuit differs from the original as I have removed the pre-amp and RF band-pass filter so that the signal is passed pretty much straight from the antenna tuned circuit to the mixer. I also decided to re-design the IF filter, but this time I opted for a 4-pole, low-pass, active Chebyshev filter rather than a two-pole passive Butterworth band-pass, and I added an amplifier of adjustable gain to prevent overloading when the signal is strong, rather than the very high-gain single op-amp amplifier I had before.

I was told - by somebody who knows rather more about electronics than I do - that a receiver for the MSF Radio Clock signal at Rugby (now Anthorn) would be a doddle, so I thought it would be a good starter project. As it turns out, it's a little more complicated than I anticipated.

The object of the exercise is to learn how to design and build a radio receiver, so I decided not to buy a pre-built module (such as those made by Galleon) and have shied away from monolithic receiver chips such as the MK484.

I did look around for existing designs on the 'net, but there seems to be precious little available - especially if you don't intend to use a pre-built module of some sort. The best example I have found is Hans Summers' project, but by his own admission it's not a very good receiver. Hans' site is well worth a look - he seems to be a very interesting fellow that's done some fantastic (and crazy...) projects. As a result, I give my MSF offering to the 'net, in the hope that somebody will find it useful, play with it, tweak it, hack it, and share with the rest of us.

This is a two-part project and eventually I intend to build the MSF decoder, which will be a Z80-based system that will interface with my PC and keep its clock correct. The firmware for the Z80 decoder will be written in assembly, for which I am building an assembler - again, this is another learning exercise, and I am well aware of the plethora of existing assemblers.

Or perhaps the decoder will be a bunch of PIC chips rather than a Z80-based system...or something completely different. I've got plenty of time to think about it...

This receiver is a Direct Conversion (DC) receiver. I settled on this architecture after initially trying a Tuned Radio Frequency (TRF) receiver and finding that it was a pain - and fraught with error - trying to cascade the necessary filters. In the very beginning I looked at Regenerative and Super Regenerative receivers also, but decided that the former was not stable enough over time without periodic adjustments, and the latter was just not what I thought it was...

The MSF signal is broadcast on a 60KHz carrier, which is On-Off-Keyed (OOK) to transmit 2 bits of data per second. The full specification for the signal can be found on the National Physics Laboratory's homepage, but I think that the Wikipedia article is a better place to start.

The receiver can be broken down into distinct blocks, and the schematics are drawn to represent this - they have been produced with the gEDA gschem schematic editor, so the entire schematic would be too big to fit onto a single A4 diagram anyway. The following sections detail the individual parts of the receiver.

The front-end consists of a standard ferrite rod antenna and capacitor tuned circuit arrangement with a centre frequency of 60KHz - I cannot remember what bandwidth I measured, but 5KHz sounds familiar, which would give a Q of 12. I created the antenna by winding 220 turns of enamalled wire onto a ferrite rod; I tried lots of different numbers of turns, styles of winding, several different formers, and guages of wire before settling on this - it took quite a bit of trial and error to produce. The coil's inductance is approximately 2.35mH. The coil has also been painted with Araldite to set it.

The rod used in the antenna is 110mm long and about 11mm in diameter - just a basic lump of ferrite I bought from Rapid Electronics - I buy most of my equipment and components from them as they tend to offer the cheapest prices in small volumes, but with the downside of a fairly narrow range of stock available.

Construction Note: The aerial was found to receive no signal once it had been placed on the PCB, due to its close proximity to the ground planes. To remedy this, the aerial needs to be mounted about an inch above the board.

After the tuned circuit, the signal is piped into a JFET for buffering - the JFET provides a very high impedance to the weak MSF signal, and allows the mixer to see a much lower impedance. I've used the venerable NE602 as it seems the hobbyist mixer of choice - and was available from Rapid. I did try constructing a diode ring mixer before settling on the NE602, but I don't have much luck. I don't have many toroids available, and those I do have are higher frequency cores and seemed to cause too much attenuation. I also find toroids hard to come by at reasonable prices, and much of the time you do not know what you are buying until you get it home.

The mixer is a single-ended configuration, taking the 60KHz MSF and the 61.44KHz local oscillator (square wave, 0.5Vp-p) as input. The output, among other frequencies, is a 1.44KHz Intermediate Frequency (IF). A 60KHz beat frequency was not used because the oscillatorxi ould have to be extremely stable to avoid drift - I decided it was much easier to detect and amplify a low-frequency IF than to try and construct a very stable oscillator that tracked the incoming carrier. A 1.44KHz IF was chosen because 6.144MHz crystals were easy to come by, while KHz-range quartz is a little harder to find.

The filter that is used on the 1.44KHz IF is a 4-pole Chebyshev active low-pass filter. The filter could have been a band-pass design, but would have required more op-amps. The inductors required to filter the low frequency IF are hundreds of milli-Henries, which is the reason why an active filter has been used. The filter is unity gain, for stability and op-amp bandwidth reasons, and has a ripple of 0.5dB and an attenuation of about -80dB at 10KHz. The LF412 op-amps could be replaced with others that have decent noise characteristics, a good slew rate and a comparable gain-bandwidth products; the filter requires just less than 1MHz GBW.

Because I'm not an expert with op-amps or filters, I got TI's FilterPro software to design the IF filter based on some input parameters. I played around quite a bit with active filters (band-pass) when designing Version 1 of the receiver and found that they were complicated and prone to oscillation and distortion when combined with gain.

The amplifier for the IF produces a gain of up to 2000; the first op-amp is locked to 100, and the second stage uses a pre-set resistor to provide a gain of up to 20. Splitting the gain over two op-amps eases the GBW requirements of the op-amps - important if using types other than LF412s - and since the LF412s are dual packages it didn't really make sense to waste one. There's really no reason that the variable gain cannot be increased by using a higher pre-set resistor if the signal is still too weak to drive the detector, but in my area the signal is in more danger of being clipped.

The detector is a 4046 PLL that requires at least 200mVp-p as output from the amplifier. It is wired as a Type I and has a centre frequency of about 1440Hz and a bandwidth of about 400Hz; due to the component tolerances and the narrow bandwidth, the PLL needs some trimming, which comes in the form of a preset resistor.

Initially, the detector was intended to be an LM567 (tone detector) or perhaps an LM565 (PLL), which are both intended as small-signal AC devices; this is unlike the 4046, which is intended more for digital square-wave signals of larger amplitude. The reason the 4046 was used was because I had some already and they are a lot cheaper than the other devices.

The idea behind using a PLL for the carrier detection is that the amplitude of the signal does not matter and the noise supression should be improved - more important now that a low-pass filter is being used for the IF rather than a band-pass. Since I do not know much about PLLs - I know roughly how they work, but I get lost in the mathematics of it all - I used a program to compute the values for me (can't remember its name...)

Since the 4046 chips in my possession do not have the in-built lock detector like the newer 74HC4046 models, I used the standard NOR-gate implementation. Unfortunately there is precious little information on finding the values for the resistor and capacitor combinations for the lock detector - and the information that is about uses the slower 4001 NOR gate - so I used a little trial-and-error. This turned out to be OK for the breadboard assembly, but the PCB assembly has a lot less noise and these values are no longer appropriate to drive the comparator (next section). This stage needs to be re-designed or tweaked now that the PCB isn't working as it did on the breadboard - I will possibly use an LM567 instead the next time around, as fiddling with the 4046 has been a real pain throughout.

The receiver is intended to be a daughterboard to a decoder which I am looking to build based around a Z80 and an LCD I have. To facilitate this, the output from the receiver needs to be TTL level and also needs to be capable of being gated onto a bus.

The conversion from the detector's output capacitor into TTL level is done via an LM311 comparator, which is wired up as a Schmitt Trigger. The voltage thresholds are approximately one third of the supply voltage for a low level, and two thirds of the supply voltage for a high level. The output from the LM311 is used to toggle an LED (everyone likes flashing lights !), and also as input to the 74HC74 flip-flops.

Construction Note: The threshold voltages have been reduced somewhat now the circuit has been constructed on the PCB; the breadboard values for R401, R402 and R404 were 10K - these are now 12K, 12K and 33K respectively. These values reduce the hysterisis to about 0.7V, between 2.1V and 2.8V. This is not an ideal situation and reduces the tolerances significantly. The effect is probably due to the better grounding.

The 74HC74 is used to provide a gating mechanism for the decoder, with an additional 74HC74 used to prevent latch-up from occurring, which can happen if the data is being gated onto the bus at the same time that it is being stored in the flip-flop; a symptom of the receiver and the decoder being asynchronous processes. This is not a foolproof method of preventing latchup, it merely reduces the probability of it occuring; that probability is inversely proportional to the number of flip-flops used. A more advanced method that would cure latch-up would be to lock onto the MSF carrier with a PLL and synthesize the decoder's CPU clock; this, however, would introduce a lot of complexity, as well as a dependence of the decoder on the receiver - I would like to keep open the possibility of adding other receivers in future, while utilising the same decoder.

Also included in the schematic is the header for interfacing the receiver and decoder boards. This is a 16-wire ribbon cable, with one half of the pins grounded for shielding purposes - there is one ground between each signal wire. The other 8 pins in the header are:

• GND - Signal ground, which is the same as power ground; really just an unused pin.
• /RD - ReaD strobe from the decoder (active low); this causes the 4 data bits (pins 1, 3, 5 and 7 in the diagram) to be gated onto the decoder's data bus. Currently only 1 bit is used and the remaining bits are tied to ground. The extra bits are included for future use - ie. for receivers that have higher bit rates than the decoder can handle, or receiver status flags, parity checks, etc.
• /RESET - Held low when the decoder board first has power applied; this pin allows the receiver to initialise itself if necessary, but is currently unused.
• /HALT - An active low signal that allows the receiver to be placed into a low-power mode when it is not in use. Currently, the oscillator frequency divider and the detector PLL are the only parts of the receiver that utilise this.

The local oscillator - used for mixing - is a low-power Colpitts crystal oscillator, which is then fed into a frequency divider. The internal oscillator of the NE602 was not used due to its potential reluctance to oscillate below 100KHz, and the fact that KHz crystals are harder to come by (there would have to be no frequency divider, so a crystal frequency close to the MSF carrier would need to be chosen).

The crystal used is a 6.144MHz (natural frequency) crystal, as these are easy to get hold of off the shelf, and divide nicely (by 100) to a frequency close to the MSF carrier. The oscillator is crystal as opposed to, say, an LC, for decent stability - being a clock, I intend to have this receiver running continuously, so good long-term stability is an important characteristic; crystals give that stability in a way that is fairly easy to obtain, providing you don't overdrive them.

The transistor oscillator produces a 6.144MHz sine wave of about 200mVp-p amplitude that is then passed into a gated amplifier - a CMOS NOR gate - to convert it to TTL levels. The NOR gate must be a CMOS type because we are abusing a property of the FET configuration of CMOS inputs to effectively turn the device into a very high-gain amplifier. The diodes and 100 ohm resistor are in place to protect the gate against static discharge and from being overdriven - they can probably be omitted in this circuit since the gate should always be driven.

The output of the NOR amplifier is then passed to a dual decade counter to divide the frequency down to 61.44KHz, which will produce the 1.44KHz IF when mixed with the MSF signal. Because the NE602 mixer is easily overloaded, the output of the decade counter is reduced to about 0.5Vp-p and then buffered by a JFET.

On the breadboard, the counter provided considerable noise - no doubt the big digital voltage swings and harmonics from the lower divided frequencies - and a lot of ground bounce (until more supply decoupling was added). During construction, this part of the circuit should be far enough away from the aerial to minimise the interference - the PCB diagrams supplied on this site situate the counter at the bottom of the ferrite rod, in a null, to prevent pick-up. The big ground areas should also minimise the prospect of ground bounce.

The breadboard of Version 1, from above. Running quite happily in my computer room between two CRT monitors and above three base units. It ran for about three months like this, and I never once caught it acting spuriously. Shame the *&%$$%^! thing didn't work on the PCB then...

Version 1 of the breadboard again, on an angle.

Version 1 of the PCB. This is a single-sided board 6.5x5.5 inches, with about 8 jumper links (8 more than I wanted, but towards the end of the board layout it was taking silly amounts of time to try and find via-less routes).

Version 2 of the PCB (front). This is a double-sided board 6x4 inches. I went to double-sided because I squeezed the components into a smaller area and the number of jumper links started to approach 20; at that point I decided to go double-sided, since I had the copper-clad board anyway. This board took me about two days to lay out, which is a lot quicker than my first board.

Version 2 of the PCB (front). This is after drilling. Notice that the some of the pads and the title have been etched away. This is because of my poor photo-resist coating skills. The tracks are 25mils (1mil = 1/1000 inch) for signals (down to 15mils between pins), 50mils for power tracks, with a minimum copper spacing of 10mils. The writing in the title is about 6-8mils; I can manage this by using a bubble etch tank, but it's not too reliable for such small details and involves me re-covering the areas with an acid resistant marker every 30 seconds or so during etching.

Version 2 of the PCB (back). Notice the light grey marks on the board - these are where the etching process was not fully completed and I have had to separate the tracks with a scalpel. If I'd have left the board in any longer then the finer details would have been etched away, and the big areas of copper would have got even more pin holes. Again, this problem was down to my poor photo-resisting skills. I also think that the laser printer toner coverage leaves a lot to be desired - it's very patchy.

Version 2 of the PCB (back). This is after drilling.

Version 2 of the PCB after assembly, running with a quick power supply knocked up on a breadboard. The power supply runs from a 12Vrms AC wall adapter, able to supply 1300mA - though this small circuit uses nowhere near that much. The power supply is simply a 7805 and 7905 to give +/- 5V, along with the big capacitors and diodes for rectification of course. You can also see one of my oscilloscopes and my function generator in the picture. And the bomb site that has been my working area for this project...

Version 2 of the assembled PCB from above, up and running. The aerial is pointing North-South so that its length is facing Anthorn. Notice the highlighter pen propping it about an inch above the ground plane so that the signal can be received. I have some nice plastic clips that I was going to use to strap it to the board with those mounting holes you can see, but it looks like I may have to rethink that idea slightly.

Version 2 of the assembled PCB again, from a slightly different angle. You can see the LED is on (indicating that the MSF carrier is present) - this will periodically turn off when the MSF carrier disappears to convey bits of information.

The waveform output from the amplifier; this is the IF at about 1440Hz. You can see the noise (both lower and higher frequencies) so it's far from perfect, but good enough for a PLL to lock into.

To download the schematics and PCB artwork, just click on one of the links below.

Download the archive either as a zip or tar.gz - they both contain the same files, just compressed in different ways for your convenience. Note that these downloads should contain no virus (obviously), but it's worth a little disclaimer anyway - I have not checked these files with a virus checker, so you download at your own risk; just remember to check them at your end before opening if you want proper peace of mind.

• radio_clock.tar.gz (637KB)
• radio_clock.zip (652KB)