Dekodierung eines unbekannten FM bzw. FSK Signals

Begonnen von Sven77, 29 November 2017, 16:50:26

Vorheriges Thema - Nächstes Thema

Sven77

Hallo in die Runde,

ich weiß gar nicht, ob ich hier richtig bin - muss aber irgendwo mal einen Anfang machen!
Ich würde gern den Temperatursensor meiner Abbrandsteuerung in meine Hausautomation einbinden. Zum einen als kleines Gimmick, zum anderen als weiteres Spielprojekt bzw. Machbarkeitsstudie und last but not least um bei brennendem Grundofen die Fussbodenheizung auszuschalten bzw. sehr weit herunter zu fahren.

Eins vorweg - dank vieler guter Tipps habe ich das Signal inzwischen entschlüsselt. Die kurze Zusammenfassung hier:

Man nehme einen RTL2838 DVB-T Stick, dazu eine SDR Software und sucht sich stückweise alles zusammen.
Entweder scannt man die üblichen Frequenzen, sucht nach einem Typenschild oder fragt (wie ich es getan habe) den Hersteller. Somit hatte ich zumindest die grobe Info "433 MHz".
Damals in einem ersten Versuch hatte ich SDR# benutzt und (irgend)ein Signal gesehen, s. Anhang "SDR_25dB Gain_Sequence.png".

Nun wollte ich in der kalten Jahreshälfte endlich mal wieder diesem Thema etwas Zeit opfern und bin ein gutes Stück weiter. In den diversen SDR-Programmen kann man die Modulation wählen und Mitschnitte als WAV speichern, um diese in Audacity zu analysieren.
Mir sagte zwar bisher weder die Raw-Ausgabe noch die in GQRX angebotene Raw-IQ-Demodulation und auch AM nichts, den Vergleich sieht man im Anhang "GQRX_RAW-RawIQ-AM.png". Mit FM hatte ich mich nicht weiter beschäftigt, da hier offenbar nur Rauschen drin war.

Ich habe dann jedoch an den o.g. Kandidaten schonmal erkannt: es werden alle 100ms ein Signal mit ca. 10ms Länge gesendet.
Mit dieser Info habe ich nochmal in die FM-Modulation hineingezoomt und stellte fest: TADA - das Rauschen war nur in der Stille, immer wenn gesendet wurde kamen hier brauchbare High/Low-Pegel zutage - s. "GQRX_NarrowFM_10x_30dB.png".
Um diese zu sehen, musste ich auch erstmal kräftig verstärken, auf den ersten Blick sah es immer aus wie 10ms Stille...  ;)
(das Bild zeigt untereinander 2 verschiedene Nachrichten zu unterschiedlichen Zeiten)

Nun gab es die nächste Hürde: wer macht mir aus der Kurve ein Bitmuster?
Die ersten 3ms waren offenbar immer das Preamble aus Nullen und Einsen. Abzählen Ablesen der Zeit zeigte mir: 9600 Baud!
Nur wie bekomme ich daraus die Bitfolge, ohne diese vielen Schritte und das Ablesen von Hand am Ende?

Schritt 1 auf diesem Weg:
Mit "rtl_fm" aus der RTL-SDR Sammlung kann man fertig FM demodulierte 16-Bit Signed Integer ausgeben lassen - die Frequenz konnte ich inzwischen auf 433.216MHz eingrenzen und als Samplingrate empfiehlt sich ein Vielfaches der Baudrate, in meinem Fall reicht das 4-fache gut aus, etwas mehr schadet nicht kostet aber mehr CPU-Leistung und sehr viel mehr (anfangs dachte ich "viel hilft viel" und ließ mit 3.2MHz abtasten) bringt nur unnötiges Rauschen und verkleinert die Amplitude (warum auch immer):
rtl_fm -f 433216000 -s 76800

