Signalduino Version 3.3.1 / 3.3.2 / 3.3.3-dev

[Ralf9]

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.

Dank Deinem log habe ich noch einen Fehler gefunden. In der cc1101.h  war die Arraygrösse vom PatableArray zu klein.

Bei den aktuelleren Arduino IDE gibt es mehr Fehler- und Plausibilitätsprüfungen.
Bei meinen Homematic wired Selbstbaumodulen habe ich mal versucht eine aktuellere Arduino IDE zu verwenden, habe aber dann die warnings und errors nicht wegbekommen.

Gruß Ralf

[pejonp]

Hallo Sidey,

ich habe mal beim CC1101 ein Paar  Anpassungen durchgeführt so das er 2-FSK empfangen kann. Ich empfange jetzt auch etwas. Ich hoffe das sind meine Sensoren. Wie kann ich aus den Daten die Hex-Nachrichten machen. Als Anlage noch der Aufbau der Sensornachrichten. Vielen Dank.

Code Auswählen Erweitern


Using sFIFO
Reading values fom eeprom
CCInit
CCVersion=20
CCPartnum=0
Starting timerjob
receiver enabled
MU;P0=107;P1=-94;P2=310;P3=-191;D=0101010101010101010101010101012103230101210323010;CP=0;R=227;
V 3.3.1-dev SIGNALduino cc1101 - compiled at Jan  8 2017 16:43:33
ccreg 00: 0D 2E 2D 02 00 00 3D 04 32 00 00 06 00 21 65 6A  ccreg 10: 89 5C 06 23 B9 56 07 00 18 14 6C 07 00 90 87 6B  ccreg 20: F8 56 11 EF 2C 19 1F 41 00 59 7F 07 88 31 0B
ccFactoryReset done
ccreg 00: 0D 2E 2D 02 00 00 3D 04 32 00 00 06 00 21 65 6A  ccreg 10: 89 5C 06 23 B9 56 07 00 18 14 6C 07 00 90 87 6B  ccreg 20: F8 56 11 EF 2C 1A 1F 41 00 59 7F 3F 88 31 0B
MU;P0=-212;P1=203;P2=-311;P3=104;P4=-108;P5=312;P6=-496;D=012343434343434343234145434323432303634361652163417;CP=3;R=225;
MU;P0=-348;P1=105;P2=-103;P3=208;P4=312;P5=-208;P7=-524;D=012121212121212101232421210121015101210374037123;CP=1;R=225;
MU;P0=-341;P1=106;P2=-101;P4=210;P5=316;P6=-572;P7=-896;D=01212121212121210124252121012101612121056101240421217;CP=1;R=225;
MU;P0=-481;P1=107;P2=-102;P3=-312;P4=211;P5=320;P6=-212;P7=-876;D=0121212121212121312425212131213161012104040401242171;CP=1;R=225;
MC;LL=-340;LH=456;SL=-108;SH=205;D=AAAA8E;C=270;L=23;R=225;
MU;P0=456;P1=-116;P2=-340;P3=205;P4=315;P6=-198;P7=-1048;D=40101216101030101610101236401710173616301210403610061136061;CP=0;R=225;
MU;P0=-311;P1=102;P2=-107;P3=207;P4=316;P5=-212;P6=-498;D=012121212121212101232421210121015161216364036123;CP=1;R=225;
MU;P0=-314;P1=103;P2=-103;P3=211;P4=312;P5=-209;P6=-472;D=01212121212121210123242121012101516121636403515121237;CP=1;R=225;
MU;P0=-330;P1=110;P2=-102;P3=212;P4=314;P5=-572;P7=-964;D=0121212121212121012324212101210151212104510123032121712;CP=1;R=225;
MU;P0=442;P1=-104;P2=-338;P3=209;P4=312;P6=-203;P7=-1044;D=0101010101010101210304010121610103010161010123640171017361630161640361006113201;CP=0;R=225;
MU;P0=355;P1=106;P2=-102;P3=-313;P4=207;P6=-210;P7=-1042;D=161212421216121213460217121746164216160246120612430;CP=1;R=225;
MU;P0=386;P1=-102;P2=-361;P3=207;P6=-210;P7=-1152;D=0101010101010101210300010121610103010161010123012170730021212113202310;CP=0;R=225;
MU;P0=-328;P1=107;P2=-101;P3=212;P4=318;P5=-572;P7=-900;D=01212121212121210123242121012101512121045101230321217;CP=1;R=225;
MU;P0=364;P1=101;P2=-119;P3=206;P5=-419;P6=-212;P7=-1150;D=01212121212121210123202121516121232121612121032151707063532151230053202;CP=1;R=225;
MU;P0=-332;P1=104;P2=-105;P3=208;P4=314;P5=-570;P7=-900;D=01212121212121210123242121012101512121045101230321217;CP=1;R=225;
ccreg 00: 0D 2E 2D 02 00 00 3D 04 32 00 00 06 00 21 65 6A  ccreg 10: 89 5C 06 23 B9 56 07 00 18 14 6C 07 00 90 87 6B  ccreg 20: F8 56 11 EF 2C 1A 1F 41 00 59 7F 3F 88 31 0B
MU;P0=-546;P1=106;P2=-100;P3=-329;P4=212;P5=314;D=0121212121212121312425212131213101212135013124342121;CP=1;R=225;
MU;P0=-501;P1=100;P2=-107;P3=-314;P4=208;P5=312;P6=-208;P7=-1088;D=0121212121212121312425212131213161012104053401247;CP=1;R=225;



