SIGNALDuino Empfänger Firm- und Hardware

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

Vorheriges Thema - Nächstes Thema

juergs

#60
Hallo Ralf,
kann Dir den Sachverhalt mit einem Screenshot des SDR# vielleicht verdeutlichen.
Der markierte Bereich um die SollFrequenz ist eine 32KHz Bandbreite (+/- 16 KHz),
also Faktor 10 kleiner als der CC1101!
Es zeigt zwar den Sendebetrieb bei IT,
Gleiches gilt aber mit Sicherheit übertragbar auch für den Empfang.

Die 433MHz-Sensoren liegen nicht immer auf der aufgedruckten Frequenz.
Die Fernbedienungs-Sender streuen deshalb in einem weiten Bereich, um auch jeden Abweichling zu erwischen,
also über eine "riesen" Bandbreite.

Ganz im Gegenteil der CC1101, er sendet je nach Abweichung des Quarzes und der Anpassung
mehr oder weniger eng um die Frequenzvorgabe. Liegen die Empfänger/Sender  "daneben"
funktioniert es nicht oder nur schlecht.

Deshalb muss man meist "nachhelfen". Die Power nach oben "drehen",
da sie standardmäßig im Mittelbereich angesiedelt  ist (was Störungstechnisch gesehen auch Sinn macht)
oder besser die "richtige" Mittenfrequenz suchen (SDR#).

ZitatHier nochmal der Hinweis, wo man mit solchen Modulen senden darf:
433.05 bis 434.79MHz.
Quelle

Grüße + Lob für das tolle Projekt!
Jürgen

Sidey

Ich habe zur Bandbreite folgendes gefunden:

Frequency tolerance of output: ±75KHz


Ob es stimmt, weiss ich nicht.


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

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

juergs

#62
Oder 433mhz-superheterodyne-3400-rf-link-kit:
oder hier https://forum.fhem.de/index.php/topic,17196.msg198580.html#msg198580

TX Technical Specifications:
1.Working voltage: 3V~12V
2.Working current: max40mA (12V), min9mA(3V)
3.Resonance mode: sound wave resonance (SAW)
4.Modulation mode: ASK /OOK
5.Working frequency: 315MHz-433.92MHz, customized frequency is available.
6.Transmission power: 25mW (315MHz at 12V)
7.Frequency error: +150kHz (max)
8.Velocity: 10Kbps
9.Self-owned codes: negative
10.Aerial Length: 24cm (315MHz), 18cm(433.92MHz)




RX Technical Specifications:
1.Working voltage: 5.0VDC +0.5V
2.Working current:2.5mA (5.0VDC)
3.Working principle: superheterodyne
4.Working method: OOK/ASK
5.Operating frequency: 315MHz, 433.92MHz, customized frequency is available;
6.Bandwidth: 2MHz (315MHz, having result from testing at lowing the sensitivity 3dBm)
7.Sensitivity: excel -105dBm (50)
8.Velocity:
9.Output signal: TTL electric level signal entire transmit

Ralf9

ich finde es etwas seltsam, warum nur ich mit dem CC1101 Probleme mit dem empfangen der EAS800z Temperatursensoren habe. Da es die EAS800z damals recht günstig im Ausverkauf gab, müssten eigentlich recht viel mit dem cul als Empfänger inbetrieb sein. Mir sind keine Fälle bekannt wo zum Empfangen die Bandbreite hochgesetzt werden musste.
Habe ich evtl ein CC1101 Modul mit einem ungenauen Quarz erwischt?

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

#64
Hallo Ralf,
scheint mir eher kein Bandbreitenproblem zu sein.

Wie sieht es mit dem RSSI aus > 100?
Batteriezustand? Platzierung? Antenne (Unterschiede ASK + FSK)?

ZitatQuarter-wave or monopole antennas require an associated ground plane
counterpoise for proper operation. The size and location of the ground
plane relative to the antenna will affect the overall performance of the
antenna in the final design. When used in conjunction with a ground
plane smaller than that used to tune the antenna, the center frequency
typically will shift higher in frequency and the bandwidth will decrease. 
The proximity of other circuit elements and packaging near the antenna
will also affect the final performance.
Quelle (Splatch Planar Antenne)

Grüße,
Jürgen

juergs

#65
Hallo Ralf,

um mein Verständnis der Signalduino SW und des CC1101 aufzufrischen,
habe ich mir erlaubt, Deinen Code etwas "aufzuräumen" und minimal erweitert.

Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:
RF_Receiver:165: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&cc1101::getRSSI); // Provide the RSSI Callback
                 ^
