THEMA:

Hi,

wo ist in [1] eine Beschränkung auf 32 Werte ?

Laut Protokollbeschreibung sind pro Sensor 255 Werte möglich. Eine Einschränkung gibt es bei den Sendern - da sind mit Monochrom-Display 32, mit Farbdisplay 80 Werte insgesamt, also für alle Sensoren zusammen, spezifiziert.

Das Problem bei den GPS Fliegern liegt hauptsächlich daran das viele Sensoren verwendet werden und dann die Schnittstelle im Sender nur EX-Daten mit 9600 Baud ausgiebt. Die Daten werden wohl willkürlich vom Sender ausgewählt.
Dadurch kommen dann unter Umständen bestimmte Werte sehr selten dort und damit im Handy an.

Der Flaschenhals ist hier die Schnittstelle im Sender. Oder anders, würde man nur einen EX-Sensor im Modell verwenden wäre das Ergebnis gut. Klar geht das mit einer separaten Funkstrecke noch besser.

Nach meinem Stand sammelt der RX nicht Telemetriepakete, um sie dann irgendwann zu verschicken. Was da ist wird verschickt.

Gruß

Zufälliger Weise habe ich mich in der letzten Zeit mit der Optimierung der MS5611-Sensor-Behandlung im VarioGPS-Sensor DIY Projekt beschäftigt und hier eine deutliche Verbesserung des Signal-Rausch-Verhältnisses erreicht.
Nach der Integration in den originalen Code war die Enttäuschung groß, weil auf dem Sender lediglich ca. 1Wert/Sekunde übertragen wurde.
Eine Analyse zeigte, dass das benutzte EX-Sensor-Interface (Interface zwischen Telemetrie-Geber und Empfänger) mit Werten überflutet wurde und die 9600 Baud Schnittstelle, hier der Flaschenhals war.
Wird versucht mehrere / viele Telemtriewerte (bei mir ca. 25 ) oft zu übertragen, kommt es ganz schnell zu einer Überlastung und damit zu einer deutlichen Latenz an dieser Schnittstelle.

Für eine Verbesserung dieser Latenzzeit, ist eine Reduzierung der Telemetriewerte unumgänglich. Also alles unnötige Telemetriewerte, wenn möglich entfernen.
Desweiteren wurde die in dem DIY Projekt VarioGPS-Sensor eingesetzte JetiExSensor-Lib, um eine Priorisierungs-Funktion erweitert.
Für meinen Fall war wichtig die Vario-Werte häufig zu übertragen, die GPS Daten reichen 1 mal pro Sekunden.
Damit konnten ca. 13 Telemetriewerte übertragen werden. Der Vario-Wert mit ca. 6.5 Werten pro Sekunde.
Das im Assist integrierte Vario, arbeitet mit ca. 10 Werten pro Sekunde.
Wird das VarioGPS-Sensor nur auf die Vario-Funktionalität (ohne GPS und andere Sensore) gebaut, schafft man ~12 Vario-Werte/Sekunde.
An das Jeti-Vario kommt das VarioGPS-Sensor-Projekt in Punkto Latenz/Geschwindigkeit nicht ran. Ob das am verwendeten Sensor, der Bearbeitung der Daten oder an der "Priorisierung" der Daten im RX liegt, kann ich nicht analysieren. Fakt ist, dass ein "Steigen"-Signal des Jeti-Assist-Varios ca. 150ms schneller am Sender angezeigt wird (siehe raw.githubusercontent.com/Pulsar07/Jeti_...3.6_0.96_6.5VSps.png)

Die Schnittstelle der modifizierten JetiExSensor-Lib erlaubt es dynamisch diese Prioritäten zu verändern (wird in Jeti_VarioGPS-Sensor nicht gemacht).
So könnte man aufgrund von sich stark ändernden Daten die Priorität erhöhen, oder auf Servo-Eingänge reagieren, um z.B. zwischen Thermik und Strecke unterschliedlich Prioritäten zu nutzen.

Wen das interessiert, hier die Projekte:
* github.com/Pulsar07/Jeti_VarioGPS-Sensor
* github.com/Pulsar07/JetiExSensor

Natürlich müssen diese Werte dann vom RX noch per Rückkanal übertragen werden. Über Übertragungsrate und Latzenz hat Ingmar ja versucht sich einen Überblick zu verschaffen.
Hier ist aber zu berücksichtigen, dass es sich hier um eine Funkübertragung handelt, die natürlich von Entfernung und Frequenzbelegung abhängig ist. Eine Untersuchung auf der Werkbank liefert hier sicherlich nur Grenzwerte an der Optimum-Seite.

Gruß Rainer

