J-Log.eu - Forum

(Wochenendphilosophieren )

Das wird allenthalben vorgeschlagen.

Ich will hier nicht über die ökonomische Sinnfälligkeit des Entwicklungsaufwandes reden (die war eh nie gegeben), - sondern nur den techn. Aspekt ansprechen.

Natürlich ginge das im Prinzip, ob nun mit zwei Prozessoren oder in einem. Platz auf dem PCB des 3Digi wäre genügend. Das Package der 3Digi MCU ist unnötig groß, das der in S32 die kleinstmögliche Form. Allerdings ist es auch im momentanen 3Digi unnötig, ein kleineres Package zu wählen. Da liegt der Hase im Pfeffer:
Wie bei S32 machen bei 3Digi die Konnektoren und der SD Slot den Platzbedarf aus. Es wird ja bereits heute gemeckert, dass 3Digi kleiner sein sollte für kleine Helis.

Tja.., Physik. Die sagt: "Wo ein Körper ist, kann kein anderer sein."
Nutzbare Flächen sind bereits beim heutigen 3Digi vollständig ausgenutzt. (Man könnte höchstens noch durch eine Huckepackplatine Konnektoren stapeln. Handarbeit..) Eine Fläche ist tabu, die Montageseite. Über Servosteckverbinder oben, - vergleichsweise monströs platzgreifend, benötigen auch extra Gaps, damit die Stecker nicht kuscheln, - meckern eh Viele, obwohl es mMn sehr sinnvoll ist, sie auf die Top Side zu tun. Weitere Konnektoren, wenn S32 funktionell integriert, könnten höchsten hier untergebracht werden, - sogar schon "trickhaft", weil die Fläche des PCB darunter nicht mehr für Komponenten z.V. stünde. (oder eben auf Piggyback PCB, wie erwähnt)

Alternative wäre höchstens (3Digi könnte deutlich kleiner werden, auch mit S32 darinnen), das zu tun, was Captron damals mit dem Helicommand praktizierte: Interfaces abgesetzt auf ein extra Device. Hah! Ich höre schon förmlich die Meckerer darüber. -- Das wäre dann eigentlich state-of-the-art, z.B. ein CANbus, an dem ein oder mehrere Interface-Einheiten hängen, weil ja die zu konnektierenden Fremdeinheiten (ESC, Telemetrie/Rx) zwangsläufig monströse Old-Fassion-Konnektoren verwenden müssen. Außerdem haben wir auch eigene Sensoren der "Sensor Fusion", Temperaturen, Drehzahl, Spannungen, CVS, HVBEC, BID, GPS, Magnetfeldsensor (beide besser abzusetzen, Drucksensor in der Main Unit) - und bald auch ein Wireless Interface für Setup/Datenauswertung. Die muss man dislozieren, und NICHT in eine Unit packen wollen! (Brain kann machen, was sie wollen.. Ich vermisse dort eigentlich "Brain"..) Es ist eh sinnvoll,
a) die Komponenten im Modell nach Gegebenheiten an geeigneten Stellen platzieren zu können,
b) dabei den längst technisch ungeeigneten Schei.. mit Single Ended (-> Ground Loops!) wenigstens bis zur Peripherie der Fremdeinheiten abschütteln zu können. (CANbus ist Differential Ended)
(Es macht eh grundsätzlich keinen Sinn (mMn), wenn alle Strippen an einen Platz wollen.)

Jetzt die "Philosophie", gewissermaßen etablierter Pessimismus gegenüber dem R/C Markt

Nun käme eben nur, wie immer, die "ungeliebte Masse technisch nicht fundierter Meinungen" (und deren Äußerung in Foren -> Meinungsmache unter Laien)... Es ist nun mal so: Der Kunde ist König, auch diese Sorte "Kunde". Sein Geld soll vorfinanzierten Aufwand wenigstens decken. Bingo!

Meine momentane Conclusion nach "schnellem Nachdenken" darüber endet daher wieder an der "Common Crux of R/C": Der Kunde steht Fortschritt zu seinem Vorteil meist selbst im Weg. Nicht Leistungsmerkmale entscheiden, - sondern ein "schlauer" Anbieter in diesem Markt handelt am besten über den Preis (schließt automatisch teure Entwicklung aus) und über die Erkenntnis - der Käufer will nicht wissen, er weiß eh alles besser und verbreitet sein "Wissen", er will quasi "verarscht" werden, daher tut man das besser.
Ich will Euch nicht beleidigen! Ich bin nur Realist.
(Der "Markt" reguliert, also das Käuferverhalten. Der Mitbewerb passt sich an, ergo muss man selbst auch, es soll ja Geschäft sein. Nur Verrückte wie R2, Tom und ein paar andere haben einen ulkigen nichtkommerziellen Antrieb, ersetzten aktives Hobby durch Support dessen, quasi "Ersatzbefriedigung" )

Alles bleibt beim Alten, - irgendwann entwickelt es sich doch, nur immer später als nötig. Die 7 Jahre Praxis mit JLog haben es doch gezeigt. Erst jetzt wacht es auf, - ESC Data Interface ist inzw. ein MUSS, - und FBL versuchen, JLog zu "assimilieren". Nur leider wird das im Gegenteil enden: Zumeist technisch schwache Telemetrie wird verbraten "aus Marketinggründen". Nur einer lacht dann: Uli mit autonomem VBC. -- Ich spinne? Dann schaut doch mal, was mit Logging passierte. Alle Sender-Hersteller stürzten sich darauf. Alle Anwender finden es geil. Hat je jemand nach der Sinnfälligkeit für Forensik gefragt? Die wird zumindest durch Latenzen/Nicht-Echtzeit und Fehlerwahrscheinlichkeit der Übertragung negiert. Ist doch egal: Beim JLog war dessen Log für mich auch nur bunte Tapete, also, wo ist der Unterschied zum Logging im Sender? Dieses mein Geseier nur, um zu versuchen, klar zu stellen, was ich meine mit "Kunde steht sich selbst im Wege" und "Wer verarscht werden will, wird es".

Es wäre die 100ste Wiederholung: Ich habe momentan eigentlich eh keine Zeit für den Topic.
Jedoch: Zurücklehnen und abwarten, bis selbst der RC-Kunde geschnallt hat, was für seine Modelle besser wäre, - dann kann man es immer noch machen.

(Die Alternative, S32 einfach nur per Bus mit 3Digi zu "vereinen", - wird sicherlich auch genügend Kritiker finden, zumindest über den Gesamtpreis.)

_________________
Tom