SIGNALDuino Empfänger Firm- und Hardware

Begonnen von Ralf9, 02 Oktober 2016, 22:59:51

Vorheriges Thema - Nächstes Thema

drdownload

Hi, ich habe jetzt im Wiki gesehen, dass der Smartwares SH5-TSO-A auch ünterstützt wird mit dem Modul IT. Der Smartwares SH5-TSO-A ist jedoch ein Home-Easy Gerät, kann das stimmen?

LG
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

RappaSan

Hab ich auch gedacht. Ist aber offensichtlich nicht so.
Ich habe hier von der Heim-Bieber-Filiale 2 Bewegungsmelder, 1 x Smartwares  SH5-TSO-A, 1 x HomeEasy HE851.
Der Smartwares-Melder wird per Autocreate angelegt, der HomeEasy nicht.
Die beiden Dinger sind eineiige Zwillige - optisch gesehen. Hingen auch im Verkaufsraum an gleicher Stelle. Daß sie offensichtlich völlig unterschiedliche Funkprotokolle senden ist mir erst aufgefallen, als der HE851 sich partout nicht integrieren ließ.

Ralf9

Zitat von: Sidey am 20 Januar 2017, 07:37:19
Wenn ich die Firmware compiliere, dann ist der TX Puffer 64 Byte. Sobald wir mehr als 64 Byte seriell senden, blockiert die Serial Print Funktion, bis alle Daten im TX Puffer sind.
Ein Erhöhen der Baudrate (ich habe es mal mit 250000) getestet, bringt hier deutliche Verbesserungen.

Eine Möglichkeit wäre demnach den TX Puffer und die Baudrate zu erhöhen.
Bei einer Baudraten erhöhung gibt es was zu beachten:
http://arduino.stackexchange.com/questions/296/how-high-of-a-baud-rate-can-i-go-without-errors

Zitat
Die langen Ausgabezeiten sind im wesentlichen bei den MU Protokollen ein Problem, da hierbei um die 340 Zeichen übertragen werden müssen.
Um das Problem zu minimieren, hilft aus meiner Sicht nur, die Datenmenge zur Übertragung zu reduzieren.

Die reduzierung der Datenmenge sollte abschaltbar sein. Wenn z.B. D=13121012101012 zu D=0x13 0x12 0x10 0x12 reduziert wird, dann können die raw-Nachrichten nicht mehr mit Putty oder einem seriellen Monitor angeschaut werden

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Eine höhere Baudrate ist prinzipiell möglich, wird meines Erachtens aber zu Problemen bei  Anwendern führen. (Schlechte Kabel, ungünstig laufende Quarze )

Das Abschalten der Datenreduzierung  halte ich für ungünstig. Wir wollen ja reduzieren, damit keine Daten verloren gehen.
Das man es dann nicht mehr ohne Hilfsmittel lesen kann ist ein Nachteil, ich wüsste aber nicht, wie man das lösen möchte.

Ein Erhöhen des TX Puffers löst die Dauer auch nur geringfügig. Wir müssten den TX Puffer dafür riesen großes machen. Das lohnt sich nicht.

Im Abschnitt D= kann man das meiste herausholen. Dort haben wir einen overhead von 5/8 je Zeichen. Wir übertragen Werte von 0-7. Dafür sind drei Bits notwendig. Wir übertragen aber immer 8. Der Overhead beginnt schon im Message Array.

Wenn man das ganze ähnlich wie im Bitstore aufzieht, dann setzt man pro Wert immer 3 bits und verschiebt dann.

Man müsste auf Fhem Seite lediglich die Daten wieder in 3 Bit Häppchen unterteilen.

Dann kommt man auf einen overhead von maximal 7/8 bit auf die gesamte Datenmenge.

Den Teil bei P= kann man reduzieren, wenn man anstelle von Dezimal auf hexadezimal umstellt.

Des weiteren kann man auch Überlegungen ob man sich wiederholende Zeichenfolgen erkennt und komprimiert.
Gerade bei MU Nachrichten finden sich ja auch Wiederholungen wieder, die wir heute nicht erkennen.

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

sash.sc

Hallo zusammen.

Ich weiß, es wird gerade beim Signalduino an der Umsetzung gearbeitet, den CC1101 zu implementieren.

Ich bin im Netz in letzter Zeit öfters auf den Begriff LoRa gestoßen. Diese Module haben eine recht hohe Reichtweite beim senden.
Besteht die Möglichkeit so ein RFM95 Modul für 433 MhZ mit dem SignalDuino nutzbar zu machen ?

