This month I will only publish a blog post but no new article. This is because I have put some enormous efforts into getting release 3.0.0 of my DCF77 library out. This release got a complete overhaul of the internals. The most important new feature is ARM support (Arduino DUE). Since all known DUE boards have a crystal instead of a resonator this now makes my library accessible to more people. Also since ARM has much more memory I introduced milliseconds resolution. This in turn required some quite heavy optimizations. As a byproduct the result now consumes less CPU and less flash memory. Although this was not a design goal it is very much welcome as the AVR based Arduinos have neither a lot of sram nor to much flash.
Another impact is the incompatible change of the interfaces. But do not worry, the semantics remain basically untouched. The migration is also simple.
1) If you project is already finished with release 2 of the library, do not migrate. The new version does not offer more noise tolerance.
2) If you start a new project, use release 3.
As some of my readers noticed my documentation could be better. I agree with this. This is something I will take care of in the coming months. Till then I would be pleased if I get feedback on release 3.
Blinkenlight 
Hi,
I can report this new librairy to work well on an atmega328 with a crystal but not with the ceramic resonator (I am currently in Dunkirk (North of France)). On my previous tests, the previous librairy could work sometime with ceramic resonnator (but I were in Strasbourg (East of France)).
Excellent. If it works with a resonator you are very lucky. However I can not recommend it. It may happen that it locks to the signal and due to a temperature change it will lose the lock again. If you want reliable operation a crystal is the only way to go.
Hello Udo
Firstly I would like to thank you and Brett Oliver. I am in the process of building a Master clock similar in design to Brett Olivers. However I have an issue which I am struggling to solve.
My code is based around Bretts, utilising your V2library.
I find very occasionally that the clock changes time permanently.
For example
The clock had been running fine for a good few days, but suddenly I noticed that it had lost 4 minutes. This did not recover until I actually reset the Arduino and let the clock resync.
Should your library resync periodically ?
Kind regards
Pete ( UK just north of London)
Hi Pete,
thanks for the feedback. Can you please run the “Swiss Army Debug Helper” in mode “Ds” for ~30 minutes and send me the logs? Then put it into mode “Da” for another 30 minutes and send me the logs as well?
Another thing: are you absolutely sure that you run an Arduino with a crystal? If so I need the logs. Otherwise get a model with a crystal. The Uno in particular has a resonator (although it looks as if it has a crystal, but the crystal is only used for the USB interface).
You might also want to follow my library development at Github, if you star it you will get automatic updates on any bugfixes.
Kind regards,
Udo
Hi Udo
Thank you for your reply.
I can confirm I am running with a crystal
I have built the clock on a dedicated pcb.
I will upload the Swiss Army knife later to day and send the logs
Thank you for your help
Kind regards
Pete
Hi Udo,
I have got a question regarding the complexity of your example codes.
At the moment I am using the DCF 77 library of Thijs Elenbaas for my clock. (See https://github.com/thijse/Arduino-DCF77/blob/master/examples/InternalClockSync/InternalClockSync.pde)
As you can see, it is on a really low level, made for someone who only wants to benefit of the work behind this library. However, when the DCF 77 loses the signal (In my case because of a TV), my clock gets inaccurate for about 4s in 2 hours.
When I discovered the advantages of your code, I modified the arduino UNO with a crystal and then I tried your simple clock example with success.
In order to optimise my code with your library, I was unable to filter the main informations. By the way, is there really no description for e.g. DCF77_Clock::debug() ?
My question now is, can you publish an example with a very simple structure for your library like Thijs Elenbaas did (without LCD and so on)?
Something like:
Input (pins etc)
Setup
Loop (what functions to call to update the internal uno clock and use the auto tune, serial.print the delta of the frequency left compared to DCF 77)
For me it would be very challenging to do this. Perhaps it is only a small thing for you to do.
To make this clear, I’m very impressed of your project but I’m not so deep into programming.
Kind regards
Christian
Hi Christian,
the easiest example is the simple clock. Also I have documentation at my blog here and in the github repository here.
Why is this not simple enough? What else would you need?
Kind regards, Udo
Hi Udo,
so what you are saying is, that the simple clock includes all advantages of your library?
Especially I’m interested in the auto tune thing.
Perhaps you can help me out with this questions:
1)
What are these commands doing? I couldn’t find it in your documentation (this is what I actually meant by saying I need it easier -> foolproof description of the comments you use) .
a) Clock::time_t now;
b) DCF77_Clock::get_current_time(now);
I assume, that b) stores the time in the variable “now” (type time_t). But what is a) doing?
2)
My original program is based on the time from the DCF 77 which is stored using the Arduino Time library (setTime(…)).
In order to keep it simple for me, I stored the time from “now” in the same way every loop: setTime(BCD::bcd_to_int(now.hour), … etc). So I only had to make little changes in my program.
I’m I right, that I lose all the advantages of your library when the signal is lost?
3)
My clock stays “synced”, but there is a state called “locked”. Do I only have to wait longer or is synced the best state I can get?
I will answer the easy stuff first:
3) “synced” is best
2) No, you do not lose ***all*** advantages if the signal is lost. However there is no magic involved. If there is absolutely no signal the local clock will eventually drift away. However it will resync faster once it gets back.
1) What you are asking for is a “fool proof” explanation of things that are not specific for my library. The first thing is a variable definition the other a method call. It seems that you are unaware of C++ basics and namespaces in particular. As I said this is not specific for my library but C++ language. I recommend that you pick whatever C/C++ beginner book you find suitable and read it. Sorry for not going into more detail but this is definitely beginner stuff. Even though it is beginner stuff it is not trivial. This can not be answered easily in some short comment. Get some book or some online tutorial on it. It is not hard to learn but it takes some time.
Yeah you are absolutely right regarding your rating of my skills 😉
OK then I will delay my work with your library until I got time to learn C++
Thanks a lot
Hi Christian.
Have a look at the code for my Master Clock here http://home.btconnect.com/brettoliver1/Master_Clock_MK2/Master_Clock_MK2.htm
It may give you some examples that will help you show auto tune etc etc.
Brett.
I noticed the library technically does work on an Pro Mini with AtMega328P on 3,3V and 8MHz, although it runs only at half speed.
DCF_Scope prints pulses only 5 or 10 X’s long, Simple_Clock needs two minutes to print a line of 60 dots.
Is there some way to fix this? I use lib 3 on the newest IDE 1.6.6.
Yes, the easiest way is to use a 16 MHz module. The issue is that the library consumes significant computational power of the Arduino. I think 8 MHz might be feasible but will not have to many cycles left for the rest of your code. Why do you want to go down to 8 MHz? There exist Minis with 16 MHz.
If you want to change it anyway you would have to modify the time code and the auto tune code accordingly.
The clock needs to interface with another chip that is only available as 3.3V, and 16MHz is out of SOA for 3.3V.
I did not test if the processing speed was sufficient, though, because i have no scope to check.
Other Arduino libraries adapt to the module chosen, so i thought this will also, or at least throw an error.
But i guess i need to use voltage level adaptors.
I do not agree that other libraries in general adapt to the module chosen.
There are several ways to solve this:
1) Use a level shifter
2) Use an ARM controller. ARM Controllers are 3.3V and the library supports them.
3) Add the mssing code on your own or pay someone to do so.
Respected Udo,
I have tested your DCF77 library, and it works very good 1100 km away from Mainflingen (Belgrade, Serbia), but it is not clear to me why the local Arduino clock drift is so important for your library to lock the DCF signal. Is it possible to reset internal Arduino timer counter on the each end of any received 100 ms or 200 ms signal portions (to minus 100 ms or minus 200 ms), and all other shorter signals ignored? In that way you can sync the local Arduino clock to DCF clock on the every received DCF bit.
Best regards,
Dragan Kujović
Basically I explain the issue here: phase detection details. The main point is that a more accurate allows to narrow down the bandwidth which in turn improves signal to noise ration.
Respected Udo,
thanks for your answer.
With Arduino Due Simple Clock, Simple Clock with Time Zone Support and The Clock sketches are working excellent, but the Scope sketch do not work on the Arduino Due. On the Arduino Mega 2560 Scope works.
On the Arduino Due function int sysTickHook(void) does not work under the Arduino 1.6.7 environment, and because of that, the function process_one_sample() is never called.
Best regards,
Dragan Kujović
Hi Udo,
I get the following errors trying to compile for arm based Arduino:
Arduino: 1.6.7 (Mac OS X), Board: “Arduino Due (Programming Port)”
…
DCF77_Scope:256: error: previous declaration of ‘int sysTickHook()’ with ‘C++’ linkage
int sysTickHook(void)
^
DCF77_Scope:256: error: conflicts with new declaration with ‘C’ linkage
int sysTickHook(void)
^
exit status 1
previous declaration of ‘int sysTickHook()’ with ‘C++’ linkage
I found this on stackoverflow but can’t get the point what’s going wrong:
http://stackoverflow.com/questions/31349865/compiler-error-for-conflicting-variable-declarations-conflicts-with-new-declar
Can you set the compiler to verbose and show me the full context of this error message? That is I need the full compiler log. The point is that I can compile fine on Ubuntu with Arduino 1.6.7. Thus I have a very hard time to figure out why it fails on Max OS X.
Hi Udo,
this is the full log I get trying to compile on OS X:
Arduino: 1.6.7 (Mac OS X), Board: “Arduino Due (Programming Port)”
/Applications/Arduino.app/Contents/Java/arduino-builder -dump-prefs -logger=machine -hardware “/Applications/Arduino.app/Contents/Java/hardware” -hardware “/Users/bl/Library/Arduino15/packages” -tools “/Applications/Arduino.app/Contents/Java/tools-builder” -tools “/Applications/Arduino.app/Contents/Java/hardware/tools/avr” -tools “/Users/bl/Library/Arduino15/packages” -built-in-libraries “/Applications/Arduino.app/Contents/Java/libraries” -libraries “/Users/bl/Documents/Arduino/libraries” -fqbn=arduino:sam:arduino_due_x_dbg -vid-pid=0X2A03_0X003D -ide-version=10607 -build-path “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp” -warnings=all -prefs=build.warn_data_percentage=75 -verbose “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/arduino_55970d8794ac61be8a62ef6a2ecf5a88/DCF77_Scope.ino”
/Applications/Arduino.app/Contents/Java/arduino-builder -compile -logger=machine -hardware “/Applications/Arduino.app/Contents/Java/hardware” -hardware “/Users/bl/Library/Arduino15/packages” -tools “/Applications/Arduino.app/Contents/Java/tools-builder” -tools “/Applications/Arduino.app/Contents/Java/hardware/tools/avr” -tools “/Users/bl/Library/Arduino15/packages” -built-in-libraries “/Applications/Arduino.app/Contents/Java/libraries” -libraries “/Users/bl/Documents/Arduino/libraries” -fqbn=arduino:sam:arduino_due_x_dbg -vid-pid=0X2A03_0X003D -ide-version=10607 -build-path “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp” -warnings=all -prefs=build.warn_data_percentage=75 -verbose “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/arduino_55970d8794ac61be8a62ef6a2ecf5a88/DCF77_Scope.ino”
“/Users/bl/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -DF_CPU=84000000L -DARDUINO=10607 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON ‘-DUSB_MANUFACTURER=”Unknown”‘ ‘-DUSB_PRODUCT=”Arduino Due”‘ “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/libsam” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/CMSIS/Include/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/Device/ATMEL/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/cores/arduino” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x” “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/sketch/DCF77_Scope.ino.cpp” -o “/dev/null”
“/Users/bl/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -DF_CPU=84000000L -DARDUINO=10607 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON ‘-DUSB_MANUFACTURER=”Unknown”‘ ‘-DUSB_PRODUCT=”Arduino Due”‘ “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/libsam” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/CMSIS/Include/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/Device/ATMEL/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/cores/arduino” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x” “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/sketch/DCF77_Scope.ino.cpp” -o “/dev/null”
“/Users/bl/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -w -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -w -x c++ -E -CC -DF_CPU=84000000L -DARDUINO=10607 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON ‘-DUSB_MANUFACTURER=”Unknown”‘ ‘-DUSB_PRODUCT=”Arduino Due”‘ “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/libsam” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/CMSIS/Include/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/Device/ATMEL/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/cores/arduino” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x” “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/sketch/DCF77_Scope.ino.cpp” -o “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/preproc/ctags_target_for_gcc_minus_e.cpp”
“/Applications/Arduino.app/Contents/Java/tools-builder/ctags/5.8-arduino5/ctags” -u –language-force=c++ -f – –c++-kinds=svpf –fields=KSTtzns –line-directives “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/preproc/ctags_target_for_gcc_minus_e.cpp”
“/Users/bl/Library/Arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++” -c -g -Os -Wall -Wextra -std=gnu++11 -ffunction-sections -fdata-sections -nostdlib -fno-threadsafe-statics –param max-inline-insns-single=500 -fno-rtti -fno-exceptions -Dprintf=iprintf -MMD -mcpu=cortex-m3 -mthumb -DF_CPU=84000000L -DARDUINO=10607 -DARDUINO_SAM_DUE -DARDUINO_ARCH_SAM -D__SAM3X8E__ -mthumb -DUSB_VID=0x2341 -DUSB_PID=0x003e -DUSBCON ‘-DUSB_MANUFACTURER=”Unknown”‘ ‘-DUSB_PRODUCT=”Arduino Due”‘ “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/libsam” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/CMSIS/Include/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/system/CMSIS/Device/ATMEL/” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/cores/arduino” “-I/Users/bl/Library/Arduino15/packages/arduino/hardware/sam/1.6.6/variants/arduino_due_x” “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/sketch/DCF77_Scope.ino.cpp” -o “/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/build55970d8794ac61be8a62ef6a2ecf5a88.tmp/sketch/DCF77_Scope.ino.cpp.o”
/var/folders/_q/h3hql6f563q3rs_1ncjg71h40000gp/T/arduino_55970d8794ac61be8a62ef6a2ecf5a88/DCF77_Scope.ino: In function ‘int sysTickHook()’:
DCF77_Scope:254: error: previous declaration of ‘int sysTickHook()’ with ‘C++’ linkage
int sysTickHook(void) {
^
DCF77_Scope:254: error: conflicts with new declaration with ‘C’ linkage
int sysTickHook(void) {
^
exit status 1
previous declaration of ‘int sysTickHook()’ with ‘C++’ linkage
Aha, this explains a lot. The issue is not with the library but with this specific example. I will investigate and fix it.
Sorry for that!
I thought it was clear, that this error appeared when trying to compile your scope example as Dragan mentioned before…
Actually I could have noticed it from the first question. There was enough information in it. But a full log is somewhat easier for me 🙂 What I found out so far: it copiles OK with Arduino 1.6.0 but fails with 1.6.7. So I assume that they did some incompatible change 😦 I need to investigate this further.
Dear Udo,
do you know if your library and the example codes would run on a low-power 3.3V Arduino-328 pro mini with a 8MHz quartz? How much if anything would need to be changed?
many cheers, Rudolf
The time constants needs to be changed. All 4 assignments to
OCR2Awith the values 248, 249, 250 must be changed to 123, 124, 125. In addition all values inisr_handler()that deal withcumulated_phase_deviationmust be changed from -64000, 64000 to -128000, 128000. Again these are 4 places in the code.Notice that it may take several days for the autotune to take full effect. Hence you need a test run of several days to verify if you implmented everything correct. Use the “swiss army debug helper” to verify if everything is OK. If you succeed please drop me a note such that I may include this into the main line.
Dear Udo,
I applied the proposed changes and this is what I get from the DCF77_scope on an 8MHz/3.3V AduinoProMini:
a line every two seconds and quite obviously an otherwise clean signal.
72, +—-7XXXXXXXXX6—-+———+———+———+—-6XXXXXXXXX7—-+———+———+———
73, +—-4XXXXXXXXX8—-+———+———+———+—-6XXXX8———+———+———+———
74, +—-6XXXX7———+———+———+———+—-6XXXXXXXXX7—-+———+———+———
75, +—-4XXXX9———+———+———+———+—-6XXXX7———+———+———+———
76, +—-7XXXX7———+———+———+———+—-5XXXX7———+———+———+———
77, +—-6XXXX9———+———+———+———+—-5XXXXXXXXX7—-+———+———+———
78, +—-4XXXXXXXXX6—-+———+———+———+—-6XXXX6———+———+———+———
79, +—-4XXXX6———+———+———+———+—-6XXXXXXXXX7—-+———+———+———
80, +—-6XXXX9———+———+———+———+—-6XXXX7———+———+———+———
81, +—-5XXXXXXXXX6—-+———+———+———+—-6XXXX8———+———+———+———
82, +—-5XXXX8———+———+———+———+—-7XXXXXXXXX7—-+———+———+———
83, +—-7XXXX7———+———+———+———+—-5XXXXXXXXX6—-+———+———+———
84, +—-6XXXX9———+———+———+———+—-5XXXX7———+———+———+———
85, +—-5XXXX6———+———+———+———+—-6XXXX7———+———+———+———
86, +—-6XXXX8———+———+———+———+—-6XXXX5———+———+———+———
87, +—-7XXXX7———+———+———+———+—-6XXXXXXXXX6—-+———+———+———
88, +—-7XXXX6———+———+———+———+—-7XXXXXXXXX7—-+———+———+———
89, +—-6XXXXXXXXX7—-+———+———+———+—-6XXXXXXXXX5—-+———+———+———
90, +—-6XXXXXXXXX5—-+———+———+———+—-4XXXX8———+———+———+———
91, +—-8XXXX7———+———+———+———+—-7XXXX6———+———+———+———
92, +—-5XXXX6———+———+———+———+—-7XXXX7———+———+———+———
93, +—-7XXXXXXXXX6—-+———+———+———+—-5XXXXXXXXX5—-+———+———+———
94, +—-6XXXXXXXXX7—-+———+———+———+—-8XXXXXXXXX6—-+———+———+———
95, +—-7XXXX9———+———+———+———+—-7XXXX6———+———+———+———
96, +—-6XXXX5———+———+———+———+—-6XXXXXXXXX5—-+———+———+———
97, +—-6XXXXXXXXX7—-+———+———+———+—-7XXXX6———+———+———+———
98, +—-7XXXXXXXXX6—-+———+———+———+—-9XXXX7———+———+———+———
I also tried to update the comment lines in dcf77.cpp:
// 249 + 1 == 250 == 250 000 / 1000 = (16 000 000 / 64) / 1000
// OCR2A = 249; // for 16MHz quarz oscillator
// 124 + 1 == 125 == 125 000 / 1000 = (8 000 000 / 64) / 1000
OCR2A = 124; // for 8MHz quarz oscillator
and:
void isr_handler() {
cumulated_phase_deviation += adjust_pp16m;
// 1 / 250 / 64000 = 1 / 16 000 000 for 16MHz quarz oscillator
// 1 / 125 /128000 = 1 / 16 000 000 for 8MHz quarz oscillator <= 64000) {
// cumulated_phase_deviation -= 64000;
if (cumulated_phase_deviation >= 128000) {
cumulated_phase_deviation -= 128000;
Maybe the apparent inconsistency in the above comment line holds a clue as to where the problem is?
The Simple_clock outputs a dot every two seconds and does not synchronize after 15 minutes whereas the 16MHz Arduino mini pro synchronized after less than 5 minutes.
I can run the swiss-Army-knife but you would have to tell me what output options I should turn on.
best regards, Rudolf
I have a Due board and the latest IDE ARDUINO 1.6.12
I tried to complie Superfilter with the result
D:\__Dokus\Documents\Arduino\Due\DCF\Superfilter\Superfilter.ino: In function ‘void set_output(uint8_t, uint8_t, uint8_t)’:
Superfilter:68: error: ‘enable’ was not declared in this scope
if (enable) {
^
Superfilter:69: error: ‘threshold’ was not declared in this scope
Some of the newer versions of Arduino appear to be broken. Try with 1.6.7. If this does not work go down to 1.6.5.
Toleranz an der DIFF LED.
Von dieser Seite kopiere Anmerkung:
* I also added a “diff” output that shows the difference of the synthesized and the received signal. You may notice that it sometimes flickers slightly. This is because the received signal shape is often slightly “wider” than the synthesized signal.”
Bin gerade voll dabei die Clock von ‘Erik de Ruite’ nachzubauen.
Aktuell habe ich im Testaufbau ein DCF_Modul von ELV sowie den aktuellen Sourcecode von Github.
Das Problem ist das die DIFF LED ständig mehrmals die Sekunde flackert sobald der Filter auf ‘Locked’ schaltet. In der Debug Ausgabe im UART ist bei jeder Ausgabe jeweils ein Block mit XXX zu sehen. Eine Messung mit dem Oszilloskop zeigt das sowohl das Eingangssignal als auch das Ausgangssignal vom Filter in der Pulsebreite variieren.
Eingangsseite: 111ms, 201ms Maximal
Ausgangsseite: 115,5ms, 214,5 ms Maximal
Wenn ich den Code richtig lese ist eine Toleranz von 10ms eingebaut.
Frage ist wie der Toleranzwert auf sagen wie mal 14ms angehoben werden kann?
Hellsehen gehört nicht zu meinen Stärken. Auf welche Stelle im Code beziehst Du Dich? Und wieso willst Du überhaupt etwas daran ändern? Das die Differenz “flackert” liegt in der Natur der Sache. Also entweder Du hängst da einen wie auch immer implementierten Tiefpass hinter das Differenzsignal, oder Du überlegst Dir was *DU* als Differenz eigentlich haben willst und implementierst das entsprechend.