FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: gloob am 03 Oktober 2018, 21:25:21

Titel: Fehlerhafte CC1101 Module
Beitrag von: gloob am 03 Oktober 2018, 21:25:21
Hallo,

Hat jemand schon einmal schlechte Erfahrungen gemacht mit CC1101 Modulen von Aliexpress? Habe im Moment welche auf einem MapleCUL verbaut und bekomme schlechte RSSI Werte für Homematic (-85).
Ein anderes CC1101 Modul direkt daneben liefert halbwegs brauchbare Ergebnisse.
Kann man die Module irgendwie Testen?

Device          receive         from             last   avg      min_max    count
HM_WZ_Heizung   mapleCUL1       HM_WZ_Heizung    -84.0  -88.8  -95.0< -84.0    10

Gruß
Stefan



Mit folgenden Modulen hatte ich bisher keine Probleme:

https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32630602112.html
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 03 Oktober 2018, 21:39:00
Nach etlichen CC1101 war bisher alles ok. Ich tippe da eher auf eine Anomalie im HF Teil des Moduls. Bestenfalls ist nur ein C oder anderes Bauteil im HF Teil schlecht gelötet, schlimmstenfalls der CC1101 selbst schlecht gelötet oder gar defekt. Kannst auf Verdacht das Hühnerfutter einfach mal nachlöten. Das wäre aus meiner Sicht der schnellste Ansatz zur Funktion, wenn der Fehler nicht sichtbar ist.

Viele Grüße, Ricardo
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 03 Oktober 2018, 21:40:03
Nach etlichen CC1101 war bisher alles ok. Ich tippe da eher auf eine Anomalie im HF Teil des Moduls. Bestenfalls ist nur ein C oder anderes Bauteil im HF Teil schlecht gelötet, schlimmstenfalls der CC1101 selbst schlecht gelötet oder gar defekt. Kannst auf Verdacht das Hühnerfutter einfach mal nachlöten. Das wäre aus meiner Sicht der schnellste Ansatz zur Funktion.

Viele Grüße, Ricardo

Leider habe ich 10 Stück von den Modulen bestellt und auch schon auf unterschiedlichen Platinen verlötet. Fast alle zeigen die gleichen Empfangsprobleme. Ich denke an schlecht gelöteten Teilen kann es nicht liegen.
So wirklich schlecht sehen die Lötstellen auch nicht aus.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 03 Oktober 2018, 22:08:09
Stimmt, sehen normal aus. Und es sind wohl auch mehrere, was meine Idee widerlegt. Wie sehen die Bauteile optisch im Vergleich zu einem funktionierenden Modul aus? Könnte der Hersteller falsch bestückt haben? Zurück nach China gibt es ansich keinen rentablen Weg. Als defekt melden kannst du sie allemal.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: frank am 04 Oktober 2018, 12:04:36
auf dem foto sieht es so aus, als hätten die 3 lötpunkte am rand auf der cc1101 platine vor dem antennenstecker keine verbindung zu den 3 lötpunkten auf der "unteren" platine.

hast du mal den widerstand von der externen antenne zum antennenanschluss auf der cc1101 platine gemessen?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Oktober 2018, 12:44:56
auf dem foto sieht es so aus, als hätten die 3 lötpunkte am rand auf der cc1101 platine vor dem antennenstecker keine verbindung zu den 3 lötpunkten auf der "unteren" platine.

hast du mal den widerstand von der externen antenne zum antennenanschluss auf der cc1101 platine gemessen?

Das sieht nur so aus. Da sind Bohrungen in der Platine und dort ist Lötzinn bis auf die Leiterbahn unten drunter. der Widerstand zwischen Spitze der Antenne und dem Punkt auf der Platine ist bei < 0,1Ohm.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 04 Oktober 2018, 18:13:34
Hi,
Mit CC1101 hätte ich noch keine Probleme, sehr wohl aber mit SMA Steckern.
Kannst Du das ausschließen?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Oktober 2018, 19:29:57
Der Widerstand zwischen der Antennespitze um dem Abschluss am CC11101 beträgt < 0,1 Ohm. Also gehe ich davon aus, das an der Stelle alles okay ist. Ich habe jetzt neue CC1101 bestellt und werde mal testen.
 
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 05 Oktober 2018, 12:49:48
Moin!
Ich klinke mich mal ein, da ich aktuell ebenfalls schlechte Erfahrungen mit den 868MHz-Modulen mache.
Vergleiche bitte mal die Platinen aus einer funktionierenden Charge mit denen, die nicht oder mit sehr geringer Reichweite arbeiten.
Ich habe die Beobachtung gemacht, dass die Lötaugen/Bohrungen größer ausfallen als bei den Platinen, die nicht davon betroffen sind.
Das sieht man natürlich am besten, wenn die Module noch nicht verlötet sind, und kann auch nicht die Ursache dafür sein...
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Ranseyer am 05 Oktober 2018, 15:55:10
Ich bin gespannt auf eure weiteren Erfahrungen...

Übrigens sind die beiliegenden Antennen häufig sehr schlecht.

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 05 Oktober 2018, 15:59:01
Kann ich in meinem Fall ausschließen. Wobei mir bei den beiliegenden Antennen bewusst kein derart gravierender Unterschied aufgefallen ist.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 06 Oktober 2018, 12:32:51
Ich habe hier mal drei Module verschiedener Quellen verglichen, und man kann recht eindeutig erkennen, dass das Modul von @gloob jenes ist, das auch bei mir nicht funktioniert. Vergleicht mal den Schriftzug, es gibt nur ein sehr schmales Leerzeichen zwischen "MHz" und "Module".
Ich habe diese Module bereits von zwei verschiedenen Verkäufern (TEN*** und XM***) auf Ali erhalten, und die Fehlerrate liegt bislang bei 100%.
Kann möglicherweise der Unterschied beim Aussehen der SMD-Teile im Antennenkreis etwas damit zu tun haben (rot markiert)? Habe mich da noch nicht soweit eingelesen, um den fehlenden schwarzen Punkt beurteilen zu können.

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 06 Oktober 2018, 12:34:07
Ich habe hier mal drei Module verschiedener Quellen verglichen, und man kann recht eindeutig erkennen, dass das Modul von @gloob jenes ist, das auch bei mir nicht funktioniert. Vergleicht mal den Schriftzug, es gibt nur ein sehr schmales Leerzeichen zwischen "MHz" und "Module".
Ich habe diese Module bereits von zwei verschiedenen Verkäufern (TEN*** und XM***) auf Ali erhalten, und die Fehlerrate liegt bislang bei 100%.
Kann möglicherweise der Unterschied beim Aussehen der SMD-Teile im Antennenkreis etwas damit zu tun haben (rot markiert)? Habe mich da noch nicht soweit eingelesen, um den fehlenden schwarzen Punkt beurteilen zu können.

Genau die Module mit den "26.000 MHz" sind es auch bei mir, die nicht laufen. Werd mich jetzt mal mit dem Support auseinander setzen.
Leider kann ich bei Aliexpress keinen Dispute mehr öffnen, da ich bereits gemeldet habe ich Module erhalten zu haben. Jetzt muss ich auf die Kulanz des Verkäufers hoffen. Den "TENSTAR Store" werde ich allerdings in Zukunft meiden.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 06 Oktober 2018, 13:18:21
Mit Kulanz hatte ich kein Glück - habe ein Disput eröffnet und die Erstattung prompt via Ali erhalten.
Der Store wollte ein Video von mir, und hat, nachdem er dieses bekam, sich nicht mehr gemeldet.
Mal sehen, wie es bei XM... läuft.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 06 Oktober 2018, 13:24:56
Ich hab jetzt 2 der "fehlerhaften" CC1101 Module ersetzt durch welche von "Nodely" und die Sensoren ließen sich direkt ohne Problem OTA flashen.



Lediglich an meinem MapleCUL hat es keine Verbesserung gebracht. Dort sind die RSSI Werte immer noch unterirdisch (> -80). Da muss ich aber nochmal gucken ob es nicht vielleicht an der Antenne liegt.

Edit:
Das Problem konnte ich jetzt auch noch lösen. MapleCUL_2 ist mit dem CC1101 Modul mit 868MHz verbunden. Ich bin im Moment die ganze Zeit von MapleCUL_1 ausgegangen  ::)
Wahrscheinlich hätte ich dort garnicht den CC1101 ersetzen müssen  :'(
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: frank am 06 Oktober 2018, 20:22:56
Zitat
Wahrscheinlich hätte ich dort garnicht den CC1101 ersetzen müssen
dann sollte man das bashing der händler eventuell etwas "zurückschrauben".  ;)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 06 Oktober 2018, 21:14:54
dann sollte man das bashing der händler eventuell etwas "zurückschrauben".  ;)

Zwei wirklich defekte Module von drei ist auch noch nicht akzeptabel.

Ich werde das besagte Modul aber auch noch einmal mit einem Sensor testen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 06 Oktober 2018, 23:55:50
Falls es Euch interessiert: ich habe hier (https://forum.fhem.de/index.php/topic,71413.msg843242.html#msg843242) auch ein Problem, wofür vermutlich auch ein CC1101-Funkmodul aus dem "TENSTAR Store" verantwortlich ist. Die Fehlfunktion ist zwar nicht so offensichtlich, wie bei Euch, aber anders kann ich mir im Moment das Problem nicht erklären.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 11 Oktober 2018, 10:05:22
Ich habe hier auch noch was zu Problemen mit dem CC1101 gefunden.
https://www.mikrocontroller.net/topic/74201#641706
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 13 Oktober 2018, 17:46:09
Hi tndx,
danke, das interessiert - also noch ein TENSTAR-geplagter (in dem Thread hast du ja geschrieben, dass es nach Austausch des Moduls funktioniert).

Ich hatte auch schon den Verdacht, dass bestimmte Parameter bei diesen Funkmodulen einfach daneben liegen. Soweit ich gelesen habe, kann man im rfmode für Homematic aber nicht eingreifen, ohne die Firmware dazu zu verändern? Und dazu fehlt mir momentan sowohl die Zeit als auch die Bereitschaft, die Fehler des Herstellers auszubügeln.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 15 Oktober 2018, 19:44:47
Habe auch 2 x 5 Stück über EBAY bestellt - diese hier gehen nicht:


Sehen auch irgendwie wie handgelötet aus, auch die CHipbeschriftung ist merkwürdig
Verkäufer meinte, ich soll ihm Videos hochladen was ich damit mache :-)

Wobei ich auch 2 andere, funktionierende Module habe - auch dort sind die ICs eher schwarz beschriftet, in Deinen Bildern eher weiss?


Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 15 Oktober 2018, 23:30:37
Moin Klaus0815,

ist die Rückseite bei deinem Modul grün?
Normalerweise ist diese ja großflächig weiß bedruckt.

Was auffällig ist, ist die Beschriftung des Quarz:
Wie bei @gloob „26.000 MHz“

Sehen die beiden funktionierenden Module exakt genauso aus?

Das mit dem Video ist meines Erachtens nach Hinhaltetaktik. Nachdem ich das Video hochlud, kam keine Reaktion mehr. Ich glaube, die hoffen darauf, dass man den Auswand scheut oder die Sache vergisst, oder zögern es hinaus bis der Beschwerdezeitraum abgelaufen ist.
1 Woche nach dem Hochladen des Videos habe ich jeweils den Disput eröffnet, der prompt als „Refund only“ akzeptiert wurde.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 16 Oktober 2018, 18:39:37
Habe 3 verschiedene CC!!01-Platinen, 2 funktionieren, eine nicht, aber bei allen 3 ist die Rückseite nicht weiss / bedruckt, sondern einfach nur das PCB der Platine

In der Tat sind wie bei Gloob bei den nicht funktionierenden die Quarzoszilatoren 26 MHz beschriftet, wobei 26 MHz eigentlich ja korrekt ist?

Werden in den Libraries, die hier benutzt werden, überhaupt alle Register des CC1101 beschrieben? (Frequenzeinstellung usw) oder sind evtl die nicht funktionierenden einfach auf eine falsche Frequenz eingestellt?

 

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: fritzla am 24 Oktober 2018, 21:02:12
Mir ist bei meinem (defektem) Modul aufgefallen, dass die Frequenz vom Quarz nicht sehr stabil ist. Oder ist das normal, dass die so stark schwankt?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 24 Oktober 2018, 22:39:06
Moin fritzla,
kannst du auch ein Foto von deinem Modul senden, insbesondere Beschriftung des Quarz?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: fritzla am 24 Oktober 2018, 23:33:18
Das sieht genau so aus wie das rechte Modul in einem deiner vorherigen Posts, mit dem geringen Abstand im Text und den 26.000 MHz auf dem Quarz. Die Rückseite ist weiß.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 24 Oktober 2018, 23:45:21
Mist. Von dem Händler habe ich am 1.10. noch funktionierende Module erhalten. Das ist echt eine Seuche, und wir täten gut daran, eine Lösung zu finden.

Schwankende Frequenzen habe ich noch nicht beobachtet, wohl aber eine zu stark daneben liegende Frequenz. Werde noch Bilder posten.
Welche Möglichkeiten gibt es, die Frequenz zu korrigieren?
Mit einem Tool von TI? (wäre besser)
Mit einer Anpassung der Culfw Firmware (da ja die Frequenzeinstellung im hm-Modus nicht geht)? (wäre Herumdoktern am Symptom)
Per Register?

Wenn die Frequenz allerdings schwanken sollte, hilft auch kein Offset...
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: fritzla am 25 Oktober 2018, 00:12:52
Die mittlere Frequenz vom Quarz auf meinen board stimmt ja, auch die mittlere Sendefrequenz, aber beide schwanken bei mir viel zu stark, weshalb ich den Quarz in Verdacht habe. Meine Sendefrequenz liegt bei 868,29 +- 0,5 MHz.
Ich warte im Moment noch auf ein neues Modul um das zu verifizieren.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 25 Oktober 2018, 05:41:48
Wenn jemand Interesse hat kann er gerne von mir fehlerhafte Module haben. Ich habe meine jetzt durch neue ersetzt.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: stan23 am 25 Oktober 2018, 09:23:17
Mir ist bei meinem (defektem) Modul aufgefallen, dass die Frequenz vom Quarz nicht sehr stabil ist. Oder ist das normal, dass die so stark schwankt?
Die Frequenzstabilität bei meinen CC1101-Modulen habe ich mir zwar noch nie angeschaut, aber was du da misst ist wirklich unterirdisch.

Ich vermute die Quarzoszillatoren sind Ausschuss der dann doch verbaut wurde.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 25 Oktober 2018, 09:24:56
Könnte man die Quarze selber tauschen? Ich würde es ja mal auf einen Versuch ankommen lassen. Hab ja noch 3 ausgelötete "defekte" Module hier liegen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: stan23 am 25 Oktober 2018, 09:26:41
Das kommt auf deine Lötküste an :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 25 Oktober 2018, 09:27:33
Das kommt auf deine Lötküste an :)

Naja so klein sind die ja nicht. Auf jede Ecke nen Klecks Lötzinn und dann drauf mit dem neuen.

Hat zufällig jemand die Abmessungen von dem Ding? Bin leider im Moment auf Arbeit.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 25 Oktober 2018, 09:54:24
3,2mm x 2,5mm
Auslöten relativ gut machbar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 27 Oktober 2018, 20:11:13
Guten Abend,

ich habe offenbar auch ein paar von den betroffenen Modulen erwischt. Würde sie gerne bei Aliexpress reklamieren, gibt es irgendwelche schlüssige Argumente, außer "geht nicht in meiner Umgebung"? Über professionelles Equipment verfüge ich leider nicht.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 27 Oktober 2018, 22:11:26
Moin Horti,
da trifft es sich, dass ich doch sowieso noch Bilder vom Frequenzspektrum posten wollte, die Bilder kannst du als "evidence" bei Aliexpress hochladen. Habe noch einen DVBT-Stick rumfliegen gehabt, der nun endlich zum Einsatz gekommen ist ;)

Ich habe vier verschiedene Module getestet, 2 die IO sind und 2 die NIO sind (sowohl die Bauform mit den "großen Löchern" von TENSTAR und anderen, als auch die Bauform mit der grünen Rückseite, die Klaus0815 erwischt hat).
Als "Referenz" habe ich ein HomeMatic Wandthermostat genommen. Ich habe zuerst den Wandthermostat eine neue Temperatureinstellung senden lassen, und kurz darauf über FHEM einen regSet-Befehl an den Thermostat gesendet. So sieht man einmal das Spektrum des Thermostat und einmal das des jeweiligen cc1101 zum Vergleich.
Ich bin selbst kein Funktechniker und weiß auch nur, was ich sehe, aber die Abweichung der Frequenz scheint mir doch deutlich zu sein. Ich frage mich, ob man dies per Software ausbügeln kann, oder ob der Quarz getauscht werden muss (falls das überhaupt ohne weiteres Kalibrieren des cc1101 zum Erfolg führen kann).
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 27 Oktober 2018, 23:29:27
Hallo Dartrax,

Kompliment, das hast sehr schön aufbereitet

Habe auch noch irgendwo nen SDR-Stick rumliegen, und morgen soll es ja regnen, vielleicht mach ich mich auch mal dran

Mit welcher Software hast das gemessen?

Viele Grüße

Klaus

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dartrax am 27 Oktober 2018, 23:43:59
Danke!
SDR#.
Im Prinzip die Anleitung von Funkleuchtturm befolgen:
https://homematic-forum.de/forum/viewtopic.php?t=11087&start=24
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 28 Oktober 2018, 09:21:47
Danke Dartrax! SDR wollte ich mir auch ansehen, stelle ich mir allerdings schwierig vor in einem Haus voller HomeMatic- und LaCrosse-Sensoren  :-\

Aber was viel wichtiger ist: hat jemand eine verlässliche Quelle für die 868er CC1101-Module (China/Deutschland)? Tenstar store werde ich wohl für längere Zeit meiden.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 28 Oktober 2018, 16:41:37
Dartrax, danke für die Messungen.

Mein Tip geht (wiederholt) in Richtung Lastkapazitäten des Quarzes. Wenn die nicht zum Quarz passen, läuft der ganze Laden nicht so gut. Einfach mal zum Thema googeln; es gibt genügend Abhandlungen dazu.

Mein Ansatz wäre: das "Standardprogramm" testen, also die beiden vorhanden Cs auslöten, evtl vermessen (nicht jeder kann so kleine Werte genau genug  messen) und dann mit 2x 12p, 2x 15p, 2x 18p, ... testen und messen, bis die Frequenz passt. Da der Quarz selbst vorerst unbekannt ist, sehe ich das als die schnellste, preiswerteste und platinenschonendste Variante.

Edit: Wenn die Frequenz dann stimmt, sollte generell nochmal vergleichend ein Test gefahren werden, ob die Sende- und Empfangsleistung des Moduls dem Gewohnten entspricht. Falls auch hier noch Differenzen auftreten, wurden im HF-Teil offenbar auch noch falsche oder minderwertige Bauteile eingesetzt. Aber zuerst muss die Basis stimmen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Gernott am 28 Oktober 2018, 17:45:42
Aber was viel wichtiger ist: hat jemand eine verlässliche Quelle für die 868er CC1101-Module (China/Deutschland)?
Im August hatte ich noch zwei von Tenstar, die laufen mit Testplatinen ohne Probleme.
Im  September habe ich 4 Stk. von Module Sky bestellt, die sehen den "defekten" nicht ähnlich (siehe Bild). Eines habe ich auf einer Platine ohne FW, da scheint nach einem kurzen Check mit SDR die Frequenz zu passen.

CC1101-Modul kann man übrigens selektiv empfangen, wenn man die Antenne vom DVB-T-Stick abzieht und das Modul in die Nähe seines Antenneneingangs legt. Dann empfängt man nichts aus der Umgebung und sieht nur das Modul.

Gruß
G.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 28 Oktober 2018, 19:00:20
Hab auch mal ein bisschen mit der SDR-Software rumgespielt

Ja, die nicht funktionierenden senden bei ca. 868.2 MHz, anbei ein paar FOtos
- original HM-Fernbedienung
- 2 verschiedene funktionierende Nachbauten
- ein nicht funtionierender Nachbau


Bin mir aber nicht sicher ob das wirklich am Quarz / den Kondensatoren drum rum liegt

auf die Schnelle habe ich z.B. gefunden:
http://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/84089?Frequency-of-the-auto-calibration-of-the-CC1101-RF-radio-chip-# (http://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/84089?Frequency-of-the-auto-calibration-of-the-CC1101-RF-radio-chip-#)

Welche Software / Library benutzt ihr zum testen?
Bei mir die AskSIn++ von papa

VIelleicht wird hier auch einfach was nicht richtig initialisiert?

auch interessant:
http://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/65448?CC1101-26MHz-CRYSTAL-PROBLEM- (http://e2e.ti.com/support/wireless-connectivity/other-wireless/f/667/t/65448?CC1101-26MHz-CRYSTAL-PROBLEM-)

wobei auch hier mal von falschen Kondensatoren gesprochen wird, mal das Problem angeblich per Software gelöst werden kann

Viele Grüße

Klaus




Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: deimos am 28 Oktober 2018, 19:05:16
Hi,

wenn man den Quarz betrachten will, kann man sich an GD0 oder GD2 auch den Takt (oder einen Teiler davon) ausgeben lassen und direkt an einem entsprechend schnellen Oszi anschauen.

Viele Grüße
Alex
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: fritzla am 29 Oktober 2018, 15:16:22
Oder man greift ihn direkt ab ;-)

Anbei das Bild wie oben, aber jetzt mit einem funktionierenden Modul.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 11 November 2018, 10:29:06
Guten Morgen,

ich habe noch mal meine Module von Tenstar untersucht. Ich habe hier 10 Module, die ich paarweise im Zeitraum Sept. - Okt. gekauft habe. Davon waren 2 wohl ganz kaputt. Die restlichen wiesen beim Senden, gemessen mit dem SDR-Stick, keine Frequenzverschiebung auf. Trotzdem hat mindestens ein Modul Schwierigkeiten, wie hier (https://forum.fhem.de/index.php/topic,71413.msg843242.html#msg843242) beschrieben (Das Problem besteht hier mittlerweile auch mit FHEM). Das bringt mich zu dem Schluss, dass zumindest bei mir das Problem nicht beim Senden, sondern beim Empfangen besteht. Wie passt das ich Eure Theorie mit kaputtem Quarz / falsch dimensionierten Kondensatoren?

Was/wie könnte ich in diesem Zusammenhang noch testen?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 11 November 2018, 10:41:25
Moin,
These: Die Frequencies sind okay, aber die Registereinstellungen nicht.
Kann man alle Register auslesen und ein Diff machen?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 11 November 2018, 10:48:58
Zitat
These: Die Frequencies sind okay, aber die Registereinstellungen nicht.

Oder aber es werden bestimmte Register nicht gesetzt, die Toleranzen ausgleichen, manche CC1101 sind halt ohne diese Registern innerhalb der Toleranz, andere nicht.
Ich vermute, die meisten hier nutzen die CC1101 mit der ASKSIN-Library?

Hat jemand schon mal versucht, ein >"defektes" Modul in ein Original-HM-Gerät einzulöten?

Viele Grüße

Klaus
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 07 Dezember 2018, 16:27:31
Hallo, habe gestern eine Lieferung Module bekommen. Heute 5 Stück getestet und festgestellt, dass keines "Empfangen" kann.
Senden auf einem nanoCUL geht einwandfrei, aber in FHEM jedesmal "MISSING ACK" weil nix zurück kommt.

Die SMD-Widerstände auf dem Modul haben auch eine andere Anordung als die mir bekannten. Habe bei der Bestellung nicht drauf geachtet.
Was habe ich denn hier erwischt? Kennt ihr die Dinger? Muss ich wohl alle zurück schicken, oder?

Gruß
Thomas
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 07 Dezember 2018, 19:05:37
Ich kenne die Dinger zwar nicht, aber die Symptome sind die gleichen wie von meinen von TENSTAR. Wo hast Du sie denn gekauft?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 07 Dezember 2018, 19:22:31
ich glaube / vermute weiterhin, das die Probleme nicht an den Modulen an sich liegen, sondern irgend was wird fehlerhaft initialisiert oder dergleichen

Hab leider gerade keine freie Hardware rumliegen, sonst würde ich mal eins der Defekten in ein Original-HM-Gerät einbauen, das Resultat würde mich interessieren
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 07 Dezember 2018, 20:16:05
Meine Module, welche gestern in der Post waren, sehen so aus:

Die Funktion wurde aus Zeitgründen noch nicht getestet, der Lieferant ist "arduino_fans" in der Bucht.

Edit: funktionieren beide einwandfrei. Und warum habe ich nur zwei bestellt?  ??? :-[
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 07 Dezember 2018, 20:44:46
Hallo Leute,

wenn Ihr die Module mit Arduinos nutzt, dann könnt Ihr mal die tsculfw für nanoCUL probieren. Denn damit kann man den Frequenzoffset der Empfangs-/Sendefrequenz anpassen. https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466 (https://forum.fhem.de/index.php/topic,24436.msg175466.html#msg175466)

Das hatte ich mal eingebaut, um ein Finetuning zu ermöglichen, nachdem ich mit HDSDR bemerkt hatte, dass meine HM devices etwa -25kHz verschoben zu meinen CULs liefen.
Mit set hmFreqOffs aus FHEM heraus lässt sich der Offset im rfmode HomeMatic um -203.125 bis +201.538 kHz anpassen. Der Offset wird dann auch im EEPROM gespeichert, bleibt also.

Die Möglichkeit gibt es derzeit nur bei der tsculfw, so weit mir bekannt, wäre aber sicherlich auch bei culfw, a-culfw etc. relativ leicht "nachrüstbar".

Das hilft natürlich nur was, wenn man eine Möglichkeit hat, die Sendefrequenz zu messen, respektive mit regelmäßig sendenden HM devices zu vergleichen. Die genutzte Bandbreite ist recht schmal (~100kHz), so dass man schon recht gut treffen muss, respektive sich auch mit dem Offset oder schlechtem Quarz "rausschießen" kann.

Hier https://forum.fhem.de/index.php/topic,93193.msg859544.html#msg859544 (https://forum.fhem.de/index.php/topic,93193.msg859544.html#msg859544) hat der Offset mal darki2002 geholfen, nachdem mein Standardoffset für sein CUL wohl genau in die falsche Richtung lag.

Gruß, Ansgar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 07 Dezember 2018, 22:09:28
@kpwg: Deine Module sehen schonmal optisch gut aus. Der Quartz hat die richtige Beschriftung. Die SMD's sind korrekt und die Rückseite ist sicherlich weiß.
Somit sollten die auch funktionieren.

@noansi:
Womit kann ich die Sendefrequenz messen?
Ich habe hier jede Menge HM Geräte. Da wird ständig etwas gesendet und meinen Rolladen kann ich sowieso ständig hoch/runter bewegen und der sendet dann die Position zurück.
 
Titel: Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 07 Dezember 2018, 23:22:11
Hi,
Man sieht die Frequenzen schön mit einem SDR (z.B. alter DVB-T USB Stick mit RTL2832 Chip). Unter Windows mit SDRSharp!?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 08 Dezember 2018, 01:18:48
Hallo thgorjup,

wie RaspiLED schon schrieb, DVB-T USB Stick mit RTL2832 Chip, und HDSDR als Software unter Windows. HDSDR läuft stabiler und flüssiger.

Gruß, Ansgar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 09 Dezember 2018, 10:16:10
Prima, hab mir in der Bucht so einen Stick bestellt. Sobald der kommt, mach ich mich ans Werk.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 11 Dezember 2018, 12:57:51
@noansi: Ich habe die tsculfw Firmware geflashed aber das klappt nicht. Ich kann zwar Intertechno-Steckdosen damit schalten aber mein HM-Rolladen reagiert garnicht darauf. Ich konnte auch die Frequenz nicht anpassen.

set nanoCUL hmFreqOffs 0

Daraufhin erfolgt eine Fehlermeldung. (Ausgabe gerade nicht zur Hand)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 11 Dezember 2018, 20:55:21
Hallo thgorjup,

Zitat
Daraufhin erfolgt eine Fehlermeldung. (Ausgabe gerade nicht zur Hand)
Die Glaskugel ist damit auch gerade aus gegangen.
Fehlermeldung?
List vom nanoCUL?

Hast Du denn auch die Module in den FHEM Ordner kopiert?
Hast Du die nanoCUL Definition auf TSCUL angepasst und ist das Attribut rfmode auf HomeMatic?

Gruß, Ansgar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 13 Dezember 2018, 17:13:58
Heute sind wieder CC1101 Module eingetroffen: Auf den ersten Blick ist es die "neue" Variante. Die Rückseite ist ebenso weiß. Wenn ich richtig sehe, sind die Lötstellen teils recht mies ausgeführt. Als Nächstes werde ich die Frequenz am Quarz im Vergleich messen und zweifelhafte Lötstellen einfach nochmals erhitzen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 13 Dezember 2018, 17:51:46
Heute sind wieder CC1101 Module eingetroffen: Auf den ersten Blick ist es die "neue" Variante. Die Rückseite ist ebenso weiß. Wenn ich richtig sehe, sind die Lötstellen teils recht mies ausgeführt. Als Nächstes werde ich die Frequenz am Quarz im Vergleich messen und zweifelhafte Lötstellen einfach nochmals erhitzen.

Ich warte ja noch auf den ersten, der so ein Modul zum laufen bekommt.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 13 Dezember 2018, 21:32:16
Ich warte ja noch auf den ersten, der so ein Modul zum laufen bekommt.

Ich auch!

Ich habe hier 10+ Module von Tenstar rumliegen, heute sind Module von GREAT WALL Electronics angekommen, die auf den Fotos zwar anders aussahen, tatsächlich aber genau so aussehen, wie die von Tenstar. Getestet habe ich sie nocht nicht.

Interessant ist, dass andere offenbar keine Probleme mit den Modulen haben, zumindest merkt man das nicht an den Bewertungen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 13 Dezember 2018, 23:34:34
Heute sind wieder CC1101 Module eingetroffen: Auf den ersten Blick ist es die "neue" Variante. Die Rückseite ist ebenso weiß. Wenn ich richtig sehe, sind die Lötstellen teils recht mies ausgeführt. Als Nächstes werde ich die Frequenz am Quarz im Vergleich messen und zweifelhafte Lötstellen einfach nochmals erhitzen.

Wolltest du noch einen anderen Lieferanten neben "arduino_fans" ausprobieren? Und wieso "neue" Variante, die 2 fraglichen SMDs haben doch die gleiche Ausrichtung wie die Module von "arduino_fans" oder was ist mit neu gemeint?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 14 Dezember 2018, 00:36:39
Ich glaube zugegeben nicht das man gut / nicht gut an einer Platinenbedruckung ausmachen kann

Bals ist Weihnachten / Urlaub, ich werde dann mal eines der nicht funktionierenden CC1101-Module in ein Original-HM-Gerät einlöten, bin gespannt....
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 15 Dezember 2018, 10:22:35
Wie wäre es denn, wenn wir anstatt fehlerhaften Module, Quellen von funktionierenden Modulen sammeln?

Positive Verlinkungen auf Shops sollten ja erlaubt sein.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 15 Dezember 2018, 10:29:45
Das kann man schon machen. Für mich persönlich spricht dagegen, das ich mit der letzten Lieferung eben nicht exakt die Module bekommen habe, wie auf den Artikelfotos abgebildet waren. Daher kann erst ein vergleichender Test entscheiden, woran es liegt und was genau über "gut" und "schlecht" entscheidet.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 15 Dezember 2018, 10:33:30
Das kann man schon machen. Für mich persönlich spricht dagegen, das ich mit der letzten Lieferung eben nicht exakt die Module bekommen habe, wie auf den Artikelfotos abgebildet waren. Daher kann erst ein vergleichender Test entscheiden, woran es liegt und was genau über "gut" und "schlecht" entscheidet.

Ich habe gerade Module bestellt und erhalten und kann sagen, sie funktionieren. Es ist bisher die dritte Bestellung bei dem Lieferanten.
Also sollte die Wahrscheinlichkeit relativ hoch sein, dass die nächste Bestellung auch wieder klappt.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 15 Dezember 2018, 11:18:20
Hi,

Ich habe gerade Module bestellt und erhalten und kann sagen, sie funktionieren. Es ist bisher die dritte Bestellung bei dem Lieferanten.

kannst Du vielleicht den Namen des Lieferanten posten, gerne auch per PM.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 15 Dezember 2018, 11:20:46
Ich hab den Link von Aliexpress im ersten Post angehangen. Vielleicht können wir ja dort eine kleine Liste erstellen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 15 Dezember 2018, 15:54:02
Hallo,

auch ich habe 10 nicht funktionierende Module bekommen. D.h. auf 433.920MHz funktionieren sie. Laut SDR liegen sie bei 868.300 auf 868.180MHz. Nach dem Auswechseln der beiden Lastkapazitäten gegen 12pF funktioniert ein Testmodul. Original waren 34pF verbaut worden.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Uwe am 15 Dezember 2018, 19:20:10
Hallo,
ich habe auch im September von Tenstar Module gekauft, die erstmal scheinbar nicht funktionierten. Mit SDR hab ich dann rausbekommen, dass die ca. 113 kHz zu niedrig senden, also ca. 868,187 MHz wenn auf 868,3 eingestellt. Das hat meine Homematic Zentrale und auch ein MiniCUL mit einem älteren CC1101-Modul nicht mehr empfangen können.
Meine Original-Homematic-Komponenten funken übrigens auch nicht exakt auf 868,3 sondern ca. auf 868,237 MHz (mit SDR ermittelt).
Ich habe dann also die neuen Module einfach auf 113 kHz höher, also 868,35 MHz eingestellt. Dadurch funken sie jetzt fast exakt auch auf 868,237 MHz und alles funktioniert.

Mit AskSinPP geht das so:

class Hal: public BaseHal
{
public:
   void init(const HMID& id)
   {
      BaseHal::init(id);
      // 2165E8 == 868.35 MHz
      radio.initReg(CC1101_FREQ2, 0x21);
      radio.initReg(CC1101_FREQ1, 0x65);
      radio.initReg(CC1101_FREQ0, 0xE8);
      ...
   }

Die Formel für die Ermittlung der 3 Registerwerte aus der Frequenz:

freq_if = int(freq_carrier * 65536 / freq_osc) = 868,35 * 65536 / 26,0 = 2188776
FREQ2.FREQ1.FREQ0 = hex(freq_if) = hex(2188776) = 0x2165E8

Die erste Charge Module, die noch ordentlich funktionierten, habe ich März 2016 über Ebay von gowin_electronic gekauft.
Jetzt hab ich dort noch mal welche bestellt, mal sehen was das dann für eine Sorte ist.

Ich hoffe, das hilft dem einen oder anderen weiter.

Gruß
Uwe
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 15 Dezember 2018, 19:59:08
Sehr gute Info, alles ist drin, konkrete Anleitung für die Modifikation der AskSinPP Sketche, Formel für die Berechnung der Frequenz, einfach top, Daumen hoch.  :D
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 15 Dezember 2018, 20:04:05
Hey eine Reparaturanleitung! Super ;-) Was sind die beiden Lastkapazitäten genau? Bilder mit Kringeln möglich?

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 15 Dezember 2018, 20:30:28
Vielleicht kann man ja auch einen Testsketch machen, der die Frequenz in einem bestimmten Bereich ändert und jeweils versucht ein Kommand an die Zentrale zu senden. Von der Antwort mit dem besten RSSI Wert wird die Frquenz bzw. die Registerwerte ausgegeben.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 15 Dezember 2018, 21:12:10
Ich habe das mit der Frequenz mal probiert aber bislang keine Besserung:

https://pastebin.com/eNr8wnb5

Es ist ein CC1101 mit exakt dem TI 41l Chip wie im Bild auf Seite 1 von diesem Thread.

Die CCU scheint die Telegramme vom Aktor zu bekommen aber der Aktor erhält kein ACK: https://pastebin.com/rsaRKZir
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 16 Dezember 2018, 09:04:20
Nach dem Auswechseln der beiden Lastkapazitäten gegen 12pF funktioniert ein Testmodul. Original waren 34pF verbaut worden.
Die 12p sind plausibel. Mit 34pF ist es ein Wunder, das der Oszillator überhaupt sauber startet. Daher halte ich auch nicht viel vom Anpassen der Software, um elementare Fehler in der Hardware auszugleichen. Kann funktionieren, hinterlässt aber kein gutes Gefühl...
Ich habe leider daheim derzeit keine Möglichkeiten zu Messungen. Nachwievor ist auch die Quarzfrequenz ansich interessant sowie das Einschwingverhalten unter verschiedenen Temperaturbedingungen.

Hey eine Reparaturanleitung! Super ;-) Was sind die beiden Lastkapazitäten genau? Bilder mit Kringeln möglich?

Ein guter Link zum Thema:https://www.all-electronics.de/wp-content/uploads/migrated/article-pdf/86141/ei10-07-034.pdf (https://www.all-electronics.de/wp-content/uploads/migrated/article-pdf/86141/ei10-07-034.pdf)

Und ein Schaltbild des Moduls in unserem Wiki: https://wiki.fhem.de/wiki/Selbstbau_CUL#Die_unterschiedlichen_Ausf.C3.BChrungen_des_Funkmoduls (https://wiki.fhem.de/wiki/Selbstbau_CUL#Die_unterschiedlichen_Ausf.C3.BChrungen_des_Funkmoduls)

Hier sind im unteren Bild C81 und C101 entscheidend. Die Bauform ist 0402, wenn ich richtig sehe? Gibts in 1pf-Schritten (außer 14pF) bei Angelika zum kleinen Preis. Hier könnte man mit 1p mehr oder weniger auch noch ein paar Designfehler im Layout ausgleichen, um dem Original so nahe wie möglich zu kommen. Korrekturen in der Software sind dann immer noch ein gutes Mittel für den Feinschliff.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 16 Dezember 2018, 11:48:28
Also würde ich die im Bild markierten Kondensatoren gg z.B.
https://www.conrad.de/de/kemet-c0402c120j5gac7867-keramik-kondensator-smd-0402-12-pf-50-v-5-l-x-b-x-h-1-x-03-x-05-mm-1-st-1420326.html
tauschen?

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 16 Dezember 2018, 12:17:19
Exakt. Einen Versuch ist es allemal wert.

Mein in #58 gepostetes Modul ist übrigens auch betroffen. Kein anlernen möglich.

Edit: gerade mit dem Scanner mal drüber geschaut und bei 868.210 den Sensor "gefunden".

Edit2: Mit dem Tausch von C81 und C101 auf 12pF in Baugröße 0402 läuft das Modul auf Anhieb. Die Frequenz passt nun zu den anderen HM-Komponenten (so genau lässt sich das mit einem billigen RTL-SDR nicht feststellen, aber im direkten Vergleich ist das ok). Für entscheidend halte ich noch den Umstand, welche HM-Basis verwendet wird. Wer einen Nachbau-CUL nutzt, wird sicher weniger Probleme haben, da die HF-Seite auf den China-Modulen weniger sauber ausgeführt ist und dadurch toleranter (breiter) bei Signalen. Mein originaler CUL sieht das kritischer und konnte nichts empfangen, ein Nachbau-CUL an gleicher Stelle funktionierte zumindest bescheiden.

Edit3: Die ausgelöteten Kondensatoren wurden vermessen und lagen alle bei 18pF bis 20pF. Bei den letzten vier Modulen wurden nach erfolglosem Anlern-Versuch die Kondensatoren gewechselt, was zur sofortigen Funktion führte.

Noch ein Tip zum Löten der Kondensatoren im 0402-Gehäuse: Hier ist äußerstes Fingerspitzengefühl gefragt. Ich habe zuerst mit einer breiten flachen Spitze die C's längsseitig gleichzeitig an beiden Enden erfasst und zur Seite von den Pads geschoben. Danach mit etwas 1.5mm Entlötlitze die Pads vom restlichen Zinn befreit. Nun lohnt es, die Stellen Wattestäbchen und Spiritus zu reinigen. An dieser Stelle wechsle ich die Lötspitze (hier Weller WSP-80 mit LT1SA) und löte den neuen C mit 0.35mm Zinn zuerst auf der nicht-Masseseite an. Das geht sehr schnell, da die Spitze wenig Material zu erwärmen hat. Erst danach erfolgt die masseseitige Lötung am neuen C, denn hier ist viel Material zu erwärmen, was etwas länger dauert. Man muss sich zu dem Zeitpunkt nicht mehr aufs Festhalten des C konzentrieren. :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Dezember 2018, 14:29:21
Die 12p sind plausibel. Mit 34pF ist es ein Wunder, das der Oszillator überhaupt sauber startet. Daher halte ich auch nicht viel vom Anpassen der Software, um elementare Fehler in der Hardware auszugleichen. Kann funktionieren, hinterlässt aber kein gutes Gefühl...
Ich habe leider daheim derzeit keine Möglichkeiten zu Messungen. Nachwievor ist auch die Quarzfrequenz ansich interessant sowie das Einschwingverhalten unter verschiedenen Temperaturbedingungen.

Wobei im Datenblatt 27pF angegeben sind, insofern sind die 34pF einigermaßen plausibel. Verwendeter Quarz (Lastkap.) und Streukapazität im Layout spielen wesentliche Rollen dabei wie auch im von kpwg verlinkten pdf  lesen ist.
Wenn der Hersteller das alles berücksichtigt und berechnet hat können 34pF durchaus Sinn machen. Wenn er einfach den nächstbesten lieferbaren Quarz nimmt und bestückt kann das richtig schiefgehen was die Einhaltung der genauen Frequenz betrifft.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Dezember 2018, 14:34:19
Vielleicht kann man ja auch einen Testsketch machen, der die Frequenz in einem bestimmten Bereich ändert und jeweils versucht ein Kommand an die Zentrale zu senden. Von der Antwort mit dem besten RSSI Wert wird die Frquenz bzw. die Registerwerte ausgegeben.

Ich finde papas Idee ziemlich gut.
Es gibt aber wahrscheinlich keine Möglichkeit den RSSI Wert von der Zentrale ins Device zurück zu bekommen, um die Sache automatisiert zu gestalten, oder?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 16 Dezember 2018, 15:01:41
Wenn der Hersteller das alles berücksichtigt und berechnet hat können 34pF durchaus Sinn machen. Wenn er einfach den nächstbesten lieferbaren Quarz nimmt und bestückt kann das richtig schiefgehen was die Einhaltung der genauen Frequenz betrifft.
Gut zusammengefasst. Der Quarz benötigt die passenden Lastkapazitäten. Der Quarz ist offenbar bei allen fehlerhaften Modulen bedruckt, bei allen funktionierenden Modulen mit einer Gravur beschriftet. Könnt ihr das bestätigen?

Edit: Der Hersteller empfiehlt 13pf, wenn ich das richtig deute? (Auszug aus dem Datenblatt anbei) Daher sind die 12p mit noch ein wenig Streukapazität im Layout schon ok.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 16 Dezember 2018, 15:25:23
Hallo Zusammen,

Zitat
Es gibt aber wahrscheinlich keine Möglichkeit den RSSI Wert von der Zentrale ins Device zurück zu bekommen, um die Sache automatisiert zu gestalten, oder?
Da dass device selbst den cc1101 nutzt, kann man den Empfangs RSSI im device nutzen.
Die Zentrale könnte auch mit einer Antwort mit enthaltenem Empfangs-RSSI der Zentrale antworten.

Außerdem kann der cc1101 auch noch so eingestellt werden, dass er den Frequenzoffset beim Empfang optimiert, sofern die Modulationsart es erlaubt, was der Fall ist.
Siehe Register 0x0C: FSCTRL0 – Frequency Synthesizer Control, 0x19: FOCCFG – Frequency Offset Compensation Configuration und 0x32 (0xF2): FREQEST – Frequency Offset Estimate from Demodulator, sowie Kapitel 14.1 Frequency Offset Compensation.

D.h. grob etwa so
- Frequenz auf 868.3MHz einstellen und FOCCFG einstellen z.B. 0x26
- den Frequenzoffset in FSCTRL0 variieren, bis eine Paketantwort erfolgreich, mit erfolgreicher CRC-Prüfung von der Zentrale empfangen werden kann
- das FREQEST lesen und wieder in FSCTRL0 nutzen und gemittelt über mehrere Versuche und Antwortpakete als Offset nutzen.

Das setzt vorraus, dass der Frequenzfehler maximal etwa +/-200kHz beträgt.

Gruß, Ansgar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Dezember 2018, 20:10:27
Gut zusammengefasst. Der Quarz benötigt die passenden Lastkapazitäten. Der Quarz ist offenbar bei allen fehlerhaften Modulen bedruckt, bei allen funktionierenden Modulen mit einer Gravur beschriftet. Könnt ihr das bestätigen?

Edit: Der Hersteller empfiehlt 13pf, wenn ich das richtig deute? (Auszug aus dem Datenblatt anbei) Daher sind die 12p mit noch ein wenig Streukapazität im Layout schon ok.

Ganz so einfach ist die Rechnung glaub ich nicht, sondern
CE = 2*CL - CS
CE gesuchter Wert für ext. C
CL Lastkapazität des Quarzes
CS Streukapazität (Layout)
AVR042 App. Note, der Abschnitt dort über  Quarzosz. sollte universell gelten.

Der screenshot von kpwg aus dem Datenblatt zeigt die vom Hersteller empfohlene Lastkapazität in deren Grenzen man den OSC des CC1101 sicher betreiben kann.
TI nennt weiter hinten in der BOM 2 Bsp. für Quarze:
NX3225GA -> CL = 8pF
AT-41CD2 -> CL = 16pF

Wenn man z.B. 6pF Streukapazität annimmt
ergibt sich laut Formel
NX3225GA ein CE von 10pF
AT-41CD2 ein CE von 26pF

D.h. wenn die Module einen Quarz ähnlich AT-41CD2 hätten wären 27pF perfekt, für den NX3225GA wären 27pF viel zu groß, da machen 12pF Sinn.

=> Ohne die CL des Quarzes zu kennen kann man CE nicht sinnvoll berechnen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 17 Dezember 2018, 19:00:32
Hallo,
habe ein Modul mit geändertern Werten im Register und ein Modul mit geänderten Kondensatoren mit dem Sketch HM-LC-SWX-SM betrieben. Laut SDR sind die meisten der empfangenen Frequenzen meiner HM-Geräte nahezu deckungsgleich mit den Signalen, die die beiden Module jeweils aussenden. Dennoch kommt keine Kommunikation zustande.
Wenn ich auf der seriellen Konsole die Initialisierung beobachte und im selben Moment ein HM-Telegramm kommt, werden die 4 Schalterzustände gesendet und danach das empfangene Telegramm richtig dargestellt. Alle folgenden empfangenen Telegramme sind falsch und mit CRC-Fehlern.

Die ausgesendeten Telegramme werden weder vom CUL noch von HMUARTLGW empfangen.

Benutze ich die beiden Module mit einem NanoCUL, kann ich mit ihnen alle Geräte fehlerfrei empfangen und darüber ebenso schalten. Was mache ich jetzt mit 10xNanoCul?  ::)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 18 Dezember 2018, 06:59:19
Gestern kam eine neue Lieferung von TENSTAR bei mir an.
Hab ein Modul fix ausgepackt und getestet - Anlernen klappte auf Anhieb.

Hier mal meine Aufzeichnungen bzgl. der Sendefrequenzen verschiedener Module:
ModulTX Freq. MHZ
CC1101 neueste Lieferung (i.O.)868.21
CC1101 ältere Lieferung (i.O.)868.26
Original eQ-3 TRX868.24
HM-MOD-UART868.25

Das CC1101 aus der neuen Lieferung liegt ca. 30-40kHz neben der Frequenz, auf der das originale HomeMatic Zeugs funkt.
Bei 300kHz Bandbreite liegt es noch im Bereich von "funktioniert".

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 18 Dezember 2018, 07:39:50
Gestern kam eine neue Lieferung von TENSTAR bei mir an.
Hab ein Modul fix ausgepackt und getestet - Anlernen klappte auf Anhieb.

Hier mal meine Aufzeichnungen bzgl. der Sendefrequenzen verschiedener Module:
ModulTX Freq. MHZ
CC1101 neueste Lieferung (i.O.)868.21
CC1101 ältere Lieferung (i.O.)868.26
Original eQ-3 TRX868.24
HM-MOD-UART868.25

Das CC1101 aus der neuen Lieferung liegt ca. 30-40kHz neben der Frequenz, auf der das originale HomeMatic Zeugs funkt.
Bei 300kHz Bandbreite liegt es noch im Bereich von "funktioniert".

Wärst du bitte so nett und würdest noch ein Bild vom Modul zeigen?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 18 Dezember 2018, 07:44:45
Wärst du bitte so nett und würdest noch ein Bild vom Modul zeigen?

Klaro. Ist alles Relevante zu erkennen?

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 18 Dezember 2018, 08:03:20
Hi,
das bedeutet also, dass die Register beim nanoCUL (mit welcher Firmware?) richtig initialisiert werden, beim ASKSinPP Sketch (welcher genau, inkl. GitHub Link?) nicht. Oder?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 18 Dezember 2018, 08:42:28
Hallo jp112sdl,

Zitat
Bei 300kHz Bandbreite liegt es noch im Bereich von "funktioniert".
Wie kommst Du auf 300kHz Bandbreite?

100kHz Bandbreite wird bei HM verwendet! Schau mal, was in die Register reingeschrieben wird.

300kHz wird bei SlowRf verwendet. Nur da machen die 30-40kHz nicht so viel aus.

Gruß, Ansgar.

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 18 Dezember 2018, 08:57:33
Wie kommst Du auf 300kHz Bandbreite?

Stimmt, war mein Denkfehler!
Ich hatte auf Mikrocontroller.net in einem Beitrag nur die max. Bandbreite von 300kHz gefunden.
https://www.mikrocontroller.net/topic/258104#2672170
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 18 Dezember 2018, 09:41:37

Benutze ich die beiden Module mit einem NanoCUL, kann ich mit ihnen alle Geräte fehlerfrei empfangen und darüber ebenso schalten. Was mache ich jetzt mit 10xNanoCul?  ::)


Hast Du beim NanoCul auch die Frequenz verändert, oder alles auf Standart gelassen? Wäre hilfreich um den Fehler weiter einzugrenzen
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 18 Dezember 2018, 21:22:09
Guten Abend,

Gestern kam eine neue Lieferung von TENSTAR bei mir an.
Hab ein Modul fix ausgepackt und getestet - Anlernen klappte auf Anhieb.

Hier mal meine Aufzeichnungen bzgl. der Sendefrequenzen verschiedener Module:
ModulTX Freq. MHZ
CC1101 neueste Lieferung (i.O.)868.21
CC1101 ältere Lieferung (i.O.)868.26
Original eQ-3 TRX868.24
HM-MOD-UART868.25

Das CC1101 aus der neuen Lieferung liegt ca. 30-40kHz neben der Frequenz, auf der das originale HomeMatic Zeugs funkt.
Bei 300kHz Bandbreite liegt es noch im Bereich von "funktioniert".

wie bestimmt Ihr die exakte Sendefrequenz? Pi mal Daumen die Mitte des Signal-"Streifens", oder gibt es eine exaktere Methode?

Mitschnitt meiner Tenstar-Module s. Anhang, so arg verschoben scheint es ja nicht zu sein, oder? Meine Analyse ergab ja, dass HM-MOD-RPI-PCB (FHEM/piVCCU) durchaus in der Lage sind, die Module zu empfangen, aber die wiederum beantworten nicht deren Anfragen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: noansi am 19 Dezember 2018, 01:08:22
Hallo tndx,

nur der Vergleich mit HM-devices macht wirklich Sinn.

angehängt mal ein getConfig Beispiel.
Zuerst sendet mein CUL, dann das Device, usw. .

Im Vergeich liegen die beiden etwa 5kHz auseinander.

Gengenüber meinem DVB-T Stick sendet CUL etwa 13kHz verschoben.

Und den DVB-T Stick habe ich gegen einen gut zu empfangenen DVB-T Sender mit hoher Frequenz anhand seiner recht scharfen Bandkanten "abgeglichen". Nachdem ich den gut habe warm laufen lassen.
Und da endet auch meine Genauigkeitsinformation bei +/-?.

Gruß, Ansgar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 19 Dezember 2018, 21:02:21
Zitat
author=Klaus0815 link=topic=91740.msg873357#msg873357 date=1545122497]
Hast Du beim NanoCul auch die Frequenz verändert, oder alles auf Standart gelassen? Wäre hilfreich um den Fehler weiter einzugrenzen

nanoCUL Version: culfw-1.67
in clib/rf_asksin.c die Adresse geändert:  0x65 -> 0x66, 0x6A -> 0x75
in der Konsole eingeben:
X21
Ar

                                       
Alle Telegramme werden einwandfrei empfangen.
Befehl zum Ein/Ausschalten einer Leuchte:

As0EF4A011F100135523110201C80000
As0EF4A011F100135523110201000000

Das funktioniert bei allen 10 Modulen.
Ich habe soeben hm_cc_rt_dn_update mit solch einem nanoCUL erfolgreich durchgeführt.

AskSin++ V3.0.2
Die CC1101_Register nach dem Init mehrfach ausgelesen und verglichen - alles in Ordnung.
Nur wenige Telegramme werden richtig empfangen.


Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 11:40:16
@plombe: Bedeutet dies, dass ich einfach die Änderung wie von dir beschrieben in "rf_asksin.c" vornehme und dann die Firmware kompiliere und es sollte damit laufen?

Dann probiert ich das gleich morgen mal aus.  8)
Ist es evtl. möglich die nanoCUL-FW so umzuschreiben, dass man die abweichenden Werte direkt in FHEM per "set" korrigieren kann?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 20 Dezember 2018, 13:51:22
@thgorjup

Das gilt nur für die Verwendung des nanoCUL für HomeMatic.
Für andere Anwendungen kann man die Adressänderungen von FHEM aus vornehmen.
Schon einige Wochen läuft ein SIGNALDuino mit solch einem Modul problemlos.

H-G

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 14:00:01
Ja, für mich ist es auch nur für Homematic wichtig. Danke für deine Antwort.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 20 Dezember 2018, 19:03:53
So, richtige Frequenz gefunden!

CC1101_FREQ2 0x21
CC1101_FREQ1 0x66
CC1101_FREQ0 0x5F

Damit funktionieren alle Module.
Ich habe in der Hex Datei die Frequenz in Schritten verringert, ausgehend von der im SDR gemessenen. Dann die Software geflasht. So ging es schneller.
Ob das bei euren Modulen die gleiche Frequenz ist?

H-G
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 22:23:09
CC1101_FREQ2 0x21
CC1101_FREQ1 0x66
CC1101_FREQ0 0x5F

@plombe: Wo ist denn das in der rf_asksin.c zu ändern?
Die Änderung 0x65 -> 0x66, 0x6A -> 0x75 bewirkt bei mir, dass nichts mehr geht.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 20 Dezember 2018, 22:31:26
const uint8_t PROGMEM ASKSIN_CFG[] = {
     0x00, 0x07,
     0x02, 0x2e,
     0x03, 0x0d,
     0x04, 0xE9,
     0x05, 0xCA,
     0x07, 0x0C,
     0x0B, 0x06,
     0x0D, 0x21,
     0x0E, 0x66, //0x65,
     0x0F, 0x75, //0x6A,
     0x10, 0xC8,
     0x11, 0x93,
     0x12, 0x03,
     0x15, 0x34,
     0x17, 0x33, // go into RX after TX, CCA; EQ3 uses 0x03
     0x18, 0x18,
     0x19, 0x16,
     0x1B, 0x43,
     0x21, 0x56,
     0x25, 0x00,
     0x26, 0x11,
     0x29, 0x59,
     0x2c, 0x81,
     0x2D, 0x35,
     0x3e, 0xc3
};
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 20 Dezember 2018, 22:34:54
So, richtige Frequenz gefunden!

CC1101_FREQ2 0x21
CC1101_FREQ1 0x66
CC1101_FREQ0 0x5F

Damit funktionieren alle Module.
Ich habe in der Hex Datei die Frequenz in Schritten verringert, ausgehend von der im SDR gemessenen. Dann die Software geflasht. So ging es schneller.
Ob das bei euren Modulen die gleiche Frequenz ist?

H-G

Ich verstehe es zugegeben noch nicht wirklich
Funktionieren die fehlerhaften CC1101-Module mit dem NanoCul ohne jegliche Änderung? Oder muss auch dort an der Frequenz etwas angepasst werden?

Wir sollten versuchen, einzugrenzen ob es definitiv ein Hardware-Problem ist, oder ob vielleicht doch etwas an den AskSin-Libraries nicht passt

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 22:46:35
Also ich habe gerade nochmal getestet. Mit dieser Einstellung in der rf_asksin.c  bewegt sich mein HM_Rolladen rein garnicht.
Ohne Änderung (Original HEX File) kann ich senden aber nicht empfangen. Die Änderung von plombe passt wohl nicht zu meinem Modul.

Hab heute meinen DVBT-Stick bekommen aber muss jetzt erstmal rausfinden wie ich die Messung mache.
Gibt es irgendwo ein Toturial für HDSDR mit dem DVB-T Stick? Oder kann hier jemand ein Quick-ToDo posten?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 20 Dezember 2018, 22:50:34
@ thgorjup

Kannst Du den Wert von 0x75 mal auf 0x5F ändern?

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 22:56:55
Geht leider auch nicht.  :-\
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 20 Dezember 2018, 22:59:36

Gibt es irgendwo ein Toturial für HDSDR mit dem DVB-T Stick? Oder kann hier jemand ein Quick-ToDo posten?

https://homematic-forum.de/forum/viewtopic.php?t=11087&start=24 (https://homematic-forum.de/forum/viewtopic.php?t=11087&start=24)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 20 Dezember 2018, 23:31:22
Hmm, dasToturial ist unvollständig. Es fehlen Dateien.
Ich habe das hier gefunden und so durchgeführt: http://hdsdr.de/RTLSDR_with_HDSDR.pdf
Jetzt läuft HDSDR mit dem Stick aber was muss ich wo einstellen?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 20 Dezember 2018, 23:36:52
@Klaus0815
Zitat
Funktionieren die fehlerhaften CC1101-Module mit dem NanoCul ohne jegliche Änderung? Oder muss auch dort an der Frequenz etwas angepasst werden?

Wie geschrieben, muß in der rf_asksin.c beim nanoCUL die Frequenz geändert werden. Das funktioniert dann nur für HomeMatic. Sonst brauchts mehr Änderungen. Ob alle Module die gleiche Frequenzabweichung haben, weiß ich leider nicht. Meine 10 Module haben jedenfalls alle den gleichen Wert.
Obwohl ich die Initialisierung mehrfach zwischen CUL und AskSin überprüft und keine Abweichungen gefunden habe, kommt mir AskSin schmalbandiger vor.
H-G
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 21 Dezember 2018, 19:08:25
Ich habe nun bei zwei CC1101 die Kondensatoren C81 und C101 gegen 12pF getauscht und siehe da, ich kann die Geräte anlernen!! 

Danke euch!
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 21 Dezember 2018, 22:45:52
Ich habe meine Module auch zum Laufen bekommen. Dummerweise habe ich die meisten schon wieder zurück nach China geschickt. Hoffentlich kriege ich die Kohle wieder.

Verkäufer: WAVGAT (weijie.chen)
Link: https://de.aliexpress.com/item/Wireless-Modul-CC1101-Fern-bertragung-Antenne-868-mhz-M115-F-r-FSK-GFSK-FRAGEN-OOK-MSK/32951998715.html?spm=a2g0s.issue_5ptha.0.0.3b604c4dIfrUEZ (https://de.aliexpress.com/item/Wireless-Modul-CC1101-Fern-bertragung-Antenne-868-mhz-M115-F-r-FSK-GFSK-FRAGEN-OOK-MSK/32951998715.html?spm=a2g0s.issue_5ptha.0.0.3b604c4dIfrUEZ)

Aber die 5 Stück die ich noch habe, funktionieren mit einer kleinen Korrektur der Frequenz in der clib/rf_asksin.c:

Man muss lediglich 0x6A in 0x9A ändern und neu kompilieren.
     0x0D, 0x21,
     0x0E, 0x65,
     0x0F, 0x9A, // 0x6A

@plombe: Danke für deine Hilfe.

Gruß
Thomas
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 21 Dezember 2018, 23:15:43
@thgorjup
Würde diese Anpassung auch für AskSinPP funktionieren? Bei mir hat die Anpassung in der Radio.h kein Ergebnis geliefert
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 22 Dezember 2018, 11:04:31
@thgorjup
Würde diese Anpassung auch für AskSinPP funktionieren? Bei mir hat die Anpassung in der Radio.h kein Ergebnis geliefert
Dann muss es noch andere Unterschiede geben. Ich habe den CC1101-Code größtenteils aus der NewAskin übernommen. Ein paar Anpassungen habe ich noch gemacht, nachdem ich mir mal den Askin-Teil in der CUL-Firmware angesehen hatte. Kann mich aber nicht mehr ganz genau an die Einzelheiten erinnern. Mit Xento haben wir dann noch hauptsächlich an der Initialisierung geschraubt.
Ich könnte zumindest schon mal ein Defines vorsehen, mit denen die Frequenz im Sketch definiert werden kann. Dann kann das im Sketch angepasst werden und man braucht nicht die Lib zu patchen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: plombe am 22 Dezember 2018, 14:06:10
Hallo,
um mir die Arbeit zu erleichtern, ändere ich nur in der Hex Datei. Das gilt auch für den Bootloader. Könnte man auch komfortabel mit erweitertem  makeota bewerkstelligen.
H-G
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: frank am 22 Dezember 2018, 15:23:19
so schön es ist, dass man durch die fw änderungen die module zum laufen bekommt. allerdings erfordert es auch hohen aufwand bei der dokumentation, damit spätere fw updates weiterhin funktionieren.

wenn die vielen "privaten" cul-verkäufer das so handhaben, bricht hier im forum sicherlich demnächst das chaos aus.
Titel: Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 22 Dezember 2018, 16:03:39
Ja,
ich finde auch die Frage interessanter die Hardware zu moden oder in Software eine Erkennung einzubauen.

Was ist denn mit der RSSI Erkennung? Kann das auch in der Lib zu einem AutoOffSet eingebaut werden?
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 24 Dezember 2018, 23:42:13
Was ist denn mit der RSSI Erkennung? Kann das auch in der Lib zu einem AutoOffSet eingebaut werden?
Ich glaube für's erste wäre die Möglichkeit der Frequenzanpassung im rfmode = 'HomeMatic' schon sehr hilfreich.
So kann man sich an die passende Frequenz rantasten.
Lässt sich doch sicher schnell in die Firmware einbauen, oder?

Wer hätte denn mal die Muse dazu?
Jetzt um die Weihnachtszeit haben viele doch Zeit für solche Spielchen, oder?
Frohes Fest und schöne Feiertage  ;)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 25 Dezember 2018, 21:58:57
Hallo,
ich habe auch im September von Tenstar Module gekauft, die erstmal scheinbar nicht funktionierten. Mit SDR hab ich dann rausbekommen, dass die ca. 113 kHz zu niedrig senden, also ca. 868,187 MHz wenn auf 868,3 eingestellt. Das hat meine Homematic Zentrale und auch ein MiniCUL mit einem älteren CC1101-Modul nicht mehr empfangen können.
Meine Original-Homematic-Komponenten funken übrigens auch nicht exakt auf 868,3 sondern ca. auf 868,237 MHz (mit SDR ermittelt).
Ich habe dann also die neuen Module einfach auf 113 kHz höher, also 868,35 MHz eingestellt. Dadurch funken sie jetzt fast exakt auch auf 868,237 MHz und alles funktioniert.


Habe Uwes Vorschlag gerade getestet - funktioniert :-) 

Die 113 KHz Fehler verwirren ANfangs etwas - meine lagen ca. 125 KHz zu niedrig, also ähnlich wie bei Uwe, aber seine korrigierten Werte funktionierten nicht.
Die gemessenen Werte haben wohl auch  eine absolute Abweichung, bedingt durch Toleranzen der SDR-Geschichte, wichtig ist die Differenz der gemessenen Werte Original- falscher CC1101

Bei 125 KHz Abweichung muss man nicht auf 868,35 sondern auf 868,425 MHz einstellen - versucht es mal mit

radio.initReg(CC1101_FREQ2, 0x21);
radio.initReg(CC1101_FREQ1, 0x66);
radio.initReg(CC1101_FREQ0, 0xA5);


Edit - da oben gefragt und wir über 2 Systeme reden - das hier ist für AskSinPP
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 26 Dezember 2018, 15:54:11
Hallo,

ich lese hier mal mit, da ich einen nanoCUL mit Stiftleiste habe. Da könnte ich meine Module testen bevor ich sie in eine Schaltung einlöte. Wenn ich das richtig gelesen habe, sollte das Testen mit Homematic gemacht werden, da hier die Bandbreite nur 100 kHz ist, korrekt?

Danke + Gruß

Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Cars10 am 29 Dezember 2018, 17:28:13
Servus miteinander,

nachdem meine hier vorhandenen CC1101 Module auch alle rumspacken und meine SMD-Lötfähigkeiten eher gering sind.
Hat jemand eine brauchbare und günstige Quelle für 5 868Mhz Module?
Würde gerne meine asksinpp bat Sensoren in Betrieb nehmen (die werden leider aktuell beim Anlernen nicht gefunden)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 29 Dezember 2018, 18:44:02
Servus miteinander,

nachdem meine hier vorhandenen CC1101 Module auch alle rumspacken und meine SMD-Lötfähigkeiten eher gering sind.
Hat jemand eine brauchbare und günstige Quelle für 5 868Mhz Module?
Würde gerne meine asksinpp bat Sensoren in Betrieb nehmen (die werden leider aktuell beim Anlernen nicht gefunden)

Guck doch mal in den ersten Beitrag. Da habe ich meine Quelle gepostet wo ich zuletzt bestellt habe und keine Probleme hatte.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Cars10 am 29 Dezember 2018, 18:59:24
Guck doch mal in den ersten Beitrag. Da habe ich meine Quelle gepostet wo ich zuletzt bestellt habe und keine Probleme hatte.