Von der Modulationarten scheint es ja zu passen !

RFM95
LoRaTM Modem.
Š 168 dB maximum link budget.
Š +20 dBm - 100 mW constant RF output vs. V supply.
Š +14 dBm high efficiency PA.
Š Programmable bit rate up to 300 kbps.
Š High sensitivity: down to -148 dBm.
Š Bullet-proof front end: IIP3 = -12.5 dBm.
Š Excellent blocking immunity.
Š Low RX current of 10.3 mA, 200 nA register retention.
Š Fully integrated synthesizer with a resolution of 61 Hz.
Š FSK, GFSK, MSK, GMSK, LoRaTM and OOK modulation.
Š Built-in bit synchronizer for clock recovery.
Š Preamble detection.
Š 127 dB Dynamic Range RSSI.
Š Automatic RF Sense and CAD with ultra-fast AFC.
Š Packet engine up to 256 bytes with CRC.
Š Built-in temperature sensor and low battery indicator.
Š Modue Size:16*16mm


CC1101


- High sensitivity (–111 dBm at 1.2 kBaud, 868 MHz, 1% packet error rate)
- Low current consumption (14.7 mA in RX,1.2 kBaud, 868 MHz)
- Programmable output power up to +10dBm for all supported frequencies
- Excellent receiver selectivity and blocking performance
- Programmable data rate from 1.2 to 500 kBaud
- Frequency bands: 300-348 MHz, 387-464 MHz and 779-928 MHz

Analog Features

- 2-FSK, GFSK, and MSK supported as well as OOK and flexible ASK shaping
- Suitable for frequency hopping systems due to a fast settling frequency synthesizer: 90us settling time
- Automatic Frequency Compensation (AFC) can be used to align the frequency synthesizer to the received center frequency
- Integrated analog temperature sensor


http://www.kh-gps.de/lora.htm

Gruß und Danke
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Ralf9

#125
Zitat von: sash.sc am 21 Januar 2017, 18:07:42
Ich weiß, es wird gerade beim Signalduino an der Umsetzung gearbeitet, den CC1101 zu implementieren.

Ich bin im Netz in letzter Zeit öfters auf den Begriff LoRa gestoßen. Diese Module haben eine recht hohe Reichtweite beim senden.
Besteht die Möglichkeit so ein RFM95 Modul für 433 MhZ mit dem SignalDuino nutzbar zu machen ?

Wenn beim RFM95 Modul auch der CC1101 verwendet wird, dann ist es evtl möglich.

Edit.
Ich habe mir mal das Datenblatt des RFM95 angeschaut, das sieht komplett anders aus wie der CC1101.
Den RFM95 zu unterstützen ist mir zu aufwendig.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

sash.sc

Zitat von: Ralf9 am 21 Januar 2017, 18:18:21
Wenn beim RFM95 Modul auch der CC1101 verwendet wird, dann ist es evtl möglich.

Edit.
Ich habe mir mal das Datenblatt des RFM95 angeschaut, das sieht komplett anders aus wie der CC1101.
Den RFM95 zu unterstützen ist mir zu aufwendig.

Gruß Ralf
Danke für deine Antwort.

Gruss
Sascha
Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

Ralf9

Zitat von: Sidey am 21 Januar 2017, 10:14:37
Das Abschalten der Datenreduzierung  halte ich für ungünstig. Wir wollen ja reduzieren, damit keine Daten verloren gehen.
Das man es dann nicht mehr ohne Hilfsmittel lesen kann ist ein Nachteil, ich wüsste aber nicht, wie man das lösen möchte.

Ich würde es schön finden, wenn die Datenreduzierung abschaltbar wäre. Man könnte sie z.B, mit "CEK" ein und mit "CDK" ausschalten.

Ich habe Mir mal genauer darüber Gedanken gemacht:
Im ersten Moment hört sich das mit der Datenreduzierung recht gut machbar an. Ich denke das das doch etwas aufwändiger wird.
Die reduzierten Daten  in der "sub SIGNALduino_Read($)" zu verarbeiten ist wahrscheinlich nicht so einfach.

Am beginn der raw Nachricht sollte erkennbar, daß sie reduziert wird. zB. mit Mu und Ms. Bei MC Nachrichten müssten wir auf eine Reduzieung verzichten können.

