J-Log.eu - Forum

FBLs suchen momentan ihr Heil in Goodies, - Datenschnittstellen, Anbinden an Telemetrie und ESC.
Es geht nicht vornehmlich um Effekte für besseres Anwendungserlebnis (interaktiv-textuelle Tele für Setup ausgenommen, momentan nur mit HoTT und JETI möglich).
Es geht um "Glänzen".

Das kann nur schief gehen durch Kollisionen:

1. Jeder will bestimmte Displays exklusiv besetzen, ganz egal, ob er etwas sinnvolles darin mitzuteilen hat. Ein- und dasselbe Display mehrfach nutzen zu können, das wird teilweise gar nicht (HoTT, SPEKTRUM, JR, HiTec, FrSky) unterstützt, - auf jeden Fall treibt diese "Telemetrie-Nutzung aus Marketing-Gründen" jedes System in nullkommanix an seine Limits, jedes!

2. Telemetrie-Interfaces ohne Bus-Eigenschaften führen sofort zum Krieg um EINEN exklusiven Platz, - JETI: an einem nicht-REX sofort (ein Expander ist nur bedingt geeignet), am REX sehr bald, - SPEKTRUM SRXL: instantly.

3. Man will sich mit allem schmücken, SCHMÜCKEN, nicht wirklich nutzen im Sinne des Anwenders => ESC Interfaces: So ein Interface ist immer exklusiv. Das FBL will es haben.

Vor nicht allzu langer Zeit zog die Datentechnik in die Modelle ein.
2010 gab es den ersten ESC mit Datenanbindung, --> erst Logging, dann Alarming, dann sukzessive Telemetrie, angefangen mit Multiplex, JETI v1, ... Wer machte das? JLog (auch Unilog (o.ESC))
Dann kam es sukzessive mächtiger, die Datenwelt in der RC-Welt. Daraus angesagte Veränderungen gab es nicht, wie z.B. weg von single-ended Data Lines, die durch Ground Loops gestört werden (->CANbus).
Kooperation und Integration für Daten-Konsolidierung? Nö.

Jetzt killt sich der Fortschritt über das, was der RC-Herstellerwelt immanent ist: Jeder existiert für sich allein.
Das heißt im Umkehrschluss: Sinnvoll-moderne Produkte im Sinne des Kunden, damit die Kunden an sich, sind uns eigentlich scheißegal. Hauptsache, sie kaufen ihren Crap bei uns.

Unaufhaltsam...

Ein Datenintegrator wie JLog ist damit im falschen Film. Sieben Jahre konnte er noch nützlich existieren im Vakuum, was vor allem er befüllte. Kooperation/Integration gelangen im Wesentlichen nicht, obwohl das eigentlich sein Elixier ist.
Doch jetzt.. Diese Entwicklung, die sich eigentlich gegen die Interessen der Kunden richtet, wird sich nicht aufhalten lassen. Das geht schon deshalb nicht, weil der Großteil der Kunden nicht bereit ist, im Sinne des Großen und Ganzen bewertend zu denken, zu argumentieren (Foren), das Setup seiner Modelle zu gestalten (zu kaufen).

Wer kämpft gern gegen Windmühlenflügel? Ich nicht.
Wer argumentiert gern logisch, wo Logik nicht gefragt ist? Ich nicht.
Ich werde bald eine Entscheidung treffen müssen, fürchte ich, - meiner Logik kann ich mich nicht entziehen.

---------
Falls wer denkt, es ginge hier um JLog-Umsatz. Nein, keine Klagen.
Es geht darum, nicht das zu ignorieren, was die Augen sehen, was das spezialisierte Hirn dahinter eindeutig klassifiziert.

_________________
Tom

Ja, leider hat man wirklich immer mehr das Gefühl, man befindet sich im absolut falschen Film..

Die Kunden werden immer "blinder" - lassen sich von den Herstellern "einlullen" - und kaufen irgendeinen "proprietären Schei**", der mit nichts anderem auf dieser Welt mehr kompatibel ist - und finden es noch richtig toll, dass sie ihm dann auf Gedeih und Verderb ausgeliefert sind..

