Probleme mit HM-LC-Sw1-Pl-DN, stochastische längere Kommunikationsausfälle

[Matsch]

Das werde ich demnächst auch mal mit den Steckdosen testen.

[marvin424]

Hallo zusammen,

hatte das gleiche Problem, bin aber leider erst gestern auf diesen Thread gestoßen.
Weil ich immer davon ausgegangen war, dass es sich um Empfangsprobleme handelt, auch wenn das aufgrund der relativ geringen Entfernung nicht sein konnte, habe ich es erst mit Feintuning der Antenne und Frequenz des CC1101 versucht. Erfolglos.
Dann habe ich mir den Repeater HM-Sys-sRP-Pl gebaut und installiert und siehe da, die Probleme waren weg.
Das überraschende, was mich letztendlich dazu bewegt hat nochmal hier Forum nach "Leidensgenossen" zu suchen: Es ist völlig unerheblich, wo der Repeater steht. Es funktionierte auch, wenn der Repeater deutlich weiter weg ist, als die CCU3.

Vielleicht hilft es euch ja den Fehler weiter einzugrenzen bzw. den aktuellen Fix von Horbi zu bestätigen.

Ich versuche es jetzt noch einmal mit dem Fix von Horbi ohne Repeater.
UPDATE: funktioniert seit Tagen ohne Probleme.

Vielen Dank an alle
Gruß, Michael...

[Horbi]

Irgendwie wird das Thema zum Dauerbrenner bei mir.
Bei einem meiner Geräte traten trotz RadioWatchdog und Auslesen des Buffers von Zeit zu Zeit Empfangs Schwierigkeiten auf.
Diese haben sich auch regelmäßig durch Senden einer Nachricht beseitigen lassen.

Zur Analyse des Problems habe ich mir einen Seriellen Debug Mechanismus gebaut, über den ich Nachrichten versenden kann und die Statusregister des CC1101 auslesen kann. Dabei ist mir aufgefallen das sich der CC1101 zwar in MARCSTATE_RX befindet, aber keine Daten empfängt.
Über das Statusregister gab es auch keine Auffälligkeiten, weder in CC1101_MARCSTATE, noch über CC1101_PKTSTATUS, einzig CC1101_VCO_VC_DAC geht auf 0xff. Im Normalfall, also Betriebsmodus, ist der Wert so um 0xCC.

Wenn gesendet wird, also durch den Wechsel von RX nach TX und zurück nach RX, wird neu kalibriert, der Wert geht zurück auf 0xcc und der CC1101 empfängt wieder. Den selben Effekt hat auch ein manuelles Kalibrieren über CC1101_SCAL.

Über den Radiowatchdog lässt sich das CC1101_VCO_VC_DAC Flag recht einfach monitoren und auch das Kalibrieren starten, insofern ist der Empfänger für max. 500ms taub, was akzeptabel ist. Schöner wäre natürlich wenn wir die Ursache herausfinden und beseitigen könnten.

Was ich bisher rausgefunden habe - der CC1101_VCO_VC_DAC verändert sich recht wenig über Stunden und steigt schlagartig an, wenn der CC1101 aufhört zu empfangen.

[jp112sdl]

Hattest du mal in den CC1101 Errata Notes geschaut ob sich da was finden lässt, was das Problem erklären könnte?
https://datasheet.octopart.com/CC1101RT ... 151390.pdf

[Horbi]

Ja, hatte ich vor geraumer Zeit schon geschaut, damals hatte ich den Verdacht der Paketlänge, aber das hatte sich ja nicht bestätigt...
Was mich irritiert ist, dass das Problem offensichtlich nur bei einigen Geräten auftritt. Entweder vergessen wir was zu initialisieren oder das Problem wird durch Bauteilvarianzen begünstigt.

[HMSteve]

Unter https://e2e.ti.com/support/wireless-con ... alibration schreibt ein TI-Mensch in etwas anderem Kontext " For a constant environment (temp, voltage etc) it should be sufficient with one calibration and not having to do a calibration again but for practical applications we always advice to calibrate at given time intervals since it's not possible to know all the reasons if/ why the PLL could go out of lock."