Eine reduzierte MU Nachricht könnte dann z.B. so aussehen:
ZitatMuP0C9P1D34P2ABCP31F9D<anz><reduzierteDaten>CP0

Die Reduzierung kann man auch noch abhängig machen von der Anzahl der P Abschnitte. Bei P0-P3 kann man dann in 2 Bit Häppchen aufteilen.
Bei der Reduzierung muss auch darauf geachtet werden, daß in den reduzierten Daten der Wert 0x02 nicht vorkommt, da sonst der Beginn der Nachricht nicht mehr eindeutig erkannt werden kann.
Das hier wird auch nicht mehr so einfach funktionieren, da " \n" auch in den reduzierten Daten vorkommen kann.
  while($SIGNALduinodata =~ m/\n/) {
    my $rmsg;
    ($rmsg,$SIGNALduinodata) = split("\n", $SIGNALduinodata, 2);



ZitatEin Schleifendurchlauf kann derzeit  leider fast bis zu 50 ms dauern, da wir eine while schleife in loop haben.
In dieser Zeit läuft der FiFo voll und wir verlieren Daten.

Das hier weckt bei mir Begehrlichkeiten und Wünsche :)
Kannst Du mir eine konfigurierbar Debug Option einbauen?

Debug Level1:
Nachdem mit dem seriell senden die Verarbeitung in der signalduino.cpp fertig ist, soll der freie FIFO angeschaut werden.
Wenn zuwenig frei ist, soll der freie FIFO in einer Debug Nachricht ausgegeben werden z.B.
<002>MD10<003>   für 10 freie Bytes

falls es nicht zu aufwändig ist:
Debug Level2:
Nach jeder Nachricht wird der freie FIFO und die Zeit des schleifendurchlaufs ausgegeben.

Die Debug Option könnte man mit CED1 oder CED2 ein und mit CED0 ausschalten.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

juergs

#128
Hallo sach.sc,

die Daten des RFM95 hören sich ja gut an, aber:z.B. max. erlaubte Sendeleistung:
10mW CC1101 gegen "100 mW constant RF output"!
Short_Range_Devices
Es gäbe ja auch keine Sensoren dafür? Außer eigene Protokolle.

Allerdings gäbe es weitere die IOT-Alternativen:

z.B. "CC2650STK – Multi standard supporting Bluetooth, 6LoWPAN, and ZigBee":
TI-SensorTag
prototypingkit-texas-instruments-cc2650stk
http://www.ti.com/ww/en/wireless_connectivity/sensortag2015/tearDown.html

mit
ZitatDas neue SensorTag IoT-Kit lädt Sie ein, Ihre Cloud-verbundenen Produktideen zu realisieren. Das neue SensorTag enthält nun 10 stromsparende MEMS-Sensoren in einem winzigen roten Paket.
Es kann mit Entwicklungs-Packs erweitert werden, um das Hinzufügen von Sensoren und Aktoren zu ermöglichen.
ZitatOne year battery life and battery-less operation for Bluetooth low energy, 6LoWPAN, ZigBee, and Sub-1GHz Long Range

Grüße,
Jürgen



sash.sc

Hallo Jürgen.

Danke für die Info.
Habe gedacht das rfm95 mit 433MHz hauptsächlich als Sender einzusetzen. Einfach um die Reichweite aufgrund der Leistung zu erhöhen.
Stichwort IT Protokoll..  8)

Von mobil gesendet daher kurze Antwort

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

juergs

#130
ZitatHabe gedacht das rfm95 mit 433MHz hauptsächlich als Sender einzusetzen. Einfach um die Reichweite aufgrund der Leistung zu erhöhen.
Stichwort IT Protokoll..  8)

Ja, das bekommst Du aber auch mit einem 1:1 Repeater hin, aber max. 10 mW Sendeleistung.
Schau mal unter "Hideki" hier im Forum oder:
RemoteSensor -examples -Repeater (RemoteSensor-Lib)

Funk-Erweiterung-Repeater-ITV-100.html

Grüße,
Jürgen

Ralf9

#131
Zitat von: Sidey am 21 Januar 2017, 10:14:37
Eine höhere Baudrate ist prinzipiell möglich, wird meines Erachtens aber zu Problemen bei  Anwendern führen. (Schlechte Kabel, ungünstig laufende Quarze )

Zur Baudrate habe ich was interessantes gefunden.
http://wormfood.net/avrbaudcalc.php?postbitrate=115200&postclock=16&u2xmode=1&hidetables=1