Hallo Rainer
Endlich einmal eine fundierte Analyse und nicht ein ewiges blabla von Halbwissen.Super erklärt und analysiert.
Danke
Christian

Hallo zusammen,

ich habe einmal den sehr guten Versuch von Ingmar nachgestellt und die Latenz, also die Laufzeit mit dem Scope gemessen.

Die Laufzeit von Impulseingang Empfänger über den Sender bis zum Empfänger Ausgang ist nicht immer konstant. Laufzeit im "Best-Case" 42ms und im Worst-Case bei 146ms.

Anbei dazu die folgenden beiden Oszilloskope Bilder:





Bitte nicht vergessen die Laufzeit beinhaltet Down- und wieder Uplink.

Allerdings ist das alles eine sehr isolierte Betrachtung.
Bei 9600Baud an der EX Schnittstelle ist ein Datenbyte ca. 1ms lang. So ein Sensor bei Jeti EX also der der 9600Baud Schnittstelle, schickt schnell mal so um die 50Bytes raus (Jeti EX und Simple Jeti Text). Das ist noch nichts umfangreiches an Telemetrie Daten, da reden wir von zwei Messwerten und der JetiBox Info. Das muss der Empfänger einlesen und dann im Down-Link zum Sender schicken.

Viele Grüße
Dirk

dvcam99 schrieb:

und im Worst-Case bei 146ms

Wo wobei dieser worst case bei guten funktechnisches Bedingungen (kleine Distanz) entstanden ist.
Die gezeigten sekundenlangen Aussetzer der Telemetriedaten können nicht durch die "langsame" serielle Datenübertragung bei 9600 Baud (9700 um genau zu sein) vom Sensor zum Empfänger erklärt werden.
Es kann eigentlich nur durch Paketverluste bei der Funkübertragung vom Empfänger zum Sender erklärt werden.
Komisch ist aber das in der Zeit wo gewisse Telemetriedaten fehlen andere durchkommen und das teilweise über mehr als 10 Frames hinweg. Also doch wieder ein Indiz das bei der Kommunikation zwischen Sensor und Empfänger etwas nicht passt!

Gruss Lukas

FuniCapi schrieb:

dvcam99 schrieb:

und im Worst-Case bei 146ms

Wo wobei dieser worst case bei guten funktechnisches Bedingungen (kleine Distanz) entstanden ist.
Die gezeigten sekundenlangen Aussetzer der Telemetriedaten können nicht durch die "langsame" serielle Datenübertragung bei 9600 Baud (9700 um genau zu sein) vom Sensor zum Empfänger erklärt werden.
Es kann eigentlich nur durch Paketverluste bei der Funkübertragung vom Empfänger zum Sender erklärt werden.
Komisch ist aber das in der Zeit wo gewisse Telemetriedaten fehlen andere durchkommen und das teilweise über mehr als 10 Frames hinweg. Also doch wieder ein Indiz das bei der Kommunikation zwischen Sensor und Empfänger etwas nicht passt!

Gruss Lukas

Hallo Lukas,

ja genau, bei meinem Messungen gab es als möglichen "HF-Störfaktor" nur mein WLAN.
Ich würde einmal vermuten keine wirklich böses HF Umfeld.

Wo kann ich mir eigentlich diese langen Aussetzer einmal anschauen?? Über welche Zeiten reden wir da?
Sind diese beobachteten Aussetzer auch bei Jeti EX-Bus und / oder nur bei Jeti EX Telemetrie beobachtet worden?

Ein Problemfeld bei Jeti EX Telemetrie und vielen Sensordaten, ist die "Daten Concentrator" Struktur der Telemetrie.
Für jeden nachzulesen in der EX Protokollbeschreibung. Bei dieser Struktur ist der Sensor immer "Master", der Empfänger oder eventuell der Expander immer Concentrator also Dateneinsammler.

Wenn wir uns jetzt einmal eine REX Empfänger oder Expander Installation mit 3 oder 4 angeschlossenen EX Sensoren vorstellen, dann laufen alle diese Sensoren nicht synchron. Das heißt jeder Sensor "plappert" so vor sich hin mit seinem Frame Block von 50 oder mehr Bytes. Nach welchem Schema oder Algorithmus die Frame Blöcke erfasst werden kann nur Jeti sagen. Irgendwie muss der Expander/Concentrator ja die 3 oder 4 Ports abfragen bzw. die Frame Blöcke dort einsammeln. Ich kann mir gut vorstellen das dabei je nach Phasenlage der Frame Blöcke zueinander, Sensoren in den Vorteil einer schneller, oder auch verzögerten Übertragung kommen.

Viele Grüße
Dirk