Flugschnecke
User
Hat geklappt. Man benutzt ja gar nicht die serielle Schnittstelle, sondern das Adapterkabel des Graupner Interfaces, welches sich wieder eingefunden hat. Jetzt muß ich nur noch rausfinden, wie das in der MZ24 pro funktioniert...
UniSens-E von SM-Modellbau
- Ersteller TiKli
- Erstellt am
Reinhardt Werbik
User
Du musst auch die App IDs eindeutig machen, mit der 1.21 Firmware kann man dazu einen Offset definieren, der auf alle App IDs drauf addiert wird.
Reinhardt Werbik
User
Sehr hilfreich.
Reinhardt Werbik
User
Die Lösung besteht darin, erst mal alle IDs, auch die App IDs eindeutig zu machen. Wenn dann immer noch Sensor Conflict Warnungen kommen, kann man die Warnung ggf. abschalten. Sie sollten aber dann, wenn überhaupt, nur noch sehr selten kommen.
Es gibt in Ethos auch die Möglichkeit die Sensorwarnungen generell zu unterdrücken. Dann muß man nicht mehr mühsam nach jedem update die Datei wieder herauslöschen.
Und was Bertrand angeht: der hat da schon seine Möglichkeiten ausgeschöpft bei der Ethos Programmierung. Jetzt sind die Entwickler der HF Firmware gefragt, da liegt nämlich der Hase im Pfeffer. Die kommen vor lauter neuen Protokollen gar nicht mehr dazu eines mal vollständig fehlerfrei zu machen.
danke für Eure Hilfe
ich habe die App ID einfach irgendwie verändert, es geht noch und die Meldungen sind weg
Ich finde die ganzen Anleitungen zu HW ID und App ID auch irgendwie echt gruselig. Ich meinte verstanden zu haben, dass die HW/Sensor ID den Sensor identifiziert und die AppID den Typ Daten, der geliefert wird und das eigentlich nur die SensorID passen muss.
Whatever, es lüppt jetzt ....
Danke Euch
ich habe die App ID einfach irgendwie verändert, es geht noch und die Meldungen sind weg
Ich finde die ganzen Anleitungen zu HW ID und App ID auch irgendwie echt gruselig. Ich meinte verstanden zu haben, dass die HW/Sensor ID den Sensor identifiziert und die AppID den Typ Daten, der geliefert wird und das eigentlich nur die SensorID passen muss.
Whatever, es lüppt jetzt ....
Danke Euch
Reinhardt Werbik
User
Die Sensor ID identifizierte einen bestimmten physikalischen Sensor und dient nur dazu, das S.Port Protokoll abzuwickeln. Alle Sensoren müssen eine eindeutige Sensor ID haben, sonst gibt es Datensalat auf dem S.Port. Daher heißt diese ID eigentlich auch Physical ID.
Die Application ID kennzeichnet den Datenparameter und nur diese ist für die weitere Verarbeitung relevant. Daher müssen alle App IDs eindeutig sein, auch für Parameter, die von verschiedenen physikalischen Sensoren stammen.
Die Application ID kennzeichnet den Datenparameter und nur diese ist für die weitere Verarbeitung relevant. Daher müssen alle App IDs eindeutig sein, auch für Parameter, die von verschiedenen physikalischen Sensoren stammen.
Es is halt komisch, denn wenn ich eine andere Sensor ID habe, warum muss dann diese andere ID auch eindeutig sein, macht ja eig. keinen Sinn... Das hat mich auch immer verwirrt, da dann andere wiederum davon schrieben, dass die Kombi aus Sensor und der anderen ID eindeutig sein muss (was ja irgendwie technisch Sinn macht)
Wie dem auch sei.... es is so wie es ist....
Die beste Beschreibung ist im Ethos manual (Abschnitt "Smart Port telemetry" z.B. ab Seite 208) z.B. https://github.com/FrSkyRC/ETHOS-Feedback-Community/tree/1.5/doc
Wie dem auch sei.... es is so wie es ist....
Die beste Beschreibung ist im Ethos manual (Abschnitt "Smart Port telemetry" z.B. ab Seite 208) z.B. https://github.com/FrSkyRC/ETHOS-Feedback-Community/tree/1.5/doc