RF_Receiver:167: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&rssiCallback);        // Provide the RSSI Callback

RF_Receiver:973: error: 'stackptr' was not declared in this scope
  stackptr = (uint8_t *)malloc(4);          // use stackptr temporarily
  ^
RF_Receiver:974: error: 'heapptr' was not declared in this scope
  heapptr = stackptr;                     // save value of heap pointer
  ^
RF_Receiver:985: error: '__brkval' was not declared in this scope

  if((int)__brkval == 0)

          ^
RF_Receiver:986: error: '__bss_end' was not declared in this scope
     free_memory = ((int)&free_memory) - ((int)&__bss_end);

                                                ^


<edit>
Zitat#else
    extern int __heap_start, *__brkval;
*__brkval; ist extern void, nicht int.
</edit>

und dieser hier :
Zitat'class SignalDetectorClass' has no member named 'setRSSICallback'

und komme deshalb nicht weiter.

2. Frage:
#ifdef CMP_FIFO
  #include "SimpleFIFO.h"
  SimpleFIFO<int,FIFO_LENGTH> FiFo; //store FIFO_LENGTH # ints
#else
  // TODO klaeren!
  #include <filtering.h> //for FiFo Buffer
  RingBuffer FiFo(FIFO_LENGTH, 0); // FiFo Puffer
#endif


Weiß jemand woher die "filtering.h" kommt?

Gibt es noch Änderungen?

Grüße,
Jürgen

Ralf9

Zitat von: juergs am 28 Dezember 2016, 16:27:45
Hallo Ralf,

um mein Verständnis der Signalduino SW und des CC1101 aufzufrischen,
habe ich mir erlaubt, Deinen Code etwas "aufzuräumen" und minimal erweitert.

Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:

Der Signalduino Code ist von Sidey ich habe nur den CC1101 Code ergänzt.
Sidey hat auch das FastDelegate.h für das rssi callback eingebaut. Wenn ich das richtig sehe, verwendest Du noch eine ältere signalDecoder.h und signalDecoder.cpp wo das FastDelegate fehlt.

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

Ralf9

Zitat von: juergs am 28 Dezember 2016, 11:12:18
scheint mir eher kein Bandbreitenproblem zu sein.

Wie sieht es mit dem RSSI aus > 100?
Batteriezustand? Platzierung?

Als Antenne habe ich die 5cm Antenn die dabei war verwendet. Ich habe es auch mit der
"Delock ISM 433 MHz Antenne SMA 2,5 dBi omnidirektional # 88914" versucht.
Mit der Default Bandbreite hat es auch nicht funktioniert, wenn der CC1101 und die EAS800z im selben Raum waren. Ein EAS800z hat volle Batterien und der andere low Bat

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

#68
Zitat von: juergs am 28 Dezember 2016, 16:27:45
Damit ich die Libs separat halten kann, habe ich sie erst mal (für mich) lokal gesetzt.

Ich denke, in der Arduino IDE gibt es leider auch keine Alternative dazu.

Zitat von: juergs am 28 Dezember 2016, 16:27:45

Allerdings kommen bei dem Code aus dem GitHub noch Fehlermeldungen:
RF_Receiver:165: error: 'class SignalDetectorClass' has no member named 'setRSSICallback'
       musterDec.setRSSICallback(&cc1101::getRSSI); // Provide the RSSI Callback
 


