Kopp free control

[Gemikro]

Hallo RaspII,

ich bin auch grad dabei die Kopp Sender zu entschlüsseln.
Allerdings hab ich den Logger noch nicht fertig.
Aus Deiner Excel Datei sehe ich aber heraus dass die Pakete alle gleich sind.
Wenn Du die Daten nicht als HEX Werte sondern als Binär-Wurst aufschreibst dann wird aus AA z.b. um ein Bit verschoben 55.
Aus AA 54 07 C8 F9 9A B0 ... wird dann
10101010010101000000011111001000111110011001101010110000
und aus A9 50 1F 23 E6 6A C3 ...
10101001010100000001111100100011111001100110101011000011

was um zwei Bit nach rechts verschoben die gleiche Bitfolge ergibt wie oben:
10101010010101000000011111001000111110011001101010110000
__10101001010100000001111100100011111001100110101011000011 
auch bei 95 01 F2 3E 66 AC ...
__________1001010100011111001000111110011001101010110000110011001111000000 

d.h. das gesendete Bitmuster ist immer gleich. Zu Beginn 01010101... dann kommen irgenwann 7 Nullen und dann die gleichen Daten.
Sinnvoller zur aufzeichnung wäre d.h. die Bitfolge und triggern auf das Ende des 10101010 Musters.

Wenn ich den Logger fertig habe werd ich mal meine diversen Kopp Geräte aufzeichnen und versuchen die Funktion der einzelnen Bits herauszulesen.

lg Max

[RaspII]

Hi Max,
du bist gut !
Mir ist das so noch nicht aufgefallen, obwohl ich mir das ganze auch binär angeschaut hatte.
Ich habe Deine Überlegungen aber noch nicht komplett verstanden, warum denkst Du, dass auch die 95 01 F2 3E 66 AC ...
die gleiche binärfolge liefert, dort ist doch zumindest die von mir Fett unterlegte Bitfolge unterschiedlich (trotz Verschiebung!)
Kannst Du mir da auf die Sprünge helfen?

Zitat:
was um zwei Bit nach rechts verschoben die gleiche Bitfolge ergibt wie oben:
10101010010101000000011111001000111110011001101010110000
__10101001010100000001111100100011111001100110101011000011
auch bei 95 01 F2 3E 66 AC ...
_________1001010100011111001000111110011001101010110000110011001111000000 
Zitat Ende

Hab das nochmal weitergesponnen:
Nimmt man die erste Zeile: AA 54 07 C8 F9 9A B0 CC 0F als Binärwert
101010100101010000000111110010001111100110011010101100001100110000001111      und stellt die 95 01 F2 3E 66 AC 33 03 C0 ..  incl. vorangehender AA's (=1010 er Folgen) darunter dar:
10101010010101xxxx000111110010001111100110011010101100001100110000001111000000
ist die Zeichenfolge wieder bis auf die 4 fetten x wieder 54 07 C8 F9 9A B0 CC.. , die weiteren Binärzahlen müsste man erst noch verifizieren.
So richtig passt das alles noch nicht zusammen, auch wenn ich glaube Du bist auf der richtigen Spur.


Gruß
Claus


Nachtrag:
Habe glaub ich den Fehler gefunden: 9501 ist nicht wie von Dir geschrieben =
100101010001  binär  sondern
1001010100000001 binär,
damit sind die 4 fetten x durch  0000  zu ersetzen und alles ist wieder logisch richtig.

Jetzt muss ich nur noch klären ob das Sync Pattern am Anfang 55 oder AA ist.
Da ich bei AA eine korrekte Checksumme bekomme gehe ich mal von AA aus.

Ich schreibe bei Gelegenheit mal meine Software um und triggere auf die Zeichenfolge  aa 54, warte danach auf einen Block mit definierter Länge und triggere wieder auf aa 54.
Wenn möglich schreibe ich auch mal die Zeitstempel mit, vielleicht sind dadurch ja Sendepausen etc. reproduzierbar oder Störungen (Sender macht Pause) besser zu identifizieren.
Danach sollte eigentlich alles reproduzierbar sein (hoffentlich).
Wenn das klappt, werde ich versuchen die Daten korrekt zu senden und schau mal ob das Kopp Modul wie erwartet reagiert.

Das kann allerdings etwas dauern (habe kaum Zeit).

