Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[Sidey]

versuche mal ein set cc1101_patable

So ich habe nun ein bisschen experimentiert.

Der Befehl C3E lieferte eine komische PA Table. Da stimmte etwas nicht.

Ich habe mit x85 eine neue gesetzt, auch wenn ich der Meinung bin, dass x81 die richtige wäre.

Code Auswählen Erweitern

C3E = 00 85 00 00 00 00 00 00

Meine Codeänderungen habe ich temporär rückgängig gemacht und auch damit klappt das Senden.


Einzig was mich verwundert, nach jedem C oder X Kommando muss man den arduino resetten, da sonst unknown command erscheint.
Woran das liegt, habe ich aber noch nicht rausbekommen.

Code Auswählen Erweitern

2017.01.08 01:01:39.478 1: ERROR: >Somfy RTS checksum error!< returned by the SOMFY ParseFn is invalid, notify the module maintainer
2017.01.08 01:01:39.466 5: sduino_rxb8: dispatch YsAFE8E8C7E99C98
2017.01.08 01:01:39.459 5: sduino_rxb8: converted Data to (YsAFE8E8C7E99C98)
2017.01.08 01:01:39.455 5: sduino_rxb8: extracted data 10101111111010001110100011000111111010011001110010011000 (bin)
2017.01.08 01:01:39.452 4: sduino_rxb8: Found manchester Protocol id 43 clock 638 -> Somfy RTS
2017.01.08 01:01:39.446 4: sduino_rxb8/msg READ: MC;LL=-1293;LH=1262;SL=-656;SH=620;D=AFE8E8C7E99C98;C=638;L=55;
2017.01.08 01:01:39.110 4: sduino SendFromQueue: msg=SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AFE8E8C7E99C99;
2017.01.08 01:01:38.917 4: set sduino raw SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=AFE8E8C7E99C99;


Der CRC Error kommt wohl daher, dass das letzte Bit nicht irentifiziert werden kann, da das Signal nicht sauber abgeschlossen wird und mit dem Start der Preamble der Folgenden Wiederholung kollidiert.

Mit der Version

Code Auswählen Erweitern

V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 2 2017 01:32:22 Klappt es bei mir auch nicht, obwohl da keine Änderungen zur aktuellen auf github enthalten sind.

[pataya]

Langsam wird's unverständlich für mich

Hier meine Ausgabe falls das noch was bringt:

Code Auswählen Erweitern

2017.01.08 00:57:52 3: sduinoCC: Setting patable -10_dBm x34
2017.01.08 00:57:52 5: sduinoCC SW: x34
2017.01.08 00:57:53 4: sduinoCC/msg READ: Write 34 to PATABLE done
2017.01.08 00:57:53 5: sduinoCC SW: WS36
2017.01.08 00:57:53 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:57:53 5: sduinoCC SW: WS34
2017.01.08 00:57:53 4: sduinoCC/msg READ: Unsupported command

2017.01.08 00:58:46 3: sduinoCC: Setting patable -5_dBm x68
2017.01.08 00:58:47 5: sduinoCC SW: x68
2017.01.08 00:58:47 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:58:47 5: sduinoCC SW: WS36
2017.01.08 00:58:47 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:58:47 5: sduinoCC SW: WS34
2017.01.08 00:58:47 4: sduinoCC/msg READ: Unsupported command

2017.01.08 00:58:53 3: sduinoCC: Setting patable 0_dBm x60
2017.01.08 00:58:54 5: sduinoCC SW: x60
2017.01.08 00:58:54 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:58:54 5: sduinoCC SW: WS36
2017.01.08 00:58:54 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:58:54 5: sduinoCC SW: WS34
2017.01.08 00:58:54 4: sduinoCC/msg READ: Unsupported command

2017.01.08 00:59:01 3: sduinoCC: Setting patable 5_dBm x84
2017.01.08 00:59:01 5: sduinoCC SW: x84
2017.01.08 00:59:01 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:02 5: sduinoCC SW: WS36
2017.01.08 00:59:02 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:02 5: sduinoCC SW: WS34
2017.01.08 00:59:02 4: sduinoCC/msg READ: Unsupported command

2017.01.08 00:59:08 3: sduinoCC: Setting patable 7_dBm xC8
2017.01.08 00:59:08 5: sduinoCC SW: xC8
2017.01.08 00:59:08 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:08 5: sduinoCC SW: WS36
2017.01.08 00:59:08 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:08 5: sduinoCC SW: WS34
2017.01.08 00:59:08 4: sduinoCC/msg READ: Unsupported command

2017.01.08 00:59:14 3: sduinoCC: Setting patable 10_dBm xC0
2017.01.08 00:59:14 5: sduinoCC SW: xC0
2017.01.08 00:59:14 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:14 5: sduinoCC SW: WS36
2017.01.08 00:59:14 4: sduinoCC/msg READ: Unsupported command
2017.01.08 00:59:15 5: sduinoCC SW: WS34
2017.01.08 00:59:15 4: sduinoCC/msg READ: Unsupported command

Habs danach auch jeweils probiert was zu senden aber nichts empfangen.
Sowohl bei der offiziellen als der kompilierten Firmware.

@Ralf, kannst du mir deine hexfile zum Testen zur Verfügung stellen?

[Ralf9]

@Ralf, kannst du mir deine hexfile zum Testen zur Verfügung stellen?