Demnach ist bei 8 MHz die Baudrate 57600 nicht so gut. Der error ist mit 2.1% zwischen recommended and absolute max error rates

Beim promini müsste man eigentlich die Baudrate auf 250000 erhöhen können, da dieser normalerweise nicht direkt per Kabel zum USB Port verbunden wird, oder täusche ich mich da?

Liest hier jemand mit, der beim usr-tcp232-t2 und ESP8266 messen kann wie groß der error bei 250000 ist oder weiß es sogar ohne zu messen?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

Sidey

Zitat von: Ralf9 am 21 Januar 2017, 19:57:37
Ich würde es schön finden, wenn die Datenreduzierung abschaltbar wäre. Man könnte sie z.B, mit "CEK" ein und mit "CDK" ausschalten.

Ich habe Mir mal genauer darüber Gedanken gemacht:
Im ersten Moment hört sich das mit der Datenreduzierung recht gut machbar an. Ich denke das das doch etwas aufwändiger wird.
Die reduzierten Daten  in der "sub SIGNALduino_Read($)" zu verarbeiten ist wahrscheinlich nicht so einfach.

Ich habe mal mit einer simplen variante angefangen. Jeder Wert nimmt 4 bit ein. Somit stehen in einem byte immer 2 Werte. Die gemessenen Zeiten stehen im Code.

Serial.println("---- Start of ----");
delay(400);
     
char c[] = { "010203040506071012131415161720212324252627303132343536374041424345464750515253545657606162636465677071727374757601020304050607101213141516172021232425262730313234353637404142434546475051525354565760616263646567707172737475760102030405060710121314151617202123242526273031323435363740414243454647505152535456576061626364656770717273747576" };
unsigned long now;
unsigned int duration;
uint16_t len = sizeof(c) / sizeof(c[0])-1;


now= millis();
Serial.write(c, len);
duration = millis() - now;  // 46 ms
Serial.println("");
Serial.println(duration);
Serial.println("---- ----");

delay(400);

now = millis();
byte buff = 0;

for (int i =1; i <= len; i++)
{

if (i % 2)
{
buff = c[i - 1]<<4;
//Serial.write(buff<<4);

} else {
buff = buff | c[i - 1] ;
Serial.write(buff);
}
}
duration = millis() - now;  //18 ms
Serial.write(0x04);
delay(120);
Serial.println("");
Serial.println(duration); 

Serial.println("---- end test ----");


Alles mit 57600 Baud getestet.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

juergs

#133
Hallo Sidey,

wollte die Performance (NANO,16MHz) der Arduino- mit der Printf-Lösung gegenüberstellen,
da ich gerade den Testaufbau parat hatte.
Habe Dein Testcase etwas abgespeckt um vergleichen zu können.

Ergebnis: Leider kostet "Komfort" etwas mehr an Zeit. ( 24:30ms  ... was zu beweisen war, leider.  :'( )

ZitatStarting in 5s ...
*** Start of ArduinoSerial ----
LEN: 336
1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv
Dauer: 24
*** End test ----

*** Start of printf via FILE ---
LEN: 336
1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv1234567023456701345670124567pqrsuvwpqrstvwpqrstuwpqrstuv
Dauer: 30
*** End test ----


Grüße,
Jürgen

Sidey

Ich habe noch ein bisschen weiter getestet....

Die Variante, einen Wert nur 3 Bits belegen zu lassen bringt auch noch mal deutliche Geschwindigkeitsvorteile.
Ich denke, ich werde die den message Array auf die Bitstore Klasse umrüsten und die Bitstore Klasse noch ein wenig mit Operatoren ausrüsten.

Dann wird intern immer sparsam gespeichert und die Ausgabe kann im Normalfall dann auch so erfolgen.
Probleme mit Zeilenenden hatte ich noch keine, das schaue ich mir noch mal an, welche Bitfolge dazu führen würde.

Weitere Überlegung, die Werte hinter P=1252  können wir als int (16 bit) anstelle der 4 zeichen (32 bit) übergeben.


Lesen kann man die Ausgabe dann nur noch in Fhem.

Vielleicht schreibe ich eine mini Terminalanwendung, die das direkt umwandelt.



Zur Baudrate habe ich auch noch ein bisschen gelesen.
Die Baudrate ist von der USB Verbindung unabhängig. Die USB Verbindung ist immer gleich schnell, da gibt es keine Baudrate.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker