FrSky Servo Channel Changer? Alternative?

Merak · Jul 7, 2020

Hallo Gemeinde!
Eben habe ich versucht an meinem RX8R-Pro einen Spannungssensor und ein GPS sowie 2 RPM-Sensoren anzuschließen:
-->Smart Port RPM Sensor mit 2 Temperatur Sensoren - Engel Modellbau + Technik
Ich möchte insgesamt an 4 Stellen Temperatur messen.

Aber ich war wohl etwas blauäugig wie ich schnell gemerkt habe - es funktioniert nicht :-(

Etwas Recherche ergab, dass ich wohl die ID eines RPM Sensors ändern muss. Die beiden Temperaturkanäle melden sich mit 400/05 und 410/05 und wenn ich es richtig verstanden habe muss ich aus der 400 und der 410 für einen Sensor eine z. Bsp. 420 und eine 430 machen. Stimmt das?
Wenn ja, ist es wirklich so, dass das der FrSky Servo Channel Changer das kann?

--> SBUS Servo Channel Changer FrSky - Engel Modellbau + Technik

Irgendwie werde ich nicht schlau aus den Beschreibungen zur SensorID (400) und SubID (05) und was unter welchen Umständen geändert werden muss. Vom technischen Verständnis her würde ich denken, dass wirklich die SensorID geändert werden muss, aber wenn ich mir den Channel Changer betrachte, habe ich das Gefühl er kann nur die SubID ändern. Trotzdem wird ja gesagt "2 gleiche Sensoren" bedeutet Du brauchst einen Channel Changer.
Beiträge zu dem Changer sind recht alt und ich könnte mir vorstellen, dass sich inzwischen vielleicht was geändert hat. Gibt es denn Alternativen?

Hat jemand ein paar aufklärende Worte für mich? Schon mal vielen Dank dafür!

Carbonator · Jul 7, 2020

Hi,
du stellst die richtigen Fragen

Das Thema hatte ich schon mehrfach mit den OpenTX Devs diskutiert, weil es sehr missverständlich ist und wechselnde Bezeichnungen verwendet werden.

Kurzfassung der aktuellen Situation: Die SensorID beschreibt, um welchen Sensor es sich handelt, also welche Einheit verwendet werden soll, wieviele Nachkommastellen geliefert werden u.s.w.

Die SubID oder Instance belegt einen Slot im SPort Datentransfer. Per SubID werden ansonsten identische Sensoren unterschieden. Gleiche Sensoren benötigen unbedingt verschiedene SubID. Der einfachste Weg ist aktuell ein LUA-Script zu verwenden, das den einzigen (!) am Empfänger angeschlossenen Sensor konfigurieren kann.

R/C Settings - Lua Scripts - Sensor Config

Es gibt noch einige weitere Möglichkeiten, aber alle mit höherem Aufwand und Kosten

Merak · Jul 7, 2020

Hmm, da fallen mir gleich mehrere Punkte ein ...
1) vielen, vielen Dank für Deinen Beitrag!
2) Ich entnehme, dass ich die SubID/Instance vom zweiten RPM/Temperatur-Sensor ändern muss. Also aus der Default 5 eine zum Beispiel 6 machen, korrekt?
3) Wie passt es in dieses Schema, dass beide Temperaturkanäle des Sensors die SubID 5 haben und sich in der SensorID unterscheiden?
4) Das gleiche muss ich dann wohl auch für den RPM-Sensor der beiden Sensormodule machen, sonst kommt der Bus wieder durcheinander, korrekt?
4) Auf der von Dir referierten Seite steht:

Das lässt mich glauben, dieses LUA Script würde nun doch die SensorID und nicht sie SubID ändern ...(?)

Sorry, ich hab's immer noch nicht ... :-(

Carbonator · Jul 7, 2020

zu 2. Korrekt, die 6 muss aber frei sein
zu 3. Das ist in diesem Fall Bestandteil der Sensordefinition = SensorID
zu 4. Vermutlich ja, ich hatte die Teile noch nie in den Fingern
zu 5. aka 4

Die Bezeichnungen werden, wie ich oben geschrieben habe, wechselnd verwendet, auch von OpenTX und FrSky und Anderen. Deswegen ist es kein Wunder, dass niemand auf Anhieb durchblickt.
Mach einfach mal, dann wird es vermutlich klar - wenn nicht, nachfragen.

Guck aber auf keinen Fall in diese oXs Datei ab Zeile 20 Hier kommen nämlich noch weitere verwirrende Dinge ins Spiel

Diese Datei kannst du dir aber ruhig anschauen, das ist der OpenTX Quellcode mit den Sensor-Definitionen.

Carbonator · Jul 7, 2020

Wenn man durcheinanderkommt: in Companion ist es sauber dargestellt. Im Sender schon nicht mehr.

Merak · Jul 7, 2020

Nun, OK. Ich werd' mein Glück versuchen. Zwar habe ich noch nie auch nur garnix mit LUA gemacht, aber ich hoffe, dass ich mit den Erläuterungen auf der von Dir referierten Seite klar komme. Vielleicht kauf'ich mir auch einfach diesen Channel Changer. Im Grunde interessiert mich LUA nämlich (zumindest noch) überhaupt nicht.
Hey nochmal vielen Dank! Ich meld' mich hier zurück!

ReinhardZ · Jul 8, 2020

Beim FrSky SPort Protokoll wird zwischen physical ID und application ID unterschieden.
Physical ID ist die Adresse des physkalischen Sensors auf dem SPort.
Jeder Sensor kann 1..n Werte senden. Das sind die application IDs.
Die physical ID wird noch mit Checksummenbits (Bit 5,6,7) versehen, bevor sie auf dem SPort Bus gesendet wird. Das ergibt dann die ID Nummern, die in der OXS-Datei ab Zeile 20 stehen. Diese IDs sieht man dann, wenn man den SPort Bus mit einem Logik Analysator betrachtet.

Für den RPM sensor gilt
Physical ID = 0x04 --> mit Checksummenbits ergibt das 0xE4
Application IDs sind:
Temp1 = 0x0400 .. 0x040F
Temp2 = 0x0410 .. 0x041F
RPM = 0x0500 .. 0x050F

Wenn zwei gleiche Sensoren am SPort betrieben werden sollen, müssen sie
- unterschiedliche physical ID's haben (sonst senden sie gleichzeitig und es kommt zur Datenkollision)
- unterschiedliche application IDs haben (sonst überschreibt der 2.Sensor die Werte vom 1.Sensor)

Für zwei RPM/Temp Sensoren würde man also z.B. einstellen
Sensor 1:
physical ID = 0x04 bzw. 0xE4
Temp1 = 0x0400
Temp2 = 0x0410
RPM1 = 0x0500

Sensor2:
physical ID = 0x05 bzw. 0x45
Temp3 = 0x0401
Temp4 = 0x0411
RPM2 = 0x0501

Ob das mit dem Servo Channel Changer geht, weiß ich nicht (kann die Doku auf der FrSky Seite nicht finden).

Generell kann man jede beliebige physical ID benutzen, die von FrSky definiert wurde (erkannt wird). Es muss nur sichergestellt sein, dass jede physical ID und application ID nur einmal in dem konkreten Aufbau vorkommt.

QuadCrash · Jul 8, 2020

ReinhardZ hat gesagt.:

S.Port, nicht SBUS.

Carbonator · Jul 8, 2020

ReinhardZ hat gesagt.:

Moin Reinhard,

interessantes Thema, lass uns mal noch diese zwei Punkte diskutieren:
ich denke, unterschiedliche physical ID (instance) ist korrekt, aber sie brauchen keine unterschiedliche application ID zu haben. Wenn ein zweiter Sensor eingesetzt wird, reicht es, die physical ID (instance) zu ändern. Das ist genau das, was @Merak tun will, bzw. sogar muss.

Wenn aber ein physikalischer Sensor wie der RPM, um den es hier geht, unter einer physical ID zwei Temperaturwerte übermittelt, dann geht das nur mit unterschiedlichen application IDs, die auch so in der
frsky_sport.cpp definiert sind:

{ T1_FIRST_ID, T1_LAST_ID, 0, ZSTR_TEMP1, UNIT_CELSIUS, 0 },
{ T2_FIRST_ID, T2_LAST_ID, 0, ZSTR_TEMP2, UNIT_CELSIUS, 0 }

Ich kann theoretisch alle application IDs unter einer einzigen pysical ID übertragen, aber jede application ID, wie z.B. T1 oder Temp1 nur genau ein mal unter dieser physical ID. Flightcontroller machen das z.B. genau so, die schieben alle ihre Daten unter einer einzigen physical ID auf den S-Port.

ReinhardZ hat gesagt.:

Ich denke, dass es genau 28 physical ID gibt, von 1-28 oder 0-27 je nach Zählweise (beide Zählweisen werden in der Praxis benutzt, was auch für Verwirrung sorgt). Die application ID kann mehrmals vorkommen, aber natürlich nur in Kombination mit unterschiedlicher physical ID.

@Merak kann seine 4 RPM Sensoren einsetzen, muss nur die physical ID ändern und hat dann in der Telemetrie 4 RPM, 4 Temperatur(1)werte und 4 Tempertur(2)werte, alle mit jeweils derselben applicationID.

@Merak: einfach die LUA Datei in SCRIPTS/TOOLS auf die SD-Karte kopieren und über das Systemmenue ausführen (ab OpenTX 2.3).

ReinhardZ · Jul 8, 2020

QuadCrash hat gesagt.:

Na klar.
Bringt man immer schnell durcheinander ...

ReinhardZ · Jul 8, 2020

Carbonator hat gesagt.:

Hallo Bernd,
Dass auch die application IDs unterschiedlich sein müssen, auch wenn sie von zwei unterschiedlichen Sensoren (physical IDs) kommen, war eine Annahme von mir. Ich habe nicht in den Open TX Code geschaut, wie das dort gelöst ist. Wenn man die Messwerte für die unterschiedlichen apllication IDs pro Sensor (physical ID) speichert, ist es nicht nötig, die application IDs zu ändern.

Carbonator hat gesagt.:

Theoretisch müsste es 32 physical IDs geben. Das ist ja ein 8Bit Wert, von dem die oberen drei Bit als Checksumme benutzt werden. Es bleiben also 5 Bit für die eigentliche physical ID (2 hoch 5 = 32).
Die Adressen sind dann 0x00 bis 0x1F. Es sind aber von FrSky wohl noch nicht alle IDs benutzt. Die höchste ID, die ich bisher gesehen habe, war ein flight controller F411W, der seine Sensorwerte mit der physical ID 0x1B sendet.

Carbonator · Jul 8, 2020

Carbonator hat gesagt.:

Das will ich noch kurz erklären, weil mich das früher sehr verwirrt hat. Beim oXs heißt es:

Code:

// ***** 1.2 - SPORT_SENSOR_ID used (only for Frsky Sport protocol)  *****   See list of available values in oXs_config_descripion.h
#define         DATA_ID_VARIO  0x00  // = sensor 0 used for Alt and Vspeed
#define         DATA_ID_FLVSS  0xA1  //          1 used for Cell values
#define         DATA_ID_FAS    0x22  //          2 used for vfas , current and fuel
#define         DATA_ID_GPS    0x83  //          3 used for GPS data
#define         DATA_ID_RPM    0xE4  //          4 used for rpm, T1, T2, airspeed
#define         DATA_ID_ACC    0x67  //          7 used for Acc X, Y, Z
#define         DATA_ID_TX     0x0D  //           used to read data sent by Tx in order to adjust some oXs parameters (flow sensor or ppm)

- Erst mal werden sowohl "Sensor ID" als auch "Data ID" als Bezeichnung für die physical ID oder instance verwendet.
- Und eigentlich sollte jeder Hardwaresensor nur eine physical ID belegen, denn die Daten werden ja bereits durch die application ID identifiziert. Die Flightcontrolerfirmwares machen es z.B. korrekt. oXs aber nicht.
- Bei den 6 physical ID wurde gleich noch die Prüfsumme eingearbeitet, aber so erscheinen diese natürlich nicht später im Sender bzw. Companion. Die Prüfsumme hätte man eleganter später dazufügen können, ohne den User zu verwirren.

Übrigens war hier die Tinte noch nicht richtig getrocknet, da war der Link zum LUA auch schon im Engel-Wiki

r41065 · Jul 8, 2020

Carbonator hat gesagt.:

bekenne mich schuldig, wer so eine Steilvorlage liefert wenn ich gerade Urlaub habe....

Ralf 😇 😁

ps. ich nutze für die Konfiguration meistens das SPort Tool und einen als STK geflashten Arduino Nano...

Merak · Jul 8, 2020

Wow (der Autor dieses Wortes atmet desillusioniert aus).

