DCF77 Chip Ausgabeformat

[Abdul K. (ehydra)]

Ich würde gerne einen DCF77 Empfängerchip unter die Leute bringen. Da 
ich erst am Anfang der Softwareentwicklung bin, können noch Vorschläge 
für die Datenausgabe eingebracht werden.
Momentan dachte ich an ASCII im UART-Format 8N1 mit 2400Baud. 
Darstellbar in jedem Terminalprogramm mit CRLF am Blockende.
Dazu vielleicht einen weiteren Block, in dem die max. 60 Bits als 
3x<hex> übertragen werden, sodaß man auch eine eigene Dekodierung z.B. 
der Wetterdaten dann vornehmen kann.
Brauch dann noch wer den Pulsecode? Es sind halt nur begrenzt Pins am 
Controller.

Also her mit den Ideen.

[Silvan K. (silvan)]

Abdul K. schrieb:
> Es sind halt nur begrenzt Pins am
> Controller.

Wie viele?

[Konrad S. (maybee)]

Wählbar: Push-Betrieb mit änderbarem Intervall, Pull-Betrieb, 
Sekunden-Takt.
Ausgabeformat konfigurierbar wie bei strftime().
Baudrate könnte änderbar sein.
Statusinformation über erfolgreich durchgeführte Plausibilitätsprüfungen 
bzw. Fallback auf RTC usw.

[Osche R. (Gast)]

Aber dann inclusive Analog-Frontend und PLL für einen 32768 Hz - 
Uhrenquarz.
77,5/32,768 ... aua ...

[Abdul K. (ehydra)]

Konrad, soviel Speicher ist da nicht drin. Bzw. lohnt die 
Codeentwicklungs-Zeit für die breite Masse nicht. Aber ich werde jeden 
gebrachten Punkt auf die Goldwaage legen.
Push und Pull? Eigentlich sollte er nur senden! Wenns irgendwie geht, 
werde ich noch einen aufrufbaren Standby-Zustand einbauen.

[Silvan K. (silvan)]

Abdul K. schrieb:
> Push und Pull? Eigentlich sollte er nur senden!

Ich wollte eigentlich TWI vorschlagen :-(

[Steffen (Gast)]

sowas in der Art gibt es doch schon. CME8000 von C-MAX.

[Abdul K. (ehydra)]

Du meinst i2c-Slave. Das wäre möglich. Ich befürchte nur, daß die 
meisten Leute es nicht nutzen wollen. Der nächste will dann lieber SPI, 
usw.

[Peter (Gast)]

Abdul K. schrieb:
> lohnt die
> Codeentwicklungs-Zeit für die breite Masse nicht.

Ich stelle mir gerade sowieso die Frage nach der Sinnhaftigkeit eines 
solchen Projektes. Das DCF-Protokoll ist doch so simpel, das man es 
nebenbei mit erledigt. Wenn da Bedarf für einen Extrachip bestünde, wäre 
der längst auf dem Markt. Da besteht einfach kein Bedarf.

[Lars (Gast)]

Peter schrieb:
> Da besteht einfach kein Bedarf.

Das haben auch schon andere gesagt :-)

[BM (Gast)]

Der zwar interessant ist, ich aber nie zum Laufen bewegen konnte.
Scheint ziemlich sensibel zu sein, das Teil.

[BM (Gast)]

BM schrieb:
> Der zwar interessant ist, ich aber nie zum Laufen bewegen konnte.
> Scheint ziemlich sensibel zu sein, das Teil.

 ... Ähh, ich meinte den CME8000 von C-MAX

[Abdul K. (ehydra)]

Tja das mit dem Bedarf und Features. Ich werds einfach mal fertigstellen 
und dann schauen, ob es jemanden interessiert.

[Osche R. (Gast)]

Nicht das ich sowas brauchen würde, aber

a) (Funk-)uhrzeit ist etwas, dass sich relativ langsam ändert. Daher 
reicht ein langsamer Bus, z.B. UART + I2C-Slave

b) ein Notlauf bei Ausfall des Funksignals macht sicherlich Sinn. 
Entweder mit externem MHz-Takt, oder auf internem Oszillator plus 
optionalem 32kHz-Quarz

c) wenn noch ein Pin frei ist: Status-LED. Blinkt wenn gültiger Puls, 
leuchtet wenn 3 komplette Telegramme decodiert sind. Oder invertiert zum 
Energiesparen, d.h. leuchtet bei Fehler und geht aus bei lock.

[Abdul K. (ehydra)]

UART: ja
i2c: eher nein, vielleicht bei strenger Nachfrage
Notlauf: ja
gelockt-Anzeige: ja
Sleep: ja
kräftiger Ausgangstreiber: ja
Pulse-Ausgabe: vermutlich ja
Status-LED: eher nein

Momentan habe ich allerdings gar keinen DCF-Empfang. Warum auch immer.