SPort - mal schauen, was da geht

headwind · Dez 8, 2016

Guten Tag

in der Entwicklung meines Projekts kommt nun die Telemetrie etwas gründlicher an die Reihe. Ausgangsbasis ist die Library von pawelsky. Gut dokumentiert und überschaubar.

Da ich nicht gerne mit der Bratpfanne im Trüben fische, beginne ich, mal ein paar Progrämmchen zu schreiben, die erst mal das polling-Verhalten eines X8R betreffend der Sensor-IDs dokumentieren sollen.

Dazu habe ich für den Anfang einen "dummy"-Sensor mit ID 10 geschaffen. Der macht zwar nichts anderes, als mal da zu sein und zwei Werte auszugeben - mir gehts um das prolling.

Ein Teensy 3.1/2 oder 3.6 ist der letzte in der SPort-Kette. Es können beliebig viele Frsky-SPort Sensoren vorgängig dazwischen geschlauft werden.

Das Programm sollte die polling-rates für alle Sensor-IDs innerhalb 10 Sekunden erfassen. Sollte weil es PNP ist - plug and pray.

Innerhalb 10 Sekunden bedeutet auch - 10 Sekunden warten, bis am Arduino-serial-monitor was kommen kann.

Danach können beliebig Sensoren Frsky-Sensoren dazugefügt oder weggenommen werden.

Anschlüsse : Teensy TX3 an SPort signal, Teensy GND an SPort GND

