DCF77 Uhr in C mit ATtiny26

Der MAX7219 erzeugt nen Multiplextakt mit hohen Impulsströmen.

Halte ich die Ferritantenne etwa 10cm entfernt geht es auch mit Display.

Ich wollte aber nur ein kleines Gehäuse nehmen, d.h. die Ferritantenne 
sitzt direkt hinter dem Display.


Ich hab den Conrad-Modul direkt an 5V, der hat ja nochmal ne 
Spannungsstabilisierung und Treiberstufen.


Peter

Tolles Programm, der Code ist mal wieder typisch Peter:
Unglaublich mit wie wenig Zeilen Code man ein Programm schreiben kann.

Aber ich habe den Sinn vom MAX7219 noch nicht verstanden:
Klar ist das ein gutes IC zum Multiplexen von Siebensegment-Anzeigen 
oder LED-Matrixen. Aber 6,95 EUR sind halt auch ein Wort. Da kann ja 
jeder ATmega locker mithalten.

Armin K. wrote:

> Aber ich habe den Sinn vom MAX7219 noch nicht verstanden:

Ich nehme ihn gerne, weil sich dadurch das Layouten sehr vereinfacht.

Aber das Programm ist ja modular aufgebaut.
Es ist also kein Problem, ne andere Displayroutine einzufügen.

Z.B. im ADC- und im Jumbo-LED-Beispiel ist ne Multiplexanzeige mit dem 
AVR drin.


Peter

Propper wrote:
>
> Ich nehme ihn eher ungern, nehme den MAX7221 anstelle des 7219
> (allerdings ist der noch teurer). Erstens hat der echtes SPI

Was ist daran ein Vorteil ?

Beide kann man am 8051/AVR ohne Probleme anschließen.

Ob nun Pin 12 die ganze Zeit Low oder nur am Ende ne Flanke machen muß, 
ist doch völlig wurscht.


Das mit der Slew-Rate könnte tatsächlich helfen, aber ich hab eben noch 
einige 7219 rumliegen, zum wegschmeißen wärs zu schade.

Immerhin synchronsiert er besser, als ein gekaufter Funkwecker, der geht 
seit  gestern 2 min nach, manchmal wars auch ne Stunde.


Peter

Matthias wrote:

> kann ich mal die Schaltung sehen? In der wo der MAX.. den Empfang
> stört..


Schaltplan habe ich keinen.
Die 5V werden aus ner Trafo-Wandwarze mit nem 7805 gemacht und noch 
220µF dahinter.
Alle ICs haben µ1-Pillen, der 7805 hat 2, also insgesamt 4 Stück.

Das Conrad DCF-77 ist mit etwa 30cm 3-adrig angeschlossen, strecke ich 
die 30cm aus, gehts auch mit Anzeige an.


Peter

swesch wrote:

> 1. Frage: vom DCF-Modul den "normalen" oder den invertierenden Ausgang?

Ich habe den äußeren Anschluß freigelassen.


> 2. Frage: Mein AtMega8 läuft mit externem Quarz bei 3686400 Hz.

#define XTAL 3686400L


Peter

Ja, der Kommentar stimmt natürlich nicht mehr bei nem anderen XTAL-Wert.

Also nicht -183, sondern der Wert, der aus der Formel im Define 
rauskommt.


Peter

swesch wrote:

> Ich hab die Ausgaberoutinen auf ein LCD umgeschrieben.
...
> Leider zeigt's manchmal völlig falsche Uhrzeiten an.

Ohne Programm kann man dazu schlecht was sagen.

Der Fehlertest ist jedenfalls sehr streng. Er übergibt lieber keine 
gültige Zeit, als eine fehlerhafte.
Bei gekauften DCF77-Weckern habe ich dazu im Gegensatz schonmal falsche 
Zeiten sehen können.

Daher wird der Fehler vermutlich in Deinen Änderungen (LCD-Routine) 
liegen.


Peter

Hmm.

Könnte vielleicht die LCD-Ausgabe zu lange dauern.