Direkt übersehen :-(
Dann schauen wir mal, ob die besser laufen. *daumendrück*
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: locutus am 06 Januar 2019, 23:58:01
So ein Modul mit der grünen Rückseite (https://forum.fhem.de/index.php/topic,91740.msg850631.html#msg850631) ist mir auch untergekommen. Im Vergleich zu anderen Modulen schwingt der Quarz unsauber.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 07 Januar 2019, 17:23:33
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 (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)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 07 Januar 2019, 17:25:10
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:

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.

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 24 Januar 2019, 09:31:33
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 24 Januar 2019, 11:09:38
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?

Zitat
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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 24 Januar 2019, 11:32:56
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 24 Januar 2019, 12:17:44
Im EEPROM ablegen klingt gut, das wäre hilfreich.

Zitat
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  :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 29 Januar 2019, 22:10:20
Ich habe eine gute Nachricht. Mit Hilfe des FreqTest.ino Sketches (https://github.com/pa-pa/AskSinPP/blob/master/examples/FreqTest/FreqTest.ino) 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:
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:
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
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 30 Januar 2019, 07:50:28
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
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 30 Januar 2019, 11:33:42
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 ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 30 Januar 2019, 18:45:09
Hi,

Ich habe eine gute Nachricht. Mit Hilfe des FreqTest.ino Sketches (https://github.com/pa-pa/AskSinPP/blob/master/examples/FreqTest/FreqTest.ino) 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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 30 Januar 2019, 19:29:18
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 30 Januar 2019, 19:34:23
Sehr cooles Feature, vielen Dank an papa.  8)
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) .
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 30 Januar 2019, 20:16:59
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 30 Januar 2019, 21:27:31
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!
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 30 Januar 2019, 21:51:25
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 30 Januar 2019, 23:27:21
Die 1. Hürde habe ich nun genommen, wenn auch im Blindflug: der FreqTest-Sketch ist geflasht, das Testobjekt hat auch mit meiner VCCU kommuniziert, sichtbar am Event-Log und Device-Readings in FHEM.
Wollte nun die RHS-Firmware neu übersetzen, habe den RHS-Sketch aus dem V3-Branch genommen und um USE_OTA_BOOTLOADER und USE_AES ergänzt, bekomme allerdings beim Kompilieren die Meldung
In file included from D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:27:0:

C:\Users\xyz\Documents\Arduino\libraries\EnableInterrupt/EnableInterrupt.h:22:125: note: #pragma message: NOTICE: *** EnableInterrupt library version pre-0.9.6. This is not a problem. Keep calm, and carry on. ***

 #pragma message("NOTICE: *** EnableInterrupt library version pre-0.9.6. This is not a problem. Keep calm, and carry on. ***")

                                                                                                                             ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:58:33: error: redefinition of 'const as::DeviceInfo devinfo'

 const struct DeviceInfo PROGMEM devinfo = {

                                 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:58:33: note: 'const as::DeviceInfo devinfo' previously defined here

 const struct DeviceInfo PROGMEM devinfo = {

                                 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:67:7: error: redefinition of 'class BatSensor'

 class BatSensor : public BatterySensorUni<17,7,3000> {

       ^

HM-SEC-RHS:67: error: previous definition of 'class BatSensor'

 class BatSensor : public BatterySensorUni<17,7,3000> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:94:7: error: redefinition of 'class Hal'

 class Hal : public BaseHal {

       ^

HM-SEC-RHS:94: error: previous definition of 'class Hal'

 class Hal : public BaseHal {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:101:6: error: invalid type in declaration before ';' token

 } hal;

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:101:6: error: conflicting declaration 'int hal'

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:101:3: note: previous declaration as 'Hal hal'

 } hal;

   ^

In file included from D:\Programme\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from sketch\HM-SEC-RHS.ino.cpp:1:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:92: error: redefinition of 'const uint8_t __Reg0Register__ [7]'

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                                                                            ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:103:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

 ^

In file included from D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:31:0:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:47: note: 'const uint8_t __Reg0Register__ [7]' previously defined here

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                               ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:103:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:103:13: error: redefinition of 'class Reg0'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

HM-SEC-RHS:103: error: previous definition of 'class Reg0'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:104:7: error: redefinition of 'class RHSList0'

 class RHSList0 : public RegList0<Reg0> {

       ^

HM-SEC-RHS:104: error: previous definition of 'class RHSList0'

 class RHSList0 : public RegList0<Reg0> {

       ^

In file included from D:\Programme\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from sketch\HM-SEC-RHS.ino.cpp:1:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:92: error: redefinition of 'const uint8_t __Reg1Register__ [5]'

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                                                                            ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:115:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

 ^

In file included from D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:31:0:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:47: note: 'const uint8_t __Reg1Register__ [5]' previously defined here

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                               ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:115:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:115:13: error: redefinition of 'class Reg1'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

HM-SEC-RHS:115: error: previous definition of 'class Reg1'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:116:7: error: redefinition of 'class RHSList1'

 class RHSList1 : public RegList1<Reg1> {

       ^

HM-SEC-RHS:116: error: previous definition of 'class RHSList1'

 class RHSList1 : public RegList1<Reg1> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:168:7: error: redefinition of 'class RHSType'

 class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0> {

       ^

HM-SEC-RHS:168: error: previous definition of 'class RHSType'

 class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:187:14: error: redefinition of 'RHSType sdev'

 RHSType sdev(devinfo,0x20);

              ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:187:9: note: 'RHSType sdev' previously declared here

 RHSType sdev(devinfo,0x20);

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:188:34: error: redefinition of 'as::ConfigButton<RHSType> cfgBtn'

 ConfigButton<RHSType> cfgBtn(sdev);

                                  ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:188:23: note: 'as::ConfigButton<RHSType> cfgBtn' previously declared here

 ConfigButton<RHSType> cfgBtn(sdev);

                       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino: In function 'void setup()':

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:190:6: error: redefinition of 'void setup()'

 void setup () {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:190:6: note: 'void setup()' previously defined here

 void setup () {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino: In function 'void loop()':

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_mod.ino:203:6: error: redefinition of 'void loop()'

 void loop() {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:203:6: note: 'void loop()' previously defined here

 void loop() {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino: At global scope:

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:53:33: error: redefinition of 'const as::DeviceInfo devinfo'

 const struct DeviceInfo PROGMEM devinfo = {

                                 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:58:33: note: 'const as::DeviceInfo devinfo' previously defined here

 const struct DeviceInfo PROGMEM devinfo = {

                                 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:62:7: error: redefinition of 'class BatSensor'

 class BatSensor : public BatterySensorUni<17,7,3000> {

       ^

HM-SEC-RHS:67: error: previous definition of 'class BatSensor'

 class BatSensor : public BatterySensorUni<17,7,3000> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:89:7: error: redefinition of 'class Hal'

 class Hal : public BaseHal {

       ^

HM-SEC-RHS:94: error: previous definition of 'class Hal'

 class Hal : public BaseHal {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:96:6: error: invalid type in declaration before ';' token

 } hal;

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:96:6: error: conflicting declaration 'int hal'

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:101:3: note: previous declaration as 'Hal hal'

 } hal;

   ^

In file included from D:\Programme\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from sketch\HM-SEC-RHS.ino.cpp:1:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:92: error: redefinition of 'const uint8_t __Reg0Register__ [7]'

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                                                                            ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:98:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

 ^

In file included from D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:31:0:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:47: note: 'const uint8_t __Reg0Register__ [7]' previously defined here

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                               ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:103:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:98:13: error: redefinition of 'class Reg0'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

HM-SEC-RHS:103: error: previous definition of 'class Reg0'

 DEFREGISTER(Reg0,DREG_INTKEY,DREG_CYCLICINFOMSG,MASTERID_REGS,DREG_TRANSMITTRYMAX,DREG_SABOTAGEMSG)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:99:7: error: redefinition of 'class RHSList0'

 class RHSList0 : public RegList0<Reg0> {

       ^

HM-SEC-RHS:104: error: previous definition of 'class RHSList0'

 class RHSList0 : public RegList0<Reg0> {

       ^

In file included from D:\Programme\Arduino\hardware\arduino\avr\cores\arduino/Arduino.h:28:0,

                 from sketch\HM-SEC-RHS.ino.cpp:1:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:92: error: redefinition of 'const uint8_t __Reg1Register__ [5]'

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                                                                            ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:110:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

 ^

In file included from D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:31:0:

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:292:47: note: 'const uint8_t __Reg1Register__ [5]' previously defined here

 #define DEFREGISTER(rgname,...) const uint8_t __##rgname##Register__[NUMARGS(__VA_ARGS__)] PROGMEM = {__VA_ARGS__}; \

                                               ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:115:1: note: in expansion of macro 'DEFREGISTER'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

 ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:110:13: error: redefinition of 'class Reg1'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

HM-SEC-RHS:115: error: previous definition of 'class Reg1'

 DEFREGISTER(Reg1,CREG_AES_ACTIVE,CREG_MSGFORPOS,CREG_EVENTDELAYTIME,CREG_LEDONTIME,CREG_TRANSMITTRYMAX)

             ^

C:\Users\xyz\Documents\Arduino\libraries\20190130_AskSinPP-master/Register.h:293:9: note: in definition of macro 'DEFREGISTER'

   class rgname { public: \

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:111:7: error: redefinition of 'class RHSList1'

 class RHSList1 : public RegList1<Reg1> {

       ^

HM-SEC-RHS:116: error: previous definition of 'class RHSList1'

 class RHSList1 : public RegList1<Reg1> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:163:7: error: redefinition of 'class RHSType'

 class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0> {

       ^

HM-SEC-RHS:168: error: previous definition of 'class RHSType'

 class RHSType : public ThreeStateDevice<Hal,ChannelType,1,RHSList0> {

       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:182:14: error: redefinition of 'RHSType sdev'

 RHSType sdev(devinfo,0x20);

              ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:187:9: note: 'RHSType sdev' previously declared here

 RHSType sdev(devinfo,0x20);

         ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:183:34: error: redefinition of 'as::ConfigButton<RHSType> cfgBtn'

 ConfigButton<RHSType> cfgBtn(sdev);

                                  ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:188:23: note: 'as::ConfigButton<RHSType> cfgBtn' previously declared here

 ConfigButton<RHSType> cfgBtn(sdev);

                       ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino: In function 'void setup()':

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:185:6: error: redefinition of 'void setup()'

 void setup () {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:190:6: note: 'void setup()' previously defined here

 void setup () {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino: In function 'void loop()':

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS_orig.ino:198:6: error: redefinition of 'void loop()'

 void loop() {

      ^

D:\FHEM\Fensterdrehgriffkontakt\fw\20180923\20180923_AskSinPP-V3\AskSinPP-3\examples\HM-SEC-RHS\HM-SEC-RHS.ino:203:6: note: 'void loop()' previously defined here

 void loop() {

      ^

exit status 1
previous definition of 'class BatSensor'

Leider reichen meine bescheidenen Kenntnisse hier nicht mehr aus...

Mit dem AskSin-V3-Branch ließ sich das ganze noch vor ein Paar Monaten übersetzen, ich schließe aber auch nicht aus, dass ich beim Aktualisieren der AskSinPP-Lib gepatzt habe.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 31 Januar 2019, 00:42:22

Leider reichen meine bescheidenen Kenntnisse hier nicht mehr aus...

Mit dem AskSin-V3-Branch ließ sich das ganze noch vor ein Paar Monaten übersetzen, ich schließe aber auch nicht aus, dass ich beim Aktualisieren der AskSinPP-Lib gepatzt habe.

Du hast
HM-SEC-RHS_mod.ino
und
HM-SEC-RHS.ino

im gleichen Verzeichnis HM-SEC-RHS\.
Beide definieren die die gleichen Klassen, das geht nicht. Nimm nur einen sketch pro Verzeichnis.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 31 Januar 2019, 09:12:28
@Tom Major: Danke für die Info, das hat gewirkt!

@Papa: Zumindest bei einem als kaputt abgestempelten Funkmodul hat das Script funktioniert, ich kann den FDGK an der CCU anmelden, was früher nicht möglich war, auch die RSSI-Werte liegen im normalen Bereich. Also noch mal vielen Dank für das tolle Feature!

Jetzt würde ich nur noch auch den OTA-Bootloader auf der richtigen Frequenz funken lassen. Bin bei der Suche im Netz auf ein Programm namens "eXtreme Burner- AVR" gestoßen, damit kann ich komfortabel per ISP Flash, EEPROM und Fuses auslesen, ändern und zurückschreiben. Jetzt müsste ich nur noch wissen, wo ich den Wert im EEPROM finde und welchen Wert ich im Flash damit überschreiben muss. Für ein geübtes Auge ist's wahrscheinlich schnell lokalisiert, aber ich sehe leider nur Buchstabensalat :(
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 31 Januar 2019, 10:01:27
Also Du musst nach 0D210E650F50 im Hex suchen. Badei stehen die 21, 65 und 50 für die Frequenz bestimmenden Werte. Die kannst Du einfach entsprechend ändern.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 31 Januar 2019, 10:23:22
Hi,

Also Du musst nach 0D210E650F50 im Hex suchen. Badei stehen die 21, 65 und 50 für die Frequenz bestimmenden Werte. Die kannst Du einfach entsprechend ändern.

das war einfach, danke!

Die EEPROM-Daten sehen nach dem Lauf des FreqTest-Sketches laut eXtreme Burner - AVR folgendermaßen aus:

:100000006820FECA66120000000000000000000028
:100010000000000000000000000000000000002AB6

Das einzige, was hier nach einer Frequenz aussieht, ist die Zeichenkette "CA6612", allerdings von rechts nach links geschrieben  ??? Würde mich jetzt nicht wundern, aber ist es richtig? Oder muss ich im EEPROM woanders nach was Anderem suchen?

Edit: EEPROM-Auszug gekürzt
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 31 Januar 2019, 10:29:12
Fast - die erste 4 Byte im EEPROM sind die Signature und Checksumme der AskSin++. Dann stehen in Byte 5 & 6 die beiden letzten Byte der Frequenz. Das sind bei Dir 66 & 12. Du musst dann im Bootloader 0D210E660F12 eintragen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 31 Januar 2019, 11:11:16
Fast - die erste 4 Byte im EEPROM sind die Signature und Checksumme der AskSin++. Dann stehen in Byte 5 & 6 die beiden letzten Byte der Frequenz. Das sind bei Dir 66 & 12. Du musst dann im Bootloader 0D210E660F12 eintragen.

OK, vielen Dank!
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 31 Januar 2019, 11:59:30
Und ? Kannst Du jetzt auch ein OTA-Update einspielen ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 31 Januar 2019, 13:37:50
Und ? Kannst Du jetzt auch ein OTA-Update einspielen ?

Ja, Erfolg auf der ganzen Linie!  ;D
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: dogman am 02 Februar 2019, 10:58:08
Hallo zusammen!

Vielen Dank, für die Mühe, die fehlerhaften CC1101 doch noch zum Laufen zu bekommen.
Nun bin ich ziemlich neu in der Materie und wollte fragen, ob ihr vielleicht ein weniger genauer erklären könntet, was man tun muss, damit er läuft. Verstanden habe ich, dass AskSin++ den Check hat. Aber ich hab auf meinem NanoCUL kein AskSin installiert, oder habe ich es nur nicht gemerkt?! ;)

Vielen Dank und viele Grüße
dogman
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 02 Februar 2019, 12:54:10
Für den NanoCul gibt es noch keine Lösung. Du kannst aber auch den FreqTest-Sketch aus der AskSin++ nehmen und ermitteln, wie weit das Funkmodul daneben liegt. Dann müsstest Du die Werte im SourceCode des NanoCul entsprechend anpassen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: DasQ am 02 Februar 2019, 13:46:09
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 ?

Und ich hoff auch für den signalduino auch.
Egal was ich da Flash, diese Module funktionieren nur mit 433mhz obwohl 868 drauf steht und ne kurze Antenne verbaut ist.

Als nanocul wollen se garnicht

Genau an dem genauen implementieren wär natürlich auch interessiert. Sowas gehört ins Wiki
Und der Thread gehört verschoben, da es sich ja nicht um ein reines Homematic Problem dreht, viel mehr ist die Hardware verbugt.

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Lokverführer am 14 Februar 2019, 18:04:40
Ich hatte Ende Dezember diese hier bestellt:
https://de.aliexpress.com/item/CC1101-Drahtlose-Modul-Fern-bertragung-Antenne-868-mhz-SPI-Interface-Low-Power-M115-F-r-FSK/32906580490.html

Insgesamt 4 Stück geordert, eines funktioniert einwandfrei. Die anderen 3 irgendwie gar nicht, auch mit dem Test-Sketch kein Empfang.

Rückseite ist weiß, "868 Mhz Module" mit sehr kleinem Leerraum vor Module
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 14 Februar 2019, 19:59:51
Was sagt denn der Test-Sketch ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Lokverführer am 15 Februar 2019, 12:35:50
Es kommt bei jeder Frequenz "0/0", während des Suchlaufes habe ich mit einem HmIP-Thermostat bei jeder Frequenz die Temperatur verstellt die auch zur Zentrale (Raspberrymatic) übertragen wurde. Funkverkehr war also vorhanden.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 15 Februar 2019, 13:45:04
HmIP Funk wird nicht erkannt.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Lokverführer am 16 Februar 2019, 05:07:04
Ah ok, weil das Modul welches funktioniert hat da nämlich im Test Sketch gleich am Anfang Werte angezeigt.

Dann muss ich mal sehen wie ich die ID der Raspberrymatic herausfinden kann und einmal den aktiven Modus zwischen dem HM-Selbstbausensor in der Zentrale testen.

Nachtrag: Wie bringe ich denn die ID der Raspberrymatic raus? in /etc/config ids steht 65535 (das kann wohl nicht korrekt sein), in /var/ids ist BidCoS-Adress komplett leer.
Soweit ich richtig verstanden habe, sollte da eine sechsstellige Dezimalzahl erscheinen die ich dann in Hex umrechnen muss und in den Sketch eintragen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: sammler27 am 23 Februar 2019, 17:43:57
Ich konnte das Testscript hochladen.
Jedoch bekomme ich die folgenden Fehler. Ist mein Modul defekt oder nicht richtig angeschlossen ?

AskSin++ V3.1.7 (Feb 23 2019 17:38:21)
CC init1
Error at 00 expected: 2E read: 00
Error at 02 expected: 06 read: 00
Error at 03 expected: 0D read: 00
Error at 04 expected: E9 read: 00
Error at 05 expected: CA read: 00
Error at 07 expected: 0C read: 00
Error at 0B expected: 06 read: 00
Error at 0D expected: 21 read: 00
Error at 0E expected: 65 read: 00
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 00
Error at 11 expected: 93 read: 00
Error at 12 expected: 03 read: 00
Error at 15 expected: 34 read: 00
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: 00
Error at 19 expected: 16 read: 00
Error at 1B expected: 43 read: 00
Error at 21 expected: 56 read: 00
Error at 23 expected: E9 read: 00
Error at 24 expected: 2A read: 00
Error at 25 expected: 1F read: 00
Error at 26 expected: 11 read: 00
Error at 29 expected: 59 read: 00
Error at 2C expected: 81 read: 00
Error at 2D expected: 35 read: 00
Error at 2E expected: 09 read: 00
Error at 3E expected: 03 read: 00
CC Version: 00
Error at 3E expected: C0 rea
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 23 Februar 2019, 18:42:01
Der CC1101 wird nicht gefunden, ich würde alle Verbindungen zu diesem genau prüfen bzw. mit Multimeter nachmessen, auch auf Kurzschlüsse prüfen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: sammler27 am 23 Februar 2019, 20:09:33
Der CC1101 wird nicht gefunden, ich würde alle Verbindungen zu diesem genau prüfen bzw. mit Multimeter nachmessen, auch auf Kurzschlüsse prüfen.

Ok Danke, habs gefunden. Das Saubere verlöten mit Lackdraht ist oft nicht so einfach. Selbst wenn der lötbar sein soll ....

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 28 Februar 2019, 20:15:21
Grrrrr - jetzt habe ich ne Lieferung mit den Schrotdingern gekriegt :-(
Da ich noch ein durchgebranntes Modul liege hatte, habe ich einfach mal bei einem Neuen den Quarz ersetzt. Und siehe da - das neue Modul mit dem alten Quarz hat sofort perfekt funktioniert. Hatten wir schon rausgekriegt, was auf den funktionierenden Boards für ein Quarz drauf ist? Vielleicht gibt es die ja in Stückzahlen günstig. Den Quarz  kann man wirklich einfach mit einer Heißluft-Lötstation wechseln.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 02 März 2019, 11:47:43
Hallo,
ich habe den FreqTest.ino sketch geflashed und erstmal nichts empfangen, obwohl ich meine Steckdose bei jeder Frequenz mehrmals ein/aus geschaltet habe.
Da der Durchlauf ewig dauert, habe ich ACTIVE_PING aktiviert und aus FHEM die ID's meiner VCCU und der HM-Steckdose eingetragen, aber trotzdem wird nichts empfangen.
Ich denke ich habe irgendwo einen Fehler gemacht. Stimmen denn die ID's, welche ich eingetragen habe? Kann jemand bitte helfen?

Danke und Gruß
Thomas

Sketch:
#define ACTIVE_PING
//#HMID PING_FROM(0x12,0x34,0x56);      // from address for status message e.g. switch
//#HMID PING_TO(0x99,0x66,0x99);        // to address for status message / central / CCU
HMID PING_FROM(0x67,0x22,0x1C);      // from address for status message e.g. switch
HMID PING_TO(0xF1,0x00,0x00);        // to address for status message / central / CCU
#ifdef ACTIVE_PING
  #define SCANTIME seconds2ticks(5)  // maximal time to wait for a valid message
#else
  #define SCANTIME seconds2ticks(60) // maximal time to wait for a valid message
#endif

Ausgabe:
AskSin++ V3.1.7 (Mar  2 2019 11:30:07)
CC init1
CC Version: 14
 - 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


List VCCU:
Internals:
   DEF        F10000
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     20899
   NAME       VCCU
   NOTIFYDEV  global
   NR         185
   NTFY_ORDER 50-VCCU
   STATE      nanoCUL:ok,nanoCUL2:ok
   TYPE       CUL_HM
   assignedIOs nanoCUL,nanoCUL2
   channel_01 Rauchmelder_Team
   lastMsg    No:4D - t:02 s:F10000 d:5222E6 00
   nanoCUL2_MSGCNT 19959
   nanoCUL2_RAWMSG A0A4B8002F100005222E600::-72:nanoCUL2
   nanoCUL2_RSSI -72
   nanoCUL2_TIME 2019-03-02 11:40:10
   nanoCUL_MSGCNT 940
   nanoCUL_RAWMSG A0A4D8002F100005222E600::-75.5:nanoCUL
   nanoCUL_RSSI -75.5
   nanoCUL_TIME 2019-03-02 11:40:18
   protLastRcv 2019-03-02 11:40:18
   protRcv    18117 last_at:2019-03-02 11:40:18
   protRcvB   265 last_at:2019-03-02 11:32:39
   rssi_at_nanoCUL cnt:448 min:-84 max:-46.5 avg:-68.68 lst:-75.5
   rssi_at_nanoCUL2 cnt:17850 min:-81 max:-63.5 avg:-68.85 lst:-72
   READINGS:
     2019-03-02 11:40:18   CommandAccepted yes
     2019-02-21 01:39:52   IOopen          2
     2019-03-01 12:50:15   aesReqTo        HM_2CAB38
     2019-02-21 01:39:52   state           nanoCUL:ok,nanoCUL2:ok     
   helper:
     HM_CMDNR   77
     PONtest    1
     mId        FFF0
     regLst     ,0
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       nextSend   1551523218.15003
       prefIO     
       vccu       VCCU
       ioList:
         nanoCUL
         nanoCUL2
     mRssi:
       mNo        4D
       io:
         nanoCUL:
           -73.5
           -73.5
         nanoCUL2:
           -72
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     rssi:
       at_nanoCUL:
         avg        -68.6808035714285
         cnt        448
         lst        -75.5
         max        -46.5
         min        -84
       at_nanoCUL2:
         avg        -68.8567507002797
         cnt        17850
         lst        -72
         max        -63.5
         min        -81
Attributes:
   IODev      nanoCUL
   IOList     nanoCUL,nanoCUL2
   IOgrp      VCCU
   expert     2_raw
   group      CUL
   hmKey      01:24f13d70c38f63f5244c87c351633d64
   icon       cul
   model      CCU-FHEM
   subType    virtual
   webCmd     virtual:update

LIST Steckdose:
Internals:
   DEF        67221C
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     433
   NAME       HM_67221C
   NOTIFYDEV  global
   NR         455
   NTFY_ORDER 50-HM_67221C
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:06 - t:10 s:67221C d:F10000 0601000000
   nanoCUL2_MSGCNT 207
   nanoCUL2_RAWMSG A0E8B800267221CF100000101000047::-76.5:nanoCUL2
   nanoCUL2_RSSI -76.5
   nanoCUL2_TIME 2019-03-02 11:04:06
   nanoCUL_MSGCNT 226
   nanoCUL_RAWMSG A0E06A21067221CF100000601000000::-82:nanoCUL
   nanoCUL_RSSI -82
   nanoCUL_TIME 2019-03-02 11:30:10
   protErrIoAttack 49 last_at:2019-03-01 21:02:09
   protLastRcv 2019-03-02 11:30:10
   protRcv    227 last_at:2019-03-02 11:30:10
   protResnd  1 last_at:2019-02-28 00:33:22
   protSnd    178 last_at:2019-03-02 11:30:10
   protState  CMDs_done
   rssi_at_nanoCUL cnt:226 min:-85 max:-65 avg:-69.8 lst:-82
   rssi_at_nanoCUL2 cnt:207 min:-78.5 max:-66 avg:-72.51 lst:-76.5
   rssi_nanoCUL cnt:210 min:-100 max:-67 avg:-72.88 lst:-71
   Helper:
     DBLOG:
       level:
         DBLOG:
           TIME       1551522610.36416
           VALUE      0
       pct:
         DBLOG:
           TIME       1551522610.36416
           VALUE      0
   READINGS:
     2019-03-02 11:04:06   CommandAccepted yes
     2018-12-20 21:59:13   D-firmware      2.6
     2018-12-20 21:59:13   D-serialNr      PEQ0089042
     2018-12-20 21:59:13   R-pairCentral   set_0xF10000
     2019-03-02 11:30:10   deviceMsg       off (to VCCU)
     2019-03-02 11:30:10   level           0
     2019-03-02 11:30:10   pct             0
     2019-03-02 11:30:06   powerOn         2019-03-02 11:30:06
     2019-03-02 11:30:10   recentStateType info
     2019-02-07 20:35:36   sabotageAttack_ErrIoAttack cnt 22
     2019-03-01 21:02:09   sabotageAttack_ErrIoAttack cnt 49
     2019-03-02 11:30:10   state           off
     2019-03-02 11:30:10   timedOn         off
   helper:
     HM_CMDNR   6
     PONtest    0
     cSnd       11F1000067221C0201C80000,11F1000067221C0201000000
     dlvlCmd    ++A011F1000067221C0201000000
     mId        00D8
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +67221C,00,01,00
       nextSend   1551522610.35407
       rxt        0
       vccu       VCCU
       p:
         67221C
         00
         01
         00
       prefIO:
         nanoCUL
     mRssi:
       mNo        06
       io:
         nanoCUL:
           -80
           -80
         nanoCUL2:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         nanoCUL
       flg        A
       ts         1551522610.25515
       ack:
         HASH(0x49980c8)
         068002F1000067221C00
     rssi:
       at_nanoCUL:
         avg        -69.8097345132744
         cnt        226
         lst        -82
         max        -65
         min        -85
       at_nanoCUL2:
         avg        -72.512077294686
         cnt        207
         lst        -76.5
         max        -66
         min        -78.5
       nanoCUL:
         avg        -72.8809523809524
         cnt        210
         lst        -71
         max        -67
         min        -100
Attributes:
   IODev      nanoCUL
   IOgrp      VCCU:nanoCUL
   alias      HM_Steckdose
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.6
   group      Steckdosen
   icon       ge_wht_steckdose
   model      HM-LC-Sw1-Pl-DN-R1
   room       20_Wohnzimmer
   serialNr   PEQ0089042
   subType    switch
   webCmd     statusRequest:toggle:on:off
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 02 März 2019, 14:00:51
Sieht soweit alles gut aus. Hast Du mal ein anderes Modul probiert ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 02 März 2019, 16:24:57
Habe auch Module gehabt, die sich mit papas Script alleine nicht wieder nutzbar machen ließen, nur in Kombination mit dem Austausch der Kondensatoren. Vielleicht ist es so ein Exemplar.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 02 März 2019, 18:21:54
Ja, habe 3 Module probiert.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: thgorjup am 02 März 2019, 21:29:32
Seltsam ist halt, dass ich durch manuelles ausprobieren eine Frequenz gefunden habe, welche zu 80% funktioniert. Habe die nanoCUL Firmware damit kompiliert und kann damit einige HM-Devices schalten. Die Frequenz ist: 0x2165FF. Also sollte doch in der Nähe dieser Frequenz der Sketch etwas anzeigen. Tut er aber leider nicht.  :-[
Schade! Ansonsten finde ich die Lösung von Papa super! So wie ich hier lese, konnten einige damit die passende Frequenz finden.
k.A. warum es bei mir nicht funktionieren will....?
 
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 12 März 2019, 11:18:10
Ich habe jetzt nochmal nach dem Quarz recherchiert und folgende Info bei Epson gefunden.
https://www5.epsondevice.com/en/ic_partners/ti/cc_series.html
Demnach würde ein Epson Quarz aus der Serie TSX-3226 mit 10pF kompatibel sein. Leider habe ich noch keine Quelle gefunden, wo man mal ein paar zum Testen ohne riesige Versandkosten bestellen kann. Hat da jemand vielleicht eine Idee ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 12 März 2019, 23:00:14
Demnach würde ein Epson Quarz aus der Serie TSX-3226 mit 10pF kompatibel sein. Leider habe ich noch keine Quelle gefunden, wo man mal ein paar zum Testen ohne riesige Versandkosten bestellen kann. Hat da jemand vielleicht eine Idee ?

Hängt aber auch vom Wert der beiden SMD C's auf dem CC1101 Board ab. Die müssen bei der Berechnung der erforderlichen Quarz CL berücksichtigt werden.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 13 März 2019, 08:41:09
Ja, ist klar. Ich habe irgendwie das Gefühl, die Chinesen haben einfach nur den Quarz gewechselt und den Rest gleich gelassen. Wenn man andere Quarze ordert, sollt eman aber natürlich auch die entsprechend passenen Kondensatoren mitbestellen.
Oder hoffen wir, dass die Chinesen die Qualität wieder in den Griff kriegen :-)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 13 März 2019, 17:02:17
Ja, ist klar. Ich habe irgendwie das Gefühl, die Chinesen haben einfach nur den Quarz gewechselt und den Rest gleich gelassen. Wenn man andere Quarze ordert, sollt eman aber natürlich auch die entsprechend passenen Kondensatoren mitbestellen.
Oder hoffen wir, dass die Chinesen die Qualität wieder in den Griff kriegen :-)

Genau das war auch mein Gefühl, Quarz mit anderer CL z.B. wegen Lieferantenwechsel oder Preis genommen.

Den TSX-3226 mit 9pF gibt es bei Farnell
https://de.farnell.com/epson/x1e0000210132-tsx-3225-25-mhz-9-0pf/quarz-tsx-3225-25mhz-9pf/dp/1712843?st=X1E0000210143 (https://de.farnell.com/epson/x1e0000210132-tsx-3225-25-mhz-9-0pf/quarz-tsx-3225-25mhz-9pf/dp/1712843?st=X1E0000210143)
ist aber erst ab 55€ versandkostenfrei (und ein Firmenaccount erforderlich).

Wenn man den eingesetzten Quarz kennen würde wäre es einfacher die 2x SMD C neu zu berechnen und tauschen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Jasimo am 18 März 2019, 19:22:24
Hallo Zusammen,

ich hab hier auch ein CC1101 Module welches in Fhem sehr schlechte RSSI Werte liefert. Das Modul befindet sich auf einer HB-UNI-SENS-BATT Platine, als Sketch nutze ich HM-WDS40-TH-I-BME280.ino von Jerome

Nun hab ich auf den Arduino mal den FreqTest.ino geladen und bekomme als Ausgabe folgendes:
AskSin++ V3.1.7 (Mar 18 2019 16:12:41)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A: 345681.  1/79
Search for upper bound
Freq 0x21657A: 5D0534.  1/81
Freq 0x21658A: 471147.  1/75
Freq 0x21659A: 585D8C.  1/82
Freq 0x2165AA: 345682.  1/83
Freq 0x2165BA: 345686.  1/73
Freq 0x2165CA: 345683.  1/76
Freq 0x2165DA:   0/0
Search for lower bound
Freq 0x21655A: 585D8C.  1/79
Freq 0x21654A: 345681.  1/82
Freq 0x21653A: 5E86A9.  1/75
Freq 0x21652A: 471147.  1/72
Freq 0x21651A: 471147.  1/74
Freq 0x21650A: 5E86A9.  1/72
Freq 0x2164FA: 5E86A9.  1/74
Freq 0x2164EA:   0/0

Done: 0x2164FA - 0x2165CA
Calculated Freq: 0x216562
Store into config area: 6562

Anschließend flashe ich wieder den Sketch von Jerome und hatte die Hoffnung das sich die RSSI Werte bessern, aber leider nein.
Muss ich in dem Sketch von Jerome noch eine Anpassung vornehmen? Ich hatte es so gelesen bzw. verstanden das die Korrektur der Frequenz automatisch durch die AskSinPP zur Anwendung kommt.
Hab ich was vergessen, oder gar die falsche AskSinPP Version?

Gruß
Jan
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 18 März 2019, 23:50:37
Hallo zusammen,

leider hab ich auch etwaige Probleme weshalb sich mir folgende Fragen ergeben:


Danke für eure Arbeit!
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 19 März 2019, 06:24:26
Wie komme ich an die Adressen der Devices ohne FHEM, ich bin RasperryMatic Nutzer[/li][/list]

grep "^<device serial" /etc/config/rfd/ABCDEF0123.dev|awk -F 'address="0x' '{print $2}'|awk -F'"' {'print $1'}

wobei ABCDEF0123 die Seriennummer des Gerätes ist.

Da ich eine "CC1101 Testsation" habe bevor ich ihn verbaue teste ich mit einem anderen Pro Mini, wie bekomme ich die ermittelte Frequenz übertragen?

Der Testsketch schreibt den Wert ins EEPROM.
Mit avrdude lässt sich der EEPROM Inhalt lesen/schreiben (https://logbuch.dmaertens.de/elektronik-hardware/microcontroller/eeprom-eines-microcontrollers-mit-avrdude-auslesen-und-beschreiben).

Wenn ich es richtig interpretiere, stehen die beiden Werte am Anfang vorn an (https://github.com/pa-pa/AskSinPP/blob/4ad8f147f07634b875e380085d14ae042cf19c82/AskSinPP.h#L14)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 19 März 2019, 07:14:45
Die Werte werden aber nur genommen, wenn die Checksumme am Ende des Speicherbereiches stimmt. Die Implementierung ist in Storage.h Zeile 457 - einfaches XOR mit 0x5e als Startwert.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Jasimo am 19 März 2019, 13:45:18
Moin, und das ist im Master und V3 implementiert, oder nur im V3?
Gruß
Jan
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 19 März 2019, 13:49:31
Moin, und das ist im Master und V3 implementiert, oder nur im V3?
nur im Master
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Jasimo am 19 März 2019, 13:51:00
okay, danke.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 20 März 2019, 17:09:59
So, ich hab mich mal mit dem FreqTest beschäftigt. Hat tatsächlich ein paar CC1101 zur (scheinbar) sauberen Funktionalität verholfen.

Was mir aber jetzt "passiert" ist: RESET und damit natürlich auch CONFIG_FREQ1/2 gekillt. Wo/wie wäre einige gute Stelle um die Frequenz im Sketch zu setzen?

Im Setup?
void setup() {
  hal.radio.initReg(CC1101_FREQ2, 0x21);
  hal.radio.initReg(CC1101_FREQ1, 0x65);
  hal.radio.initReg(CC1101_FREQ0, 0xCA);
  DPRINT("Config Freq: 0x2165CA");
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 20 März 2019, 17:20:20
Was mir aber jetzt "passiert" ist: RESET und damit natürlich auch CONFIG_FREQ1/2 gekillt.
Was meinst du mit RESET?
Die Werte vom FreqTest werden ins EEPROM geschrieben und überleben einen Reset.

Man muss jedoch beim Setzen der Fuses darauf achten, dass "Preserve EEPROM on Chip Erase" aktiviert ist.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 20 März 2019, 17:22:28
Die Fuses hab ich nicht verändert. Ich sehe nur im Monitor, dass u.A. "Config Freq: 0x2165CA" ausgegeben wird.

Nen very-long-press auf den Config Taster startet das Ding durch und ab dann seh ich kein "Config Freq: 0x2165CA" mehr also würde ich davon ausgehen, dass es gelöscht wurde.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 20 März 2019, 17:24:02
Die Fuses hab ich nicht verändert. Ich sehe nur im Monitor, dass u.A. "Config Freq: 0x2165CA" ausgegeben wird.

Nen very-long-press auf den Config Taster startet das Ding durch und ab dann seh ich kein "Config Freq: 0x2165CA" mehr also würde ich davon ausgehen, dass es gelöscht wurde.
Ach den RESET meinst du :)
Ja, der initialisiert den EEPROM Inhalt neu
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 20 März 2019, 17:39:35
Dank Jerome scheint es nun zu gehen:

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  if( control.init(hal,DIMMER1_PIN,DIMMER2_PIN) ) {
    // first init - setup connection between button and first channel
    sdev.channel(1).peer(cfgBtn.peer());
  }
  // Init the hw button
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);

  // Set frequency for CC1101
  hal.radio.initReg(CC1101_FREQ2, 0x21);
  hal.radio.initReg(CC1101_FREQ1, 0x65);
  hal.radio.initReg(CC1101_FREQ0, 0xCA);
  DPRINTLN("Config Freq: 0x2165CA");

  sdev.initDone();

  // Output ID and Serial in serial console
  DDEVINFO(sdev);
}
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 21 März 2019, 08:20:21
Ach den RESET meinst du :)
Ja, der initialisiert den EEPROM Inhalt neu
Das ist aber eigentlich blöd :-(
Der RESET sollte nur die Gerätedaten betreffen - die Frequenz ist ja eher ein Hardware Setting, was unabhängig vom logischen Gerät ist.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 24 März 2019, 11:40:36
Kann es sein, dass die Werte für die Frequenzanpassung jetzt nicht mehr durch einen LongPress Reset überschrieben werden?

Ich nutze den Master Stand von heute.

Zitat
11:41:18.492 -> AskSin++ V3.1.7 (Mar 24 2019 11:34:52)
11:41:18.526 -> Address Space: 32 - 73
11:41:18.526 -> CC init1
11:41:18.526 -> CC Version: 14
11:41:18.559 ->  - ready
11:41:18.903 -> Bat: 34
11:41:18.903 -> Config Freq: 0x21653A
11:41:18.903 -> Measure...
11:41:18.903 -> T/H = 273/33
11:41:20.237 -> <- 0C 01 A0 70 345681 00FFFF 01 11 21  - 1710
11:41:20.343 -> -> 0A 01 80 02 00FFFF 345681 00  - 1847
11:41:20.378 -> waitAck: 01
11:42:50.923 ->  debounce
11:42:50.996 ->  pressed
11:42:54.450 ->  longpressed
11:42:58.215 ->  longpressed
11:42:58.215 -> RESET
11:42:58.252 -> AskSin++ V3.1.7 (Mar 24 2019 11:34:52)
11:42:58.252 -> Address Space: 32 - 73
11:42:58.252 -> 00000000
11:42:58.252 -> Init Storage: CAFE6189
11:42:58.392 -> CC init1
11:42:58.392 -> CC Version: 14
11:42:58.425 ->  - ready
11:42:58.770 -> Bat: 34
11:42:58.770 -> Config Freq: 0x21653A
11:42:58.770 -> Measure...
11:42:58.770 -> T/H = 273/33
11:43:00.105 -> <- 0C 01 84 70 345681 000000 01 11 21  - 1871
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 24 März 2019, 12:23:10
Das ist das von mir erwartete Verhalten. Hatte noch keine Zeit selbst zu testen. Weitere Einzelheiten im AskSin++ Beitrag.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Lokverführer am 30 März 2019, 10:57:37
Mal ganz doof gefragt:
Hat hier noch jemand in jüngerer Zeit CC1101 geordert?
Ich habe mittlerweile mehrere Lieferungen von unterschiedlichen Händlern erhalten die alle nicht funktionieren. Zwischendrin kam mal eine Charge (hab nur 2 bestellt) die funktioniert. Langsam kommt mir das schon komisch vor, es kann doch nicht sein, dass die Mehrzahl der Platinen defekt ist zumal die Quarze unterschiedlich sind.
Mittlerweile löte ich sie schon auf Buchsenleisten damit ich mir die Entlötarbeit spare...

Das Test-Sketch hilft mir offenbar wenig, da ich keine HM-Geräte habe sondern nur HmIP. (https://forum.fhem.de/index.php/topic,91740.msg906578.html#msg906578)
Probehalber habe ich es mit den "guten" Modulen mal laufen gelassen, da wurden Werte angezeigt. Bei den defekten überall "0/0".

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Eistee am 30 März 2019, 13:16:59
Hatte auch mal pech und defekte Module bekommen. Inzwischen hab ich Händler in China die zuverlässig funktionierende Module liefern.

Alles auf Aliexpress:
433MHz: https://de.aliexpress.com/item/RTC1101-high-performance-wireless-FSK-transceiver-module-CC1101-radio-transceiver-chip-600-meters-1200bps-433-Mhz/32472259186.html
868MHz: https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html

Hab damit inzwischen über 30 MapleCUN zusammengelötet ohne ein defektes Modul von diesen Lieferanten.

LG Alina
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: CatWeazle am 28 April 2019, 15:20:14
Hi Leutz,

so, nun hat es mich auch erwischt, gleich doppelt. :(

Da habe ich vorsichtshalber bei zwei verschiedenen Anbietern bestellt und bekomme zwei verschiedene Module.

Den FreqTest.ino Sketch in den ProMini geflasht und in Null Komm Nix waren die CC1101 Module beider Anbieter mit korrekter Frequenz unterwegs.

Alles gut, besten Dank für den FreqTest.ino Sketch. :)

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: naneb am 06 Mai 2019, 20:41:34
Nachdem ich lange auf meine PCBs aus China warten musste, konnte ich die ebenfalls aus China gelieferten CC1101 868MHz Module mit 26MHz Quarz-Beschriftung und keiner Leerstelle zwischen MHz und Modul in der Beschriftung  erst letzte Woche testen. Da sie sich nicht an meiner CCU2 anmelden konnten, habe ich mich im Forum auf die Suche gemacht und bin hier fündig geworden. Ich kann freudig vermelden, dass ich nach Tausch der beiden Kondensatoren am Quarz auf 12pF (von Seiten des chinesichen Herstellers waren 20pF verbaut) alle meine 20 Module zum Leben erweckt habe. Eine Oszimessung im Originalzustand hatte ergeben, dass nicht ein einziger Quarz der 20 Module angeschwungen ist. Mit 12pF klappt jetzt alles super. Danke für die Vorarbeit.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 13:31:23
So ich hab mal ne Druckvorlage erstellt um die CC1101 Module vor dem Löten zu testen. In die Löcher kommen Pogo Pins und das Modul wird mit einem einfachen Gummiband fest gemacht. Unten drin ist es hohl, damit man Kabel an die Pogo Pins löten kann.

Vielleicht hat ja jemand Bedarf oder Verbesserungsvorschläge.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 04 Juni 2019, 13:34:56
Für alle, die sich trauen den Quarz und die Kondensatoren zu tauschen, habe ich einen Tipp. Den Quarz durch einen TSX-3226 26MHz und 9pF Kondensatoren ersetzen. Damit habe ich alle Module bisher wieder auf die richtige Frequenz gekriegt.

https://de.aliexpress.com/item/32649740943.html
https://de.aliexpress.com/item/32910476856.html
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 04 Juni 2019, 13:36:34
Vielleicht hat ja jemand Bedarf oder Verbesserungsvorschläge.
Eine Vertiefung für die Briefmarke. Dann kann man auch mit der Hand festhalten. Die Antenne kann für den Test auch einfach weggelassen werden. Wir wollen ja eh nur den guten Bereich haben :-)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 13:38:53
Eine Vertiefung für die Briefmarke. Dann kann man auch mit der Hand festhalten. Die Antenne kann für den Test auch einfach weggelassen werden. Wir wollen ja eh nur den guten Bereich haben :-)

Meinst du ein Test ohne Antenne funktioniert? Hätte jetzt spontan gedacht, dann kommt garnix an.
Ich denke das mit dem festhalten sollte auch ohne Vertiefung passen, sind ja genug Pins da. Ich werde es testen wenn ich es gedruckt habe und CC1101 Module wieder da habe.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 04 Juni 2019, 16:33:00
Meinst du ein Test ohne Antenne funktioniert? Hätte jetzt spontan gedacht, dann kommt garnix an.
Das geht ganz fantastisch. Ich habe derzeit eine 2mm Stiftleiste mit Kabel dran und stecke das Modul nur leicht verkantet auf die Stifte, um den Frequenztest laufen zu lassen.
Es könnte sich ja mal jemand die Mühe machen und eine LCD-Displayansteuerung in den Sketch mit aufnehmen. Dann hätte man ein autarkes Gerät, um die Frequenz zu ermitteln. Und ich hätte endlich eine Verwendung für den Uno inklusive LCD-Keypad-Shield :-)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 04 Juni 2019, 16:57:42
Und ich hätte endlich eine Verwendung für den Uno inklusive LCD-Keypad-Shield :-)
Bist Du Dir sicher, dass der Sketch für den Arduino Uno compiliert? Wenn ich den Sketch für den Arduino nano compiliere, kommt irgend ein dummer exception fault  >:(.

Gruß Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 04 Juni 2019, 18:47:10
So ich hab mal ne Druckvorlage erstellt um die CC1101 Module vor dem Löten zu testen. In die Löcher kommen Pogo Pins und das Modul wird mit einem einfachen Gummiband fest gemacht. Unten drin ist es hohl, damit man Kabel an die Pogo Pins löten kann.

Vielleicht hat ja jemand Bedarf oder Verbesserungsvorschläge.

Das mit den Pogo Pins finde ich gut, die kannte ich nicht.
Ich könnte mir eine Platine für ein "CC1101 Testbench" vorstellen, Arduino Pro Mini, CC1101 über Pogo Pins und ggf. ein LCD. Momentan ist mir das zeitlich nicht möglich aber ich behalte das mal im Hinterkopf.
Kontaktierung des CC1101 in etwa so wie im Bild.

Welche Bezugsquelle nimmst du für die Pogo Pins?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: RaspiLED am 04 Juni 2019, 19:06:55
Hi,
Ich habe solche:

€ 3,15 | Pogo pin stecker pogopin Batterie frühling Geladen Durch Loch 1.2A 80gf nadel PCB 2 3 4 5 6 7 8 9 10 11 12 16
https://s.click.aliexpress.com/e/bjo1v6Be

Oder solche:
€ 1,16  30% Rabatt | Heißer 100 stücke Frühling Test Probe Pogo Pin P75-B1 Dia 1,02mm 100g Schwelle Speer Gold Überzogen Für Test werkzeuge
https://s.click.aliexpress.com/e/bNAu55i0

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 19:41:39
€ 3,15 | Pogo pin stecker pogopin Batterie frühling Geladen Durch Loch 1.2A 80gf nadel PCB 2 3 4 5 6 7 8 9 10 11 12 16
https://s.click.aliexpress.com/e/bjo1v6Be

Oder solche:
€ 1,16  30% Rabatt | Heißer 100 stücke Frühling Test Probe Pogo Pin P75-B1 Dia 1,02mm 100g Schwelle Speer Gold Überzogen Für Test werkzeuge
https://s.click.aliexpress.com/e/bNAu55i0

Bei mir führen leider beide Links ins leere.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: SabineT am 04 Juni 2019, 20:04:47
Bei mir führen leider beide Links ins leere.
einfach nach pogo pins suchen.
https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins (https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins)

Die Idee, sowas zu verwenden finde ich super!

lg,
Sabine
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 20:26:26
einfach nach pogo pins suchen.
https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins (https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins)

Die Idee, sowas zu verwenden finde ich super!

lg,
Sabine

Ich habe solche Pins bereits zuhause und auch einen Adapter gerade gedruckt. Leider ist es relativ schwierig genau 1mm große Löcher zu drucken.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Frank_Huber am 04 Juni 2019, 20:47:29
Ich habe solche Pins bereits zuhause und auch einen Adapter gerade gedruckt. Leider ist es relativ schwierig genau 1mm große Löcher zu drucken.
0,5 drucken und aufbohren?

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 20:52:30
Hab keinen 1mm Bohrer :)
Ich probiere mal mit Einkleben.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: frank am 04 Juni 2019, 21:01:06
statt aufbohren heiss einpressen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Frank_Huber am 04 Juni 2019, 21:30:38
Hab keinen 1mm Bohrer :)
Ich probiere mal mit Einkleben.
Soll ich dir einen schicken? [emoji6]

Gesendet von meinem Doogee S60 mit Tapatalk

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 04 Juni 2019, 21:31:50
Soll ich dir einen schicken? [emoji6]

Gesendet von meinem Doogee S60 mit Tapatalk

Kein Stress. Ich guck erstmal wie die Klebeversion hält. Spricht ja auch nicht gerade fürs Design im Moment.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 04 Juni 2019, 23:27:43
einfach nach pogo pins suchen.
https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins (https://de.aliexpress.com/wholesale?catId=0&initiative_id=AS_20190604100146&SearchText=test+probes+pogo+pins)

Die Idee, sowas zu verwenden finde ich super!

lg,
Sabine

Danke für den link, sehen gut aus, werde mal welche bestellen, auch wenn der Frühling bald vorbei ist  ;)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Ranseyer am 05 Juni 2019, 09:11:04
Möchte eigentlich jemand eine Hand voll Stamps mit dem "868MHz"-Aufdruck (ohne Leerzeichen) geschenkt haben ?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 05 Juni 2019, 09:13:30
Möchte eigentlich jemand eine Hand voll Stamps mit dem "868MHz"-Aufdruck (ohne Leerzeichen) geschenkt haben ?

Bevor du sie weg wirfst würde ich mich mal dran versuchen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 05 Juni 2019, 09:54:20
Möchte eigentlich jemand eine Hand voll Stamps mit dem "868MHz"-Aufdruck (ohne Leerzeichen) geschenkt haben ?
Nehme ich - habe noch Quarze da. Schicke auch gern die Hälfte zurück, wenn sie ordentlich funktionieren.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: CatWeazle am 10 Juni 2019, 20:17:12
Hi Leutz,

ich habe hier gelesen, dass man die seltsamen Module mit dem FreqTest.ino Sketch testen kann.

Okay, ich habe einen fertig aufgebauten HB-UNI-SENS-BATT mit einem Pro-Mini 3V 8Mhz und einem dieser Module, die die Widerstände unter dem Chip Quer angeordnet haben.

In diesen ProMini habe ich den FreqTest.ino Sketch geladen.
So sollte es sein ... ... oder?

Dann sehe ich in dem Beitrag von papa:
Zitat
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
 
usw.


Wie liest man diese Daten?
Über die serielle Schnittstelle des ProMini kommen keine vernünftigen Daten, egal wie schnell ich sie einstelle ?!?!?
 
Wat nu ?



EDIT 20:41!

okay, mein Fehler, die Einstellung in der Aruino IDE war falsch, ProMini 5V :(
Aber was soll ich sagen, kaum macht man es richtig, schon funktioniert es bei 57600 Baud
Die Frequenz des Moduls wurde auch angepasst und schon in FHEM eingebunden :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: DirkS am 13 Juni 2019, 08:02:20
Leider muss ich wohl auch solche fehlerhaften Module erwischt haben. Der erste Versuch ein HM-WDS40-TH-I-BME280 nach zubauen schlug fehl. Ich hatte dann noch ein älteres CC1101 in der Schublade gefunden, welches mal für ein CUL gedacht war. Dies wurde dann zu einem HM-LC-Sw2-FM zusammen gebaut und funktioniert auf Anhieb. Da diese beiden aktuell meine einzigen Homematic Komponenten sind, habe ich also die beiden Module und die CCU2 nebeneinander gelegt und getestet. (Vielleicht auch ein Fehler?)
Ohne ActivePing und nur die CCU2 im Anlernmodus passiert beim HM-WDS40-TH-I-BME280, welches das Frequenz Sketch laufen hat, keine Ausgabe. Wenn ich dann über die CCU oder am HM-LC-Sw2-FM den Anlernknopf drücke empfängt das HM-WDS40-TH-I-BME280 ein paar Telegramme und stellt auch eine Frequenz ein. Wobei die hintere Zahl vom HM-LC-Sw2-FM immer größer ist, wie die von der CCU2. Wenn dann wieder das richtige Sketch geflasht wird scheint die CCU2 wohl manchmal den Anlernversuch zu erkennen, denn es erscheint im Log die Seriennummer aber dann wird vom HM-WDS40-TH-I-BME280 wohl die Bestätigung nicht korrekt gesendet oder die Antwort von der Basis nicht erkannt.
Ist die hintere Zahl der Ausgabe aus dem Frequenztest Skript die Signalstärke?
Kann ein falsch konfiguierter BME280 den Funkverkehr beeinflussen? Denn als Meßwerte kommen ~250C und 0% raus. Hatte mich aber darum noch nicht weiter gekümmert.
Logs liefere ich heute Abend noch nach. Musste nur mal meinen Frust loswerden. Hoffe es ist nicht zu konfus.
[Nachtrag]
Ich habe wohl meine Platine mit 5V gegrillt. Der USB/Serial Adaoter hat einen 3V/5V Schalter. Aber dies scheint wohl nur die Signalpegel zu betreffen. Als Vcc kommt immer 5V raus... :-(
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: berniie am 20 Juni 2019, 17:43:24
Hallo,
ich bekomme folgende Werte mit dem Test Sketch.

Done: 0x2164EA - 0x2165DA
Calculated Freq: 0x216562
Store into config area: 6562

Gibt es eine Formel mit der man daraus berechnen kann, um wieviel khz mein C1101 daneben liegt?

Gruß,
Jörg
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 20 Juni 2019, 18:08:43
hatte gerade heute dazu was in einem anderen thread gepostet:
https://forum.fhem.de/index.php/topic,101568.msg950636.html#msg950636 (https://forum.fhem.de/index.php/topic,101568.msg950636.html#msg950636)

in deinem Fall sind das 868,2967 MHz, nur 3kHz Abweichung zum Originalwert 868.299866 MHz.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: berniie am 20 Juni 2019, 19:16:29
Danke für die Info. Hatte auch den Eindruck, dass meine im Februar bestellten Module ganz ok sind.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Oktober 2019, 01:09:10
Bedeutet eigentlich bei der RSSI Ausgabe hinten z.B. die 76 hier
req 0x21655A 868.294 MHz: 583E8D.  1/76
ein hoher Wert eine bessere Empfangsstärke?

In radio.h wird das so berechnet:
        uint8_t rsshex = spi.readReg(CC1101_RXFIFO, CC1101_CONFIG);         // read RSSI
        rss = -1 * ((((int16_t)rsshex-((int16_t)rsshex >= 128 ? 256 : 0))/2)-74);

Habe Module die durchgängig 70..80 RSSI haben und andere die um die 50 liegen.
Frage mich ob die 50er irgendwie schlechter sind.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 16 Oktober 2019, 06:33:46
Da gehört eigentlich ein Minus (-) davor.

Die Kalkulation rss = -1 *... macht den Wert wieder positiv und ist für die Übertragung zur CCU. Die RSSI Werte werden dort unsigned erwartet.

-50 sind besser als -70...-80

Hier noch was zum Lesen:
http://www.ti.com/lit/an/swra114d/swra114d.pdf
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Ranseyer am 16 Oktober 2019, 09:04:27
Entweder diese haben einen schlechteren Empfang (Weil für das jeweils andere Band gedacht: 433/868 MHz), oder die Messung fällt schlechter aus wären meine beiden Theorien...

https://de.wikipedia.org/wiki/Received_Signal_Strength_Indication


Beispiel: DVB-Karten scheinbar baut der Hersteller der im Treiber nochmals kurz etwas addiert :-)  8)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Oktober 2019, 12:20:19
Danke für die links und besonders Jerome für die Klarstellung bei der Berechnung.
Habe auch mehr Module mit 50 oder 60 und wenige mit 70..80.
Das RSSI Interpretation and Timing pdf schaue ich mir noch mal in Ruhe an.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 16 Oktober 2019, 12:49:16
Es gab schon mal eine Korrektur bei der RSSI-Berechnung in der AskSinPP
https://github.com/pa-pa/AskSinPP/pull/120

Um die Werte an sich hab ich mir jedoch noch nie Gedanken gemacht.
Für mich zählt nur "Gerät erreichbar".
Der RSSI-Wert ist nur eine Momentaufnahme. Verlässliche Vergleichswerte zu ermitteln halte ich für kaum machbar.
Da reichts schon aus, wenn man seinen eigenen Körper mal anders positioniert, die Antenne nicht aufs µ exakt identisch ist (Länge, Ausrichtung) oder beim Nachbarn die Mikrowelle läuft...
Ich hab früher mal im BOS-Bereich HF-Geräte abgeglichen mit extra HF-dichtem Gehäuse und Schlumberger Messtechnik.
Da konnte man schön sehen, wie sich äußere Einflüsse auswirken, wenn man auf die Abschirmung verzichtet hat.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Oktober 2019, 13:07:45
sehr interessant, jetzt habe ich mir das pdf angesehen und weiß z.B. wo die 74 herkommen  :).

habe gestern meinen cc1101 Vorrat durchgemessen, alle kurz hintereinander und ein paar davon auch 2x.
Die Werte waren reproduzierbar.
Das alles mit meiner provisorischen test bench durch Runterdrücken des Moduls mit der Hand, da könnte es Varianz geben.

Ich designe mal demnächst eine richtige test bench Platine wo das Modul durch eine Art Rahmen fixiert werden wird.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 16 Oktober 2019, 13:13:37
Der Pogo-Pin an der Antenne ist aber auch nicht gerade förderlich für einen guten Empfang. Das Ding wirkt doch wie eine "Verlängerung" der Antenne.

Ich löte seit neuestem immer 2mm Pinheader an die Module, bei Platinen mit Löchern. Somit sind sie steckbar und können einfach ausgetauscht werden. Vielleicht als Vorschlag für weitere Platinenentwicklungen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 16 Oktober 2019, 13:18:56
Der Pogo-Pin an der Antenne ist aber auch nicht gerade förderlich für einen guten Empfang. Das Ding wirkt doch wie eine "Verlängerung" der Antenne.
Da warst du jetzt schneller als ich.

Aber gut, dann ist es halt für alle getesteten Module im Vergleich gleich schlecht.

Ich designe mal demnächst eine richtige test bench Platine
Ich weiß nicht, ob sich der Aufwand lohnt,....
Hast du einen konkreten Fall, wo ein Gerät "gerade so" nicht erreichbar ist?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Oktober 2019, 13:22:21
Das mit der Antenne und dem pogo pin sehe ich auch so, ist mir aber egal da es mir nur um eine Vorab Qualifizierung des Moduls vor dem Einlöten geht (und nur interessehalber um einen Vergleich der Module untereinander mit RSSI..)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 Oktober 2019, 13:25:51
Da warst du jetzt schneller als ich.

Aber gut, dann ist es halt für alle getesteten Module im Vergleich gleich schlecht.
Ich weiß nicht, ob sich der Aufwand lohnt,....
Hast du einen konkreten Fall, wo ein Gerät "gerade so" nicht erreichbar ist?

Ist nicht wirklich Aufwand, leichte Modifikationen von einer vorhandenen Platine..
Nein, keine konkreten Probleme mit der Erreichbarkeit im Moment..  :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 16 Oktober 2019, 13:31:51
und nur interessehalber um einen Vergleich der Module
Alles klar, das dachte ich mir schon fast. ;) :-X
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag 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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 24 Oktober 2019, 07:52:35
GDO0 ist richtig angeschlossen ? Das würde das Verhalten erklären. Man kann ordentlich senden, aber da die Interrupts nicht durchkommen, hört man nichts :-(
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 24 Oktober 2019, 09:50:18
GDO0 war richtig verbunden, ich hatte die ganzen Signalpfade gestern noch geprüft. Aber die kleine Lötbrücke zw. GDO0 und TX ist mir gestern nicht aufgefallen, erst heute beim Tageslicht.

Wie auch immer, danke für den Tipp, und Entwarnung, keine defekten CC1101 mit neuem Fehlerbild im Umlauf! Mein anderes Problemexemplar muss wohl auch unter die Lupe :)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 24 Oktober 2019, 22:27:52
Guten Abend,

leider gestaltet es sich mit dem anderen Problemkandidaten nicht so einfach. Bzgl. Hardware: es ist die FDGK-Platine V1.1. Was ich bis jetzt (mehrfach) gemacht habe:
- Pins des Atmega auf Kurzschlüsse untersucht
- Verbindung zw. Atmega und CC1101 überprüft
- Anschlüsse des CC1101 auf Kurzschlüsse untersucht
- Sämtliche Lötstellen nachgelötet
- Frequenztest laufen lassen

Das Problem bleibt:
- Der Frequenztest meldet: "Could not receive any message"
- FHEM kriegt die Nachrichten mit
- Auf der seriellen Konsole sehe ich, dass FHEMs Antworten nicht empfangen werden, obwohl sie da sein müssten
- Es ist mir mehrfach gelungen, durch mehrfaches Drücken des Config-Buttons doch Antworten von FHEM zu empfangen und damit das Pairing abzuschließen, aber leider nie reproduzierbar und auch das anschließende "getConfig" schlug wieder fehl
- RSSI leigt im Übrigen bei etwa -39 bzw. -56 (2 IOs)

Dadurch, dass das Funkmodul ein paar Mal FHEMs Nachrichten empfangen konnte, steht für mich fest, dass es nicht ganz taub sein kann. Aber woran kann es sonst noch scheitern?

Hatte im Übrigen auch unterschiedliche FW-Versionen geflasht, die sich teilweise nur durch die Version der AskSin-Lib unterschieden haben, das Verhalten blieb gleich.

Noch irgendwelche Ideen?  ;)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 13 November 2019, 18:53:25
Hallo zusammen,

ich habe mittlerweile 9 CC1101 Module auf meinem nanoCUL getestet und habe bei jedem folgenden Output an der seriellen Schnittstelle:
AskSin++ V4.0.3 (Oct 18 2019 15:02:50)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A 868.300 MHz:   0/0
Freq 0x2165BA 868.332 MHz:   0/0
Freq 0x21651A 868.268 MHz:   0/0
Freq 0x21660A 868.363 MHz:   0/0
Freq 0x2164CA 868.236 MHz:   0/0
Freq 0x21665A 868.395 MHz:   0/0
Freq 0x21647A 868.205 MHz:   0/0
Freq 0x2166AA 868.427 MHz:   0/0
Freq 0x21642A 868.173 MHz:   0/0
Freq 0x2166FA 868.459 MHz:   0/0
Freq 0x2163DA 868.141 MHz:   0/0
Freq 0x21674A 868.490 MHz:   0/0
Freq 0x21638A 868.109 MHz:   0/0
Freq 0x21679A 868.522 MHz:   0/0
Freq 0x21633A 868.078 MHz:   0/0
Freq 0x2167EA 868.554 MHz:   0/0
Freq 0x2162EA 868.046 MHz:   0/0
Freq 0x21683A 868.586 MHz:   0/0
Freq 0x21629A 868.014 MHz:   0/0
Freq 0x21688A 868.617 MHz:   0/0
Freq 0x21624A 867.982 MHz:   0/0
Freq 0x2168DA 868.649 MHz:
Done: 0x21656A - 0x21656A
Could not receive any message

Meiner Ansicht nach ist in meinem Testaufbau prinzipiell was faul, da ich der Meinung bin, dass einige Module von unterschiedlichen Verkäufern sind und funktionieren sollten.

Was habe ich gemacht:
- Frequenztest Sketch aufgespielt (Arduino nano, entsprechend kompiliert)
- das jeweilige Modul aufgesteckt (Bild des Testaufbau kann ich gerne nachreichen)
- laufenlassen und bei jeder Frequenz einen Knopf meines Homematic e-Paper Displays gedrückt
  (die Events sind im FHEM Event Monitor angekommen)

Wo muss ich suchen? Meine Suchfelder sind momentan:
Oder andere Alternative:
Ich baue einen Fenstersensor aus (die sind gepairt) und lasse den Sketch da drauf laufen und schaue, was passiert. Dann hätte ich die Punkte 1. und 2. von oben schon mal ausgeschlossen, ggf. auch 3.

Habt ihr noch andere Ideen, bin momentan ziemlich ratlos.
Zwei andere Module sind schon auf Ultraschallsensoren aufgelötet und eines zeigt dasselbe Verhalten, lässt sich nicht pairen, aber empfängt artig die Messdaten. Selbes Verhalten beim Frequenztest  :o :o :o
Zwei weitere sind auf der CR2032 Platine v1.2 aufgelötet, bisher ungetestet.
Zwei neue Module sind von China aus unterwegs. Die sollten aus einer funktionierenden Charge sein.

Danke für Eure Anregungen bzw. Geduld. Gerne schicke ich jemand ein oder zwei Module zum Testen zu.

Gruß Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: tndx am 13 November 2019, 19:56:49
Hi,

das deckt sich ja exakt mit meinem Problembild, nur dass ich ich bei mir Kontaktprobleme ausschließen kann, denn die Module sind bereits auf unterschiedlichen Platinen aufgelötet, und eins davon zeigt das gleiche Verhalten auch ganz ohne AskSin++ (Dirks Universalsensor-FW).

Ich habe meine letzten CC-Module, bestimmt 20 Stück, immer aus einer Quelle bezogen, die meisten waren auch vollkommen ok, aber 2 zeigen eben dieses Verhalten (und ein paar liegen noch eingeschweißt in der Tüte)...

 
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 November 2019, 01:34:10
Hallo zusammen,

ich habe mittlerweile 9 CC1101 Module auf meinem nanoCUL getestet und habe bei jedem folgenden Output an der seriellen Schnittstelle:
...

Habt ihr noch andere Ideen, bin momentan ziemlich ratlos.

Danke für Eure Anregungen bzw. Geduld. Gerne schicke ich jemand ein oder zwei Module zum Testen zu.

Gruß Peter

Hallo Peter,

das eine Modul von den 9 ist Freitag angekommen.
Habe es nur kurz heute Nacht mit meiner Standard Cfg (ActivePing zu einen 220V Switch an der Garage) laufen lassen, was soll ich sagen, es lief auf Anhieb.
Sieht total ähnlich aus zu meinen anderen Modulen, auch das die Freq einen Tick tiefer als die 868,3 ist.

An den Modulen kann es nicht liegen.
Kann auch morgen noch mal den passiven Modus testen wenn du willst, finde aber den aktiven angenehmer da schneller.

AskSin++ V4.0.3 (Nov 16 2019 01:22:30)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A 868.300 MHz: 583E8D.  1 / -57dBm
Search for upper bound
Freq 0x21657A 868.306 MHz:   0
Search for lower bound
Freq 0x21655A 868.294 MHz: 583E8D.  1 / -57dBm
Freq 0x21654A 868.287 MHz: 583E8D.  1 / -57dBm
Freq 0x21653A 868.281 MHz: 583E8D.  1 / -57dBm
Freq 0x21652A 868.274 MHz: 583E8D.  1 / -57dBm
Freq 0x21651A 868.268 MHz: 583E8D.  1 / -56dBm
Freq 0x21650A 868.262 MHz: 583E8D.  1 / -57dBm
Freq 0x2164FA 868.255 MHz: 583E8D.  1 / -57dBm
Freq 0x2164EA 868.249 MHz: 583E8D.  1 / -57dBm
Freq 0x2164DA 868.243 MHz: 583E8D.  1 / -57dBm
Freq 0x2164CA 868.236 MHz: 583E8D.  1 / -57dBm
Freq 0x2164BA 868.230 MHz: 583E8D.  1 / -57dBm
Freq 0x2164AA 868.224 MHz:   0

Done: 0x2164BA - 0x21656A
Calculated Freq: 0x216512 868.265 MHz
Store into config area: 6512

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 16 November 2019, 09:09:19
Hallo Tom,

danke für die Nachtschicht  ;). Ich habe mittlerweile noch mal den Sketch von hier (https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#frequenzanpassung-per-sketch) neu compiliert und bin mit meinem Homematic Display 3 m weg von der Teststelle, und siehe da: es funktioniert:
AskSin++ V4.0.3 (Nov 16 2019 06:41:30)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A 868.300 MHz:   0
Freq 0x2165BA 868.332 MHz: 6935D1.  1 / -65dBm
Search for upper bound
Freq 0x2165CA 868.338 MHz: F10000.  1 / -75dBm
Freq 0x2165DA 868.344 MHz:   0
Search for lower bound
Freq 0x2165AA 868.325 MHz: F10000.  1 / -76dBm
Freq 0x21659A 868.319 MHz: 6935D1.  1 / -65dBm
Freq 0x21658A 868.313 MHz: 6935D1.  1 / -72dBm
Freq 0x21657A 868.306 MHz:   0

Done: 0x21658A - 0x2165CA
Calculated Freq: 0x2165AA 868.325 MHz
Store into config area: 65AA

Jetzt teste ich mal alle Module durch und schreibe die Frequenzen drauf.

Gruß Peter

Edit:
Hier das Ergebnis:
Calculated Freq: 0x21660A 868.363 MHz
Calculated Freq: 0x2165C2 868.335 MHz
Calculated Freq: 0x2165BA 868.332 MHz
Calculated Freq: 0x2165BA 868.332 MHz
Calculated Freq: 0x2165AA 868.325 MHz
Calculated Freq: 0x21657A 868.306 MHz
Calculated Freq: 0x216572 868.303 MHz
Calculated Freq: 0x216572 868.303 MHz
Calculated Freq: 0x216512 868.265 MHz (von Tom getestet)

Ich habe auch mal ein Bild meines Testaufbaus drangehängt.

Fazit: Man sollte den Sender nicht zu dicht am zu testenden Modul haben, bei mir waren es jetzt so ca. 3 m.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 16 November 2019, 11:10:01
Hallo Tom,

danke für die Nachtschicht  ;). Ich habe mittlerweile noch mal den Sketch von hier (https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#frequenzanpassung-per-sketch) neu compiliert und bin mit meinem Homematic Display 3 m weg von der Teststelle, und siehe da: es funktioniert:


Kein Problem. Also lag es "nur" am Standort des Testaufbaus.

Die Abweichung bei unseren Tests bzgl. der gefundenen Freq. liegt eventuell auch an der Center Freq. der Zentrale, meine leicht unterhalb der 868,3, deine oberhalb + die Abweichung der Module selbst.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 16 November 2019, 18:37:52
Hm, und das Modul im Utraschallsensor zickt immer noch rum:
- mit der Frequenz 0x21656A (Standard) lässt es sich pairen
- der Frequenztest hat nur was sporadisches ausgespuckt (einmal was um 868.300 MHz)
- nach kürzen der Antenne auf 82.2 mm war der Bereich dann 0x21679A (=868.522 MHz),
  aber FHEM hat nichts mehr empfangen

Hier noch mal die Beschreibung, was funktioniert und was nicht:
- der Ultraschallsensor wird erkannt (0x21656A), aber nicht gepairt (RESPONSE TIMEOUT:RegisterRead)
- er sendet aber (ungepairt) alle Messwerte einigermaßen zuverlässig
2019-11-16 18:10:59 CUL_HM HM_3E8A69_Values batVoltage: 1.3
2019-11-16 18:10:59 CUL_HM HM_3E8A69_Values distance: 89.8
2019-11-16 18:10:59 CUL_HM HM_3E8A69_Values 89.8 1.3
2019-11-16 18:14:12 CUL_HM HM_3E8A69_Values batVoltage: 1.3
2019-11-16 18:14:12 CUL_HM HM_3E8A69_Values distance: 89.7
2019-11-16 18:14:12 CUL_HM HM_3E8A69_Values 89.7 1.3
2019-11-16 18:17:25 CUL_HM HM_3E8A69_Values batVoltage: 1.3
2019-11-16 18:17:25 CUL_HM HM_3E8A69_Values distance: 89.7
2019-11-16 18:17:25 CUL_HM HM_3E8A69_Values 89.7 1.3
- getconfig bricht mit o.g. Fehlermeldung ab
- im Frequenztest wird keine Frequenz erkannt

Jetzt werde ich mal die Antenne prüfen (welche Länge ist den optimal?) und ggf. das Modul auslöten und gegen ein anderes austauschen. Oder hat jemand noch eine Idee?

Danke + Gruß

Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 16 November 2019, 19:38:05
Hallo tndx,

Das Problem bleibt:
- Der Frequenztest meldet: "Could not receive any message"
- FHEM kriegt die Nachrichten mit

Noch irgendwelche Ideen?  ;)
ggf. schwingt bei diesen Modulen der Quarz unsauber, siehe locutus' Post hier (https://forum.fhem.de/index.php/topic,91740.msg882803.html#msg882803).
Das würde m.E. erklären, dass kurze Nachrichten empfangen werden, die langen (wie nach getconfig) eher nicht. Wäre das plausibel?

Gruß Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 16 November 2019, 23:30:10
Hallo zusammen,

irgendwie scheint die Reproduzierbarkeit des Frequenztests nicht stabil zu sein. Dasselbe Modul zweimal ohne active ping und zweimal mit active ping zeigt folgendes Ergebnis:
Calculated Freq: 0x216572 868.303 MHz
Calculated Freq: 0x21651A 868.268 MHz
Calculated Freq: 0x21660A 868.363 MHz (ap)
Calculated Freq: 0x21679A 868.522 MHz (ap)
Hattet ihr das schon mal?

Gruß Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 17 November 2019, 13:22:00
Hallo zusammen,

irgendwie scheint die Reproduzierbarkeit des Frequenztests nicht stabil zu sein. Dasselbe Modul zweimal ohne active ping und zweimal mit active ping zeigt folgendes Ergebnis:
Calculated Freq: 0x216572 868.303 MHz
Calculated Freq: 0x21651A 868.268 MHz
Calculated Freq: 0x21660A 868.363 MHz (ap)
Calculated Freq: 0x21679A 868.522 MHz (ap)
Hattet ihr das schon mal?

Gruß Peter

nein, diese Art Abweichung hatte ich noch nie. Das Modul sieht unbrauchbar aus.
Vielleicht liegt es tatsächlich an dem unsauberen Schwingen des Quarzes  :o
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 24 November 2019, 18:11:36
Habe mal meine Idee einer CC1101 Testbench in eine erste Version umgesetzt, Details hier:
https://homematic-forum.de/forum/viewtopic.php?f=76&t=54701 (https://homematic-forum.de/forum/viewtopic.php?f=76&t=54701)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 03 Januar 2020, 23:06:50
Gibt es eigentlich eine zuverlassige Quelle für ordentliche Module? Bräuchte mal wieder etwas Nachschub.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: locutus am 08 Januar 2020, 22:03:00
Diese Module mit der Bezeichnung CC11010 aus der Bucht werden mit einer falschen Antenne ausgeliefert! Zuerst haben mich die schlechten RSSI-Werte gewundert. Dann ist mir die ungewöhnliche Antennenlänge aufgefallen.

Vor dem Antennentausch, mitgelieferte Helixantenne, ca. 17 Windungen (vermutlich 433 MHz):
AskSin++ V4.1.1 (Jan  8 2020 21:15:00)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A 868.300 MHz:   0
Freq 0x2165BA 868.332 MHz: 987401.  1 / -80dBm
Search for upper bound
Freq 0x2165CA 868.338 MHz: B5D148.  1 / -81dBm
Freq 0x2165DA 868.344 MHz: 987401.  1 / -80dBm
Freq 0x2165EA 868.351 MHz:   0
Search for lower bound
Freq 0x2165AA 868.325 MHz: 21F2AF.  1 / -98dBm
Freq 0x21659A 868.319 MHz: 27CBF9.  1 / -75dBm
Freq 0x21658A 868.313 MHz: B5D148.  1 / -81dBm
Freq 0x21657A 868.306 MHz:   0

Nach dem Antennentausch, Helixantenne mit 8 Windungen:
AskSin++ V4.1.1 (Jan  8 2020 21:30:00)
CC init1
CC Version: 14
 - ready
Start searching ...
Freq 0x21656A 868.300 MHz: 232B5C.  1 / -66dBm
Search for upper bound
Freq 0x21657A 868.306 MHz: B5D148.  1 / -70dBm
Freq 0x21658A 868.313 MHz: A5A501.  1 / -53dBm
Freq 0x21659A 868.319 MHz: 27CBF9.  1 / -65dBm
Freq 0x2165AA 868.325 MHz: B5D148.  1 / -69dBm
Freq 0x2165BA 868.332 MHz: 21F2AF.  1 / -80dBm
Freq 0x2165CA 868.338 MHz:   0
Search for lower bound
Freq 0x21655A 868.294 MHz:   0

Done: 0x21656A - 0x2165BA
Calculated Freq: 0x216592 868.316 MHz
Store into config area: 6592...stored!

Das Footprint wurde ebenfalls überarbeitet. Der Abstand am 3-pol. Antennenanschluß wurde von 2,54 auf 2 mm reduziert.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 08 Januar 2020, 22:08:21
Ich nutze schon immer einen Draht als Antenne da ich damit bislang immer bessere Ergebnisse erzielt habe.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 08 Januar 2020, 23:07:02
Das Footprint wurde ebenfalls überarbeitet. Der Abstand am 3-pol. Antennenanschluß wurde von 2,54 auf 2 mm reduziert.

das ist schon seltsam, hoffentlich bleibt das ein Einzelfall - wegen den vielen Homebrew Platinen.
Welcher Händler genau verkauft die?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: jp112sdl am 08 Januar 2020, 23:37:48
das ist schon seltsam, hoffentlich bleibt das ein Einzelfall - wegen den vielen Homebrew Platinen.
Sind das so viele?
Bei deinen, beim HMSensor (https://raw.githubusercontent.com/pa-pa/HMSensor/master/HMSensor-StepUp/panel10/Untitled_Combined_Bottom.png) und am AskSinAnalyzer (https://raw.githubusercontent.com/stan23/myPCBs/master/AskSinAnalyzer/Bilder/Platine_bestückt.jpg) sind die Antennen-Pins auf die Platine gebracht.

Ansonsten find ich keine weiter. Weder bei den Platinen deimos (https://github.com/alexreinert/PCB), stan23 (https://github.com/stan23/myPCBs), pafra (https://github.com/pafra-123/AskSin_Uni_PCB) oder mir (https://github.com/jp112sdl/328RFStamp) (und hier (https://github.com/jp112sdl/HB-RC-2-PBU-LED)).

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 08 Januar 2020, 23:54:46
papas Platinen haben es auch gehabt in 2017
https://forum.fhem.de/index.php/topic,73954.0.html (https://forum.fhem.de/index.php/topic,73954.0.html)
interessanterweise mit 2mm Abstand an der Antennenseite, damals ev. ein Bug, heute ein Feature  ;)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 09 Januar 2020, 07:53:28
Hallo Damian,

Das Footprint wurde ebenfalls überarbeitet. Der Abstand am 3-pol. Antennenanschluß wurde von 2,54 auf 2 mm reduziert.
meines Wissens war der schon immer im 2 mm Raster, ich kenne keine Module im 2,54 mm Raster.

Gruß Peter

Edit: Stimmt, die Seite mit den vielen Pins war im 2 mm Raster, die Antennenseite (wenig Pins) war im 2,54 mm Raster.

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Omega-5 am 09 Januar 2020, 10:07:21
meines Wissens war der schon immer im 2 mm Raster, ich kenne keine Module im 2,54 mm Raster.

Gruß Peter
Hallo Peter,

das kann ich leider nicht bestätigen. Ich habe noch Module (defekt) aus zwei Lieferungen 2015 und 2016. Beide mit Raster 2,54mm am Antennenanschluss.

Edit: Ich bin zwar schon ein wenig älter  ;) aber die Erinnerung und die Suche haben geholfen.
https://forum.fhem.de/index.php/topic,38561.msg488298.html#msg488298 (https://forum.fhem.de/index.php/topic,38561.msg488298.html#msg488298)
Die nanoCUL Layouts und Libs liegen auch noch bei mir im Eagle Verzeichnis.

LG Friedrich
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 09 Januar 2020, 18:26:15
meines Wissens war der schon immer im 2 mm Raster, ich kenne keine Module im 2,54 mm Raster.

da stimme ich Omega-5 zu, die Antennenseite hatte bisher das 2,54mm Raster.
Alle von Jerome aufgezählten Platinen (inkl. meiner), bei denen die Antennenpins auf die Platine gebracht wurden, berücksichtigen das.
Deswegen war ich auch erstaunt über locutus Nachricht bezüglich der Änderung auf 2mm.

Die andere Seite (SPI, Vcc) hatte schon immer 2mm.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 09 Januar 2020, 18:50:07
... die Antennenseite hatte bisher das 2,54mm Raster.
Die andere Seite (SPI, Vcc) hatte schon immer 2mm.
Ja, ihr habt recht, habe meinen Post oben korrigiert. Dann muss ich meine neuen Module mal messen  :o.

Danke + Gruß

Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Eistee am 11 Januar 2020, 10:23:29
Evtl. hilft das:
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Eistee am 11 Januar 2020, 10:27:10
Ahja und ich hatte mal für KiCAD einen Footprint erstellt:
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Omega-5 am 11 Januar 2020, 11:27:49
Ahja und ich hatte mal für KiCAD einen Footprint erstellt:

Könntest du uns die Quelle deiner Maßzeichnung nennen? Ich habe noch eine Zeichnung von Apr. 2012 gefunden. Nach der habe ich damals auch die Layouts von PeMue kontrolliert.  ;)

Friedrich
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Eistee am 11 Januar 2020, 16:14:24
Von meinem Lieferanten in China. Also um genau zu sein sind das die 433MHz Module (blau). Die 868MHz Module (grün) haben allerdings die gleichen Maße. Dort sind nur die Anschlüsse etwas anders. Die sind meist auch nicht ganz 19mm. Mit 2mm Stiftleisten kann man aber beide gleich anschließen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: PeMue am 18 Januar 2020, 21:41:20
... die Welt macht irgendwann keinen Spaß mehr  ??? ??? ??? ...

Gruß Peter
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 19 Januar 2020, 00:00:32
ist nicht so schlimm glaub ich.

die Massepins an der Ant. könnte man schräg einlöten oder weglassen.
(Ob man die Massepins an der Ant. überhaupt verbinden sollte gibt es einen thread im orangen Forum und geteilte Meinungen (bis das mal jemand mit Profi-Equipment vergleichend messen kann).

Die Antenne kann man auch direkt in den CC1101 einlöten, ich persönlich verbinde zumindest gern das Ant.pin mit der Platine um nicht später ggf. beim Antennenwechsel am CC1101 rumlöten zu müssen und das Hühnerfutter dort drauf zu gefährden  ;)
HF technisch sauberer wäre es die Ant. direkt im CC1101 zu haben, ich habe aber in der Praxis keine Probleme mit dem Übergang auf die Platine.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: gloob am 25 Januar 2020, 20:05:15
Ich habe jetzt auch ein paar Platinen der Testbench erhalten und leicht modifiziert.

Ich habe in die Löcher der Platine ein M3 Gewinde geschnitten und von unten eine Schraube rein gedreht.
Zusätzlich habe ich die Löcher in der gedruckten Klemme auf M3 Durchgangsloch vergrößert.
Von oben kann ich so mit einer M3 Mutter den Halter festklemmen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Ralf9 am 19 März 2020, 23:03:52
Zitat
Diese Module mit der Bezeichnung CC11010 aus der Bucht werden mit einer falschen Antenne ausgeliefert! Zuerst haben mich die schlechten RSSI-Werte gewundert. Dann ist mir die ungewöhnliche Antennenlänge aufgefallen.
Ich habe auch so ein Modul, ich wollte von einem anderem Modul eine richtige Antenne einlöten, dabei ist mir aber aufgefallen, daß dafür die Bohrung zu klein ist. In der Anlage ist ein Vergleich der beiden Antennen.
Kann ich die Bohrung einfach mit einem Bohrer vergrößern?

Ist es möglich eine Koaxbuchse auch direkt an ein CC11010 oder CC1101 Modul anzulöten?

Gruß Ralf
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Psi am 19 März 2020, 23:22:54
Meine persönliche Erfahrung ist, dass ein Steifdraht in passender Länge mit möglichst viel Abstand zur "Elektronik" die Besten RSSI Werte ergab.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Ranseyer am 20 März 2020, 11:29:41
Zitat
Steifdraht in passender Länge mit möglichst viel Abstand zur "Elektronik" die Besten RSSI Werte

Absolut.

0. unbedingt meiden: Die billigen verpupferten Stahl-Draht Spulen. (Außer es gibt keinen Platz)

1. Draht. Keine Litze, ein massiver Draht aus Kupfer. (Besser: Versilbert, weil da nicht oxidiert. Isoliertes Kupfer wäre auch schon mal ein Kompromiss. Achtung hängt massiv vom "Gegengewicht in der Umgebung ab. Das ist vor allem die Massefläche der Platine))

2. Dipol Antenne die wie ein Stab aussieht: https://forum.fhem.de/index.php/topic,93021.msg856054.html#msg856054 ( Siehe Foto CS-Family. Platinen-Antennen sind billig/wiederholbar mit identischer Qualität produzierbar)

3. Eine Groundplane ist relativ einfach zu bauen und wäre noch besser als Rundstrahler. Ist aber meist blöd unterzubringen (Erleichterung beim Bauen: https://www.thingiverse.com/thing:2849393 . Diese Antenne ist kaum noch von der Umgebung abhängig...)

@Ralf9: Du hast von mir eine Antenne mit der Aufschrift VSWR=1.2 erhalten. Die habe ich persölich gemessen. Das sollte so ein Teil von CS-Family sein, und die sind für ihre Größe super !
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: kpwg am 20 März 2020, 11:37:01
1. Draht. Keine Litze, ein massiver Draht aus Kupfer.
Da musste ich jetzt beim Gedanken an alle ARR- und Fertiggeräte von EQ3 schmunzeln. Hier hat die Litze eher den Vorteil, sich Reklamationen wegen zwölfmal verbogener und schließlich gebrochener Antenne fernzuhalten. Ich nehme für gewöhnlich auch isolierte Litze- hat sich eben bewährt und genügt an dieser Stelle.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Pek am 12 April 2020, 17:54:04
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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Pek am 12 April 2020, 18:12:53
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 13 April 2020, 17:03:12
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 (https://github.com/kc-GitHub/Wettersensor/blob/master/Firmware-Release/HB-UW-Sen-THPL_update_V0_15_000_150303.hex)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag 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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 13 April 2020, 18:34:39
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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 13 April 2020, 21:10:02
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  ???
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 24 April 2020, 00:05:36
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   :-[
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Tom Major am 24 April 2020, 23:35:25

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.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 10 Mai 2020, 15:29:11
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 (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 (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 (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 (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 (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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 10 Mai 2020, 21:24:22
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?

Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 10 Mai 2020, 22:27:41
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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 10 Mai 2020, 22:41:14
Im OTA-Bootloader ist das nicht in einer Zeile sondern geteilt in zwei.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 10 Mai 2020, 23:26:40
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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 11 Mai 2020, 22:08:50
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:

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?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Klaus0815 am 11 Mai 2020, 23:31:21
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
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 12 Mai 2020, 08:36:38
Danke für den gut gemeinten Ratschlag. Die Firmmware von Dirks Wettersensoren basiert aber nicht auf papas asksinpp, deswegen kann ich da auch nicht einfach Werte ins EEPROM schreiben. Sicher gebe es auch hier andere Möglichkeiten, als die Frequenz zu patchen, aber darum geht es hier nicht.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 12 Mai 2020, 09:34:38
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:

Welche Checksumme wird denn vom OTA-Bootloader geprüft?
Du musst natürlich auch die Firmware übertragen, nachdem der Bootloader geflasht wurde.

Hier stehen die Schritte alle beschrieben: https://github.com/pa-pa/AskSinPP/tree/master/bootloader/avr
Oder hier: https://wiki.fhem.de/wiki/Universalsensor#OTA_.28OverTheAir.29_Firmwareupdate

Siehe Bild, wo die Daten im HB-UW-Sen-THPL_update_V0_15_000_150303.hex zu patchen sind.
Hier ist ein Onlinetool zum Checksumme berechen: https://www.fischl.de/hex_checksum_calculator/
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 12 Mai 2020, 10:26:29
Moin,

ich kenn die ganzen Schritte mittlerweile ausreichend genau, denke ich, habe ich ohne Frequnzanpassung auch mehr als einmal gemacht. Ich habe jetzt wie gesagt eine Hex-Datei mit der makeota.html, die auch die Firmware enthält, erzeugt. Die funktioniert auch grundsätzlich, nur die Frequenzeinstellung ist für das verwendete Funkmodul nicht optimal oder halt umgekehrt :)
Also habe ich jetzt die beiden Frequenstrings in der Datei korrigiert (50 durch CA ersetzt), die Checksumme korrigiert und die entstandene Hex-Datei geflasht. Dabei bekomme ich die Ausgabe auf der seriellen Konsole.
Die ganzen Schritte gerade noch mal durchgeführt, beide Hex-Dateien s. Anhang, aber trotzdem bleibt das Ding im Bootloader stecken.
Habe ich irgendein entscheidendes Detail übersehen?
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 12 Mai 2020, 10:39:16
Sorry - keine Zeit mir das im Detail anzusehen.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 12 Mai 2020, 13:41:45
Klar, verstehe ich, Danke für Deine Hilfe bis hierhin.

Vielleicht kann sich das Thema ja noch jemand anders ansehen, beide Dateien sind identisch, bis auf die Zeilen mit der gepatchten Frequenzeinstellung, die Checksummen sind angepasst. Trotzdem weigert sich der Bootloader im 2. Fall die Applikation zu starten (CRC fail).
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: frank am 12 Mai 2020, 14:15:21
hier sollte ja die crc prozedur vom damaliegen bootloader beschrieben sein:
https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/README.md (https://github.com/jabdoa2/Asksin_OTA_Bootloader/blob/master/README.md)
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Horti am 12 Mai 2020, 17:39:10
Ich habe nun doch eine neue Firmware-Datei mit der aktuellen Linux-Version der Arduino-IDE erzeugt (man wächst mit seinen Aufgaben :) ). Und zwar einmal mit der Standard- und einmal mit der geänderten Frequenz. Erwartungsgemäß haben sich die hex-Dateien nur an 2 Stellen unterschieden: Frequenz selber und Zeilen-Prüfsumme
pi@raspberrypi:~/Downloads $ diff -y --suppress-common-lines WetterSensor.cpp.hex WetterSensor.cpp_CA.hex
:10025000063D070C0B060D210E650F5010C81193BB            | :10025000063D070C0B060D210E650FCA10C8119341

Meine ursprüngliche Frage, wo man die Frequenz patchen kann, wäre damit beantwortet. Warum es bei der Ausführung hackt muss ich ggf. woanders weiter analysieren.
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: Dirk P. am 08 Juni 2020, 14:11:38
Für den NanoCul gibt es noch keine Lösung. Du kannst aber auch den FreqTest-Sketch aus der AskSin++ nehmen und ermitteln, wie weit das Funkmodul daneben liegt. Dann müsstest Du die Werte im SourceCode des NanoCul entsprechend anpassen.
Hallo, ich bin am verzeifeln.
Habe auch zwei Module bekommen deren Frequenz zu tief senden und empfangen.
Ich nutze es für meine eQ3 Thermostaten.
Das Modul das funzt liegt nur ewas neben der Frequenz....
Nun habe ich die neuen Werte die ich ausgerechnet habe, in die rf_asksin.c. eingefügt und neu compilliert.
Nichts, keine Frequenzänderung.
Jetzt habe ich in der cc1100.c entdeckt, das dort auch die Standardwerte drin stehen, auch geändert...nichts.
Ich verstehe einfach nicht, das nicht ein Modul (auch das funktionierende) auf eine Änderung reagiert....
Den SelbstbauCul habe ich schon zigmal überprüft und ist nach der Schaltung entstanden > https://wiki.fhem.de/wiki/Selbstbau_CUL
...ich muss aber gestehen das ich aus der ioBroker Gemeinde stamme...
Da hier aber das Thema behandelt wird/wurde, wende ich mich an euch.

Danke
Titel: Antw:Fehlerhafte CC1101 Module
Beitrag von: papa am 16 Juni 2020, 23:35:33
Da man ja praktisch keine ordentlichen CC1101 Module mehr kaufen kann, habe ich mal das Frequenzhandling im Zusammenhang mit dem OTA-Bootloader etwas verbessert. Die neue "makeota.html" Seite erlaubt die Eingabe der ermittelten Frequenz und patched den OTA-Bootloader mit den entsprechenden Werten. Außerdem kann jetzt im Sketch das Define "USE_OTA_BOOTLOADER_FREQUENCY" gesetzt werden. Dann wird im Sketch auch die Einstellung aus dem Bootloader übernommen. Somit braucht die Frequez nur einmal - im Bootloader - gesetzt werden.
Bei der Gelegenheit habe ich die "makeota.html" Seite auch überarbeitet. Die Model-ID kann jetzt auch aus einer Drop-Down-Liste ausgewählt werden. Ich suche noch jemanden, der mal alle Original und Homebrew Geräte dort einträgt und aktuell hält  :D