Schritt 2:
Diese Ausgabe könnte man nun mit SOX in eine WAV-Datei packen und wäre genauso weit wie vorher...
Ich fand ein Projekt "pydemod", was aber schon wieder viel zu tief in die Protokolle eingriff, weshalb es mir auch nicht weiter half.
Also habe ich erstmal ein kleines C-Programm geschrieben, was die Samples einliest und immer nach 4 Samples eine 0 oder 1 ausgibt.
Damit stellte ich schnell fest: es wird hier weder weiter Kodiert, noch mit Start/Stop/Parity gearbeitet und noch nicht einmal wie sonst üblich aus einer 1 ein Low-Pegel gemacht. Ganz simpel: 4 Samples >0 bedeuten eine logische 1 und 4 Samples <0 eine logische 0.

Schritt 3:
Ein paar Beispiele aufzeichnen und mit angezeigten Werten vergleichen...
Reine Fleißarbeit - Ergebnis: es werden 32s 01-Pärchen gesendet, danach die Hex-Folge 2D.D4.46.49.52.45 und dann variable Daten.
Schnell fällt auf, dass die letzten 4 Bytes dieser Folge der ASCII-Code für "FIRE" ist - wir dekodieren also das richtige!  :D
Dahinter folgt ein Byte für die aktuelle Verbrennungsstufe, ein Word für die Temperatur in °C, ein Byte für die abgelaufenen Stunden, eins für die Minuten, ein noch unbekanntes was bisher immer 0 ist und zuletzt 16-Bit Prüfsumme.
Auch diese war dank Online-CRC-Berechnung schnell entschlüsselt: es ist der sogenannte "CRC-CCITT (XModem)" Code.

Also noch schnell eine Prüfsummenprüfung mit ins Programm und den Programmabbruch nach erfolgreichem Dekodieren - schon kann ich mir die Ausgabe von rtl_fm in mein Programm pipen und erhalte eine auswertbare Anzeige:
rtl_fm -f 433216000 -s 76800 | ./hoxdemod


SOOOO....
Und an dieser Stelle weiß ich jetzt nicht mehr weiter!

Ein DVB-T-Stick samt RTL-SDR und selbstgebasteltem Demodulator erscheint mir ein wenig übertrieben, um ein einfaches FM-Signal mitzulesen!
Billige 433MHz Receiver können aber offenbar nur AM.
Ich habe noch 2 Stück CC1101, leider für 868MHz, aber grundlegend sollten diese ja auch für 433MHz nutzbar sein.

Aber wie gehe ich vor? Auch hier scheint alles schon sehr signalspezifisch hinterlegt zu sein.
Wie kann ich mit einem nanoCUL oder SIGNALduino einfach FM-Bitfolgen auslesen, um schrittweise zu probieren, ob die CC1101 das überhaupt empfangen können?
Oder sollte ich gleich das (inzwischen ja bekannte) Protokoll irgendwo einpflegen?

Ich hätte halt gern einen Arduino o.ä., der mir direkt einfach die zyklisch empfangbaren 14 Bytes zur Verfügung stellt, ohne mich um 76.8kHz Samples in 16-Bit Tiefe zu plagen.
Irgendwelche Ideen?
VG, Sven

KölnSolar

SDR kenne ich nicht wirklich, weshalb mir Deine Analysen auch nicht viel sagen. Aber AM/FM sind ja eigentlich analoge Modulationsverfahren. Bist Du Dir sicher, dass Du da nicht auf dem falschen Dampfer unterwegs bist ?
ZitatHigh/Low-Pegel zutage
passt ja eigentlich auch nicht zu FM, sondern zu ASK oder doch FSK :-\
Wenn Du also etwas besser das Modulationsverfahren beschreibst, kann ich Dir vielleicht sagen, ob Du mit Sduino/CUL/CC1100 weitermachen kannst.

Grüße Markus

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

Sven77

#2
Zitat von: KölnSolar am 29 November 2017, 17:39:07
AM/FM sind ja eigentlich analoge Modulationsverfahren. [...]  passt ja eigentlich auch nicht zu FM, sondern zu ASK oder doch FSK :-\
Nun, genau da liegt ja eigentlich auch mein Problem:
Es gibt heutzutage mehr Bezeichnungen als ich an zwei Händen abzählen kann...

