DCF77 PM receiver (radio clock) - Page 1
Forum section: electronics / projects

author: capt bullshot
author_rank: Super Contributor
timestamp: April 09, 2019, 09:05:38 am
content: Recently, I've started a new project, building an DCF77 (German / European radio clock) receiver in PM (phase modulation) mode.The common commercially available radio clocks (for DCF77 usage) all use the simpler AM mode, but PM mode can provide better accuracy and higher noise tolerance.It's still work in progress, but I've got a working prototype:http://wunderkis.de/dcf-rcvr/index.html

author: Kleinstein
author_rank: Super Contributor
timestamp: April 09, 2019, 09:36:07 am
content: I don't think it is a good idea to have the ZF to be digitized by the µC at zero. It starts with the odd divider and possible coupling from the clock to the antenna. I would more consider running the I/Q mixers (probably Tayloe -mixer) with something like 70 KHz and this a ZF of 7.5 kHz.Going to a real super-het receiver with a non zero ZF helps avoiding coupling back to the antenna, as some of the gain can be behind the mixers.One may not even need I/Q mixers anymore if there is a sufficient filtering, but they could help avoiding mirrored bands.So there would be a little more math in the µC, but easier hardware. If the clock (more like an VCXO) is also driving the µC, the now CPLD block may be just a 74HC74, if needed at all.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 09, 2019, 09:55:06 am
content: Quote from: Kleinstein on April 09, 2019, 09:36:07 amYou're right, LO coupling is one of the reasons I needed the ADC offset auto zero. Anyway, these Cortex-M4 aren't quite real digital signal processors, by mixing to DC I can get away withquick and dirty (or just lazy) signal processing in C at a moderate sample rate (3875Hz).QuoteNo doubt, this can be done by directly sampling the carrier (no LO and mixers at all), but most probably not using that particular Cortex-M4. A 20 year old real DSP is still more capable thanthis class of uC in terms of signal processing.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: April 09, 2019, 10:25:06 am
content: You might find this an interesting read too...http://www.marvellconsultants.co.uk/DCF/I'm thinking about giving up on DCF (and MSF) since interference with local sources is making it problematic for me to receive them.

author: Kleinstein
author_rank: Super Contributor
timestamp: April 09, 2019, 10:27:38 am
content: I don'T know the M4, but the processing needs for the rather low, maybe a 10 kHz ZF are not that high.A M3 ARM should be well fast enough. I even though about using a similar scheme with an AVR (using some 2.5 kHz ZF) - though in this case it could get close with the speed.The extra processing needs for a non zero ZF are not really high:1) Step the virtual ZF phase by an addition and cut away the highest bits2) get sine and cosine values from a table3) 2 multiplications (16 bit integers) for each ADC channel and 4 additions/subtractions to combine the 4 signalsThis should not need much more than about 1% of the processor speed if the sampling rate is not very high.Mixing to zero ZF is a little easier for software, but can be a real nightmare with coupling / shielding.By not needing I/Q I meant still keeping a mixer, but only a simple 1 phase mixer. The phase info is still there from the IQ step done numerically.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 09, 2019, 11:03:49 am
content: Quote from: Kleinstein on April 09, 2019, 10:27:38 amI thought about this approach, but right after having built the I / Q mixers on the prototype and having tested them with a lab signal generator providing the I/Q LO signals. Next I implemented the CPLD clock generator just because I can do it this way.This project "just happened" bit by bit and step by step, without having a polished concept of how to do it at the very beginning. So, yes, some design decisions would have been different if this project was properly planned.Indeed, there's a routine doing the vector rotation you describe in the firmware, for removing the short term LF residue of the LO / DCF77 carrier difference from the received signals. The (voltage controlled) TCXO is controlled rather long term, so the I/Q mixers output "DC" after a significant time of stabilizing. Before that stablisation is achieved, the I/Q-signals are at a low frequency (0.1Hz), which is removed in the firmware. It's not shown in the block diagram.BTW, the link NivagSwerdna provided shows a nice example of "mixing down to DC" by sampling the signal at the carrier frequency / an exact multiple of the carrier frequency.Also it does the samples processing in a loop that must execute within one period of fc, my approach is rather "brute force" by storing the samples in buffers and running loops across the data.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 09, 2019, 11:14:13 am
content: Quote from: NivagSwerdna on April 09, 2019, 10:25:06 amYes, if you just want an accurate timing source, just use a GPSDO. Anyway, thanks for the link, just peeked through the source code to see how it is done. The link to the elektor magazine is broken, alas.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: April 09, 2019, 12:19:37 pm
content: Quote from: capt bullshot on April 09, 2019, 11:14:13 amI have a GPSDO, a Rb standard,.... but each has pro-s and con-s. DCF77 is quite nice as modules are super cheap and there exist libraries that do some limited form of signal processing but, in my experience, EMI from monitors, PSUs etc is problematic.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 09, 2019, 12:40:52 pm
content: Quote from: NivagSwerdna on April 09, 2019, 12:19:37 pmThe EMI from all kind of equipment was one of the motivations to make this radio clock. At the place I work, there's all that EMI happening, and I had this radio clock at my work desk:As it employs one of these simple DCF77 receiver modules, it has all the well known issues. Works fine at home, but not at work. Making a more noise-immune radio clock is one of the goals of the project, using the PM receiver alone is a step forward, combined with a more tolerant decoder it does the job at my workplace where other radio clocks fail.

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2019, 08:52:33 am
content: Quote from: capt bullshot on April 09, 2019, 09:55:06 amSure. Yet it is still quite good for 16bit fixed point DSP tasks (link to M4 DSP presentation as pdf). It has saturated integer math, 2-way 16bit SIMD instructions that includes single cycle multiply-add. 16-bit complex 1024-FFT in <=100k cycles IMHO is pretty impressive for MCU you can get for 2$ (stm32f301).Quote from: capt bullshot on April 09, 2019, 11:03:49 amThere's always option to reconsider. I find your project unnecessary overengineered and would have bitter taste finishing such because less is more for me. If I were you, I would take stm32f301 and make better version ofmentionedreceiver. In addition to M4 core and fast ADC, f301 have programmable gain opamp needed for this app. BTW that project can be improved as well - by replacing lowpass filter with narrow 78-KHz tuned bandpass.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 10, 2019, 10:14:29 am
content: Quote from: ogden on April 10, 2019, 08:52:33 amYes, I've seen impressive stuff done on the STM32F7 discovery board, and I've done digital control loop stuff on a STM32F3 myself, I was quite impressed of how fast I could run the ADC sampling and control loop written in C (not assembler) and using floating point arithmetic. In fact, the same control loop executed somewhat faster using the FPU than the "good old fashioned" fixed point integer stuff. But what I miss with these Cortex-M cores is the ease and effectivity of e.g. the ADSP-21xx architecture assembly language. This lets you do your typical FIR filter at 1 cycle per coefficient plus 4 cycles overhead. Cortex-M7 with its dual issue pipeline can't do this yet and is more complex.QuoteThe available F3 series nucleo boards were too small in terms of on-chip RAM for this project, so my choice was the L432. The signal processing (receiver) part can be done with less memory than I used now, anyway, I needed larger buffers for the decoder part. My rough estimates showed 8K RAM (that is available on the F3 nucleo module) were way too small. I'll finish this one the way it is, evaluate how it performs regarding the short and long term stability of the 10MHz and PPS outputs, and at some point I might start the next one based on that experience.

