Signalduino Entwicklung

Sidey · 14 Mai 2016, 16:10:32

Ich weiss nicht genau was Du mit Sync meinst.
Auf ein Manchester Signal kann man sich immer dann synchen, wenn eine Puls 2* Takt Länge gefunden wird.
Ob der nun low oder high ist, spielt keine Rolle.
Die Variante nach IEEE oder G.E. Thomas kann man im Signal selbst nicht unterscheiden.
Das müssen Sender und Empfänger auf anderen Weg untereinander ausmachen.

Zumindest ist das mein Stand. Ich nehme einfach an, es wird nach IEEE übertragen. Ist das nicht so, muss man invertieren.

Ich gehe auch mal stark davon aus, dass SOMFY nach IEEE überträgt.

Ellert · 14 Mai 2016, 16:29:59

Zitat von: habeIchVergessen am 14 Mai 2016, 11:07:58
diese hier bitte
https://github.com/viegener/Telegram-fhem/raw/master/Somfy/10_SOMFY.pm

die auch noch
https://github.com/habeIchVergessen/RFFHEM/raw/dev-r32/FHEM/00_SIGNALduino.pm

Wenn ich über einen nanoCUL sende, werden durch meine beiden SIGNALduino auf unterschiedlichen RasPi SOMFY Geräte angelegt.

ZitatnanoCUL RAWMSG: YsA31600039C3812

Zitat2016.05.14 16:03:48 4: SD_433/msg READ: MC;LL=-1288;LH=1286;SL=-685;SH=683;D=5B4D4D49D5EDFF;C=656;L=56;
2016.05.14 16:03:48 4: SD_433: Found manchester Protocol id 43 clock 656 -> Somfy RTS
2016.05.14 16:03:49 4: SD_433: Somfy RTS preprocessing check: 6 enc: A4B2B2B62A1200 dec: A41600049C3812
2016.05.14 16:03:49 1: SOMFY Unknown device 12389C, please define it
2016.05.14 16:03:49 2: autocreate: define SOMFY_12389C SOMFY 12389C
2016.05.14 16:03:49 2: autocreate: define FileLog_SOMFY_12389C FileLog ./log/SOMFY_12389C-%Y.log SOMFY_12389C

und

Zitat2016.05.14 16:03:47 4: SDuino_433/msg READ: MC;LL=-1286;LH=1292;SL=-686;SH=678;D=5B4D4D49D5EDFF;C=656;L=56;
2016.05.14 16:03:47 4: SDuino_433: Found manchester Protocol id 43 clock 656 -> Somfy RTS
2016.05.14 16:03:48 4: SDuino_433: Somfy RTS preprocessing check: 6 enc: A4B2B2B62A1200 dec: A41600049C3812
2016.05.14 16:03:48 1: SOMFY Unknown device 12389C, please define it
2016.05.14 16:03:48 2: autocreate: define SOMFY_12389C SOMFY 12389C
2016.05.14 16:03:48 2: autocreate: define FileLog_SOMFY_12389C FileLog ./log/SOMFY_12389C-%Y.log SOMFY_12389C
2016.05.14 16:03:48 4: SDuino_433/msg READ: MC;LL=-1282;LH=1291;SL=-689;SH=679;D=5B4D4D49D5EDFF;C=656;L=56;
2016.05.14 16:03:48 4: SDuino_433: Found manchester Protocol id 43 clock 656 -> Somfy RTS
2016.05.14 16:03:48 4: SDuino_433: Dropped (YsA4B2B2B62A1200) due to short time or equal msg
2016.05.14 16:03:48 4: SDuino_433/msg READ: MC;LL=-1286;LH=1289;SL=-683;SH=681;D=5B4D4D49D5EDFF;C=656;L=56;
2016.05.14 16:03:48 4: SDuino_433: Found manchester Protocol id 43 clock 656 -> Somfy RTS
2016.05.14 16:03:48 4: SDuino_433: Dropped (YsA4B2B2B62A1200) due to short time or equal msg
2016.05.14 16:03:48 4: SDuino_433/msg READ: MC;LL=-1285;LH=1293;SL=-686;SH=678;D=5B4D4D49D5EDFF;C=656;L=56;
2016.05.14 16:03:48 4: SDuino_433: Found manchester Protocol id 43 clock 656 -> Somfy RTS
2016.05.14 16:03:48 4: SDuino_433: Dropped (YsA4B2B2B62A1200) due to short time or equal msg

Wenn ich über die angelegten Geräte sende, wird das vom jeweils anderen Gerät nicht registriert.

Zitat2016.05.14 16:17:57 4: SDuino_433/set: sending via SendMsg: SM;R=6;C=660;D=A1B7B7B62A1200
2016.05.14 16:17:57 4: SDuino_433/msg READ: SM;R=6;C=660;D=A1B7B7B62A1200

Kein Empfang auf dem Gegenstück, keine Logeinträge trotz debug 1

Zitat2016.05.14 16:22:08 1: PERL WARNING: Argument "go-my" isn't numeric in addition (+) at ./FHEM/10_SOMFY.pm line 1045.
2016.05.14 16:22:08 4: SD_433/set: sending via SendMsg: SM;R=6;C=660;D=A1B7B7B62A1200
2016.05.14 16:22:08 4: SD_433/msg READ: SM;R=6;C=660;D=A1B7B7B62A1200

Kein Empfang auf dem Gegenstück, keine Logeinträge trotz debug 1

Sidey · 14 Mai 2016, 17:12:33

Zusammengefasst erkennt der Signalduino nicht, was über einen Signalduino gesendet wird?

Ellert · 14 Mai 2016, 17:50:14

Zitat von: Sidey am 14 Mai 2016, 17:12:33
Zusammengefasst erkennt der Signalduino nicht, was über einen Signalduino gesendet wird?

Ja, aber auch der Somfy-Handsender und der RFXTRX433E wird nicht empfangen, das klapt nur wenn der CUL sendet.

Sidey · 14 Mai 2016, 19:08:16

Schick mal ein verbose 5 Log, wenn der Wandsender sendet und dann noch mal eines wenn der rfxtrx sendet.
Da muss ja wohl ein Unterschied sein.

Ellert · 14 Mai 2016, 19:26:15

Zitat von: Sidey am 14 Mai 2016, 19:08:16
Schick mal ein verbose 5 Log, wenn der Wandsender sendet und dann noch mal eines wenn der rfxtrx sendet.
Da muss ja wohl ein Unterschied sein.

Ich habe mit dem Logikanalysator drei Varianten aufgezeichnet, ich hoffe das hilft.
In den nächten Tagen kann ich keine Test durchführen.

Bis dann
Ellert

habeIchVergessen · 15 Mai 2016, 03:43:21

@Sidey: clock ist die Zeit, die für die Übertragung pro Bit anfällt? Die Flanke muss also bei clock/2 sein?

Sidey · 15 Mai 2016, 09:29:23

Clock ist der Takt, mit dem moduliert wird.

Ich habe mir gestern noch den sende Code angesehen.
Der stimmt so nicht. Ich verstehe nicht warum, denn es hat den schon mal wer verwendet.

Ich werde das überarbeiten. War da jetzt gestern schon dran, bin da aber insgesamt noch am verifizieren.

Vielleicht habe ich beim Empfang auch doch noch einen Bug und das, das Signal invertiert ausgewertet wird.

Grüße Sidey

habeIchVergessen · 15 Mai 2016, 16:41:30

@Sidey: ich habe somfy_rts.c (culfw) nochmals durchgesehen (s.u.). Was sofort auffällt ist, dass clock 620 sein muss.
Auch das

Hardware-Snyc (High-Low; clock 2550,2550; Wiederholungen: 2 - 1. senden / 7 - weiteres senden)
Software-Sync (High-Low; clock 4860,620)

gibt es so in send_mc und den Parametern nicht.

Auszug somfy_rts.c
uint8_t somfy_rts_repetition = 6;
uint16_t somfy_rts_interval = 1240; // symbol width in us -> ca. 828 Hz data rate
uint16_t somfy_rts_interval_half = 620;

// IEEE 802.3 logical 0 high to low
static void send_somfy_rts_bitZero(void) {
   // Somfy RTS bits are manchester encoded: 0 = high->low
   CC1100_OUT_PORT |= _BV(CC1100_OUT_PIN);            // High
   my_delay_us(somfy_rts_interval_half);                              // somfy_rts_interval_half = 620
   CC1100_OUT_PORT &= ~_BV(CC1100_OUT_PIN);      // Low
   my_delay_us(somfy_rts_interval_half);                              // somfy_rts_interval_half = 620
}

// IEEE 802.3 logical 1 low to high
static void send_somfy_rts_bitOne(void) {
   // Somfy RTS bits are manchester encoded: 1 = low->high
   CC1100_OUT_PORT &= ~_BV(CC1100_OUT_PIN);         // Low
   my_delay_us(somfy_rts_interval_half);                              // somfy_rts_interval_half = 620
   CC1100_OUT_PORT |= _BV(CC1100_OUT_PIN);         // High
   my_delay_us(somfy_rts_interval_half);                              // somfy_rts_interval_half = 620
}

static void send_somfy_rts_frame(somfy_rts_frame_t *frame, int8_t hwPulses) {
   // send hardware sync (pulses of ca. double length)
   for (int8_t i = 0; i < hwPulses; i++) {
      CC1100_OUT_PORT |= _BV(CC1100_OUT_PIN);      // High
      my_delay_us(2550);                                                         // 2x somfy_rts_interval = 2480
      CC1100_OUT_PORT &= ~_BV(CC1100_OUT_PIN);   // Low
      my_delay_us(2550);                                                         // 2x somfy_rts_interval = 2480
   }

   // send software sync (4 x symbol width high, half symbol width low)
   CC1100_OUT_PORT |= _BV(CC1100_OUT_PIN);         // High
   my_delay_us(4860);                                                               // 4x somfy_rts_interval = 4960
   CC1100_OUT_PORT &= ~_BV(CC1100_OUT_PIN);      // Low
   my_delay_us(somfy_rts_interval_half);                              // somfy_rts_interval_half = 620

   // Send the user data
   for (int8_t i = 0; i < SOMFY_RTS_FRAME_SIZE; i++) {
      uint16_t mask = 0x80; // mask to send bits (MSB first)
      uint8_t d = frame;
      for (int8_t j = 0; j < 8; j++) {
         if ((d & mask) == 0) {
            send_somfy_rts_bitZero();
         } else {
            send_somfy_rts_bitOne();
         }
         mask >>= 1; //get next bit
      } //end of byte
   } //end of data

...
}

