Fehlerhafte CC1101 Module

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

Vorheriges Thema - Nächstes Thema

jp112sdl

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

Ranseyer

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)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

Tom Major

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

jp112sdl

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.

Tom Major

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

gloob

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.
Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

jp112sdl

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?

Tom Major

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

Tom Major

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

jp112sdl

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

tndx

#220
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?

papa

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

tndx

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 :)

tndx

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?  ;)

PeMue

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