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
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
Zitat 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.
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.
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.
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?
Zitat 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?
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.
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
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.
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...
Ich bin gespannt auf eure weiteren Erfahrungen...
Übrigens sind die beiliegenden Antennen häufig sehr schlecht.
Gesendet von meinem VTR-L09 mit Tapatalk
Kann ich in meinem Fall ausschließen. Wobei mir bei den beiliegenden Antennen bewusst kein derart gravierender Unterschied aufgefallen ist.
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.
Zitat 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.
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.
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.
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 :'(
ZitatWahrscheinlich hätte ich dort garnicht den CC1101 ersetzen müssen
dann sollte man das bashing der händler eventuell etwas "zurückschrauben". ;)
Zitat von: frank am 06 Oktober 2018, 20:22:56
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.
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.
Ich habe hier auch noch was zu Problemen mit dem CC1101 gefunden.
https://www.mikrocontroller.net/topic/74201#641706
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.
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?
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.
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?
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?
Moin fritzla,
kannst du auch ein Foto von deinem Modul senden, insbesondere Beschriftung des Quarz?
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ß.
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...
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.
Wenn jemand Interesse hat kann er gerne von mir fehlerhafte Module haben. Ich habe meine jetzt durch neue ersetzt.
Zitat 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?
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.
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.
Das kommt auf deine Lötküste an :)
Zitat von: stan23 am 25 Oktober 2018, 09:26:41
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.
3,2mm x 2,5mm
Auslöten relativ gut machbar.
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.
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).
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
Danke!
SDR#.
Im Prinzip die Anleitung von Funkleuchtturm befolgen:
https://homematic-forum.de/forum/viewtopic.php?t=11087&start=24
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.
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.
Zitat von: Horti am 28 Oktober 2018, 09:21:47
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.
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
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
Oder man greift ihn direkt ab ;-)
Anbei das Bild wie oben, aber jetzt mit einem funktionierenden Modul.
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?
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
ZitatThese: 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
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
Ich kenne die Dinger zwar nicht, aber die Symptome sind die gleichen wie von meinen von TENSTAR. Wo hast Du sie denn gekauft?
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
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? ??? :-[
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.
@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.
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
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.
Prima, hab mir in der Bucht so einen Stick bestellt. Sobald der kommt, mach ich mich ans Werk.
@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)
Hallo thgorjup,
ZitatDaraufhin 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.
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.
Zitat 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.
Ich warte ja noch auf den ersten, der so ein Modul zum laufen bekommt.
Zitat von: gloob am 13 Dezember 2018, 17:51:46
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.
Zitat 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.
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?
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....
Wie wäre es denn, wenn wir anstatt fehlerhaften Module, Quellen von funktionierenden Modulen sammeln?
Positive Verlinkungen auf Shops sollten ja erlaubt sein.
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.
Zitat 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.
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.
Hi,
Zitat von: gloob am 15 Dezember 2018, 10:33:30
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.
Ich hab den Link von Aliexpress im ersten Post angehangen. Vielleicht können wir ja dort eine kleine Liste erstellen.
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.
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
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
Hey eine Reparaturanleitung! Super ;-) Was sind die beiden Lastkapazitäten genau? Bilder mit Kringeln möglich?
Gruß Arnd
Gesendet von iPhone mit Tapatalk
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 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
Zitat von: plombe am 15 Dezember 2018, 15:54:02
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.
Zitat 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?
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.
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?
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. :)
Zitat von: kpwg am 16 Dezember 2018, 09:04:20
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.
Zitat 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.
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?
Zitat von: Tom Major am 16 Dezember 2018, 14:29:21
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.
Hallo Zusammen,
ZitatEs 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.
Zitat von: kpwg am 16 Dezember 2018, 15:01:41
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.
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? ::)
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:
Modul | TX Freq. MHZ |
CC1101 neueste Lieferung (i.O.) | 868.21 |
CC1101 ältere Lieferung (i.O.) | 868.26 |
Original eQ-3 TRX | 868.24 |
HM-MOD-UART | 868.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".
Zitat 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:
Modul | TX Freq. MHZ |
CC1101 neueste Lieferung (i.O.) | 868.21 |
CC1101 ältere Lieferung (i.O.) | 868.26 |
Original eQ-3 TRX | 868.24 |
HM-MOD-UART | 868.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?
Zitat von: gloob am 18 Dezember 2018, 07:39:50
Wärst du bitte so nett und würdest noch ein Bild vom Modul zeigen?
Klaro. Ist alles Relevante zu erkennen?
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
Hallo jp112sdl,
ZitatBei 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.
Zitat von: noansi am 18 Dezember 2018, 08:42:28
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
Zitat von: plombe am 17 Dezember 2018, 19:00:32
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
Guten Abend,
Zitat 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:
Modul | TX Freq. MHZ |
CC1101 neueste Lieferung (i.O.) | 868.21 |
CC1101 ältere Lieferung (i.O.) | 868.26 |
Original eQ-3 TRX | 868.24 |
HM-MOD-UART | 868.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.
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.
Zitatauthor=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.
@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?
@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
Ja, für mich ist es auch nur für Homematic wichtig. Danke für deine Antwort.
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
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.
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
};
Zitat 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
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
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?
@ thgorjup
Kannst Du den Wert von 0x75 mal auf 0x5F ändern?
Geht leider auch nicht. :-\
Zitat von: thgorjup am 20 Dezember 2018, 22:46:35
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)
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?
@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
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!
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
@thgorjup
Würde diese Anpassung auch für AskSinPP funktionieren? Bei mir hat die Anpassung in der Radio.h kein Ergebnis geliefert
Zitat 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
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.
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
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.
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
Zitat von: RaspiLED am 22 Dezember 2018, 16:03:39
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 ;)
Zitat 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.
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
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
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)
Zitat 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)
Guck doch mal in den ersten Beitrag. Da habe ich meine Quelle gepostet wo ich zuletzt bestellt habe und keine Probleme hatte.
Zitat von: gloob am 29 Dezember 2018, 18:44:02
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*
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.
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)
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.
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.
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?
ZitatEs 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?
Zitat 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?
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.
Zitat von: Tom Major am 24 Januar 2019, 11:09:38
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.
Im EEPROM ablegen klingt gut, das wäre hilfreich.
ZitatAls 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 :)
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
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
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 ?
Hi,
Zitat 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 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?
Zitat von: tndx am 30 Januar 2019, 18:45:09
Nur für mich zum Verständnis:
1. Dieses Feature ist vollkommen transparent für den Benutzer?
Ja
Zitat von: tndx am 30 Januar 2019, 18:45:09
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.
Zitat von: tndx am 30 Januar 2019, 18:45:09
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.
Zitat von: tndx am 30 Januar 2019, 18:45:09
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.
Zitat von: tndx am 30 Januar 2019, 18:45:09
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.
Zitat von: tndx am 30 Januar 2019, 18:45:09
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.
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) .
Zitat von: Tom Major am 30 Januar 2019, 19:34:23
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.
Hi,
Danke für Deine ausführliche Antwort und natürlich für das neue Feature!
Zitat von: papa am 30 Januar 2019, 19:29:18
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:
Zitat von: papa am 29 Januar 2019, 22:10:20
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!
Zitat von: tndx am 30 Januar 2019, 21:27:31
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
Zitat von: tndx am 30 Januar 2019, 21:27:31
- 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.
Zitat von: tndx am 30 Januar 2019, 21:27:31
- 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.
Zitat von: tndx am 30 Januar 2019, 21:27:31
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.
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.
Zitat von: tndx am 30 Januar 2019, 23:27:21
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.
@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 :(
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.
Hi,
Zitat 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.
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
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.
Zitat 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.
OK, vielen Dank!
Und ? Kannst Du jetzt auch ein OTA-Update einspielen ?
Zitat von: papa am 31 Januar 2019, 11:59:30
Und ? Kannst Du jetzt auch ein OTA-Update einspielen ?
Ja, Erfolg auf der ganzen Linie! ;D
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
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.
Zitat 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 ?
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.
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
Was sagt denn der Test-Sketch ?
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.
HmIP Funk wird nicht erkannt.
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.
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
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.
Zitat 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.
Ok Danke, habs gefunden. Das Saubere verlöten mit Lackdraht ist oft nicht so einfach. Selbst wenn der lötbar sein soll ....
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.
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
Sieht soweit alles gut aus. Hast Du mal ein anderes Modul probiert ?
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.
Ja, habe 3 Module probiert.
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....?
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 ?
Zitat von: papa am 12 März 2019, 11:18:10
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.
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 :-)
Zitat 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 :-)
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.
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
Hallo zusammen,
leider hab ich auch etwaige Probleme weshalb sich mir folgende Fragen ergeben:
- Wie komme ich an die Adressen der Devices ohne FHEM, ich bin RasperryMatic Nutzer
- Da ich eine "CC1101 Testsation" habe bevor ich ihn verbaue teste ich mit einem anderen Pro Mini, wie bekomme ich die ermittelte Frequenz übertragen? Im Sketch definieren wäre eigentlich ganz elegant.
Danke für eure Arbeit!
Zitat von: Psi am 18 März 2019, 23:50:37
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.
Zitat von: Psi am 18 März 2019, 23:50:37
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)
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.
Moin, und das ist im Master und V3 implementiert, oder nur im V3?
Gruß
Jan
Zitat von: Jasimo am 19 März 2019, 13:45:18
Moin, und das ist im Master und V3 implementiert, oder nur im V3?
nur im
Master
okay, danke.
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");
Zitat von: Psi am 20 März 2019, 17:09:59
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.
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.
Zitat 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.
Ach den RESET meinst du :)
Ja, der initialisiert den EEPROM Inhalt neu
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);
}
Zitat von: jp112sdl am 20 März 2019, 17:24:02
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.
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.
Zitat11: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
Das ist das von mir erwartete Verhalten. Hatte noch keine Zeit selbst zu testen. Weitere Einzelheiten im AskSin++ Beitrag.
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".
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
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. :)
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.
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.
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
Zitat von: gloob am 04 Juni 2019, 13:31:23
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 :-)
Zitat von: papa am 04 Juni 2019, 13:36:34
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.
Zitat von: gloob am 04 Juni 2019, 13:38:53
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 :-)
Zitat von: papa am 04 Juni 2019, 16:33:00
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
Zitat 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.
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?
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, ...
Zitat von: RaspiLED am 04 Juni 2019, 19:06:55
€ 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.
Zitat von: gloob am 04 Juni 2019, 19:41:39
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
Zitat von: SabineT am 04 Juni 2019, 20:04:47
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.
Zitat von: gloob am 04 Juni 2019, 20:26:26
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
Hab keinen 1mm Bohrer :)
Ich probiere mal mit Einkleben.
statt aufbohren heiss einpressen.
Zitat von: gloob am 04 Juni 2019, 20:52:30
Hab keinen 1mm Bohrer :)
Ich probiere mal mit Einkleben.
Soll ich dir einen schicken? [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 04 Juni 2019, 21:30:38
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.
Zitat von: SabineT am 04 Juni 2019, 20:04:47
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 ;)
Möchte eigentlich jemand eine Hand voll Stamps mit dem "868MHz"-Aufdruck (ohne Leerzeichen) geschenkt haben ?
Zitat 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 ?
Bevor du sie weg wirfst würde ich mich mal dran versuchen.
Zitat 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 ?
Nehme ich - habe noch Quarze da. Schicke auch gern die Hälfte zurück, wenn sie ordentlich funktionieren.
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:
ZitatAskSin++ 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 :)
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... :-(
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
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.
Danke für die Info. Hatte auch den Eindruck, dass meine im Februar bestellten Module ganz ok sind.
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.
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
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)
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.
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.
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.
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.
Zitat 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.
Da warst du jetzt schneller als ich.
Aber gut, dann ist es halt für alle getesteten Module im Vergleich gleich schlecht.
Zitat von: Tom Major am 16 Oktober 2019, 13:07:45
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?
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..)
Zitat von: jp112sdl am 16 Oktober 2019, 13:18:56
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.. :)
Zitat von: Tom Major am 16 Oktober 2019, 13:22:21
und nur interessehalber um einen Vergleich der Module
Alles klar, das dachte ich mir schon fast. ;) :-X
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?
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 :-(
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 :)
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? ;)
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:
- AskSin Library Version? Brauche ich eine andere?
- Die Module haben keinen sauberen Kontakt?
- Antenne bei meinem Aufbau ist schlecht?
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
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)...
Zitat 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:
...
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
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.
Zitat 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:
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.
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
Hallo tndx,
Zitat von: tndx am 24 Oktober 2019, 22:27:52
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
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
Zitat 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
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
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)
Gibt es eigentlich eine zuverlassige Quelle für ordentliche Module? Bräuchte mal wieder etwas Nachschub.
Diese Module aus der Bucht mit der Bezeichnung CC11010 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 die Helixantenne ausgerollt, um die tatsächliche Drahtlänge zu messen: 27 +/- 0,5 cm
Erkenntnis: die Antenne ist weder für 433 noch für 868 MHz zu gebrauchen.
Vor dem Antennentausch, mitgelieferte Helixantenne, ca. 17 Windungen:
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.
Ich nutze schon immer einen Draht als Antenne da ich damit bislang immer bessere Ergebnisse erzielt habe.
Zitat von: locutus am 08 Januar 2020, 22:03:00
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?
Zitat von: Tom Major am 08 Januar 2020, 23:07:02
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%C3%BCckt.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)).
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 ;)
Hallo Damian,
Zitat von: locutus am 08 Januar 2020, 22:03:00
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.
Zitat von: PeMue am 09 Januar 2020, 07:53:28
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
Zitat von: PeMue am 09 Januar 2020, 07:53:28
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.
Zitat von: Tom Major am 09 Januar 2020, 18:26:15
... 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
Evtl. hilft das:
Ahja und ich hatte mal für KiCAD einen Footprint erstellt:
Zitat von: Eistee am 11 Januar 2020, 10:27:10
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
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.
... die Welt macht irgendwann keinen Spaß mehr ??? ??? ??? ...
Gruß Peter
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.
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.
ZitatDiese 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
Meine persönliche Erfahrung ist, dass ein Steifdraht in passender Länge mit möglichst viel Abstand zur "Elektronik" die Besten RSSI Werte ergab.
ZitatSteifdraht 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 !
Zitat von: Ranseyer am 20 März 2020, 11:29:41
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.
Zitat von: tndx am 23 Oktober 2019, 23:14:02
Guten Abend,
ich habe hier mittlerweile ein 2. Exemplar von einem CC1101, was sich zwar komisch verhält, aber anders komisch, als die bereits bekannten CC1101 mit einer Frequenzverschiebung. Das Funkmodul sendet auf der vorgesehenen Frequenz und wird ohne Probleme von meinem FHEM empfangen, "hört" aber nicht die Antworten. So ist z.B. kein Pairing möglich, senden der Zustände funktioniert dagegen problemlos. Ich habe testhalber den Frequenztest-Sketch laufen lassen:
AskSin++ V4.1.1 (Oct 23 2019 22:53:10)
CC init1
CC Version: 04
- ready
Start searching ...
Freq 0x21656A: 0/0
Freq 0x2165BA: 0/0
Freq 0x21651A: 0/0
Freq 0x21660A: 0/0
Freq 0x2164CA: 0/0
Freq 0x21665A: 0/0
Freq 0x21647A: 0/0
Freq 0x2166AA: 0/0
Freq 0x21642A: 0/0
Freq 0x2166FA: 0/0
Freq 0x2163DA: 0/0
Freq 0x21674A: 0/0
Freq 0x21638A: 0/0
Freq 0x21679A: 0/0
Freq 0x21633A: 0/0
Freq 0x2167EA: 0/0
Freq 0x2162EA: 0/0
Freq 0x21683A: 0/0
Freq 0x21629A: 0/0
Freq 0x21688A: 0/0
Freq 0x21624A: 0/0
Freq 0x2168DA:
Done: 0x21656A - 0x21656A
Could not receive any message 0/0
Done: 0x21656A - 0x21656A
Could not receive any message
Mein FHEM bekam dagegen viele, wenn nicht alle dieser Anfragen mit, ich habe die entsprechenden Ausgaben im Event-Monitor gesehen.
Ich schließe zwar nicht aus, dass irgendwas an meinem Hardware-Aufbau nicht stimmt, aber ich hatte schon mal ein ähnliches Problem mit einem Funkmodul aus der gleichen Lieferung, das habe ich damals nicht weiter verfolgt. Kann sich jemand einen Reim drauf machen?
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.
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)
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.
Zitat von: Horti am 13 April 2020, 18:22:55
Wo ich gerade schon dabei bin: läuft der Frequenztest-Script auch auf einem Atmega 1284P? Ich habe hier ja noch ein HB-Dis-42BW, dessen Funkmodul ich auch im Verdacht habe, nicht auf der richtigen Frequenz zu senden.
ja, das tut er.
Zitat von: Horti am 13 April 2020, 17:03:12
Kann mir jemand bitte sagen, an welcher Stelle ich die Frequenz patchen kann?
Hilfsweise nehme ich auch Hinweise entgegen, an welcher Stelle im Code die Frequenz eingestellt wird. ;) Ich könnte ja dann immerhin versuchen, mit geänderter Frequenz zu compileren, auch wenn ich nicht weiß, ob die aktuellen Toolversionen mit dem Quellcode zurechtkomen ???
Zitat von: Tom Major am 13 April 2020, 18:34:39
ja, das tut er.
Nun, das kann ich zumindest bestätigen. Allerdings muss man den Sketch natürlich für den 1284p neu kompilieren und die Pinbelegung anpassen. Mag zwar für einen erfahrenen Entwickler selbstverständlich sein, mir hat es aber ein paar zusätzliche graue Haare beschert :)
Leider bin ich bei der Ermittlung der Stelle, wo man in der Hex-Datei die Frequenz patchen kann immer noch nicht weiter. Ich weiss zwar mittlerwiele, wo man in der NewAskSin-Lib die Standard-Freqenz verändern kann, aber ich würde dennoch gerne ohne Neukompilieren auskommen :-[
Zitat von: Horti am 24 April 2020, 00:05:36
Leider bin ich bei der Ermittlung der Stelle, wo man in der Hex-Datei die Frequenz patchen kann immer noch nicht weiter. Ich weiss zwar mittlerwiele, wo man in der NewAskSin-Lib die Standard-Freqenz verändern kann, aber ich würde dennoch gerne ohne Neukompilieren auskommen :-[
Wo ist denn genau die Stelle für die Frequenz?
So kommst du zum Ziel:
Standardfrequenz in der sketch source suchen, in hex umrechnen, diese bytes dann im hex file suchen, dabei beachten das der AVR assembler load Befehl ggf. nicht die ganzen 24bit der Freq. auf einmal laden kann. Und am Ende nicht vergessen die checksum der Zeile im hex file auch anzupassen wenn du dort patchst.
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?
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?
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?
Im OTA-Bootloader ist das nicht in einer Zeile sondern geteilt in zwei.
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?
Und wieder ich :)
Ich habe an der seriellen Konsole gelauscht:
AskSin OTA Bootloader V0.7.0
TX bootloader sequence
Wait for CB msg
Timeout
CRC fail, Reboot
Was habe ich gemacht:
Zitat von: Horti am 10 Mai 2020, 22:27:41
Wenn ich mit papas makeota.html eine OTA-Bootloader-Hex erstelle, dann gibt es darin gar keinen "0D210E650F50". Wenn ich die Universalsensor-FW 0.15 dranhänge (immer noch mit papas makeota.html), dann taucht diese Zeichenkette da auf, aber sie stammt dann wohl von der Universalsensor-FW. Ersetze ich 50 durch CA, passe die Checksumme und flashe die Datei, dann funktioniert der Sensor nicht. Er blinkt zwar am Anfang 6 mal oder so, also die Blinksequenz von dem Bootloader, es kommt danach aber nichts Brauchbares. Keine Anlern-Message, keine Helligkeitswerte.
Welche Checksumme wird denn vom OTA-Bootloader geprüft?
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
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.
Zitat 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:
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/
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?
Sorry - keine Zeit mir das im Detail anzusehen.
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).
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)
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.
Zitat 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.
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
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
Zitat von: PeMue am 18 Januar 2020, 21:41:20
... die Welt macht irgendwann keinen Spaß mehr ??? ??? ??? ...
Gruß Peter
Hallo Peter
Funktionieren die denn mit dem kleineren Abstand für die Antennen-Anschlüsse ?
Viele Grüße
Markus
Zitat von: Markus. am 12 Januar 2021, 10:21:31
Funktionieren die denn mit dem kleineren Abstand für die Antennen-Anschlüsse ?
Mit etwas mehr Lötzinn schon, aber es sieht halt
sch... ziemlich unprofesionell aus ...
Gruß Peter
Wieder Module mit falscher Frequenz erwischt. Auf dem Quartz steht: T260 HL75
Nachdem ich bisher auch nur Module erwischt hatte, die ein ziemliches Offset haben (dank Verwendung der neusten Version von TSCUL konnte ich auch unter Homematic eine Anpassung auf +70 machen, womit es jetzt ganz gut funktioniert), habe ich mich nach Modulen umgesehen die deutlich anders aussehen.
Ich hatte mir daher jetzt mal dieses Modul bestellt:
https://www.aliexpress.com/item/32975296156.html?spm=a2g0s.9042311.0.0.27424c4dWCUMTE
(Englische Bezeichnung: CC1101 868MHz Long Range SPI Transceiver rf Module ebyte E07-868MS10 Wireless Transmitter Receiver 868 MHz)
Offensichtliche Unterschiede sind schon mal die andere Farbe und andere Pinbelegung (was es leider schwierig macht das Modul in bestehende Platinenlayouts zu integrieren, daher habe ich zum Testen Kabel dran gelötet und überkreuzt, siehe Foto).
Nach einem ersten Test kann ich zumindest sagen, das das Modul ohne Frequenzanpassung sauber empfängt und selbst mit der kleinen Spiralantenne (die nicht dabei war) ordentliche rssi Werte liefert.
Fazit: Wer eine neue CUL baut oder anderweitig in der Lage ist mit den vertauschten Pins zurecht zu kommen, dem kann ich dieses Modul durchaus empfehlen.
Gruß,
Jörg
Guten Morgen,
Zitat 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
Wie kann mit dieser Datei die low-Battery-Werte für den Fensterdrehgriffsensor definieren? Config String? Mit welcher Syntax?
Guten Abend zusammmen,
ich habe habe Probelem mit meinem Maple Cun diesen habe ich aufgebaut und von anfangan Probleme gebabt mit Homematic Geräte zu Pairen oder zu schalten.
Nun bin ich auf diesen Beitrag gestossen und wollte meine C1101 868Mhz mit dem FreqTest.ino mal testen.
Habe alles Verbunden und geflashed jedoch bekomme ich Fehlermeldungen.
AskSin++ v5.0.0 (Jul 31 2021 23:16:58)
CC init1
Error at 00 expected: 2E read: 07
Error at 02 expected: 06 read: C0
Error at 03 expected: 0D read: 0C
Error at 04 expected: E9 read: 0F
Error at 05 expected: CA read: 03
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: 18
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 60
Error at 11 expected: 93 read: 08
Error at 12 expected: 03 read: 0F
Error at 15 expected: 34 read: 07
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: E0
Error at 19 expected: 16 read: 1F
Error at 1B expected: 43 read: 1F
Error at 1E expected: 2F read: 1F
Error at 1F expected: 65 read: 00
Error at 20 expected: 78 read: 38
Error at 23 expected: E9 read: 1F
Error at 24 expected: 2A read: 1F
Error at 25 expected: 1F read: 03
Error at 26 expected: 11 read: 80
Error at 3E expected: 03 read: 1C
CC Version: 1F
Error at 3E expected: C0 read: 1F
- ready
Start searching ...
Freq 0x21656A 868.300 MHz: Error at 0D expected: 21 read: DB
Error at 0E expected: 65 read: 60
Error at 0F expected: 6A read: 6F
Packet too big: 111
CRC Failed
CRC Failed
Packet too big: 60
CRC Failed
Packet too big: 56
CRC Failed
Packet too big: 60
usw.
Hat jemand vielleicht eine Ahnung an was dies liegt?
Habe die Verdrahtung bereits mehrmals geprüft auch die Einstellungen unter Werkzeugen Board, Prozessor, Port jedoch ohne erfolg.
Danke schon mal im Voraus.
Thomas
Zitat von: ThomasS am 01 August 2021, 00:21:22
Guten Abend zusammmen,
ich habe habe Probelem mit meinem Maple Cun diesen habe ich aufgebaut und von anfangan Probleme gebabt mit Homematic Geräte zu Pairen oder zu schalten.
Nun bin ich auf diesen Beitrag gestossen und wollte meine C1101 868Mhz mit dem FreqTest.ino mal testen.
Habe alles Verbunden und geflashed jedoch bekomme ich Fehlermeldungen.
AskSin++ v5.0.0 (Jul 31 2021 23:16:58)
CC init1
Error at 00 expected: 2E read: 07
Error at 02 expected: 06 read: C0
Error at 03 expected: 0D read: 0C
Error at 04 expected: E9 read: 0F
Error at 05 expected: CA read: 03
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: 18
Error at 0F expected: 6A read: 00
Error at 10 expected: C8 read: 60
Error at 11 expected: 93 read: 08
Error at 12 expected: 03 read: 0F
Error at 15 expected: 34 read: 07
Error at 17 expected: 03 read: 00
Error at 18 expected: 18 read: E0
Error at 19 expected: 16 read: 1F
Error at 1B expected: 43 read: 1F
Error at 1E expected: 2F read: 1F
Error at 1F expected: 65 read: 00
Error at 20 expected: 78 read: 38
Error at 23 expected: E9 read: 1F
Error at 24 expected: 2A read: 1F
Error at 25 expected: 1F read: 03
Error at 26 expected: 11 read: 80
Error at 3E expected: 03 read: 1C
CC Version: 1F
Error at 3E expected: C0 read: 1F
- ready
Start searching ...
Freq 0x21656A 868.300 MHz: Error at 0D expected: 21 read: DB
Error at 0E expected: 65 read: 60
Error at 0F expected: 6A read: 6F
Packet too big: 111
CRC Failed
CRC Failed
Packet too big: 60
CRC Failed
Packet too big: 56
CRC Failed
Packet too big: 60
usw.
Hat jemand vielleicht eine Ahnung an was dies liegt?
Habe die Verdrahtung bereits mehrmals geprüft auch die Einstellungen unter Werkzeugen Board, Prozessor, Port jedoch ohne erfolg.
Danke schon mal im Voraus.
Thomas
du schreibst zwar Verdrahtung mehrfach geprüft, aber die Meldungen
Error at .. expected ..
sind typisch wenn der CC1101 nicht gefunden wird weil nicht korrekt angeschlossen (oder gar defekt ist).
Außerdem müssen die SPI Pin defines im FreqTest natürlich genau zur HW passen, ggf. das noch mal prüfen.
Hallo Tom Major,
ich habe heute parallel nochmals alles geprüft und hatte eine falsche Pinbelegung im www erwischt das hatte ich gestern natürlich nicht geprüft ( SI < -- > SO).
Nachdem ich dies umgesteckt hatte konnte ich den CC1101 ansprechen.
ACTIVE_PING aktiviert und die HMID's eingetragen.
AskSin++ v5.0.0 (Aug 1 2021 18:54:17)
CC init1
CC Version: 14
- ready
Start searching ...
Freq 0x21656A 868.300 MHz: A2F3C3. 1 / -82dBm
Search for upper bound
Freq 0x21657A 868.306 MHz: A2F3C3. 1 / -81dBm
Freq 0x21658A 868.313 MHz: A2F3C3. 1 / -81dBm
Freq 0x21659A 868.319 MHz: A2F3C3. 1 / -82dBm
Freq 0x2165AA 868.325 MHz: A2F3C3. 1 / -82dBm
Freq 0x2165BA 868.332 MHz: 67876A. 1 / -96dBm
Freq 0x2165CA 868.338 MHz: A2F3C3. 1 / -82dBm
Freq 0x2165DA 868.344 MHz: A2F3C3. 1 / -81dBm
Freq 0x2165EA 868.351 MHz: 67876A. 1 / -95dBm
Freq 0x2165FA 868.357 MHz: A2F3C3. 1 / -84dBm
Freq 0x21660A 868.363 MHz: A2F3C3. 1 / -84dBm
Freq 0x21661A 868.370 MHz: 0
Search for lower bound
Freq 0x21655A 868.294 MHz: A2F3C3. 1 / -82dBm
Freq 0x21654A 868.287 MHz: A2F3C3. 1 / -83dBm
Freq 0x21653A 868.281 MHz: 0
Done: 0x21654A - 0x21660A
Calculated Freq: 0x2165AA 868.325 MHz
Store into config area: 65AA...stored!
Nun habe ich wie beschrieben im FreqTest.ino abgeändert das die ermittelte Frequenz geschrieben wird.
void setup () {
#if defined ARDUINO_ARCH_STM32F1
delay(5000);
#endif
DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
sdev.init(hal);
// eingefuegt 20210801
// Set frequency for CC1101
hal.radio.initReg(CC1101_FREQ2, 0x21);
hal.radio.initReg(CC1101_FREQ1, 0x65);
hal.radio.initReg(CC1101_FREQ0, 0xAA);
// start sender
info.trigger(sysclock);
}
Jedoch wenn ich den CC1101 erneut auslese sehe ich nicht die gesetzte Frequenz 0x2165AA.
Ist das so korrekt?
Gruß und Danke
Thomas
Moin,
der Frequenztest-Sketch trägt die ermittelte Frequenz ins EEPROM ein, die AskSinPP-Anwendung (die bei der Kompilierung verwendete Lib-Version darf nicht zu alt sein) schaut da nach und übernimmt den Wert bei der Initialisierung, soweit vorhanden. Nur wenn keine alternative Frequenz im EEPROM gefunden wird, wird die Stadardeinstellung verwendet. U.U. überschreibt die Stadardeinstellung dann deine Einstellung im Sketch.
Am einfachsten ist es also, sich keine Gedanken um die Frequenzverschiebung im Sketch zu machen, sondern den Frequeztest auf der Zielhardware laufen zu lassen, bevor der eigentliche Sketch aufgespielt wird.
Hallo,
Ich habe nun versucht ein mit den Sketch (FreqTest.ino) korrigierten CC1101 mit den Maple zu benutzen jedoch kann ich keinen Unterschied zu einem "original" CC1101 feststellen.
Ich habe zwei Heligkeitssensoren einer wird von Bestandsystem ausgewertet und der andere von Testsystem, beide Sensoren sind nebeneinander aufgestellt.
Beim Bestandsystem bekomme ich alle 3 Minuten ein Messwert der vom Testsystem zwischen 3Minuten bis mehrere Stunden daran hat sich nichts geändert die Frequenz scheind zu passen jedoch die Signalbreite ist sehr unterschiedlich.
Ich habe mit einem SDR-RTL das Signal versucht zu analysieren und einen Screenshot gemacht.
Im Bild kann man erkennen das das Signal des Testsystems sehr breit ist und dies ist vermutlich auch das Problem beim senden und empfangen.
Hat hier schon jemand Erfahrung an was dies liegen könnte?
Danke
Thomas
Ist das so korrekt?
Gruß und Danke
Thomas
Hi,
vielleicht habe ich ja Tomaten auf den Augen, aber ich steige gerade nicht durch.
Was ist dein Testsystem und dein Bestandsystem? Warum wertest Du mit beiden unterschiedliche Sensoren aus, einer würde ja auch ausreichen? Ist das breite Signal die Antwort des Testsystems auf eine Nachricht eines der beiden Sensoren?
Nutzt das Testsystem dein Maple-CUx als IO-Device? Nutzt dein Maple-CUx ein "fehlerhaftes" CC1101, von dem Du zwar die "gute" Frequenz kennst, aber die CUx-Firmware wahrscheinlich von sich aus keine Einstellung zum Ändern der Frequenz mitbringt?
P.S.: die Signalbreite ist schon sehr ungewöhnlich
P.P.S.: die CUx-Fraktion gilt mittlerweile als eine schlechte Wahl für Homematic, beim Maple kannst du theoretisch ein HM-MOD-RPI-PCB seriell anbinden.
Nur um noch mal das FreqTest Thema aufzugreifen und in Ergänzung zu tndx's Beitrag, wenn die ermittelte Freq aus dem EE erfolgreich im Sketch verwendet wird kommt eine Ausgabe im seriellen Log so etwa wie im verlinkten Bild die erste Zeile
"Config Freq: 0x.."
https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor-Blitz#serieller-log (https://github.com/TomMajor/SmartHome/tree/master/HB-UNI-Sensor-Blitz#serieller-log)
Hallo Tndx,
ich habe 2017 mich mit Hausautomatisierung beschäftigt, ich ein möglichst offenes System haben um nicht auf nur einen Hersteller beschränkt zu sein.
Aus diesem Grund habe ich mich in Fhem eingelesen und mein Hausautomatisierung begonnen.
Da ich immer noch Einsteiger bin obwohl ich schon einiges umgesetzt habe will ich nicht zuviel auf meinem laufenden System probieren daher habe ich mir ein zweites Systen installiert.
Bestandsystem: Raspberry --> Fhem installation --> CunX (Bu..re) --> diverse Homematic Sensoren und Aktoren plus diverse 433Mhz Sensoren und Aktoren).
Testsystem: Raspberry --> Fhem installation --> Maple Cun (CC1101 mit 868Mhz und CC1101 mit 433Mhz) --> 2 Homematic Sensoren, 2 Rolladenaktoren und Intertechno Schaltsteckdosen.
Bei meinen Bestandsystem setze ich den CunX von Bu...re im 868Mhz Band ausschliesslich für Homematic ein und habe hierzu auch keine schlechten Erfahrung nur das eben der Sende und Empfangsbereich nicht ausreicht soll heissen die am weitesten entfernten Rolladenaktoren erreiche ich an 280 Tagen im Jahr immer jedoch an 30-40 Tagen überhaupt nicht und die restlichen Tage so lala.
Wenn ich dann den CunX umpositionieren erreiche ich wiederum ander Geräte nicht daher wollte ich auf 2 CunX erweitern jedoch ist der CunX nicht mehr lieferbar und alle Fragen welches diesen ersetzt wurden konsiquent vom Hersteller ignoriert.
Daher habe ich eine Alternative gesucht und bin bei Maple Cun hängengeblieben um eventuell noch Erweiterungsmöglichkeiten für die zukunft zu haben.
Maple Cun auf meinem Testsystem eingerichtet zwei C1101 jeweils mit 433 und 868Mhz.
Nun habe ich aber von Anfang an Probleme mit der Reichweite D.h. fast zu 95% fährt der Aktor die Position an jedoch für es zu einem ACK ausser Sender und Empfänger sind Nahe zusammen <10m dann läuft alles ohne Probleme.
Dieses Verhalten kenne ich von meinem Bestandssysten überhaupt nicht.
Ich bin mir nichteinmal sicher ob es an den C1101 liegt jedoch habe ich von verschiedenen Händlern gekauft und alle verhalten sich gleich.
Wenn uch den CunX im Testsystem temporär einrichte funktioniert die Kommunikation anso sollte nach ausschlußverfahren es am Maple Cun liegen jedoch bin ich ja nicht der einzigste der diesen einsetzt und dann bleibt eigentlich nur noch das CC1101 Modul übrig.
Auch nachdem ich versucht habe die Frequenz zu korrigieren scheind es keine Veränderung zu geben zumindest ist die Sendefequenz immer noch zu niedrig.
Ich habe nun beide Sender (CunX und Maple Cun) an die gleiche Position gestellt um den gleichen Abstand zum SDR zu haben und jetzt ist zumindest das Signal nicht mehr so breit war der Maple Cun wohl zu nahe an der SDR Antenne.
In Anhang nun 2 Bilder jeweils von den zwei Systemen und beim Maple Cun scheind die Rückmeldung nicht anzukommen wenn ich das richtig interpretiere.
Mir fehlt hier wirklich der Backround denn es schein mir das ich vielleicht an der falschen Stelle sucht oder nicht weis wie ich es korrigiert bekomme.
Gruß
Thomas
Hi,
danke für die ausführliche Beschreibung!
Damit ist dein Problem zwar zum Teil OT hier, aber für mich sieht es auch so aus, als würde es an einem fehlerhaften CC1101 liegen.
Das Problem ist ja für AskSin so gelöst, dass mit dem Frequenztest die Frequenzeinstellung gesucht wird, die der HM-Frequenz (868,3 MHz) am nächsten kommt. Diese Frequenzeinstellung wird dann dauerhaft für den Funkverkehr benutzt, die eigentliche Applikation weiss aber nichts davon, sie denkt, sie würde immer noch mit der Standard-Frequenz kommunizieren.
Ein CUx und auch ein Maple-CUx ist da anders gestrickt. Er ist ja darauf ausgelegt, dass man Frequenzen / Bandbreiten / Sendestärken konfigurieren kann. Aus diesem Grund reicht das wahrscheinlich nicht aus, die mit dem Frequenztest ermittelte Frequenz bei der Initialisierung anzugeben, denn die wird im weiteren Verlauf wieder überschrieben. Am konsequentesten wäre es, eine Frequenzdifferenz Ist-Soll zu berechnen und diese überall zum Sollwert zu addieren. Im Idealfall wäre sie halt 0. Aber das muss die Firmware unterstützen, oder Du musst das im Source Code überall nachpflegen.
Eine Möglichkeit, die mir noch einfällt, und sei es nur zum Testen, dass du nachträglich die über Frequenztest ermittelte Frequenz (set CUL freq 868.XYZ) einstelltst und damit testest? Ich weiss nur nicht, ob das bei "rfmode - HomeMatic" überhaupt möglich ist, oder ob dann fix die 868,3 eingestellt ist.
Wie bereits vorher gesagt, du gehst den Problemen eleganter aus dem Weg, indem du bei deinem Maple ein HM-MOD-RPI-PCB seriell anbindest (wenn das deine Leiterplatte unterstützt). Ansonsten gibt es die CC1101-Module in einer anderen Ausführung, die zwar teurer sind, dafür aber bis jetzt noch nicht "in fehlerhaft" aufgetaucht sind. Es gibt auch Adapter-Platinen, um diese auf die Leiterplatten mit dem "Standard"- CC1101 Footprint zu platzieren:
https://github.com/TomMajor/SmartHome/tree/master/PCB/GB_CC1101_Adapter (https://github.com/TomMajor/SmartHome/tree/master/PCB/GB_CC1101_Adapter)
Hallo, ich wollte nach langer Zeit mich mal wieder mit dem FreqTest beschäftigen, da es bislang bei mir nicht funktioniert hatte.
Ich nutze einen Arduino Nano V3 und die SPI Pinbelegung ist ja dieselbe wie von dem Pro Mini.
#if defined ARDUINO_ARCH_STM32F1
// we use a BluePill
#define CC1101_GDO0_PIN PB0
#define CC1101_CS_PIN PA4
// CC1101 communication uses HW-SPI
#define LED_PIN LED_BUILTIN
#else
// we use a Pro Mini
#define CC1101_GDO0_PIN 2 // PD2
#define CC1101_CS_PIN 10 // PB2
#define CC1101_MOSI_PIN 11 // PB3
#define CC1101_MISO_PIN 12 // PB4
#define CC1101_SCK_PIN 13 // PB5
// Pro Mini LED
#define LED_PIN 4 // PD4
#endif
Trotzdem bekomme ich lediglich diese Ausgabe:
AskSin++ v5.0.0 (Sep 20 2021 15:28:36)
CC init1
CC Version: 14
- ready
Active ping is enabled, looking for telegrams only from F10000!
Start searching ...
Freq 0x21656A 868.300 MHz: 0
Freq 0x2165BA 868.332 MHz: 0
Freq 0x21651A 868.268 MHz: 0
Freq 0x21660A 868.363 MHz: 0
Freq 0x2164CA 868.236 MHz: 0
Freq 0x21665A 868.395 MHz: 0
Freq 0x21647A 868.205 MHz: 0
Freq 0x2166AA 868.427 MHz: 0
Freq 0x21642A 868.173 MHz: 0
Freq 0x2166FA 868.459 MHz: 0
Freq 0x2163DA 868.141 MHz: 0
Freq 0x21674A 868.490 MHz: 0
Freq 0x21638A 868.109 MHz: 0
Freq 0x21679A 868.522 MHz: 0
Freq 0x21633A 868.078 MHz: 0
Freq 0x2167EA 868.554 MHz: 0
Freq 0x2162EA 868.046 MHz: 0
Freq 0x21683A 868.586 MHz: 0
Freq 0x21629A 868.014 MHz: 0
Freq 0x21688A 868.617 MHz: 0
Freq 0x21624A 867.982 MHz: 0
Freq 0x2168DA 868.649 MHz:
Done: 0x21656A - 0x21656A
Could not receive any message 0
Done: 0x21656A - 0x21656A
Could not receive any message
Was mache ich falsch? Die PING Parameter habe ich meiner HM-Steckdose und der VCC hmid in FHEM angepasst.
Zitat von: thgorjup am 20 September 2021, 15:48:25
Was mache ich falsch? Die PING Parameter habe ich meiner HM-Steckdose und der VCC hmid in FHEM angepasst.
Miss mal die SPI Verbindungen durch, es scheint, dass kein Frequenzwert zurückgelesen wird.
Gruß Peter
Danke, aber da ist alles in Ordnung. Ich habe bereits die culfw mit Anpassung 0x2165A2 draufgespielt und ich kann meine Geräte steuern.
Also funktioniert der nanoCUL ansich einwandfrei. Aber der sketch findet leider nichts. Auch nicht, wenn ich die PING Parameter raus lasse.
Hab ich vielleicht falsche Bibliotheken verwendet? Habe die aktuelle AskSin++ 5.0 Library installiert.
Problem gefunden. Beim nanoCUL musst, warum auch immer, der GD00 auf Pin 3 gemapped werden.
#define CC1101_GDO0_PIN 3
Jetzt klappt es:
AskSin++ v5.0.0 (Sep 20 2021 17:53:12)
CC init1
CC Version: 14
- ready
Active ping is enabled, looking for telegrams only from F10000!
Start searching ...
Freq 0x21656A 868.300 MHz: 0
Freq 0x2165BA 868.332 MHz: F10000. 1 / -97dBm
Search for upper bound
Freq 0x2165CA 868.338 MHz: F10000. 1 / -98dBm
Freq 0x2165DA 868.344 MHz: F10000. 1 / -97dBm
Freq 0x2165EA 868.351 MHz: 67221C.67221C.F10000. 1 / -97dBm
Freq 0x2165FA 868.357 MHz: F10000. 1 / -97dBm
Freq 0x21660A 868.363 MHz: F10000. 1 / -97dBm
Freq 0x21661A 868.370 MHz: F10000. 1 / -95dBm
Freq 0x21662A 868.376 MHz: F10000. 1 / -97dBm
Freq 0x21663A 868.382 MHz: F10000. 1 / -96dBm
Freq 0x21664A 868.389 MHz: F10000. 1 / -99dBm
Freq 0x21665A 868.395 MHz: 0
Search for lower bound
Freq 0x2165AA 868.325 MHz: F10000. 1 / -97dBm
Freq 0x21659A 868.319 MHz: F10000. 1 / -97dBm
Freq 0x21658A 868.313 MHz: F10000. 1 / -98dBm
Freq 0x21657A 868.306 MHz: 0
Done: 0x21658A - 0x21664A
Calculated Freq: 0x2165EA 868.351 MHz
Store into config area: 65EA...stored!
Old Config Freq was: 0x2165EA 868.351 MHzGoing to sleep...
Gibt es eigentlich mittlerweile irgendeine Möglichkeit, bei der CUL-/A-CUL-FW einen Offset zu definieren, um die Frequenzverschiebung zu kompensieren? Ansonsten kann man doch die "fehlerhaften"-CC1101-Module gar nicht mehr fur einen NanoCUL nutzen, oder?
Mir ist aufgefallen, dass im Seriellen Monitor meist "CC Version: 14", bei einigen meiner Funkmodule aber "CC Version: 04" geliefert wird. Und bin dazu unter https://jgromes.github.io/RadioLib/class_c_c1101.html (https://jgromes.github.io/RadioLib/class_c_c1101.html) fündig geworden: ... CC1101_VERSION_LEGACY (0x04) or CC1101_VERSION_CURRENT (0x14) if CC1101 is connected and working.... Den genauen Unterschied kenne ich aber noch nicht.
Hallo zusammen
PSI hat in seinem Beitrag (https://forum.fhem.de/index.php?msg=872505) die Kondensatoren C81 & C101 auf dem Bild markiert.
Eine Frage in die Runde: es hat nicht zufällig jemand bereits die restlichen Komponenten bereits wie PSI anhand der Schaltung
CC1101 Circut.png
auf der Platine markiert und kann diese zur Verfügung stellen?
Ich habe hier einige defekte CC1101 rumliegen und würde die Komponenten gerne verwerten.
Vielen Dank schon mal