Also entweder bin ich übermüdet, oder ich bin Dir intellektuell nicht gewachsen...
Ich frage mich: Wat will der Typ?
"Konsolidieren"? Das könnte zwei Stoßrichtungen haben, oder eben beide..
- Zwei Devices, alles in ein Log.
- Was das eine Device säuselt, gibt das andere als Telemetrie-Gateway weiter.
Beides ist nicht prinzipiell unmöglich, beides hat seine Pferdefüßchen, gerade bei den Telemetrien, - man kann nun mal nicht zwei volle 10l-Eimer in einen dritten 10l-Eimer kippen, ohne, dass was dabei abhanden kommt. "Eimer" steht für Display Items im Telemetrie-Terminal, i.Allg. der Sender.
Denke mal, Du willst am liebsten und ganz bescheiden beides, Log und Telemetrie konsolidiert, oder?
Na ja, mal prinzipiell: Wer würde schon durch sein Betriebssystem reiten, um überall "Windoofs" durch "Schokoweihnachtsmann" zu ersetzen, wohl wissend, dass das mit dem nächsten OS Update wieder weg wäre. Will sagen: Es tendiert dazu, ein Kampf gegen Windmühlenflügel zu werden, wenn man die Daten eines Fremdgerätes erhaschen und interpretieren will.
Eigentlich sollten beide Geräte getrennt ihren Job machen. Was die Telemetrie betrifft, sollte man es gleich dabei belassen.
Spricht man nun vom On-Top-Logging der Daten eines Fremdgerätes, landet man bei dem Problem, dass Interfaces fehlen, wenn man so was nicht von Hause aus auf dem Radar hatte. Ich muss z.B. die Telemetrie des Gerätes empfangen, dessen Daten ich in mein Log integrieren will, ergo brauche ich ein exklusives Interface dafür. Dasselbe für das serielle Protokoll, mit dem SM GPS-Logger und Unilog koppeln kann.
Nun.., weder JLog2 hat ein Interface dafür frei, sofern er parallel potentiell alle Telemetrien bedienen soll, wenn auch nur mit seinen eigenen Daten, noch hat ein anderes SM Device das (Oder doch? s.o.). Was ginge, wäre Sniffering auf allen 1-Wire Bussen (MPX, HoTT, S.BUS2, JETI, JR, - mit SPEKTRUM, HiTec gäbe es etwas Trauer ohne große Klimmzüge), - gleichzeitig die Telemetrie von beiden Devices (getrennt) zu haben, erfordert aber, dass beide auch das gesamte Spektrum abdecken. Nur so könnte man ohne ein zusätzliches Interface auskommen. JLog2 und SM-Geräte tun das bereits, aber bisher nur auf dem MSB (Multiplex). JLog2 konnte zusätzlich als Busmaster agieren für den Fall, dass man gar keine MPX-Telemetrie verwendet, aber die Daten des SM-Gerätes in JLog's Log haben will. Allerdings habe ich solche Spezialfunktionen bisher nicht von der 3.2.2 in die 4.0.0 übernommen.
Last but not least: JLog3 wird die Hardware hierfür haben, dann auch Telemetrie-Gateway-Funktion (ähnlich) in seiner Software. Anders gesagt: Eigentlich ist es höchst uneffektiv, mit Einschränkungen bzgl. der Konstellation (Telemetrietyp) versehen, und irgendwie aus zeitlichen Gründen nicht ratsam, das mit der Brechstange und JLog2, wieder in's Auge zu fassen.