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
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.
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:
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.
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
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
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.
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.
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
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.
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
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:> 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).
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.
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.pnghttps://www.mikrocontroller.net/attachment/301971/MSF60_Channel_Code.pngBeitrag "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!
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...