Ruf mal das scan_dcf77 im Timerinterrupt hinter dem DCF77-Empfang auf, 
statt im main.
Es ist ja nur sehr wenig Code, kann man also auch direkt im Interrupt 
machen, dann spielt die Main-Zeit keine Rolle mehr.


Peter

swesch wrote:

> Ich versteh nur nicht warum...

Die Routine funktionert nur, wenn sie garantiert bis zur nächsten Flanke 
aufgerufen wurde, also innerhalb 100ms.

Wenn die Mainloop aber länger dauert, dann muß man sie in den Interrupt 
mit reinhängen. Dann ist es egal, wie langsam die Mainloop ist.

Und wenn die Mainloop länger als 1s dauern kann, muß man auch die 
clock-Routine mit in den Interrupt reinhängen.

Solange keine anderen zeitkritischen Interrupts bestehen (z.B. schnelle 
Mehrkanal-Software-PWM) ist das total unkritisch.


Manche Leute hängen sogar Delays oder Divisionen mit in Interrupts rein, 
das kann dann oft sehr böse ins Auge gehen.


Peter

horst wrote:

> in der Routine clock() muesste doch eigentlich
> stehen:
>         if( LPM(MDAYS + i ) == time.day )


Stimmt.

Peter

neo_87 wrote:

> könnte darum jemand bitte die funktion von der variable synchronize
> erklären

synchronize wird gesetzt, wenn scan_dcf77 ein Paket vollständig und 
fehlerfrei empfangen hat, das kann 3min dauern bzw. bei Störungen länger 
(vom PC weggehen oder ausschalten).

Wenn Du das STK500 benutzt, kannst Du ja mal newtime.second auf nen Port 
ausgeben und mit den LEDs ansehen (1 = LED aus), der muß im Sekundentakt 
von 0..58 zählen.


Peter

Hallo Peter,

beim ausprobieren Deines Codes ist mir etwas aufgefallen:

Der Timer läuft 64 Mal pro Sek. über. Somit sind die 100ms bzw. 
200ms-Bitzeiten 6,4 bzw. 12,8 Überläufe lang (Nachkommastelle nur der 
Theorie wegen;-). Bei mir betragen sie meist 7 bzw. 13 Überläufe.

in der Funktion scan_dcf77() testest Du die Bit-Gültigkeit auf
if( dcf77_pulse > 3 && dcf77_pulse < 8 ) bzw.
if( dcf77_pulse > 10 && dcf77_pulse < 14 ).

Da das in meinem Fall grad so an der Grenze mit der realen Überlaufzahl 
liegt, wurde die Zeit eher selten erkannt. Durch hochsetzen auf
if( dcf77_pulse > 5 && dcf77_pulse < 9 ) bzw.
if( dcf77_pulse > 11 && dcf77_pulse < 15 )
klappt es super.

Vielleicht hab ich ja auch einen Denkfehler (ist schon spät...) - aber 
wenn deckt der sich prima mit der Funktionssicherheit;-))

Gruß Frank

@Frank,

ich hatte angenommen, es wird abgerundet, müßte nochmal genauer in das 
Programm sehen.

Welchen Quarz nimmst Du denn und welchen Empfängermodul ?
Vielleicht werden die Pulse ja durch den Empfänger etwas verschliffen.

Wie ich damals die Fenster ermittelt habe, weiß ich nicht mehr.
Hast aber recht, die sollten schon mittig um die Impulslängen liegen.


Peter

Hallo Peter,

momentan ist ein 10MHz-Quarz drin. Die Konstanten im Vergleich:

1

        // at 12MHz,  at 10MHz:

2

#define T0COUNT    (F_CPU / 1024 / 64)                    //183, 152

3

#define T0SECERR   (F_CPU - 1024L * 64 * T0COUNT)    //6912, 38528

4

#define T0COUNTSEC (T0COUNT + T0SECERR / 1024)            //189, 189

5

#define T0MINERR   (F_CPU - 1024 * (63 * T0COUNT + T0COUNTSEC)) //768, 640

