Hallo zusammen, ich versuche gerade für meine chinesische Fahrradrücklampe eine bessere Firmware zu schreiben und hab soweit alle Pins identifiziert. Für einige Funktionen gibt es einen 433Mhz Sender am Lenkrad, welcher die Befehle zur Lampe schickt. Empfangen wird das Signal von einem "SYN480R" IC, welcher über den Datenausgang die Signale liefert. Jedoch gibt es nun das Problem, das wildes Rauschen die Auswertung ziemlich erschwert (siehe Bild Rauschen). Wenn ich nun eine Taste drücke, kommt etwas vernünftiges durch. Meine Frage ist nun: Hat jemand eine Idee wie man das Signal mit dem Mikrocontroller gut erfassen kann? Wenn ich nun einen Interrupt auf fallende oder steigende Flanke mache, dann erzeugt das Rauschen doch ständige Interrupts und legt meinen Controller quasi lahm. Wie macht man das normalerweise? Danke und viele Grüße, Paul
Ist dank AGC ganz normal, da muss man eben auf einer oder mehrere Flanken mit sinnvollem Abstand warten
Paul W. schrieb: > Wie macht man das normalerweise? Man nimmt einen Timers und pollt den Signaleingang. Damit hat man immer eine konstante und vor allem deterministische Interruptlast. Ich könnte mir da was Einfaches mit einem Zähler und einem 100us Interrupt vorstellen...
Wenn du Lust hast zu basteln, könntest du das Signal mit einem retriggerbaren Monoflop (74xx123) schonmal so konditionieren, dass nur Pulsbreiten zum uC durchgelassen werden, die eine passende Mindestdauer haben. Dann kommt vom Rauschen schonmal deutlich weniger an. Lothars Vorschlag ist aber auch sehr gut (reine Softwarelösung).
:
Bearbeitet durch User
Paul W. schrieb: > Meine Frage ist nun: > Hat jemand eine Idee wie man das Signal mit dem Mikrocontroller gut > erfassen kann? Lothar M. schrieb: > Man nimmt einen Timers und pollt den Signaleingang. Ein Blick in die VirtualWire Implementierung ... und genau so wird es gemacht. ... mit 8-fach oversampling ..... Joe F. schrieb: > Dann kommt vom Rauschen schonmal deutlich weniger an. Wenn ein Sendesignal anliegt "gibt es kein Rauschen". Es gibt nur statistische Fehler von empfangenen Einsen und Nullen bedingt durch mehr oder weniger Rauschen. Das kann die VirtualWire Lib ab.
Lothar M. schrieb: > Man nimmt einen Timers und pollt den Signaleingang. Damit hat man immer > eine konstante und vor allem deterministische Interruptlast. Frickelfritze schrieb: > ... und genau > so wird es gemacht. > ... mit 8-fach oversampling ..... Okay, das klingt gut. Im Signal sind 10 Bit in 5ms. Demnach 1 Bit in 500us und nun 8-fach oversampled bedeutet einen Timerinterrupt alle 62,5us?! Reicht auch 5-fach oversampled? Dann wären wir bei Lothars 100us. Ich hoffe das wird nicht zuviele Ressourcen fressen. Ich habe ja nur 16Mhz und er soll ja noch jede Menge anderes machen. Aber die Chinesen haben es ja auch hinbekommen :-) Danke, Paul
Paul W. schrieb: > Reicht auch 5-fach oversampled? Das kannst du allein mit deinem Design bestimmen. Die VirtualWire Implementierung "erlaubt" bis zu 2KBit Netto-Datenrate, also mit 8-fach Oversampling wären das 16 KBit/s, das wären also 62.5 usec pro Interrupt. In der Zeit kann man offensichtlich noch einiges mit einem AVR anstellen .... läuft üblicherweise auf Arduinos mit 16 MHz.
Das Problem ist ja aber das ich am PCB-Design nichts ändern kann, weil ich lediglich deren Controller auswechsle. Und ein Monoflop ist da offensichtlich nicht verbaut. Demnach muss ich es rein in Software lösen. Ich werd mal versuchen ob ich das hinbekomme :) Danke, Paul
Vor Jahren befaßte ich mich auch mit Software Dekodierung solcher Datenströme. Als Anhaltspunkt nahm ich den Artikel bei Ricci-Bitti in Circuit Celler für ein Mausefallennetzwerk auf 433Mhz. http://faculty.petra.ac.id/resmana/private/circuit-cellar/Wireless%20Monitoring%20System.pdf Sein Design lief auf einem Motorola uC, welches ich als Referenzdesign auf eien PIC portierte. Das ganze funktionierte sehr robust und zuverläßig. Irgendwo hier im Forum publizierte ich die ganzen Unterlagen. Wichtig ist bei Bit Slicing einfachen Daten Komparatoren ein Sync Sequenz den eigentlichen Daten vorauszuschicken damit die Hardware sich einpendeln kann (training). Die Daten werden pulslängenkodiert im 333us Raster gesendet. Eine 1 ist 333us und eine 0 ist 667us, eine Pause ist 333us. Jedes Symbol ist also 1ms lang, also eine Baudrate von 1kBit/s . Mit Hilfe einer 100us Timer ISR werden die Daten gesampelt und gemittelt. Jedenfalls ist das alles relativ leicht zu beherrschen. Hier ist mein Original Beitrag: Beitrag "Microcontroller OOK Datenradio Beispiel und Demo Sourcen"
:
Bearbeitet durch User
Paul W. schrieb: > Ich hoffe das wird nicht zuviele Ressourcen fressen. Ich habe ja nur > 16Mhz und er soll ja noch jede Menge anderes machen. Bei 100 µs und 16 Mhz Takt hast du pro Durchlauf 160 Taktzyklen Zeit. Wenn du deine ISR nicht übermäßig lang machst und 80 Taktzyklen für den Interrupt brauchst, ist der Prozessor zu 50% ausgelastet. Frickelfritze schrieb: > Joe F. schrieb: >> Dann kommt vom Rauschen schonmal deutlich weniger an. > > Wenn ein Sendesignal anliegt "gibt es kein Rauschen". Dann braucht man es ja auch nicht unterdrücken. Aber wenn kein Signal anliegt, muss man sicherstellen, dass das Rauschen nicht als Signal fehliterpretiert wird. Darum ging es doch: Zuverlässig zu erkennen, ob überhaupt das Signal anliegt.
Rolf M. schrieb: > Dann braucht man es ja auch nicht unterdrücken. Aber wenn kein Signal > anliegt, muss man sicherstellen, dass das Rauschen nicht als Signal > fehliterpretiert wird. > Darum ging es doch: Zuverlässig zu erkennen, ob überhaupt das Signal > anliegt. Genau das macht eine (die) VirtualWire Implementierung, sie lässt nämlich genau 16 verschiedene "Symbole" zu die ein gültiges Datum darstellen, daraus werden dann Nibbles er- zeugt und zu Bytes zusammengebaut. Rauschen (Datenrauschen) hat da keine Chance da alles Sonstige als Müll verworfen wird. Ein Grund mehr das Rad nicht neu zu erfinden. Ich finde die VirtualWire Implementierung einfach genial.
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.