dank Dir nochmal für die Hilfe, das hat mich richtig weitergebracht.

Gruß
Claus

[Gemikro]

Hi RaspII,

war gestern schon etwas spät ich hab das auf Dienstreise am Schleppi im Hotel getippt
Da können sich schon ein paar Fehler einschleichen.

Ich habe daheim ein paar Handsteuerungen herumliegen (822302025, 811402020, 811407025) und mehrere Empänger (Rolladen, Einzelempfänger, schaltbare Steckdosen etc.).
Sobald ich meinen 868Mhz Empfänger hab logg ich da mal mit.

Mir kommt so vor als ob der große Handsender etwas anders funktioniert als der kleine.
Jedenfalls verhalten sich die Rollladen anders mit dem kleinen (reagieren langsamer).
Ich bin auch gerade dabei die Rollladen Schalter alle umzubauen, da sind nach 7 Jahren Betrieb die Netzteil Kondis defekt und manche von den Schaltern reagieren nur mehr schlecht. Die Ersatzteile gibts um ein paar Cent beim Farnell und danach gehen die Schalter wieder wie neu.

Hab mir dabei auch die verbauten Chips ansehen.
In den Rollladen Empfänger sitzt ein CC1100 (TI 868 Transceiver) so wie am CUL (dort ist´s halt ein CC1101) und ein echter Atmel (ATmega48V).
In allen Sendern sitzt immer ein CC1150 (TI 868MHz Transmitter) und ein scheinbar chinesischer Nachbau für den Atmel (T2313V 10MUCL).

Werd mal schauen ob man die Atmels auslesen kann, die SPI Pins sind auf Testpads herausgeführt 

lg Max

[RaspII]

Hi Max,
so gefält mir das.
Die Info mit den Sender IC's hatte ich auch schon, die Info bzgl. Empfänger IC's ist für mich neu und wertvoll (habe meine 3 Empfänger im Schaltschrank verbaut und keine Lust den zu zerlegen )
Ich benutzte für meine Experimente das RFM12b Modul mit einem Si4420/Si4421 868MHz IC von Silicon Labs.
Erst durch Deine Info wurde mir gestern bewusst, dass der Baustein die einzelnen Bytes nicht über Start/Stopp Bits synchronisiert sondern einfach jeweils n mal 8 Bits sendet und der Empfänger die Synchronisation über bestimmte bekannte Pattern durchführt. Genau hier habe ich ein Problem mit dem RFM12B Modul im Empfangsmode.
Ich kann ein maximal 2 Byte großes Pattern festlegen. Ein Byte davon ist frei definierbar, das 2te Byte liegt fest auf "2D". Damit kann ich aber kein zu den Kopp Modulen passendes 2 Byte Synchron Pattern definieren, in SW möchte ich das nicht nachbilden. Ein ein Byte Synchron Pattern liefert mir zu viele falsche Trigger (ca. alle sec. ein Ereignis ohne das der Sender überhaupt bedient wird).

Habe mir eben das Datenblatt zum CC1101 grob angeschaut.
Dieser Baustein kann tatsächlich ein Sync Pattern von 16Bit frei konfigurieren, damit könnte man z.B. auf AA 54 synchronisieren und alles wäre gut
Allerdings ist der Baustein so komplex, dass man vermutlich einen Monat braucht um zu verstehen wie er zu konfigurieren ist , da ist der Umgang mit dem  RFM12b Modul deutlich einfacher.

Die gute Nachricht:
Eigentlich habe ich ja schon die meisten  Info's die ich brauche um die korrekten Botschaften zu senden.
(Der Empfänger ist ja nur ein Hilfskonstrukt um rauszubekommen was die Sender so treiben).
Ich muss jetzt "nur" noch ermitteln wie oft die Sender die Blöcke wiederholen und wie groß die Pausen zwischen den Blöcken sind, danach kann ich mal auf "Sendung" gehen.
Notfalls kann ich den Empfänger nochmal in Betrieb nehmen und auf 54 Synchronisieren, falsche Schrott-Botschaften muss ich dann per SW aussortieren .
Ich melde mich wieder, spätestens sobald ich meinem Schaltschrank per Raspberry Pi steuern kann . (Könnte aber einige Wochen dauern)