Eines Tages - und ich hoffe der kommt sehr bald - werden sie aufwachen, und erkennen dass das der falsche Weg war
Oder die Hersteller erkennen, dass man im schrumpfenden Markt zusammenarbeiten muss - statt gegeneinander.
DIe Hoffnung stirbt zuletzt

Dasselbe spielte sich im Bereich der Konsumelektronik ab, nimm mal nur die proprietäre Vielfalt bei den Videoaufzeichnungssystemen, was die Kunden bald frustrierte.
Erst, als es den Herstellern selbst die Beine weg schlug, begann man, sich zu einigen. Das Ergebnis war dann auch mehr state-of-the-art, gemessen an den momentanen technischen Möglichkeiten. Zunächst wird immer nur versucht, mit SEINEM Kram zu obsiegen, Tatsachen des Marktes zu schaffen, wobei machbare Tatsachen der Technik völlig außen vor sind.
Nur, der Markt ist um etliche Zehnerpotenzen größer als der RC Markt.

Wir haben 8 Telemetriesysteme mit wenigstens 10 Protokollen momentan (o.VBC+IISI). Nichts davon ist wirklich state-of-the-art, gar nichts. Lediglich der CANbus in DJI Geräten ist eine Ausnahme, allerdings in der Applikation ebenso proprietär und ohne ein Common Protocol.
Man verhält sich von Anfang an (seit ca. 2009) so, als wäre man eben aus dem 100-jährigen Kryo-Schlaf erwacht, wüsste nicht, was technisch geht und usus ist.
Nicht mal bezüglich der Steckverbinder lässt man Vernunft und Notwendigkeit über historisch entstandene Tatsachen siegen (JR's Erfindung der Servosteckverbindungen). Stattdessen wird ohne Not Gigantomanie betrieben, immer mehr Leistung, höhere Spannung, damit höhere Ströme. Der Anachronismus der RC Stromversorgung wird endgültig wirksam.
Man bleibt auf single-ended Signaltechnik hängen (Signal-Masse), die massig einziehende Datentechnik hat dadurch Datenstraßen mit tiefen Schlaglöchern.

Die Single Line Protokolle tun jetzt dasselbe, proprietär, bis der Arzt kommt. Es werden immer mehr, jeder kocht SEIN Süppchen.

Worauf das immer schneller zu steuert:
- Der Hersteller einer teilnehmenden Komponente hat exponentiell wachsenden Aufwand damit, kompatibel zu sein, die Nutzbarkeit all des proprietären Crap zu gewährleisten,- und dann, vor allem auch, zu erhalten.
- Man hat wohl eines vergessen: Die Anwender, also die Kunden, sind keine Entwicklerkollegen aus der selbst und sinnlos geschaffenen Bastelecke. Sie wollen einfach nur nutzen, und zwar Leistungsmerkmale im Outcome, ansonsten wollen sie eigentlich nur ihr Hobby betreiben, - FLIEGEN, FAHREN, SCHWIMMEN.
- Jetzt allerdings steuert es massiv auf einen Dead Lock zu: Als Erstes wird es den prorietären Telemetriekram in die NoGo-Ecke treiben, und zwar nur, weil da ein paar Leute "Ich auch! Ich viel besser! (Brain Advertizing: "Telemetry is Here")" schreien wollen, - für nix anderes.

Ich kann wahrscheinlich sagen, dass ich als kleine Privatperson die Entwicklung der Technik des RC Marktes weltweit maßgeblich beeinflußt habe.
MSH darf dann stolz sagen, dass sie Auslöser der ersten Stunde waren, und zwar des Kollaps der RC Data Cave Technology. Well done!
Schaut man genauer hin, sieht man den Anlass ganz woanders: VBC. Brain will 1..2 USP's von Mikado kompensieren. Die Lawine kommt in's Rollen, - Spirit will (muss) dann auch usw. usw.
Am Ende wird witzigerweise der Superproprietäre der lachende Außenseiter sein, weil solche Brain-Verbrannten sich selbst in die Ecke trieben, ohne Brain und Verstand.
Auch IISI kann lachen, denn auch sie sind irgendwo zu deren Glück teilweise unabhängig von dem ganzen Müll der sich nicht einigen könnenden sogenannten Etablierten. Etabliert aber unfähig, es kommt nur Cave Technology heraus. (Das hat natürlich auch praktische Gründe, all der technische Crap: Der Markt ist gar nicht so ergiebig, dass ROI selbstverständlich ist.)

Es ist traurig, zu sehen, wie sich das Nicht-System nun in den Dead Lock bewegt.
Man kann aber nur zusehen. Also denn, RC-Kino, - macht mal weiter so!

_________________
Tom

Hi Tom,

ich habe mir erst vor kurzem das S32 gekauft weil ich einfach mal sehen wollte wie das so funktioniert (bin ein Spielkind).
Und was soll ich sagen, ich habe mich noch nie wohler mit einem System gefühlt wie mit diesem.
Dein Service ist mehr als beispiellos.
Ich kann dich auch verstehen wenn du denkst man kämpft gegen Windmühlen.
Und wenn du mal eine Auszeit brauchst, dann nimm sie dir einfach.
Es muss auch nicht alles im leben Logisch sein, wichtig ist doch das man Spaß an der Sache hat.
Aber eins kann ich dir sagen, dein System hat mir bis jetzt viel Spaß bereitet, dafür möchte ich dir danken egal wie du deine Entscheidung treffen wirst.
Ein System zu haben was der Entwickler noch selbst Supported ist eigentlich unbezahlbar!
Und ich denke das sehe ich nicht alleine so!

Gruß
Werner

Ja, danke, Werner!

Ich hab ja noch keine Entscheidung getroffen. Das muss ich gar nicht, der RC-Kindergarten tut es für mich.

Schon bald wird sich der Anwender entscheiden müssen. Er hat 5 Häufchen vor sich liegen, die partout nicht mit gutem Ergebnis zusammen kommen wollen:
- Telemetry Master (Rx), aber auch Single Line Data Transmitter!
- FBL
- ESC
- weitere Sensoren, die er nutzen will
- JLog, der es eigentlich bisher integrierte
Ich hatte das einmal in der Kindheit, nach der Schule im "Planscha", werde ich nie vergessen: Es ging um Fussball: "Wer ist dafür, dass Thomas nicht mitspielt?"
(Der Typ war ein Dummbazi, hatte trotzdem seine Anhänger.)

So what..

----------
Übrigens, es gibt da noch den in RC leider sehr häufig wirkenden "Pfusch-Faktor" on top.
Was ich gerade bei RCH lese über Probleme mit HoTT im textuellen Mode, da das FBL den jetzt benutzt für sein Setup: Andere Busteilnehmer sind nicht mehr erreichbar im Text Mode..
Tja, glasklar ein Implementierungsfehler im FBL. Nicht ohne Grund bekamen HoTT Sensoren dann auch eine dedizierte Adresse für den Text Mode, - die alte globale Adresse wird seitens SJ leider immer noch unterstützt..
Auch der Hersteller, hier Graupner/SJ, hat möglicherweise seinen Anteil daran durch die übliche Dokumentationskatastrophe. Den Deutschen Entwicklern gibt Graupner nach wie vor meine Doku, die ich eigentlich nur mal so machte, auch nicht wirklich professionell in meinem Verständnis, - aber eben verstehbar im Gegensatz zu dem Kram von SJ und Output von Reverse Engineering an eigenen Produkten(!) bei Ur-Graupner. Tja.., ein Entwickler aus CZ wird das schwerlich lesen können, ist nur in Deutsch verfasst..

_________________
Tom

Hi Tom,

ich sehe die jüngsten Entwicklungen beim Brain, aber auch bei den neuen Spektrum Empfängern sowie schon länger bei der VBC auch eher mit Besorgnis als mit reiner Freude über neue Möglichkeiten.

Als Nutzer hätte ich zwar allzugerne ein System, das alle Belange abdeckt, gut aufeinander abstimmt ist und einfach funktioniert. Dafür würde ich ggf. auch einen Vendor-Lock-In akzeptieren. So was hat aber keiner und ein geschlossenes System, dass nur zu 70% passt ist halt nicht attraktiv genug.

Deshalb ist für mich ein J-Log noch auf lange Zeit ein essentieller Bestandteil, um die Telemetrie zu integrieren.

Ich finde es auch ganz gut, dass ich heute einen Stack für die Telemetrie habe (ESC->J-Log->TM1000), der zunächst einmal unabhängig von der Flugsteuerung ist. Die Lösung mit einem S32 als Signalkonverter zwischen RX und FBL finde ich zwar cool, hätte aber doch große Bauchschmerzen, die Flugkontrolle durch den S32 zu leiten. Dazu ist mir mein Telemetriesubsystem dank der hübsch anfälligen Implementierungen schon zu oft ausgefallen (Ich hatte schon die gefürchtete Masseschleife am X-Bus, Timeouts vom ESC [Du erinnerst Dich vielleicht an die Probleme mit dem Mezon], aber auch gerne mal Schwierigkeiten mit dem SD-Karten-Interface).

Ob also Telemetrie im FBL so eine gute Idee ist?! Umgekehrt ist das FBL natürlich ein sehr interessanter Sensor für die Steuerbefehle an Servos, Beschleunigungs- und Drehratenwerte sowie Vibrationsanalyse. Nur dafür hat ja wieder keiner einen Signal-Output...

Also alles Mist und Sackgasse? Nein, es geht ja doch irgendwie voran. Immer mehr ESCs liefern Telemetriedaten, die FBLs kônnen zumindest über ihre eigene Software diverse Daten anzeigen und wenn Empfänger und TM1000 ein Gerät werden, gefällt mir das. Das FBL Setup über die Funke ist auch eine tolle Sache, die ich gerne hätte und bei anderen Systemen verfügbar wäre.

Mit der J-Log Codebase hast Du hier wirklich ein massives Erbe an Know How und konkreten Lösungen aufgebaut. Das merkst Du ja selbst, wenn Entwickler der anderen Firmen gerne bei Dir Know How absaugen möchten Vielleicht ließe sich aus dieser Not ja auch eine Tugend machen und der Integrationscode ließe sich sozusagen lizensieren?

Oder man könnte auch alles in ein Open Source Projekt umwandeln, das dann von den diversen Herstellern co-finanziert wird? Das fände ich persönlich richtig gut.

Oder Du machst den merkwürdigen Wettlauf mit und baust, wie Du ja selbst schon gesagt hast - ich nehme an mehr im Scherz - , eine Kombo aus 3Digi und S32, die dann als Alleinstellugsmerkmal auch die FBL Daten mit loggen/senden könnte. Außerdem könnte das 3Digi vielleicht auch mit den ESC Daten etwas anfangen und diese in die Control-Loops mit einbeziehen bzw. automatisch tunen, o.ä.

Was auch immer Du tust, danke für das bisher geleistete und ich hoffe, Du wirst noch lange dem Hobby wichtige Impulse geben, ohne Dich dabei aber selbst kaputt zu machen.

Alles Feine,
Martin

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

Wenn mir der unprofesssionelle Mist, gern noch vermischt mit aggressivem, verlogenen Marketing, nicht bald über das Limit geht, - dann werden 3Digi und S32 ein Common Data Interface bekommen. So etwas war eigentlich schon vor Jahren geplant, modular, statt ein Ding, zu dem alle Kabel wollen.

Habe vorhin aus Quatsch ein 3Digi mit dem S32 zusammengesteckt, als ESC den RCE-BL130A dran, den ich gerade untersuchte, SPM4649T am S32, SPEK SRXL.
Funktioniert, natürlich. Wegen der Zuverlässigkeit mache ich mir eigentlich keine Sorgen, obwohl ich bei so was immer der Erste bin, der schwitzt.

Das Logging, nämlich das Filesystem auf der SD und die Elektronik der SD selbst, sind das Einzige, was S32 aufhängen könnte, wenn es defekt geht.
Da bin ich aber ganz entspannt, - baue einen Watchdog ein, und nix kann mehr passieren. Der Prozzi im S32 ist mit Abstand das dickste Ding im RC Markt *), mit dessen Ressourcen kann ich Fettlebe machen, einfach alles implementieren.
*) dabei nur 4x4mm, weil gehäuseloser BGA, ein wafer chip

