CUL HM empfängt nicht oder sendet Empfangsdaten nicht an den Rechner

[frank]

hallo ansgar,

in rf_asksin.c gibt es diese behandlung von "zu langen" (>= 30/50 byte) telegrammen

Was nach der Info vor Seite 9 nicht ganz passt, weder die 30, noch die 50. Lediglich als Pufferüberlaufschutz funktional.
26 wäre max. für ein Datentelegramm für das Längenbyte. Bei FUP können es 39 für das Längenbyte sein, nach meinem bisherigen Erfahrungsstand.

ich habe ein altes FUP (HM-LC-SW1PBU-FM, alternative fw über hmusb mit eq3 software) gefunden mit 46 bytes.

Code Auswählen Erweitern

2014.10.24 12:18:16.698 0: HMLAN_Parse: hmlan1 R:E266E75   stat:0000 t:08B25141 d:FF r:FFC5     m:00 0010 266E75 000000 004B455131313039373937
2014.10.24 12:18:16.720 0: HMLAN_Parse: hmusb1 R:E266E75   stat:0000 t:09D61EA4 d:FF r:FFBB     m:00 0010 266E75 000000 004B455131313039373937
2014.10.24 12:18:16.974 0: HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:08B25255 d:FF r:FFB5     m:42 00CB 1ACE1F 266E75 105B11F81547
2014.10.24 12:18:17.017 0: HMLAN_Parse: hmusb1 R:E1ACE1F   stat:0000 t:09D61FB9 d:FF r:FFCC     m:42 00CB 1ACE1F 266E75 105B11F81547
2014.10.24 12:18:17.076 4: CUL_Parse: cul868 A 0F 43 20CB 1ACE1F 266E75 105B11F815471F -58.5
2014.10.24 12:18:17.113 4: CUL_Parse: cul868 A 0A 43 8002 266E75 1ACE1F 0032 -49
2014.10.24 12:18:17.161 4: CUL_Parse: cul868 A 2E 44 00CA 1ACE1F 266E75 01000C942C710C94D4710C9449710C9449710C9449710C9449710C9449710C9449710C94491F -58.5
2014.10.24 12:18:17.195 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 710C9449710C9449710C9449710C9449710C9449710C9449710C9449710C9449710C9420 -58
2014.10.24 12:18:17.228 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 49710C94BC710C9449710C94B5760C94E3760C9449710C9449710C9449710C9449710C20 -58
2014.10.24 12:18:17.261 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 9449710C9449712E007061676553697A6520616E6420626C6F636B506F7320646966661F -58.5
2014.10.24 12:18:17.318 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 65720A00546F206D616E79206461746120666F72207061676553697A650A00626C6F6320 -58
2014.10.24 12:18:17.370 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 6B4C656E20646966666572207061676553697A650A0057726F6E67204D73674964210A20 -58
2014.10.24 12:18:17.406 4: CUL_Parse: cul868 A 2C 44 00CA 1ACE1F 266E75 0052657472616E736D69742C207265666C617368210A00476F74206F74686572206D7320 -58
2014.10.24 12:18:17.441 4: CUL_Parse: cul868 A 14 44 20CA 1ACE1F 266E75 67547970650A005265636520 -58

##################

die maximale Paketlänge sollte sich filtern lassen, indem das PKTLEN Register 0x06 des cc1101 benutzt wird. Siehe auch "15.3.2  Maximum Length Filtering" Im cc1101 datasheet. rf_asksin.c Änderung:

wenn ich das richtig sehe, wird zumindestens im file cc1100.c PKTLEN auf 61 byte begrenzt.

Code Auswählen Erweitern

