J-Log.eu - Forum

JLF ------ SPAM Bots! Bitte nach Registrierung eine Email an mich zur Freischaltung! / After registration drop me an email please for clearing! ===Nenne/name the NICK you used to register with!=== Email address: -> http://j-log.eu/impressum
Aktuelle Zeit: 13. Mär 2020, 04:50

Alle Zeiten sind UTC + 1 Stunde




   [ 34 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4
Autor Nachricht
 Betreff des Beitrags: Re: JLog2 & FX-32
Verfasst: 21. Jul 2013, 23:30 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Zitat:
frage:
1 wirst du den neuen stromsensor einbinden dann könnte man die m amp direkt von sender ablesen?
(seit dem neuen update ist der nämlich drin.)

Ooch, Leute.., - warum lest Ihr eigentlich nie in anderen Threads?

Die Frage habe ich schon x-mal beantwortet: Jein. Ich würde die Leute mit T-Box in den Regen stellen, - und auf noch mehr Firmwares habt weder Ihr noch ich Bock.

_________________
Tom


Nach oben
   
 
 Betreff des Beitrags: Re: JLog2 & FX-32
Verfasst: 22. Jul 2013, 07:43 

Registriert: 8. Jun 2011, 22:36
Beiträge: 302
Good News!!

DANKE Tom & DANKE Klaus!

Auch wenn die Hauptsache natürlich ist, dass es jetzt funktioniert - was war denn eigentlich der Grund? Was ist da anders bei der FX-32?

Grüße
Thomas


Nach oben
   
 
 Betreff des Beitrags: Re: JLog2 & FX-32
Verfasst: 22. Jul 2013, 08:44 

Registriert: 20. Jun 2011, 12:37
Beiträge: 114
Ich vermute Tom wüsste viel lieber WARUM es mal wieder anders ist... Von wegen Kreativität in der Entwicklung und so


Nach oben
   
 
 Betreff des Beitrags: Re: JLog2 & FX-32
Verfasst: 22. Jul 2013, 09:05 
The Madman from Laboratory 4

Registriert: 8. Jun 2011, 14:28
Beiträge: 4760
Es ist immer alles "anders", offenbar Dank eines einzelnen Herrn in Nippon, mein professioneller Freund..

"Konsistenz" scheint ein Fremdwort zu sein, ob es nun die Senderfirmware betrifft bzgl. Telemetrie oder Firmware für Empfänger.

Hier: Das Registrierungsprotokoll hat ja eigentlich nichts mit dem operativen Protokoll des S.BUS2 zu tun. Bisher sinnloserweise sieht das Protokoll 10 Bytes Data Payload vor, die aber lt. Protokollbeschreibung bis jetzt keinen effektiven Zweck haben.

Nun.., und da mir das ganze Protokoll und der Stil der Umsetzung von Anfang an suspekt ist, leider zurecht, wie sich seit April vorigen Jahres immer wieder bestätigte, - gehe ich bzgl. solcher undokumentierten Elemente so ran, dass ich mich an der Praxis vorhandener Geräte orientiere, also an dem, was mir mein LA auf dem Bus zeigt. Mein bisheriger Input stammte von T18MZ, Robbe T-Box und T14SG. Zufällige Konsistenz , alle diese Terminals besetzen den bzgl. seines Verwendungszwecks undokumentierten "Payload" mit Null. Folglich habe ich meinen Sensor darauf checken lassen, dass diese 10 Bytes Null sind, bevor ich ein Paket akzeptiere.
Bingo, die FW der FX-32 besetzt zwei Bytes davon in einem bestimmten Kommando mit Daten, die lt. Protokoll keinen Verwendungszweck haben. Ergo schluckte JLog das Kommandopaket nicht und blieb eine erwartete Antwort schuldig.
(Wen wundert's? Auch die Kommandosequenz ist anders, als bisher gesehen.)

Ich halte das Protokoll insgesamt für eine aufgeblasene Angelegentheit, die an der Praxis vorbei geht. Perverserweise hat man parallel praktische Aspekte einer Telemetrie, die ihre Nutzbarkeit ausmachen, völlig ignoriert, ich meine vor allem dieses Unding, das die Dateninterpretation allein Sache des Terminals ist, - konsequenterweise beschreibt das Protokoll auch nirgends, wie die vom Sensor in einen Time Slot gepackten Daten denn nun interpretiert werden. Um das zu erfahren, muss man Lotto spielen..

Viel schlimmer ist diese "kreative Freiheit", die der Designer nun auch noch zunehmend entwickelt. Ich meine, dass das Terminal in einem Display nicht mal mehr proportional zu den Daten darstellt, die ein Sensor auf den Bus packt, - man macht also eine Gleichung mit zwei Unbekannten draus. Wo gibt's denn so was?! Alarme durch Sensoren gibt es nicht, damit kein state-sensitives Agieren eines Sensors möglich. Gleichzeitig ist das Alarm-Setup des Terminals so schräg, dass man durch Nulldaten nervige Zombie-Alarme bekommt. OK, Workarounds sind möglich, macht JLog auf Userwunsch auch, also z.B., dass ein Alarm nur durch Negieren des Wertes (Unterschreiten von Null im Terminal) ausgelöst wird. Sieht zwar komisch aus, plötzlich eine negative Spannung zu haben, ermöglicht aber, den Sensor den Alarm auslösen zu lassen, denn der kennt den Status des Datengebers (ESC hier), weiß, dass bei PWM oder Throttle <x eine Alarmgabe ungewollt sein wird, z.B.

Nun greift man hier auch noch ein seitens des Systemanbieters, sozusagen im Sinne der Maximierung des Hindernislaufes:

Als sich herausstellte, dass die Robbe T-Box GPS-Distanz plötzlich selbst berechnet, statt den Wert vom Sensor (GPS) zu nehmen, wie es die T18MZ zum damaligen Zeitpunkt machte, - dachte ich noch "schlecht" vom (deutschen) Designer der T-Box.

Inzwischen ist aber klar, das hat "System", kommt vom Entwickler aus Nippon. Die T14SG und die FX-32 machen dasselbe, - offenbar nur zu dem Zweck, einstellen zu können, ob die Distanz sich in Luftlinie zum Modell berechnet (So muss es für JLog eingestellt werden!), oder als lotrechte Projizierung des Modellstandortes auf den Grund. (Warum nicht auf den Mond? )

Noch schlimmer ist, dass nun auch noch (zumindest die T14SG) alle Displays "Höhe" (in VARIO oder GPS) im Terminal eigenständig (Eigenmächtig!) genullt werden: Das Terminal nimmt den Höhenwert als Null-Referenz, den es beim Einschalten sieht (Einschalten des Senders). Das ist ein absolutes Unding!! Schaltet man bei laufendem Sensor (hier JLog) den Sender noch mal aus/an, kommt nur noch Grütze raus in den betreffenden Displays, betrifft momentan Imot, Ubat, ext.RPM, mAh, RPM-Rotor.
Besonders "freundlich" finde ich das, da man doch weiß, dass 3rd-Parties solche Displays (Sensoren) vergewaltigen müssen, - da Futaba ja mit diesem unsäglichen Design selbst dafür gesorgt hat, dass nur sie die Displays/Dateninterpretation implementieren können, da sie damit aber nicht aus dem Knick kommen.

Um ehrlich zu sein, ich war schon ein paarmal drauf und dran, die Futaba-Telemetrie aus JLog zu entfernen. Aufwand und Ärger stehen in einem krassen Mißverhältnis zum Nutzen.

Meine Hoffnung richtet sich nun auf den von mir Futaba vorgeschlagenen Sensor "ESC+" in der Senderfirmware. Außerdem schlug ich vor, dass/wie man ein Futaba/Robbe-Terminal für den Sensor konfigurierbar gestalten kann seitens der Dateninterpretation und -darstellung, also á la JETI EX. Dann muss man aber damit aufhören, dem Sender ein Eigenleben einzuhauchen, was aber momentan eher am Zunehmen ist! (Man stelle sich vor: Ich habe einen elektronischen Meßschieber. Der aber zeigt mir nicht den zu messenden Wert an, sondern irgendeine Hausnummer, die er gemäß der ihm eingehauchten gottgleichen Weisheit geneigt ist, zur Anzeige zur bringen. Irrenhaus..)

Die Hoffnung stirbt zuletzt...

(Musste mal raus, sorry.)

P.S. Das ist Futaba, nicht Robbe! Obwohl es Robbe natürlich nicht gefallen wird, wenn ich so was äußere, es betrifft ja ihr Geschäft. Robbe ist wirklich bemüht, bestes Zeichen ist die Eigeninitiative "T-Box".
Es wird werden, davon war ich immer überzeugt, nur wird es vermutlich weiterhin ab und an unnötig viel Nerven und Nacharbeit kosten.

_________________
Tom


Nach oben
   
 
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
   [ 34 Beiträge ]  Gehe zu Seite Vorherige  1, 2, 3, 4

Alle Zeiten sind UTC + 1 Stunde


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de