Eine kleine Auswertung : (jeweils polling rate der angeschlossenen Sensoren während 10 Sekunden bzw. unbelegter SensorIDs

Dummy 415 / 15
Dummy und Vario 277 /10
Dummy, Vario und FAS 209 / 8
Dummy, Vario, FAS und UART 167 / 7
Dummy, Vario, FAS, UART und current sensor 138 / 6

Mein Fazit : Frsky bevorzugt seine Sensoren nicht und der polling-Algorithmus ist in Ordnung. Eine bestimmte Sensor-ID dürfte recht schnell Mühe bekommen, eine refreh-rate von 10hz zu halten (je nach dem, wieviele Daten sie bereitstellt).

PS : eine bescheidene Frage an die Cracks hier : da gibt es so etwas wie "byte stuffing" - ist das nur für die UART-Kommunikation oder geht das auch bei der Abfrage der Sensordaten ?

mfg hw

Carbonator · Dez 8, 2016

headwind hat gesagt.:

Echt jetzt? Ich finde das Thema gar nicht prollig, eher sehr interessant

Im Ernst, beim S.Port hat FrSky Vieles (Alles?) richtig gemacht. So wie ich mitbekommen habe, werden erstmal alle Sensor ID´s gepollt und wenn Antworten kamen, werden die Antwortenden öfter gepollt. Kann man diesen Vorgang auch sichtbar machen? Sind die 10 Sekunden das Delay, bis gemessen wird, oder misst du 10 Sekunden lang?

Konkret: Hast du das "Lernen" der Sensoren in der Messung mit drin, oder misst du nach dem "Lernen"?

headwind · Dez 8, 2016

Carbonator hat gesagt.:

Sieht so aus wie von Dir beschrieben. Programm laden, Teensy am Ende der Kette und beliebig Sensoren anhängen. Und jeweils mal im serial monitor schauen was passiert. Das Programm stürzt bei mir nicht ab, wenn die Leitung zum SPort zwischendurch unterbrochen wird.
"Gemessen" werden die polling-Anfragen auf alle Sensor-IDs im Zeitraum von 10 Sekunden. Ich verwendete einen X8R, ich denke mal der Empfänger spielt keine Rolle, solange er SPort ist. 10 Sekunden, weil die polling-rate der inaktiven sensor-IDs so einigermassen messbar wird.

Ich vermute, das Lernen geht in etwa ruckzuck, wenn man mit einem Zeitraum von einer Sekunde zufrieden ist. Ich habe das nicht untersucht, weil ich die Sensoren meistens nicht wechsle, wenn mein Modell in der Luft ist

PS : eine bescheidene Frage an den Bischof : weisst Du etwas über das "byte-stuffing" im SPort. Wenn ja und nicht nur in Zusammhang mit UART-2x - bitte PM an mich und Du bist für mich der Papst

mfg hw

leo2e · Dez 8, 2016

Hallo,
das scheint so ähnlich wie beim I2C Bus zu sein. Da hängen auch alle Sensoren parallel am Bus und werden über unterschiedliche Adressen angesprochen. Wenn man die Adressen nicht kennt gibt ein Programmchen das die 255 Adressen durch adressiert und prüft ob sich an der entsprechenden Adresse was tun.

headwind · Dez 8, 2016

leo2e hat gesagt.:

Hi Leo2e

im Prinzip ja. Im Vergleich mit gängigen I2C-scanern, die einfach immer schauen, was da so da ist, schaut der "SPort-Scanner" mit kleiner Abfragerate alle möglichen Adressen ab, und wenn er eine findet und die antwortet, holt er sie in die "Liste" derjenigen, die etwas "bringen", verleiht ich sag es mal so - ein "high-ranking"
Es sieht so aus, als ob dann diese Adresse merklich häufiger gepollt würde (Schätzung Faktor 10x-20, abhängig von der Anzahl angehängten Sensor-IDs). Es sieht ausserdem so aus, dass jede Adresse jederzeit die Möglichkeit hat, ein "high-ranking" zu ergattern oder zu verlieren. Was ich betreffend polling-rate inaktiver Sensor-IDs bebachtet habe : schwankte zwischen 6-15 Abfragen pro zehn Sekunden, abhängig von der Auslastung des SPorts durch Sensoren.

mfg hw

Carbonator · Dez 8, 2016

headwind hat gesagt.:

Meinst du das? Letzter Absatz. Ein paar Beiträge weiter kommt von Mike B. die Aserial.cpp, die das für den openXsensor handelt.

headwind · Dez 8, 2016

Hi Carbo

kann schon sein. Ich weiss nicht. Ich meinte eher was in der Richtung http://openrcforums.com/forum/viewtopic.php?t=5393 Es ist mir schon klar, dass dort über was anderes diskutiert wurde als das, was ich gerne wüsste.

Ich blick gegenwärtig nicht durch, weshalb die polling-Raten so abnehmen, wie das obige Progrämmchen das dokumentiert. Angenommen, jedes polling würde eine Sensor-id dazu veranlassen, das zu tun :
If a sensor is present it answers by sending:

0x10 (8bit data frame header)
value_type (16 bit, e.g. voltage / speed)
value (32 bit, may be signed or unsigned depending on value type)
checksum (8 bit)

dann müsste nach meiner Überlegung die polling-Rate beim Hinzufügen eines Sensors jeweils mehr oder weniger linear zurückgehen. Tut sie aber mE nicht - ich denke, da geht noch was anderes. Falls Du ein Frsky-GPS hast und mit dem den Test machen könntest ---- wenn ich eins hätte, dann hätte ich mit dem mal geschaut, weil es eindeutig am meisten Daten hergibt. Falls es tatsächlich gegen zehn pollings braucht, bis alles was das Teil hergibt, übermittelt ist....... Bin diesbezüglich mit der Bratpfanne unterwegs.Na ja - das Dunkle ist dazu da, um Licht hineinzubringen. Die Frsky-Doku hätte ich zuweilen trotzdem gerne.
Auch die Lib von pawelsky ist noch etwas rätselhaft. Ein einer Stelle gibt es was, wo er er eigens für ID25 (RSSI,SWE,RXbat) Rücksicht nimmt (wenn ich mich richtig erinnere), aber ID25 oder auch was immer wird beharrlich mit der "Leerlauf"-rate gepollt.

Egal was rauskommt - es interessiert mich, aber ich brauch nicht alles zu wissen. Es wäre nett, wenn ich die Menge an Daten, die ich habe, schlau übermitteln könnte, aber es muss eigentlich nicht sein. Ich nagle nun die Frage : kann ich bei einem polling mehr als 1x value (32 bit, may be signed or unsigned depending on value type)

0x10 (8bit data frame header)
value_type (16 bit, e.g. voltage / speed)
value (32 bit, may be signed or unsigned depending on value type)
checksum (8 bit)

mit byte stuffing rübersschicken ?

schönen abend noch

hw

r41065 · Dez 8, 2016

Ich denke alle Sensoren abgetastet wird nur bei der Sensorsuche.
Im Normalbetrieb werden nur die Sensoren gepollt die dabei gelistet wurden...
Ralf

headwind · Dez 8, 2016

Hi Ralf

das ist auf Grund meiner Ergebnisse defintiv nicht so. Ich warte mal auf den Gegenbeweis. Glauben macht seelig - prüfen und beweisen schafft Klarheit.

mfg hw

Champus · Dez 8, 2016

Hallo hw,

ich finde das Thema auch sehr interessant! Für mich wäre es auch wichtig, noch mehr Details über den S.Port zu bekommen, speziell auch die Polling-Routinen. Ich benötige das in Verbindung mit openLRS, weil ich dort dann die Empfängerseite des S.Port emulieren muss.

Die Sache mit dem byte-stuffing scheint ja dank Carbonator geklärt zu sein. Würde es kein byte-stuffing geben und ein Sensor antwortet zB mit 0x7e 0x02 0x00 (richtig in Erinnerung?), dann würde in die Antwort der Strom Sensor reinbomben.

Hast Du schon mal das Timing zwischen der Übertragung einzelner Bytes gemessen? Ich denke da an HoTT, wo die ersten Implementationen in die Hose gingen, weil zwischen jedem Byte feste Pausen definiert sind.

Ich kann leider erst nach Weihnachten forschen ..

Carbonator · Dez 8, 2016

Das Polling wird vom XJT Modul und vom Empfänger durchgeführt, OpenTX hat darauf keinen Einfluss. Das, was wir beim "Sensor suchen" sehen, ist nur eine interne OpenTX-Funktion.

Im "Leerlauf" werden die 28 ID´s nacheinander abgefragt, jeweils (12 ms):

1,2,3,4,5,.....,28,1,2,....

Antwortet Sensor 1, dann ist die Abfrage:

1,2,1,3,1,4,1,5......28,1,2,1,.....

Antworten Sensor 1 und 5, dann:

1,5,2,1,5,3,1,5,4,1,5,......28,1,5,2,1,5.....

Oder anders ausgedrückt, es werden nacheinander alle antwortenden Sensoren abgefragt, bevor es von vorne losgeht, wird der nächste nicht antwortende abgefragt u.s.w.. So steht bei zunehmender Sensoranzahl den antwortenden Sensoren (relativ) immer mehr Bandbreite zur Verfügung, zu Lasten der Erkennungsgeschwindigkeit für neue Sensoren.

Wie die Pollingrate, die man in den Sensoren konfigurieren kann, das Gesamtsystem ändert, ist mir noch nicht klar. Da muss es noch einen weiteren Mechanismus geben.

Das ist ein schönes Beispiel, was der S.Port packt. 5Hz GPS, 1Hz GPS, Airspeed, Vario, Gleitzahl, mittleres Sinken, ACCX,Y,Z alles ohne merkbaren Geschwindigkeitseinbruch. Schön zu sehen beim VSpeed.

[video=youtube;p-cMhuEyLfk]https://www.youtube.com/watch?v=p-cMhuEyLfk[/video]

headwind · Dez 8, 2016

Hi Carbo

da wage ich es, mal gaaaaanz vorsichtig zu widersprechen. Hast Du mein (mod von pawelsky) Progrämmchen mal getestet ? Das ganze wird in Abhängigkeit der Anzahl der Sensoren vollzogen. Das polling der unbenutzten sensor-IDs ist gemäss meinen Auswertungen auch nicht fix.Und das polling der benutzten Sensor-IDs ändert eben auch, je mehr Sensor-IDs dranhängen. Ich warte da auf ein Programm, das den Gegenbeweis bringt.

Was ganz anderes : kann mir jemand sagen, was er in der Tele-Page für Höhenangabe mit einem Frsky-Vario unter Altitude sieht ? Ich verwende OTX 2.1.8 und einen
original FrSky-Vario HP, FW ca vermutlich 1 Jahr alt. Wenn ich Autooffset wegnehme, bekomme ich eine Höhe, die in etwa 10x so gross ist, wie sie sein sollte. (von aktuellem Luftdruck (QNH/QNE) brauchen wir nicht zu reden, das kenn ich). Beim wuseln mit eigener Telemetrie und eigenem Vario bin ich auf die fast exakt gleich falsche Anzeige gestossen.
Da gibt es nun diverse Möglichkeiten : was ich codiere, ist Müll, die Firmware des Varios ist veraltet, mein OpenTX ist veraltet- oder was anderes.

Da wäre es nun hilfreich, wenn sich jemand die Mühe machen würde, auf der Tele-page den auto-offset zu deaktivieren und mir mitteilen würde, ob seine gemessene Höhe in etwa dem entspricht, wie sie sein sollte.
Sollte der Test positiv ausfallen, wäre Angabe der OTX-version, firmwareversion des vario für mich hilfreich.

PS: &carbo die Videos sind nett. Ich hätte gerne "hard numbers", in Form eines .inos. Alles andere ist Religion.
Falls die FrSky-Leute entgegen der Annahme von pawelsky den RSSI nicht geschützt haben (wovon ich natürlich gemäss den bisherigen Beobachtungen NICHT ausgehe) mülle ich Dir den Sport zu, dass Du ein neues Video drehen kannst. Dann wäre es mit Aussagekraft - aber so dumm sind Frsky-Leute nicht - und Wunder muss man da auch nicht erwarten. Die armselige SBUS-Auswertung sagt über Frsky mE auch was aus. Was ich da drüber denke, behalte ich lieber für mich.

mfg hw

Carbonator · Dez 9, 2016

headwind hat gesagt.:

Guckst du hier, da hab ich den S.Port belauscht, einmal ohne Sensor, da sieht man, wie der S.Port alle ID´s nacheinander abfragt. Einmal mit einem FAS40, wo man schön sieht, dass der FAS bei jedem zweiten Poll seine Daten schicken darf. Dann wird die nächste ID gepollt......

Anhang anzeigen SPort.zip

Carbonator · Jan 16, 2017

hobby1946 hat gesagt.:

Ich zieh deine Frage mal hier rein, weil dieser Thread (hoffentlich) übersichtlicher bleibt. Hier die Data IDs und die vorbelegten Sensor ID aus dem OpenTX Source-Code.

Code:

// FrSky new DATA IDs (2 bytes)
#define ALT_FIRST_ID              0x0100
#define ALT_LAST_ID               0x010f
#define VARIO_FIRST_ID            0x0110
#define VARIO_LAST_ID             0x011f
#define CURR_FIRST_ID             0x0200
#define CURR_LAST_ID              0x020f
#define VFAS_FIRST_ID             0x0210
#define VFAS_LAST_ID              0x021f
#define CELLS_FIRST_ID            0x0300
#define CELLS_LAST_ID             0x030f
#define T1_FIRST_ID               0x0400
#define T1_LAST_ID                0x040f
#define T2_FIRST_ID               0x0410
#define T2_LAST_ID                0x041f
#define RPM_FIRST_ID              0x0500
#define RPM_LAST_ID               0x050f
#define FUEL_FIRST_ID             0x0600
#define FUEL_LAST_ID              0x060f
#define ACCX_FIRST_ID             0x0700
#define ACCX_LAST_ID              0x070f
#define ACCY_FIRST_ID             0x0710
#define ACCY_LAST_ID              0x071f
#define ACCZ_FIRST_ID             0x0720
#define ACCZ_LAST_ID              0x072f
#define GPS_LONG_LATI_FIRST_ID    0x0800
#define GPS_LONG_LATI_LAST_ID     0x080f
#define GPS_ALT_FIRST_ID          0x0820
#define GPS_ALT_LAST_ID           0x082f
#define GPS_SPEED_FIRST_ID        0x0830
#define GPS_SPEED_LAST_ID         0x083f
#define GPS_COURS_FIRST_ID        0x0840
#define GPS_COURS_LAST_ID         0x084f
#define GPS_TIME_DATE_FIRST_ID    0x0850
#define GPS_TIME_DATE_LAST_ID     0x085f
#define A3_FIRST_ID               0x0900
#define A3_LAST_ID                0x090f
#define A4_FIRST_ID               0x0910
#define A4_LAST_ID                0x091f
#define AIR_SPEED_FIRST_ID        0x0a00
#define AIR_SPEED_LAST_ID         0x0a0f
#define POWERBOX_BATT1_FIRST_ID   0x0b00
#define POWERBOX_BATT1_LAST_ID    0x0b0f
#define POWERBOX_BATT2_FIRST_ID   0x0b10
#define POWERBOX_BATT2_LAST_ID    0x0b1f
#define POWERBOX_STATE_FIRST_ID   0x0b20
#define POWERBOX_STATE_LAST_ID    0x0b2f
#define POWERBOX_CNSP_FIRST_ID    0x0b30
#define POWERBOX_CNSP_LAST_ID     0x0b3f
#define RSSI_ID                   0xf101
#define ADC1_ID                   0xf102
#define ADC2_ID                   0xf103
#define SP2UART_A_ID              0xfd00
#define SP2UART_B_ID              0xfd01
#define BATT_ID                   0xf104
#define SWR_ID                    0xf105
#define XJT_VERSION_ID            0xf106
#define FUEL_QTY_FIRST_ID         0x0a10
#define FUEL_QTY_LAST_ID          0x0a1f

// Default sensor data IDs (Physical IDs + CRC)
#define DATA_ID_VARIO             0x00 // 0
#define DATA_ID_FLVSS             0xA1 // 1
#define DATA_ID_FAS               0x22 // 2
#define DATA_ID_GPS               0x83 // 3
#define DATA_ID_RPM               0xE4 // 4
#define DATA_ID_SP2UH             0x45 // 5
#define DATA_ID_SP2UR             0xC6 // 6

Die Sensoren antworten auf die Abfrage ihrer Sensor IDs, davon gibt es 28 Stück, das ist auch die maximale Anzahl an Sensoren auf dem SmartPort Bus. Die Sensor ID bestimmt also, welcher Sensor auf die Abfrage (Poll) antwortet, Vario, GPS....

Die 28 Sensor IDs mit CRC:

Code:

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

Ein Sensor kann aber verschiedene Daten senden, GPS ist ein schönes Beispiel. Dafür gibt es die Data ID, beim GPS zum Beispiel 10 verschiedene, siehe Code, also z.B. GPS Koordinaten, GPS Höhe, GPS Speed.......

Das bedeutet, dass das GPS (bis zu - (FrSky sendet kein Heading, openXsensor keine Zeit)) 10 verschiedene Daten verschickt, das Vario z.B. 4 verschiedene.

Falls die Sensoren zum Zeitpunkt der Abfrage keine neuen Daten bereithalten, werden sie übersprungen.

SPort - mal schauen, was da geht

headwind

Benutzer

Anhänge

Carbonator

Allerhopp ;)

headwind

Benutzer

leo2e

Erfahrener Benutzer

headwind

Benutzer

Carbonator

Allerhopp ;)

headwind

Benutzer

r41065

:)

headwind

Benutzer

Champus

Neuer Benutzer

Carbonator

Allerhopp ;)

headwind

Benutzer

Carbonator

Allerhopp ;)

Carbonator

Allerhopp ;)