Airspeed & compensated vertical speed

[Allerhopp]

A pressure probe on SDP31 does not show positive airspeed, it shows exactly zero - using the known working (from M328) probe setup. But negative (compared to the M328 setup) airflow is shown correctly. Compensated Vspeed is always zero. 10:05:02.972 -> Volt 1 = 693 mVolt 10:05:02.972 -> Vspeed = -4 cm/s 10:05:02.972 -> Baro Rel altitude = 100 cm 10:05:02.972 -> Airspeed = -16 cm/s <-- without airflow through the sensor 10:05:02.972 -> Compensated Vspeed = 0 cm/s 10:05:13.958 -> processing cmd 10:05:13.958 -> 10:05:13.958 -> Cmd to execute: FV 10:05:13.958 -> 10:05:13.958 -> Volt 1 = 772 mVolt 10:05:13.958 -> Vspeed = 0 cm/s 10:05:13.958 -> Baro Rel altitude = 115 cm 10:05:13.958 -> Airspeed = -2930 cm/s 10:05:13.958 -> Compensated Vspeed = 0 cm/s

[mstrens]

I can easily reverse the sign of the airspeed to get it in the same way as Avr328 but I presume this is just a convention.

Anyway, I have to check why the compensated Vspeed is always 0

[Allerhopp]

Ah, OK - I thought there should be positive and negative numbers using the fv command. But I got zero or negative - never positive. No matter which airflow was given.

[mstrens]

Normally you should get

• with FV positive and negative values
• on the TX (with sport) only positive values (or 0 when FV is negative). If it is not so, I expect I have a bug somewhere.

[Allerhopp]

I've got 0 or negative values with FV Always 0 on the handset with SPort

[mstrens]

I fixed the bug about airspeed in 1.8.0 (available on github). I did not (yet) looked at compensated Vspeed.

[Allerhopp]

Airspeed shows numbers in an expected range. But when you're on it, there is a always positive offset between 100 to 130 cm/s.

Compensated VSpd is still zero, but no hurry, the weather is still not suitable ;-)

[mstrens]

I hope compensated Vspeed is now calculated (and not always 0) in version 1.8.1 About airspeed, oXs code does not apply offsets. I had expected that the sdp31 did not have to be calibrated. I use as is the values provided by the sensor. This is the way I did also in oXs on pro mini.

On Pro mini, is it so that there was no offset?

[Allerhopp]

On Pro mini, is it so that there was no offset?

This was my first test with pro mini walking with a scale of 10 in the sketch. It seemed to be a perfect 0 without movement. But in some versions you had a deadzone in the code for airspeed with 10 km/h. Not sure about this version ...

But another test with RP showed airspeed is limited to 2,59 m/s max. VSpd works as usual. Compensated VSpd is a little bit noisy at rest (just as if it is working), but it reacts neither on altitude nor on airspeed changes.

[Allerhopp]

You added a debug routine for SDP. Changing airflow changes the numbers. The file contains a session at the end where the sensor goes in saturation (ff7f). SDP_debug.zip

[mstrens]

sorry, the way the data are generated are unclear. I changed the format in a version 1.4.8 on github. I hope this this will be easier to understand

[Allerhopp]

I will have to dig deeper into the dataformat. Meanwhile here are 2 files. One at rest and one blowing over the nozzle. A SDP810 sensor is ordered so I will be able to crosscheck with this one next week .... Debug_2x.zip

[mstrens]

With the last log, I saw that there was a bug in the way oXs calculates the diff pressure from the sdp3 sensor. It seems that the sdp3x does not need an offset. I presume the version 1.8.5 (now on github) should fix it and so you should have a better airspeed. If Ok, I will remove the debug messages I added.

[Allerhopp]

Thanks! Airspeed shows the expected data now. Compensated VSpeed and the corresponding variosound are still erratic and need some love ;-) Will try to gather some flying data over the weekend.

[mstrens]

There should be a bug in the way compensated Vspeed is calculated. I will have to check the code and probably add some more debug msg in this part of the code. I will remove the previous debug msg. I will post a msg when it is done (not intermediately I think except if the bug is trivial)