Ich weiß nicht ob ich richtig geschnallt habe was ich nun ändern muss und was ich ändern kann.
Da mir das etwas zu weit weg ist von komfortablem Endusermanagement, habe ich einen Störfaktor eliminiert und auf jeden Fall mal diesen Channel Changer bestellt. Für die Ausführung von Lua-Scripten und den damit zusammenhängenden Kollateralproblemen fühle ich mich noch nicht weit genug. Ihr sagt zwar immer es sei einfach, aber ich glaube ihr unterschätzt einfach wie tief Ihr in der Materie drin steckt ;-)

Ein Versuch die Terminologie zu erfassen (bewusst einfach gehalten):
Der Fühler Tmp1 an meinem RPM-Sensor ist sichtbar mit 0400 und 5

0400, ein HexWert daher genau genommen 0x400: Application ID, ID, Sensor Sub ID
05: Instance, physical ID, Sensor ID, Data ID

Ich habe 2 RPM Sensoren, die sich aus der Tüte wie folgt melden:

Sensor 1:
Tmp1 0x0400/05
Tmp2 0x0410/05
RPM 0x0500/05

Sensor 2:
Tmp1 0x0400/05
Tmp2 0x0410/05
RPM 0x0500/05

Damit alles läuft (ich mag 4x Temperatur und 1 x Drehzahl) konfiguriere ich beispielsweise wie folgt:

Sensor 1 (unverändert Default):
Tmp1 0x0400/05
Tmp2 0x0410/05
RPM1 0x0500/05

Sensor 2 (modifiziert via LUA oder Channel Changer):
Tmp3 0x0400/15
Tmp4 0x0410/15
RPM2 0x0500/15

Lieg' ich da jetzt in etwa richtig?

Carbonator · Jul 8, 2020

Das sieht doch gut aus

Der Durcheinander bei den Bezeichnungen ist über die Zeit leider so entstanden, das werden wir nicht mehr ändern können. Eigentlich ist Reinhards Definition mit application und physical ID die eindeutigste, aber leider zeigt uns der Sender und Companion etwas anderes an.

LUA ist nicht so kompliziert, wie du denkst. Ich finde es deutlich einfacher, als mit separater Hardware, Software und PC zu arbeiten. Probier es doch aus .... Leider wird auch zum Thema LUA viel Quatsch geschrieben, man braucht zum Beispiel definitiv kein OpenTX mit der LUA-Option um die ganzen Standard LUA Skripte zu nutzen. Der Modellassistent ist z.B. auch ein LUA-Skript.

Merak · Jul 8, 2020

Carbonator hat gesagt.:

Na da sagst Du was

Genau da fürchtete ich Probleme - ich hatte nämlich LUA in den Build-Options abgewählt. Sicher werde ich es mal probieren. Aber wohl erst wenn ich mit dem Channel Changer Erfolg hatte und somit das zu erwartende Ergebnis klar ist

Mit zuviel Unbekannten mag ich nicht ins Rennen gehen. Das Schiff soll bald vom OP-Tisch um wieder den Fliegern Platz zu machen ...

Ich meld' mich hier zurück ...

Derweil - vielen, vielen Dank an alle!

fa223 · Jul 9, 2020

Um hier noch etwas mehr Verwirrung (wenigstens für mich) rein zu bringen, noch eine Frage:
Wie ändert man die physical-ID am oXs?

Konkret geht es darum, die im anderen Beitrag diskutieren AirSpeedsensoren gleichzeitig zu testen. Beim Anschluss des FrSky-Sensors und eines oXs werden beide erkannt. Ein zweiter Arduino mit ebenfalls einem AirSpeedsensor wird hingegen nicht (zusätzlich) erkannt. Dies erscheint mir logisch, da ja die Firmware-Grundeinstellung gleich ist. Nur, wo darf ich ändern?

Grüße, Klaus.

r41065 · Jul 9, 2020

fa223 hat gesagt.:

Bernd hat die Stelle in der config_advanced oben schon angegeben: openXsensor/openXsensor

If needed (e.g. in order to connect 2 oXs devices sending similar data), you can change some SPORT_SENSOR_ID but you must select only values from this list* 0x00,0xA1,0x22,0x83,0xE4,0x45,0xC6,0x67,0x48,0xE9,0x6A,0xCB,0xAC,0x0D,0x8E,0x2F,0xD0,0x71,0xF2,0x53,0x34,0x95,0x16,0xB7,0x98,0x39,0xBA,0x1B* Those SPORT_SENSOR_ID parameters are defined in oXs_config_advanced

