SBUS-Frame Monitoring über SPort

[headwind]

Guten Tag

ich habe einen kleinen Sketch gemacht, der den Status der SBUS-Frames (Signal-OK, Signal-Lost oder Failsafe) auszuwertet und über SPort an den TX zu übermittelt. Die Werte erscheinen in der Telemetrie unter A3. Wert 100 bedeutet, 100% der letzten 100 Frames hatten den Status Signal-OK, 50 bedeutet 50% der letzten 100 Frames hatten den Status Signal-OK usw..

Der Sketch ist für einen Teensy 3.x programmiert, sollte aber mit kleinen Anpassungen (SoftwareSerial) auch auf einem Arduino laufen.

mfg hw

 

[Carbonator]

Würde ich gerne mal auf einem Arduino testen. Mein Arduino Berater meinte damals beim S-Bus Decoder, S-Bus geht beim Kleinen nur mit der Hardware serial und Inverter. Das Material für Beides hab ich aber da, kannst du die Änderungen im Code angeben?

 

[headwind]

Hallo Carbo

helle hat da schon was gemacht : http://fpv-community.de/showthread.php?32899-FrSky-TARANIS-Hardware-Mods/page12

Wie der pawelsky den sofwareserial braucht : FrSkySportSingleWireSerial.cpp

Softwareserial sollte die 100000 schaffen, invertieren nicht vergessen, Softwareserial kann das (heute) angeblich.

grüessli hw

 

[MarenB]

Ich programmiere zwar in Basic, kann aber bestätigen, dass der kleine Atmel das problemlos schafft. Ich nutze Softserial allerdings nur, um mir die Invertierung des S.Bus zu sparen.
Hab das sowohl auf einem ATmega328PA (zum RC-Schalter umprogrammierter 6A ESC) als auch auf ATtiny44 (2-Kanal PWM-Ausgabe für Pan/Tilt und S.Bus-Buzzer) am laufen. Unter Verwendung des internen RC-Schwingkreises hat es allerdings nicht so dolle funktioniert, weshalb auch die fliegend aufgebauten tinys ein Quarz bekommen haben.

 

[Carbonator]

Das wäre ein großer Fortschritt, auch für den S-Bus to PPM Konverter von mstrens. Der "Bau" des Inverters hält am meisten auf. Ich hoffe, es erbarmt sich jemand, den "SBUS-Frame Monitoring über SPort" Sketch auf Arduino pro mini umzuschreiben. Mein Frustationspotential ist nach der ersten Fehlermeldung, die ich nicht interpretieren kann, sofort erschöpft

 

[Champus]

Habt ihr schon mal an den Attiny841 gedacht?

14Pin, 2xechte USART, 8k Flash im SOIC Gehäuse. Ok, wenn das löten eines Inverters mit einer Transe und 2 Widerständen schon unnötig aufhält, dann greift man lieber zum 15x teureren Teensy.

 

[Carbonator]

Vielen Dank für diesen zielführenden Beitrag!

 

[r41065]

... Ich hoffe, es erbarmt sich jemand, den "SBUS-Frame Monitoring über SPort" Sketch auf Arduino pro mini umzuschreiben. Mein Frustationspotential ist nach der ersten Fehlermeldung, die ich nicht interpretieren kann, sofort erschöpft

Habt ihr schon mal an den Attiny841 gedacht?
...

@Bernd:
Bin momentan bei der zweiten Fehlermeldung gescheitert die ich noch nicht interpretieren kann.
Der Winter ist aber noch lang und meine Arduinos noch in der Post..( steht auch noch nicht oben auf meiner Prioritätenliste)
Hoffe also wie du das jemand das zeitnah für den Arduino umsetzt.


@ Champus
kennst du die Definition von Hobby?
( mit dem gröstmöglichen finanziellen und zeitlichen Aufwand ...)

