Unbekannte Funkprotokolle - Versionsgeschichte

Ph1959de: Tippfehler korrigiert

2023-01-08T10:18:54Z

Tippfehler korrigiert

← Nächstältere Version		Version vom 8. Januar 2023, 12:18 Uhr
Zeile 294:		Zeile 294:
	* Änderungen durchführen (im korrekten Branch)		* Änderungen durchführen (im korrekten Branch)
	* alles committen		* alles committen
	* <code>controls_signalduino.txt</code> updaten (wird ~~via~~ via github actions automatisch aktualisiert), sonst kann nicht über den update Befehl installiert werden!		* <code>controls_signalduino.txt</code> updaten (wird via github actions automatisch aktualisiert), sonst kann nicht über den update Befehl installiert werden!
	* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten		* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
	* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig		* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig
	* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.		* wenn das alles passt, hat man bereits seinen eigenen Fork fix und fertig (und authentisch getestet) und kann somit direkt - evt. nach einem bereinigenden <code>git rebase -i @{u}</code> - einen Pull Request daraus machen (anders ausgedrückt: "direkt kontext-integrierte Entwicklung", "am Puls der Zeit", "mit voller Tool-Unterstützung"). Dies am besten vollständig Automatisierungs-gekapselt durch ein Shell-Script (FIXME: am besten hier einfach direkt hier präsentieren?), welches an FHEM den <code>update all ...</code> request schickt (über telnet, Port 7072) ''und'' den <code>reload BEARBEITETES_MODUL</code> durchführt.

	== SIGNALduino - FSK ==		== SIGNALduino - FSK ==

	Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.		Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

Zeile 308:		Zeile 307:

	=== FSK Senden ===		=== FSK Senden ===

	Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:		Die ersten Bits des CC1101-Register 12 MDMCFG2 bestimmen die Übertragungsweise:
	000 = 2-FSK		000 = 2-FSK
Zeile 325:		Zeile 323:

	=== Sendefrequenz und Frequenzhub ===		=== Sendefrequenz und Frequenzhub ===

	<div class="tright" style="clear:none">[[Datei:PeakLow.png\|mini\|ohne\|300px\|FSK, Trägerfrequenz minus Hub]]</div>		<div class="tright" style="clear:none">[[Datei:PeakLow.png\|mini\|ohne\|300px\|FSK, Trägerfrequenz minus Hub]]</div>
	<div class="tright" style="clear:none">[[Datei:PeakHigh.png\|mini\|links\|300px\|FSK, Trägerfrequenz plus Hub]]</div>		<div class="tright" style="clear:none">[[Datei:PeakHigh.png\|mini\|links\|300px\|FSK, Trägerfrequenz plus Hub]]</div>
Zeile 334:		Zeile 331:

	=== Ermittlung der Frequenzen ===		=== Ermittlung der Frequenzen ===

	Wie im OOK-Kapitel bereits angesprochen, ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.		Wie im OOK-Kapitel bereits angesprochen, ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

	=== Hub ===		=== Hub ===

	Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40, der mittels		Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40, der mittels
	<code>set <mysduino> raw W1740</code>		<code>set <mysduino> raw W1740</code>
Zeile 350:		Zeile 345:

	=== Baudrate ===		=== Baudrate ===

	Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.		Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.

Zeile 378:		Zeile 372:

	=== Konfiguration ===		=== Konfiguration ===

	Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12		Last but not least meine Konfiguration: SDUINO Firmware war die Version v3.4.1_dev_21.12

Zeile 446:		Zeile 439:

	=== Finale ===		=== Finale ===

	Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.		Nach Aktivierung der vormals ausgeschalteten Message-Typen im SIGNALduino werden nunmehr SD_Keeloq-Devices angelegt.

Zeile 472:		Zeile 464:

	== CUL - FSK und Co. ==		== CUL - FSK und Co. ==

	Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.		Dieses Kapitel geht davon aus, dass ihr einen CUL für alle weiteren Schritte nutzt.

Zeile 478:		Zeile 469:

	== FAQ ==		== FAQ ==

	=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===		=== Woran genau wird erkannt ob ein Signal ShortHigh, bzw ShortLow ist? ===

	Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.		Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