Du hast nicht die aktuelle Lib aus github. Ich habe setrssiCallback vor 2 Tagen eingebaut.

Zitat von: juergs am 28 Dezember 2016, 16:27:45
<edit>  *__brkval; ist extern void, nicht int.</edit>

Das muss ich mir noch mal ansehen, bei mir compiliert der Teil für freememory .

Zitat von: juergs am 28 Dezember 2016, 16:27:45
Weiß jemand woher die "filtering.h" kommt?

Ja, das habe ich mit meinem Bruder vor einiger Zeit mal erstellt. In den Ersten Versionen des SIGNALduino habe ich die Lib für den FIFO verwendet. Die Lib war aber zu mächtig, deshalb bin ich dann irgendwann mal auf SimpleFifo umgestiegen.
filterhing.h ist wird in der aktuellen Version aber nicht mehr eingebunden. Welche Version von RF_Receiver hast Du?

Grüße Sidey
[/code]
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

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

juergs

#69
Hallo Sidey,
merci für die Infos.

habe beide repositories heruntergeladen:
1.)  https://github.com/RFD-FHEM/RFFHEM
2.)  https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101 (Branch von Ralf9)

Das sollten die aktuellen sein?

Hintergrund, wollte die Problematik mit dem CC1101 und Ralf Problem bei mir mal begutachten.
Nebenbei fällt dann noch etwas Verständnis für die Implementierung für FHEM dabei ab.  :)

Da ich diese Sensoren https://forum.fhem.de/index.php/topic,36104.msg543191.html#msg543191
hier gerne integrieren möchte.

Die oben erwähnten Probleme konnte ich bis auf die fehlende RSSI-Implementierung selbst lösen.
Allerdings mach noch der Signaldecoder Warnings, Compile geht aber durch:
Zitat
signalDecoder.cpp:366:7: warning: extra tokens at end of #endif directive  -> beseitigt.
signalDecoder.cpp: In member function 'int8_t SignalDetectorClass::findpatt(int)':signalDecoder.cpp:165:62
signalDecoder.cpp: In member function 'int8_t SignalDetectorClass::findpatt(int)' :signalDecoder.cpp:576:31
signalDecoder.cpp: In member function 'void SignalDetectorClass::compress_pattern()' ::signalDecoder.cpp:165:62: warning: right shift count >= width of type

C:\Users\JRGEN~1\AppData\Local\Temp\arduino_build_602412\sketch\signalDecoder.cpp:576:31: warning: right shift count >= width of type

   if ((val ^ pattern[idx]) >> 31)

                               ^

Die Hilfsfunktionen habe ich so gelöst:


///-----------------------------------------------------------------------
*** extern int __bss_end;   ***
*** extern int *__brkval;    ***

//--- diese Deklaration hatte define-abhängig gefehlt:
uint8_t * heapptr, * stackptr;

void check_mem() {
  stackptr = (uint8_t *)malloc(4);          // use stackptr temporarily
  heapptr = stackptr;                     // save value of heap pointer
  free(stackptr);      // free up the memory again (sets stackptr to 0)
  stackptr =  (uint8_t *)(SP);           // save value of stack pointer
}

Gilt für nicht gesetztes "CMP_MEMDBG"-Define.

Die FastIO-Makros habe ich gefunden und eingebunden.

Sorry, muss mich in Git noch etwas einarbeiten ...  :'(

Hättest Du mir bitte ein Hinweis auf die neueren Versionen?

Hier https://github.com/RFD-FHEM/SIGNALDuino/tree/dev-r33_cc1101 ?

Grüße,
Jürgen

/EDIT:
Geht schon mal:
ZitatUsing sFIFO
Reading values fom eeprom
CCInit
CCVersion=20
CCPartnum=0
Starting timerjob
receiver enabled
V 3.3.1-dev SIGNALduino cc1101 - compiled at Dec 29 2016 17:11:22



