J-Log.eu - Forum

Meine Antwort war falsch.

Es geht ja nicht, anhand der Spannung zu beurteilen, ob sich die Quelle generell umschaltete (->Backup) bzw. die Main Source (BEC) gerade ausfiel.
Wenn es die Alarmschwelle im Terminal auf den übertragenen Wert bemerkt, ist es bereits etwas zu spät.

Daher braucht es einen Alarm, der an der Quelle entsteht und zum Terminal übertragen wird, - eine Zustandsmeldung, nicht, dass das Terminal diesen Zustand selbst ermittelt, was es hier nicht rechtzeitig kann.

_________________
Tom

Ah verstehe,
damit meinst du es erfolgt bereits ein Alarm bevor es zum Kollaps kommt.
Wenn die Caps 3000ms Puffern bevor ein Alarm ausgegeben wird, kann evtl. die Spannung am RX deutlich unter der 0,3V Spannungshysterese im Sender liegen.
Ist dies der Fall, spricht der Sender Alarm wieder vor dem Caps Alarm an.
Müsste man prüfen welcher Alarm zuerst kommt.
Aber prinzipiell eine gute Idee!!

Gruß
Werner

Ja, müsste man. Einen Dip nach unten wird es bald geben, was man im Sender selbst detektieren kann.

Beim UltraGuard machen wir es ja deshalb so, dass der immer 0,5V unterhalb der gesehenen nominalen BEC Spg. erscheint. Damit hat die Alarmschwelle im Sender eine bessere Chance, es sofort zu bemerken.

Ich werde die Firmware des S32 noch mal anpassen, so, dass es bereits nach 750ms meldet.
Linus und ich hatten endlich ein paar Minuten Zeit, darüber zu quatschen aus Sicht beider Devices, - nachts an Linus's Küchentisch.

_________________
Tom

Wieder zu faul.. https://www.helifreak.com/7473879-post53.html

_________________
Tom

Updates. Bin mal wieder zu faul..

https://www.helifreak.com/7488054-post54.html

...Oh man... Die html Welt konvertiert zu Schei**e..

_________________
Tom

Das erklärt natürlich den Sinn des neuen Protokolls ein wenig - bin schon "curios"

Unabhängig von mehr Potential eines vom ESC-Hersteller gewählten Protokolls, z.B. auch für Setup:

Eine Tele schreibt den Wortschatz vor. Das kann nie vollständig zu den Bedürfnissen des Gerätes passen, was etwas zu sagen hat, hier ein ESC.
Was nutzt es, wenn man sagen kann "ich hab Hunger", aber man isst gar nicht, aber "ich muss kacken" nicht gesagt werden kann, obwohl die Düse drücken könnte.

