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

[Satcomix]

Hello Mstrens, My X20S sends -100% = 988us, 0%=1500us, +100% = 2012us

PWM commands: 1: CH6 988us show 988us at SBUS_out at analyzer 2: CH6 1500us show 1500us at SBUS_out at analyzer 3: CH6 2012us show 2012us at SBUS_out at analyzer But the PWM_out 1-16 show: CH6 988us handheld = 1064us PWM_out at analyzer CH6 1500us handheld = 1596us PWM_out at analyzer CH6 2012us handheld = 2128us PWM_out at analyzer Br, Torsten

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

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

processing cmd

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

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

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

[mstrens]

Note : in this version, I added some parameters in config.h to let the user change the mapping from sbus to pwm value. Currently it uses:

define FROM_SBUS_MIN 172

define TO_PWM_MIN 1000

define FROM_SBUS_MAX 1811

define TO_PWM_MAX 2000

[Satcomix]

I think 988us to 1000us for -100% is ok, and 2012us for 2000us for +100% is ok, in SBUS_out. But the PWM_out 1-16 channels don't match, see last post

[mstrens]

Sorry but I do not understand.

I understood that -100% on the handset gives a PWM of 988 us (on the handset). In order to get also 988us on oXs PWM, I have to know the sbus value that oXs get for -100%. So you should set a channel on -100% and send PWM command on the PC. The PC should then display a value between brackets (says xxx). Then you should change the define

define FROM_SBUS_MIN xxx

define TO_PWM_MIN 988

Do the same for +100%. If yyy is the value between bracket then defines should be

define FROM_SBUS_MAX yyy

define TO_PWM_MAX 2012

[Satcomix]

My X20S sends -100% = 988us, 0%=1500us, +100% = 2012us

PWM commands: 1: CH6 988us show 988us at SBUS_out CH6 at analyzer 2: CH6 1500us show 1500us at SBUS_out CH6 at analyzer 3: CH6 2012us show 2012us at SBUS_out CH6 at analyzer But the PWM_out 1-16 show: CH6 988us handheld = 1064us PWM_out CH6 at analyzer CH6 1500us handheld = 1596us PWM_out CH6 at analyzer CH6 2012us handheld = 2128us PWM_out CH6 at analyzer

[Satcomix]

Terminal PWM command: handheld 988us -100% Cmd to execute: PWM PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1000( 172) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) processing cmd

handheld 1500us 0% Cmd to execute: PWM PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) processing cmd

handheld 2012us +100% Cmd to execute: PWM PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 2000( 1811) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992)

the displayed values ​​are taken from the SBUS_out and displayed almost correctly 988us=1000us 2012us=2000us

[mstrens]

in 2.2.10, I put those define

define FROM_SBUS_MIN 172

define TO_PWM_MIN 988

define FROM_SBUS_MAX 1811

define TO_PWM_MAX 2012

So you should get 988 as reply of PWM command when handset is -100% And 2012 as reply of PWM command when handset is +100%. If so the mapping define are OK.

Now, it could still be that the real width of PWM pulse (measure with a logic analyser) does not match the expected value. If this is the case, then I have to check the program that generates the pulses on the output pins.

[Satcomix]

Handset: X20S CH6 -100%=988us , 0%=1500us , +100%=2012us

Analyzer at CH6 PWM_out at board show: 1051us at 988us handset---not-ok Analyzer at CH6 PWM_out at board show: 1595us at 1500us handset--not-ok Analyzer at CH6 PWM_out at board show: 2140us at 2012us handset--not-ok

Analyzer at CH6 SBUS_out with SBUS-Decoder show: 988us at 988us handset-----ok Analyzer at CH6 SBUS_out with SBUS-Decoder show: 1500us at 1500us handset---ok Analyzer at CH6 SBUS_out with SBUS-Decoder show: 2012us at 2012us handset--ok

Cmd to execute: PWM CH6 ok PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 988( 172) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) processing cmd

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

Cmd to execute: PWM CH6 ok PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 2012( 1811) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992)

My Kingst Analyzer can measure the PWM very well, i made own scripts for my pololu mini maestro 24Ch in Forth script language. :-)) I think you have to check the program that generates the pulses on the output GPIO pins for PWM Ch1-16_out

[mstrens]

Can you measure the enlapsed time between 2 pwm pulses (from rising edge to rising edge e.g). It is expected that it should be 20000 usec. (for all channels when the PWM values are stable) The RP2040 is supposed to run at 133mHz. The PWM part is quite simple. In the program, I configure

• a divider to 133 in order to let the PWM component runs at 133mHz/133 = 1mHz (=> 1usec).
• a "Top" value = 20000 which means that a new PWM signal must be generated every 20000 usec.
• a PWM counter = is set to the remap of Sbus (e.g. if sbus = 172 then I put PWM counter = 988) If the RP2040 is not running at 133mHz, it could explain the issue. Still it would be the result of an inaccurate oscillator/quartz. This would also have an impact on all the UART signal being read/generated.

[Satcomix]

I made a capture. X20S TD-R10 1500us out to RP2040 PWM_out 1595.985us With 19.6849ms Period 21,2808ms PWM Channels 1, 2, 3 ,4 = 255 255 6 7 (C1 / C16= 0, 1, 2, ..., 15) PWM Channels 5, 6, 7 ,8 = 8 9 10 11

2023-04-24_17-39-31.zip

[mstrens]

So, indeed there is an issue with the RP2040 oscillator. The period is 21.28 ms instead of 20.0 I calculated the ratio between the expected pwm and the real one for the 3 cases (-100, neutral, +100) and it is exactly the same.

if you have several RP2040, it could be nice to check them to see if they all have the same oscillator difference.

[Satcomix]

I'm doing a few more tests with all the other RP2040 boards, it'll take a while. br, Torsten

[Satcomix]

Hello Mstrens, bad news :-( It's the same on all boards. Pulse: 1595us With: 19.6842ms Period: 21.28ms So it shouldn't be the oscillator, or it's bad for all manufacturers (Waveshare/Pimoroni/Cytron). I believe that this problem only affects the GPIO pins with PWM-out. FBUS and SBUS in and out delivers 100% the correct values, telemetry works with full equipment 34 values. It's definitely just a small transposed number in PWM_out. br, Torsten

[mstrens]

It seems that 133 is the max clock freq of RP2040 but that Rapsberry SDK set the clock freq on a different value. Sdk allows to change the clock freq. I added an instruction in new 2.1.11 version in order to change the clock. Perhaps this will help. Can you try with one rp2040?

[Satcomix]

I think the Raspberry SDK uses 125Mhz

[mstrens]

I think too. 133/125 = 1.064 which is the ratio you measured on PWM

[Satcomix]

It should work like this. 987,99us 1.49998us 2.01198us Period: 20.00082ms Frequency: 49.9979Hz

Cmd to execute: PWM CH6 PWM values us (sbus) 1... 8 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 988( 172) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) processing cmd

Cmd to execute: PWM CH6 PWM values us (sbus) 1... 8 1650( 1232) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) processing cmd

Cmd to execute: PWM CH6 PWM values us (sbus) 1... 8 1650( 1232) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 2012( 1811) 1500( 992) 1500( 992) PWM values us (sbus) 9...16 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992) 1500( 992)

[mstrens]

So, it seems 100% OK.

[Satcomix]

So, it seems 100% OK. I should have figured that out too, since most RPi SDKs run at 125Mhz. Thank you again for your work, time and effort. br, Torsten