Ralf9

Ich habe mir mal Gedanken gemacht was alles beim CC1101 noch benötigt wird.
Wenn ein 868 MHz CC1101 verwendet wird, sollte er etwas anders (Frequenz und PATABLE) initialisiert werden.
Ich habe irgendwo gelesen, daß es beim CUL einen Jumper für (433/868 MHz) gibt.
Oder gibt es noch eine andere Möglichkeit damit die Firmware beim Factory Reset weiß ob sie die Werte für 433 oder 868 verwenden soll.

Ich hab mir auch mal überlegt wie man das mit dem senden machen könnte.
Ich denke es wäre sinnvoll, wenn man beim Senden die Frequenz ändern könnte, dazu müsste man "set sduino raw" (z.B. mit F=<F1><F2><F3>)
und "set sduino sendMsg" (z.B. mit #F<F1><F2><F3>) erweitern. Wobei F1-F3 die Werte für Register 0D-0F sind.

Ein senden könnte dann z.B. so aussehen:

- command strobe 0x36 SIDLE
- Register  0D-0F auslesen und merken
- Register  0D-0F mit den übergebenen Werten beschreiben
- command strobe 0x35 STX
- senden
- command strobe 0x36 SIDLE
- Register  0D-0F mit den vorher gemerkten Werten beschreiben
- command strobe 0x34 SRX


Es dürfte auch sinnvoll sein beim Befehl C3E (CC1100_PATABLE) alle 8 Werte zurückzugeben.

Mit ist noch nicht klar was beim Befehl x (set PATABLE) der Defaultwert ist

Zitatx<pp> Change the (EEPROM) PA tables (power amplification for RF sending)

    <pp> is a one-byte hex value, valid values are 00 to 09, with following values: the first 5 is -10/-5/0/5/10 dBm with PA ramping, the next 5 is the same without PA ramping. If the value is outside this spec, then the 5dBm variant (03) will be used.


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

#71
Hallo Ralf,

inder aculfw gibt es 2 Varianten die Frequenz einzustellen.

1. per SW in der 328P nanoCUL-Variante
/* define this device as a 433 MHz one */
/* this isn't done like a CUL by reading a port pin but instead a fixed value of 0 for mark433_pin is used */
#define MULTI_FREQ_DEVICE
#define MARK433_PIN mark433_pin
#define MARK433_BIT             0
extern const uint8_t mark433_pin;


2. per Port-Pin in der 32U4 CUL-Variante
#define MARK433_PORT            PORTB
#define MARK433_PIN             PINB
#define MARK433_BIT             6
#define MARK915_PORT            PORTB
#define MARK915_PIN             PINB
#define MARK915_BIT             5



Zitat
0x57, // 10 MDMCFG4   8C     bWidth 325kHz
0xC4, // 11 MDMCFG3   22     DataRate
0xb9, // 14 MDMCFG0   F8     ChannelSpace: 350kHz

Zitat
0x57, // 10 MDMCFG4  *8C    55    bWidth 325kHz
0xC4, // 11 MDMCFG3 (x)   DataRate: 5603,79 Baud ((256+196)*2^7)*26000000/(2^28)

Die Datenrate scheint bei ASK relevant zu sein, 0xC4 für MDMCFG3 scheint entgegen dem Kommentar auf Bitrate von 1400.95 BAUD zu setzen.
Channelspace MDMCFG0 = B9  => 174.957275 KBAUD
Die aculfw gibt da Aufschluss zur Berechnung. D.h. man müsste mal das InputSignal/Periodendauer nach der Datenrate-Vorgabe überprüfen...



Sidey

Also ich würde nicht so viel in die Firmware implementieren.

Meines Erachtens, kann man die komplette Register Information über die serielle Schnittstelle auf den UC und dann auf den CC1101 übertragen.
Da müsste nichts in die Firmware zwingend rein. Dort nimmt es nur platz weg, den wir vielleicht noch brauchen.. z.B. für die Ethernet Variante.

Sobald es einmal im EEProm ist, läuft das Gerät auch ohne FHEM und der normale Ablauf ist ja in etwa so:

Hardware zusammenbauen
Per USB an den FHEM Server anbinden
Firmware Flashen

Für die Ethernet Variante stelle ich mir auch vor, dass man die nach dem Flashen konfiguriert.
Das sollte für die CC1101 Variante doch auch kein Problem sein.

Je nach Verwendungswzeck kann man dann die passenden Register im FHEM Modul hinterlegen.


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

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

Ralf9

Hallo Sidey,

demnach ist es für Dich kein Problem für den CC1101 vier hex Files zu erstellen (nanoCC1101_433, nanoCC1101_868, prominiCC1101_433, prominiCC1101_868).

Die 29 Registerwerte für den FactoryReset würde ich gerne in der Firmware behalten.
Bei der PATABLE können wir es so machen, daß sie im Signalduino Modul hinterlegt wird. Beim x-Befehl werden dann anstatt 1 Byte die 8 Byte der PATABLE übergeben.

Zum Platz sparen müssten eigentlich die ganzen IT-Befehle raus können, da sie nicht mehr benötigt werden.

Eine Alternative zur Ethernet Variante ist das USR-TCP232-T2 Tiny Serial Ethernet Converter Module.
Ich denke die Ethernet Variante macht nur Sinn, wenn damit mehr möglich ist als mit dem USR-TCP232-T2
z.B. Betrieb über Port 1000 und Debug Ausgabe über Port 23. Bringt die höhere Übertragungsrate als 57600 der Ethernet Variante Vorteile?

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 30 Dezember 2016, 00:27:42
demnach ist es für Dich kein Problem für den CC1101 vier hex Files zu erstellen (nanoCC1101_433, nanoCC1101_868, prominiCC1101_433, prominiCC1101_868).
Eher eine Fleißarbeit. Aber wofür brauchen wir unterschiedliche firmware für 868 und 433 Mhz?


Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Die 29 Registerwerte für den FactoryReset würde ich gerne in der Firmware behalten.

Warum? Wenn wir das für alle Varianten machen, dann bläht sich das ja unweigerlich auf. Im Moment 433 und 868 Mhz, aber für andere Variationen (ich weiss jetzt nicht welche) würde sich das ja noch erweitern.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Bei der PATABLE können wir es so machen, daß sie im Signalduino Modul hinterlegt wird. Beim x-Befehl werden dann anstatt 1 Byte die 8 Byte der PATABLE übergeben.

Ich kenne Unterschied zwischen PATable und Register leider noch nicht.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Zum Platz sparen müssten eigentlich die ganzen IT-Befehle raus können, da sie nicht mehr benötigt werden.
Ja, die können raus.

Zitat von: Ralf9 am 30 Dezember 2016, 00:27:42
Eine Alternative zur Ethernet Variante ist das USR-TCP232-T2 Tiny Serial Ethernet Converter Module.
Ich denke die Ethernet Variante macht nur Sinn, wenn damit mehr möglich ist als mit dem USR-TCP232-T2
z.B. Betrieb über Port 1000 und Debug Ausgabe über Port 23. Bringt die höhere Übertragungsrate als 57600 der Ethernet Variante Vorteile?
Könnte man machen. Debug Ausgaben würde ich ja aber nur seriell ausgeben.
Die Geschwindigkeit hängt meines Erachtens am SPI Bus, was der kann weiss ich aktuell nicht. Für einen Arduino Uno ist halt das Ethernet Shield ganz nett, draufstecken geht. Auf dem ESP8266 habe ich ja auch schon ein wenig experimentiert. Da schien mir aber der Empfang durch die 3,3v eher schlecht.


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

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