Zeile 504:		Zeile 493:

	== Links ==		== Links ==

	* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)		* [https://github.com/RFD-FHEM/RFFHEM RFFHEM git repository] (drandenken: korrekten Branch auswählen!)
	* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]		* [https://www.hamspirit.de/2286/signalanalyse-fuer-dummies/ Signalanalyse für Dummies]

Sidey: Vorgehen zur Aktualisierung controls Datei überarbeitet

2023-01-05T12:03:54Z

Vorgehen zur Aktualisierung controls Datei überarbeitet

← Nächstältere Version		Version vom 5. Januar 2023, 14:03 Uhr
Zeile 293:		Zeile 293:
	Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:		Es ist evt. empfehlenswert, auf github einen eigenen Fork des RFFHEM-Upstream-Repositories zu erstellen - dann kann man ''dort'' seine Entwicklung durchführen:
	* Änderungen durchführen (im korrekten Branch)		* Änderungen durchführen (im korrekten Branch)
	* <code>controls_signalduino.txt</code> updaten (via <code>build_controls_list.sh</code>), sonst werden die Änderungen nicht angenommen!
	* alles committen		* alles committen
			* <code>controls_signalduino.txt</code> updaten (wird via via github actions automatisch aktualisiert), sonst kann nicht über den update Befehl installiert werden!
	* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten		* mit dem üblichen FHEM-Befehl (<code>update all ...</code>, aber eben sinnigerweise unter Angabe der URL seines ''eigenen'' Repositories!!) seine eigenen Änderungen jeweils korrekt verwaltend und updatend austesten
	* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig		* evt. hier jeweils <code>reload BEARBEITETES_MODUL</code> nötig

AndreasMohr: /* Ansatz 1 - Versuchen */

2021-10-10T09:47:03Z

Ansatz 1 - Versuchen

← Nächstältere Version		Version vom 10. Oktober 2021, 11:47 Uhr
Zeile 89:		Zeile 89:
	Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.		Einfach probieren: Bau Dir einen [[SIGNALduino]] für das passende Frequenzband (die 433 oder 868 MHz-Variante des CC1101). Stelle im SIGNALduino-Setting die Frequenz auf die genannte ein (durch den Befehl cc1101_freq = 433.000 oder 868.000) und die Bandbreite auf das Maximum (cc1101_bWidth = 325 kHz bzw. 650 kHz). Jetzt noch das Attribut verbose auf 5 setzen und dann das FHEM-log (tail -f fhem-yyyy-mm.log) beobachten.

	Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn ''autocreate'' aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).		Ist ein Gerät in Reichweite, das regelmäßig etwas sendet (z.B. ein Funkthermometer), sollte hin und wieder etwas empfangen werden. Wenn [[Autocreate\|autocreate]] aktiv ist, werden auf Basis der erkannten, bekannten Funkprotokolle automatisch neue Devices angelegt (dabei können auch diverse Funkthermometer der Nachbarschaft auftauchen).

	Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).		Ist es ein Gerät, das sich über eine Fernbedienung steuern lässt: Eine Taste betätigen und hoffen, dass sich im FHEM-Log etwas tut. Auch hier gilt: Handelt es sich um ein bekanntes Funkprotokoll, wird automatisch ein Device angelegt, allerdings nur eines für die Gerätefamilie. Bei Baumarkt-Funksteckdosen z.B. nur das erste gefundene. Die anderen müsst Ihr manuell anlegen und die entsprechenden Codes zur Identifikation der einzelnen Steckdosen anpassen (schaut z.B. hier nach: [[Intertechno_Code_Berechnung]]).

AndreasMohr: /* SIGNALduino - OOK */

2021-08-15T14:17:49Z

SIGNALduino - OOK

