Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41

Begonnen von noansi, 09 Juni 2014, 19:16:01

Vorheriges Thema - Nächstes Thema

rudolfkoenig

Zitatauf Seite 31 der cc1101 Doku steht es in Table 23: Status Byte Summary.
Das war bei mir auf Seite 26, ich sollte meine Dokumente erneuern. Ich habs eingebaut, und getestet: CUL_V4 funktioniert, auch ein CUL V1.1 als Basis mit einem "neuen" CUL V2.1 als RFR. Habs als 1.60 eingecheckt, damit wir Probleme einfacher eingrenzen koennen.

ZitatAllerdings führt das immer noch vorhandene (vermutlich) USB Problem trotz CUL_WS Konfiguration (also nur Empfang) zu folgenden Einträgen mit PLL0:
Ich war bisher ueberzeugt, dass diese Probleme von der anderen Seite (Linux/etc) stammen, weil da echo aktiviert ist.
Bin inziwschen nicht mehr so sicher.

ZitatCUL_0WS: unknown message K00
Sowas ist "normal", ich (oder jemand sonst :) muesste endlich mal fuer das S300 Protokoll die Pruefung
des zweiten CRC-Nibbles einbauen, samt Minimallaenge.

ZitatHier noch mehr Log zum Problem:
Hilft mir nicht.


noansi

Hallo Rudolf,

ZitatIch war bisher ueberzeugt, dass diese Probleme von der anderen Seite (Linux/etc) stammen, weil da echo aktiviert ist.
Bin inzwschen nicht mehr so sicher.

Echo ist (zumindest bewust) nicht an. Sonst müsste es bei AskSin auch immer auftreten, wenn empfangene Sensordaten an den RasPi geschickt werden.

Ich habe mit CDC_Task nun einige Varianten durch, um dem Problem näher zu kommen. Aber einer Lösung hat mich das noch nicht näher gebracht.

CDC_Task fest gegen Interrupt- Reentranz zu machen, macht Sinn. Denn

  • display_char wird ggf. in ISR(TIMER1_COMPA_vect) aufgerufen wenn REP_MONITOR aktiv ist oder wenn in einem Interrupt mal was ausgegeben werden soll
  • CDC_Task wird auch von display_char aufgerufen, um bei vollem TTY Puffer Platz zu schaffen oder bei Zeilenende die Daten im TTY Puffer auch auf die Reise zu schicken
  • input_handle_func sorgt wiederum ggf. für Output über display_char und verstellt dann bei einem möglichen Aufruf in einem Interrupt den Endpoint

Hilft aber nicht wirklich gegen das Problem.

Dafür bin ich aber noch auf folgenden Beitrag zu LUFA gestoßen, was mir vom Verhalten her ähnlich scheint und mit einem LUFA Update Besserung bringen könnte:

https://code.google.com/p/lufa-lib/issues/detail?id=21

In der Doku zum ATmega32U4 bin ich auch schon auf das Speichermanagement des DPRAM für Endpoint Bänke gestossen. Aber ob die TX Bank mal (durch ein USB "Ereignis") freigegeben werden kann und damit ein Problem auftreten könnte, ist mir nocht nicht klar.

Da ich aber sonst bisher keinen andren Grund im Quelltext der Firmware habe finden können, bleibt mir derzeit nur der LUFA Code als Fehlerquelle übrig(, so mir denn USB-Hub und RasPi keinen Streich spielen).

Das einzige, was mir auffällt, ist, dass die CUL die nur auf CUL_WS läuft, also bis auf die Initialisierung eigentlich keine Daten mehr vom Host bekommen sollte, das Problem drastischer zeigt, als die die auf CUL_HM läuft und immer mal wieder Sendedaten vom Host bekommt.

Gruß, Ansgar.

noansi

Hallo Rudolf,

hier habe ich mal zwei markannte Log-Einträge:

2014.06.23 13:05:50 2: CUL_0: unknown message ? (7812345678123456781234567812345678123As1078A011F1103417832D0201290320FFFF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x
2014.06.23 16:48:59 2: CUL_0: unknown message ? (7812345678123456781234567812345678123As10B5A011F1103417832D0201230320FFFF is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x


die "7812345678123456781234567812345678123" müssen noch von ein Ping-Test stammen, den ich heute morgen noch losgelassen habe.

Der Ping war lang, so dass er gerade komplett in den Befehlspuffer passte:

Ap123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456

die Antwort war dann so was:

AFF02009D66223F12345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345678123456781234567812345680

Das Muster der Pingdaten hat sich also über Stunden erhalten. Und es ist die gleiche Anzahl an Bytes (37), die da im Eingabestrom vor dem eigentlichen Sendebefehl landen. Andere Log-Einträge sind nicht aufgetreten (außer einigen PLL0 Meldungen).

Die CUL ist auf CUL_HM eingestellt und sendet und empfängt regelmäßig Daten.

D.h. die TTY-Ringbuffer sind in der Zeit schon mehrfach überschrieben worden. Da kann es nicht herkommen.

Der Code für den Befehlspuffer in analyze_ttydata arbeited mit Feldoffset. Da kann sich das Muster nicht drin erhalten haben, schon gar nicht vor dem Sendebefehl.

Dann bleiben als Fehlerkandidaten auf CUL Seite nur noch die USB-Bänke übrig. Die TX-Bank wird üblicherweise bei den Empfangsdaten nicht voll genutzt. D.h. da können sich Daten von dem langen Ping erhalten. Gleiches gilt für die RX-Bank, da die Sendebefehle auch kürzer als 64 Bytes sind.
D.h. beide Bänke wären prinzipiell Kandidaten. Da bei CUL_WS aber CUL anscheinend Ausgabedaten im Empfangsbuffer landen mutmaße ich mal, dass es auch hier ehemalige Sendedaten sind.
Die 37 kann auch durch Fragmente von CR/LF verfälscht sein, da CR/LF ja in analyze_ttydata unter den Tisch fallen können.

Das ist schon alles seltsam, auch wenn es auf der Gegenseite beim USB-Hub oder RasPi passieren sollte.

Fällt Dir dazu noch was auf oder ein?

Gruß, Ansgar.

rudolfkoenig


noansi

#19
Hallo Martin,

hier eine neue Test-Version für CUL_V3 für TimeStamp.

In Sachen USB habe ich Stabilitätsverbesserungen in der Firmware erzielen können.
Allerdings hat auch mein RasPi seinen Teil zum USB-Problem beigetragen. Aktives plotfork führt zu USB Problemen auf dem RasPi, wie ich empirisch herrausgefunden habe. Plotfork auf dem RasPi also abschalten.

PLL-Lock Check ist natürlich auch drin.

Credits10ms laufen damit auch unter ASKSIN und begrenzen die Sendezeit, wie es sein sollte. Hier kanst Du die Rückmeldungen (s.u.) zur Optimierung oder Begrenzung für sendezeithungrige Geräte nutzen.

Bei den TimeStamps habe ich erweitert.
Das Codeformat hat sich geändert in FFxy, wobei y den Typ kennzeichnet und x eine grobe Auskunft über den Stand der Credits10ms liefert.

Hier die Definitionen aus dem Quellcode, die das erläutern:


#  define TS_ID_RECTIME 0xff01 // Receive TimeStamp

# ifdef HAS_ASKSIN_PING
#  define TS_ID_PING 0xff02 // Ping Receive TimeStamp
# endif

# ifdef HAS_ASKSIN_SEND_TIMESTAMP
#  define TS_ID_SENDSUCC 0xff03 // Send Success TimeStamp
#  define TS_ID_SENDFAIL 0xff04 // Send Fail TimeStamp, failed due to switch to TX, channel not free
#  define TS_ID_SENDFAIL_CREDIT 0xff05 // Send Fail TimeStamp, failed due to not enough credits
#  define TS_ID_SENDFAIL_LEN 0xff06 // Send Fail TimeStamp, failed due to message lenght error
# endif // HAS_ASKSIN_SEND_TIMESTAMP


// credit level Ids, are ored to Timestamp ID
#  define TS_ID_CREDIT_OK 0x00        // credits <= 3600
#  define TS_ID_CREDIT_HALF 0x10 // credits < 1800 (< 50% of hourly sendtime left)
#  define TS_ID_CREDIT_QUARTER 0x20 // credits < 900 (< 25% of hourly sendtime left)
#  define TS_ID_CREDIT_LOW 0x30 // credits < 360 (< 10% of hourly sendtime left)
#  define TS_ID_CREDIT_NOBURST 0x40 // credits < 37 (not enough credits for another burst message)
#  define TS_ID_CREDIT_NONE 0x50 // credits < 2 (not enough credits for another message at all)


TimeStamps kommen nun auch beim Senden mit den IDs FFx3 bis FFx6 und liefern den Zeitpunkt des Sendens (oder des Fehlers), und liefern damit etwas Feedback zum Sendeerfolg und grob für ein Credits Management.

In der angehängten Zip Datei sind sowohl Hex File für CUL_V3, als auch der Quelltext dazu und auch ein adaptiertes 00_CUL.pm enrhalten, das derzeit nur die Empfangssnachrichten weitergibt und die Sendefeedbacknachrichten ausfiltert.

Da ich wegen Problemen mir KS Sensoren auch kräftig am SlowRF Empfang und Dekodieren geändert habe, kann ich aus meinen Tests mit CUL und COC sagen, dass meine ELV KS-Wetterstationssensoren, WS2000 Repeater und ein TX3 Sensor und meine Homematic-Sensoren/Aktoren funktionieren.

Andere SlowRF Protokolle und auch der RF-Router wären von freiwilligen Testern :) noch zu testen.
Probleme mit dieser Testversion bitte hier melden, da es zum Teil erhebliche Abweichungen zum bisherigen Code gibt und mich natürlich interessiert, welche Unschärfen trotz aller Mühe ggf. noch verblieben sind und ich die auch korrigieren möchte.

Wenn die PLL Nachrichten stören, lassen sie sich mit AP1 bis um nächsten Reset abschalten.
PLL35 zeigt wiederholte Versuche der Umschaltung auf Sendebetrieb an und sind erst mal nicht bedenklich.

Gruß,

Ansgar.

tpm88

Hallo Ansgar,

die neue Kombi aus FW und modifizierter 00_CUL.pm mit Timestamps funktioniert in meiner HM Umgebung einwandfrei. Meine Test-Suite mit den immer etwas kritischen getConfigs auf die RT-DNs läuft fehlerfrei und erstmals sogar ganz ohne Resends.

Die PLL-Lock Checks und vor allem aber die TimeStamps haben die Stabilität und das HM Timing mit CUL definitv verbessert.  Möchte ich daher nicht mehr missen :)

