CC1101 - Reichweite oder verschluckte Pakete

Deutsche Foren Hardware
#1

Hallo,

ich kämpfe schon seit Wochen oder gar Monaten mit einem Problem, dessen Ursache ich bislang nicht gezielt eingrenzen konnte. Ich benutze einen CC1101 mit einem Raspberry Pi 2, was grundsätzlich sehr stabil läuft. Ich habe inzwischen und 40 Homematic-Devices und mit zunehmender Anzahl tauchte das Problem auf, dass beispielsweise die Kontaktsensoren ihr Signal nicht übertragen können.

Erkenntnisse bzw. Detail:

  • Laut Log von Homegear werden in dieser Situation angeblich keine BidCoS-Pakete empfangen
  • Retries auf 10 brachte keine Verbesserung
  • es konnten keine echten Überlagerungen zwischen Sensoren erkannt werden
  • ich habe den Eindruck, dass ein Homegear-Restart die Situation jedes Mal zunächst verbessert
  • Tausch der Batterien brachte keine Verbesserung (Voltmeter-Messung sagt ok)
  • wenn die Signale dann doch mal ankommen, dass ist der RSSI-Wert eigentlich auch ok (0x6*)
  • die Sensoren sind teilweise nur wenige Meter (<10) entfernt
  • verschiedene Antennen am CC1101 probiert

Ich habe fast die Vermutung, dass eventuell bei der Kommunikation mit dem CC1101 die Pakete verloren gehen. Irgendwelche Ideen, wie man dem Problem auf die Spur kommen könnte?

#2

Was ich noch erwähnen wollte: mit dem CFG-LAN läuft alles - ja geschmeidig, allerdings läuft die Komponente nicht mit über die Batterie, sodass bei Stromausfall gar nix mehr geht.
Verschiedene CC1101 hab ich auch schon probiert

#3

Hallo,

hört sich tatsächlich so an. Schick mir doch einmal ein Log, in dem das Problem auftritt, vielleicht kann ich dann mehr dazu sagen.

Liebe Grüße

Sathya

#4

welches debuglevel benötigst du?

#5

4 reicht erst einmal.

#6

Sorry für die späte Antwort, hier mal das Log des Öffnens und Schließens eines Kontaktes. Der Sensor hat die ID 20, ist also auch in dem geloggten RPC-Call Bestandteil.

Homegear version 0.6.0:

06/08/15 19:55:31.866 HomeMatic BidCoS packet received (SPI, RSSI: 0x63): 0CF6A2412A2112FD21B501F5C8 06/08/15 19:55:31.868 Info: Calling RPC method "system.multicall" on server 192.168.0.199. 06/08/15 19:55:31.869 Module HomeMatic BidCoS: Info: LOWBAT on channel 1 of HomeMatic BidCoS peer 20 with serial number LEQ0239359 was set to 0x00. 06/08/15 19:55:31.869 Info: Connecting to host 192.168.0.199 on port 4000... 06/08/15 19:55:31.869 Module HomeMatic BidCoS: Info: STATE on channel 1 of HomeMatic BidCoS peer 20 with serial number LEQ0239359 was set to 0xC8. 06/08/15 19:55:31.871 Info: Connected to host 192.168.0.199 on port 4000. Client number is: 27016 06/08/15 19:55:31.966 Module HomeMatic BidCoS: TI CC110X "SPI": Info: Sending (SPI): 0AF68002FD21B52A211200 Planned sending time: 06/08/15 19:55:31.966 06/08/15 19:55:31.967 Info: Calling RPC method "system.multicall" on server 192.168.0.199. 06/08/15 19:55:31.967 Info (SPI): Packet processing took 101 ms. 06/08/15 19:55:31.969 Info: Connecting to host 192.168.0.199 on port 4000... 06/08/15 19:55:31.970 Info: Connected to host 192.168.0.199 on port 4000. Client number is: 27017 06/08/15 19:55:32.004 RPC Server (Port 2001): Info: Connection from 192.168.0.199:47161 accepted. Client number: 27018 06/08/15 19:55:32.009 RPC Server (Port 2001): Info: Client number 27018 is calling RPC method: getValue Parameters: (Integer) 20 (Integer) 1 (String) STATE 06/08/15 19:55:32.045 RPC Server (Port 2001): Info: Client number 27018 is calling RPC method: getValue Parameters: (Integer) 18 (Integer) 1 (String) STATE 06/08/15 19:55:34.975 HomeMatic BidCoS packet received (SPI, RSSI: 0x5F): 0C37847035B68E00000000F033 06/08/15 19:55:34.977 Info: Calling RPC method "system.multicall" on server 192.168.0.199. 06/08/15 19:55:34.978 Module HomeMatic BidCoS: Info: HUMIDITY on channel 1 of HomeMatic BidCoS peer 33 with serial number LEQ1482575 was set to 0x33. 06/08/15 19:55:34.978 Info: Connecting to host 192.168.0.199 on port 4000... 06/08/15 19:55:34.978 Module HomeMatic BidCoS: Info: TEMPERATURE on channel 1 of HomeMatic BidCoS peer 33 with serial number LEQ1482575 was set to 0x00F0. 06/08/15 19:55:34.980 Info: Connected to host 192.168.0.199 on port 4000. Client number is: 27019 06/08/15 19:55:34.980 Info (SPI): Packet processing took 4 ms. 06/08/15 19:55:34.992 Info: Calling RPC method "system.multicall" on server 192.168.0.199. 06/08/15 19:55:34.994 Info: Connecting to host 192.168.0.199 on port 4000... 06/08/15 19:55:34.996 Info: Connected to host 192.168.0.199 on port 4000. Client number is: 27020 06/08/15 19:55:42.057 RPC Server (Port 2001): Info: Connection to client number 27018 closed (3). 06/08/15 19:55:45.139 Info: Connecting to host phue on port 80... 06/08/15 19:55:45.311 Info: Connected to host phue on port 80. Client number is: 27021 06/08/15 19:55:46.038 Info (phue): Packet processing took 0 ms. 06/08/15 19:55:46.041 Info (phue): Packet processing took 2 ms. 06/08/15 19:55:46.041 Info (phue): Packet processing took 0 ms.

