J-Log.eu - Forum

Weiß ich doch, Werner, dass Du das nicht wolltest.
Ich habe nur momentan ziemlich "am Wasser gebaut", stelle wiederholt, und diesmal heftig, mir die Frage nach dem Sinn von RC, weil es nämlich den Sinn meines Lebens tatsächlich entststellt, seit 7J. Machen noch mehr Jahre on top Sinn?

Was schräg sein kann in der Tx Firmware: Andy shared einige Data Items über die Displays, aber teilweise nicht ganz nachvollziehbar. Das Ganze ist "lebendes Stückwerk". Daher ist nicht ausgeschlossen, dass sich die Konfusion in einem Sendermodell anders darstellt als in anderen Sendern.

_________________
Tom

Drehzahlsensor am TM1000 abstecken. Dann gibts keine Mondwerte mehr bei min/max.

Das wäre zu einfach.

Ich habe keinen Drehzahlsensor am TM1000 angeschlossen.
Die Drehzahl bekomme ich vom Regler über das S32.

Schade. Bei mir hat es Wunder gewirkt....
Hängt der Flugakku am TM ? Wenn ja steck auch mal ab.

ja, der hängt wieder dran.
Hatte ich aber auch schon erfolglos probiert mit abklemmen.
Abe wie bereits oben beschrieben, ich habe einfach das Stromfenster im Sender deaktiviert
Der Maxstrom sowie der Alarm ist ja auch noch über das Flugakku Fenster sichtbar.

Für die Buchhaltung: Ich habe das Problem mit den Mondwerten auf dem Current Display jetzt auch und zwar auf einer DX9. Das schlägt anscheinend sogar auf das Flight Pack Display durch (siehe Foto).

S32 vermittelt lediglich zwischen Kosmik und TM1000. An letzterem ist sonst nur der Pluspol des Spannungssensors angeklemmt.

Ich habe das Display jetzt ebenfalls aus der Konfiguration der Funke verbannt.

Ansonsten plagen mich noch sporadische Mondwerte bei der Drehzahl. Wie war da noch der Stand der Dinge, muss man immer noch die Motorpole im Kosmik statt S32 hinterlegen (Kosmik Firmware 4.10)?

Gruß,
Martin

_________________
TDR, Diabolo 550, Protos 500, Trex 250 // BeastX

Damit hast Du unbewusst das Übel an der Wurzel gepackt: Sender. Je mehr Sensor Displays, desto mehr Schei**e macht der Sender.


Nein, man muss nichts exotisches einstellen für S32. Ja, der ESC sendet ab und zu Mist bei der Drehzahl, ansonsten sind es etliche Protokollfehler, die zu immer wieder hohen Latenzen führen. Ich habe bereits Hazard Filter auf allen Werten, es kann aber trotzdem mal was durchrutschen, weil es zu lange anhält.

Aber, Entspannung: Ich habe gerade eine zukünftige Firmware für KOSMIK/JIVEpro getestet, in der all diese schiefen Protokollsachen bereinigt sind.
Müsste also bald was kommen von Sobek.

_________________
Tom

Das nenne ich doch mal gute Nachrichten. Damit hätte man ja dann nur ganz wenige Jahre nach Markteinführung einen nahezu vollständig funktionierenden ESC

Man könnte sich biegen vor Lachen, wenn es nicht alles*) so traurig wäre.

\o/
Martin

*) Meinen ersten hysterischen Lachanfall hatte ich, als mir klar wurde, dass der Kosmik nicht etwa mit der eingebauten USB Schnittstelle an einen Rechner anzuschließen ist, sondern man stattdessen die ProgUnit auf kreative Weise in den Signalweg hängen muss m( Und die Config Software ist auch der absolute Urknall. Zu den Spektrum T Receivern fällt mir aber langsam auch nix mehr ein... </rant>

_________________
TDR, Diabolo 550, Protos 500, Trex 250 // BeastX

Ich habe vergessen, zu erwähnen, dass es erst mal nur den S32 betreffen wird, weil JETI EXbus (TelMe),
- leider immer noch nicht JLog2.5,6, der emuliert ein anderes TelMe, wofür die Firmware im ESC hochgradig buggy ist seit wenigstens 3 Jahren. Das war ja der Grund, mit S32 ein anderes TelMe zu emulieren. Leider war der Outcome auch nicht 100%ig, - aber bald nun.

Einen ROM-residenten Bootloader wollte man nicht verwenden, weil die Firmware verschlüsselt ist, erst im Prozzi entschlüsselt werden soll beim Updaten.
Man schrieb dann aber keinen eigenen Bootloader, sondern die Applikation macht das Kommunizieren beim Update.

USB ist elektrisch angeschlossen, wird aber von der App nicht implementiert. Das erschien wohl zu komplex/aufwändig wg. HID vs... (Driver) usw.
Man verwendet daher simples Asynchron-Seriell (UART), kommuniziert mit dem Updater via USB Serial Converter (VCOM).
Updaten geht in den NAND (Flashen), also page-weise, relevante Ziel Pages müssen zuerst gelöscht werden.
Leider löscht man immer alle Pages zuerst, - bzw. shared der updatende Teil der App dieselbe Page mit übrigem Code.
Wahrscheinlich löscht man einfach alle Pages, denn der ESC verliert bei einem Update immer sein Setup.
Also vermutlich Loader zuvor in RAM kopiert und dort ausgeführt.

Der Outcome ist, dass ein ESC bricked ist, wenn das Update abbricht, - denn der updatende Code-Teil ist dann ja auch weg.

Man hätte nun wenigstens auch die zwei Signale von SWD (ROM-resident) mit auf einen der von außen zugänglichen Pins legen sollen.
Das ist für Flashen mit Factory-Mitteln, - ein User hat ja kein Interface USB zu SWD. Er soll auch nicht das erforderliche Cleartext Image bekommen.
Tat man aber nicht. Ergebnis ist, dass ein gebrickter JIVEpro erst ausgeschmatzt werden muss, um ihm wieder einen Factory Flash zu verpassen, um an die Pins zu kommen. Damit hat man sich aber nur selbst ein ökonomisches Ei gelegt.

Der host-basierte Updater, mit Dot Net gemacht, wurde falsch implementiert, weil er seine Oberfläche nicht updatet, wenn er nicht im Vordergrund ist. VB kann das, nur der Programmierer konnte es nicht. Das kann dazu führen, dass ein User den Updater beendet, bevor der fertig ist, weil der User denkt, der Updater hätte sich aufgehängt. Tat er aber wahrscheinlich nicht. Daher muss man immer die LEDs des USB-Serial-Converters beäugen, ProgDISC oder ProgUNIT (hat die UNIT LEDs, die beim Update zwinkern?).
Insgesamt birgt das Updaten ohne Bootloader immer die Gefahr, dass man den Prozzi bricked. No good.

_________________
Tom

Muhahaaaaha.

Als ich den ganzen Schlamassel gesehen habe, dachte ich nur: Mann, muss die Regelung vom Kosmik gut sein, dass die Leute sich das antun. Und das ist sie in der Tat.

_________________
TDR, Diabolo 550, Protos 500, Trex 250 // BeastX