Forum: Mikrocontroller und Digitale Elektronik DCF77, warum so komisch codiert?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Der Andere (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hm, kostet aber im Vergleich zu normaler Codierung immer noch ein Bit 
extra.

von Peter D. (peda)


Bewertung
4 lesenswert
nicht lesenswert
Früher hatte man noch keinen MC verwendet, sondern die einzelnen Digits 
direkt angezeigt:

http://www.fuhs.de/de/fachartikel/gallery/dcf77.shtml

von Mati (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Der Andere (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Löwenbräu Uhrtyp schrieb:
> im Vergleich zu normaler Codierung

Wer definiert "normal"?
Früher™ war halt BCD "normal".

von soso (Gast)


Bewertung
4 lesenswert
nicht lesenswert
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.

von Tom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Der sendet so seit 1973. Für Auswertung durch Mikroprozessoren war das 
knapp zu früh.

: Bearbeitet durch User
von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
-5 lesenswert
nicht lesenswert
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
von Felix P. (fixxl)


Bewertung
2 lesenswert
nicht lesenswert
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?

von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Der Andere (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Dumdi D. (dumdidum)


Bewertung
0 lesenswert
nicht lesenswert
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

von Felix P. (fixxl)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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/

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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;

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jobst M. (jobstens-de)


Bewertung
1 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Es waren sogar noch 14 Bits übrig, die seit 2006 verschlüsselte 
Wetterinformation enthalten.

: Bearbeitet durch User
von Soul E. (souleye) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
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.

von Jobst M. (jobstens-de)


Bewertung
1 lesenswert
nicht lesenswert
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

von M.N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Walter S. (avatar)


Bewertung
0 lesenswert
nicht lesenswert
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"?

von Jobst M. (jobstens-de)


Bewertung
1 lesenswert
nicht lesenswert
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

von Amateur (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Amateur schrieb:
> Der Sender ist seit ca. 1959 in Betrieb.

Aber erst seit 1973 mit Datenübertragung.

von Programmiersprachentheaterintendant (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nächstes Mal schreibe ich Pseudocode dazu seufz

if x=y then y=z

ist auch heute noch in Bascom zulässig.

von Jobst M. (jobstens-de)


Bewertung
5 lesenswert
nicht lesenswert
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

von Walter S. (avatar)


Bewertung
0 lesenswert
nicht lesenswert
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
von Löwenbräu Uhrtyp (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von M.N. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das wärs doch: Demnächst kommt DCF-2 und alle müssen sich einen neuen 
Wecker kaufen.

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jobst M. (jobstens-de)


Bewertung
0 lesenswert
nicht lesenswert
Einen noch:

DCF-2 Geräte müssen HDCP unterstützen.

huiiii ...


Gruß

Jobst

von WECKERTECHNOLOGIEAUFSICHTSBEAMTER (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von Patrick J. (ho-bit-hun-ter)


Bewertung
-2 lesenswert
nicht lesenswert
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

von Dirk B. (dirkb2)


Bewertung
2 lesenswert
nicht lesenswert
Der "Nachfolger" vom DCF ist GPS.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
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 ;)

von HildeK (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Der Andere (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von M. K. (sylaina)


Bewertung
1 lesenswert
nicht lesenswert
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 
;)

von Uhrmacher (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg (Gast)


Bewertung
6 lesenswert
nicht lesenswert
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

von HildeK (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Glücklos Zeitiger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> 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.

von Jörg (Gast)


Bewertung
0 lesenswert
nicht lesenswert
... und ohne Smartcard wird nichts gehen.

von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel R. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Dirk B. (dirkb2)


Bewertung
0 lesenswert
nicht lesenswert
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
von M.N. (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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"...

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
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.

von HildeK (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Thomas Z. (thozei)


Bewertung
0 lesenswert
nicht lesenswert
Gabs beim 6502 nicht sogar ein BCD-Bit, um die Arithmetik umzustellen?

--Thomas

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Wolfgang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 ...

von Lutz H. (luhe)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
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
von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Christian B. (casandro) Flattr this


Bewertung
2 lesenswert
nicht lesenswert
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...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.