author: dietert1
author_rank: Super Contributor
timestamp: April 10, 2019, 10:52:06 am
content: Here is a link with a description of a digital DCF receiver i made using a HP E1430A VXI module. Written in German but you can probably use an automatic translator.http://www.cadt.de/dieter/dcf/Praezisionsfrequenzmessungen.pdfAlso i agree that the Cortex M4 is strong in comparison to many traditional DSPs, since you can do everything in 32 bit. And if you have an optimizing compiler like IAR, at clock frequencies like 100 MHz it can be used even for high end audio.Regards, Dieter

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2019, 12:09:23 pm
content: Quote from: capt bullshot on April 10, 2019, 10:14:29 amYour approach could need plenty of memory. dsPIC of mentioned project has 2KB RAMIt is wise to use "overkill" chip for prototype rather than late into the project realize that MCU of choice is too small/weak and you have to start it all over again on another chip or even worse - different MCU architecture. Thou you need discipline while using "overkill" chips. Some programmers tend to cut corners writing memory and performance-inefficient code in result. Most of the PCsoftbloatware are fine example for that.BTW using single ADC, thus interleaving I/Q samples kind of destroys whole idea of "no compromises" zero-IF design. For IQ sampling you definitely need two synchronous ADC peripherals.

author: Kleinstein
author_rank: Super Contributor
timestamp: April 10, 2019, 12:24:05 pm
content: Quote from: ogden on April 10, 2019, 12:09:23 pmThere is nothing good in using a zero ZF IQ sampling in hardware. It causes several HW problems, especially coupling back to the antenna and also DC drift of the ADCs / corresponding amplifiers. Zero ZF is a good thing in the virtual / software word.If really needed one could still use an interleaved ADC for I/Q sampling: just add a suitable delay circuite/filter. At zero ZF and thus a quasi DC a delay does not cause a significant phase shift.At least the early conversion stages (go from 1. ZF to Zero ZF IQ data, carries PLL, maybe even the PLL for the sync of the PM part) can be done in real time as the data come in. So no need to save much data.

author: ogden
author_rank: Super Contributor
timestamp: April 10, 2019, 01:42:29 pm
content: Quote from: Kleinstein on April 10, 2019, 12:24:05 pmRight. Also it is good for cost-sensitive "pure silicon radio" ASICs. IQ sampling shall not be used *especially* when hardware is capable of best possible radio architecture - direct RF sampling. You sample filtered by narrowband (preselector) filter 1KHz wide DCF77 "channel" at 70KSPS (3rd Nyquist zone undersampling) to get 7.5KHz digital IF, then convert to IQ baseband digitally using precomputed sin/cos table.  Those sampling & IF frequencies are just example. One may consider another values that are perhaps more suitable for intended purpose

author: capt bullshot
author_rank: Super Contributor
timestamp: April 10, 2019, 02:00:19 pm
content: Quote from: ogden on April 10, 2019, 12:09:23 pmThe dsPIC does the receiver part alone, not the decoder. So it's a nice and tidy PM receiver that outputs the demodulated time code. Of course, I've done DCF77 decoders in a few bytes (not kB) of RAM within an 8051, so one could most probably add a simple decoder to the dsPIC. No doubt one can do this using an STM32F3 too. The larger amount of RAM eases the implementation of the decoder having large buffers of received data to make use of the predictability of the time code to mitigate weak / distorted signal conditions. This would be significantly harder to implement with 8kB (or 2kB) of RAM.QuoteThanks, interesting reading. Especially the conclusion about the tuned antenna that acts like a swing that is flapping around in the breeze. Apparently, mine does that too, directly affecting the short term stability of the PPS and 10MHz outputs.

author: capt bullshot
author_rank: Super Contributor
timestamp: May 20, 2019, 11:29:19 am
content: Hi folks,I've updated my project page:http://wunderkis.de/dcf-rcvr/Some more effort went into this project, including building receivers on a PCB, optimizing and testing the firmware and getting some results observing their timing output stability.BTW: at the left hand side of the first picture, one might discover the GPSDO mady by forum member RoadRunner