Jörg

[Ralf9]

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.

Ich habe es mal in die 00_SIGNALduino.pm eingebaut.
Wenn in der ProtocolListSIGNALduino frequency definiert ist, dann wird diese verwendet,
wenn aber die Sendeparameter mit sendmsg (z.B. #F10aa56) übergeben werden, dann werden diese verwendet.

Beim IT Modul macht es Sinn die Frequenz pro device zu hinterlegen, wie es bereits schon bein CUL gemacht wird.
Ich habe es mal bei mir eingebaut, es sieht dann so aus:

Code Auswählen Erweitern

2017.01.08 18:58:52.945 2: sduinoE IT_set: Lampe1 on
2017.01.08 18:58:52.948 3: sduinoE IT_set: Setting ITfrequency (0D,0E,0F) to 10 aa 56 = 433.300 MHz
2017.01.08 18:58:52.948 5: sduinoE/write: adding to queue sendMsg P3#F0F000FFFF0F#R6#C280#F10aa56
2017.01.08 18:58:52.948 5: sduinoE: sendmsg IT V1 convertet tristate to bits=010001000000010101010001
2017.01.08 18:58:52.948 5: sduinoE: sendmsg Preparing rawsend command for protocol=3, repeats=6, clock=280 bits=010001000000010101010001
2017.01.08 18:58:52.948 4: sduinoE/set: sending via SendMsg: SR;R=6;P0=280;P1=-8680;P2=840;P3=-280;P4=-840;D=01042304040423040404040404042304230423042304040423;F=F10aa56;

Gruß Ralf

[Sidey]

ich habe mal beim CC1101 ein Paar  Anpassungen durchgeführt so das er 2-FSK empfangen kann. Ich empfange jetzt auch etwas. Ich hoffe das sind meine Sensoren. Wie kann ich aus den Daten die Hex-Nachrichten machen. Als Anlage noch der Aufbau der Sensornachrichten. Vielen Dank.

Wir müssten erst mal eruieren wie eine 2-FSK Modulation aussieht und wie man diese demoduliert.
Mir ist das jetzt nicht so klar.

Ich habe es mal in die 00_SIGNALduino.pm eingebaut.
Wenn in der ProtocolListSIGNALduino frequency definiert ist, dann wird diese verwendet,
wenn aber die Sendeparameter mit sendmsg (z.B. #F10aa56) übergeben werden, dann werden diese verwendet.

Das gefällt mir

Beim IT Modul macht es Sinn die Frequenz pro device zu hinterlegen, wie es bereits schon bein CUL gemacht wird.
Ich habe es mal bei mir eingebaut, es sieht dann so aus:

Die Attribute gibt es, allerdings fehlt mir gerade eine Idee, warum man das pro IT Gerät einzeln machen soll.
Auf jeden Fall sollten wir noch mal überlegen, ob wir vor jedem Sendebefehl die Frequenz setzen oder ob wir die nach dem Senden auf einen Standard zurück setzen.

Mir ist die Tage auch bewusst geworden, dass das Protokoll #3 eigentlich nicht das IT Protokoll darstellt, sondern einen PT2262 demodulator.
Wir haben da ein paar Besonderheiten eingebaut, um mit dem IT Modul klar zu kommen, die ich mittlerweile nicht mehr so gut finde.

Zwei Anwender haben eine Leinwand von eSmart. Das Protokoll ist nicht Interntechno kompatibel, macht auch nix.
Ich dachte mir, wenn die Bitfolge "111101011001101000000010" empfangen wird, dann kann das einfach mittels sendMsg P3#111101011001101000000010#R6#C210 gesendet werden. So habe ich es auch in der Commandref behauptet. Für das Protokoll #3 stimmt dies leider nicht, gesendet werden muss "11FFDFDD000D", wegen dieser Tristate Umandlung.

Ein normaler Anwender kommt da ja nicht drauf und ich hatte es auch vergessen.
Können wir die Umwandlung der Bits nicht in das IT Modul verlagern?

In der cc1101.h  war die Arraygrösse vom PatableArray zu klein.

Wozu brauchen wir überhaupt einen reservierten Speicher für PatableArray .
So wie ich das sehe, wird die PATable im Register gespeichert. Wir haben jetzt folgendes:

8 Byte im Flash für den Standard
8 Byte im RAM für temporäre Ausgaben?
8 Byte in den CC1101 Registern
8 Byte im EEProm

Im besten Fall stehen immer identische Werte im Speicher.
Brauchen wir dieses Array denn dauerhaft oder können wir es nicht einfach aus den Registern auslesen, wenn es mal benötigt wird?

Grüße Sidey

[Ralf9]

Die Attribute gibt es, allerdings fehlt mir gerade eine Idee, warum man das pro IT Gerät einzeln machen soll.
Auf jeden Fall sollten wir noch mal überlegen, ob wir vor jedem Sendebefehl die Frequenz setzen oder ob wir die nach dem Senden auf einen Standard zurück setzen.

Es ist pro IT Gerät notwendig, da nur bei ein paar wenigen IT Geräten die Frequenz geändert werden muß.
Es muß nur dann vor dem Senden die Frequenz geändert werden, wenn auch per "F=xxxx" eine Frequenz übergeben wurde.
Nach dem Senden auf einen Standard zurücksetzen finde ich nicht so gut. Wenn ich bei mir die Frequenz und Bandbreite geändert habe, möchte ich nicht, daß sie nach dem Senden wieder auf Standart zurück gesetzt wird.

Das mit der Datenrate ist mir nicht so recht klar, welchen Vorteil bringt es wenn wie z.B. bei Somfy beim Senden die Datenrate heruntergesetzt wird.
Ich hab nicht nachgeschaut ob die Datenrate überhaupt zum Senden verwendet wird.

Mir ist die Tage auch bewusst geworden, dass das Protokoll #3 eigentlich nicht das IT Protokoll darstellt, sondern einen PT2262 demodulator.
Können wir die Umwandlung der Bits nicht in das IT Modul verlagern?

Ich finde das verlagern ins IT Modul würde unnötig Kompatibilitäts- und Fehlerquellen geben, wenn die Versionen nicht zusammenpassen. 
Es müsste auch reichen, wenn wir in der sendmsg Routine beim Protokoll #3 eine Abfrage einbauen, daß bei einer Datenlänge größer 19 und nur 1en und 0en keine Umwandlung durchgeführt wird.

Wozu brauchen wir überhaupt einen reservierten Speicher für PatableArray .
Brauchen wir dieses Array denn dauerhaft oder können wir es nicht einfach aus den Registern auslesen, wenn es mal benötigt wird?

Ja, es müsste auch ohne dauerhaftes Array gehen.
Z.B. so:

Code Auswählen Erweitern

void writeCCpatable(uint8_t var) {           // write 8 byte to patable (kein pa ramping)
for (uint8_t i = 0; i < 8; i++) {
if (i == 1) {
EEPROM.write(EE_CC1100_PA + i, var);
} else {
EEPROM.write(EE_CC1100_PA + i, 0);
}
}
writePatable();
}

void writePatable(void) {
cc1101_Select();                                // select CC1101
wait_Miso();                                    // wait until MISO goes low
sendSPI(CC1100_PATABLE | CC1100_WRITE_BURST);   // send register address
for (uint8_t i = 0; i < 8; i++) {
sendSPI(EEPROM.read(EE_CC1100_PA));                     // send value
}
cc1101_Deselect();
}


Beim readPatable wird das Multibyte Register per readburst gelesen, da bin ich mir nicht sicher ob es timing mässig passt, wenn es nach jedem sendSPI(0x00) eine kurze Pause beim msgprint gibt.

Gruß Ralf

[Harst]

Hallo,

vor kurzem kam eine allgemeine Anfrage zu den Olympia Fensterkontakten. Ich habe auch solche und mal mitgeschnitten.

https://forum.fhem.de/index.php/topic,60404.msg558111.html#msg558111

ist solch ein Protokoll mit dem Signalduino zu machen?
Ich habe einen 868-SDuino laufen und er meldet zumindest den Empfang, bricht aber wohl wegen der Präambel ab.

Horst

[stefanru]

Hi Ralf,

kurze Frage.
Ich habe hier Steckdosen vom Lidl. Sind wohl Brennstuhl.
Zur Zeit steuere ich sie über einen 433Mhz sender am Rapberry an PGIO.
Das tool ist:
"/home/pi/433Utils/RPi_utils/codesend 4294560 4"

Der sduino erkennt diese Sendungen, aber nur mit Help me!
Hier mal ein Auszug:
sending code[5821218]
2017.01.12 00:09:01 3: sduino: Unknown code u26#A72CDD, help me!
sending code[4780364]
2017.01.12 00:10:04 3: sduino: Unknown code u26#B70EB3, help me!
sending code[4294562]
2017.01.12 00:11:55 3: sduino: Unknown code u26#BE785D, help me!
sending code[4679092]
sending code[5821218]
2017.01.12 00:14:01 3: sduino: Unknown code u26#B89A4B, help me!
2017.01.12 00:14:02 3: sduino: Unknown code u26#A72CDD, help me!
sending code[4780364]
2017.01.12 00:16:04 3: sduino: Unknown code u26#B70EB3, help me!

Kann  ich das über einen raw befehl mit sduino senden?
Fände es toll wenn ich die Krücke über den Raspberry los werden könnte.

Viele Grüße,
Stefan

[Sidey]

Zum Thema 868 MHz FSK gibt es seit ein paar Tagen erste Überlegungen.

Prinzipiell sollte das machbar sein, aber hierfür sind noch ein paar Grundkenntnisse in der FSK Demodulation notwendig.

Zum Thema der Lidl Steckdosen.
Ich wüsste nicht, warum der Signalduino das nicht verarbeiten sollte.

Du müsstest dazu mal in einem neuen Beitrag die Signaldaten (Verbose 4) posten.

Grüße Sidey

[stefanru]

Perfekt, mache ich.
Danke Sidey!

Gruß,
Stefan

[rin67630]

Weiteres ergibt sich vermutlich noch.

Grüße Sidey

Hallo,
den Signalduino habe ich mit der in der Anleitung beschriebene Hardware aufgebaut.
Das Problem ist, dass der vorgeschlagene Receiver ziemlich unselektiv ist und munter ein Störsignal, der bei 424,23MHz liegt mit aufnimmt.

Kennt jemand ein solches Signal? Es sendet ununterbrochen Pulsmoduliertes mit einem Raster von 100ms, viel zu langsam, um Audio zu sein...

Es scheint die Signalduino Firmware durcheinander zu bringen, so dass das Signalduino sich schließt und aufhört zu funktionieren.
Ich glaube, man sollte schon ein besseren Receiver einbauen. Ist jetzt bestellt.

Habt Ihr auch Ähnliches erlebt?

[juergs]

Ja, Powerline sendet auf 443 MHz.

Jürgen

[rin67630]

Man sollte allerdings keinesfalls die billigen chinesischen Receiver-Module im Signal-Duino einbauen!

Ich glaube damit holt man sich viel zu viel Schrott von benachbarter Frequenzen und es dürfte auch der Grund sein, warum so viele "Fremdprotokolle" registriert werden.
Sehe ich das richtig?

Ich habe jetzt eine Weile mit SDR# gespielt, und es ist ziemlich Wahnsinn, was alles sich links und rechts um die 433,9 MHz herum dümpelt.
Also wer nicht gerade auf dem Bauernhof in Niederkleinöd wohnt, sollte sich unbedingt ein gescheiten Receiver-Modul zulegen, bevor es sich mit Fremdprotokolle herum ärgert.

[Ralf9]

Man sollte allerdings keinesfalls die billigen chinesischen Receiver-Module im Signal-Duino einbauen!

Kennst Du einen besseren Superheterodyne Empfänger als den RXB6 2.0?

Wenn Du den CC1101 verwendest kannst Du eine Bandbreite von 58 - 812 kHz einstellen.

Gruß Ralf

[rin67630]

Ich hatte erstmals mit dem billigen Set Sender-Receiver, der beim FHEM-Duino beschrieben war, angefangen.
Der Superhet Receiver ist bestellt.

Ich hatte die Beschreibung aus https://wiki.fhem.de/wiki/Datei:Fhemduino_schematic.png verwendet.

Wie wäre die Schaltung des CC1101 für ein SignalDuino?
Meintest Du ein CUL mit CC1101 und den CUL-Code?

Oder geht die SignalDuino Firmware auch auf ein  CUL mit CC1101?

Sorry für die viele Fragen.

[Ralf9]

Oder geht die SignalDuino Firmware auch auf ein  CUL mit CC1101?

Die SignalDuino CC1101 Firmware funktioniert auf dem Selbstbau Cul
https://wiki.fhem.de/wiki/Selbstbau_CUL#Schaltplan

https://forum.fhem.de/index.php/topic,58396.msg560502.html#msg560502

Gruß Ralf