ASK wäre ja sicher das Pendent zu AM, also dann eher FSK. Aber auch hier gibt es noch GFSK und sicher noch weitere... Oder ist es doch irgendein PSK? Ich selbst weiß es wirklich nicht - daher habe ich die Signalkurven oben mit abgebildet und hoffe, dass jemand etwas gutes darin erkennen kann...

Was mir auch unklar ist: wäre denn "jedes" FSK mit jedem kompatibel?
Ich habe irgendwo gelesen, dass JeeLink und CUL inkompatibel zueinander sind - ich verstehe aber nicht so recht, warum - wo doch beide eigentlich ganz flexibel einsetzbar sind?!  :-\ :-[
VG, Sven

KölnSolar

ZitatWas mir auch unklar ist: wäre denn "jedes" FSK mit jedem kompatibel?
Wohl eher nicht. FSK ist ja nur ein Oberbegriff für Modulationsverfahren.

ZitatIch habe irgendwo gelesen, dass JeeLink und CUL inkompatibel zueinander sind - ich verstehe aber nicht so recht, warum - wo doch beide eigentlich ganz flexibel einsetzbar sind?!
Ich vermute, dass das eine zu pauschale Aussage ist. Ein Jeelink oder CUL bestehen ja aus Hard- u. Firmware u. die Inkompatibilität besteht vermutlich in der Firmware(bzgl. FSK)

Unterschiede der Hardware
CC1100(CUL, S'duino)
Zitat2-FSK, 4-FSK, GFSK, and MSK supported as well as OOK and flexible ASK shaping
RFM12B(Jeelink)
Zitatmulti-channel FSK transceiver(modifiziert auch ASK/OOK)

Ein Beispiel für FSK ist Homematic. hier kannst Du ableiten, dass das Protokoll mit beiden Chips abbildbar ist. Weitere devices/Protokolle mit FSK: PCA301, Lacrosse, MAX!, ZWAVE, SWAP... Vielleicht helfen Dir diese Stichwörter als Suchbegriffe weiter.

Zitatdaher habe ich die Signalkurven oben mit abgebildet und hoffe, dass jemand etwas gutes darin erkennen kann...
Ich bemüh mich ja..verstehe es aber nicht. Da schwingt "etwas" um einen Nullpunkt. Was zur Hölle ist der Nullpunkt u. was die Amplituden  :-\ Die Schwing-Frequenz fix 433,21 MHz ? Oder doch variabel(FSK) ?

Ich bin halt kein Profi und kenne mich eher mit dem einfachen ASK/OOK aus  :-[


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

Harst

Das sieht sehr nach FSK aus. Es sind zeitgleich Signale auf mehreren Frequenzen zu sehen. OOK, AM  oder ASK haben im unteren Fenster nur eine senkrechte Linie.

Horst

Sven77

Ich habe das Thema auch in einem anderen Thread aufgegriffen und dort eine weitere Erkenntnis gepostet:
https://forum.fhem.de/index.php/topic,35064.msg726694.html#msg726694

Das verwendete Startwort 0x2DD4 scheint beim RFM12(b) (also auch Jeelink?) Standard zu sein, ich versuche also mit diesen Infos weiter, das Signal mit culfw auszulesen.
Danke nochmal für alle Tipps an dieser Stelle!
VG, Sven

pejonp

#6

... Vielen Dank aber, dass Du mich auf Deine Änderungen aufmerksam gemacht hast - vor allem, weil die Signale ja doch irgendwie ähnlich scheinen... (FSK mit 4800 bis 19200 Baud)

Was mir noch nicht so ganz klar wird: brauche ich ein RFM69? Du hattest glaube ich irgendwo geschrieben, dass andere Funkmodule (derzeit?) nicht unterstützt werden - kann ich vielleicht irgendwo ansetzen, um das mit einem CC1101 zu empfangen?
Mich wundert auch der Zusatz "Der W137 wird auch nur auf dem 1.RFM69 empfangen, beim 4.RFM69 kommt nichts." - kannst Du das erklären?

Was mich bei meiner Untersuchung vielleicht weiterbringen würde:
Hast Du (analoge) Aufzeichnungen des Signals und ggf. Anhand derer die Bandbreite usw. bestimmt? Oder klappte es bei Dir zufällig auf Anhieb nach Einstellen der Datenrate und Frequenz?
Hast Du evtl. auch Rohdaten der Sensoren? Also was senden diese auf Bitebene und was bedeuten diese Bits?

Ich scheiterte zuletzt leider noch immer daran, dass ich nach Einstellung der Frequenz nicht mal irgendwelche Rohbits zurückbekommen, die ich dann irgendwie auswerten könnte. Einzig funktionierende Lösung ist für mich derzeit über einen DVB-T-Stick und rtl_fm mit nachgeschaltetem selbstgebackenen Demodulator...
...


Hallo Sven,

sicher kann man auch FSK mit dem CC1101 empfangen, es wird ja mit der Anpassung für das LaCross-Protokoll im CUL so gemacht. Aber ich kenne mich mit dem CC1101 und den notwenigen Anpassungen nicht aus.

Beim JeeLink mit dem RFM69 kenne ich mich etwas besser aus. Und habe schon Anpassungen vorgenommen, so das ich den W137 und die WH25A empfangen kann.
Beim JeeLink kann man den DEBUG-Modus einschalten und sich die empfangen Daten als HEX-Code anzeigen lassen.

z.B: (DEBUG-Modus, OK-Werte werden im KeyValueProtokoll ausgegeben)

[LaCrosseITPlusReader.10.1w137 (RFM69CW f:869820 r:4800)]

End receiving, HEX raw data: F7 53 1A ED FF 0 ED FF 9 4 0 8 0 3C 1 0
OK VALUES W137 247 Header=26,Temperature=-1.90,Humidity=53,Rain=79.00,WindSpeed=0.40,WindDirection=202.50,WindGust=0.80,UV=0.00,strikesDistance=-1,strikesTotal=38,

End receiving, HEX raw data: 1C 66 91 88 10 25 C0 54 12 36 1A D 9C 8C DD C9

End receiving, HEX raw data: F7 53 1A ED FF 0 ED FF 7 6 0 10 0 3C 1 0
OK VALUES W137 247 Header=26,Temperature=-1.90,Humidity=53,Rain=79.00,WindSpeed=0.60,WindDirection=157.50,WindGust=1.60,UV=0.00,strikesDistance=-1,strikesTotal=38,


z.B: (DEBUG-Modus) OK-Werte sind richtig erkannte Daten bzw. die schon einem Protokoll zugeordnet sind.

[LaCrosseITPlusReader.10.1w137 (RFM69CW f:868300 r:17241)]

End receiving, HEX raw data: 92 3 94 6A AA 59 B 19 EB 45 3C 73 4 65 BC 77
OK 9 8 1 3 226 106

End receiving, HEX raw data: D8 49 24 4C 91 44 31 9E 77 C6 6D A6 32 94 37 D5
## CRC FAIL ##
No valid start

End receiving, HEX raw data: 99 44 90 49 6D 9E 1C 66 52 A0 9F 25 EA B4 28 A0
OK 9 37 1 4 66 73

End receiving, HEX raw data: 92 3 94 6A AA 32 A9 DF B9 3A 9 B8 69 DF F9 44
OK 9 8 1 3 226 106

End receiving, HEX raw data: ED 62 4C 30 28 1B E C AA AA AA 0 B 9B DB 78
OK WS 214 5 4 164 48 255 255 255 255 255 255 255 255 0 4 2

End receiving, HEX raw data: 92 3 94 6A AA 28 B6 3F 49 44 C7 2C 9F 16 84 B5
OK 9 8 1 3 226 106

End receiving, HEX raw data: 24 4F 16 61 7F 36 0 0 2 40 0 1 0 0 0 A4
## CRC FAIL ##
No valid start

End receiving, HEX raw data: 99 44 90 49 6D 98 F A1 22 4A 45 9E CF A4 4E BF
OK 9 37 1 4 66 73

End receiving, HEX raw data: E5 2 53 31 28 55 E8 AA AA AA 0 51 29 9A 51 E9
OK WS 80 5 4 171 49 255 255 255 255 255 255 255 255 0 4 8


##Mich wundert auch der Zusatz "Der W137 wird auch nur auf dem 1.RFM69 empfangen, beim 4.RFM69 kommt nichts." - kannst Du das erklären?

Das war nur als Hinweis für das LaCrossGateway gemeint, zur Fehlersuche. Es hat bei mir nicht auf allen Receivern funktioniert. Zur Zeit habe ich beim LaCross-Gateway den 4. und 5. RFM69 bestückt und der 4. empfängt den W137 und die anderen schaltet zwischen den Baudraten hin und her (17241 / 9579).

Wenn man den Hex-String hat und einige davon aufzeichnet, kann man sich die veränderden Stellen ansehen. CRC-Prüfung ist auch schon vorhanden. Die "2D.D4" sind für den empfang wichtig.

    /* 0x2F */ WriteReg(REG_SYNCVALUE1, 0x2D);  // 0x2D
    /* 0x30 */ WriteReg(REG_SYNCVALUE2, 0xD4);  // 0xD4

Ein paar Beispiele aufzeichnen und mit angezeigten Werten vergleichen...
Reine Fleißarbeit - Ergebnis: es werden 32s 01-Pärchen gesendet, danach die Hex-Folge 2D.D4.46.49.52.45 und dann variable Daten.
Schnell fällt auf, dass die letzten 4 Bytes dieser Folge der ASCII-Code für "FIRE" ist - wir dekodieren also das richtige!  :D
Dahinter folgt ein Byte für die aktuelle Verbrennungsstufe, ein Word für die Temperatur in °C, ein Byte für die abgelaufenen Stunden, eins für die Minuten, ein noch unbekanntes was bisher immer 0 ist und zuletzt 16-Bit Prüfsumme.
Auch diese war dank Online-CRC-Berechnung schnell entschlüsselt: es ist der sogenannte "CRC-CCITT (XModem)" Code.



Wenn du einen RFM12 hast kannst du diesen auch erst einmal nehmen und im Debug-Modus sehen was kommt.
Geht nur mit Arduino Nano oder UNO mit dem LaCrosseITPlusReader10-Sketch

Bauanleitung:
https://blog.gummibaer-tech.de/jeelink-433-868-mhz-selbstbau/
https://blog.moneybag.de/lacrosse-temperatursensor-an-arduino-nano-und-rfm12b-als-jeelink-ersatz/
https://lowpowerlab.com/2012/12/28/rfm12b-arduino-library/

Zeichne mal ein Paar Daten im Hex-Format auf.

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Sven77

Vielen Dank für die Ausführungen!

Mein Problem ist leider bisher, dass ich so weit noch gar nicht bin...
Ich habe bisher 3 Stück CC1101 herumliegen, eines an einem ESP8266 und die anderen am Arduino. Leider konnte ich denen noch keine Rohdaten entlocken, vermutlich wegen falscher Bandbreite, Deviation oder was auch immer man noch einstellen kann, was ich (noch) nicht verstehe.

Vermutlich muss ich doch nochmal RFM69 (oder 12) bestellen und mit denen probieren. Wenn diese aber bezahlbar sein sollen, ist es mit wochenlanger Wartezeit verbunden.  ;)
Und am Ende habe ich vermutlich 2 Kisten voller Funkmodule, von denen ich nur eines nutze. Klar, es ist ein überschaubares Lehrgeld - nur vermutlich kann man letztlich mit allen diese simplen FSK-Daten empfangen, wenn man die richtigen Einstellungen nutzt.  ::)

Falls jemand also noch RFM69/12 oder einen JeeLink mit 433MHz unbenutzt herumliegen hat, kann er sich ja gern bei mir melden.
Wenn nicht, bestelle ich einfach mal und warte auf das nächste Containerschiff aus Asien.


Eine letzte Idee kam mir noch vor ein paar Tagen:
Gibt es vielleicht auch (nur) eine Frequenzabweichung zwischen CC1101 und RTL2838?
Leider habe ich bei der Überlegung, wie man das prüfen könnte, zu lange das offensichtliche übersehen: ich sende einfach mal mit dem CC1101 auf der gewünschten Frequenz 433.216MHz und schaue mir im SDRsharp an, auf welcher Frequenz es ankommt. Danach berichte ich wieder...
VG, Sven

pejonp

Hallo Sven ,
Einen rfm12 433MHz habe ich noch. Denn kannst du haben. Einen Nano oder uno hast du so etwas?
Schicksal eine mail

Jörg
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

RaspiLED

Hi,
ich habe gerade einen RFM69 433 und mehrere 868er erhalten.
Melde Dich einfach; -)
Gruß Arnd

