Vario mit OpenXsensor - Frsky Lua Scripte fehlerhaft

#21
Guck ich mir an.

Ich bin nicht sicher, wie ich eine Blase mit einem stabilisierten Segler zentrieren könnte. Die ganzen Wackler werden weggeregelt, da hätte ich kein Gefühl mehr, wo ich jetzt bin.
 
#22
Also ich finde keinen oXs VFAS 0x22 Sensor in den Logs. Stell mal bitte die oXs config Dateien ein.
 
#25
Aus deiner config:

#define DATA_ID_FAS 0x22 // 2 used for vfas , current and fuel

Das passt nicht zusammmen, sorry. Du hast ja jetzt die Werkzeuge, um den SPort Stream zu analysieren. Ich sehe keinen Zusammenhang mit dem openXsensor, außer, dass er mehr Traffic verursacht, aber das kann der SPort locker wegstecken. Die Sensor IDs sind sauber, keine Ahnung wo bei dir ein VFAS Sensor 17 herkommt. oXs hat definitiv Sensor ID3 (das ist die 2 von oben, im SPort ist es immer -1) für VFAS. Du willst mir doch nichts auf die Backe malen, oder?
 

hobby1946

Erfahrener Benutzer
#26
Nicht nervös werden bei der Hitze ....

Das stand so auf meiner X10 !
Und das liefert mein fertiger Sensor : ID 0210 /17.
Dabei funktioniert Lua eigentlich bis auf einen Wert am Anfang.


Ich habe in der X10 nochmal alles gelöscht.
Den dir geschickten Sketch nochmal aufgespielt (Nano).
Neue Sensorsuche.
Jetzt hat Vfas die ID 0210/3 - warum das vorher anders war ????

Aber jetzt funktioniert das Lua überhaupt nicht mehr.
Es bringt keinen einzigen Wert.

Ich werde das nochmal loggen.
Muß das ganze erst wieder aufbauen.
 

hobby1946

Erfahrener Benutzer
#27
So nun hier die 2 Dateien.
Das Lua hakelt dabei genauso wie beim Vario-Sensor.

Ich muß mal was vorausschicken. Ich suche gerne Fehler mit. Aber für mich ist es eine sehr große Anstrengung.
Ich kann eigentlich seit über 20 Jahren nichts mehr merken. Lernen geht, aber ich vergesse alles wieder. Ich bin seitdem auch berufsunfähig. Deshalb bitte ich um Nachsicht.
 

Anhänge

#28
Allerhopp ;)

guck dir mal die Befehle im SxR LUA-script an, ich habe die Lese-Schreibkommandos mal rauskopiert. Das Script liest jedes Paket, vergleicht den Inhalt, u.s.w..

Ich behaupte einfach mal, wenn das Script funktionieren soll, dürfen keine SPort Sensoren angeschlossen sein, sonst kriegt es Panik.

Code:
Lesen und prüfen auf ID 26 (27)
 local physicalId, primId, dataId, value = sportTelemetryPop()
    if physicalId == 0x1A and primId == 0x32 and dataId == 0x0C30 then
    
Schreiben mit ID 23 (24)   
    return sportTelemetryPush(0x17, 0x30, 0x0C30, field)
Da gibt es sonst keinerlei Konfliktpotential mit dem openXsensor.
 

hobby1946

Erfahrener Benutzer
#29
Das wäre ja gut.

OK, ich werde das mal testen.
Ich werde mal verschiedene FRSKY Sensoren anschließen und das Lua testen.

Das mit der "falschen" Vfas ID hat sich jetzt gelöst.
Das war kein OXS Sensor, sondern ein anderer Sketch (evtl. von Dir?).
Aber bei dem ging das Lua bis auf 1 Fehler.
 
#30
Das kannst du ja jetzt analysieren. Der SPort Datenstrom besteht aus dem Poll (Anfrage) 0x7E und der Sensornummer, dann antwortet der Sensor, wenn er vorhanden ist und Daten bereithält oder es kommt der nächste Poll an die Reihe. Hat ein Sensor geantwortet, wird er eine Zeitlang öfter abgefragt. Antwortet er immer, wird er ständig bevorzugt angefragt. So regelt sich die Anfragehäufigkeit sozusagen selbst.