← Nächstältere Version		Version vom 15. August 2021, 16:17 Uhr
Zeile 210:		Zeile 210:
	Wie ist diese Sequenz zu interpretieren?		Wie ist diese Sequenz zu interpretieren?

	Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (~~Vorzeichen~~/Dauer):		Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Aktiv-Indikator/Dauer):

	* Es startet mit einer Pause D='''0'''123232323232		* Es startet mit einer Pause D='''0'''123232323232
	* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms.		* gefolgt von einem Signal D=0'''1'''23232323232 in der Länge von ca. 16 ms (15916 µs).
	* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.		* danach folgt ein Sync-Block D=01'''23232323232'''... bei dem jeweils Pärchen von 400 µs Pause/400 µs Signal wiederholt werden.
	* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265		* Sync- und Datenteil sind durch einen Puls von 4 ms [P4=4008] getrennt D=0123232323232323232323232'''4'''53265
	* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....		* gefolgt vom Datenteil D=01232323232323232323232324'''53265'''....

	Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Vorzeichen und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.		Beim Datenteil wird es etwas komplizierter. Hier sind immer ein kurzer (2 oder 3) und ein langer (5 oder 6) Wert kombiniert. Folglich muss man bei der Interpretation zwischen Aktiv-Indikator (Vorzeichen) und Dauer differenzieren. Ein Pärchen ist immer 1.200 µs lang. In der Mitte dieser Zeitscheibe kann der übertragene Wert folglich eine Pause oder ein Signal sein.

	Beispiel: Den Vorspann		Beispiel: Den Vorspann
	<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf den Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):		<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> (bestehend aus Puls-Beschreibungen und initialer Puls-Aktivität) lassen wir mal außen vor und konzentrieren uns auf den nachfolgenden echten Nutz-Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):

	<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)		<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)

AndreasMohr: /* Ansatz 2 - Aufschrauben */

2021-08-15T14:10:43Z

Ansatz 2 - Aufschrauben

← Nächstältere Version		Version vom 15. August 2021, 16:10 Uhr
Zeile 116:		Zeile 116:
	* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]		* ASK/FSK -> [[Selbstbau_CUL]] oder [[JeeLink]]

	Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen im Datenblatt des daneben verbauten Chips lässt sich dann die Sende- bzw. Empfangsfrequenz errechnen.		Die Devices senden/empfangen nicht notwendigerweise auf 433 oder 868 MHz, sondern auf Frequenzen "knapp daneben", das kann z.B. bis zu 870 MHz hochgehen. Darüber, welche Frequenz es genau ist, gibt möglicherweise der verbaute Quarz Auskunft. Meist klein, silber mit einer Gravur wie z.B. 6,70 MHz versehen. Mit Hilfe der Spezifikationen (Frequenzteiler, ...) im Datenblatt des daneben verbauten Chips lässt sich dann die tatsächliche Sende- bzw. Empfangsfrequenz errechnen.

	==== Ansatz 3 - Messen ====		==== Ansatz 3 - Messen ====

AndreasMohr: "Friends don't let friends use Google." :(

2021-08-15T14:06:29Z

"Friends don't let friends use Google." :(

← Nächstältere Version		Version vom 15. August 2021, 16:06 Uhr
Zeile 108:		Zeile 108:
	* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt		* abfotografieren und das Foto vergrößern bis Ihr den Aufdruck lesen könnt

	Danach folgt dann ~~Google~~ und das Studium der zugehörigen Data Sheets der Chips.		Danach folgt dann Internet-Suchmaschine und das Studium der zugehörigen Data Sheets der Chips.

	Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.		Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.
Zeile 123:		Zeile 123:

	* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.		* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
	* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele ~~Google~~-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].		* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Internet-Suchmaschine-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
	* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage, mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.		* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage, mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

AndreasMohr: Verbesserungen (Analyse-Beschreibung, Code-Block etc.)

2021-08-15T14:04:48Z

Verbesserungen (Analyse-Beschreibung, Code-Block etc.)

AndreasMohr: Typos / language

2021-08-15T13:25:25Z

Typos / language

Plin53177: /* Finale */

2020-01-20T19:01:00Z

Finale

← Nächstältere Version		Version vom 20. Januar 2020, 21:01 Uhr
Zeile 466:		Zeile 466:
	</pre>		</pre>
	und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.		und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

			Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.

	== CUL - FSK und Co. ==		== CUL - FSK und Co. ==

Plin53177: /* Finale */

2020-01-16T16:38:46Z

Finale

← Nächstältere Version		Version vom 16. Januar 2020, 18:38 Uhr
Zeile 465:		Zeile 465:
	2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2		2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
	</pre>		</pre>
	und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.		und routet die Request an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

	== CUL - FSK und Co. ==		== CUL - FSK und Co. ==

← Nächstältere Version		Version vom 15. August 2021, 16:04 Uhr
Zeile 3:		Zeile 3:
	Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.		Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.

	Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big> (oder natürlich einfach verbessern) - die Usability dieses Projekts sollte sehr gut werden...		Wenn hier drin irgendetwas unverständlich sein sollte (und wenn es nur deswegen sein sollte, weil es hinreichend bescheuert beschrieben ist :)), dann --> <big>'''MELDEN!'''</big>, vielleicht via BenutzerSeite (oder natürlich einfach direkt verbessern) - die Usability dieses Projekts sollte sehr gut werden...

	Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:		Dieser Artikel soll eine möglichst gut chronologische Sortierung haben, also:
Zeile 20:		Zeile 20:
	* Frequenzband (433 MHz, 868 MHz)		* Frequenzband (433 MHz, 868 MHz)

	(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)		(bei SIGNALduino / CUL kann manche Hardware - z.B. nanoCUL - da hardware-kompatibel, mit Projektaktivitäten von CUL ''oder'' SIGNALduino betrieben/firmware-geflasht werden; evt. ist es sogar außerdem empfehlenswert, mehrere baugleiche Geräte zu haben, um Support für SIGNALduino ''und'' CUL gleichzeitig verfügbar zu haben - evt. auch weitere Geräte mit unterschiedlichen Frequenzen: 433/868)

	==== Frequenzbereich ====		==== Frequenzbereich ====
Zeile 72:		Zeile 72:
	Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).		Das ist der herstellerspezifische Teil des Signalstroms - die Daten. Hersteller haben i.d.R. ihre eigene Definition der übertragenen Datenströme. Teils werden feste Code-Sequenzen übertragen, es gibt aber auch rollierende Codes (Engl.: Rolling Codes) bei denen sich die Daten bei jeder Übertragung ändern (Fremd-Manipulations-Sicherheit).

	Mit etwas Glück erkennt z.B. SIGNALduino das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").		Mit etwas Glück erkennt z.B. SIGNALduino bereits das Protokoll, damit den Hersteller und legt automatisch ein passendes Device in FHEM an. Manchmal gibt es auch Fehlinterpretationen und das vermeintlich bekannte Device entpuppt sich als etwas anderes (Statement aus dem Forum: "Lösung war, wo Dooya drauf steht muss nicht immer Dooya drin stecken.").

	== Wie fange ich an? ==		== Wie fange ich an? ==
Zeile 110:		Zeile 110:
	Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.		Danach folgt dann Google und das Studium der zugehörigen Data Sheets der Chips.

	Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen ~~die die~~ Chips unterstützen.		Das gibt Euch weitere Anhaltspunkte zum Modulationsverfahren, den Frequenzen und Optionen welche diese Chips unterstützen.

	Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen		Wenn die Grundsatzfrage geklärt ist, ergeben sich die ersten Handlungsoptionen
Zeile 165:		Zeile 165:
	Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.		Das folgende Beispiel geht davon aus, dass Ihr im 868 MHz-Band unterwegs seid. Bei 433 MHz könnt Ihr in gleicher Weise vorgehen.

	Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch get ccconf. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.		Fangt damit an, dass Ihr den CC101 mittels set-Command cc1101_freq auf 868.000, cc1101_bWidth auf 650 und cc11=1_sens auf 8 einstellt. Kontrollieren könnt Ihr das durch <code>get ccconf</code>. Die Bandbreite bWidth gibt an wie groß der Empfangsbereich ist. Bei 650 kHz sind das z.B. +/- 325 kHz, also der Bereich von 867.675 bis 868.325 MHz.

	Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.		Wenn ihr etwas empfangt ist das ein Ansatzpunkt. Anderfalls könnt Ihr die cc1101_freq in 200 kHz-Schritten (868.200, 868.400 ...) erhöhen und das Frequenzband auf diese Art und Weise absuchen. Ein Hinweis an der Stelle: Im FHEM-Log folgt bei den SIGNALduino-Einträgen nach dem Datenteil D= die Empfangsstärke R=. Damit könnt Ihr feststellen, ob Ihr Euch der Sendefrequenz nähert oder entfernt.
Zeile 209:		Zeile 209:

	Wie ist diese Sequenz zu interpretieren?		Wie ist diese Sequenz zu interpretieren?

			Anhand der anfänglich gelisteten Puls-Beschreibungen Px= (Vorzeichen/Dauer):

	* Es startet mit einer Pause D='''0'''123232323232		* Es startet mit einer Pause D='''0'''123232323232