@Rudolf - Wann bekommen wir das im Standard?

Vielen Dank für die Arbeit, Gruß
Tobias
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

rudolfkoenig

Wenn ich einen Patch (== diff -u) sehe, dann kann ich das beurteilen.
Je groesser der Patch, desto eher kommt es hinten in meine TODO Liste.
Und wichtig: ein Patch == ein Problem.

noansi

Hallo Rudolf,

ich habe mit Blick auf Deine übrigen Supportbemühungen größtes Verständnis für Deine Haltung und Vorgehensweise. Daher habe ich auch eine Testversion für Martin bezüglich erweiterterter TimeStamps und willige Tester für alle Änderungen gepostet.

Ich habe ein ureigenes Interesse, meine KS, TX3 und Homematic Sensoren stabil zu empfangen und mit Homematic zu meinen Aktoren stabil senden zu können. Insbesondere, da es kühler wird und alles laufen soll.
ks_send war ein nettes Spiel am Rande, was ich aber auch ändern und testen musste, wegen der Checksummenänderungen an KS.

Die Empfangs-TimeStamps haben sich bei mir positiv ausgewirkt. Und ein CUL bei mir profitiert in Sachen Stabilität deutlich von den PLL-Lock Änderungen.

Wirf bitte mal einen Blick in rf_receive.c aus der Quellcode zip. Das ist in großen Teilen geändert und umsortiert (weil das auch noch mal ein paar wenige Bytes Veränderung bewirkt hat). Auch mit einem diff -u würdest Du es nach bisheriger Erfahrung ans Ende des Endes Deiner ToDo Liste schieben oder wegen zu aufwändig ablehnen. Aber vielleicht weckt es trotzdem Dein Interesse.

