Fehlerhafte CC1101 Module

[Pek]

Guten Abend,

ich habe hier mittlerweile ein 2. Exemplar von einem CC1101, was sich zwar komisch verhält, aber anders komisch, als die bereits bekannten CC1101 mit einer Frequenzverschiebung. Das Funkmodul sendet auf der vorgesehenen Frequenz und wird ohne Probleme von meinem FHEM empfangen, "hört" aber nicht die Antworten. So ist z.B. kein Pairing möglich, senden der Zustände funktioniert dagegen problemlos. Ich habe testhalber den Frequenztest-Sketch laufen lassen:

Code: [Auswählen]

AskSin++ V4.1.1 (Oct 23 2019 22:53:10)
                                                          CC init1
                                                                  CC Version: 04
                                                                                - ready
       Start searching ...
                          Freq 0x21656A:   0/0
                                              Freq 0x2165BA:   0/0
                                                                  Freq 0x21651A:   0/0
      Freq 0x21660A:   0/0
                          Freq 0x2164CA:   0/0
                                              Freq 0x21665A:   0/0
                                                                  Freq 0x21647A:   0/0
      Freq 0x2166AA:   0/0
                          Freq 0x21642A:   0/0
                                              Freq 0x2166FA:   0/0
                                                                  Freq 0x2163DA:   0/0
      Freq 0x21674A:   0/0
                          Freq 0x21638A:   0/0
                                              Freq 0x21679A:   0/0
                                                                  Freq 0x21633A:   0/0
      Freq 0x2167EA:   0/0
                          Freq 0x2162EA:   0/0
                                              Freq 0x21683A:   0/0
                                                                  Freq 0x21629A:   0/0
      Freq 0x21688A:   0/0
                          Freq 0x21624A:   0/0
                                              Freq 0x2168DA:
                                                             Done: 0x21656A - 0x21656A
      Could not receive any message  0/0

                                        Done: 0x21656A - 0x21656A
                                                                 Could not receive any message

Mein FHEM bekam dagegen viele, wenn nicht alle dieser Anfragen mit, ich habe die entsprechenden Ausgaben im Event-Monitor gesehen.

Ich schließe zwar nicht aus, dass irgendwas an meinem Hardware-Aufbau nicht stimmt, aber ich hatte schon mal ein ähnliches Problem mit einem Funkmodul aus der gleichen Lieferung, das habe ich damals nicht weiter verfolgt. Kann sich jemand einen Reim drauf machen?

[Pek]

Keine Abschirmung/kein Pairing. Ich hatte inzwischen auch einige Module die zwar Daten empfangen können, aber nicht mit einer Zentrale angelernt werden konnten, bei mir rumliegen. Und einen dicken Hals. Freqenztest funktioniert einwandfrei. Dann bekam ich ein Modul von Makershop, der ließ sich anlernen, manchmal mußte man zwei mal auf den config Button drücken. Unterschied war? Bei gleicher Bauweise, war bei Makershop Modul ein TI Chip verarbeitet (CC Version 1.4), bei den anderen kann man es trotz Lupe kaum lesen. Aber definitiv kein TI Chip (CC Version 04). Am besten waren aber noch alte original hm Module, wegen der Abschirmung? Leider habe ich kein hf Labor. Ich habe mir also selber eine Abschirmung gebastelt. Erst Schrumpfschlauch, dann Alufolie und anschließend Alufolie mit Masse verbunden. Und siehe da ALLE Module laufen einwandfrei.

[Horti]

ich habe hier noch einige Platinen für Dirks-Universalsensor, aber nur fehlerhafte CC1101-Module. Da die 0.15-Firmware es immer noch anstandslos tut, würde ich sie auch gerne weiterhin einsetzen. Kann mir jemand bitte sagen, an welcher Stelle ich die Frequenz patchen kann? Für den Bootloader hat das papa ein paar Seiten vorher erklärt, aber das scheint nicht analog für die Firmware zu gelten.

https://github.com/kc-GitHub/Wettersensor/blob/master/Firmware-Release/HB-UW-Sen-THPL_update_V0_15_000_150303.hex

[Horti]

Wo ich gerade schon dabei bin: läuft der Frequenztest-Script auch auf einem Atmega 1284P? Ich habe hier ja noch ein HB-Dis-42BW, dessen Funkmodul ich auch im Verdacht habe, nicht auf der richtigen Frequenz zu senden.

[Tom Major]

Wo ich gerade schon dabei bin: läuft der Frequenztest-Script auch auf einem Atmega 1284P? Ich habe hier ja noch ein HB-Dis-42BW, dessen Funkmodul ich auch im Verdacht habe, nicht auf der richtigen Frequenz zu senden.

ja, das tut er.

[Horti]

Kann mir jemand bitte sagen, an welcher Stelle ich die Frequenz patchen kann?

Hilfsweise nehme ich auch Hinweise entgegen, an welcher Stelle im Code die Frequenz eingestellt wird. Ich könnte ja dann immerhin versuchen, mit geänderter Frequenz zu compileren, auch wenn ich nicht weiß, ob die aktuellen Toolversionen mit dem Quellcode zurechtkomen 

[Horti]

ja, das tut er.

Nun, das kann ich zumindest bestätigen. Allerdings muss man den Sketch natürlich für den 1284p neu kompilieren und die Pinbelegung anpassen. Mag zwar für einen erfahrenen Entwickler selbstverständlich sein, mir hat es aber ein paar zusätzliche graue Haare beschert

Leider bin ich bei der Ermittlung der Stelle, wo man in der Hex-Datei die Frequenz patchen kann immer noch nicht weiter. Ich weiss zwar mittlerwiele, wo man in der NewAskSin-Lib die Standard-Freqenz verändern kann, aber ich würde dennoch gerne ohne Neukompilieren auskommen   

