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.
Abdul K. schrieb: > Es sind halt nur begrenzt Pins am > Controller. Wie viele?
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.
Gast
#2612135
Aber dann inclusive Analog-Frontend und PLL für einen 32768 Hz - Uhrenquarz. 77,5/32,768 ... aua ...
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.
Abdul K. schrieb: > Push und Pull? Eigentlich sollte er nur senden! Ich wollte eigentlich TWI vorschlagen :-(
Gast
#2612171
sowas in der Art gibt es doch schon. CME8000 von C-MAX.
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.
Gast
#2612445
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.
Gast
#2612468
Peter schrieb: > Da besteht einfach kein Bedarf. Das haben auch schon andere gesagt :-)
Gast
#2612581
Der zwar interessant ist, ich aber nie zum Laufen bewegen konnte. Scheint ziemlich sensibel zu sein, das Teil.
Gast
#2612586
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
Tja das mit dem Bedarf und Features. Ich werds einfach mal fertigstellen und dann schauen, ob es jemanden interessiert.
Gast
#2613609
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.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.