6

#define T0COUNTMIN (T0COUNTSEC + (T0MINERR * 60 + 512) / 1024) //234, 227

Die Ticks sind wegen Integer-Rundung von T0COUNT statt 1/64 Sekunden 
1/64,25 Sekunden. 100ms benötigen demnach 6,425 Überläufe. Meine 
Eingangsschutzschaltung mag etwas verschleifen, daraus resultieren wohl 
die 7 bzw. 13 Überläufe. Als DCF-Quelle benutze ich momentan wegen 
Empfangsproblemen den RS232-DCF77-Simulator
Beitrag "Re: DCF77-Signal generator" .
Und wer weiß, was Windows daran noch zusätzlich zeitlich verschmiert ;-)

Gruß Frank

Nachtrag

Conrad-DCF-Empfängerplatine Best.Nr.641138 an langer Leine (Empfang am 
Fenster) macht 6..7 bzw. 12..13 Überläufe.

Sebastian wrote:
> Könnte mir jemand erklären was diese Zeilen machen?
>
>    i = LPM(&BITNO[i]);
>
>  *d += LPM(&BMASK[i]);      // set bit

Jedes Bit hat eine bestimmte Bedeutung (Variable, Wert) und der Wert 
steht
in der Tabelle BMASK (1,2,4,8,10,20,40 oder 80).


> Set bit?? Ich hab keine Ahnung was dieses LPM eigentlich ist.....

Ist in types.h definiert:

#define code PROGMEM
#define LPM(i) (__LPM_classic__(i))

Es ruft GCC-Macros auf, um konstante Daten im Flash zuzugreifen.


Peter

@Sebastian,

Du hast recht. Da ist was schiefgelaufen beim Umschreiben von Keil C51 
auf WINAVR. Richtig muß es so lauten:

1

if( LPM(MDAYS+i) < time.day ){

Peter

Kannst du messen, ob das Problem am DCF77 Modul liegt, dass es einfach 
keine Daten ausspuckt? So könnte man das Problem eingrenzen.

PS: Wo wohnst du? Ich war schon 2x im Mathematikum, hab die Uhr noch 
nicht gesehen, muss also relativ neu sein oder?

Hmm das mit den 3 Jahren kommt etwa hin ... kurz davor war ich das 
letzte mal da (noch mit der Schule).

Zum Thema:
Da die DCF77 Module sehr wenig strom ziehen kann man eigentlich ohne 
Probleme einen RC Filter davor hängen um Störungen durch die 
Versorungsspannung zu minimieren.

Ich hab hier nur nen DCF77 Modul von Reichelt, das Spuckt eigentlich 
schon nach wenigen Sekunden was aus. Das Modul hat aber auch nur nen 
Bockkondensator in der nähe.

Warum der Code nicht tut kann man leider ohne Code nicht direkt 
überprüfen ;)

Aber sonst: schöne Uhr und vor allem nicht so klein wie all die anderen 
Uhren in dieser Form !

PS: Ich wohne bei Marburg.

Hallo,

Ich hab jetzt auch ein DCF 77 Modul an mein STK500 gehängt. Als Ausgabe 
benutz ich ein LCD Display an Port D. Das DCF Modul hängt an PC2. Leider 
funktioniert das Ganze noch nicht ganz. Es wird nie mit der DCF77 Zeit 
synchronisiert.

Ich benutz einen Mega 8 mit 8 Mhz internen Takt. Die normale Uhr zählt 
brav nach oben.

In der Main habe ich folgenden Code auskommentiert:

1

     /* if( synchronize == 0 )

2

        continue;

3

      if( synchronize == 1 && time.hour == 3 ){

4

        if( time.minute == 20 )

5

6

        if( time.minute == 28 )

7

          synchronize = 2;

8

        continue;

9

      }

10

      if( time.hour == 4 )

11

        synchronize = 1;*/

Im Code toggle ich eine Led nach   if( dcf77_period )
Da blinkt die Led ordentlich. Ich geb auch newtime.second auf dem 
Display aus. Die Variable zählt aber nur sporadisch nach oben (nicht im 
Sekundentakt)