-----
Hättest Du mich fast in's Bockshorn gejagt: SRXL und Remote Receiver sind komplett interrupt-gesteuert. Denen ist eine plötzlich abkackende SD total egal, - sie funktionieren immer, solange keiner mit dem Hammer auf S32 haut oder 200V als Betriebsspannung gibt.

(Apropos 200V: Hatte mich einer auf HF vorgestern gefragt, was der S32 denn aushielte. Wieso wir das nicht spezifizieren. Ich sagte, weil 8,4V eh das Maximum sind, was S32 nicht juckt. Wieso darüber reden, evtl. Leute zum Experimentieren animieren?
Wenn's nun doch ausgeplaudert wurde, warum nur in US? Hab's dann direkt für ihn ausprobiert: Ab 15,5V sinkt die Effizienz des Buck Regulators etwas, 20V sind das theoretische Limit, was ich auch einstellte. Geht. Es gehen noch mehr, aber als Elektroniker und Messie brachte ich es nicht über's Herz, die Kill-Grenze oberhalb 20V zu suchen.)

_________________
Tom

Sag mal, hast Du die kaputte SD noch?

Ich suche eine Laborratte zum Testen des SD Watchdog, den ich eben einbaute.

----
Wg. "Laborratte": Nimm mal bitte das alternative Firmware Repository #1. Dort befindet sich eine Version 1.36. Sie hat diesen Watchdog überall drin, wenn mit der SD rumgemacht wird.
Eine SD Operation wird abgebrochen, wenn sie innerhalb 100ms nicht fertig wird.

Da das Log Recording ganz zeitnah zur Data Acquisition erfolgen soll, befindet es sich mit in der Main Loop. Hängt ein plötzlicher Defekt der SD oder des Filesystems einen Zugriff auf, dann klemmt hier die Main Loop, gewonnene Daten werden nicht mehr ausgewertet, bzw. werden einige erst gar nicht gewonnen (von Data Bus Devices, von ADCs). Alle andere Funktionalität (ESC Interfaces, Telemetrie, GPS etc.) läuft weiter, weil interruptgesteuert.
Durch den Watchdog kann die Main Loop jetzt maximal 100ms aufgehalten werden, und zwar nur einmal, denn dann wird die SD aufgegeben.

_________________
Tom

Zurück zum Topic:

Ich werde ein paar Bildchen malen, um Workarounds für die befürchteten, aufkommenden Probleme aufzuzeigen.

An 3 Stellen geht es nur durch Anwenderentscheidung:

1. Telemetriedisplays, die nur exklusiv verwendbar sind (einmal existieren).

2. Überschreiten von Limits, wie max. 15 "Sensoren" in JETI, max. 15 Sensoradressen in Multiplex, max. 31 nutzbare Time Slots in S.Bus2 usw.

3. Bezüglich des Anschließens des ESC. Ich kann als Entscheidungsgrundlage nur etwas wiederholen, was ich seit 7 Jahren sage, wo jeder weghört, weil ich es nicht einfach genug beschreiben kann: Es ist nicht damit getan, einfach nur Momentanwerte zu erfassen und rauszutun. Der ESC, seine Daten, sind ein Prozess. Deshalb baut JLog darum eine State Machine. Nur so kann er einen Warmstart machen, mAh und Min/Max richtig handeln. Etliche Werte werden integriert, um dann darauf eine sinnvolle Alarmbewertung machen zu können. Integration ist im Effekt zeitabhängig, das schmeißt man nicht mal eben so in ein Gerät, dessen internes Timing für ganz andre Sachen gemacht ist. Zum Strom von einem alten JIVE habe ich ja bereits was gesagt.. Aber auch mit anderen ESCs, fast jedem, bedarf es spezifischen Umgangs damit und mit vielen anderen Werten. Gerade beim Anlauf senden die meisten ESCs mal kurz Mist. Jeder ESC hat somit seine eigene, spezifische State Machine, und oft müssen auch Hazard Filter auf die Daten.

_________________
Tom

Sagen wir mal so, ich habe die SD Karte mit der ich Probleme hatte noch nicht weggeworfen, aber formatiert und seither auch nicht wieder ins J-Log gesteckt. Ich bezweifle allerdings, dass sich allein mit der Karte Fehler gezielt reproduzieren lassen. Ich hatte mehr den Eindruck, dass Karte und -Leser unter härteren Flugbedingungen Probleme bekamen, sei es durch G-Kräfte, Vibrationen oder auch elektromagnetische Felder.

Ich würde Dir die Karte aber überlassen, wenn Du denkst, dass es Dir helfen könnte.

Gruß,
Martin

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