Fehlerhafte CC1101 Module

[tndx]

Ich habe mittlerweile 6 Funkmodule von dieser Sorte erhalten und nach vielen Tests mit CUL/HM-MOD-PCB/FHEM/piVCCU für funktionsfähig befunden:
https://www.aliexpress.com/item/Wireless-Module-CC1101-Long-Distance-Transmission-Antenna-868MHZ-M115-For-FSK-GFSK-ASK-OOK-MSK-64/32951998715.html?spm=a2g0s.9042311.0.0.7fb24c4dUBbveK

[thgorjup]

Ich habe letzte Woche wieder 50 Stck. Module mit 26.000 MHz auf dem Quartz erhalten. Das ist jetzt schon das 4. Mal hintereinander, dass die Module eine Abweichung haben. Alle AliExpress-Quellen aus denen ich in der Verganhenheit ordenliche Module erhalten habe, scheinen ihre Quellen geändert zu haben.
Evtl. haben die Hersteller der CC1101 Module grundsätzlich die Produktion umgestellt....?

Jedenfalls laufen die Dinger mit folgender Einstellung in der Firmware:

Code: [Auswählen]

radio.initReg(CC1101_FREQ2, 0x21);
radio.initReg(CC1101_FREQ1, 0x65);
radio.initReg(CC1101_FREQ0, 0xFF);

Ich glaube es wird eilig nötig, dass man für HomeMatic auch die Frequenz über die FHEM Oberfläche umstellen kann.
Ich kann hier leider nicht viel mithelfen, da ich mich damit sehr wenig auskenne.

[papa]

Könnte mir bitte mal jemand so ein "defektes" Modul zukommen lassen. Ich würde gerne mal eine Idee ausprobieren. Im Prinzip denke ich mir folgendes:
Es gibt einen Frequenztest-Sketch, der versucht die besten Settings zum Empfang von Pakten zu ermitteln. Dazu kriegt er die ID eines Referenzgerätes (z.B. der Zentrale). Dann versucht er Nachrichten zu empfangen. Wenn die gelingt, wir der RSSI gemerkt. Wir eine bestimmte Zeit nicht empfangen, wird die Frequenz leicht geändert und das lauschen geht wieder los. So müssten sich die optimalen Settings für ein Modul ermitteln lassen.
Damit dann so ein Gerät einfach in betrieb und später auch aktualisiert werden kann, würde ich die so ermittelten Werte im OTA-Bootloader ablegen. Dort habe ich schon mal vor einiger zeit 10 Byte Konfigdaten eingeplant. Bisher wird das nur vom Fensterkontakt für die Batterieschwellwerte genutzt. Es ist also noch Platz. Damit könnte man die Frequenzsettings im spezielen Gerät speichern. Die Firmware würde für alle gleich bleiben. So wird es ja auch schon mit der ID und Serial im OTA-Bootloader gemacht.

[Tom Major]

Gut wäre wenn man auch ohne OTA den ermittelten Wert im sketch setzen könnte. Momentan geht das ja bereits über 3x initReg() im init HAL, vielleicht dann einen setter der das gefundene 32 (24)bit frequency value übergibt?

Es gibt einen Frequenztest-Sketch, der versucht die besten Settings zum Empfang von Pakten zu ermitteln. Dazu kriegt er die ID eines Referenzgerätes (z.B. der Zentrale). Dann versucht er Nachrichten zu empfangen. Wenn die gelingt, wir der RSSI gemerkt. Wir eine bestimmte Zeit nicht empfangen, wird die Frequenz leicht geändert und das lauschen geht wieder los. So müssten sich die optimalen Settings für ein Modul ermitteln lassen.

Das könnte aber länger dauern, oder? Könnte man nicht eine definierte message in einer loop mit schrittweise geänderter Frequenz an die Zentrale senden lassen und auf das ACK sowie RSSI schauen und den besten Wert nehmen?

[papa]

Gut wäre wenn man auch ohne OTA den ermittelten Wert im sketch setzen könnte. Momentan geht das ja bereits über 3x initReg() im init HAL, vielleicht dann einen setter der das gefundene 32 (24)bit frequency value übergibt?

Hm - ich habe ein paar Byte am Anfang im EEPROM frei gelassen. Die ersten 4 Byte sind für die Checksumme. Dann geht es ab 0x20 mit den Devicedaten los. Dort könnten wir auch solche Devicesettings ablegen.