[Tom Major]

Leider bin ich bei der Ermittlung der Stelle, wo man in der Hex-Datei die Frequenz patchen kann immer noch nicht weiter. Ich weiss zwar mittlerwiele, wo man in der NewAskSin-Lib die Standard-Freqenz verändern kann, aber ich würde dennoch gerne ohne Neukompilieren auskommen   

Wo ist denn genau die Stelle für die Frequenz?
So kommst du zum Ziel:
Standardfrequenz in der sketch source suchen, in hex umrechnen, diese bytes dann im hex file suchen, dabei beachten das der AVR assembler load Befehl ggf. nicht die ganzen 24bit der Freq. auf einmal laden kann. Und am Ende nicht vergessen die checksum der Zeile im hex file auch anzupassen wenn du dort patchst.

[Horti]

Hallo,

lang ist's her, aber noch immer nicht ausgestanden Folgende Erkenntnisse habe ich:
1) Hier ist die Stelle im Source-Code des OTA-Bootloaders:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader/blob/master/cc.c#L22
Zu dem Bootloader sagte papa mal in diesem Thread, man solle Ausschau nach dem String "0D210E650F50" halten und die Frequenz entsprechend anpassen. Diesen String finde ich aber weder hier:
https://github.com/pa-pa/AskSinPP/blob/master/bootloader/avr/Bootloader-OTA-atmega328.hex
noch hier:
https://github.com/kc-GitHub/Asksin_OTA_Bootloader/blob/master/Bootloader-AskSin-OTA-HB_UW_Sen_THPL.hex
2) Hier ist die Stelle im Source-Code, wo die Frequenz gesetzt wird:
https://github.com/kc-GitHub/AskSin/blob/master/utility/cc110x.cpp#L71
Den o.g. String finde ich aber hier:
https://github.com/kc-GitHub/Wettersensor/blob/master/Firmware-Release/HB-UW-Sen-THPL_update_V0_15_000_150303.hex#L12

Die Preisfrage wäre, kann ich davon ausgehen, dass es die richtige Stelle in der Firmware-Hex ist? Warum ist die Stelle nicht in den Bootloadern zu finden, obwohl es wohl schon mal funktioniert haben soll? Oder bin ich ganz falsch abgebogen?

[Klaus0815]

Schau doch mal hier im Thread auf Seite 5 - Beitrag von Uwe

Kannst es nicht dementsprechend ändern?
Oder hat sich hier mittlerweile was geändert?

[Horti]

Nee, Du, die Stelle kenne ich ja, aber dafür müsste ich neu kompilieren, und genau den Aufwand würde ich mir gerne ersparen bei dem 5-6 Jahre alten Code. Geht ja auch nicht nur um den Code, sondern auch um die Compiler-Version von damals u.s.w. Mag sein, dass das alles nicht so kritisch ist, aber ich dachte 50 durch CA in der Frequenzeinstellung zu ersetzen müsste doch einfacher gehen. Zumal es schon mal funktioniert haben soll.

Ich habe jetzt noch weiter "gespielt". Wenn ich mit papas makeota.html eine OTA-Bootloader-Hex erstelle, dann gibt es darin gar keinen "0D210E650F50". Wenn ich die Universalsensor-FW 0.15 dranhänge (immer noch mit papas makeota.html), dann taucht diese Zeichenkette da auf, aber sie stammt dann wohl von der Universalsensor-FW. Ersetze ich 50 durch CA, passe die Checksumme und flashe die Datei, dann funktioniert der Sensor nicht. Er blinkt zwar am Anfang 6 mal oder so, also die Blinksequenz von dem Bootloader, es kommt danach aber nichts Brauchbares. Keine Anlern-Message, keine Helligkeitswerte.

papa, kannst Du das vielleicht auflösen?

[papa]

Im OTA-Bootloader ist das nicht in einer Zeile sondern geteilt in zwei.

[Horti]

Danke, das macht einiges klarer. Dann hätte aber mein Experiment funktionieren müssen, denn ich habe ja dann wohl an der richtigen Stelle gepatcht. Nächster Schritt wäre wohl die serielle Konsole, oder können die Experten noch weitere Fehler im Versuchsaufbau erkennen?

[Horti]

Und wieder ich
Ich habe an der seriellen Konsole gelauscht:

Code: [Auswählen]

AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot
Was habe ich gemacht:

Wenn ich mit papas makeota.html eine OTA-Bootloader-Hex erstelle, dann gibt es darin gar keinen "0D210E650F50". Wenn ich die Universalsensor-FW 0.15 dranhänge (immer noch mit papas makeota.html), dann taucht diese Zeichenkette da auf, aber sie stammt dann wohl von der Universalsensor-FW. Ersetze ich 50 durch CA, passe die Checksumme und flashe die Datei, dann funktioniert der Sensor nicht. Er blinkt zwar am Anfang 6 mal oder so, also die Blinksequenz von dem Bootloader, es kommt danach aber nichts Brauchbares. Keine Anlern-Message, keine Helligkeitswerte.

Welche Checksumme wird denn vom OTA-Bootloader geprüft?

[Klaus0815]

Warum machst Dir den ganzen Aufwand?
Ich hatte damals die paar Wertegeändert - neu kompiliert
Vermute das geht auch heute noch mit dem 3 Jahre alten Code problemlos?

Vor paar Wochen habe ich mal wieder einen Sensor gebraucht - papa hat da eine geniale Routine um bei fehlerhaften CC1101-Modulen die Korrekturfaktoren raus zu finden und is EEPROM zu schreiben - hat auf Anhien funktioniert