SIGNALDuino - Analyse unbekannter Funkprotokolle

Begonnen von plin, 26 Februar 2018, 17:42:45

Vorheriges Thema - Nächstes Thema

habeIchVergessen

was ich bis jetzt gesehen habe, ist eher kein Manchester kodiertes Signal. in der Mitte eines Pulses (800ms) müsste ein high/low oder low/high Wechsel stattfinden.

3. Gleis: den kaputten Motor öffnen und die Elektronik untersuchen?

plin

#91
Zitat von: habeIchVergessen am 12 März 2018, 20:09:18
3. Gleis: den kaputten Motor öffnen und die Elektronik untersuchen?
Ja, den Gedanken hatte ich gestern auch schon. Heute tut ein Zahn weh und reduziert die Laune ...

P.S. Man sollte wohl immer einen Arduino nano in Reserve haben. Gestern fiel mir wieder ein, dass ich mir vor einem Jahr mal einen RFM12B gekauft habe. Jeelab hat damit einen Scanner gebaut inkl. Anwendung um das Spektorgramm darzustellen https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B.
Vielleicht "leihe" ich mir einen von einem Kollegen.Zehnweh bedindert die Gedanken: Der Arduino nano meines 2. S'duino steckt in einer Fassung und muss nur rausgenommen werden.

P.P.S. Ist halt wie beim Adventure Spiel: Aufgeben gilt nicht. Aber manachmal produziert eine Pause neue Ideen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

tux75at

Hallo,
Ich habe nicht jeden Beitrag genau gelesen, einmal ist es schon vorgekommen. Als erstes würde ich einen DVB-T stick als Sdr (Software defined Radio) benutzen. Damit sieht man nicht nur die Frequenz und Bandbreite, sondern auch die Kodierung.
Des weiteren sieht man auch ob das selbst gesendete auch dem entspricht was die originale FB sendet. So genau sind diese tranceiver nicht, müssen Sie aber auch nicht sein. Aber mit den Toleranzen kanns mal sein dass es nicht mehr geht. Könnte der Fall gewesen sein, dass es mal nicht ging aber später am nächsten Tag doch wieder. Das ist alles viel Rätsel raten, dauert lange und führt nicht zum richtigen Ergebnis.

So ein SDR stick kostet ca. 25 Euro und ist das Geld wert.

Gesendet von meinem E5823 mit Tapatalk


plin

Ansatz Spektralanalyse mittels RFM12B (ich hatte da noch einen rumliegen): Ich habe den RFM12B und einen Arduino nano auf einem Breadboard zusammengesteckt. Erst mal ist es schwer den richtigen Wiring Sketch, die richtige Kombination aus rf12mon.ino und rfmon.tcl zu finden (bis man realisiert, dass im nrfmon-ZIP-File in einem Unterverzeichnis auch das rf12mon.ino steckt). Die rudimentäre Dokumentation hilft da auch nicht weiter; die aktuelle Version des rfmon.tcl passt nicht mehr zu den Screenshots ...
Ergebnis: Die Spektralanalyse zeigte entweder einen orangefarbenen Block über alle Frequenzen oder gar keine Pegelanzeige.

Dann ging's hier weiter: https://github.com/dzach/nrfmon/issues/9#issuecomment-373216244

Der "Support" durch dzach hat schnell reagiert, war erst hilfreich und endete dann in "lies dir mal diesen langen Thread durch, dann wirst du verstehen" und besorg dir einen zweiten RFM12B/Arduino nano damit du mittels RF12demo verifizieren kannst, dass der sendet/empfängt.

Ich habnoch ein wenig im Code des rf12mon.ino rumgespielt. Da wo eigentlich ein langer String mit den rssi-Pegeln ausgegeben werden sollte kam gar nichts. Umschaltung auf Analog-rssi führte dann zu dem orangefarbenen Block. Dann kam ein Sendetest auf 868.000 MHz in der Hoiffnung, dass mein Signalduino irgend etwas im log ausgibt - Fehlanzeige.

Ich habe mich deshalb heute entschieden in puncto Spektralanalyse mittels RFM12B nicht weiter meiner Devise "aufgeben gilt nicht zu folgen".
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

tux75at

Zitat von: plin am 17 März 2018, 10:56:12
Ansatz Spektralanalyse mittels RFM12B (ich hatte da noch einen rumliegen): Ich habe den RFM12B und einen Arduino nano auf einem Breadboard zusammengesteckt. Erst mal ist es schwer den richtigen Wiring Sketch, die richtige Kombination aus rf12mon.ino und rfmon.tcl zu finden (bis man realisiert, dass im nrfmon-ZIP-File in einem Unterverzeichnis auch das rf12mon.ino steckt). Die rudimentäre Dokumentation hilft da auch nicht weiter; die aktuelle Version des rfmon.tcl passt nicht mehr zu den Screenshots ...
Ergebnis: Die Spektralanalyse zeigte entweder einen orangefarbenen Block über alle Frequenzen oder gar keine Pegelanzeige.

Dann ging's hier weiter: https://github.com/dzach/nrfmon/issues/9#issuecomment-373216244

Der "Support" durch dzach hat schnell reagiert, war erst hilfreich und endete dann in "lies dir mal diesen langen Thread durch, dann wirst du verstehen" und besorg dir einen zweiten RFM12B/Arduino nano damit du mittels RF12demo verifizieren kannst, dass der sendet/empfängt.

Ich habnoch ein wenig im Code des rf12mon.ino rumgespielt. Da wo eigentlich ein langer String mit den rssi-Pegeln ausgegeben werden sollte kam gar nichts. Umschaltung auf Analog-rssi führte dann zu dem orangefarbenen Block. Dann kam ein Sendetest auf 868.000 MHz in der Hoiffnung, dass mein Signalduino irgend etwas im log ausgibt - Fehlanzeige.