[mstrens]

I already saw a bug about compensated airspeed. I fixed it. Perhaps it was the only one. I did not add new debug msg but removed the previous one. Version 1.8.6 is available on github

[Allerhopp]

Thanks again! DTE Vario reacts now as expected and OpenTX produces a nice sound using this compensated VSpd. Ready for some flying now :-) It will be exciting to see how well the timing of VSpd and airspeed go together.

Btw. Do you have plans to add a pssibility to switch varios? Now both varios are transmitted but this uses more bandwidth and it is hard to switch on the fly. I'm not even sure, if LUA allows to switch vario source. Tuning compensation in flight was also a nice feature with the "old" oXs.

[Satcomix]

Hello Mstrens, Allerhopp had already asked about the "tuning compensation" function, i.e. like the older oXs_on_Arduino via PWMin port. Would this option be possible? or did you already plan it for next comming versions? br, Torsten

[mstrens]

For sure, I do not plan to tune the compensation with a PWM in port. There are several other way to do it; each has pro and con:

• I could a parameter in file config.h to setup the compensation coefficient. Pro: very easy to do; it should work for all protocols because it does not require that oXs get a rc channel (via sbus, ELRS Fbus, Exbus,..) Con: it does not allow to tune the compensation while flying It requires that the user change the config.h and compile him self

• I could add a command to enter the compensation coefficient via the PC serial terminal Pro/con : same as with config.h except that user does not have to compile him self.

• I could add a parameter in config.h (or a command to enter via the Pc serial terminal) to select a RC channel to be used to adapt the coefficient while flying. Con : oXs code is more complex to write; It does not work when oXs does not get the Rc channels (e.g. with jeti non exbus).

I have not yet decided the option to implement.

[Satcomix]

Hello Mstrens, I may have expressed myself a bit wrong, but your last point is exactly what I and Allerhopp (I suspect) meant as a function. The non-plus-ultra would of course be your second point combined with the third point. With protocols that do not support SBUS, the user could enter the compensation coefficient himself via the terminal, not everyone can compile him self. Your point three would be interesting for users with SBUS/FBUS protocol. For example: If point two is set, point three cannot be executed. Or, if point three is executed, point two cannot be set. I know it's like you wrote a lot of work. You have to know and program it, we can only help with testing. br, Torsten

[mstrens]

I put a version 2.2.5 on github (test branch). In this version:

• you can define a default compensation factor in config.h. It is set to 1.15 (same as in arduino oXs)
• you can enter a command VCC (Vspeed Compensation Channel) = X where X = 1...16 (= a channel) or 255;
• When 255, it means that a rc channel is not used and so oXs works as before (Airspeed compensated Vspeed is calculated and transmitted with default factor from config.h)
• when a channel is specified but oXs does not get a RC value, oXs works as before
• when a channel is specified AND oXs get a Rc value, there are 3 cases depending on the value of the RC channel.
• When the rc value is above center position (in fact when 11 bit digital internal value from Sbus is more than 0X0500; 0X0400 being about the center position), then oXs will use the Rc value to calculate compensated vpeed factor. Factor will varies between 0.9 and 1.4 depending on the Rc value; Furthermore, compensated Vspeed will be transmitted and contain the compensated Vpseed.
• When rc value is around center (in fact between 0X0200 and 0X0500), oXs will work as if there would be no channel defined
• When rc channel is low (less than 0x0200 ; so you can try a -100% on Tx), oXs will transmit the compensated vspeed but this field will be filled with the same value as normal Vspeed. This allows to let the vario play sound based on normal vario or compensated vario depending of a switch on Tx. Note: in this case, compensated vspeed is still calculated (based on previous factor) but not transmitted.

This is supposed to work for all protocols. This has not been tested at all.

[mstrens]

I forgot to say that when you use the command FV, it will display the current compensation factor. So, you can, e.g. activate a channel to setup the compensation factor while flying. At home, you can display the factor being used (using command FV) and then you can change the value in config.h and disable the Vspeed compensation channel (e.g. to use it for another purpose)