Sidey · 15 Mai 2016, 20:29:31

Naja, die Clock wird ja so übergeben. Kenne den exakten Wert nicht auswendig, aber um die 600 ist der ja.

Das was im Code als Hardware oder Software Sync bezeichnet wird, hat aber nichts mit Manchester Encoding zu tun.
Das findet man natürlich deswegen auch nicht in meiner universal Senderoutine.

Für die Synchronisation auf ein Manchester Signal, braucht man das auch nicht. Deshalb gehe ich mal davon aus, dass es nur zum Training des Empfängers und zur Abgrenzung der Nachrichten verwendet wird.

viegener · 16 Mai 2016, 13:59:51

Hier gibt es eine relativ gute Beschreibung des Somfy-Protokolls:

https://pushstack.wordpress.com/somfy-rts-protocol/

Allerdings ist ein Fehler enthalten, denn eigentlich ist eine Zykluszeit 1280us und damit die halbe Zykluszeit 640us.
Da ich gerade erst wiedergekommen bin, habe ich jetzt noch nicht alle Änderungen druchgeschaut, als weiteren Hinweis kann ich noch sagen, bei den eigenen Versuchen gab es zum Teil Abhängigkeiten zu den hardware- und Softwaresynczeiten. Die Funktaster halten sich sehr genau an die Synczeiten und bei eigenen Sendeversuchen haben meine RTS-Empfänger ohne die Synczeiten nicht gut funktioniert!

Ralf9 · 16 Mai 2016, 14:48:02

Zitat von: viegener am 16 Mai 2016, 13:59:51
Hier gibt es eine relativ gute Beschreibung des Somfy-Protokolls:

https://pushstack.wordpress.com/somfy-rts-protocol/
Die Funktaster halten sich sehr genau an die Synczeiten und bei eigenen Sendeversuchen haben meine RTS-Empfänger ohne die Synczeiten nicht gut funktioniert!

Hallo Sidey,

wenn ich das so sehe, dann ist es wahrscheinlich einfacher, wenn Du im 00_SIGNALduino.pm die Sendedaten in ein raw Signal (SR) mit den Syncs wandelst, dann brauchst Du auch nicht mehr bei jedem Versuch eine neue Firmware machen.

Gruß Ralf

habeIchVergessen · 16 Mai 2016, 15:28:10

eigentlich sollte die Info aus SOMFY kommen
sendMsg P43#<Sync-Sequenz>#DA...

Sync-Sequenz sollte generisch sein.

sash.sc · 16 Mai 2016, 16:09:43

Zitat von: hjgode am 04 Mai 2016, 06:49:33
Hallo Sascha

hast Du alle Nanos gleichzeitig gekauft? Sind die alle von der Hardware und dem Aussehen gleich?

Es gibt leider auch in Deutschland-Versender die Nanos mit Fake-FTDI (China Zeugs) verkaufen. Die Dinger kann man besten erkennen, wenn man die unter Windows anschließt und die FTDI Treiber laden lässt. Bei den Fake Chips kommt dann serial immer nur wiederholt "Not a genuine product".

Meine Fake FTDI Nanos sind nacheinander mit den unschiedlichsten Symptomen aufgefallen oder 'gestorben': Initialisieren nicht, Serial geht gar nicht mehr, ...

gruss

Josef

Hallo zusammen.

Muss nochmal hier mit dem SOMFY zwischenfunken.
Habe es geschafft, meine Sticks an den Windowsrechner zu klemmen und mit dem FTDI Testprogramm geprüft. Jeder wird mit einer eigenen ID angezeigt.
Habe auch mal den Sender und Empfänger vom sduino auf einen anderen Nano V3 gelötet und geflasht. Nach einem Reboot des FHEM Server bleiben der JeeLink und sduino immer noch unerkannt. Die beiden nanoCULs laufen sofort.
Habe aber mal nach einem Systemreboot ind das /dev/serial/by-ID/ Verzeichniss reingeschaut.
Die beiden Sticks werden vom System (raspi) nicht erkannt. Erst wenn ich diese abziehe und wieder anstecke werden die von Linux erkannt und stehen dann auch in FHEM zur Verfügung.

Hilft das jemanden weiter ?

Gruß
Sascha

Sidey · 16 Mai 2016, 16:09:59

Naja, man kann dafür ja das SC Kommando verwenden.

Da kann man eine Raw Nachricht vor der MC Nachricht senden lassen.
Damit lässt sich das zum Arduino ganz gut übertragen.

Am besten schreibt man die Sync Sequenz in die Start Variable des Protokolls, dann kann man universell nutzen und muss sich damit auch nicht im logischen Modul auseinandersetzen.

Grüße Sidey