Ich habe mich deshalb heute entschieden in puncto Spektralanalyse mittels RFM12B nicht weiter meiner Devise "aufgeben gilt nicht zu folgen".
Die RFM Module geben nur eine digitale Auswertung des Spektrums wieder, ich kenne diese Methode nicht, jedoch kenne ich diese Module. In Punkte Auflösung und Bandbreite können die sicher nicht das ganze Spektrum wiedergeben.
Ein DVB-T stick kann sehr breitbandig ohne viele Vorkenntnisse das analoge Spektrum darstellen. (klar ist es digital, jedoch zeigt der Bildschirm nicht mehr zwischenwerte an, es gibt nicht mehr Pixel, und darum kann man schon von einer analogen Anzeige sprechen.
Ohne klarem Bild eines Spektrums kann man sich nie klar sein welche Modulation etc. Verwendet wird. OOK kann ich theoretisch auch mit FSK erreichen. FSK je nach empfangsmodul eventuell, aber nicht garantiert mit OOK. Wenn man das mit einem RFM Modul zeigen kann ist es gut. Aber ohne dieser Information ist alles nur rumprobieren.

Gesendet von meinem E5823 mit Tapatalk


plin

#95
MacGyver (Was will ich? Was steht mir zur Verfügung?) hätte so etwas produziert (siehe Grafik). Die Auswertung entstand aus Basis der rssi-Angabe am Ende der MU-Zeilen meines manuellen Frequenzband-Scans vom 11.3. sowie eines neues Scans bei sendendem S'duino.

Klar zu sehen: Der S'duino hat eine starke Oberwelle bei ca. 868.325 MHz. Das scheint die gemeinsame Verständigungsbasis zu sein. Interessanterweise mögen sie Motoren es aber nicht, wenn ich auf dieser Frequenu sende. Keine Reaktion.

Jetzt bin ich mal auf die analoge Variante mittel DVB-T-Stick gespannt.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

#96
Das neueste von Motor 7: Wer nicht mitspielt ist raus und wird auseinandergebaut.

Der Empfänger scheint ein TDA 5210 zu sein.

@Markus: Rechne ich richtg? 6,7 MHz * 128 + 10,7 = 868,3 MHz? Und das dann +/- 25 kHz?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen

Pin 5/10/13 sind GND
Pin 11 auf GND => 868MHz
Pin 15 auf GND => FSK

plin

Hallo hIV, prima, dass Ihr noch mit dabei seid. Gibt es eine einfache Lösung aus FHEM heraus FSK so flexibel zu senden wie via SIGNALduino??? Wenn sich die Frequenzen und das Protokoll herauskristallisieren, müsste ich ja irgendwann FSK statt OOK angehen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

KölnSolar

#99
Ich befürchte Du meinst mich ? Denk dran, dass ich nur interessierter Laie bin

ZitatRechne ich richtg? 6,7 MHz * 128 + 10,7 = 868,3 MHz?
Nach Datenblatt richtig. Aber wie kommst Du auf den Hub ?

Das fand ich noch interessant
ZitatThe demodulator circuit is switched off in case of reception of ASK signals
Grund warum OOK mit 868,00 empfangen wird ?

Ich versuche weiter die Demodulation zu verstehen.... :-[

Edit:
ZitatGibt es eine einfache Lösung aus FHEM heraus FSK so flexibel zu senden wie via SIGNALduino???
Nicht bekannt.
Bei einer Integration in die aculfw(CUL) evtl. mit raw send machbar. Abgucken ließe sich beim WMBUS-/MAX-mode.
Edit2: Was macht eigentlich das verstaubte Oszi ? Mal an Pin25 hängen ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

plin

Zitat von: KölnSolar am 18 März 2018, 16:35:04
Nach Datenblatt richtig. Aber wie kommst Du auf den Hub ?
Bauchgefühl (kann aber total falsch liegen). In den ersten Runde schien ja 868.275 MHz eine besondere Rolle zu spielen, jetzt die 868.325 MHz. Die Kalkulation auf Basis der Quartz-Frequenz führt zu 868.300 MHz. Außerdem sieht das was der S'duino so rudimentär als Spektrum (bei einer Bandbreite von 58 kHz) erkennt wie zwei Hügel aus. Frag mich nicht was das zu bedeuten hat, mein Studium ist schon zu lange her und ich bin danach direkt in die EDV abgedriftet.

Ich bin gerade auf den SIGNALESP gestoßen. Ist das nur eine kleine Variante des SIGNALduino?
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen

#101
SIGANLduino basiert auf einem atmega328p.
SIGNALESP ersetzt den atmega328p mit dem ESP8266.

Die miniCULs mit WLAN von locutus haben einen atmega328p und ein cc1101. Der ESP-01/8285 bedient "nur" die serielle Schnittstelle von atmega328p und stellt diese im WLAN bereit.

Pin 15 mal getestet?

plin

#102
SIGNALSP: ich habe noch ein paar Wemos D1 mini hier rumliegen, müsste mir nur einen weiteren CC1101 bestellen. Aktuell liegt mein Raspi2 im Wohnzimmer rum (musste schon die LEDs abkleben weil die vielen Lichter meine Frau stören :-)). Ein Wemos D1 wäre kleiner/eleganter.

Nee, meinen Oszi habe ich noch nicht rausgeholt, werde ich aber wohl noch angehen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

plin

Das Ding ist verdammt klein. Wie komme ich am sichersten an die Pins (meine Oszi-Klemmen waren für andere IC-Größen ausgelegt)? Kabel an Stecknadel, Stecknadel auf Pin drücken? Aber wie fixiere ich die so, dass sie auf dem Pin bleibt?

FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

habeIchVergessen