[mstrens]

Another use case of FV command is the following. At home while oXs is connected to the PC you can experiment which range of Rc channel values are used to switch between the different cases (min RC % to get compensated vspeed filled by normal vspeed, min RC % value to get 0.9 compensation, RC % to get 1.4 compensation)

[Satcomix]

Hello Mstrens, thank you very much for that work. I will download the new release 2.2.5 and do some tests, with all the settings you mentioned. br, Torsten

[Satcomix]

Hello Mstrens, I have set and connected everything. I work with FrSky X20S FBUS PWM channel 6 for airspeed compensation. One question, if I change the setting from 1500us to 1750us on my handheld, I should also see this change in the Vspeed compensation in the terminal at FV, right? This always shows 1.15). br, Torsten

processing cmd

Cmd to execute:

Version = 2.2.5 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 6 7 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 9 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Fbus(Frsky) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 353 , 448 , -2735 Gyro offsets X, Y, Z = 12 , -161 , -196 Aispeed sensor is detected using MS4525 No Vspeed compensation channel defined; oXs uses default settingsFirst analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix Failsafe uses predefined values Chan 1...4 = 992 , 992 , 992 , 992 Chan 5...8 = 992 , 992 , 992 , 992 Chan 9...12 = 992 , 992 , 992 , 992 Chan 13...16= 992 , 992 , 992 , 992

Config parameters are OK Press ? + Enter to get help about the commands

processing cmd

Cmd to execute: FV

GPS Latitude = xx.xxxxxxxxxxx degree GPS Longitude = x.xxxxxxxxxx degree GPS Groundspeed = 5 cm/s GPS Heading = 30.580000 degree GPS Altitude = 4933 cm GPS Num sat. = 118 GPS Date J M A = 20 4 23 GPS Time H M S = 10 31 59 GPS Pdop = 118 GPS Home bearing = 351 degree GPS Home distance = 7 m Volt 1 = 1575 mVolt Current (Volt 2) = 1669 mA Volt 3 = 1614 mVolt Volt 4 = 263 mVolt Capacity (using current) = 503 mAh Vspeed = 3 cm/s Baro Rel altitude = 144 cm Pitch = -8 degree Roll = -1 degree RPM = 1007 Hertz Ads 1 1 = 118 mVolt Ads 1 2 = 118 mVolt Ads 1 3 = 118 mVolt Ads 1 4 = 119 mVolt Ads 2 1 = 118 mVolt Ads 2 2 = 118 mVolt Ads 2 3 = 118 mVolt Ads 2 4 = 118 mVolt Airspeed = 12 cm/s Compensated Vspeed = -35 cm/s Gps cumulative distance = 34 Vspeed compensation = 1.15)

[Satcomix]

No Vspeed compensation channel defined; oXs uses default settingsFirst analog to digital sensor is detected using ads1115 VCC=6 for PWM Channel 6, but it doesnt work.

[mstrens]

I made a new version (same nr) with a debug message to see what is the Rc channel value

[Satcomix]

comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400 comp 400

[mstrens]

again a new version with more debug msg

[Satcomix]

I take VCC=6 ????

channel= 0 comp 400 channel= 0 comp 400 channel= 0 comp 400 channel= 0 comp 400 channel= 0 comp 400 channel= 0

[mstrens]

Channel was not saved. I fixed it but I change the command from VCC to ACC. So please use first ACC=6 before continuing testing.

[Satcomix]

I think, it works. Now I can see the changes, when i turn the poti on ch6 at my handheld. but the debug messages are now somewhat annoying in order to compare the values ​​in the FV terminal. br, Torsten

[Satcomix]

Here the results in .txt, when i turn from 1500us to 2000us and back over 1500us to 1000us with ACC=6 ACC_6_Airspeed_Comp.zip

[mstrens]

I removed debug msg in version 2.2.6 It is quite surprising that 2000 usec gives only a value of 0X713. I made a change in order that 2000 usec gives about a compensation factor of 1.4

[Satcomix]