Also beim Compilieren...

Ralf

kalle123 · Jul 9, 2020

fa223 hat gesagt.:

* 1.2 ****** SPORT SENSOR ID (for SPORT protocol only) **********************
*
* In SPORT protocol, there may be several sensors connected on the same bus (e.g. a GPS) but each sensor must have a different SPORT_SENSOR_ID.
* For SPORT protocol, oXs uses up to 6 SPORT_SENSOR_ID. The 6 SENSOR_ID used by oXs are by default :
* DATA_ID_VARIO 0x00 // = sensor 0 used for Alt and Vspeed
* DATA_ID_FLVSS 0xA1 // 1 used for Cell values
* DATA_ID_FAS 0x22 // 2 used for vfas , current and fuel
* DATA_ID_GPS 0x83 // 3 used for GPS data
* DATA_ID_RPM 0xE4 // 4 used for rpm, T1, T2, airspeed
* DATA_ID_ACC 0x67 // 7 used for Acc X, Y, Z
* If needed (e.g. in order to connect 2 oXs devices sending similar data), you can change some SPORT_SENSOR_ID but you must select only values from this list
* 0x00,0xA1,0x22,0x83,0xE4,0x45,0xC6,0x67,0x48,0xE9,0x6A,0xCB,0xAC,0x0D,0x8E,0x2F,0xD0,0x71,0xF2,0x53,0x34,0x95,0x16,0xB7,0x98,0x39,0xBA,0x1B
* Those SPORT_SENSOR_ID parameters are defined in oXs_config_advanced.h file (section 1.1)

aus 'oXs_config_description.h'

cu KH

Hallo Ralf, seh gerade, du warst schneller

Carbonator · Jul 9, 2020

fa223 hat gesagt.:

Ich mach mal ein konkretes Beispiel, erst noch mal die Standard physical IDs:

Code:

// ***** 1.2 - SPORT_SENSOR_ID used (only for Frsky Sport protocol)  *****   See list of available values in oXs_config_descripion.h
#define         DATA_ID_VARIO  0x00  // = sensor 0 used for Alt and Vspeed
#define         DATA_ID_FLVSS  0xA1  //          1 used for Cell values
#define         DATA_ID_FAS    0x22  //          2 used for vfas , current and fuel
#define         DATA_ID_GPS    0x83  //          3 used for GPS data
#define         DATA_ID_RPM    0xE4  //          4 used for rpm, T1, T2, airspeed
#define         DATA_ID_ACC    0x67  //          7 used for Acc X, Y, Z
#define         DATA_ID_TX     0x0D  //           used to read data sent by Tx in order to adjust some oXs parameters (flow sensor or ppm)

Als Faulenzer tausche ich jetzt einfach die Airspeed ID gegen eine aus der Liste, die nicht genutzt wird, zum Beispiel ACC:

Code:

// ***** 1.2 - SPORT_SENSOR_ID used (only for Frsky Sport protocol)  *****   See list of available values in oXs_config_descripion.h
#define         DATA_ID_VARIO  0x00  // = sensor 0 used for Alt and Vspeed
#define         DATA_ID_FLVSS  0xA1  //          1 used for Cell values
#define         DATA_ID_FAS    0x22  //          2 used for vfas , current and fuel
#define         DATA_ID_GPS    0x83  //          3 used for GPS data
#define         DATA_ID_RPM    0x67  //          4 used for rpm, T1, T2, airspeed
#define         DATA_ID_ACC    0xE4  //          7 used for Acc X, Y, Z
#define         DATA_ID_TX     0x0D  //           used to read data sent by Tx in order to adjust some oXs parameters (flow sensor or ppm)

So braucht man weder in die description zu schauen, noch sich Gedanken machen, ob die ID frei ist. Es ist nur ein copy/paste in der advanced. Die IDs werden von oXs nämlich nur dann verwendet, wenn der Sensor auch definiert ist.

FrSky Servo Channel Changer? Alternative?

Well-known member

Allerhopp ;)

Well-known member

Allerhopp ;)

Allerhopp ;)

Well-known member

Benutzer

Erfahrener Benutzer

Allerhopp ;)

Benutzer

Benutzer

Allerhopp ;)

:)

Well-known member

Allerhopp ;)

Well-known member

Erfahrener Benutzer

:)

Jugend forscht ....

Allerhopp ;)