Gesendet von meinem SM-G800F mit Tapatalk

Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

pejonp

Hallo Sven,

ich hatte mir mal 2 JeeNode V6 ( https://www.digitalsmarties.net/products/jeenode) mgekauft, dort werden die RFM aufgelötet.
Zum basteln habe ich an die RFM12 Steck(Stift)leisten angelötet bzw. mir von JeeLabs Shop Leiterplatten (https://www.digitalsmarties.net/products/rfm12b-board
https://www.digitalsmarties.net/products/rfm-board) geholt. Da ich die RFM am esp8266 betreibe habe ich mir nur die Leiterplatten ohne alles geholt.

Jörg

LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Sven77

So... ein paar neue Erkenntnisse habe ich schon:

a) Ich muss beim CC1101 als Baudrate 19200 einstellen, um ein gleichlanges Signal zu bekommen. Hätte mir eigentlich klar sein können/müssen - in meinen Aufzeichnungen steht sogar 19200 Baud, warum ich hier immer von 9600 sprach, weiß der Geier.  :-X

b) Das vom CC1101 erzeugte Signal sieht schon von den Flanken her anders aus, und auch im SDRsharp. Ich hänge mal den Vergleich zwischen Original (Mitte) und FSK-2 bzw. GFSK an. Warum ist das keine so schöne Kurve, wie im Original??
Und die Amplitude ist auch größer - wohlgemerkt ist dieses Audio-File schon FM dekodiert, es scheint eine größere Bandbreite zu nutzen - kann man denn die Sendebandbreite konfigurieren?