Hello Mstrens, It now works better on FV without debug messages. I receive from: 1500us to 1675us 1.15 1677us 0.90 1680us 0.91 1690us 0.92 1700us 0.94 1800us 1.10 1830us 1.15 1900us 1.26 2000us 1.40

So everything should work. Sometimes i get sbus messages at the end from FV

processing cmd

Cmd to execute:

Version = 2.2.6 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 6 7 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 9 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Fbus(Frsky) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 353 , 448 , -2735 Gyro offsets X, Y, Z = 12 , -161 , -196 Aispeed sensor is detected using MS4525 Vspeed compensation channel = 6 First analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix Failsafe uses predefined values Chan 1...4 = 992 , 992 , 992 , 992 Chan 5...8 = 992 , 992 , 992 , 992 Chan 9...12 = 992 , 992 , 992 , 992 Chan 13...16= 992 , 992 , 992 , 992

Config parameters are OK Press ? + Enter to get help about the commands

processing cmd

Cmd to execute: FV

GPS Latitude = XX.XXXXXXX degree GPS Longitude = X.XXXXXX degree GPS Groundspeed = 11 cm/s GPS Heading = 255.670000 degree GPS Altitude = 2429 cm GPS Num sat. = 115 GPS Date J M A = 20 4 23 GPS Time H M S = 16 5 15 GPS Pdop = 176 GPS Home bearing = 161 degree GPS Home distance = 11 m Volt 1 = 1576 mVolt Current (Volt 2) = 1670 mA Volt 3 = 1614 mVolt Volt 4 = 263 mVolt Capacity (using current) = 586 mAh Vspeed = 0 cm/s Baro Rel altitude = -57 cm Pitch = 0 degree Roll = -2 degree RPM = 998 Hertz Ads 1 1 = 118 mVolt Ads 1 2 = 118 mVolt Ads 1 3 = 118 mVolt Ads 1 4 = 118 mVolt Ads 2 1 = 118 mVolt Ads 2 2 = 118 mVolt Ads 2 3 = 118 mVolt Ads 2 4 = 118 mVolt Airspeed = 1323 cm/s Compensated Vspeed = -6 cm/s Gps cumulative distance = 89 Vspeed compensation = 0.90 fbus: first pos not a valid length frame

br, Torsten

[mstrens]

Using a FV blocks the cpu for a quite long time (because it has to print all the chars). So, it happens that RP2040 discards some chars received on the sbus/fbus. This should not happen in normal use of oXs (when not connected to a PC)

[Satcomix]

Hello Mstrens, If there is nothing more to test, I would like to thank you very much for this new good feature. I will write to Allerhopp that he can close that issue when he is satisfied. And the issue of the M10 GPS was reopened by you, in my opinion it could also be closed. br, Torsten

[Allerhopp]

Great news! Here are my findings with 2.2.6 and SBus (FrSky): Compensation adjustment: 1680 µs -> 1,15 1681 µs -> 0,90 1700 µs -> 0,93 1750 µs -> 1,01 1800 µs -> 1,09 1850 µs -> 1,17 1900 µs -> 1,24 1950 µs -> 1,32 2000 µs -> 1,40 Switching compensated/not compensated: <= 1200 µs -> not compensated

= 1201 µs -> compensated (Edit: I wrote greater equal - Github changed it)

Two VSpd are transmitted simultaneously. Baro VSpd (0110) and switchable VSpd (011F).

It will be exciting to see how well the timing fits between the two pressures. IIRC with Arduino I had to reduce vario-sensitivity to about 50 to get time alignment. Unfortunately the weather in southwest Germany is still not good enough for meaningful testflights.

[Allerhopp]

@Satcomix a spineless and humourless mouse pusher muted me in RC-Network. Even PN are blocked. RCGroups is the way to go ;)

[Allerhopp]

It was very gusty but still got some decent data. Energy compensation works. About 110 % compensation seems to be the sweet spot. Here my mixer for compensation and switching VSpd to get the full range on a pot (F2):

XL_3200_RP-2023-04-22-GPS.zip