Die Variable synchronize bleibt immer 0.

Weiß jemand woran es liegen kann?

Danke im Voraus
Gruß Robert

Vielleicht schlechter Empfang?
Die spannungsversorgung vom STK500 kann auch schuld sein, die module 
sind SEHR empfindlich gegen spannungsschwankungen.

mal nen RC filter in der VCC leitung probieren.

ich wrote:
> läuft der interrupt mit 64hz oder mit 1hz?

64Hz

Peter

Versuche von Peter den Code zum laufen zu bringen bekomme aber immer 
eine Fehlermeldung:
AVR PROGRAMME__ ASSEMBLER\tn12def.inc(141): error: F: Unknown 
instruction or macro

die Zeile sieht da so aus :
.equ E2END = 3F

was mache ich da falsch??

Hallo,
ich bin gerade dabei den Code zu verstehen, da ich ihn auf einen Tiny44V 
portieren möchte. Außerdem soll die Uhr Batteriebetrieben funktionieren. 
Also AVR Takt runter auf 250Khz und den DCF Empfänger die meiste Zeit 
vom Strom getrennt. Die Uhr soll nur den Wochentag (7 LEDs) anzeigen, 
also kommt es auf ein paar Sekunden +- nicht an.

Den Timebase Teil habe ich verstanden.
Syncronize sorgt dafür, dass das Display ausgeht, wenn knapp 24 Std kein 
korrekter Empfang mehr vorlag und danach wieder an. Eine weitere 
Funktion scheint es nicht zu geben.

Müsste ich mit dem Pulslängenvergleich nicht auch Probleme bekommen? Der 
interne Oszillator darf ja +-10% abweichen.

Hallo nochmal,
also der Code funktioniert bei 1MHZ super. Aber gibt es irgend einen 
Grund, warum er bei 500kHZ oder 250KHz nicht AVR Takt nicht 
synchonisieren möchte?
Ich habe verschiedenes Versucht
1. Takt auf 500kHz und XTAL angepasst
2. Takt auf 250khz Teiler für Timer0 auf 64, XTAL und Formeln angepasst
3. Takt auf 250khz, XTAL auf 1MHZ gelassen, Formeln unverändert gelassen 
aber Teiler für Timer0 auf 256 reduziert.
Um die Toleranz zu erhöhen habe ich die beiden Zeitgschranken zum Bit 
erkennen jeweils um +1 und -1 vergrößert.

Die Hauptschleife besteht nur aus ein paar if Abfragen zum Port setzen 
und andschließendem aktivieren des Idle Modus des Controllers.

Hier jetzt meine Version basierend auf der von Peter, für einen Tiny44V 
(oder auch Tiny24V..). Die Ansteurung des MAX7219 wurde entfernt.
7 LEDs zeigen jeweils an, welcher Wochentag gerade ist. Ideal für ältere 
vergessliche Leute, für die kaufbare LCD Uhren zu schwer lesbar sind.
Nach dem Synchronisieren liegt der Stromverbauch bei 487µA (inclusive 
~360µA für eine LED), damit müsste die Schaltung bis zu 4000 Stunden = 
~5 Monate mit zwei 2000mAh Akkus laufen (meist aber wohl weniger wegen 
der Selbstentladung).

Ich hatte zunächst versucht den Stromverbrauch durch Absenken des Taktes 
auf 32kHz nach dem Synchronisieren weiter zu reduzieren und zum 
Weiterlaufen der Uhr nur noch sekündlich ein Wake-Up des Kontrollers 
auszuführen. Aber dies hatte auf den Stromverbauch keinen messbaren 
Einfluss, so dass ich dies wieder sein gelassen habe.

Hallo Peter,

Kann man den Code auch zum Auslesen des Sommerzeit-Bit erweitern?
Das müsste das 17 Bit sein.

Günter

Hallo,

