Hallo,
ich habe einen 433MHz Bewegungsmelder, dessen Signal ich gerne
dekodieren möchte. Wenn ich dieses mit SDR# ansehe, sieht es wie folgt
aus.
Wenn ich das Signal nun mit Audacity ansehe, dann sehe ich dieses Signal
mit 0.25MSPS
sunshineh schrieb:> Hallo,> ich habe einen 433MHz Bewegungsmelder, dessen Signal ich gerne> dekodieren möchte. Wenn ich dieses mit SDR# ansehe, sieht es wie folgt> aus.>> Wenn ich das Signal nun mit Audacity ansehe, dann sehe ich dieses Signal> mit 0.25MSPS
Wenn ich ein Signal mit Audacity ansehe, dann sieht es wie ein Signal
aus.
Ich kann Dir diesen Logik Analysator empfehlen, der hat bei mit mit der
Software von Saleae auf Anhib funktioniert:
https://www.amazon.de/AZDelivery-Logic-Analyzer-kompatibel-Version/dp/B01MUFRHQ2
Mit Audio-Schnittstellen kann man digitale Signale nur sehr bedingt
aufzeichnen, weil dafür nicht vorgesehen sind. Hier wäre es interessant,
deinen Schaltplan zu zeigen. Denn wenn das Signal passend aufbereitet
ist und man die Eigenschaften der Schaltung kennt, dann kann man damit
schon was anfangen.
Aber so ganz ohne weitere technische Details kann ich mit deinen Bildern
nichts anfangen.
Deb begriff SDR# solltest du vielleicht auch mal erklären. Ich kenne ihn
nicht. Steht das für Software Defined Radio? Wenn ja, welches Gerät und
was genau zeigen dann die Bilder?
Wenn die Punkte im mittleren Bild die Samples andeuten sollen, dann kann
ich Dir schon einmal versichern, dass die Samplerate für dieses Signal
viel zu gering war. Man braucht etwa 10 Samples pro Schwingung, um diese
halbwegs brauchbar darzustellen. Wenn man zu wenig Samples hat, kann die
Software nur raten, welce Form das Signal ursprünglich hatte und dann
neigt sie dazu, einen Sinus darzustellen, denn das ist die natürliche
Grundform von Audio Signalen.
Und nun das Wichtigste nochmal: Wie lautet deine Frage?
Wenn du einen Arduino rumliegen hast, wäre das vielleicht was für dich;
https://github.com/gillham/logic_analyzer
Ich hatte damit ein wenig am nano herumgespielt und es sah halbwegs
brauchbar aus.
Hallo,
danke für eure Beiträge. Also grundsätzlich geht es mir darum einen
Bewegungsmelder der auf einer Frequenz von 433MHz sendet.
Ich habe mehrere dieser Bewegungsmelder und einen Raspberry Pi mit einem
DVB-T Stick bzw. einer 433MHz Antenne.
Nun möchte ich erkennen, dann er Bewegungsmelder per Funk ein Signal
sendet bzw. welcher Bewegungsmelder es gerade ist.
Mit der Software SDR# und Audacity kann ich nun das Funksignal schon wie
im Bild dargestellt erkennen. Somit könnte ich das Signal schon
auszählen?!
So wie ich es sehe, wäre die Software "Universal Radio Hacker" hier am
sinnvollsten für meine Anwendung?!
Ich hab leider sowas noch nie gemacht und versuche nun dem Problem auf
die Schliche zu kommen. Ist es überhaupt realistisch, dass der DVB-Stick
an meinem Raspberry die ganze Zeit auf der Frequenz 433NMHz lauscht und
sofort reagiert, wenn ein Signal reinkommt?
Mir ist jetzt nicht klar, was dein DVB-T Stick mit 433MHz zu tun hat.
Ich empfange 433MHz Signale mit einem 433MHz Empfänger, der das HF
Signal in ein NF Signal decodiert. Das kann man dann mit einem
Logik-Analysator wesentlich komfortabler untersuchen.
Das Audacity Bild das du von dem Signal zeigst sieht gut aus, damit kann
man was anfangen. Aber ohne zu wissen, welches Protokoll die Sender
benutzen und wie viele Bits das Signal hat, könnte es sehr mühsam
werden.
Manche senden sogar mit variabler Länge! Irgendwie ist der gesendete
Code in der Regel auch gesichert, zum beispiel mit einer wie auch immer
berechneten Prüfsumme. Auch das müsstest du herausfinden, oder diese
einfach ignorieren und dann hinnehmen, dass dein Empfänger gelegentlich
auf Störungen/Rauschen reagiert.
@ H. C. (sunshine)
Das sieht mir nach OOK aus.
https://de.wikipedia.org/wiki/On-Off_Keying
Sollte nicht allzu schwierig sein.
Du kannst so vorgehen:
Zeichne jeweils das komplette Telegramme deiner Melder auf und dekodiere
sie per Hand nach diesem Schema:
Träger EIN lang, Träger AUS kurz -> 1
Träger EIN kurz, Träger AUS lang -> 0
Anhand der Ergebnisse (hier posten) kann man sehr oft den Inhalt des
Telegramms entschlüsseln.
Stefan U. schrieb:>> dekodiere sie per Hand>> Dafür wäre ich zu faul, wozu haben wir das Programmieren gelernt?
Bevor du ein Programm geschrieben hat, kenne ich bereits den Code :)
> Bevor du ein Programm geschrieben hat, kenne ich bereits den Code
Das ist der Vorteil von Erfahrung. Was man nicht im Kopf hat, hat man in
den Fingern oder Beinen.
Danke, zum Glück gibt's ja fertige Software, die diesen Job übernimmt!
Das hat wunderbar geklappt mit Universal Radio Hacker!! Super
empfehlenswert!
Das ist nun der Code, der gesendet wird:
111011101000111010001000100011101000100010001110111011101110111011101110
1000111011101110111010001
bzw. als HEX
ee8e888e888eeeeeee8eeee88
Ich habe nun einen 433MHz Empfänger (die günstigen, dies bei Ebay gibt)
und möchte damit an meinem Raspberry die Bewegungsmelder empfangen.
Ich dachte hier an dieses Tutorial:
https://tutorials-raspberrypi.de/raspberry-pis-ueber-433mhz-funk-kommunizieren-lassen/
Oder kennt ihr was besseres?
Mit den üblichen Linux Systemen ist der Raspberry aber nicht
Echtzeitfähig. Decodiere das Singal besser mit einem kleinen
Mikrocontroller und sende das dann seriell an den Computer.
Meinst du, es ist zuviel Arbeit für den Raspberry oder warum soll ich es
gesondert machen? Ich habe auch noch einen Arudino Nano, aber dann
müsste ich halt 2 Boards versorgen...
Harald schrieb:> Träger EIN lang, Träger AUS kurz -> 1> Träger EIN kurz, Träger AUS lang -> 0sunshineh schrieb:> Das ist nun der Code, der gesendet wird:> 111011101000111010001000100011101000100010001110111011101110111011101110> 1000111011101110111010001> bzw. als HEX> ee8e888e888eeeeeee8eeee88
Vorschlag:
1110 (0xe) -> 1
1000 (0x8) -> 0
Dein Programm auf dem Raspberry wird durch Interrupts und andere Threads
unterbrochen. Es wird signifikante Zeitabschnitte geben die das Programm
nicht mit bekommt da es dann nicht ausgeführt wird. Dadurch wird es
Teile des Signals verpassen und somit nicht zuverlässig funktionieren.
20180310-0.25MSPS.jpg
(460 KB)
20180310-0.25MSPS2.jpg
(470 KB)
20180310-Funksignal1.jpg
(240 KB)