Ich denke jeder nutzt da seine Möglichkeiten.
Ich baue meine Fahrtregler immer noch mit Pic16F84 Prozessoren auf.
Das Programm dazu funktioniert seit Jahren sicher und zuverlässig.
Auch wenn der Prozessor mittlerweile sicherlich nicht mehr Up-To-Date ist: Brenner, Software, Layout und einige Platinen sind im Bestand vorhanden und werden weiter genutzt.
Wenn headwind also einen Teensy benutzt wird er KnowHow und entsprechende Hard und Software zur Verfügung haben.
Ansonsten ist ein Teensy für diesen Zweck sicherlich mit Kanonen auf Spatzen schiessen.
Bau den Sensor mit dem ATtiny, veröffentliche das Programm und dein Layout dazu und du wirst sicherlich viele Nachahmer finden...

Ralf

 

[Carbonator]

Bau den Sensor mit dem ATtiny, veröffentliche das Programm und dein Layout dazu und du wirst sicherlich viele Nachahmer finden...

Moin,

ich bin für den Pro mini. Wir haben ja oben geklärt, dass softserial für S-Bus (100000 Baud) funktioniert. Das ist sicherlich von der Hardware her dann das Einfachste (4 Verbindungen, kein Inverter).

 

[r41065]

@ Bernd:
Idealerweise kriegst du mstrens ja dazu die Funktion in den OpenXSensor mit aufzunehmen, dann hast du 2 Fliegen mit einer Klappe erschlagen:
- Korektur des Vario direkt über SBus (d.h. kein zusätzlicher HW-Empfängerkanal mehr)
- SBus-Fehlerauswertung ...
- nicht noch ein Sensor der mitfliegen muss. ( Bei meinen Schiffen spielen Grösse und Gewicht ja keine Rolle...)

Ralf

 

[Carbonator]

Ralf, ich habe alles versucht, bis meine Knieschützer durchgeschliffen waren -> keine Chance, dass er kurz/mittelfristig was macht. Und wenn wir ehrlich sind, das Thema hat ja, seit die Horus Failsafes erledigt sind, keine hohe Priorität mehr. Es wäre eher "Grundlagenforschung" ,aber, wie du schreibst, der Winter ist noch lang.

Gruß Bernd

 

[headwind]

Hi,

ich melde mich gerne noch mal, um ein paar Punkte aus meiner Sicht zu klären :

- die Auswertung korreliert mit RSSI nicht, der RSSI geht runter, und recht kurz bevor gar nichts mehr geht, kommen die ersten Packets mit der SIGNAL_LOST Information. Das ist ein ultimatives Warnsignal, dass nächstens mit grosser Wahrscheinlichkeit der Telemetry-Lost und dann der Failsafe kommt. Ich habe nicht den Eindruck, dass es sich beim FrSky RSSI um ein RSSI im klassischen Sinne mit nur Feldstärke handelt, sondern bereits AUCH eine Auswertung der Packets (nicht SBUS) stattfindet. Andere wissen bestimmt mehr darüber. Ist nur eine Mutmassung, weil ein paar Sachen sich nicht so verhalten, wie ich es erwartet habe.
- zur Integration in openXsensor : es wundert mich nicht, dass mstrens da passen will. Um das zu implementieren, kommt er um einen Wechsel der Plattform nicht herum. Und das ist eine Sache, die mE nicht so einfach zu erledigen ist. Ich habe das letztes Jahr versucht und habe es nach ein paar Tagen aufgegeben. openXsensor ist für mich zu hardwarenah programmiert. Ich hatte Mühe, das Ganze innert nützlicher Frist zu lesen, zu verstehen und zu portieren. openXsensor hätte Ausgangsbasis für ein Projekt sein sollen - und für das konnte ich es nicht verwenden. Man soll mich nicht falsch verstehen - als openXsensor funktioniert es auf einem Nano immer noch bestens und ich bin froh, dass ich es habe. Trotzdem - ich beschäftige mich nicht mehr weiter damit - aber eine tolle Vorlage war es.

- für diverse Teile von openXsensor gibt es recht ausgereifte Libraries, die für meine Begriffe sehr schön programmiert und dokumentiert sind, zB die MPU9250 und UBLOX Libs von BRTaylor und die Lib für die FrSky-Telemetrie von Pawelsky. Die Libs für den MS5611 und den SBUS liegen eigentlich abrufbereit vor, und von Prunkdump gab es auch schon mal eine respektable Version eine Varios. Sieht auf meinem Arduino-Plotter seeehhhr gut aus. Für mich ein Grund, um wenn nicht von vorne, so doch in der Mitte etwas Neues zu beginnen

