|
Ubat Anti-Hazard zum Testen (zum Download) auf der HWv4 Manual Page.
Da werden aber vermutlich mehr Hazards sein, - in der operativen Protokollphase zumindest auf RPM.
Außerdem, wenn man LogStop ausschaltet, wird es noch etwas "schweinischer" aussehen.
Ich habe aber beim besten Willen nicht in allen Telemetrie-Kombinationen noch den Platz im flashROM für notwendige Scherze, um den HW-Pfusch zu kompensieren. Will aber einheitlich vorgehen über alle Firmwares, sonst habe ich zuviel Erklärungsnot im Support.
Der Mist hatte mir am WE zwei ungeplante Tage eingetragen, zunächst auf JLog2.x.
Wegen der Hazards und Mode Transistions (idle -> operative), der dabei durch den ESC geschehenen Fehlwertbesetzungen, der Protokollücken, unvollständigen Paketen, sich massiv änderndem Timing im Protokoll, - noch mal zwei Tage on top.
Die absolvierte ich auf dem S32, letztendlich (vor 20 Min) erfolgreich (nach 28h). Der S32 hat aber ausreichend Luft, was JLog2.x nicht hat, - nicht mehr (seit Jahren).
Meine Point Person bei HW war zu den kürzlichen großen Events in CH und NL. Plötzlich kommt er mir damit, dass die User sagen, es wäre eben Schei**e, dass Daten nur kommen, wenn es kommutiert. HW würde was machen wollen. Ich sagte: Good idea but NO GO yet! First let's finish everything and deploy it, afterwards it can be a topic if I find the time for.
Tja, sie hörten nicht. Ich ging zwar hoch wie ein HB-Männchen, moderierte mich dann sogar selbst, aber seit Samstag durfte ich feststellen: Du hättest nicht mit Steinen schmeißen sollen, sondern mit dem Leo vorfahren. Dieser Wechsel zwischen nun auch operativen Daten im Idle Mode (kein Kommutieren) und dem (unveränderten) operativen Mode (es kommutiert), - wurde einfach ohne Rücksicht auf Verluste implementiert, - zumal es kein CRC gibt. On top ändert sich das Timing (Datenfrequenz) dabei, on top bricht der ESC einfach irgendwo mitten im Satz ab, um dann nach unterschiedlich großer Protokollpause rein operative Daten mit viermal höherer Datenfrequenz zu senden. On top schickt er dabei stochastisch erst mal fehlerhafte Daten, - on top hat er Hazards in den RPM-Daten.
Man kann alles heilen, - wenn man die Zeit und die Nerven für einen komplexen Filter hat, - aber dann nur, wenn man auch genügend Luft im Speicher des Prozzi hat. Beim S32 schon (wenn auch der Aufwand nervig/ärgerlich war), beim JLog2.x stand die ganze Sache eh prinzipiell in den Sternen wegen ROM-Mangel, doch jetzt überschreitet es die kritische Grenze endgültig. Ich hatte am vergangenen WE bereits 48h u.a. gegen fehlenden Platz im Speicher gekämpft.
Summasummarum: Mit dieser plötzlichen und in der Ausführung unabgesprochenen Änderung im Protokoll (idle+operative/operative) hat mir HW, wie befürchtet, ein heftiges Ei gelegt.
Ich hab's angefangen, ich muss da durch.. Im Prinzip ist es geschafft, - muss "nur" noch mal ALLE Firmwares neu machen und deployen.
Besser wäre, erst alle Prinzipien an allen ESC's zu testen. Zu befürchten sind Hazards in RPM (mit dem S32 last minute festgestellt, dann weggefiltert).
Das Spannungsproblem ist offenbar gelöst.
Bleibt noch das initiale Fragezeichen um den Strom. Sieht aber aufgrund Eurer Mithilfe inzw. so aus, als sollte ich meine Stromkorrektur untenrum drin lassen (ohne, geht es erst bei ca. 10A los), als wäre der Output insoweit verwendbar. Natürlich muss man jeweils mit ImotShunt nachhelfen. Die Strommessung in den HW's ist kein Genauigkeitswunder, und Exemplarstreuungen scheint es auch zu geben.
_________________
Tom
|
Anmelden
Registrieren
FAQ
Suche
