Show Posts
Pages: [1] 2 3 ... 233
1  International / Deutsch / Re: DCF77 – macht keinen Spaß on: Today at 10:30:38 am
@uwe: bei 1 bit pro Jahr braucht es bei optimaler Dekodierung trotzdem mehrere Jahrzehnte um die genau Zeit zu finden. Aber theoretisch ist sowas machbar ... falls man eine gute genuge Zeitbasis hat .... Falls man aber eine so gute Zeitbasis hat, daß man über ein paar Dekaden nur 1/100s abweicht, dann ist man vermutlich eh an der Quelle smiley-wink

@Jurs: das was Du erklärst reicht um kurze Transienten wegzubüglen. Dein Ansatz würde immer noch eine sehr hohe Bitrate brauchen. Mein Ansatz drückt die notwendige Bitrate. D.h. mit Deiner Methode engst Du die Empfängerbandbreite auf um die 10 Hz ein. Mein Ansatz führt zu einer effektiven Bandbreite weit unterhalb von 1 Hz. Oder anders: ich werde mit einem 10-20 dB schlechteren SNR noch ziemlich gut fertig.  Der Preis dafür ist die aufwändigere Dekodierung.

Oder nochmal anders: stellt Euch einen verrauschten 4 Bit Zähler vor. Der Zähler zählt

Code:
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111

Der Empfänger sieht aber wg. Rauschen


Code:
0010
0101
0010
1011
0110
0101
1110
0101
1001
1101
0010
1011
1101
1111
1010
1110

Was tun? Einfach beim Empfänger auch zählen und schauen bei welchem Phasenversatz die Fehlerquote am niedrigsten ist. Das nennt der Statistiker "Korrelation". In der Signalverarbeitung berechnet man stattdessen sogenannte Faltungen die eben bei der korrekten Phasenlage ein Maximum haben. Um die Performance in den Griff zu bekommen muß man gewaltig tricksen, daber das ist die Grundideee.
2  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 12:26:34 pm
Das Prinzip ist wie folgt:

Seit Herr Shannon das vorgerechnet hat, ist bekannt, daß man bei einem verrauschten Kanal weniger Daten übertragen kann als in einem unverrauschten Kanal. Das ist qualitativ klar, Shannon hat es aber quantifiziert.

Das Problem ist nur: wie komme ich mit weniger Informationen auf die Zeit?

Die Erkenntnis ist, daß das vollständige Signal lokal synthetisiert werden kann (von Schaltsekunden mal abgesehen). Ergo: ich muss es gar nicht dekodieren, ich muss nur wissen "wo" in der Zeichenfolge der Sender gerade steht. D.h. mein Dekoder versucht überhaupt nicht das Signal zu dekodieren, er kennt es schon vorher. Stattdessen versuch er die Phase zu detektieren. Oder anders ausgedrückt: statt ~40 Bits pro Sekunde kommt dieser Ansatz mit weniger als 1 Bit pro Sekunde aus. Folglich sind 10 Bitfehler pro Minute noch überhaupt kein Problem.

Wenn genug Speicher da wäre und eine ausreichend genaue lokale Uhr, dann würde auch eine Rate von 1 Bit pro Jahr reichen. Aber mit einem Arduino kannst Du das vergessen.

Theoretisches Grundprinzip: verschiebe die lokale Zeichenfolge so lange bis sie optimal zur ausgesendeten passt. Die Phasenlage erlaubt dann die Zeit zu ermitteln.

Praktische Implementation mit schlappen 2k RAM: das ganze wird implementiert als "gestackter matched Filter". Mit fällt keine bessere Beschreibung dafür ein.


Wenn Du das nicht verstehst, mach Dir nichts draus. Auf solche Ideen kommt man nicht ohne entsprechende Vorbildung. Falls solche Begriffe wie "Faltung", "FFT", "Filterkern" Dir nichts sagen, dann hast Du wenig bis gar keine Chancen sowas zu entwickeln. Dann musst Du einfach glauben, daß ich ganz genau weiss was ich tue smiley-wink Oder Du nimmst einfach meine Library und freust Dich, daß Sie gut funktioniert smiley
3  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 06:38:25 am
Danke, das ist mir doch glatt entgangen. Auf die Funktion der Uhr hat das aber keine Auswirkung. Hat hier jemand einen Vorschlag wie man das auf Englisch nennen sollte? Call Bit? Bleep?
4  International / Deutsch / Re: finde den Fehler on: August 31, 2014, 03:56:28 am
Warum nicht gleich

Code:
 digitalWrite(relay3, !(myRTC.hours >=  8 && myRTC.hours < 13 ||
                         myRTC.hours >= 15 && myRTC.hours < 20));
5  International / Deutsch / Re: DCF77 – macht keinen Spaß on: August 31, 2014, 03:49:30 am
Mir fallen zu dem DCF77 Problem ein paar Dinge ein:

1) Nachschauen ob das Signal sauber ist. Z.B. damit: http://blog.blinkenlight.net/experiments/dcf77/dcf77-scope/

2) Die Sache mit dem Störnebel wird immer gerne übertrieben. Häufig kommt aus den Modulen noch ein Signal raus. Die Wahrheit ist, daß die meissten DCF77 Libraries keine brauchbare Fehlerkorrektur haben. Meine Library: http://blog.blinkenlight.net/experiments/dcf77/dcf77-library/ hingegen hat das Ziel die Entstörung soweit zu treiben wie man es auf einem Arduino hinbekommen kann. Hier http://blog.blinkenlight.net/experiments/dcf77/the-clock/ könnt Ihr Euch Videos anschauen wie eine ältere Version (die neue Library ist besser) damit fertig wird, wenn die Antenne direkt auf einem Motor liegt. Mittlerweile lege ich zum Testen oft ein Smartphone auf die Antenne --> überhaupt kein Problem.