ich brauche für eine ganz simple Einschaltverzögerung für ein kurzes
anliegendes Signal von 1-1,5 Sekunden (bzw. einstellbar in 0,1 sec).

Mit diesem Programm lässt kann man einfach einen Port 1 bis 2 Sekunden 
einschalten.

1

...

2

( timeflags & 1<<ONE_SECOND ){

3

...

Was muss ich in der timebase.c an den Timer ändern oder erweitern,
um die 0,1 Sekunden einstellen zu können?


Grüsse, Günter

C. D. schrieb:
> Hi,
> bei mir klappt der Empfang ganz ausgezeichnet. Allerdings ist mir
> unklar, warum die Variable synchronize außer bei der Initialisierung an
> keiner Stelle im Code auf 0 gesetzt wird.

Das ist schon richtig so.
0 bedeutet, warte bis eine gültige Zeit empfangen wurde und schalte dann 
das Display ein.
Danach wird nur bei Bedarf um 3.20Uhr das Display ausgeschaltet für 
neuen Empfang.


Peter

Helmut schrieb:
>> Unglaublich mit wie wenig Zeilen Code man ein Programm schreiben kann.
>
> Stimmt. Allerding macht diese Kürze den Code sehr kryptisch und für
> einen unerfahrenen Programmierer nahezu unlesbar. Dies soll jetzt aber
> keinesfalls negativ gemeint sein.

Naja, ich würd mich nicht als unerfahren bezeichnen... das alles 
auseinander zu klabüstern (regelrechte Header etc.) und die magischen 
Zahlen rausfischen nimmt schon was Zeit in Anspruch.

Übrigens lässt sich

1

time.second = 0;

2

time.minute = newtime.minute;

3

time.hour = newtime.hour;

4

time.wday = newtime.wday;

5

time.day = newtime.day;

6

time.month = newtime.month;

7

time.year = newtime.year;

platzsparender und übersichtlicher (allerdings etwas langsamer) 
formulieren als

1

time = newtime;

2

time.second = 0;

Macht für die paar Zeilchen immerhin rund 30 Bytes.

Johann

...und in click.c lassen sich auch nochmal 30 Byte sparen.

Ausserdem muss es doch heissen

1

if( LPM(MDAYS+1+i) == time.day ){

anstsatt

1

if( LPM(MDAYS+1) == time.day ){

Oder?

C. D. schrieb:
> Hi,
>> also der Code funktioniert bei 1MHZ super. Aber gibt es irgend einen
>> Grund, warum er bei 500kHZ oder 250KHz nicht AVR Takt nicht
>> synchonisieren möchte?
>
> [...] Eine '0' bedeutet eine Absenkung des Pegels für 0,1
> Sekunden, d.h. ca. 6,4 Ticks (wenn ein Tick exakt 1/64 Sekunde = 0,0156s
> dauert).
> Wenn ein Tick dagegen 0,0122s dauert, enspricht eine '0'  ca. 8,2 Ticks.
> Wie man im Code sehen kann, ist die Prüfung damit nicht mehr
> erfolgreich.

Der Empfänger ist eben ausgelegt für 64 DCF-Ticks pro Sekunde. Bei einer 
anderen Tick-Anzahl kann man also nicht erwarten, daß er noch 
reibungslos funktioniert. Man kann die "magischen Zahlen", die in der 
Integritätsprüfung auftauchen, jedoch einfach herausparametrisieren 
durch Makro(s), das die Anzahl DCF-Ticks pro Sekunde enthält.

Johann

C. D. schrieb:

> Noch Gedanke dazu:
> Wegen des Rundungsfehlers gibt es für XTAL=250kHz noch ein anderes
> Problem.

Man kann doch problemlos eine andere Tick-Anzahl implementieren, zB 100 
Ticks/Sekunde. Der Algorithmus ändert sich dadurch nicht (bis auf das & 
0x3f an einer Stelle, was man minimalinvasiv ändern kann, und die paar 
magischen Zahlen).

Es ist immer eine gute Idee, eine solche IRQ-Rate zu wählen, die keine 
Moiré-Effekte irgendwo erzeugt.

Johann

Gast schrieb:
> Müsste es nicht (newtime.second < 59) sein, da sonst der Wert 60
> zustandekommen könnte, und dann nie synchronize gesetzt wird?

Ne, 60 muß möglich sein, um Störimpulse zu erkennen.
Es ist eigentlich unnötig, da eine Anzahl von 256 + 59 Störimpulsen 
nicht möglich ist, ohne die Pulslängen- und Abstandstests zu 
überschreiten.

> Warum wird immer auf unsigned int gecastet? Ist doch nur ein 8 bit
> Timer.

Dann gibt es ne Warnung, wenn 8Bit nicht mehr ausreicht.


Peter

Ne, das ist Bit 17:

1

u8 new_mesz;

2

3

void decode_dcf77( u8 pulse )

4

{

5

  static u8 parity = 0;

6

  u8 i;

7

  u8 *d;

8

//----------------------- MESZ 

9

  if( newtime.second == 17 )

10

    new_mesz = pulse;

11

//----------------------------

12

  i = newtime.second - 21;

13

  if( i >= sizeof( BITNO ))      // only bit 21 ... 58

14

    return;

15

  parity ^= pulse;        // calculate parity

16

  i = LPM(&BITNO[i]);

17

  if( i == 0xFF ){        // test parity

18

    if( parity )

19

      dcf77error = 1;

20

    parity = 0;

21

    return;

22

  }

23

  d = (u8 *)&newtime.minute + (i >> 4);    // byte address

24

  i &= 0x0F;          // bit number

25

  if( i == 0 )

26

    *d = 0;          // clear all, if lsb

27

  if( pulse )

28

    *d += LPM(&BMASK[i]);      // set bit

29

}

Und dann eben noch bei der Zeitübernahme das new_mesz übernehmen, wenn 
das Paket gültig war.


Peter

Hallo Peter,

danke für das tolle Programm.

Das DCF-Modul ist sehr robust. Tolle Programmiertechnik.

MfG.

Tom schrieb:
> Mmmh. Der Code ist ja so gut kommentiert, wie die Opensolaris
> Kernelquellen...

Peters Code ist sicher alles andere, als gut dokumentiert, gut 
strukturiert oder für jemand der GNU-Code gewohnt ist, gut 
lesbar....aber eines muss man ihm lassen:

Seine Methoden sind hocheffizient und platzsparend...

Das hier ist nicht der erste Code-Schnipsel von Peter, den ich verwende; 
und jedesmal musste ich den Code erstmal komplett aufräumen.
Aber, Peter dafür zu kritisieren, find ich unangemessen.
Der Umfang seiner hier veröffentlichen Projekte sollte es jedem, der ein 
wenig Erfahrung mit C hat erlauben, sich da reinzudenken. Wem das nicht 
gelingt, der sollte sich erstmal mit C-Grundlagen beschäftigen!
Es geht mit C noch sehr viel schlimmer! (20KB langer "Einzeiler")

Harry

Harald L. schrieb:
> Das hier ist nicht der erste Code-Schnipsel von Peter, den ich verwende;
> und jedesmal musste ich den Code erstmal komplett aufräumen.

Kannst Du bitte mal so ein aufgeräumtes Codebeispiel zum Vergleich 
posten?


Peter

Hallo Peter,
ich bin gestern auf deine DCF77uhr gestossen, und hab die für meine 
Zwecke angepasst.
LED-Ausgabe o.Ä. brauch ich in meinem Projekt nicht.

Was ich im wesentlichen gemacht habe:

* Dateinamen die nur aus Großbuchstaben bestehen sind unter Linux ein 
absolutes NoGo. Daher werden zunächst alle Dateien in Namen mit 
Kleinbuchstaben umbenannt.

* Du definierst in deiner types.h eigene Typen für die gängigen 
Integers. In den Atmel Headern findet sich aber bereits uint8_t, int8_t 
usw. Um den Code auch nach längerer Zeit lesbar und verständlich zu 
halten, hab ich alle Var-Definitionen auf die Atmel-Typen umgestellt.

* alle wichtigen Includes in eine Header-Datei zu schreiben, spart zwar 
ein wenig Tipperei, aber macht den Code nicht gerade übersichtlicher.

* das Thema "Code-Formatierung" sprech ich jetzt mal gar nicht an. Das 
macht Eclipse für mich auf Knopfdruck ;)

In dem ZIP-File ist kein Makefile, da ich mit Eclipse arbeite. In dem 
ZIP-File ist der vollständige Inhalt meines Projektordner nach dem "make 
clean".
Ich hoffe, daß du deinen Code noch wiedererkennst. ;)

Selbstverständlich hab ich alle Hinweise auf den Autor im Code belassen.

Harry

Eins hab ich noch vergessen:

Alle Includes sollten durch entsprechende #define- und 
#ifdef-Kombinationen vor mehrfachem Einbinden geschützt werde. Als Code 
sieht das dann so aus:

1

/*

2

 * myinclude.h

3

 *

4

 *  Created on: 25.06.2010

5

 *      Author: harry

6

 */

7

8

#ifndef MYINCLUDE_H_

9

#define MYINCLUDE_H_

10

11

// hier kommt der Inhalt rein!

12

13

#endif /* MYINCLUDE_H_ */

Harry

Harald L. schrieb:
> Ich hoffe, daß du deinen Code noch wiedererkennst. ;)