Was Dir evt. weiterhilft:
Im Meinem Excel Sheet Blatt "Block1" habe ich ja schon aufgeführt was mein großer Handsender (811402) sowie mein kleiner Handsender (8114.07) an Kommandos sendet.
Vor allem die Daten zum großen Handsender sind sehr aufschlussreich (kurzer Tastendruck). Falls Du schon die Möglichkeit zum senden hast kannst Du ja mal Loslegen und schauen ob es funktioniert.
Evt. muss Du nach der vermeindlichen Checksumme noch die Nullen+den Rest mitsenden (das ist in Sheet "Taste dauergedrückt" besser herausgearbeitet).

Welche IC's hast Du eigentlich bzw. welche wirst Du Dir besorgen?
Ach noch was, wozu willst Du eigentlich die Atmels auslesen? Um die Kommunikation zum HF Modul zu belauschen (wird ohne gute Meßgeräte & Protokoll Interpreter nicht einfach sein, Du wirst doch nicht die Bits von Hand zählen wollen ?)


Gruß
Claus

[Gemikro]

Hallo RsapII,

Bits per Hand zählen tu ich nur auf Dienstreise wenn ich am Abend nichts besseres zu tun hab
Ich hab einige Atmels + ISP, Arduinos, Raspberry Pi, Beaglebone etc. herumliegen irgendwas wird sich da schon finden mit dem man senden und empfangen kann.
Die Receiver und Transmitter bekomme ich erst nächste Woche, muß da auf eine Sammelbestellung warten.
Ich hab auch ein RFM12b Modul bestellt.

In der Firmware für den CUL müsste ja ein Modul für den CC1101 dabei sein oder.
Das müssten wir doch nicht neu programmieren ?

Was ich noch interessant finde ist dass die Empfänger einen Transceiver haben und somit senden können. Womöglich wiederholen die Dinger die Meldungen die sie empfangen und nicht der Sender

Grüße
Max

[RaspII]

Hi nochmal,
CUL sagt mir nix, musst Du mir erklären. (Nachtrag: hab grad gegoogled und verstanden)
Für den Raspberry Pi und das RFM12b Modul habe ich Sende und Empfangssoftware verfügbar die den Kopp Sender prinzipiell empfangen kann.
Die Empfangssoftware ist zwar noch bastelei, damit konnte ich aber die Daten für's Excel Sheet empfangen.

Auch senden müsste tun, allerdings reagiert mein Kopp Schaltmodul noch nicht darauf (könnte aber auch einfach ein Reichweitenproblem sein, die Schaltmodule sind im Sicherungsschrank und mein Raspberry Pi ist zwei Stockwerke entfernt).


Nachdem ich mir gestern das Datenblatt vom CC1101 angeschaut habe hoffe ich, dass wir mit dem RFM12b Modul auskommen, der ist völlig simpel zu programmieren.
Alles andere (SPI Kommunikation....) ist für den Raspberry Pi verfügbar, ich kann Dir bei Bedarf mal zusammenstellen welche Schritte ich unternommen habe bis das RFM12b Module funktioniert hat.
(wollte das sowieso noch dokumentieren)

Ich bin mir sehr sicher, dass der Sender die Daten wiederholt. Drückt man die Taste nur ein mal, kommt immer der gleiche Block. Beim nächsten Druck wird das Zählerbyte incrementiert.
Bei einem langen Druck wird zuerst ein um 80hex erhöhter Tastencode gesendet, beim Loslassen der Taste kommt als Tastencode 7F, das macht alles richtig Sinn.
Ich hätte auch erwartet, dass der Sender den Block wiederholt, Man muss ja mit einer gestörten Übertragungstrecke rechnen.

Würde mich darüber freuen, wenn Du Dir das RFM12B Modul auch auf den Raspberry Pi klemmst, ich vermute mal dass wir schneller unterwegs sind wenn wir gemeinsam an einer Lösung arbeiten.
Hab noch ein Bild von meinem Aufbau angehängt.

Gruß
Claus

[RaspII]

Hallo Max,
ich bin am Verzweifeln.
Ich habe am Wochenende meine Software umgebaut, Zeitstempel hinzugefügt
und mal auf das erste Byte gesynct, das immer konstant ist (5A).

