CUL/COC HM-Firmwaretester gesucht

[mgernoth]

Hallo,

nachdem ich größere Probleme hatte, einen HM-LC-SW1-FM zuverlässig mit einem CUL anzusprechen (obwohl RSSI weit im grünen Bereich), der gleiche Aktor aber mit einem HM-CFG-USB absolut problemlos lief, habe ich mir mal den AskSin-Mode der culfw genauer angeschaut und habe zu meinen Kommunikationsproblemen folgendes gefunden:

• Nach dem Absetzen eines Funkbefehls kann es (im schlechtesten Fall) 5ms dauern, bis der RX-Modus wieder aktiviert wird. Alles was dazwischen gesendet wird, geht verloren. Anscheinend antwortet der HM-LC-SW1-FM recht schnell, weshalb ich zwar (mit dem HM-CFG-USB mitgesniffed) die Antwort des Aktors in der Luft gesehen habe, der CUL diese aber ignortiert hat, da er sich nicht mehr einsynchronisieren konnte.
• Einige Aktoren (anscheinend mindestens der HM-LC-SW1-FM) brauchen eine etwas längere Präambel vor dem eigentlichen Befehl, um sich sicher auf die übertragenen Daten zu synchronisieren.
• Durch die Art, wie der Empfangsmodus in der culfw implementiert ist, kann es bei vielen gleichzeitigen Paketen in der Luft (z.B. Antworten auf ein "set" auf eine große structure) zu Paketverlusten kommen, da der RX-Modus nach jedem empfangenen Paket abgeschaltet wird und erst wieder aktiviert wird, wenn der Mikrocontroller das Paket vollständig gelesen hat. So scheint aber auch der HM-CFG-USB zu arbeiten.

Alle drei Punkte habe ich versucht zu verbessern:

• Der CC1101 ist jetzt so konfiguriert, dass er nach dem Verlassen des TX-Modus sofort selbstständig in den RX-Modus wechselt.
• Vor dem Absetzen eines Funkbefehls wird jetzt immer eine 10ms lange Präambel (im Burst-Fall 360ms) gesendet.
• Die Empfangslogik wurde komplett überarbeitet, der CC1101 verlässt den RX-Modus nun nicht mehr und der Mikrocontroller kümmert sich darum, immer komplette Pakete aus dem FIFO des CC1101 zu holen und an den Host weiterzugeben.

Mit diesen Änderungen kann ich meinen Problemaktor zuverlässig bedienen (kein verlorenes Paket bei 200 Versuchen, davor mindestens 1 verlorenes Paket bei 5 Versuchen) und bekomme auch alle Antworten, wenn ich den Zustand einer Struktur mit 7 Aktoren ändere, ohne das eine Retransmission (durch CUL_HM) nötig wird.

An diesem Post hängen Firmware-Dateien für CUL und COC, die meine Änderungen (Patch) enthalten. Sollte irgendjemand auch Probleme bei der Kommunikation mit einzelnen Aktoren haben, verschafft diese Firmware vielleicht Besserung. Über positive (und auch negative) Rückmeldungen würde ich mich freuen.

Gruß
  Michael

[marc2]

Hallo Michael,

ich habe einen HM-LC-SW2-FM der über einen direkt gepairten Taster wunderbar funktioniert
mit CUL und CUNO (trotz recht guten RSSI Werte) immer wieder Probleme macht. Ich habe den
CUL der als primäres IODev genutzt wird mal mit Deinem Patch versehen. Bisher funktioniert
der HM-LC-SW2-FM jetzt über den CUL ohne die bisherigen Probleme. Werde ich mal weiter
beobachten und ggf. auch noch den CUNO mit dem Patch versehen.

Es wundert micht, dass es in diesem Thread so ruhig zugeht ! Hat wirklich sonst noch niemand
den Patch getestet ? Beim gestrigen Update kamen zwar neuen HEX Dateien mit, das CULFW SVN
ist aber unverändert . Warum dann die neuen HEX Files für CUL und Co. ?

Gruß, Marc

[mgernoth]

Hallo Marc,

ich habe einen HM-LC-SW2-FM der über einen direkt gepairten Taster wunderbar funktioniert
mit CUL und CUNO (trotz recht guten RSSI Werte) immer wieder Probleme macht. Ich habe den
CUL der als primäres IODev genutzt wird mal mit Deinem Patch versehen. Bisher funktioniert
der HM-LC-SW2-FM jetzt über den CUL ohne die bisherigen Probleme. Werde ich mal weiter
beobachten und ggf. auch noch den CUNO mit dem Patch versehen.

Danke für die Rückmeldung. Schön, dass der Patch auch bei Dir hilft. :-)

Es wundert micht, dass es in diesem Thread so ruhig zugeht ! Hat wirklich sonst noch niemand
den Patch getestet ?

Anscheinend hat sonst niemand diese Probleme, oder es faellt nicht auf (meistens kommt ja einer der Retransmits trotzdem beim Aktor an)...