Der Sensor wurde geöffnet und binnen 1-2 Sekunden geschlossen, Wie man sieht, wurde das Schließen nicht übertragen - der Sensor zeigte lange gelb und irgendwann rot. In Homegear ist er noch als offen vermerkt.

Treten eventuell Locks durch die RPC-Calls auf? Ich habe die Anwendung, welche per RPC kommuniziert, anschließend beendet. Danach funktioniert der Sensor wieder normal - bzw. die Übertragung. Davor zeigte sich das übliche Spiel: Von Stunde zu Stunde wurde die Übertragung unzuverlässiger, sodass ich das Gefühl habe, dass irgendwelche Leichen zurückbleiben.

#7

Hallo,

Wirklich merkwürdig… Nein, durch die RPC-Aufrufe wird nichts blockiert. Damit nichts blockiert wird, laufen diese extra in einem seperaten Thread. Deswegen ist es wirklich merkwürdig, dass die Übertragung von Stunde zu Stunde unzuverlässiger wird.

Läuft die Anwendung auf dem gleichen Rechner? Wie ist die CPU-Auslastung des Systems und wie voll ist der Arbeitsspeicher? Bei hoher CPU-Auslastung, hoher Netzwerkauslastung oder vollem Arbeitsspeicher ist die SPI-Kommunikation nicht mehr zuverlässig. SPI hat mit dem Standard-Raspbian-Kernel nämlich keine Echtzeitunterstützung.

Wenn du den HM-CFG-LAN parallel laufen lässt, empfängt dieser die vom CC1101 nicht empfangenen Pakete? Schick mir auch da mal ein Log und die Ausgabe von “top”, wenn es gerade nicht funktioniert. Hoffentlich kommen wir damit weiter…

Liebe Grüße

Sathya

#8

Dauert wieder eine Weile. Ich kann aber schon folgende Hinweise geben:

  • mit HM-CFG-LAN parallel funktioniert es ohne Probleme - dauerhaft
  • der RAM ist zu 80% belegt, Swapping hält sich in Grenzen
  • die CPU-Last liegt bei ungefähr 50% ±10%

Ja die Anwendung läuft auch auf dem Pi2. Der Netzwerktraffic dürfte sich in Grenzen halten, wobei hoch natürlich relativ ist. Würde ich aber eher ausschließen, da die Anwendung kaum Traffic übers Net erzeugt. Die Standard-Optimierungen mit tmpfs etc. zur Reduzierung von IO-Locks/-Delays hab ich aktiv.

#9

Hier mal die top-Ausgabe:

[code]top - 21:12:21 up 10 days, 21:02, 2 users, load average: 1.06, 0.74, 0.58
Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 16.4 us, 1.9 sy, 0.0 ni, 80.7 id, 0.0 wa, 0.0 hi, 1.0 si, 0.0 st
KiB Mem: 946104 total, 939460 used, 6644 free, 6780 buffers
KiB Swap: 1048572 total, 497188 used, 551384 free. 86848 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
27211 root 20 0 851452 474728 6952 S 42.6 50.2 4507:22 java
30151 root 20 0 148492 16192 4276 S 14.9 1.7 97:09.61 gst-launch-1.0
14009 root 20 0 203808 14852 4256 S 13.6 1.6 31:40.92 gst-launch-1.0
25758 root 20 0 2812 1628 1252 S 1.3 0.2 0:14.79 top
3 root 20 0 0 0 0 S 1.0 0.0 144:36.34 ksoftirqd/0
[/code]

Der ARM vom PI2 hat 4 Kerne.

Speicher:

root@alarmcontrol:/var/log/homegear# free total used free shared buffers cached Mem: 946104 933408 12696 40900 13680 144892 -/+ buffers/cache: 774836 171268 Swap: 1048572 567412 481160

Das Netzwerkinterface hat folgenden Traffic:

WLAN über USB etwa 320 kbyte/sec Ethernet-Port etwa 200 kbyte/sec