Hab gar nicht gewusst, daß ich mit der Arduino IDE auch ein hex File erzeugen kann

Code Auswählen Erweitern

version: V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan 8 2017 01:40:34

Gruß Ralf

[pataya]

Tatsächlich funktioniert's damit auch bei mir...
Du benutzt auch die aktuelle GitHub Version und Arduino IDE unter OpenSuse (hab ich gelesen)?
Wenn ja würde ich mal ne OpenSuse-VM fertig machen und damit testen.

[Ralf9]

kann der Somfy damit was anfangen?

[pataya]

Der RXB6-sduino legt zumindest SOMFY Geräte an.
Die Hardware steht im Haus meiner Eltern und möchte sie jetzt ungerne durch hochfahrende Rollläden wecken
Mach ich dann später.

[pataya]

So, weiter getestet und teilweise spannende Sachen herausgefunden...

Die hexfile die auf dem Windowssystem kompiliert wurde funktioniert nach wie vor nicht.
Habe die Selben Dateien auf OSX kompiliert, damit geht's (gleiche Ergebnis wie mit der hexfile von Ralf).

Die Somfy Geräte reagieren trotzdem nicht. ABER: mit einer manuellen Frequenzanpassung auf 433,42 MHz (die auch die culfw verwendet, danke Ralf) lassen sich die Rollläden steuern!

Einen ELRO Zwischenstecker habe ich zum Testen noch mal eingebunden. Das Einschalten funktioniert auf Anhieb, das Ausschalten braucht mehrere Versuche bis er reagiert.
Die Anhebung der Bandreite hilft in dem Fall auch nicht.

[habeIchVergessen]

Welche Version der IDE verwendest du unter dem jeweiligen OS?

[pataya]

jeweils die 1.8.0

[Ralf9]

ich denke, das könnte auch noch ein Timing Problem sein.
Ich verwende noch die etwas ältere Arduino IDE 1.6.5
Zwischen dem enable TX und dem Senden muß wahrscheinlich noch ein delay eingebaut werden. Beim senden werden die ersten paar Wiederholungen nicht sauber empfangen.

Beim Senden der ELRO kann es evtl was bringen, wenn die ITRepition etwas erhöht wird. Evtl passt die Frequenz auch nicht ganz.
Ich bin mir nicht sicher ob sich das Erhöhen der Bandbreite auch auf das Senden auswirkt.

Ich habe schon angefangen das Auswerten des F=10AB85550A in die Firmware einzubauen, das Schreiben in die Register ist aber noch auskommentiert

set raw SR;R=7;P0=-334;P1=709;P2=-152;P3=-663;P4=379;P5=-15226;D=5401013401013;F=10AB85550A;

Code Auswählen Erweitern

write new ccreg  10AB85550A
ccreg write back 10B07157C4
SR;R=7;P0=-334;P1=709;P2=-152;P3=-663;P4=379;P5=-15226;D=5401013401013;F=10AB85550A;

Gruß Ralf

[habeIchVergessen]

ich nutze die 1.6.6 für Arduino und 1.6.5 für den ESP8266 unter Windows.

[Harst]

Als alter Amateurfunker möchte ich einwerfen:

Beim Senden sollte die Bandbreite egal sein. Da wird halt eine (Sinus-)Welle erzeugt. Beim Empfang wird die Bandbreite durch die Filter bestimmt und die kann man steuern.

Horst

[habeIchVergessen]

Code Auswählen Erweitern


2017.01.06 18:52:54.491 4 : set sduinoE raw SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECEC1ACA9D44;


Eigentlich sollte das msgOutro auch genutzt werden, da es eine Protokoll-Erweiterung gibt, die in der langen Pause gesendet wird (z.B. für die Lamellen-Neigung).

Code Auswählen Erweitern


Definition Protokoll 43 in 00_SIGNALdunio.pm
msgOutro               => 'SR;P0=-2560;D=00000000000;'


Nachricht würde dann so aussehen:

Code Auswählen Erweitern


SC;R=6;SR;P0=-2560;P1=2560;P3=-640;D=10101010101010113;SM;C=640;D=A0ECEC1ACA9D44;SR;P0=-2560;D=00000000000;


[pataya]

Okay, unter Windows mit 1.6.5 kompiliert funzt auch.
Kriege mit 1.8.0 auch ein paar Fehlermeldungen beim kompilieren. Aber nur unter Windows. Siehe Anhang.
Aber funktioniert ja jetzt quasi.

Werde als Workaround erst mal die Frequenz anpassen. Brauche eh nur Somfy.

Vielen Dank an euch für die Zeit!

Gruß

[Sidey]

ich denke, das könnte auch noch ein Timing Problem sein.
Ich verwende noch die etwas ältere Arduino IDE 1.6.5
Zwischen dem enable TX und dem Senden muß wahrscheinlich noch ein delay eingebaut werden. Beim senden werden die ersten paar Wiederholungen nicht sauber empfangen.

Das habe ich gestern eingebaut, zumindest wird jetzt mit dem senden gewartet, bis das Status Register auf tx steht.

Um das Thema mit den Sendeparametern anzugehen, könnten wir in jedem Protokoll die passenden Register hinterlegen. Das in die logischen Module zu verlagern halte ich für zu kompliziert.


Bezüglich der Firmware, werde ich einfach mal eine neue compilieren. Irgendwas stimmt da ja nicht.

Gruß sidey

Gesendet von meinem SM-T580 mit Tapatalk