mfg hw

 

[Carbonator]

....die Auswertung korreliert mit RSSI nicht, der RSSI geht runter, und recht kurz bevor gar nichts mehr geht, kommen die ersten Packets mit der SIGNAL_LOST Information.

Bei einem Test hatte ich mal ein PPM Dreieckssignal zum oXs geschickt, habe dann das decodierte PPM Signal beim Reichweitentest gelogt. Selbst bei RSSI < 30 war das Signal noch vollständig. Das spricht für deine Beobachtung. Das ganze ist eher akademisch, es wäre halt für viele beruhigend, zu wissen, dass selbst bei niedrigem RSSI noch nachweisbar Übertragungssicherheit besteht. Wenn man diesen Test im Rangetest durchführt, reißt auch die Telemetrie nicht vorher ab. Ein zwei sorgfältige Tests und das Thema ist gegessen. Ein ständiges Messen im Modell halte ich (zur Zeit) für unnötig. Meines Erachtens handelt es sich aber beim RSSI tatsächlich (nur) um die Feldstärke. Die Datenübertragung bleibt aber sehr lange ungestört und erst relativ knapp vor der Reichweitengrenze gehen erste Frames verloren.

- zur Integration in openXsensor : es wundert mich nicht, dass mstrens da passen will.

Die Integration in oXs war nie ein Thema mit mstrens, es sollte immer ein standalone Gerät zu Testzwecken werden, s.o..

Ich bin lediglich der Testflieger und User, mir ist die technische Basis egal. Die Sensoren müssen einfach nur richtig gut funktionieren. Ich habe noch nix Besseres als den oXs gefunden. Wenn du mal was getestet haben willst, sag Bescheid. Ich habe meine eigene Wiese beim Haus (WLAN) und meine Segler sind montiert. Tests und Datenübermittlung gehen da ruckzuck.

Gruß Bernd

 

[headwind]

Hi Carbo

alles klar, falls Du testen willst, kauf Dir :

- einen Teensy 3,6
- eine MPU9250 von Sparkfun oder etwas vergleichbares
- einen MS5611 von Drotek, was anderes standalone geht wahrscheinlich auch, ich konzipiere das standalone für den Einbau mit MS4525DO und Jeti-Pitot in der Seitenflosse, um die Leitungen für Dyn+Stat-Druck kurz zu halten, die I2C-Leitungen sind 4 Litzen für beide
- einen MS4525DO von Drotek

Mein Projekt :

- SBUS wird in den Teensy gespeist
- Sensordaten werden erfasst (MPU9520, MS5611)
- Teensy berechnet auf Grund der Beschleunigung Klappenausschlag für einen Hacker Vagabond, (+g -> -Wölb runter, -g -> Wölb runter), mit entsprechender Höhenruderkorrektur, nur mal so zum ausprobieren, keine Ahnung was da passiert, kann gut sein, dass das erst mal aus dem Ruder läuft.
- Ausgabe Q/W und H über PWM, (der Teensy kann 22 PWM-Kanäle). SBUS auf PWM hab ich soweit im Griff, auf 8-Kanäle skaliert mit T3.2 ausprobiert.

- Vario mit MS5611 und MPU9250, MPU9250 über Madwick von Krisweiner für reine Beschleniugung in z-Achse (sowie pitch, roll, yaw/heading), wird fusioniert mit Daten von MS5611 über Kalman-Filter von prunkdump, den MS4525DO lass ich mal, da ich mit der Braunschweiger zufrieden bin. Das Auslesen der Geschwindigkeit möchte ich bis nächsten Frühling machen. Über zwei SBUS-Kanäle kann der Einfluss der IMU sowie die Sensitivität beider eingestellt werden.


Telemetrie : da ist eine Menge an Daten verfügbar. Ich muss das SPort polling von FrSky noch genauer anschauen, besonders der freien Adressen.
Pawelsky macht es vor, wie es geht - eine eigene Sensorklasse habe ich noch nicht versucht. Ich hoffe, ich habe verstanden, wie es geht. Die Abfrage freier Adressen habe ich im polling schon gesehen. Eilt meinerseits nicht - ich schau den Kram sowieso nicht an, und zu Aufzeichnen ist mir die SD-Karte lieber.