Die LUA-Pakete sind ebenfalls Sensorpakete. Unterschied ist halt die Sensornummer. Es ist logisch, dass nicht zwei Sensoren auf die gleiche Sensoranfrage antworten dürfen, sonst gibt es Chaos.
 

hobby1946

Erfahrener Benutzer
#31
Das Lua Script arbeitet mit allen Frsky-Sensoren einwandfrei, auch mit mehreren (GPS, Vario, Spannung)

Mit einem OXS Sensor arbeitet das LUA nicht einwandfrei, es werden 50% der Daten nicht erfasst.
Die erfassten Daten kann man bearbeiten, die nicht erfassten nicht.

Ziehe ich während das Lua-Script läuft den OXS-Sensor ab, werden alle weiteren Daten erfasst.
Stecke ich während das Lua-Script einwandfrei läuft den OXS-Sensor an, werden nicht mehr
alle Daten erfasst.

Die Frsky-Sensoren arbeiten mit den OXS-Sensoren ohne Probleme zusammen.

Was stört das Lua-Script ?
 

hobby1946

Erfahrener Benutzer
#32
Hier ein Arduino Programm was die Spannung über den S-Port überträgt.

Mit diesem Sensor läuft das Lua-Script einwandfrei !

Also muß doch etwas in OXS sein was den Fehler verursacht.
 

Anhänge

#33
Sorry, ich will da nicht mehr Zeit investieren. Nimm doch die "lahmen" Sensoren, wenn es für dich funktioniert. Wenn ich je einen SXR mit oXs benutzen würde, würde ich den oXs halt abstecken, so lange ich den RX konfiguriere. Da bastelt man ja nicht dauernd dran rum.

Ansonsten ist tatsächlich der SPort der einzige Berührungspunkt und den kannst du dir jetzt in allen Detail angucken und deine Schlüsse ziehen. Da gibt es nichts "Mystisches" irgendwo.
 

hobby1946

Erfahrener Benutzer
#34
Also nun habe ich mal weiter getestet.

Sensor OXS nur mit Vfas.

Sobald der Sensor nach dem Einschalten aktiv ist, sendet er bei jedem Aufruf 07xE die Daten.
Damit scheint der RX überfordert zu sein, wenn das Lua-Script auch läuft.
Dies hat dann Aussetzer und ist nicht bedienbar !

Als Vergleichstest habe ich einen anderen Sketch genommen, der auch nur Vfas überträgt.
Dieser sendet bei Aufruf 1x die Daten und dann bei 4 weiteren Aufrufen nichts (Idle-Frame).
Hier läuft das Lua einwandfrei.

Wenn ich mit diesem Sketch bei jedem Aufruf die Daten sende, läuft auch hier das Lua nicht
einwandfrei, Fehler wie bei OXS.

Sende ich die Daten bei Aufruf und einmal nicht bei Aufruf (1x Daten dann 1x IdleFrame) dann funktioniert
das Lua wie es soll.

Ich verstehe nicht, wieso OXS ständig (bei jedem Aufruf) die Daten sendet.
Ist das so gewollt oder ein Fehler ?

Wenn z.B. 4 Idle Frames eingefügt werden, kommen die Daten doch auch noch ca. 10x in der
Sekunde. Das muß doch reichen ?
 

Anhänge

#35
Ich verstehe nicht, wieso OXS ständig (bei jedem Aufruf) die Daten sendet.
Weil er es kann ;)

Du siehst doch, dass, wenn nur der VFAS Sensor vorhanden ist, er bei jedem zweiten Poll abgefragt wird. Dazwischen kommt immer ein anderer von den 28, falls doch mal einer was zu sagen hat.

Diese Automatik ist ein großer Vorteil des SPort. Stell dir vor, was passieen würde, falls alle 28 Sensoren antworten und VFAS nur bei jedem fünften Poll .... Ein oft antwortender Sensor wird bevorzugt behandelt, ein lahmes LUA Script kommt halt nicht oft genug an die Reihe, wenn ein schneller Sensor im Spiel ist.

Nochmal: Das ist ein leistungsfähiger Telemetrieport, wenn man den zweckentfremden will, dann einfach die Sensoren so lange abstecken.
 
#36
Hier die Antwort vom Meister, ganz einfach, wenn man es weiß ;)