Über die Zeitpattern habe ich rausbekommen, dass sobald die X11 Oberfläche, Dateimanager, Leafpad etc. auf dem RPi läuft es mit der echtzeit nicht mehr weit her ist.
8 Bit benötigen zum Empfangen ca. 1,67 ms, ich hatte Jitter bis zu 30ms (d.h. mir gingen einige Bytes flöten).
Gehe ich nicht über X11 auf den RPi sonder mit einem einfachen Terminal, empfange ich die Bytes mit einem Jitter von max. ca. 300µsec, das erklärt sich über das Fifo.
Somit ist klar, warum ich manchmal völlig unerklärbare Ergebnisse hatte. -> Problem erkannt / gebannt 

Aber jetzt kommts.
Schaut man sich die plausiblen Botschaften im Excel Sheet an, ist das erste plausible Byte immer 54.
Wenn ich auf 0x54 synchronisiere bekomme ich immer falsche Botschaften. Ich konnte mir das nicht erklären, schaut mal sich aber den Bitstream wieder an (Du siehst ich bin lernfähig), sieht man folgendes:
Ich weiss ja schon, dass ca. 17 Bytes Präambel mit 0xAA ankommen.
D.h. die erste gültige Botschaft fängt folgendermaßen an:
....AA5407...
als Bitstream:
101010100101010000000111

Im Detail:
   A  |   A  |  5   |  4   |  0  |  7
101010100101010000000111

Das Sync Byte 54 kann man in diesem Stream auch so finden:
|  5   |  4   |  A   |  8  |..........
101010100101010000000111

und da diese 54 immer vor der erwarteten 54 kommt wird automatisch jedes mal falsch gesynct. ! 
Synce ich auf die 07 klappt es prinzipiell. Es kommen danach 8-10 korrekte Blöcke an, die Bitverschiebungen wie oben beschrieben (z.b. 95 statt 54) gibt es nicht mehr.
Allerdings kommt es ohne Signal immer mal zu Störsyncronisationen, da ich per SW nichts mehr zusätzlich filtern kann (das nächste Byte ist senderspezifisch)

Jetzt hilft nur noch eines (fällt mir gerade ein, es hilft wenn man schreibt).
Ich synce auf 07, lese den restlich erwarteten Block komplett ein und prüfe die Checksumme.
Ist die Checksumme ok -> Block wird verwertet
Ist die Checksumme nicht ok werfe ich den Block weg.
(und ich hoffe, dass es keinen Kopp Befehl gibt der eine Länge <> 07 hat, die 07 ist das Längenbyte)
Ich melde mich falls ich das heute noch schaffe

Gruß
Claus

Nachtrag:
Ich Synce jetzt auf 0x07 und prüfe die gültigen Blöcke anhand der Checksumme.
Ergebnis: funktioniert einwandfrei.
Bei jedem "kurzen" Tastendruck werden 13 identische Botschaften gesendet.
Drücke ich die Taste 2x hintereinander erhöht sich der "Tastendruckzähler" um 1
Bei lange Tastendrücken werden auch 13 identsiche Botschaften gesendet (Tastaturcode wie bei kurzem Druck +0x80)

Habe das mit 2 Handsendern (mehr hab ich nicht) und unterschiedlichen Tastendrücken getestet,  es funktioniert jedes Mal und problemlos.

Details zu einer Aufzeichnungssequenz siehe angehängtes Excel Sheet, Tab: 17.3.2014

So, demnächst mache ich mich ans senden, incl. Präambel von 17x AA,  Checksumme etc.
Mir ist nur noch nicht klar, ob die fünf bis sechs 0x00 Bytes die in den alten Aufzeichnungen nach einem gesendeten Block kommen aktiv gesendet werden müssen
oder ob die Bits nur als "0" gelesen werden weil nach einem starken Sendesignal plötzlich kein Signal mehr kommt (das kann man nur direkt am Sender nachmessen)

Gruß
Claus

[Gemikro]

Hallo Claus,

hatte leider in den letzten Tagen keine Zeit für die Bastelei
Ich werd mir Deine Datei mal durchsehen, Du hast da ja schon einiges zusammegetragen !
Am Wochenende hab ich hoffentlich wieder Zeit.

Inzwischen sind auch meine Bauteile eingetroffen und ich werd mal einen Arduino ProMini mit dem RFM12B zusammenschalten.
Es gibt da für den Arduino auch schon eine Lib (JeeLib) die den Transponder anspricht, damit sollte es eigentlich einfach sein einen Logger zu programmieren.
Sobald ich das habe lese ich meine Sender aus und dann können wir die Daten vergleichen.