Ich heisse zwar nicht Peter, aber das Zip-Archiv ist irgendwie kaputt, 
denn ich konnte da zunächst gar nix erkennen ;-)

- filzip unter Windows zeigt nur leere Ordner

- unzip-Kommando-Version unter Windows zeigt zwar Dateien, die kann
  man aber nicht auspacken, da die Dateien im zip-Archiv mit absoluten
  Pfaden gespeichert sind.

- 7zip unter Windows kann es unter Anzeige eine unleserlichen
  Hauptordners.

- unzip-Komando-Version unter Linux entpackt dann die Dateien - unter
  Angabe von:

    warning:  stripped absolute path spec from dcf77.cproject
    .... (usw).


Wer beim Programmieren auf Portabilität/Lesbarkeit achtet, sollte auch 
beim Erstellen eines Zip-Archivs eine gewisse Sorgfalt an den Tag legen 
;-)

Gruß,

Frank

Also ich kann alles lesen.
Ich benutzte WINRAR, da ist alles paletti.


Peter

Frank M. schrieb:
> Wer beim Programmieren auf Portabilität/Lesbarkeit achtet, sollte auch
> beim Erstellen eines Zip-Archivs eine gewisse Sorgfalt an den Tag legen
> ;-)

Sorry, ich versteh dein Problem nicht. Bei mir geht das problemlos.
Ich hab allerdings auch keine Möglichkeit das unter WinDoof zu testen.

