Fehlerhafte CC1101 Module

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

Vorheriges Thema - Nächstes Thema

Tom Major

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

ThomasS

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

tndx

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.

ThomasS

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

tndx

#289
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.

Tom Major

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

ThomasS

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


tndx

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

thgorjup

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.



FHEM auf Ubuntu 18.04LTS, 2x nanoCUL, JeeLink, nanoPIR, MQTT, ESP-Easy, HUE.
Sensoren+Aktoren: HM, IT, Lacrosse, Multitrade-PIR, VU+, Somfy

PeMue

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
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

thgorjup

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.
FHEM auf Ubuntu 18.04LTS, 2x nanoCUL, JeeLink, nanoPIR, MQTT, ESP-Easy, HUE.
Sensoren+Aktoren: HM, IT, Lacrosse, Multitrade-PIR, VU+, Somfy

thgorjup

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...

FHEM auf Ubuntu 18.04LTS, 2x nanoCUL, JeeLink, nanoPIR, MQTT, ESP-Easy, HUE.
Sensoren+Aktoren: HM, IT, Lacrosse, Multitrade-PIR, VU+, Somfy

Horti

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?

HorstHS

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 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.

DerD!

Hallo zusammen

PSI hat in seinem Beitrag 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
Du darfst diesen Dateianhang nicht ansehen.
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