Moin, beschäftige mich gerade mit DCF77 (möchte mal mit Kindern von Bekannten eine Funkuhr bauen). Wie das Signal funktioniert usw. habe ich verstanden, und wie ein Bit codiert wird auch. Allerdings ist mir die Codierung von z.B. Minuten nicht sonderlich einleuchtend (finde ich). Bit=Anzahl Minuten 21=1 22=2 23=4 24=8 25=10 26=20 27=40 Welchen Sinn machen diese "krummen" Zahlen? Warum sendet man künstlich 7 bit, wo doch 6 reichen würden? 1 + 2 + 4 + 8 + 16 + 32 gäben auch mehr als 60, würde also reichen und ein Bit weniger kosten. Klar, im Nachhinein kann man das nicht mehr ändern, jetzt wo drölfzigtausend Funkuhren danach laufen. Warum hat man sich damals für genau diese Codierung entschieden und nicht für die übliche Binärzahl-Codierung? Weiß da jemand den Grund dafür? Danke
Ohne es genau zu wissen tippe ich aber auf BCD Codierung. Also für jede Dezimalstelle extra Löwenbräu Uhrtyp schrieb: > 25=10 > 26=20 > 27=40 Das sind die Zehner Löwenbräu Uhrtyp schrieb: > 21=1 > 22=2 > 23=4 > 24=8 Und das die Einser
Hm, kostet aber im Vergleich zu normaler Codierung immer noch ein Bit extra.
Früher hatte man noch keinen MC verwendet, sondern die einzelnen Digits direkt angezeigt: http://www.fuhs.de/de/fachartikel/gallery/dcf77.shtml
Löwenbräu Uhrtyp schrieb: > Warum hat man sich damals für genau diese Codierung entschieden und > nicht für die übliche Binärzahl-Codierung? Weiß da jemand den Grund > dafür? Unter > https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/zeitcode.html Findest Du die Hintergründe der verwendeten BCD-Codierung.
Löwenbräu Uhrtyp schrieb: > im Vergleich zu normaler Codierung Wer definiert "normal"? Früher™ war halt BCD "normal".
Löwenbräu Uhrtyp schrieb: > Hm, kostet aber im Vergleich zu normaler Codierung immer noch ein > Bit > extra. Das ist BCD-Code. Das lässt sich viel einfacher mit diskreter Logik auf z.B. 7Segment anzeigen. Man muss nämlich nur eine Stelle decodieren, um das auf 7Seg anzuzeigen. Ein Decoder pro Stelle. Sonst müsste man die gesamte Zahl decodieren, was deutlich aufwändiger ist. Bei vielen RTCCs ist das Format übrigens genauso. Man muss sich vor Augen halten, dass DCF77 uralt ist. Damals spielte sowas noch eine Rolle.
Nicht nur in Mikroconroller denken. BCD-Codierung macht den Funkuhrchip viel einfacher! Der Display-Dekoder muss 4 bit auf 0..9 können + ein BCD-Zähler. Fertig. Ansonsten muss ein Dekoder 6 bit auf 00..60 können - viel komplizierter! (Oder villeicht Unix Timestamp seit 1970?) Und was bringt es das eine Bit im Protokoll zu sparen? Fast nix.
Der sendet so seit 1973. Für Auswertung durch Mikroprozessoren war das knapp zu früh.
:
Bearbeitet durch User
Also ein Relikt aus älterer Zeit. Hat aber auf die Auswertung keinen Einfluss, oder? Kann ich die ganzen Bits einfach addieren, Zehner und Einer hin oder her? Also quasi Minuten: wenn bit 1 = 1 dann minuten + 1 wenn bit 2 = 1 dann minuten + 2 wenn bit 3 = 1 dann minuten + 4 wenn bit 4 = 1 dann minuten + 8 wenn bit 5 = 1 dann minuten + 10 wenn bit 6 = 1 dann minuten + 20 wenn bit 7 = 1 dann minuten + 40 ? Es werden ja wohl kaum z.B. Bit 3 und 4 gleichzeitig 1 sein, das gäbe ja keinen Sinn, wenn das nur die Einer sein sollen.
Löwenbräu Uhrtyp schrieb: > Es werden ja wohl kaum z.B. Bit 3 und 4 gleichzeitig 1 sein, das gäbe ja > keinen Sinn, wenn das nur die Einer sein sollen. Dass beide Bits 1 sind, wäre um 8:12 ganz gut, oder um 9:12 oder um 10:12... Machs so:
1 | minuten = 0 |
2 | wenn bit 1 = 1 dann minuten = minuten + 1 |
3 | wenn bit 2 = 1 dann minuten = minuten + 2 |
4 | wenn bit 3 = 1 dann minuten = minuten + 4 |
5 | wenn bit 4 = 1 dann minuten = minuten + 8 |
6 | wenn bit 5 = 1 dann minuten = minuten + 10 |
7 | wenn bit 6 = 1 dann minuten = minuten + 20 |
8 | wenn bit 7 = 1 dann minuten = minuten + 40 |
:
Bearbeitet durch Moderator
Lothar M. schrieb: >> Es werden ja wohl kaum z.B. Bit 3 und 4 gleichzeitig 1 sein, das gäbe ja >> keinen Sinn, wenn das nur die Einer sein sollen. > Dass beide Bits 1 sind, wäre um 8:12 ganz gut, oder um 9:12 oder um > 10:12... Sind um xx:12 Uhr nicht die Bits 2 und 5 jeweils 1? Es geht bei BCD doch darum, jede Ziffer von 0-9 darzustellen und eben solche Überläufe zu vermeiden?
Inwiefern unterscheidet sich das von dem, was ich vorgeschlagen habe? minuten=0 habe ich im Kopf vorausgesetzt. Aber ich glaube, wir wollen auf dasselbe hinaus, nämlich darauf, dass ich im Endeffekt alle Bits zusammenzählen kann und fertig. So wie bei gewohnter Binärdecodierung eben auch.
Löwenbräu Uhrtyp schrieb: > Kann ich die ganzen Bits einfach addieren Du meinst das richtige, sagst aber das falsche. Man kann die Bits nicht einfach addieren, man kann aber die dezimalen Werte für die sie stehen addieren. Genau das hat Lothar gemacht.
Felix P. schrieb: > Es geht bei BCD doch > darum, jede Ziffer von 0-9 darzustellen und eben solche Überläufe zu > vermeiden? Was heisst vermeiden - in BCD können 4 Bit (1/2 (Byte) eben nur die Kombinationen 0..9 annehmen. 10..15 kommt nicht vor, Punkt. Wo ist Problem? Georg
Löwenbräu Uhrtyp schrieb: > Kann ich die ganzen Bits einfach addieren, Zehner und Einer hin oder > her? Könnte man, ist m.M.n. aber unschön. Schöner wäre (raw ist die dcf zahl) einer= raw & 15 zehner=( (raw >> 4) & 7) (das &7 kann je nachdem wie Deine Zahl weitergeht weggelassen werden) minuten= zehner×10+einer
Georg schrieb: > Felix P. schrieb: >> Es geht bei BCD doch >> darum, jede Ziffer von 0-9 darzustellen und eben solche Überläufe zu >> vermeiden? > > Was heisst vermeiden - in BCD können 4 Bit (1/2 (Byte) eben nur die > Kombinationen 0..9 annehmen. 10..15 kommt nicht vor, Punkt. Wo ist > Problem? Das habe ich doch nie bestritten. Es ging mir doch darum, dass bei DCF77 die 12 durch die Kombination 2+10 (Bit 2 und 5) dargestellt wird und nicht durch 4+8 (Bit 3 und 4).
Der Andere schrieb: > Löwenbräu Uhrtyp schrieb: >> Kann ich die ganzen Bits einfach addieren > > Du meinst das richtige, sagst aber das falsche. > Man kann die Bits nicht einfach addieren, man kann aber die dezimalen > Werte für die sie stehen addieren. > Genau das hat Lothar gemacht. Hm, ich seh den Unterschied zwischen wenn bit 1 = 1 dann minuten + 1 wenn bit 2 = 1 dann minuten + 2 wenn bit 3 = 1 dann minuten + 4 wenn bit 4 = 1 dann minuten + 8 wenn bit 5 = 1 dann minuten + 10 wenn bit 6 = 1 dann minuten + 20 wenn bit 7 = 1 dann minuten + 40 und minuten = 0 wenn bit 1 = 1 dann minuten = minuten + 1 wenn bit 2 = 1 dann minuten = minuten + 2 wenn bit 3 = 1 dann minuten = minuten + 4 wenn bit 4 = 1 dann minuten = minuten + 8 wenn bit 5 = 1 dann minuten = minuten + 10 wenn bit 6 = 1 dann minuten = minuten + 20 wenn bit 7 = 1 dann minuten = minuten + 40 noch nicht so ganz (außer dass die Minuten vor der Berechnung wieder zurückgesetzt werden, was ich implizit vorausgesetzt habe) Aber gut, deswegen brauche ich jetzt auch keinen Streit vom Zaun brechen und Korinthenkackerei betreiben. Wenns funktioniert, dann soll mir beides recht sein.
DCF77 ohne Mikroprozessor: http://www.df1ud.de/Deutsch/dcf_77.html Aber wer es ernst meint, der macht es mit Einzeltransistoren: https://sophisticatedcircuits.wordpress.com/2014/06/05/projekt-dcf77-empfanger/
Löwenbräu Uhrtyp schrieb: > wenn bit 1 = 1 dann minuten + 1 > wenn bit 2 = 1 dann minuten + 2 > wenn bit 3 = 1 dann minuten + 4 > wenn bit 4 = 1 dann minuten + 8 > wenn bit 5 = 1 dann minuten + 10 > wenn bit 6 = 1 dann minuten + 20 > wenn bit 7 = 1 dann minuten + 40 > > und > minuten = 0 > wenn bit 1 = 1 dann minuten = minuten + 1 > wenn bit 2 = 1 dann minuten = minuten + 2 > wenn bit 3 = 1 dann minuten = minuten + 4 > wenn bit 4 = 1 dann minuten = minuten + 8 > wenn bit 5 = 1 dann minuten = minuten + 10 > wenn bit 6 = 1 dann minuten = minuten + 20 > wenn bit 7 = 1 dann minuten = minuten + 40 > > noch nicht so ganz Deine "Programmiersprache" impliziert offenbar die Zuweisung an die "minuten". Das kommt überraschend und ist in keiner anderen mir bekannten Programmiersprache so umgesetzt. Ich würde die Bits für die Zehner und die Einer übrigens einfach jeweils in ein Byte schieben und dann so rechnen: minuten = zehner*10 + einer;
Löwenbräu Uhrtyp schrieb: > Hm, kostet aber im Vergleich zu normaler Codierung immer noch ein Bit > extra. Es sind genug Bits da, nämlich 59 Stück! Man bedenke, dass das erste Bit nach einer Lücke den Beginn der neuen Minute kennzeichnet und die ausgesendete Zeit immer Minute+1 ist. Peter D. schrieb: > Früher hatte man noch keinen MC verwendet, sondern die einzelnen Digits > direkt angezeigt: In meinem ersten TTL-Grab wurden die Bits durch ein Register geschoben und per Zwischenspeicher (D-Latch?) auf den 7-Segment-Decoder gepackt. Das ist dank BCD simple Verdrahtung, es muß nichts gerechnet werden. Wenn ich micht recht entsinne, habe ich auch in der Mikroprozessoruhr mit 6502 Bitschieberei betrieben. Der 6502 kann sogar dezimal rechnen (Assemblerbefehl SED) - dann wird 10 + 5 = 15 und nicht $0F.
Löwenbräu Uhrtyp schrieb: > Welchen Sinn machen diese "krummen" Zahlen? Weniger Rechenaufwand im Empfänger. Löwenbräu Uhrtyp schrieb: > Also ein Relikt aus älterer Zeit. Nö. Sinnvoll und praxisnah gewählt. Auch heute würde ich dieses Format wählen, da es einfach naheliegend ist. Und es besteht / bestand ja kein Bedarf Bits zu sparen. Gruß Jobst
Es waren sogar noch 14 Bits übrig, die seit 2006 verschlüsselte Wetterinformation enthalten.
:
Bearbeitet durch User
Manfred schrieb: > Es sind genug Bits da, nämlich 59 Stück! Man bedenke, dass das erste Bit > nach einer Lücke den Beginn der neuen Minute kennzeichnet und die > ausgesendete Zeit immer Minute+1 ist. Sach das nicht. Hätte man damals effizienter codiert, dann hätte man später mehr Bits zum Vertickern gehabt -- für Dienste wie Meteodata etc.
soul e. schrieb: > Sach das nicht. Hätte man damals effizienter codiert, dann hätte man > später mehr Bits zum Vertickern gehabt -- für Dienste wie Meteodata etc. So müssen die eben effizienter codieren. Ist mir so auch lieber, denn der Krempel ist sowieso closed. Gruß Jobst
A. K. schrieb: > Aber wer es ernst meint, der macht es mit Einzeltransistoren: > https://sophisticatedcircuits.wordpress.com/2014/06/05/projekt-dcf77-empfanger/ Ne, wenn schon, dann mit einzelnen Röhren. Die Zeit muss sein! http://www.jogis-roehrenbude.de/Leserbriefe/Bruegmann-Digital-Roehren-Clock/Digital-Roehrenuhr.htm
Lothar M. schrieb: >> wenn bit 5 = 1 dann minuten = minuten + 10 >> wenn bit 6 = 1 dann minuten = minuten + 20 >> wenn bit 7 = 1 dann minuten = minuten + 40 >> > Deine "Programmiersprache" impliziert offenbar die Zuweisung an die > "minuten". Das kommt überraschend und ist in keiner anderen mir > bekannten Programmiersprache so umgesetzt. und welche "Programmiersprache" verwendet "wenn" und "dann"?
IF bit1 = 1 THEN minuten = minuten + 10 ... war zumindest beim C64 eine gültige und sinnvolle Befehlszeile. Es gab auch Versuche, Basic einzudeutschen. Dort gab es 'wenn', 'dann' und 'sonst'. Gruß Jobst
Der Sender ist seit ca. 1959 in Betrieb. Es wäre ja toll gewesen, wenn man ein so kompliziertes Protokoll verwendet hätte, welches (damals, mit den damaligen Mitteln) keiner entschlüsseln konnte. Natürlich lassen es die heutigen Möglichkeiten zu, noch alles Mögliche in das Protokoll hineinzupacken, aber da gibt es die Stichwort: "Kompatibilität ". Darüber hinaus wird das Signal auch zu Synchronisationszwecken verwendet. Wird zu viel an den Signalflanken herumgefummelt, so ist das u. U. nicht mehr möglich.
Amateur schrieb: > Der Sender ist seit ca. 1959 in Betrieb. Aber erst seit 1973 mit Datenübertragung.
Walter S. schrieb: > Lothar M. schrieb: >>> wenn bit 5 = 1 dann minuten = minuten + 10 >>> wenn bit 6 = 1 dann minuten = minuten + 20 >>> wenn bit 7 = 1 dann minuten = minuten + 40 >>> >> Deine "Programmiersprache" impliziert offenbar die Zuweisung an die >> "minuten". Das kommt überraschend und ist in keiner anderen mir >> bekannten Programmiersprache so umgesetzt. > > und welche "Programmiersprache" verwendet "wenn" und "dann"? Dieselbe welche 1 an 5, 6 und 7 zuweist.
Nächstes Mal schreibe ich Pseudocode dazu seufz if x=y then y=z ist auch heute noch in Bascom zulässig.
Amateur schrieb: > Es wäre ja toll gewesen, wenn man ein so kompliziertes Protokoll > verwendet hätte, welches (damals, mit den damaligen Mitteln) keiner > entschlüsseln konnte. Heutzutage würde man das dann vermutlich geistiges Eigentum nennen und die Zeit bzw. den Zugang dazu teuer verkaufen. Und jeder der eine Uhr anbietet wird verklagt (oder muss Lizenzen zahlen). Außerdem müsstest Du an eine ... ähm .. GEZ einen monatlichen Beitrag zahlen, weil Du ja erfahren könntest, wie spät es ist. "Sie haben doch gerade auf den Sonnenstand geschaut!?" - "Nein, ich habe nur etwas die Sonne genossen!" - "Kommen Sie mal mit, mit Euch Schwarzzeitlern haben wir schon Erfahrung ..." **hust* :-) Gruß Jobst
das war nicht an dich gerichtet, sondern an Lothar, der meiner Meinung nach etwas zu pingelig war. deinen Pseudocode habe ich schon als solchen verstanden
:
Bearbeitet durch User
Jobst M. schrieb: > Amateur schrieb: >> Es wäre ja toll gewesen, wenn man ein so kompliziertes Protokoll >> verwendet hätte, welches (damals, mit den damaligen Mitteln) keiner >> entschlüsseln konnte. > > Heutzutage würde man das dann vermutlich geistiges Eigentum nennen und > die Zeit bzw. den Zugang dazu teuer verkaufen. Und jeder der eine Uhr > anbietet wird verklagt (oder muss Lizenzen zahlen). Außerdem müsstest Du > an eine ... ähm .. GEZ einen monatlichen Beitrag zahlen, weil Du ja > erfahren könntest, wie spät es ist. "Sie haben doch gerade auf den > Sonnenstand geschaut!?" - "Nein, ich habe nur etwas die Sonne genossen!" > - "Kommen Sie mal mit, mit Euch Schwarzzeitlern haben wir schon > Erfahrung ..." > > **hust* :-) > > Gruß > > Jobst Etwas offtopic, aber interessant und erheiternd, weitermachen! :) Walter S. schrieb: > das war nicht an dich gerichtet, sondern an Lothar, der meiner > Meinung > nach etwas zu pingelig war. > deinen Pseudocode habe ich schon als solchen verstanden Ich denke, das ist eine Frage der Perspektive. Wenn es nach mir ginge, würde unser Bad auch nicht neu geweißelt werden. Aber meine Frau findet, dass die Ecken total schwarz sind. So ähnlich wird wohl der Unterschied zwischen einem Informatiker/Elektroniker und einem Hobbybastler sein.
Das wärs doch: Demnächst kommt DCF-2 und alle müssen sich einen neuen Wecker kaufen.
M.N. schrieb: > Das wärs doch: Demnächst kommt DCF-2 und alle müssen sich einen neuen > Wecker kaufen. Verdammt! Wieso bin ich nicht darauf gekommen! Und der Mehrwert von DCF-2? Man muss sich jetzt 8 Sekunden Werbung ansehen, bevor man die Zeit lesen kann ... :-/ Löwenbräu Uhrtyp schrieb: > Etwas offtopic, aber interessant und erheiternd, weitermachen! :) Nee, ich muss weg! Gruß Jobst
Einen noch: DCF-2 Geräte müssen HDCP unterstützen. huiiii ... Gruß Jobst
AUFWACHEN! NACH DCF77 KOMMT DCF100, UND NICHT DCF-2. WEGEN MISSACHTUNG DER ZEITGEMÄSSEN OCTALNOTATION (UNSIGNED, WOHLGEMERKT) WERDEN SIE VON AMTES WEGEN INS EWIGWÄHRENDE A.SCHWARTZZEITLERFORUM ZWANGREGISTRIERT.
Hi Schade - dachte gerade nach, ob das DCF77-Protokoll vll. 63 Bit beinhaltet, was 77 Octal wäre - hat's aber nicht. DCF100 - schön konstruierte Folgeversion ;) MfG
Patrick J. schrieb: > Hi > > Schade - dachte gerade nach, ob das DCF77-Protokoll vll. 63 Bit > beinhaltet, was 77 Octal wäre - hat's aber nicht. > DCF100 - schön konstruierte Folgeversion ;) > > MfG Ihr wisst aber schon, dass die 77 für die Sendefrequenz steht? Naja, man kann sicher einen neuen Sender mit neuer Bezeichnung aufstellen ;)
Jobst M. schrieb: > Und jeder der eine Uhr > anbietet wird verklagt (oder muss Lizenzen zahlen). Außerdem müsstest Du > an eine ... ähm .. GEZ einen monatlichen Beitrag zahlen, weil Du ja > erfahren könntest, wie spät es ist. Naja, es war ja fast so. Zumindest bis in die 80ern war der Empfang des DCF-Signals gebührenpflichtig - ich meine sogar, mit 15 DM / Monat! Tja, ist verjährt, aber damals war ich Schwarzzeitler mit meiner Eigenbauuhr. Und die profitierte davon, dass es die BCD-Codierung gab: Ein langes Schieberegister (aus CD 4015) nahm die Bits auf und zur '0' wurde es in die BCD-zu-7-Segementdekoder (CD 4543) übernommen.
Und heute wäre so ein Sender privatisiert, die Zeit dann nicht unbedingt immer genau, dafür aber verschlüsselt, so daß man teure Hardware kaufen oder lizensieren müsste um sie zu entschlüsseln. Und keiner würde meckern, weil in den freien Bits irgendwelche Unfug-News zu Fussball übertragen würde.
Der Andere schrieb: > Und heute wäre so ein Sender privatisiert, die Zeit dann nicht unbedingt > immer genau, dafür aber verschlüsselt, so daß man teure Hardware kaufen > oder lizensieren müsste um sie zu entschlüsseln. > Und keiner würde meckern, weil in den freien Bits irgendwelche > Unfug-News zu Fussball übertragen würde. Und es gäbe mehr als genügend Kunden, die bereit wären dafür zu bezahlen ;)
Da wird ja noch mehr übertragen: https://de.wikipedia.org/wiki/DCF77: Zusätzlich zur amplitudenmodulierten Zeitübertragung wird seit Juni 1983 diese Information über eine Phasenmodulation des Trägers mit einer Pseudozufallsfolge (PZF) in einer Länge von 512 Bit übertragen. Mittels Kreuzkorrelation kann mit dem auf Empfangsseite reproduzierten Signal der exakte Beginn der Sekundenmarken wesentlich besser ermittelt werden. Die PTB Braunschweig gibt die immer noch hinzunehmenden Ungenauigkeiten mit 6,5–25 μs an, abhängig von Tages- und Jahreszeit. Wann wird der Sender eigentlich abgeschaltet? Die Telekom wollte das iirc schon mehrmals weil der Betrieb sehr teuer ist und als Zeitzeichensender heute überflüssig.
HildeK schrieb: > Und die profitierte davon, dass es die BCD-Codierung gab: Ein langes > Schieberegister (aus CD 4015) nahm die Bits auf und zur '0' wurde es in > die BCD-zu-7-Segementdekoder (CD 4543) übernommen. Bei mir wurden die Nibbles in einen D195 (7495) geschoben und dann in einem tschechischen 16*4Bit TTL-RAM (MH7498) zwischengespeichert. Mit dem Minutenimpuls wurde dann die eine RAM-Seite auf die Multiplexanzeige geschaltet und in die andere RAM-Seite das nächste Telegramm eingelesen. Vielen andere Selbsbauuhren hatte dagegen keinen Zwischenspeicher, d.h. haben die Bits direkt so angezeigt, wie sie reinkamen (sie gingen daher vor). Die Ablauflogik und Bitzählerei machten einige DL174 (74LS74), die Impulserkennung und die Multiplexfrequenz ein DL014 (74LS14). Empfänger war ein 4-Kreiser mit 2kHz ZF ohne Quarz.
Peter D. schrieb: > HildeK schrieb: >> Und die profitierte davon, dass es die BCD-Codierung gab: Ein langes >> Schieberegister (aus CD 4015) nahm die Bits auf und zur '0' wurde es in >> die BCD-zu-7-Segementdekoder (CD 4543) übernommen. > > Bei mir wurden die Nibbles in einen D195 (7495) geschoben und dann in > einem tschechischen 16*4Bit TTL-RAM (MH7498) zwischengespeichert. Mit > dem Minutenimpuls wurde dann die eine RAM-Seite auf die Multiplexanzeige > geschaltet und in die andere RAM-Seite das nächste Telegramm eingelesen. > Die Ablauflogik und Bitzählerei machten einige DL174 (74LS74), die > Impulserkennung und die Multiplexfrequenz ein DL014 (74LS14). > Empfänger war ein 4-Kreiser mit 2kHz ZF ohne Quarz. Autsch. Wann war das denn? Also ich hätte da ja einen U882 drauf geworfen statt ein derartiges TTL-Grab^H^H^H^H Mausoleum zu errichten.
Uhrmacher schrieb: > Wann wird der Sender eigentlich abgeschaltet? Laut http://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/verfuegbarkeit-und-empfangsberechtigung.html läuft der Vertrag bis Ende 2021. Aber der wurde schon mehrmals verlängert/erneuert.
Uhrmacher schrieb: > und als > Zeitzeichensender heute überflüssig. Das ist keineswegs so, wenn man mal über den PC-Tellerrand schaut: es gibt noch unzählige, vermutlich Millionen, Funkuhren als Wanduhren und Armbanduhren. Georg
Axel S. schrieb: > Autsch. Wann war das denn? Also ich hätte da ja einen U882 drauf > geworfen statt ein derartiges TTL-Grab^H^H^H^H Mausoleum zu errichten. 1980? Womit programmiert? Mit dem ZX81? Außerdem: in der damaligen 'BRD' gab's keinen U882 :-). Zu der Zeit kam mir erstmals ein 4-Bit Prozessor in die Finger (National?). Programmiert durch manuelles Übersetzten der Assemblerbefehle in HEX. Nein, da war das 'Grab' das kleinere und vermutlich sogar das billigere Übel.
>> DCF100 - schön konstruierte Folgeversion ;) >> >> MfG > > Ihr wisst aber schon, dass die 77 für die Sendefrequenz steht? Naja, man > kann sicher einen neuen Sender mit neuer Bezeichnung aufstellen ;) Nicht nötig: DCF100 bekommt also eine um 1/77tel höhere Sendefrequenz, sämtliche RF relevante Teile der Sendeanlage(n?) werden schlicht um 1/77tel gekürzt. Wo dann distanzmässig ein paar meter fehlen wird mit VTLE überbrückt. (auch hier: VTLE = VioletToothLowEnergy ist der leicht kurzwelligere Nachfolger von BTLE) Die Rx werden ohnehin aufgrund des neuen, selbstverständlich inkompatiblen, Protokolls auf Kosten der Nutzer ersetzt.
Hier ist ein schöner Artikel über die Funkuhrentwicklung eines Bastlers in der Anfangszeit: http://www.reinhardweiss.de/german/dcf77-history.htm Es gab zu diesem Zeitpunkt zwar bereits die ersten Mikroprozessoren, aber die waren für den Bastler kaum verfügbar, und wenn doch, dann zu teuer. Die Schaltung ist schon recht aufwendig. Wäre die Übertragung von Uhrzeit und Datum aber nicht im BCD-, sondern im reinen Binärformat (bspw. als 32-Bit-Unix-Zeit) erfolgt, hätte dies sicher noch eine (oder eher zwei) Handvoll zusätzlicher TTL-ICs erfordert. Übrigens verwenden auch die meisten (oder sogar alle?) aktuellen RTC-ICs das BCD-Format. Deswegen kann man nicht unbedingt sagen, dass das DCF77- Datenformat altmodisch sei.
Georg schrieb: > Uhrmacher schrieb: >> und als >> Zeitzeichensender heute überflüssig. > > Das ist keineswegs so, wenn man mal über den PC-Tellerrand schaut: es > gibt noch unzählige, vermutlich Millionen, Funkuhren als Wanduhren und > Armbanduhren. > > Georg Soviele, wie es DVB-T Empfänger gibt??? Das schalten die Ar$1öcher auch einfach ab! StromTuner
HildeK schrieb: > Axel S. schrieb: >> Autsch. Wann war das denn? Also ich hätte da ja einen U882 drauf >> geworfen statt ein derartiges TTL-Grab^H^H^H^H Mausoleum zu errichten. > > 1980? Da du nicht PeDa bist ... warum antwortest du? Und wieso endet deine "Antwort" mit einem Fragezeichen? > Womit programmiert? Mit dem ZX81? Natürlich mit einem MC80. Oder PC1715. Oder KC85/x. Was halt da war. > Außerdem: in der damaligen 'BRD' gab's keinen U882 :-) Mein Beileid! > Zu der Zeit kam mir erstmals ein 4-Bit Prozessor in die Finger > da war das 'Grab' das kleinere und vermutlich sogar das billigere > Übel. 1980 gab es noch keine DL074, eben deswegen stimmt deine Rechnung auch nicht. Den U882 gab es in der Tätärä nur wenig später als LS-Logik. Deswegen auch meine Frage.
Axel R. schrieb: > Soviele, wie es DVB-T Empfänger gibt??? Viel mehr. Mal abgesehen von Uhren, sind da auch Ampelsteuerungen, Wetterstationen, ... Und nicht jeder DVB-T Empfänger wird auch genutzt. Ich habe zwei, nutze aber DVB-S(2). Zudem sitze ich auch noch im Funkloch eines schlecht versorgten Bereichs (keine privaten Anbieter).
:
Bearbeitet durch User
Dirk B. schrieb: > keine privaten Anbieter Sei froh! Verpasst eh nix, außer "Bauer sucht Sau", "Sauentausch", "Mütter von Teenie-Müttern", "Germanys next Top-Moppel"...
Axel S. schrieb: > Also ich hätte da ja einen U882 drauf > geworfen statt ein derartiges TTL-Grab^H^H^H^H Mausoleum zu errichten. Naja, 10 ICs im DIP14/16 sind nicht gerade ein Grab. Und der dicke U882 mit 2716 hätte auch nicht weniger Platz belegt. Durch das Multiplexen und den TTL-RAM konnte man deutlich Bauteile sparen. Ich hab nur die Uhrzeit dekodiert. Insgesamt waren es 3 Platinchen (Empfänger, Dekoder, Anzeige). Das ganze U880-Gedöns gabs erst deutlich später in den Bastlerläden und Beziehungen zum Organisieren hatte ich keine. War außerdem noch alles NMOS, d.h. hätte ein stärkeres Netzteil gebraucht, als die 10 (LS)-TTLs.
Axel S. schrieb: >> 1980? > > Da du nicht PeDa bist ... warum antwortest du? Ich wurde mit zitiert. Du meintest doch uns beide mit 'TTL-Grab'? > Und wieso endet deine "Antwort" mit einem Fragezeichen? "1980?" Damit meinte ich in Kurzform: Du hättest auch schon 1980 einen Prozessor eingesetzt? Irgendwie waren damals die Prozessoren noch ziemlich rar... 1980 hatte ich meine Uhr gebaut und der erste Prozessor kam mir erst danach in die Finger. Axel S. schrieb: > 1980 gab es noch keine DL074, eben deswegen stimmt deine Rechnung auch > nicht. Das versteht jetzt ich nicht. DL074 war wohl die DDR-Variante vom LS74. Aber warum stimmt welche Rechnung nicht? Ich hatte CMOS-Bausteine verwendet und die gabs bei 'uns' mindestens seit etwa Anfang/Mitte der '70er Jahre. 1980 waren sie jedenfalls in den Bastelläden vorhanden. Und 74LSxx war vorher.
Gabs beim 6502 nicht sogar ein BCD-Bit, um die Arithmetik umzustellen? --Thomas
Thomas Z. schrieb: > Gabs beim 6502 nicht sogar ein BCD-Bit, um die Arithmetik umzustellen? Thread lesen: Manfred schrieb: > Wenn ich micht recht entsinne, habe ich auch in der Mikroprozessoruhr > mit 6502 Bitschieberei betrieben. Der 6502 kann sogar dezimal rechnen > (Assemblerbefehl SED) - dann wird 10 + 5 = 15 und nicht $0F.
Uhrmacher schrieb: > Wann wird der Sender eigentlich abgeschaltet? Die Telekom wollte das > iirc schon mehrmals weil der Betrieb sehr teuer ist und als > Zeitzeichensender heute überflüssig. Vielleicht warten sie damit noch, bis Galileo richtig läuft. Wenn da nur das Uhrenproblem nicht wäre ...
Wolfgang schrieb: > Uhrmacher schrieb: >> Wann wird der Sender eigentlich abgeschaltet? Die Telekom wollte das >> iirc schon mehrmals weil der Betrieb sehr teuer ist und als >> Zeitzeichensender heute überflüssig. Und was empfangen die Funkuhren?
Hi, die Paritybits wurden bislang noch nicht erwähnt. (Die Parity-Bits lassen eine einfache Plausibilitätskontrolle zu.) Sogar die Schotten bei MSF60 senden nicht mehr "fast code", greifen auf den "Slow-Code" zurück. Allerdings so ziemlich alles verkehr herum. MSB=>LSB, 59. Sekunde gesendet, A- und B-Code, Synch. durch 0,5 s Austastung etc. Siehe auch hier: https://www.mikrocontroller.net/attachment/301973/MSF60_vs_DCF77.png https://www.mikrocontroller.net/attachment/301971/MSF60_Channel_Code.png Beitrag "MSF60 Dekoder AVR Teil_1" ciao gustav P.S.: Meine erste DCF77-Uhr arbeite mit Monoflops (TTL) und tastete die "Pseudotetraden" ab Minute 20 im Sekundentakt ein. Konnte man im Display (7-Segment) schön das umgedrehte C etc. sehen. Erst bei Min. 59 stimmte die Zeit- und Datumsangabe, sie ging also nicht vor. Was die Einführung des Sommerzeitbits bedeutete, kann man sich ausdenken. Ein weiteres Monoflop mit erschreckend langer Austastung!
:
Bearbeitet durch User
Dirk B. schrieb: > Der "Nachfolger" vom DCF ist GPS. Weil man den so problemlos empfangen kann? Um aus GPS eine Normalfrequenz abzuleiten, braucht man immer eine Außenantenne. Uhrmacher schrieb: > und als Zeitzeichensender heute überflüssig. Vielleicht. Es gibt genug technische Anwendungen, wo man Frequenznormale per DCF77 auf Kurs hält. Abgesehen vom Sekundentakt, ist auch die Trägerfrequenz sehr gut. http://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-442/verbreitung-der-gesetzlichen-zeit/dcf77/traegersignal.html sagt: "Die Trägerfrequenz von DCF77 beträgt 77,5 kHz. Sie wird von einer Atomuhr der PTB abgeleitet und weicht am Sendeort im Mittel über einen Tag weniger als relativ 2 ·10-12, im Mittel über 100 Tage um weniger als relativ 2 ·10-13 von dem durch die primären Atomuhren der PTB vorgegebenen Sollwert ab."
Hi, hier wird's nochmal erläutert, wieso es einfacher ist, lieber den aus Datenreduktionsgründen verwendeten BCD-Code zu nehmen, und ihn in einer kleinen Programmroutine wieder in den für andere Programmabschnitte leichter verwertbaren 8-Bit-Code zurückzuverwandeln. Beitrag "MSF60 Dekoder AVR Teil_2" ciao gustav
Eigentlich wäre ja "Sekunden seit einem definierten Zeitpunkt in der Vergangenheit" normal, denn da kannst Du einfach eine Zahl weiter zählen. Die Tageszeitinformation in DCF-77 war halt dafür gedacht, dezimal dargestellt zu werden. Da erscheint es unsinnig, Binärcode in BCD umwandeln zu müssen. Viel einfacher ist es, alles in BCD zu lassen, besonders da auch die Mikrocontroller der damaligen Zeit besondere BCD Befehle hatten. Sprich Du hast dann zum Beispiel 2 Zahlen addiert, und dann einen "Decimal Adjust" Befehl verwendet, der Dir das Ergebnis korrigiert. Oder Du hast den ALU auf "BCD" umgeschaltet, etc... Es gibt nun mal unterschiedliche Zeitformate. Je nach Anwendung ist das eine sinnvoller als das andere... und es gibt auch ein paar die garnicht sinnvoll sind, wie zum Beispiel das "Windows OLE"-Format, das die Zeit als Ortszeit seit 01.01.1900 in Tagen als Fließkommazahl speichert...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.