Zeile 219:		Zeile 221:

	Beispiel: Den Vorspann		Beispiel: Den Vorspann
	<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf ~~die~~ Daten		<code>P0=-32001;P1=15874;P2=-364;P3=447;P4=4060;P5=-762;P6=853;D=01232323232323232323232324</code> lassen wir mal außen vor und konzentrieren uns auf den Daten-Teil (hinsichtlich dessen logischer Protokoll-Umformung hin zur finalen Nutz-Datenwort-Sequenz):

	<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626		<code>53265326535326535326265353262653265353535326265353265326262653265326265353535353532653535353262653265353265353535353535353532626 (rohe Abfolge der Puls-Typen)

	lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL		lSsLlSsLlSlSsLlSlSsLsLlSlSsLsLlSsLlSlSlSlSsLsLlSlSsLlSsLsLsLlSsLlSsLsLlSlSlSlSlSlSsLlSlSlSlSsLsLlSsLlSlSsLlSlSlSlSlSlSlSlSlSsLsL (als sSlL-Notation)

	1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0		1 0 1 0 1 1 0 1 1 0 0 1 1 0 0 1 0 1 1 1 1 0 0 1 1 0 1 0 0 0 1 0 1 0 0 1 1 1 1 1 1 0 1 1 1 1 0 0 1 0 1 1 0 1 1 1 1 1 1 1 1 1 0 0 (als Bitfolge)

	10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100		10101101 10011001 01111001 10100010 10011111 10111100 10110111 11111100 (Gruppierung auf Bit-Datenworte)

	AD99 79A2 9FBC B7FC</code>		AD99 79A2 9FBC B7FC (als Hex-Datenworte)</code>

	Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)		Die Analyse basiert auf folgenden Annahmen (mit Beispiels-Werten)
Zeile 240:		Zeile 242:
	* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können		* es ist wohl sinnvoll, zu versuchen, sich evt. an einem längsten Puls (das ist nämlich evt. eine Sync-Pause) zu orientieren, um nachfolgende Bereiche evt. als startendes Bit-Datenpaket identifizieren zu können
	* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt		* man sollte die Pulsfolge per Textsuche analysieren, in einem Editor/Reader, der Such-Texte in einer Zeile '''mehrfach''' farbig markieren kann (less, ...) - bei markiertem Suchtreffer kann man dann Teil-Folgen identifizieren, welche sich deterministisch ''wiederholen'' - diese sind dann wohl offensichtlich codierte Bit-Daten, welche es passend zu entschlüsseln gilt
	* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein "reload 00_SIGNALduino" gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!!) Attribute verbose 5 und debug 1 setzen!)		* die identifizierten Merkmale sind dann als ein neues Protokoll (falls kein bereits existierendes Protokoll zu unpräzise formuliert sein sollte!) in <code>FHEM/lib/signalduino_protocols.hash</code> hinzuzufügen (Angabe präziser Durchschnittswerte von Basis-Takt, Gesamt-Patternlänge, Puls-Pause-Verhältnisse, ... - Details dieses Protokolls siehe Header dieser Datei), und dann muss ein <code>reload 00_SIGNALduino</code> gemacht werden, um dies zu testen (hier: beim sduino-Device temporär(!! - hoher Platzbedarf...) Attribute verbose 5 und debug 1 setzen!)
	* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links\|RFFHEM git repository]] ansehen		* für Beispiele einer Protokoll-Implementierung sollte man sich wohl auch die History (entsprechende Commits) im [[#Links\|RFFHEM git repository]] ansehen
	* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen		* es ist evt. sinnvoll, sich die Verarbeitungskette anhand von Empfang/Senden bereits funktionsfähiger Protokolle / Geräte zu verdeutlichen, bevor man selber loslegt, neue Geräte (Protokolle) zu unterstützen
Zeile 314:		Zeile 316:

	Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über		Schaut Euch den aktuellen Registerinhalt an, bevor Ihr ihn ändert. Am einfachsten geht das über
	''get <mysduino> ccreg 99''		<code>get <mysduino> ccreg 99</code>
	Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.		Ihr müsst beim angezeigten Wert die ersten drei Bits entsprechend abändern, also z.B. aus 0x30 dann 0x10 für GFSK statt OOK machen.
	Das Register wird über		Das Register wird über
	''set <mysduino> raw W1410''		<code>set <mysduino> raw W1410</code>
	abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).		abgeändert (bitte beachtet das Offset von 0x02 für das Beschreiben eines Registers, 14 adressiert Register 12).

Zeile 338:		Zeile 340:

	Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40, der mittels		Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40, der mittels
	''set <mysduino> raw W1740''		<code>set <mysduino> raw W1740</code>
	an den CC1101 des SDUINO übermittelt wird.		an den CC1101 des SDUINO übermittelt wird.

Zeile 354:		Zeile 356:
	FHEM <-> Arduino <-> CC1101 <-> Sendesignal		FHEM <-> Arduino <-> CC1101 <-> Sendesignal

	Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.		Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels <code>get <myduino> ccconf</code> ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

	Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.		Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter ('''P'''uls?) 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

	<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png\|mini\|600px\|RIO-Signal decodiert]]</div>		<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png\|mini\|600px\|RIO-Signal decodiert]]</div>

