DCF receiver

[lpcware]

Content originally posted in LPCWare by serge on Sun Jun 12 11:26:28 MST 2011
Hello all,

I was looking for some DCF77 receiver code for the ARM Cortex-M3 series (I am going to use a LPC13xx or LPC17xx depending on the size of the finished code)
I used google to do a search but i guess that i was looking at the wrong places because all i got was sample code for Microchip's PIC series and Atmel AVR.

Since i hate reinventing the hot water i am so free to ask if there exist some code to decode a DCF77 bitstream. The bitrate is 1 bit a second (a 100ms puls = 0 and a 200ms puls = 1) and for more information you can visit these websites:

http://www.ptb.de/index_en.html
http://www.dcf77.de/  (only in German)
http://en.wikipedia.org/wiki/DCF77


I already use a very acurate RTC chip DS3232. I only need the DCF receiver to set the clock in the RTC chip and to keep it synchronised.

[lpcware]

Content originally posted in LPCWare by serge on Thu Jun 16 03:58:15 MST 2011
I am going to build such a receiver. First a complete one. Later on i will do a part of the conversion in software. I'll keep you posted.
And thanks again for all the valuable information.

[lpcware]

Content originally posted in LPCWare by Rob65 on Wed Jun 15 05:00:16 MST 2011
As always, Zero is the man !

Just use the part of the schematic shown in Abb. 2 and create a direct conversion receiver in software :D
Bertrik Sikken (well known from a USB stack fot the lpc1xxx/2xxx series) made a bat detector this way.
Ok, that's just 40 or-so kHz but that was also on an lpc2138 which is a bit slower than an lpc175x/176x

Rob

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Wed Jun 15 04:09:14 MST 2011
There are a lot of examples in german for "dcf77 empfaenger schaltplan" :)

Like:

http://www.obonic.de/dcf77-empfaenger-grundlagen/

or more old-fashioned with tubes:

http://www.jogis-roehrenbude.de/Leserbriefe/Katzmann-Clock/Roehrenuhr.htm

[lpcware]

Content originally posted in LPCWare by serge on Wed Jun 15 03:51:39 MST 2011
Anyone who is good in high frequency techniques?
To develop an GOOD dcf77 receiver...
I think i will have to look back to my old books and build a nice dcf receiver myself.
It's a pitty that the old Telefunken/Temic chip U422B (or T4224B like Atmel renamed the chip after they bought Temic) is no longer available. Atmel should be ashamed!