Für 3rd Party ist so was eh besser, statt von hinten durch die Brust ein in einer Steinzeithöhle entworfenes Tele-Protokoll verwenden zu müssen.
Skorpion Tribunus, auch YGE, und andere ESC tun teilweise dasselbe, - eigenes plus "erzwungenes", - wobei ich immer noch dabei bleibe, dass ein einheitlicher Konverter wie JLog die effizienteste Lösung ist.
Nun ja... JLog hat die "Welt" umgekrempelt, nun will (und "muss") man ihn eliminieren, - aus vorgeblichen Preisgründen (wer's glaubt..), vor allem, weil diese unökonomischen Fertigunsginseln des RC sich immer noch komplett einzäunen müssen. Schön blöd.. Hintenrum passiert teilweise schon was, aber nicht konsequent genug. Was von diesem Kram R2 inzw. alles baut, ohne, dass die Welt es wissen muss.. Mir ist das aber herzlich egal. So, z.B., helfe ich eben Tomáš von Spirit, damit ich hinterher "JLog schmähende" Sprüche von Usern lesen kann.

_________________
Tom

Nach den "philosophischen Ergüssen" noch was technisches:

Es wird bald (k.A., wann) eine neue Firmware kommen für KOSMIK + JIVEpro, dann wahrscheinlich auch ein weiterer ESC.

JLog3 (S32): Der ist einfach adaptiv. Er kann mit der jetzigen TelMe-Implementierung und der dann neuen, - bemerkt den Unterschied und passt sich an. Dem User kann das egal sein, nur, dass er plötzlich auch "Gas" und "Timing" bekommt, - und, dass S32 via JETI Tele noch mehr "operativ" im Setup ist. Angebotene Displays sind nun vollständig vom Setup seitens ESC-Typ und von dessen Firmware bestimmt, ebenso seitens weiterer Sensorik an S32. (das geht nur mit JETI Tele, EX oder EXbus)

S32 kann außerdem auch das neue Datenprotokoll "Kontronik TelMe" (oder andersrum, oder Schokoweihnachtsmann). Das ist für JLog3 und vermutlich weitere 3rd Party, - keine "offizielle Tele" für irgendein FS-System.
S32 sollte dann immer via dieses Interface an K ESC's verwendet werden, weil es dadurch mehr Daten bekommt, und mit höherer Update Rate.
Das "Mehr" an Daten erscheint sichtbar im Augenblick nur in dieser einen Zeile im Log, wo die ESC FW Version steht. Außerdem dient es automatischer Anpassung: Egal, ob ich KOSMIK(KT) oder JIVepro(KT) oder KOLIBRI oder KONTROL-X einstelle. S32 spricht KT Protokoll, erfährt den wahren ESC Typ und Subtyp, stellt sich darauf ein. So kann es also passieren, dass im Setup "Kontronik KOSMIK(KT)" steht, aber im Log Erkennen als "Kontronik JIVEpro(KT)", und JLog die Daten entsprechend behandelt.

Nun wird auch endlich das TelMe gefixt, was JLog 2.x darstellt. Das wird wahrscheinlich in derselben Firmware enthalten sein.
Ich forderte "Gas" und "Timing" on top, - bekam es mit TelMe JETI.
Wenn das nun auch im TelMe für JLog2.x erscheint, statt ausschließlich überfälliges Bugfixing zu betreiben, - dann habe ich mir (Euch) damit in's Knie geschossen:
- Muss alle JLog2.x Firmware Images für KOSMIK/JIVEpro modifizieren, re-deployen.
- Trotzdem wird es dann noch etliche Supportfälle geben, wo der Anwender aus dem Muspott kommt, die auf JLog2.x geflashte Firmware nicht zur neuen ESC Firmware passt.
JLog2.x kann hier wahrscheinlich nicht adaptiv gemacht werden wie JLog3. Es fehlt einfach (seit Langem, daher so viele Firmware Images) der Platz im Programmspeicher dafür.
Nun muss ich mich entscheiden zwischen "Fortschritt" mit Mehrarbeit bei keine Zeit und "Maschinenstürmer". Der Kollege bei K würde vermutlich meinem Wunsch entsprechen, zumal dieses Tele-Protokoll längst sehr selten verwendet wird, also mit echtem TelMe ohne JLog.

_________________
Tom

Habe mich entschieden, kein "Maschinenstürmer" zu sein. Für JLog2.x wird es dann also endlich nicht nur "reibungslos" gehen mit KOSMIK, JPro, weil die Bugs im ESC endlich gefixt sind, sondern er wird auch "Gas" und "Timing" anbieten können, sowie "Ubec" (während er zusätzliches "Ibat" erst mal nur "bunkert", weil er es längst selbst errechnet aus Imot und PWM).

Es gibt auch einen praktischen Grund: Seit ESC Firmware 4.6/1.6, als die Bugs losgingen, ist so viel Zeit geflossen, Mods/Adds in die JLog Software gekommen.. Es ist somit "effizienter", massig Firmwares zu backen, als stundenlang vergleichend durch Source Code zu hirschen.
Außerdem, wie ich heute merkte, braucht es mal ein Refresh des JLog2.x-Fummlers bzgl. der Tools, als wie icke.

Das "KT" wurde nun doch erneuert, dabei verschlankt. Habe es bereits in S32 angepasst, werde es testen/debuggen, sobald ich die neue (interne) Fw von K habe.
Tja, wenn man erst eine riesige "Meckerliste" abliefert, erst danach implementiert und sagt, ignoriere mein Meckern, funktioniert ja trotzdem, - dann muss man die Suppe auslöffeln, die man selbst austeilte. Sowas kommt von sowas, konkret, wenn mein Dev-Partner meine Mails sequentiell abarbeitet.

Ich weiß nun auch, was KONTROL-X ist (hatte ich verdrängt, dieses kleine Ding für Multikopter), und ich weiß, inwieweit sich KOLIBRI und KONTROL-X von den anderen beiden (bekannten) unterscheiden, - KOSMIK und JIVEpro, jeweils mit dem Zusatz "(KT)", weil über anderes Datenprotokoll. Nachdem ich gestern die ESC-Übersicht im S32terminal aufbohrte, kann/muss ich sie jetzt ergänzen. (Bin ja mal gespannt, wer in seinem Multi-Quirl mit JLog3 rumfliegt. )

-------
Ja, "KT" ist für 3rd Party. Also werden die Gehirn-Jungs und mein Namensvetter von Spirit es sicher bald benutzen.

So, erst mal Sendepause dazu, kommt ja bald offiziell von K. Damit habt Ihr wenigstens die Background-Info zum Update, die vielleicht so gar nicht ausgeschenkt werden wird, weil eigentlich nicht erforderlich.

_________________
Tom