Airspeed jumps a bit but this may result from my DIY pitot tube. A more rounded inlet may help here. SDP airspeed sensors need more througput. Standard pitot like Jeti/Hacker duplex do not work with SDP but are perfect for MS4525. Overall very happy with the actual development. Only "Hdg" should be multiplied with 100 to match 5102 (home bearing) format.

[Satcomix]

Hello Mstrens, After successfully checking all possible settings of the latest test version, a thought came to me: Is it possible to transmit the PWM value of a selected channel, 1-16, to the handheld via telemetry value in us? e.g. range 1000us to 2000us. br, Torsten

[mstrens]

I would like to avoid this. It would require one more parameter, would consume some telemetry bandwidth and would not work with many protocols. Knowing the PWM value has a limited interest (e.g. to make the setup for airspeed compensation). I think it would be enough and easier to add a pc command to get (on request) the PWM values for the 16 channels.

[Satcomix]

Hello Mstrens, Many thanks for the quick response. Your suggestion with the PC command would suffice perfectly. Something else occurs to me: The values ​​displayed when failsafe is activated are processing values ​​of the oXs, but are not shown in the corresponding PWM values. Would it be a big hassle to change this? Since I'm using the FBUS and Failsafe, I recognize 992 as 1500us. Could this 992 be converted to show 1500us. Greeting, Torsten

[mstrens]

You can try version 2.2.7 I added command PWM (to display PWM values - if they are known). I also converted failsafe values to usec.

[Satcomix]

Hello Mstrens, Thank you for your work and effort! The values ​​of Ch 1-16 are not displayed correctly yet. 1000us show 938us 1500us show 1409us 2000us show 1880us Everything in the handheld is set to middle = 1500us, but 1409us is shown in Terminal br, Torsten

processing cmd

Cmd to execute:

Version = 2.2.7 Function Pin Change entering XXX=yyy (yyy=255 to disable) Primary channels input = 5 (PRI = 5, 9, 21, 25) Secondary channels input = 255 (SEC = 1, 13, 17, 29) Telemetry . . . . . . . . = 255 (TLM = 0, 1, 2, ..., 29) GPS Rx . . . . . . . . . = 12 (GPS_RX = 0, 1, 2, ..., 29) GPS Tx . . . . . . . . . = 13 (GPS_TX = 0, 1, 2, ..., 29) Sbus OUT . . . . . . . . = 2 (SBUS_OUT= 0, 1, 2, ..., 29) RPM . . . . . . . . . . = 4 (RPM = 0, 1, 2, ..., 29) SDA (I2C sensors) . . . . = 14 (SDA = 2, 6, 10, 14, 18, 22, 26) SCL (I2C sensors) . . . . = 15 (SCL = 3, 7, 11, 15, 19, 23, 27) PWM Channels 1, 2, 3 ,4 = 255 255 6 7 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 255 9 255 255 PWM Channels 9,10,11,12 = 255 255 255 255 PWM Channels 13,14,15,16 = 255 255 255 255 Voltage 1, 2, 3, 4 = 26 27 28 29 (V1 / V4 = 26, 27, 28, 29)

Protocol is Fbus(Frsky) CRSF baudrate = 420000 Voltage parameters: Scales : 1.000000 , 1.000000 , 1.000000 , 1.000000 Offsets: 0.000000 , 0.000000 , 0.000000 , 0.000000 No temperature sensors are connected on V3 and V4 RPM multiplier = 1.000000 Baro sensor is detected using MS5611 Sensitivity min = 100 (at 100) , max = 300 (at 1000) Hysteresis = 5 Acc/Gyro is detected using MP6050 Acceleration offsets X, Y, Z = 353 , 448 , -2735 Gyro offsets X, Y, Z = 12 , -161 , -196 Aispeed sensor is detected using MS4525 Vspeed compensation channel = 6 First analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Second analog to digital sensor is detected using ads1115 Measurement setup: 4 , 5 , 6 ,7 Gains: 1 , 1 , 1 ,1 Rates: 5 , 5 , 5 ,5 Offsets: 0.000000 , 0.000000 , 0.000000 ,0.000000 Scales: 1.000000 , 1.000000 , 1.000000 ,1.000000 Averaged on: 10 , 10 , 10 ,10 Foreseen GPS type is Ublox (configured by oXs) :GPS is detected and has a fix Failsafe uses predefined values Chan 1...4 = 1409 1409 1409 1409 Chan 5...8 = 1409 1409 1409 1409 Chan 9...12 = 1409 1409 1409 1409 Chan 13...16= 1409 1409 1409 1409