VG, Sven

Sven77

ich nähere mich (langsam):
Die größere Frequenzabweichung kann man durch Reduktion der DEVIATION verkleinern. Ein RFM12 hat als Minimalwert 15kHz, mit diesem Wert erzeugt das CC1101 schon eine ähnliche Kurve - jedoch insgesamt nach unten Verschoben, also nach FM Demodulation ist eine logische 0 auf -0,5dB und eine logische 1 bei etwa -0,1dB.

Zur Erinnerung: das Original schwingt genau um 0 mit ca. -0,1dB für 0 und +0,1dB für 1.

Ideen, womit das geändert werden kann?
VG, Sven

pejonp

Hasllo Sven,

ich habe eine esp8266 mit einem RFM69 verbunden. Schaltung siehe hier (https://wiki.fhem.de/w/images/e/e8/Lgw_Schaltplan_Devkit_minimum.png). Ist aus diesem Wiki (https://wiki.fhem.de/wiki/LaCrosseGateway_V1.x).

Software ist das LaCrossGatewaye. Ließ dir mal den Wikieintrag zum Gateway durch. Dort steht auch wie du die Software darauf bekommst.
Du kannst dich per Wlan verbinden und dir den Log ansehen und auch in den debugmodus umschalten "1d v".

Hast du schon mal etwas mit Arduino und Co. gemacht oder ist es dein erstes Projekt ?

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Sven77

Nein, nicht mein erstes.
Habe letztes Jahr meine Rollladensteuerung mit ATTinys gemacht und nebenbei ein wenig mit dem Nano herumgespielt. ESP8266 habe ich mir nur grob angesehen, aber solange es von der IDE unterstützt wird, verhalten sie sich ohnehin ähnlich. Interna (welche Pins sind interrupttauglich etc.) kann ich mir ohnehin nie merken und ergoogle sie mir immer wieder neu.  ;D
VG, Sven