Immerhin funktioniert damit der Empfang aller meiner KS Sensoren, auch der Helligkeitssensor S2500H und auch die WS2000 Repeater.
Der Helligkeitssensor funktionierte zuvor nicht, weil die Checksummenauswertung bezüglich ungerader/gerader Nibblezahl nicht sauber war (und war nach erfolglosen Antennen- und Batterieexperimenten schon kurz vor dem Mülleimer  ;)). Das machte dann wieder Anpassungen in rf_send erforderlich...
Und die WS2000 Repeater sind schon im Sendetiming (mit Oszi vor dem Sender gemessen) sehr variabel und dass schon beim Sync (und ich habe mich zuvor gewundert, warum die ELV Empfänger sehr häufig von den Repeatern was empfingen, aber CUL nur sehr selten). Daher habe ich die Sync-Detection verändert und auch ein Umtastprotokoll-Collect ergänzt, sowie eine Variation in der Timingempfindlichkekt ergänzt.
TX3 wird nun schon im Sync erkannt und das konnte ich ebenfalls testen, weil ich einen Temperatursensor dafür habe.

Wenn Du andere SlowRF Protokolle und den RFRouter testen kannst, herzlich gerne. Mir fehlt leider die Hardware dazu. Wenn Du darin Probleme siehst, mach ich mir gerne Gedanken dazu.

Da ich mich mit SlowRF nun intensiv auseinander gesetzt habe, habe ich nun auch verstanden, warum Du bei cli()/sti() empfindlich reagierst und alles geänderte, was eine Interruptabschaltung erfordert, so knapp wie möglich gehalten, um das SlowRF Empfangs-Timing minimalst zu stören.

Mit COC kann man übrigens in dieser Testversion auch mal das SlowRF Empfangstiming in Textform über ganze Messages in lesbarer Form ins Log bekommen (HAS_RF_RECEIVE_RECORD definiert und REP_LCDMON gesetzt). Mit CUL geht das mangels Speicher leider nicht.

Und ein Blick in rf_asksin.c ist angebracht, da darin die Begründung für die Creditsanwendung auf ASKSIN steht.

Zitatein Patch == ein Problem

Ich komme mit der Summe Deiner Wünsche und gefundener Probleme leider nicht drumherum, an vielen Schrauben zu drehen, insbesondere der Wunsch nach geringem Programmspeicherbedarf erfordert immer wieder die Suche nach ein paar Bytes, die noch für CUL_V2 raus zu kitzeln sind, respektive bedingte Compilierung, da ich für alle Ergänzungen für CUL_V2 nicht genügend freie Bytes habe finden können.

Da ich dabei jeweils meine CC1101 Änderungen verwende, benötige ich diese auch. Ebenso die Erweiterung in display, clock und die weiteren Änderungen.
Das alles in kleine Patches zu zerlegen, tut's bei mir leider nicht mehr. Das bekomme ich auch zeitlich nicht hin, respektive wäre auch unnütz, weil Du es erst in Summe verstehen kannst.

Gruß, Ansgar.

martinp876

Hallo Ansgar,

anbei meine Version des 00_CUL.pm.