Beim gestrigen Update kamen zwar neuen HEX Dateien mit, das CULFW SVN
ist aber unverändert . Warum dann die neuen HEX Files für CUL und Co. ?

Die Firmware-Dateien enthalten die Änderungen der ersten beiden Punkte. Die Änderungen für den letzten Punkt hatte ich mich nicht getraut zu committen, da ich manchmal noch Probleme habe, die Paketgrenzen richtig zu erkennen.
Der aktuelle Code im SVN hat noch ein paar mehr Änderungen, womit jetzt auch CCA benutzt wird (es wird vor dem senden geschaut, ob gerade anderer Funkferkehr stattfindet und solange gewartet, bis dieser vorbei ist). Da habe ich aber noch keine neuen HEX-Dateien committed.

Evtl. hast Du einen alten SVN-Checkout, sourceforge hat das Repository umgezogen:
svn checkout svn://svn.code.sf.net/p/culfw/code/trunk/culfw">svn://svn.code.sf.net/p/culfw/code/trunk/culfw

Gruß
  Michael

[marc2]

Hallo Michael !

Der aktuelle Code im SVN hat noch ein paar mehr Änderungen, womit jetzt auch CCA benutzt wird (es wird vor dem senden geschaut, ob gerade anderer Funkferkehr stattfindet und solange gewartet, bis dieser vorbei ist). Da habe ich aber noch keine neuen HEX-Dateien committed.

Wenn CCA bislang nicht implementiert war, bin ich verblüfft, wie gut das ganze bisher auch ohne CCA funktioniert hat :-)

Evtl. hast Du einen alten SVN-Checkout, sourceforge hat das Repository umgezogen:
svn checkout svn://svn.code.sf.net/p/culfw/code/trunk/culfw">svn://svn.code.sf.net/p/culfw/code/trunk/culfw

Ja, in der Tat, das ist an mir vorbei gegangen. Danke für den Hinweis ! Das scheint für FHEM selbst ja auch zu gelten, wobei
das auf FHEM.de referenzierte SVNLOG noch auf die alte Lokation verweist (Revision 3274).

http://fhem.de/SVNLOG

Gruß, Marc

[mgernoth]

Hallo Marc,

soeben habe ich neugebaute Firmwaredateien (Version 1.57) ins SVN committed, d.h. ab morgen gibts CCA per update.

Wenn CCA bislang nicht implementiert war, bin ich verblüfft, wie gut das ganze bisher auch ohne CCA funktioniert hat :-)

Naja, die "alte" Version hat schon ein bisschen CCA gemacht: Sie hat das aktuelle Paket weggeschmissen und nicht gesendet.
Mein Änderungen in 1.56 haben dann CCA komplett umgangen, weil ccTX() sich etwas unerwartet verhält (es kämpft aktiv gegen CCA). Das habe ich zwar schonmal festgestellt aber wieder verdrängt. Deswegen habe ich dann die ccTX()-Funktionalität nochmal etwas abgewandelt in rf_asksin.c implementiert.

Das scheint für FHEM selbst ja auch zu gelten, wobei das auf FHEM.de referenzierte SVNLOG noch auf die alte Lokation verweist (Revision 3274).

http://fhem.de/SVNLOG

Danke, ich schreibs mal Rudi, damit er sich die Links anschaut.

Gruß
  Michael

[marc2]

Hallo Michael,

ich habe die Version 1.57 mal auf meinen CUL und nach ein paar kurzen erfolgreichen Tests (der problematische Aktor funktioniert nach wie vor fehlerfrei), auf beide CUNOs geflasht. Nachdem auch die von Hand gepatchte 1.55 auf den CUL keinerlei Probleme gemacht hat, bin ich bei Deiner 1.57 auch guter Dinge :-) Ich werde es die kommenden Tage mal beobachten.

Beinhaltet diese Version nun alle drei Änderungen + CCA ? Haben die Änderungen eigentlich ausschließlich Auswirkungen
auf "rfmode HomeMatic" oder auch z.B. "rfmode MAX" oder andere. MAX nutzt zwar kein asksin, aber es wurde ja auch
einiges mehr angepackt.

Gruß, Marc

[mgernoth]

Hallo Marc,

ich habe die Version 1.57 mal auf meinen CUL und nach ein paar kurzen erfolgreichen Tests (der problematische Aktor funktioniert nach wie vor fehlerfrei), auf beide CUNOs geflasht. Nachdem auch die von Hand gepatchte 1.55 auf den CUL keinerlei Probleme gemacht hat, bin ich bei Deiner 1.57 auch guter Dinge :-) Ich werde es die kommenden Tage mal beobachten.

Sehr gut :-)

Beinhaltet diese Version nun alle drei Änderungen + CCA ?

Nein, nur die ersten beiden und CCA. Wobei ich diese Version jetzt einsetze, seit ich die Änderungen committed habe und dabei keine Funkprobleme mehr aufgetreten sind. Wahrscheinlich war das Problem also eher das fehlende CCA als das kurze Abschalten des Receive-Mode nach dem Empfang eines Pakets.