Anyway the GPS solution will probably not work in my case since the whole system i am developping will be installed in a basement. Of course I can always put some long cables to the outside of the building :(.
I think that i will just finish the code with the dcf receiver at the back of my garden and see what it gives.
I just noted that the first plastic box i used to enclose the dcf receiver also blocks the signal. I'll placed the antenna at the outside of the box now :p.
I think that next week i will have some working code since at the moment i have a heavy daily schedule.

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jun 13 12:12:45 MST 2011
Bought it in a shop called 'amazon' :eek:

http://www.amazon.de/NAVILOCK-Engine-Module-NL-552ETTL-Navilock/dp/B00304PRQ0/ref=sr_1_1?ie=UTF8&s=c...

[lpcware]

Content originally posted in LPCWare by Rob65 on Mon Jun 13 12:03:38 MST 2011
Serge,

I also used the Conrad module (nr. 641138, see picture). It needs a clear view and will not receive a proper signal when it was on my table - it just hates any electrical interference.

Place it in the windowsill or even better in a small water tight box outdoors and it will receive a good signal.

All of my DCF enabled clocks also need a good view to the sky. The clock in my bedroom is placed 2 meters from the window, there is no other electrical equipment next to it and still it will not receive a proper DCF signal. I need to place it near a window to sync. I live in Nijmegen, just a wee bit closer to Mainflingen (approx. 350 km).

The GPS module also needs a fairly clear view to the sky. I have a GS407 module with helical antenna but I will also try the Navilock 552. Both use the uBlox 5 chipset. The Helical antenna is less directional sensitive. The block ceramic antenna from the Navilock module must be horizontally placed, pointing upwards, to receive the best signal. But the block ceramic antenna has a better gain than the helical so you could experiment with this one.
With a price of € 40,- (the GS407 was € 74,- :() it is worth a try.
Power is 5V but serial I/O is 3.3V which is perfect for the lpc13/17xx

Note that you will need a serial port for the GPS and the lpc13xx has only 1 port. The lpc17xx has up to 4 ports.

He Zero, Thanks! Nice GPS module.
Do you perhaps have a different source for the connector? € 9,- is much more than the € 3,90 suggested retail price that Navilock themselves show on the website.

Rob

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jun 13 06:54:50 MST 2011
No DCF, then GPS?
Conrad also sells a wonderful NAVILOCK 552ETTL GPS receiver...

[lpcware]

Content originally posted in LPCWare by serge on Mon Jun 13 06:44:05 MST 2011
Hello Rob,

I went to look at my old documentation and indeed you are right of course. The 4-bit processor i meant was the Intel 4004. It was first available back in 1971 if i ain't mistaken. The MCS48 was released in 1976. Where are those times...

Anyway it looks like i have another problem with my dcf reception. The reception is all but stable. At first sight i have a lot of interference here in Brussels. If i look closer to the signal comming out of the conrad receiver (and i tried two of those) i see spikes on the signal and the LPC1343 i am using is fast enough to detect those and generate an interrupt.
So I will start on other subroutines and wait with the DCF reception until i figured out what the origin is of the spikes.

Concerning the RTOS, it looks like a great idea but first i want to become a bit more experienced with programming the device in C. I try to take it one step at a time.

[lpcware]

Content originally posted in LPCWare by Rob65 on Mon Jun 13 04:02:21 MST 2011
Hi Serge,

yes, doesn't it seem silly to have an RTC and no battery backup option.
Well surprisingly the lpc12xx seems to have no separate Vbat input.
Luckily the lpc1754 does - so battery backup is available, including a calibration register and 20 bytes battery backuped ram.

---

Quote:

I am a newbie in c-programming for ARM. Before i always used a 8051 or  compatible chip and programmed it in assembler. During my studies Intel  was just done with the 8048 (a 4 (yes four) bit controller) and the 8085  was brandnew at the time.

---

I remember those also ... The first microcontroller circuit I designed was around an 8048 with an external EPROM. As I remember this is an 8 bit CPU and that's also what the Intel manual tells me.

Sounds like you are also from a generation that is still able to read datasheets and manuals :D so I guess you will not have much problems learning the lpc13/17 family. There are lots of examples available that may guide your development.
For process control I can recommend to use an RTOS like FreeRTOS to program your tasks in. It will take you a few days to get the hang of it but then it will save you much of the manual labor you otherwise would have.
When I started with FreeRTOS I created a little thread with some tips (link) that might be helpful.
To be able to measure the time in system ticks (which have a 1 ms resolution in the standard setup) you can create your own tick hook function to count system ticks or just remove the static declaration from xTickCount (defined in tasks.h) so that it is accessible to your application.

Happy Programming!

Rob

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Mon Jun 13 02:58:22 MST 2011
New LPC12xx has RTC also... :)

[lpcware]

Content originally posted in LPCWare by serge on Mon Jun 13 02:10:48 MST 2011
:D
Rob and Zero thanks for the fast reply.
By the way, i need the RTC chip since it has a battery backup. I can't garantee that the system will have continious power since at least twice a month there is a general power failure due to the very old high tension lines. Concerning the accuracy: the DS3232 has a aging register to compensate xtal 'aging' and since the time will be adjusted at least once a day with the DCF signal it will be accurate enough for the application. Also the RTC chip has some battery backed-up ram (236 bytes) i intend to use.
I think i will have to read the user manual (yes indeed RTFM) of the LPC17xx more toroughly since i didn't noticed if the RTC timer in the LPC17xx can be battery operated in case of power failure. Of course one can use a huge battery to power the whole system but the pumps and valves i need to control will be powerless also ...

Anyway i always find great help here, thank you guys.

PS. I am a newbie in c-programming for ARM. Before i always used a 8051 or compatible chip and programmed it in assembler. During my studies Intel was just done with the 8048 (a 4 (yes four) bit controller) and the 8085 was brandnew at the time.

[lpcware]

Content originally posted in LPCWare by Rob65 on Sun Jun 12 23:57:47 MST 2011
Thanks to Zero for this example.
This just shows how easy it is ... to start all over and use features that are available on the lpc13xx or 17xx controllers.

First, the DCF routine used in T-Clock uses a 10 ms interrupt to poll the DCF signal.
Why would we do this when we have GPIO interrupts...

Setup a timer to count and create an interrupt that is called on rising and falling edge of the DCF signal. Wait for a falling edge, start the timer and wait for a rising edge (I am assuming that the DCF signal is normally low and only high during the 100-200 ms pulse).
Once you see there is a > 1 second delay (it should be 1800 or 1900 msec) you start counting pulses.
Reset the timer and initialize your DCF decoder.
On the next interrupt (falling edge) you read 1 bit. It is a 0 or a 1 depending of the time (100 or 200 ms). Shift all bits in a variable (>> thus left to right since the least significant bit is received first). As soon as you have the bits belonging to the seconds, minutes etc. align those and call a BCD decoding function to get a real binary number (binary = (BCD & 0xf0) * 10 + (BCD & 0x0f))

When done, stop the timer to free it for any other task.

If you want to make it really nice you could even keep track of the time between the edges of the DCF signal and calculate a quality attribute depending on the spread in timing. And if might be wise to check for a valid time (minutes over 59 make no sense, neither do hours over 23).

Rob

[lpcware]

Content originally posted in LPCWare by Ex-Zero on Sun Jun 12 13:18:21 MST 2011

---

Quote:

...all i got was sample code for Microchip's PIC series and Atmel AVR...

---

We are coming closer: LPC2106 :)

http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/glcd_dcf77/index.html

[lpcware]

Content originally posted in LPCWare by Rob65 on Sun Jun 12 12:12:43 MST 2011

---

Quote: Serge
Hello all,

I was looking for some DCF77 receiver code for the ARM Cortex-M3 series (I am going to use a LPC13xx or LPC17xx depending on the size of the finished code)

---

If you use an lpc17xx you don't need an external RTC anymore, just a 32.768 kHz crystal. And surprisingly the lpc1754 is cheaper than an lpc1343 (when buying from Farnell) :eek:

It should be easy to convert from one of the other microcontrollers to the lpc so just go ahead and give it a try.
Just don't reinvent the wheel - reinventing hot water sounds great: solar energy could do with a new form of hot water that is able to store more energy ;)

---

Quote:
I already use a very acurate RTC chip DS3232. I only need the DCF receiver to set the clock in the RTC chip and to keep it synchronised.

---

Very accurate ... Crystal aging is +/-5ppm which still is 2.5 minutes per year :D