Harry

Harald L. schrieb:

> Sorry, ich versteh dein Problem nicht. Bei mir geht das problemlos.

Dann packe die zip-Datei unter Linux wieder aus und versuche, die dabei 
ausgedruckten Warnings zu verstehen.

> Ich hab allerdings auch keine Möglichkeit das unter WinDoof zu testen.

Das hat überhaupt nichts mit "WinDoof" zu tun.

Das Erstellen von tar- oder zip-Archiven mit absoluten Pfaden darin(!) 
ist ein absolutes NoGo und gilt als nicht sehr "höflich". Damit haben 
sich schon oft Admins in der Vergangenheit unter Unix/Linux/Windows 
wichtige Systemdateien überschrieben. Deshalb wurde dann auch schon vor 
vielen Jahren beim GNU-Tar und auch unzip unter Unix/Linux das Strippen 
von führenden Slashes eingebaut - abweichend vom System-V-tar, welcher 
auch heutzutage noch unter bestimmten Unix-Derivaten Dateien mit 
absoluten Pfaden gnadenlos überschreibt.

Gruß,

Frank

Frank M. schrieb:
> Deshalb wurde dann auch schon vor
> vielen Jahren beim GNU-Tar und auch unzip unter Unix/Linux das Strippen
> von führenden Slashes eingebaut - abweichend vom System-V-tar, welcher
> auch heutzutage noch unter bestimmten Unix-Derivaten Dateien mit
> absoluten Pfaden gnadenlos überschreibt.
>
> Gruß,
>
> Frank