Haben die Änderungen eigentlich ausschließlich Auswirkungen auf "rfmode HomeMatic" oder auch z.B. "rfmode MAX" oder andere. MAX nutzt zwar kein asksin, aber es wurde ja auch einiges mehr angepackt.

Meine Änderungen betreffen nur Homematic (und Support für die RFbee). Die anderen Änderungen stammen von Dirk Tostmann und sind für die Implementierung von Aktoren/Sensoren mit culfw relevant (wenn ich das richtig sehe).
Die Moritz-Implementierung sieht für mich auf den ersten Blick so aus, als ob sie die Probleme der AskSin-Implementierung nicht hätte, genau hab ich mir das aber noch nicht angeschaut.

Gruß
  Michael

[thunder]

sorry für die dumme Frage... aber wo finde ich die compilierte 1.57 für den CUNO2?

[mgernoth]

Hallo,

sorry für die dumme Frage... aber wo finde ich die compilierte 1.57 für den CUNO2?

Das ist gar keine dumme Frage. Da ich die culfw-Webseite nicht aktualisieren kann, findest Du die kompilierte Version für alle Geräte nur im SVN-Repository. Das hat aber auch ein Web-Interface: https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/

Die Firmware für den CUNO2 gibts direkt hier: https://sourceforge.net/p/culfw/code/HEAD/tree/trunk/culfw/Devices/CUNO2/CUNO2.hex?format=raw

Gruß
  Michael

[thunder]

Vielen Dank!!!!

[betateilchen]

Ich habe grade die COC radio-only 1.57 auf meinen COC geladen, danach tut der gar nicht mehr, weder senden noch empfangen.

Wenn ich wieder die 1.49 einspiele, ist alles in Ordnung. Hat jemand einen konstruktiven Tipp für mich?


Nachtrag: die 1.55 hier aus dem Thread scheint zu funktionieren.

[mgernoth]

Hi,

Ich habe grade die COC radio-only 1.57 auf meinen COC geladen, danach tut der gar nicht mehr, weder senden noch empfangen.

Wenn ich wieder die 1.49 einspiele, ist alles in Ordnung. Hat jemand einen konstruktiven Tipp für mich?

Nachtrag: die 1.55 hier aus dem Thread scheint zu funktionieren.

Hmm, das ist komisch.
Die Version in diesem Thread hat im Gegensatz zur 1.57 einen anderen CC1101-FIFO-Lesealgorithmus, der Sendealgorithmus ist aber fast identisch.
Die 1.57 hat einen CC1101-FIFO-Lesealgorithmus, der sich wieder näher an dem der Release-FW <= 1.55 ist.
Der eingesetzte Compiler ist bei beiden Versionen identisch (habe beide auf dem selben Rechner kompiliert).

Deswegen hätte ich erwartet, dass zumindest eine der beiden Operationen Senden/Empfangen funktioniert.

Hast Du evtl. irgendwelche SlowRF-Geräte die den COC als IODev benutzen? Das geht im HM-Modus nicht, da nach dem umschalten auf SlowRF die AskSin-Configuration nicht wieder hergestellt wird.

Ich versuche mal draufzukommen, warum die 1.57 bei Dir dieses Verhalten zeigt. (Bei mir läuft sie problemlos auf einem COC).

Gruß
  Michael

[betateilchen]

Hallo Michael,

der COC wird bei mir ausschließlich für SlowRF (FS20 und S300TH) benutzt und nie umgeschaltet. Für HomeMatic habe ich separate Hardware im Einsatz.

Was mir noch aufgefallen ist:
Bei 1.49 und 1.55 wird mir der COC als "initialized" in FHEM angezeigt, mit 1.57 steht da nur "opened" und es wird auch keine Versionsnummer angezeigt.

Viele Grüße
Udo

[mgernoth]

Hallo Udo,

Was mir noch aufgefallen ist:
Bei 1.49 und 1.55 wird mir der COC als "initialized" in FHEM angezeigt, mit 1.57 steht da nur "opened" und es wird auch keine Versionsnummer angezeigt.

Also kommt gar keine Kommunikation mit dem COC zustande.
Hast Du ihn nach dem Flashen nochmals testweise resettet und war der Bootloader-Pin (gpio18) sicher wieder high?

Der grundlegende Kommunikationscode wurde zwischen den Versionen nicht angefasst, deswegen ist dieses Verhalten noch sonderbarer als gedacht...

Gruß
  Michael

[betateilchen]

Hast Du ihn nach dem Flashen nochmals testweise resettet und war der Bootloader-Pin (gpio18) sicher wieder high?

Hallo Michael,

Alles probiert. Inkl. spannungslos machen und wieder Einschalten der gesamten Hardware. Die beiden anderen Versionen laufen direkt nach dem Aufspielen und dem Neustart von fhem los (beim Start von fhem wird der COC resettet)

Viele Grüße
Udo