Meine Versuche oben zeigten, dass das Problem der Nichterreichbarkeit in S26-Umbauten auftritt, nicht aber auf batterieversorgter selbst gebauter Testhardware und nicht mit Original-EQ3-Steckdosen. Weiter oben wurde im S26-Kontext schon mal mit anderem Netzteil und zusaetzlichen Cs probiert, Vcc-Glitches auszuschliessen. Die Aenderungen brachten keinen Erfolg.

Mein Versuch, irgendwas mit selbst gebauter Schnueffelsonde und SDR statt Spectrum Analyser zu sehen, waren erwartungsgemaess erfolglos (konnte aber die 26MHz sehen ).

Vielleicht kann man ja bei laengerer Beobachtung mit viel Geduld das Wegspringen des Registerwertes mir irgend einem Umweltereignis (Grossverbraucher geschaltet, Zeitintervall/Zeitpunkt, was auch immer) korrelieren?

[Horbi]

Vielen Dank - habe dort noch ein weiteres Thema gefunden:

Our testing show that if you calibrate at a certain temperature the PLL will stay in lock if the temperature changes by less than +/-40C.

Since the VCO uses an internal voltage regulator, the frequency drift over supply voltage is negligible, at least above ca. 1.9 V unregulated supply voltage. The charge pump runs on un-regulated voltage and the charge pump current might change the PLL BW with significant changes in supply voltage resulting in a non-optimum PLL BW (i.e the phase margin might get low). We have not measured the maximum drop, so to play it safe I would say the maximum drop as 1.0 V.

I have also come across a case where the CC1101 was calibrated and the PLL in lock. However, when strobing CSn there was a coupling of the CSn signal to the crystal oscillator resulting in the PLL going out of lock for a certain period of time (don't have details on timing - sorry). Simple test is to cut the CSn trace at both ends and running a jumper wire to check if the problem goes away completely.

Wobei wir das CS nicht wirklich stark nutzen...

Ich habe mal ein Update auf den dev-trilu Zweig geschoben, falls jemand mit testen will.
#define RADIOWATCHDOG im Sketch nicht vergessen.

Edit: Proof of concept

Code: Alles auswählen

ignore 0F 36 86 10 46BDAE 000000 0A 24 D7 09 00 40  - 18168349


calibration forced... - 18168569

ignore 0F BC 86 10 38EDCF 000000 0A 88 DF 0E 00 40  - 18169667

[papa]

Spannend ...

[HMSteve]

Ich habe mal ein Update auf den dev-trilu Zweig geschoben, falls jemand mit testen will.
#define RADIOWATCHDOG im Sketch nicht vergessen.

Edit: Proof of concept

Code: Alles auswählen

ignore 0F 36 86 10 46BDAE 000000 0A 24 D7 09 00 40  - 18168349


calibration forced... - 18168569

ignore 0F BC 86 10 38EDCF 000000 0A 88 DF 0E 00 40  - 18169667

Lasse das jetzt auf meinem Testboard mal ueber Nacht laufen, bisher leider ohne "Treffer". Unter welchen Bedingungen erfolgte Dein proof of concept genau?

[Horbi]

Ich nutze zur Zeit zum Testen einen AskSinDuino32 der an einem umgebauten LED Treiber/Step Down Regler angeschlossen ist.
Die Kombo wird von einem 12V/20W Schaltnetzteil gespeist.
Das ist der Aufbau für eine umgerüstete Wandlampe die Mehrfach bei mir im Treppenhaus hängt.

Als Sketch läuft HM-LC-DW-WM von hier: https://github.com/trilu2000/HM-LC-DW-WM-stm32l1xx
Der Sketch ist mit einem seriellen Inputparser erweitert, d.h. ich kann über die serielle Konsole die Statusregister vom CC1101 auslesen oder eben auch einen HEX-String direkt ins Funkmodul zum Versenden schicken.

Interessant ist, dass ich den Fehler nur reproduzieren kann, wenn der AskSinDuino32 über ein 230V Netzteil betrieben wird.
Bei Batteriebetrieb tritt das Problem nicht auf, zumindest konnte ich es nicht nachweisen.