Code:
In order to let oXs send less VFAS voltage, you should make a little change in oXs_out_frsky.cpp
instead of
  #if defined(ARDUINO_MEASURES_VOLTAGES) && (ARDUINO_MEASURES_VOLTAGES == YES) &&  ( (VFAS_SOURCE == VOLT_1) || (VFAS_SOURCE == VOLT_2) || (VFAS_SOURCE == VOLT_3) || (VFAS_SOURCE == VOLT_4) || (VFAS_SOURCE == VOLT_5) || (VFAS_SOURCE == VOLT_6) )
   if ( (!vfas.available) && ( oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].available) ){
      vfas.value = oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].value / 10 ;  // voltage in mv is divided by 10 because SPORT expect it (volt * 100)
      vfas.available = true ;
      oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].available = false ;
   }
  #elif defined(AN_ADS1115_IS_CONNECTED) && (AN_ADS1115_IS_CONNECTED == YES ) && defined(ADS_MEASURE) && ( (VFAS_SOURCE == ADS_VOLT_1) || (VFAS_SOURCE == ADS_VOLT_2) || (VFAS_SOURCE == ADS_VOLT_3) || (VFAS_SOURCE == ADS_VOLT_4) )
   if ( (!vfas.available) && ( ads_Conv[VFAS_SOURCE - ADS_VOLT_1].available) ){
      vfas.value = ads_Conv[VFAS_SOURCE - ADS_VOLT_1].value / 10 ;  // voltage in mv is divided by 10 because SPORT expect it (volt * 100)
      vfas.available = true ;
      ads_Conv[VFAS_SOURCE - ADS_VOLT_1].available = false;
   }
  #else


use (2X 1 line added)
  #if defined(ARDUINO_MEASURES_VOLTAGES) && (ARDUINO_MEASURES_VOLTAGES == YES) &&  ( (VFAS_SOURCE == VOLT_1) || (VFAS_SOURCE == VOLT_2) || (VFAS_SOURCE == VOLT_3) || (VFAS_SOURCE == VOLT_4) || (VFAS_SOURCE == VOLT_5) || (VFAS_SOURCE == VOLT_6) )
   if ( (!vfas.available) && ( oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].available) ){
      vfas.value = oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].value / 10 ;  // voltage in mv is divided by 10 because SPORT expect it (volt * 100)
      vfas.available = true ;
      oXs_Voltage.voltageData.mVolt[VFAS_SOURCE - VOLT_1].available = false ;
   }
  #elif defined(AN_ADS1115_IS_CONNECTED) && (AN_ADS1115_IS_CONNECTED == YES ) && defined(ADS_MEASURE) && ( (VFAS_SOURCE == ADS_VOLT_1) || (VFAS_SOURCE == ADS_VOLT_2) || (VFAS_SOURCE == ADS_VOLT_3) || (VFAS_SOURCE == ADS_VOLT_4) )
   if ( (!vfas.available) && ( ads_Conv[VFAS_SOURCE - ADS_VOLT_1].available) ){
      vfas.value = ads_Conv[VFAS_SOURCE - ADS_VOLT_1].value / 10 ;  // voltage in mv is divided by 10 because SPORT expect it (volt * 100)
      vfas.available = true ;
      ads_Conv[VFAS_SOURCE - ADS_VOLT_1].available = false;
   }
  #else

Then, VFAS will be sent only once every 500 msec (by default)
 

hobby1946

Erfahrener Benutzer
#37
Danke erst mal für die Mühe.

Du sagst Sensor einfach abstecken ....

Der große Vorteil des Lua Scriptes ist doch gerade, daß man sein Modell einstellen kann wenn es
in Betrieb ist. Ich meine nicht die Grundeinstellungen, sondern die Anpassungen der Empfindlichkeiten usw.
Wenn man z.B. das Gain auf Querruder verändern will kann man das ohne weiteres Einstellen.
Da muß man sein Modell nicht auseinanderbauen um an den Empfänger zu kommen, die Änderung machen und dann alles wieder zusammenbauen. Nicht immer kommt man einfach so an den Empfänger.

Mag der S-Port noch so leistungsfähig sein ...
Wenn ich Vfas bei jedem Aufruf übertrage, setzt das Lua-Script ständig aus. Also etwas muß da ja "überlastet" sein. Ob Empfänger oder Sender weiß ich nicht.
 
RCLogger

FPV1

Banggood

Oben