Config parameters are OK Press ? + Enter to get help about the commands

processing cmd

Cmd to execute: PWM PWM values (us) 1... 8 1409 1409 1409 1409 1409 1409 1409 1409 PWM values (us) 9...16 1409 1409 1409 1409 1409 1409 1409 1409

[mstrens]

When the handset transmits the Rc channel value, it does not transmit (in most protocols) the PWM value in usec (e.g. in range 1000/2000 or if extended e.g. 750/2250) because it would require more bits on the RF. So e.g. sbus uses a codification on 11 bits (range = 0/2047) ELRS uses a codification on 10 bits (range = 0/1023) (oXs convert is to 11 bits just multiplying by 2). It means that on handset there is a remap to convert PWM values to the 11 (or 10 bits). On oXs there is a similar remap to convert the e.g. sbus value to a PWM value. The issue is that (I expect) each handset/protocol uses a different mapping and so oXs should also use a different mapping. Currently oXs uses a mapping that convert

• sbus = 260 to PWM 988 us and
• sbus 2041 to PWM 2012 us I think those values where selected because they match ELRS (or Frsky?) protocol.

To further analyse (e.g. test with different handsets/protocols) I made a version 2.2.8 that display for PWM both values: PWM (in us) and Sbus (no dimension)

[Satcomix]

1. Set Ch 6 to 1000us
2. Set Ch6 to 1500us
3. Set Ch6 to 2000us

Failsafe uses predefined values Chan 1...4 = 1409 1409 1409 1409 Chan 5...8 = 1409 1409 1409 1409 Chan 9...12 = 1409 1409 1409 1409 Chan 13...16= 1409 1409 1409 1409

Config parameters are OK Press ? + Enter to get help about the commands

processing cmd

Cmd to execute: PWM PWM values us (sbus) 1... 8 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 938( 172) 1409( 992) 1409( 992) PWM values us (sbus) 9...16 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) processing cmd

Cmd to execute: PWM PWM values us (sbus) 1... 8 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) PWM values us (sbus) 9...16 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) processing cmd

Cmd to execute: PWM PWM values us (sbus) 1... 8 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1880( 1811) 1409( 992) 1409( 992) PWM values us (sbus) 9...16 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992) 1409( 992)

[Satcomix]

Hello Mstrens, What surprises me a bit are the read PWM values ​​of Ch1-16 of the SBUS with a SBUS Decoder and PWM checker/analyzer, but the output values ​​of the individual PWM channels on oXs are not correct. The values ​​of my handheld X20S send from 988 to 2012us at 100%. SBUS_out also shows 988 to 2012us, on each individual channel. Only the individual outputs on the oXs PWM_out show values from 1000 to 2000us.

[mstrens]

So, I understand that when X20s is:

• on -100%, handset says that PWM = 988 us and you sbus decoder also says 988us
• on +100%, handset says that PWM = 2012 us and you sbus decoder also says 2012us

What are the values that previous version of oXs gives between brackets when handset is at -100% and at +100%? Knowing those values should allow to adapt the mapping.

[Satcomix]

Hello Mstrens, The previous versions have the same values, I think. I can only see in previous versions the output of failsafe settings. I had addressed this topic a few months ago, I must have expressed myself somewhat incomprehensibly, sorry. br, Torsten

[mstrens]

can you try new version 2.2.9. Using PWM command should display 2 values for each channel. The first one is the pwm (in us) and the second (between brackets) is the internal sbus value. I would like to know the value between brackets for a channel set to

• -100% (so with an expected PWM = 988 us)
• +100% (so with an expected PWM = 2012 us)