Das könnte aber länger dauern, oder? Könnte man nicht eine definierte message in einer loop mit schrittweise geänderter Frequenz an die Zentrale senden lassen und auf das ACK sowie RSSI schauen und den besten Wert nehmen?

Als unbekanntest Device kriegst Du keine Antwort von der Zentrale :-( Das würde nur klappen, wenn eine existierende ID genommen wird.
Damit es schneller eght, könnte man ja auch einfach alle Nachrichten auswerten. So würde man recht einfach den Empfangsbereich ermitteln können, wenn ein paar Thermostate oder Thermometer da sind.

[Tom Major]

Im EEPROM ablegen klingt gut, das wäre hilfreich.

Als unbekanntest Device kriegst Du keine Antwort von der Zentrale :-( Das würde nur klappen, wenn eine existierende ID genommen wird.
Damit es schneller eght, könnte man ja auch einfach alle Nachrichten auswerten. So würde man recht einfach den Empfangsbereich ermitteln können, wenn ein paar Thermostate oder Thermometer da sind.

ok, verstehe. Dann muss man bei weniger Funkverkehr eben länger warten.

Gut wären dann im  Frequenztest-Sketch serielle Statusausgaben wie Anzahl der Nachrichten, RSSI, momentane Frequenz.
Außerdem würde ich vorschlagen nicht gleich bei einer empfangenen Nachricht anzuhalten und diese Frequenz zu nehmen sondern einen full sweep über einen definierten Frequenzbereich um wirklich das Optimum rauszuholen 

[papa]

Ich habe eine gute Nachricht. Mit Hilfe des FreqTest.ino Sketches konnte ich alle mir zugesandten Funkmodule zum Laufen bringen.
Das ganze funktioniert wie folgt. Der Testsketch versucht ausgehend von der Standardfrequenz ein gültiges Paket zu empfangen. Wenn nichts empfangen wurde, wird die Frequenz geändert und es wird wieder versucht. Dabei wird jeweils versucht den Bereich oberhalb und unterhalb der Standardfrequenz zu erweitern. Wenn irgendwo ein Paket empfangen wurde, wird von dort ausgehend die obere und untere Grenze ermittelt. Am Schluss wird dann die Frequenz, die in der Mitte zwischen oberer und unterer Grenze liegt, in den vorher ungenutzten Bereich des EEPROM geschrieben.
Wenn jetzt ein "normaler" Sketch geflasht wird, wird beim Start geprüft, ob eine Frequenz im EEPROM abgelegt wurde und gegebenenfalls das Funkmodul damit initialisiert. Somit kann für jedes Gerät die Frequenz ermittelt werden.

Die Ausgabe beim Scann sieht dann wie folgt aus:

Code: [Auswählen]

AskSin++ V3.1.7 (Jan 29 2019 21:23:22)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A:   0/0
Freq 0x2165BA:   0/0
Freq 0x21651A:   0/0
Freq 0x21660A: 996699.  1/88
Search for upper bound
Freq 0x21661A: 996699.  1/88
Freq 0x21662A: 996699.  1/89
Freq 0x21663A: 996699.  1/89
Freq 0x21664A: 996699.  1/87
Freq 0x21665A: 996699.  1/88
Freq 0x21666A: 996699.  1/89
Freq 0x21667A: 996699.  1/88
Freq 0x21668A: 996699.  1/88
Freq 0x21669A: 996699.  1/88
Freq 0x2166AA: 996699.  1/88
Freq 0x2166BA: 996699.  1/86
Freq 0x2166CA:   0/0
Search for lower bound
Freq 0x2165FA: 996699.  1/89
Freq 0x2165EA: 996699.  1/87
Freq 0x2165DA:   0/0

Done: 0x2165EA - 0x2166BA
Calculated Freq: 0x216652
Store into config area: 6652
Der Start mit einem "normalen" Sketch dann so:

Code: [Auswählen]

AskSin++ V3.1.7 (Jan 29 2019 21:53:51)
Address Space: 32 - 242
CC init1
CC Version: 14
 - ready
Bat: 25
Config Freq: 0x216652
Es gibt eine Ausgabe, wenn eine andere Frequenz benutzt wird.

Der Testsketch verhält sich im Standardfall passiv. Da bedeutet, dass nur versucht wird, Pakete zu empfangen. Wurde nach einer Minute (einstellbar durch SCANTIME) nichts empfangen, wird die Frequenz gewechselt. Um sicher zu stellen, dass auch Nachrichten empfangen werden können, sollten während des Scans irgendein Gerät geschaltet werden.
Durch Setzen des ACTIVE_PING Defines, kann der aktive Modus eingeschaltet werden. Dann sendet der Sketch jede Sekunde eine Statusmessage. Hierzu sind sind die PING_FROM und PING_TO IDs entsprechend der eigenen Umgebung anzupassen. PING_FROM sollte eine gepairtes Geräte sein - z.B. Steckdose. PING_TO ist die Zentrale/FHEM/CCU. Das Scannen sollte jetzt viel schneller gehen, da eine Antwort von der Zentrale angefordert wird.

Bedanken möchte ich mich bei tndx und dartrax für die schnelle Bereitstellung der problematischen Module

[RaspiLED]

Moin, Ihr seid cool!

Sehe ich das richtig, dass jetzt nur die neue Einstellung für 868.300 MHz im EEPROM abgelegt wird? Wäre es nicht sinnvoller eine Differenz zu hinterlegen, die auch bei anderen Frequenzen addiert wird?

Es soll ja Leute geben, die manchmal auf 433.920 oder sogar 433.420 MHz wechseln ;-)

Dann bräuchten wir auch noch eine Antwort auf die Frage ob es eine Abweichungskurve oder eine -gerade ist.

Gruß Arnd


Gesendet von iPhone mit Tapatalk

[papa]

Das das ganze nur mit der AskSin++ funktioniert, wird auch nur die Homematic Frequenz abgelegt. Die Differenz könnte man sich ja aber auch selbst gegebenenfalls ausrechnen.
Für die nanoCUL-Firmware könnte den Wert natürlich auch nutzen. Wird da der EEPROM für irgendwas genutzt ?

[tndx]

Hi,

Ich habe eine gute Nachricht. Mit Hilfe des FreqTest.ino Sketches konnte ich alle mir zugesandten Funkmodule zum Laufen bringen.

das ist ja eine sehr gute Nachricht!

Nur für mich zum Verständnis:
1. Dieses Feature ist vollkommen transparent für den Benutzer?
2. Die bestehenden Sketche (z.B. HM-Fensterdrehgriffkontakt) müssen nur mit der aktuellen Version von AskSinPP kompiliert, aber nicht selber angepasst werden?
3. Ein Sketch mit der älteren AskSinPP-Version wird sich nicht nicht an der im Bootloader hinterlegten Frequenz stören?
4. Ist im Bootloader keine Frequenz hinterlegt, wird die Standard-HM-Frequenz genutzt?

Wie sieht es mit dem OTA-Bootloader aus, nutzt er dann auch diese Frequenz?

Dann würde ja mein Workflow so aussehen: Bootloader mit dem Frequenz-Sketch per ISP flashen und die eigegentliche HM-Firmware per dann hoffentlich funktionierendem OTA?

[papa]

Nur für mich zum Verständnis:
1. Dieses Feature ist vollkommen transparent für den Benutzer?

Ja

2. Die bestehenden Sketche (z.B. ) müssen nur mit der aktuellen Version von  kompiliert, aber nicht selber angepasst werden?

Richtig. Das ganze Handling ist im ChannelDevice::init() implementiert.

3. Ein Sketch mit der älteren AskSinPP-Version wird sich nicht nicht an der im Bootloader hinterlegten Frequenz stören?

Die Frequenz steht nicht im Bootloaer, sondern im EEPORM.

4. Ist im Bootloader keine Frequenz hinterlegt, wird die Standard-HM-Frequenz genutzt?

Genau. Es gibt eine Checksumme für den EEPORM-Configbereich. Nur wenn diese stimmt und das erste Byte != 0 ist, wird die Frequenz bei der Initialisierung aktualisiert.

Wie sieht es mit dem OTA-Bootloader aus, nutzt er dann auch diese Frquenz?

Nein. Das könnte dort aber auch noch integriert werden. Oder man patcht die Werte direkt in den Bootloader.

Dann würde ja mein Workflow so aussehen: Bootloader mit dem Frequenz-Sketch per ISP flashen und die eigegentliche HM-Firmware per dann hoffentlich funktionierendem OTA?

Nein, der Bootloader ist derzeit noch außen vor.
Du spielst den FreqTest.ino auf und startest den Scan. Am Ende wird das Ergebnis automatisch ins EEPORM geschrieben. Dann spielst Du den Bootloader drauf inklusive der Firmware. Fertig. Es muss nur darauf geachtet werden, dass beim Flashen der EEPROM nicht gelöscht wird (EESAVE Fuse). Das ist aber standardmäßig nicht aktiviert.

[Tom Major]

Sehr cooles Feature, vielen Dank an papa. 
Irgendwann wird es wahrscheinlich jeden mit den CC1101 Modulen erwischen, nur eine Frage der Menge der verwendeten Module.
Man könnte so auch funktionierende Module/Geräte optimieren (die mit sehr schlechten RSSI Werten) .

[papa]

Man könnte so auch funktionierende Module/Geräte optimieren (die mit sehr schlechten RSSI Werten) .

Die RSSI Werte ändern sich übrigens nicht bis wenig. Also entweder es wird etwas empfangen oder nicht.
Aber man kann trotzdem alle Sender dichter zusammen bringen.

[tndx]

Hi,

Danke für Deine ausführliche Antwort und natürlich für das neue Feature!

Oder man patcht die Werte direkt in den Bootloader.

Das würde aber auch eine neue Checksumme erforderlich machen, oder betrifft das nur den Datenbereich?

Eine Frage hätte ich noch dazu:

Der Testsketch verhält sich im Standardfall passiv. Da bedeutet, dass nur versucht wird, Pakete zu empfangen. Wurde nach einer Minute (einstellbar durch SCANTIME) nichts empfangen, wird die Frequenz gewechselt. Um sicher zu stellen, dass auch Nachrichten empfangen werden können, sollten während des Scans irgendein Gerät geschaltet werden.
Durch Setzen des ACTIVE_PING Defines, kann der aktive Modus eingeschaltet werden. Dann sendet der Sketch jede Sekunde eine Statusmessage. Hierzu sind sind die PING_FROM und PING_TO IDs entsprechend der eigenen Umgebung anzupassen. PING_FROM sollte eine gepairtes Geräte sein - z.B. Steckdose. PING_TO ist die Zentrale/FHEM/CCU. Das Scannen sollte jetzt viel schneller gehen, da eine Antwort von der Zentrale angefordert wird.

Natürlich will ich den Scan beschleunigen und würde gerne den aktiven Modus benutzen. D.h.:
- HMID PING_TO(0x99,0x66,0x99) ersetze ich durch die HMID meiner VCCU?
- HMID PING_FROM(0x12,0x34,0x56) ersetze ich durch die HMID irgeneines mit der VCCU gepairtes Devices?
- Die Statusmeldungen erscheinen dann auch in FHEM-Eventlog? Kann ich an den Meldungen erkennen, was jetzt als optimale Frequenz erkannt wurde (dann kann ich mir ja den seriellen Monitor sparen)?

Und auch wenn's hier OT ist: kann den Sketch mit der Arduino-IDE kompileren und dann die HEX-Datei wie gehabt, mit den gleichen Fuses-Einstellungen mit avrdude auf der Kommandozeile flashen? Oder muss ich noch irgendwas beachten?

Danke schon mal im Voraus!

[papa]

Natürlich will ich den Scan beschleunigen und würde gerne den aktiven Modus benutzen. D.h.:
- HMID PING_TO(0x99,0x66,0x99) ersetze ich durch die HMID meiner VCCU?

Richtig

- HMID PING_FROM(0x12,0x34,0x56) ersetze ich durch die HMID irgeneines mit der VCCU gepairtes Devices?

Ja - es muss aber ein Gerät sein, welches STatusmessages sendet. Steckdose geht gut. Fensterkontakt sollte auch gehen.

- Die Statusmeldungen erscheinen dann auch in FHEM-Eventlog? Kann ich an den Meldungen erkennen, was jetzt als optimale Frequenz erkannt wurde (dann kann ich mir ja den seriellen Monitor sparen)?

Nein - im Eventlog siehst Du nur die Statusupdates. Wenn Du die Werte haben willst, muss eine serielle Konsole ran.

Und auch wenn's hier OT ist: kann den Sketch mit der Arduino-IDE kompileren und dann die HEX-Datei wie gehabt, mit den gleichen Fuses-Einstellungen mit avrdude auf der Kommandozeile flashen? Oder muss ich noch irgendwas beachten?

Es kann genau so wie die anderen Sketche behandelt werden.