Der Traffic kommt überwiegend durch angebundene IP-Kameras (WLAN und Ethernet).

Der LAN-Gateway empfängt die “problematischen” Pakete scheinbar ohne Probleme.
Hiermal ein Log mit beiden Devices parallel:

06/16/15 21:22:21.582 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x41): 0CFDA6412A2111FD21B501FAC8 06/16/15 21:22:21.835 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x40): 0CFDA2412A2111FD21B501FAC8 06/16/15 21:22:22.329 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x40): 0CFDA2412A2111FD21B501FAC8 06/16/15 21:22:23.337 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x40): 0CFDA2412A2111FD21B501FAC8 06/16/15 21:22:25.340 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x40): 0CFDA2412A2111FD21B501FAC8 06/16/15 21:22:29.347 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3F): 0CFDA2412A2111FD21B501FAC8 06/16/15 21:22:31.826 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3E): 0CFEA6412A2111FD21B501FB00 06/16/15 21:22:32.084 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3E): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:32.580 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3E): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:33.594 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3F): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:35.584 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3F): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:39.560 HomeMatic BidCoS packet received (SPI, RSSI: 0x62): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:39.599 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x3E): 0CFEA2412A2111FD21B501FB00 06/16/15 21:22:39.660 Module HomeMatic BidCoS: TI CC110X "SPI": Info: Sending (SPI): 0AFE8002FD21B52A211100 Planned sending time: 06/16/15 21:22:39.660 06/16/15 21:22:39.711 HomeMatic BidCoS packet received (HM-CFG-LAN, RSSI: 0x4E): 0AFE8002FD21B52A211100

Müsste der RSSI beim SPI nicht sogar bedeuten, dass die Signalstärke dort besser ist? Wie man hier sieht, hat der CC1101 das Öffnen des Kontaktes gar nicht empfangen, dass Schließen erst nach mehreren Übertragungsversuchen.

#10

Hmm, das sieht soweit eigentlich gut aus. Die benötigte Sendezeit des CC1101 spricht auch gegen eine zu hohe Auslastung der Interrupts (geplante Sendezeit ist echte Sendezeit).

Aber: Der RSSI ist nicht gut! Die Anzeige im Log ist etwas verwirrend, weil der negative RSSI als positive Zahl dargestellt wird. Den Wert musst du mit -1 multiplizieren. Das bedeutet: 0x62 entspricht einem RSSI von -98 dBm. Das ist nah am Grenzbereich, kann also durchaus die Ursache für den Nichtempfang der Pakete sein. Der HM-CFG-LAN hat dagegen einen guten RSSI-Wert. Irgendwie habe ich das 0x6* deines ersten Posts überlesen :blush:. Ich war etwas durch meine eigene Erfahrung beeinflusst, dass eine zu hohe CPU-Auslastung zu SPI-Interrupt-Problemen führt. Hast du die Möglichkeit mit dem Fensterkontakt näher an den Raspberry Pi zu gehen, wenn das nächste Mal das Problem auftritt? Das könnte nämlich sehr wohl das Problem sein.

Liebe Grüße

Sathya

#11

Ok, wenn der RSSI doch eher auf einen schlechten Wert zurückzuführen ist, dann muss es wohl doch daran liegen.
Da ich schon mehrere Antennen versucht habe, scheint der CC1101 anscheinend keine gute Reichweite zu bieten. Wobei Homematic ja intern auch einen CC1101 verbaut, oder irre ich?

Wenn ich den Sensor näher an die Station führe, funktioniert er besser. Manchmal reicht es schon, den Sensor zu berühren, was wohl irgendwie die Sende-Eigenschaften verbessert. Komisch ist, dass einige der Problemsensoren zum Teil nur 3-4 Meter entfernt sind.

#12

Hallo vctender,

Die Reichweitenverbesserung durch Berühren der Sensoren klingt plausibel. Die sind so klein, dass sie schlecht abstrahlen und eine Erdung durch den menschlichen Körper die Abstrahleigenschaften verbessern kann.

Ein Software-Problem würde die schlechten RSSI-Werte nicht erklären.

Hast Du den Raspi mal gegen ein anderes Exemplar ausgetauscht? Ihm wird nachgesagt, dass sein schaltender Spannungsregler Funkmodule störe. Wir konnten das bisher nicht bestätigen, aber vielleicht hast Du ein “schlechtes Exemplar” erwischt? Mögliche Störungen könnten sich über die Spannungsversorgungsleitungen ausbreiten, was erklären würde, dass der CFG-LAN nicht betroffen ist.

Hast Du einen Lötkolben? Alternativer Test der Hypothese könnte ein vorübergehender Betrieb des CC1101-Moduls mit Batterie sein: Dazu müsstest Du VCC abklemmen (GND muss mit dem Raspi verbunden bleiben) und 2 volle AA- oder AAA-Batterien in Serie mit VCC (+) und GND (-) des CC1101-Moduls verbinden. Und dann schauen, ob sich der RSSI drastisch verbessert.

Liebe Grüße
Malli