Stimmt!....ich hatte es mir bequem gemacht, und Eclipse das Archiv 
erzeugen lassen. Daß der "führende Slashes" einbaut, war mir -ehrlich 
gesagt- gar nicht bewusst.
Stellt aber heute auch nirgendwo mehr ein Problem dar(s.o.). Die 
einzigen Warnungen, die beim manuellen Entpacken auftauchen beziehen 
sich eben auf das Entfernen dieses Slash am Anfang.

Harry

Das sollte gehen (mit WINRAR entpackt und wieder gepackt).


Peter

Peter Dannegger schrieb:
> Das sollte gehen (mit WINRAR entpackt und wieder gepackt).

Danke, geht.

Gruß,

Frank

Hallo,

wie wäre es mit etwas fertigem?
http://www.sehhelfer.de/Mit-Sprachausgabe/Wecker/Sprechender-Funk-Wecker-Time.html 
oder
http://www.techno-hilfe.de/Sprechender-Funk-Wecker-Time

Das scheint aber etwas kleine Tasten zu haben.Das Gerät kann man sicher 
zurückschicken, wenn es nicht klappt.

Mein Vater ( 91 ) ist mit Uhrzeit und Temperaturaansage von einem 
anderem Gerät sehr gut zufrieden.Zum Glück behält er noch, welchen Knopf 
er drücken muss.

Peter,
wo wird die decodierte DCF77-Zeit in die Variable newtime geschrieben?
Ich hab das noch nicht verstanden.

Armin K. schrieb:
> wo wird die decodierte DCF77-Zeit in die Variable newtime geschrieben?

In dcf77.c:

1

  d = (u8 *)&newtime.minute + (i >> 4);    // byte address

2

  i &= 0x0F;          // bit number

3

  if( i == 0 )

4

    *d = 0;          // clear all, if lsb

5

  if( pulse )

6

    *d += LPM(&BMASK[i]);      // set bit

Peter

Harald L. schrieb:
> Hallo Peter,
> ich bin gestern auf deine DCF77uhr gestossen, und hab die für meine
> Zwecke angepasst.
> LED-Ausgabe o.Ä. brauch ich in meinem Projekt nicht.

Super, es hat nach kürzester Zeit geklappt mit einem Funkmodul von 
Pollin und Atmega 128.
Ich habe mich schon seit Wochen mit dem Funkmodul rumgeärgert!
1min 40sec bis zum Empfang (auf dem Schreibtisch mit Monitoren und 
ungeschirmtem Zeug drumherum).

Hier noch ein paar Bilder vom Aufbau.

Basis ist ein eHaJo atmega32u4 Board mit LUFA CDC Bootloader, ein 
martübliches LCD JHD162A und ein DCF77 Empfangsmodul.

Das DCF77 Empfangsmodul erhält über eine Diode (BAT43) und ein CRC Glied 
seine Versorgungsspannung von ~5V, da ich die 5V gerade über den USB Bus 
beziehe.

C1,C2 = 10µF
R = 100Ω

ich wollte mal eine Rückmeldung geben.

Ich nutze ja nun auch gerne den Code am Arduino weil er so schön knapp 
ist mit allen Prüfungen.

Meine Impulse sind aber etwas verkürzt also habe ich die 1 0 Schwellen 
anpassen müssen, dabei stellte sich heraus das heute 2014 erkannt wurde 
trotz Paritätsprüfung....

Wenn der Code NUR Parität und Plausibilität prüft, wirst Du da immer 
nach 5min bis 5h, bei heftigeren Störungen, irgendeinen plausiblen 
Blödsinn sehen.