Ich denke auch das die angehängten Nullen nur von der Software kommen, wenn nötig kann ich da eventuell mal mit dem Oszi nachsehen.

lg Max

[RaspII]

Hallo Max,
ich habs geschafft. Kann jetzt über meinen Raspberry Pi und das RFM12b Modul meine Kopp Empfänger schalten.
Ich war die letzten zwei Tage am verzweifeln, konnte keine Fehler mehr finden und es tat trotdem nicht.

Der Schlüssel zum Erfolg war, dass ich den FSK Modulationsparameter auf maximalwert gesetzt hatte, man muss den aber an die 4,8kBaud anpassen (45 kHz).
Nachdem ich jetzt mein TX CONFIG Register von 0x98F0 auf 0x9820 geändert habe funktioniert das ganze einwandfrei (über 2 Stockwerke, Empfänger sitzen im Schaltschrank).

So, jetzt muss ich ich nur noch die Details angehen, d.h. mir den Blockzähler irgendwie merken, damit beim nächsten Programmaufruf nicht wieder von vorne begonnen wird, und zwischen langen und kurzen Tastendrücken unterscheiden.

Falls Du es Dir noch anders überlegst und den Raspberry Pi benutzt, kann ich noch zusammenschreiben wie man das ganze zum Laufen bekommt.

Gruß
Claus

[Gemikro]

Hallo Claus,

Ich habe inzwischen erst einmal einige meiner Rollladen Empfänger ausgebaut und repariert.
Bei meinem kleinen Handsender habe ich auch gefunden warum der sich so anders verhält als der große.
Am Print beim Antennenausgang war ein SMD Kondensator nur einseitig angelötet, der dürfte beim Reflow Löten aufgestanden sein.
Damit war dann manchmal Kontakt, manchmal halt nicht ...
Neu Löten hat dann die Reichweite des Senders gleich deutlich erhöht.

Die Atmels in den Dingern lassen sich wie erwartet nicht auslesen, die Lock Bits sind gesetzt.

Ich sitze gerade vor meinem Arduino Pro Mini und versuche mich an der Kommunikation mit dem RFM12b.
Derzeit habe ich aber noch Probleme mit der Konfiguration die Du ja schon gelöst hast.
Wär nett wenn Du mir sendest was Du schon programmiert hast.
Das sollte sich einfach auf den Arduino übertragen lassen.

Was nimmst Du den übrigens als Antenne ?

Grüsse,
Max

[RaspII]

Hi nochmal,
als Antenne habe ich einen 8,6 cm langen Draht verwendet (Lambda viertel, wenn ich richtig gerechnet habe).
Meine Sende- / Empfangsroutine habe ich mal angehängt, das ist leider noch "Spagetticode", zu mehr hat's bisher nicht gereicht 
Ich hatte hierfür übrigens eine Vorlage von
http://www.susa.net/wordpress/2012/08/raspberry-pi-reading-wh1081-weather-sensors-using-an-rfm01-and-rfm12b/
benutzt. Der Author hatte damit Wettersensoren ausgelesen. Das hat mir sehr geholfen die ersten Schritte zu machen.

Hab inzwischen wieder einen Rückschlag erlitten, nach ausführlichen Tests habe ich bemerkt, dass die Funkschalter nicht jedes mal schalten wenn ich sende,
auch nicht wenn ich den Rapsberry Pi mit Sender direkt neben den Schaltschrank stelle (scheint dem Zufallsprinzip zu folgen). 
Das bekomme ich früher oder später auch noch hin.

Na dann viel Spaß beim Löten.
Claus

!!!!!  Neu  !!!!!   7.4.2014: Habe die aktuellste Version meiner RFM12b Module anghängt und die alte Version gelöscht

[Gemikro]

Hallo Claus,

danke für die Datei, ich hab leider diese Woche wenig Zeit, hoffentlich wieder nächstes Wochenende.

