Fehlerhafte CC1101 Module

Begonnen von gloob, 03 Oktober 2018, 21:25:21

Vorheriges Thema - Nächstes Thema

Pek

Zitat von: tndx am 23 Oktober 2019, 23:14:02
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:
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. :D 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

#257
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

Zitat von: Horti am 13 April 2020, 18:22:55
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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Horti

Zitat von: Horti am 13 April 2020, 17:03:12
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

Zitat von: Tom Major am 13 April 2020, 18:34:39
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

Zitat von: Horti am 24 April 2020, 00:05:36

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.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

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.
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

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:
AskSin OTA Bootloader V0.7.0

TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot


Was habe ich gemacht:

Zitat von: Horti am 10 Mai 2020, 22:27:41
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