const PROGMEM const uint8_t CC1100_CFG[EE_CC1100_CFG_SIZE] = {
// CULFW   IDX NAME     RESET STUDIO COMMENT
   0x0D, // 00 IOCFG2   *29   *0B    GDO2 as serial output
   0x2E, // 01 IOCFG1    2E    2E    Tri-State
   0x2D, // 02 IOCFG0   *3F   *0C    GDO0 for input
   0x07, // 03 FIFOTHR   07   *47   
   0xD3, // 04 SYNC1     D3    D3   
   0x91, // 05 SYNC0     91    91   
   0x3D, // 06 PKTLEN   *FF    3D   

scheinbar ein default von STUDIO (Atmel Studio?), was auch zur empfehlung im "RXFIFO_OVERFLOW Issue" passt.
dann würde ich sogar behaupten, dass die maximale länge unter hmip auch aus diesem "default" resultiert.

In applications where the packets are short enough to fit in the RX FIFO and one wants
to wait for the whole packet to be received before starting to read the RX FIFO, for
variable packet length mode (PKTCTRL0.LENGTH_CONFIG=1) the PKTLEN register
should be set to 61 to make sure the whole packet including status bytes are 64 bytes or
less (length byte (61) + 61 payload bytes + 2 status bytes = 64 bytes) or PKTLEN ≤ 62 if
fixed packet length mode is used (PKTCTRL0.LENGTH_CONFIG=0). In application
where the packets do not fit in the RX FIFO, one must start reading the RX FIFO before
it reaches its limit (64 bytes).

##################

Und was sind die eindeutigen Merkmale zur Unterscheidung in den 3 Bytes?

ich habe mal begonnen, die ersten 3 byte meiner empfangenen hmip messages zu sammeln. bisher sieht die liste sehr überschaulich aus. allerdings empfange ich hier auch nur sehr selten hmip, eventuell aus wohnmobilen.

Code Auswählen Erweitern

12 0083
10 008E
10 018E
00 008F
01 008F
bei diesem asksinpp projekt wird das 3. byte zur hmip erkennung untersucht.
"typeInt >= 0x80" ist aber falsch, da hier mindestens noch die typen 0xCA und 0xCB für das firmware update fehlen.
https://github.com/psi-4ward/AskSinAnalyzerXS/blob/master/app/src/SnifferParser.ts

Code Auswählen Erweitern

function getType(typeInt: number) {
  if (typeInt == 0x00) return "DEVINFO";
  else if (typeInt == 0x01) return "CONFIG";
  else if (typeInt == 0x02) return "RESPONSE";
  else if (typeInt == 0x03) return "RESPONSE_AES";
  else if (typeInt == 0x04) return "KEY_EXCHANGE";
  else if (typeInt == 0x10) return "INFO";
  else if (typeInt == 0x11) return "ACTION";
  else if (typeInt == 0x12) return "HAVE_DATA";
  else if (typeInt == 0x3E) return "SWITCH_EVENT";
  else if (typeInt == 0x3F) return "TIMESTAMP";
  else if (typeInt == 0x40) return "REMOTE_EVENT";
  else if (typeInt == 0x41) return "SENSOR_EVENT";
  else if (typeInt == 0x53) return "SENSOR_DATA";
  else if (typeInt == 0x58) return "CLIMATE_EVENT";
  else if (typeInt == 0x5A) return "CLIMATECTRL_EVENT";
  else if (typeInt == 0x5E) return "POWER_EVENT";
  else if (typeInt == 0x5F) return "POWER_EVENT_CYCLIC";
  else if (typeInt == 0x70) return "WEATHER";
  else if (typeInt >= 0x80) return "HMIP_TYPE";
  return "";
}

zusätzlich gibt es noch eine spezielle hmip message mit 6 bytes länge, die nur 2 geräteadressen (hmid) enthält.
das könnte das "kurze telegramm" sein (dunkelblau), das auf seite 10 des eq3-pdf zu finden ist. da der "reine" hmip burst auf 869mhz gesendet wird, ist das kurze telegramm eventuell auf 868mhz die entsprechende info zum burst.

[noansi]

Hallo Frank,

ich habe ein altes FUP (HM-LC-SW1PBU-FM, alternative fw über hmusb mit eq3 software) gefunden mit 46 bytes.

Danke für die Info. War fast zu erwarten, dass es ein Gegenbeispiel gibt.

wenn ich das richtig sehe, wird zumindestens im file cc1100.c PKTLEN auf 61 byte begrenzt.

Was aber für HM nichts bringt, weil in rf_asksin_init vor dem Schreiben der Konfiguration ein Reset des cc1101 ausgeführt wird und damit der Default von 255 wieder in dem Register landen sollte.

In SlowRF bringt es auch nichts, weil dabei gar kein Paket Handling stattfindet.

dann würde ich sogar behaupten, dass die maximale länge unter hmip auch aus diesem "default" resultiert.

Kann ich mir auch vorstellen.

ich habe mal begonnen, die ersten 3 byte meiner empfangenen hmip messages zu sammeln. bisher sieht die liste sehr überschaulich aus. allerdings empfange ich hier auch nur sehr selten hmip, eventuell aus wohnmobilen.

In der Tat übersichtlich. 

"typeInt >= 0x80" ist aber falsch, da hier mindestens noch die typen 0xCA und 0xCB für das firmware update fehlen.

Sehe ich auch so, bis auf die um Faktor 10 höheren Datenrate, mit der die beiden bei FUP gesendet werden.

Ist Bit 7=1 beim "HMTyp" für IP gesichert oder nur nicht anders beobachtet?
Siehe meine obige Fehlerfahrung zu FUP bei der Länge...

zusätzlich gibt es noch eine spezielle hmip message mit 6 bytes länge, die nur 2 geräteadressen (hmid) enthält.

In der tsculfw wir das schon durch Prüfung des Lenght Byte auf Mindestlänge 9 gefiltert. Also auch in culfw sehr einfach einbaubar.

Gruß, Ansgar.