-GPS - noch nichts gemacht
-SD-Karte : noch nichts gemacht, auf Teensy 3.6 card-Holder drauf und Libs ok, Dreh- und Angelpunkt zum Testen, da kann eine Menge an Daten drauf - so lassen sich allerhand Fehler finden.

- MS4525DO, noch wenig gemacht, Libs sind mir bekannt

Langfristig : in zB XFLR5 Polaren eines Flügels erfassen, auf SD-Karte speichern, Programm ermittelt anhand Sensordaten und Polardaten laufend, welche Klappenstellung die optimalste ist. Hier möchte ich spätestens den MS4525DO oder etwas ähnliches dabei haben.

Ich mache nichts mehr mit Unos, Micros und Nanos. Das Zeug was ich mache geht zum einen platzmässig nicht mehr drauf, zum zweiten mache ich mir das Leben wegen ein paar Euros nicht mit allerhand programmtechnischen Verrenkungen schwer.

Also - kein Fragen nach Nano und co. und pure PNP - plug and pray.

mfg hw

 

[Carbonator]

@hw: Da hast du ja Einiges vor. Ich werde erstmal noch etwas abwarten, bis sich dein Projekt konkretisiert. Der oXs läuft so perfekt, eigentlich bin ich zur Zeit glücklich damit.

Ich hab gestern noch ein bißchen mit deinem Sketch dilettiert. Wenn alle geforderten libs vorhanden sind, könnte es auf dem Arduino funktionieren, wenn man die serial durch softserial ersetzt. Die fehlende .....polling.h habe ich hier gefunden. Jetzt kommt die erste Fehlermeldung beim Aufruf der serial1, die beim pro mini nicht vorhanden ist.

 

[Carbonator]

Die Neugier hat doch gesiegt und ich habe eben einen Teensy 3.2 getestet. A3 und A4 werden übertragen. Leider kommt öfter "Sensor lost". A3 und A4 kommen nur gelegentlich im Sekundenrhythmus, dann gibt es längere Pausen, die teilweise so lange anhalten, dass sie zur "Sensor lost"-Meldung führen.

 

[headwind]

Die Neugier hat doch gesiegt und ich habe eben einen Teensy 3.2 getestet. A3 und A4 werden übertragen. Leider kommt öfter "Sensor lost". A3 und A4 kommen nur gelegentlich im Sekundenrhythmus, dann gibt es längere Pausen, die teilweise so lange anhalten, dass sie zur "Sensor lost"-Meldung führen.

Anhang anzeigen 160201 [/QUOT

Guten Abend

lösche einmal im TX alle Sensoren und starte eine Sensorsuche. Ich hatte A3/A4 auch schon doppelt und dreifach drin.
Falls das nichts hilft - alle Verbindungen io ? Als nächstes in der Arduino/IDE die DEBUG Zeile unkommentieren und schauen was im Monitor so angezeigt wird.(+5V abhängen, GND am Empfänger lassen).
Ich hoffe das hilft weiter.

PS und wichtig : Falls der Teensy nicht am USB hängt, MUSS die DEBUG-Zeile auskommentiert werden, weil er sonst für ewig auf die USB-Verbindung wartet.
while (!Serial)
{
} im setup kann auch raus wenn es stört. Und der Teensy blinkt wenn es läuft

hw

 

[Carbonator]

Es kommen im Schnitt im Debugmode alle 7 s zwei mal A3/A4 hintereinander. Der Serial Monitor ist unauffällig:



Da scheint im S.Port handling was schief zu laufen. Der X4R bringt RSSI (25), RxBt(25) und A2(27), der Teensy A3(7) und A4(7). Das ist alles sauber.

 

[headwind]

A3 und A4 werden nicht gerade häufig abgefragt. Ich versteh Dein Problem nicht.

https://www.rcgroups.com/forums/showpost.php?p=29458513&postcount=8

g8

 

[Carbonator]

Dieses 2Hz Polling ist alle sieben Sekunden mal zu sehen, wenn zwei A3/A4 am Stück kommen. Teilweise kommt aber über 10 Sekunden gar nichts.