J-Log.eu - Forum

Hi Tom, Dir natürlich auch ein frohes neues Jahr !

Der Workaround hört sich gut an. Für die Leistung dann ggff. auch, denn die ist beim Anlauf teils auch enorm

Viele Grüße,
Dirk

P=U*I, ist also automatisch geheilt.

_________________
Tom

Guck mal:

pwm reicht also nicht, muss eine Kombi mir rpm nehmen bzw. besser throttle nehmen, denn rpm reisst auch immer aus beim Anlauf, - quite normal.
Kann auch ein zeitliches Auseinanderfallen des Updatens der Werte sein.
Ist immer haarig, einen Führungswert zum Heilen zu finden. Das Problem ist hier aber ein ganz anderes: Es sind zwei Protokolle, sobald das Kommutieren beginnt, schaltet es um. Dabei passiert immer wieder mal Mist seitens ESC. Also muss ich mit Hazard-Filter an. Hazard-Filter haben nur die unangenehme Eigenschaft, natürlich das Data Update zu verzögern.

_________________
Tom

Hi Tom,

Lösung dann in FW 1.23 ?

Grüsse,
Dirk

Ehrlich gesagt, k.A... Der Hazard Filter hat nur eine Tiefe von Eins. Je tiefer, desto geringer die Update Rate. Die ist sowieso schon bescheidener als mit JLog2.x, weil dieses "TelMe" ein "Wasserkopfprotokoll" verwendet, - viel Redundanz, wenig echter Payload, - on top hat die Protokollimplementierung Flaws.
Der H-Filter wirkt jetzt ganzheitlich auf alle Werte, "ohne Ansehen der Person".

Eigentlich hätte es nicht passieren sollen, denn bis PWM 20% machte ich künstlich dicht. Ist mir noch etwas mystisch...

Der Hazard Filter blieb nur aus Vorsicht und Messietum, nachdem er dann lief.
Der Anlass meines erneuten Anfassen der KOSMIK/Jpro-Routine war ein Kalifornier, dessen KOSMIK lt. Logs (S32) verdammt lange Datenprotokollpausen einlegt, stochastisch.
Das Timeout bis Wertung als "ESC verloren" hatte ich ja bereits wg. eines spinnenden Jpro hier im Forum von 800ms auf 1500ms erhöht. Nun auf 4000, - mal sehen...

_________________
Tom