← Nächstältere Version		Version vom 15. August 2021, 15:25 Uhr
Zeile 1:		Zeile 1:
	Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.) ist es einfach dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?		Es gibt jede Menge offiziell in FHEM unterstützte Devices und Funkprotokolle. Solange das Device Ross und Reiter benennt (Homematic, Z-Wave, Intertechno etc.), ist es einfach, dieses in FHEM einzubinden. Was aber, wenn selbst mit hinreichend gut aktualisierter Installation nichts erkannt wird und es ein No-Name Produkt ist, bei dem man nur die Hoffnung hat, dass es im Innern etwas Bekanntes beherbergt?

	Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.		Dieser Wiki-Artikel soll jenen helfen, die Geräte mit einem unbekannten Funkprotokoll an FHEM anbinden bzw. mit FHEM steuern wollen.
Zeile 38:		Zeile 38:
	==== Encoding oder auch Leitungscode ====		==== Encoding oder auch Leitungscode ====

	Die Art und Weise wie dieses Signal interpretiert wird hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.		Die Art und Weise wie dieses Signal interpretiert wird, hängt wiederum vom Encoding ab. Dazu sei auf die nachfolgenden Quellen verwiesen.

	* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]		* [https://de.wikipedia.org/wiki/Leitungscode Leitungscode (Einstieg)]
Zeile 49:		Zeile 49:
	interpretiert.		interpretiert.

	Im FHEM-Forum gibt es viele freundliche Helfer die Euch bei Bedarf den richtigen Weg weisen.		Im FHEM-Forum gibt es viele freundliche Helfer, die Euch bei Bedarf den richtigen Weg weisen.

	==== Signalstruktur ====		==== Signalstruktur ====
Zeile 124:		Zeile 124:
	* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.		* Zum einen könnt Ihr den nrfmon-Ansatz verfolgen (siehe [https://jeelabs.net/projects/cafe/wiki/NRfMon_-_nano_Spectrum_Analyzer_with_the_RFM12B hier)]. Tipp: bestellt Euch direkt genug Material um zwei zu bauen, denn die RF12demo kann als Sender und Empfänger genutzt werden. Damit lässt sich direkt verifizieren, dass Euer RFM12B-Device wirklich sendet/empfängt.
	* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].		* Der andere Ansatz nutzt einen DVB-T-Stick (siehe z.B. [https://homematic-forum.de/forum/viewtopic.php?t=11087 hier]. Es gibt aber viele Google-Treffer unter dem Stichwort [https://www.mikrocontroller.net/topic/243367 SDR]. Außerdem ein konkretes Projekt: [https://github.com/merbanan/rtl_433/ rtl_433].
	* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.		* Mein persönlicher Favorit ist der [https://github.com/jopohl/urh Universal Radio Hacker]. Mit dem war ich in der Lage, mittels RTL-SDR-Stick nicht nur Sequenzen mitzuschneiden sondern auch direkt zu analysieren.

	Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.		Wieso überhaupt so kompliziert? OOK nutzt nur eine Frequenz, FSK zwei, vier, je nach Variante. Es kann auch vorkommen (so wie bei mir), dass ein FSK-Device auf einen OOK-Sender anspricht. Der Grund dafür sind Oberwellen die mit dem Ein-/Auschalten der Frequenz einher gehen.
Zeile 283:		Zeile 283:
	* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht		* aus diesen dann einen Mittelwert bilden, damit man die größte Präzision erreicht
	* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln		* evt. sogar längere (Sync-)Pulse (z.B.: 15x ''clockabs'' Low, 1x ''clockabs'' High) heranziehen, um durch Mittelung (+ Teilung) über viele dieser z.B. 15x wiederholten Pulslängen einen daraus resultierend maximal präzisen ''clockabs''-Basistakt-Mittelwert zu ermitteln
	* evt. ist es auch hilfreich, den im Gerät verbauten ~~Quartz~~ zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:		* evt. ist es auch hilfreich, den im Gerät verbauten Quarz zu berücksichtigen - u.U. lässt sich hieraus (falls eine solche Verarbeitung im Gerät tatsächlich Timer-mäßig relevant sein sollte!) ein sehr präziser da "mechanisch" passender Puls-Takt-Wert ermitteln (Pseudo-Beispiel:
	<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>		<code>(1 / 8MHz) * 2048 [digitaler Teiler] = 0.256ms == 256us</code>
	); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)		); wobei der mechanische Gerätetakt evt. doch erstaunlich anders sein könnte als die von SIGNALduino erfassten Werte (inwiefern das dann hinsichtlich Rx-/Tx-Präzision relevant ist - wer weiß...)
Zeile 301:		Zeile 301:
	Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.		Dieses Kapitel geht davon aus, dass ihr einen SIGNALduino für alle weiteren Schritte nutzt.

	Aktuell laufen Bestrebungen den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)		Aktuell laufen Bestrebungen, den SIGNALduino FSK-fähig zu machen: siehe [https://forum.fhem.de/index.php/topic,106582.0.html FSK mit SIGNALduino] (vormals https://forum.fhem.de/index.php/topic,82379.0.html)

	Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].		Die Summary der CC1101-Settings findet ihr [https://forum.fhem.de/index.php/topic,106594.0.html#new hier].
Zeile 333:		Zeile 333:
	=== Ermittlung der Frequenzen ===		=== Ermittlung der Frequenzen ===

	Wie im OOK-Kapitel bereits angesprochen ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO ~~vorgebene~~ Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung ~~könnte~~ Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.		Wie im OOK-Kapitel bereits angesprochen, ist eine Messung mit Hilfe eines SDR-Sticks hilfreich. Doch Vorsicht - diese Sticks sind oftmals nicht geeicht und die angezeigte Frequenz wird "relativ" genau gemessen. Was aber hilft ist ein Vergleich Original/Kopie. Messt mit dem SDR-Stick unter Nutzung eines Programms wie URH die Frequenzen, sendet mit dem SDUINO ebenfalls ein Signal auf einer von Euch vorgegebenen Frequenz. Nehmt als Basis für den Ver- bzw. Abgleich die von Euch im SDUINO vorgegebene Frequenz. Die ist für die weiteren Aktivitäten relevant. Die Abweichung könnt Ihr in der URH-Software zur Frequenzkorrektur vorgeben, dann werden identische Werte angezeigt.

	=== Hub ===		=== Hub ===

	Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40 der mittels		Da hilft Euch das RF Studio für den CC1101. Der darin ermittelte Wert ist in das Register 15 DEVIATN zu übertragen. Bei 25 kHz Hub ist das der Wert 40, der mittels
	''set <mysduino> raw W1740''		''set <mysduino> raw W1740''
	an den CC1101 des SDUINO übermittelt wird.		an den CC1101 des SDUINO übermittelt wird.
Zeile 349:		Zeile 349:
	=== Baudrate ===		=== Baudrate ===

	Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet ~~ein~~ Fülle weiterer Optionen (Sync, FIFO etc.) die aber eher für Spezialisten geeignet sind.		Beim SDUINO übernimmt der CC1101 die Funktion eines Modems. Die Signalaufbereitung bzw. -erzeugung erfolgt im Arduino. Das können wir auch für das Senden von FSK Signalen nutzen. Der CC1101 bietet eine Fülle weiterer Optionen (Sync, FIFO etc.), die aber eher für Spezialisten geeignet sind.

	Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:		Welche Baudrate soll/muss ich angeben? Zunächst mal gilt es folgende Teilstrecken zu unterscheiden:
Zeile 356:		Zeile 356:
	Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.		Die Baudrate zwischen FHEM und dem Arduino wird in FHEM vorgegeben. Die für den CC1101 angegebene und mittels ''get <myduino> ccconf'' ausgegebene Baudrate ist die zwischen dem Arduino und dem CC1101. Mit dieser Baudrate wird das Funksignal gesampled.

	Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ~~ermittels~~ und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.		Beim Empfang interpretiert der Arduino den Signalpegel und erkennt die Übergänge zwischen 0 und 1. Es wird die Dauer des jeweiligen Signals ermittelt und einem Parameter 0-7 zugeordnet. Auf diese Weise wird die gesamte empfangene Codesequenz beschrieben.

	<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png\|mini\|600px\|RIO-Signal decodiert]]</div>		<div class="tleft" style="clear:both">[[Datei:RIO-Signal.png\|mini\|600px\|RIO-Signal decodiert]]</div>
Zeile 363:		Zeile 363:
	Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.		Die Baudrate lässt sich im CC1101 nur bedingt präzise einstellen, da dafür nur ein Byte zur Verfügung steht.

	Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die ~~SOftware~~ URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine ~~realse~~ Darstellung zu kommen gebe ich 402 Samples/Symbol (Symbol=bit) ein.		Ich habe bei der obigen Sequenz die Baudrate bzw. SCLK aus dem Vorspann (Preamble) ermittelt und bin auf 2.482 Baud gekommen. Für die Übertragung habe ich aber die 10fache Rate verwendet, um die Steuerung des Zustandes 0/1 dem Arduino und nicht dem CC1101 zu überlassen. Statt einer 0 werden dann halt 10x 0 übertragen. Auf Sendeseite ändert sich dadurch nichts. Die Software URH arbeitet ähnlich. Das Signal wird z.B. mit 1 MHz gesampled. Um auf die ermittelte Baudrate und eine reale Darstellung zu kommen, gebe ich 402 Samples/Symbol (Symbol=bit) ein.

	Das Ergebnis:		Das Ergebnis:
Zeile 371:		Zeile 371:

	=== Codesequenzen ===		=== Codesequenzen ===
	Die Interpretaion des low und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise ~~anderes~~ interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.		Die Interpretaion des low- und high-Zustandes hängt von der Sende- und Empfangsfrequenz ab. Wenn Ihr im OOK-Modus Sequenzen mitgeschnitten habt werden die möglicherweise anders interpretiert als die mittels FSK empfangenen. Deshalb: Sequenzen mit der Original-Fernbedienung neu erzeugen und mitschneiden. Achtet dabei darauf, dass diese lang genug sind, um das komplette Steuerungssignal mitzuschneiden. Die Preamble ist recht auffällig (bei mir 01232323 ...). Die wiederholt sich nach dem eigentlichen Steuerungssignal. Ab hier könnt Ihr also abschneiden. Ferner empfiehlt sich, das mitgeschnittene Signal zu dekodieren und in Hex darzustellen. Dann erkennt Ihr, ob identische Inhalte/Sequenzen mitgeschnitten wurden. Das trennt die Spreu vom Weizen.

	Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.		Damit konnte ich mein Problem meines unbekannten Funkprotokolls (RIO-Fernbedienung) letztendlich lösen.
Zeile 465:		Zeile 465:
	2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2		2020.01.12 14:33:04 5: mySIGNALduino: Parse_MS, Starting demodulation at Position 2
	</pre>		</pre>
	und routet die ~~Request~~ an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.		und routet die Requests an das Modul SD_Keeloq weiter. Der Hinweis auf HCS301 führt auf die richtige Spur. Das analysierte Protokoll KeeLoq ist im Data Sheet des Microchip HCS301 (KeeLoq Code Hopping Encoder) beschrieben. Somit wurde aus einem unbekannten Funkprotokoll letztlich ein bekanntes.

	Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.		Mittlerweile ist das Protokoll als '''model enjoy_motors_HS''' in das Modul '''SD_Keeloq''' aufgenommen.
Zeile 481:		Zeile 481:
	Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.		Diese Begriffe kommen nur bei der Manchester Codierung zum Einsatz.

	Die Bestimmung short High / Low erfolgt einfach dadurch ob gesendet wird oder ob gerade eine Pause eingelegt wird.		Die Bestimmung short High / Low erfolgt einfach dadurch, ob gesendet wird oder ob gerade eine Pause eingelegt wird.

	Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.		Short und Long wird einfach durch die Kalkulation der Dauer ermittelt.