3) Wem die Library zu fett ist kann das auch komplett in ein extra Modul auslagern: https://blinkenlightblog.wordpress.com/experiments/dcf77/super-filter/ (Der Link steht erst am 1.9. zur Verfügung, ich schreibe noch smiley-wink

-Udo
6  International / Deutsch / Re: Wie timed man einen logger ordentlich ? on: August 28, 2014, 01:15:21 pm
4-8 ppm mit  DS1307 kann vorkommen, ist aber Zufall. Die Dinger streuen stärker. Wenn es nicht auf ein paar Cent mehr ankommt: DS3232 und Du bist garantiert auf 2 ppm genau. Wenn das nicht reicht: Funkuhr oder GPS. Ich kenne da ein aktives DCF77 Projekt smiley-wink
7  International / Deutsch / Re: Welche Unternehmen nutzen Arduino on: August 27, 2014, 10:54:30 am
Alle Anbieter im Arduino Bereich nutzen Arduinos zwecks Entwicklung. Ansonsten wird die Luft aus den bekannten Gründen schnell dünn. Der Arduino ist weder von der Hardware, noch von der Software noch vom Lizensmodell für Produkte wirklich gut einsetzbar. Vom Preis und dem unschönen Formfaktor ganz zu schweigen.

Kleinstserien, Experimente und Prototypen natürlich ausgenommen, da ist es ziemlich egal was man nimmt. Davon abgesehen fliegen in jedem Großunternehmen bestimmt ein paar Arduinos rum weil jemand sich ad hoc was gebastelt hat (z.B. Statusampeln). Ob man das als industriellen Einsatz zählen sollte wage ich aber mal sehr zu bezweifeln.
8  International / Deutsch / Re: Beste Möglichkeit um Kontakt kurzzuschließen on: August 18, 2014, 04:28:20 pm
Hinweis am Rande - weil das hier immer gerne ignoriert wird: ein Arduino hat keine Schutzschaltungen für ein Auto Boardnetz http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.23.
9  International / Deutsch / Re: 3LED's fade in/out Übergang on: August 16, 2014, 09:54:47 am
Fragen immer ins Forum. Die Antworten sind ja auch für andere Mitleser interessant.
10  International / Deutsch / Re: 3LED's fade in/out Übergang on: August 16, 2014, 08:29:27 am
Wenn Du kein Beispiel in meinem Blog gefunden hast, dann hast Du nicht richtig gesucht. Schau Dir mal das hier an:

http://blog.blinkenlight.net/experiments/removing-flicker/knight-rider-no-flicker/

Das ist im Prinzip Deine Anforderung nur eben mit 20 statt mit 3 LEDs.
11  International / Deutsch / Re: 3LED's fade in/out Übergang on: August 16, 2014, 02:12:57 am
Schau einfach in meinen Blog. Da gibt es jede Menge an Beispielen, das was Du willst findest Du in verschiedenen Varianten hier: http://blog.blinkenlight.net/experiments/basic-effects/.
12  International / Deutsch / Re: Frequenzgenerator Programmieren on: August 12, 2014, 03:41:00 pm
Bei höheren Frequenzen würde ich allerdings statt dem Leuchtturmcode eher den Weg aus den POV Beispielen empfehlen. Anders als der Leuchtturmansatz funktioniert das auch noch bei >10 kHz problemlos. D.h. die Signalform kommt direkt aus dem Flash und man muss nur noch die Frequenz variieren. Wie man die Frequenz einstellbar machen kann habe ich ja auch schon mal breitgetreten.

http://blog.blinkenlight.net/experiments/basic-effects/pov-reloaded/
http://blog.blinkenlight.net/experiments/measurements/flexible-sweep/

Die zwei Beispiele zusammenzusetzen sollte nicht sooo schwer sein.
13  International / Deutsch / Re: EVA - Prinzip erklären? on: August 12, 2014, 03:23:47 pm
Genaugenommer steckt als theoretischer Unterbau  http://de.wikipedia.org/wiki/Funktionale_Programmierung unter EVA. Die prinzipielle Idee ist die Verarbeitung (V) komplett Seiteneffektfrei zu halten und die bösen Seiteneffekte (E,A) zu separieren. Das macht vor allem die theoretische Behandlung deutlich leichter. In der Praxis wird man in C++ eher seltener funktinal gehaltene Programme sehen. Vor allem auch weil C++ Compiler das nicht wirklich gut unterstützen. Aber das Prinzip zu verstehen ist auch da eine gute Idee. Nur ob man das in einem C++ Umfeld wirklich gut lernen kann wage ich zu bezweifeln.

Wenn Du das lernen willst wäre z.B. Python eine dazu besser geeignete Mainstream Sprache. Wenn Du es richtig lernen willst sind Lisp, Erlang oder F# aber eher die Sprache der Wahl.
14  International / Deutsch / Re: Schnelle Impulse mit Analogread erfassen on: August 10, 2014, 05:13:50 am
0.3 Sekunden sind 300 Millisekunden. Das ist NICHT SCHNELL. Jedenfalls nicht für den Arduino. Du kannst in der Zeit locker 300 oder mehr analogReads auslesen.

Die Frage ist: wo ist Dein eigentliches Problem? Warum glaubst Du, daß das zu schnell ist für den Arduino ist?
15  International / Deutsch / Re: millis(), umrechnen ms in sekunde und dann auswerten on: August 09, 2014, 02:26:43 pm
Der UNO gerade eben nicht, der UNO hat einen Resonator. Mein Blinkenlighty oder ein Olimexino haben einen Quarz.
Pages: [1] 2 3 ... 233