Hast Du bei Deinen Schaltern schon mal die Kondensatoren kontrolliert ?
Die sind bei praktisch allen von meinen Rollladenschaltern kaputt, ich habe gleich einen Vorrat bestellt und inzwischen mehrere Schalter repariert.
Solange die Kondis nicht getauscht sind habe ich das gleiche Problem wie Du. Manchmal reagieren die Empfänger dann gar nicht mehr und man muß den Strom für ein paar Sekunden abschalten und dann gehts wieder einige Zeit.
Die eingebauten Kondis (Carli X2 MPX40, 250V; waren bisher in allen Empfängern gleich), sind eigentlich laut Hersteller nicht für diese Anwendung geeignet weil sie die Kapazität auf Dauer nicht halten können und dann das Kondensatornetzteil keine Leistung mehr bringt.
Bessere sind leider nicht in der 15mm Bauform zu bekommen aber die die ich bestellt habe sollten doch etwas länger halten (Epcos MKP X2 B32922, 305V).

[RaspII]

Hi,
ich denke nicht, dass es an den Kondi's liegt, mit den Handsendern funktioniert alles einwandfrei.
(trotzdem Danke für den Tipp, werde den früher/später brauchen können).

Ich werde noch nachprüfen ob ich bei irgendwelchen Frequenzen / Bitraten nicht ganz die Mitte getroffen habe (das Kopp auf 868,3 Mhz Mittenfrequenz arbeitet habe ich z.B. aus irgendwelchen Foren, vielleicht sind diese Info's nicht völlständig.)

Bis demnächst

[RaspII]

Hi Max,
habe mal die Bitrate nach oben korrigier, jetzt klappts etwas besser aber immer noch nicht zuverlässig (vielleicht sollte ich die Empfänger direkt auf das RFM12b Modul anlernen,bisher emuliere ich nur einen meiner Sender).

Habe jetzt den FHEM Server bei mir installiert und hab es letztendlich durch ausprobieren  und stöbern in den Foren  tatsächlich geschafft meine Software zu triggern und die Kopp Schalter zu bedienen. Das Hauptproblem war, dass man FHEM die Rechte geben muss externe Software vom "/home/pi/..." Laufwerk zu starten. Wie das gemacht wird und welche Modifikation ich in der Datei fhem.cfg durchgeführt hab ist im Anhang "MyInfoFHEM.txt" zu sehen. Die Datei MyFHEM.jpg zeigt wie das in etwa auf dem Handy aussieht (Screenshot ist vom PC).
FHEM ist unglaublich mächtig, das Problem ist einfach wenn man selbst kaum Erfahrung mit der Bash Shell, Perl und C hat.
(Habe meine Erfahrungen hauptsächlich in der Assembler Programmierung gemacht). Dann dauerts halt etwas länger.

Die Software für den RFM12b via Raspberry Pi habe ich noch umgebaut, damit ich Parameter übergeben kann, als ersten Schritt mal den "Tastencode" des Senders, die Dateien kann ich bei Bedarf noch anhängen (ansonsten mach ich das wenn ich fertig bin).
Der nächste Schritt ist für mich jetzt den "langen Tastendruck" incl. "Taste loslassen nach n msec", damit wären dann die komplette Funktionalität eines Kopp Senders emulierbar.

An dieser Stelle auch noch einen großen Lob an die FHEM Entwickler. FHEM ist wirklich Klasse.

Wie stehts bei Dir, hast Du Fortschritte gemacht?

Gruß
Claus

[Gemikro]

Hallo Claus,

ich steck irgenwie fest.
Ich kann jetzt zwar mit dem RFM12B reden aber irgenwie kann ich nicht so richtig auf die Pakete triggern.
Ich habe erst eine halbe Meldung abgefangen, die beginnt wie bei Dir mit 17 x aa und dann
54 07 7f 01 6f 10 cc 0f 03 ff ff und so weiter aber irgendwie komme ich fast nie bis zur Checksum und ab so 10 Bytes kommt meistens nur noch Müll.

Ich hab eine nette Demo für den Arduino und den RFM12B gefunden mit dem man den ganzen Empfangsbereich scannen kann und so die Sendefrequenzen und den Hintergrund sehen kann:
http://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B

Bei mir funken in der Umgebung jede Menge Geräte durchgehend auf verschiedenen Kanälen.
Was ich dabei gefunden habe ist dass jeder meiner Sender auf einer leicht unterschiedlichen Frequenz sendet.
Mein zweifach Wandtaster sendet auf 868.50 und wenn man dem nRFmon trauen kann mit einer FSK Shift von 240kHz. Der einfach Wandtaster sendet auf 868.35

Ich habe versucht mit Deinen Einstellungen zu Arbeiten aber da bekomme ich irgendwie keinen Empfang.
Werd´s noch weiter versuchen...

Grüsse,
Max