ich habe deine Änderungen eingearbeitet und meine Timing-korrektur sowie die formatierten Logs bestehen lassen.
Leider hatte Rudi damals bereits die (für HM notwendigen) Änderungen verweigert - daher muss ich alles manuell nachziehen, was er ändert.

Ein grobtest deiner FW hat bei mir funktioniert. Auch die Timing-justierung scheint zu funktionieren.
Das Abschalten nach Sendezeitüberschreitung habe ich noch nicht probiert. Bekomme ich hier einen statusreport, wenn nicht gesendet wird?

Gruß Martin


rudolfkoenig

ZitatDas ist in großen Teilen geändert und umsortiert

Und genau das ist mein Problem. Ich will die Aenderungen verstehen, weil ich dafuer geradestehen muss bzw. ich support dafuer leiste. Und ich habe nicht die Zeit/Energie alles neu zu lesen, verstehen, und zu testen. Deswegen die bitte: moeglichst kurze Patches und ein Patch pro Problem. Wenn das nicht moeglich ist, dann kommt der Patch nicht rein.

martinp876


noansi

Hallo Martin,

bei jedem Senden kommt eine Antwort zurück.

Bei Erfolg ein A + FFx3 + TimeStamp + die an CUL gesendete Message ohne das "As". Das x gibt stets grob Info über die Credits, die noch zur Verfügung stehen, siehe auch die unteren 6 defines aus meiner letzten Erklärung dazu.

Bei Misserfolg kommt A + FFx4 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn der Kanal bis zum Timeout nicht frei war.
Oder A + FFx5 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn die Credits nicht für diese Message gereicht haben.
Oder A + FFx6 + TimeStamp + die an CUL gesendete Message ohne das "As", wenn die zu sendene Message zu lang war, so dass in CUL der Sende-Umrechnungs-Puffer nicht reicht.

In 00_CUL.pm müsstest Du Dir ggf. noch was ergänzen, um im HM Modul zu erkennen, dass es nur Feedback war und es dann gesendeten Messages zuordnen.

Ebenfalls kommen jetzt A + FFx1 + TimeStamp + Empfangsnachricht.
Und als Antwort auf ein ApYYYYY kommt A + FFx2 + TimeStamp + YYYYY. Auch hier gibt x wieder grob Auskunft über die verfügbaren Credits.

Ich werde Deine 00_CUL.pm testen, danke!

Gruß, Ansgar.

noansi

Hallo Rudolf,

kannst Du Dich denn mit dem Änderungsumfang des letzen PLL Änderungsvorschlags anfreunden?
Und darauf verzichten, dass es mit CUL_V2 läuft?

Wie klein die Patches sein dürfen, ist mir nicht klar. In "3-Zeilern" geht es nur mit sehr wenigen Änderungen.

Gruß, Ansgar.

rudolfkoenig

Zitatkannst Du Dich denn mit dem Änderungsumfang des letzen PLL Änderungsvorschlags anfreunden?
Nein, da ich fuer etwas, was mAn 5+1 Zeile erfordert, nicht 25k an Code einchecken will.


ZitatUnd darauf verzichten, dass es mit CUL_V2 läuft?
Kann dazu wenig sagen, ich weiss nicht wieviele CUL_V2 im Umlauf sind, bzw. wieviele davon fuer HM eingesetzt werden. Ich selbst habe zwar nur V2 in "produktiven" Einsatz, allerdings habe ich meine HM Geraete gegen ZWave ausgetauscht, da HM mir zu kompliziert geworden ist, und ich ZWave testen muss. Die beiden uebriggebliebenen CULs bedienen nur noch SlowRF.

noansi

#29
Hallo Martin,

die lange Pause hat leider etwas Informationsverlust zur Einheit der Timpstamps von 8ms gebracht.

Angehängt die Korrektur von 00_CUL.pm nebst geänderter Erkennung der Timestamp Option zum Test.

Bei mir läuft sie erst mal.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.