RSSI input from ADC not working

[AndreasAntener]

@LorenzMeier it's possible that this initialization prevents your low pass filter from working: https://github.com/PX4/Firmware/pull/2061/files#diff-90c6aed97501efd7bedd6fcdae61601bR184

[AndreasAntener]

Related #2061

[LorenzMeier]

I don't have this set up. It will need someone to be debug. @dogmaphobic interested?

[dogmaphobic]

I don't have the hardware for it but I could emulate it (by feeding 0-3.3v to the ADC directly). My receivers output RSSI through PWM and I have not gotten around to build a circuit to convert it to a simple 0-3.3v DC level.

[dogmaphobic]

Added the comment before reading the full #2061 thread. Let me see what I can find...

[dogmaphobic]

Sorry, I've been swamped all day today. I have never built the firmware from sources. Looking at the wiki and wherever else I could find, things seem to be awfully outdated. I couldn't figure out how to set up the environment and how to build it. I will look at it further tomorrow...

[LorenzMeier]

The guides are completely up to date, I verified just a couple of days ago.

You don't need a circuit to get something close and reasonable. The PWM is low passed and hence becomes a valid voltage.

[dogmaphobic]

My bad. I don't use homebrew, I use MacPorts instead. When I saw this:

brew tap PX4/homebrew-px4
brew update
brew install genromfs
brew install kconfig-frontends
brew install gcc-arm-none-eabi

I assumed it was going to look for a file named homebrew-px4 in a directory called PX4, neither of which exist. I now just typed as is and it worked. It didn't occurred to me it was registered with homebrew.

I will try again :)

[LorenzMeier]

Unless you have good reasons to stick with MacPorts I would recommend homebrew. By now you just can't compare the two and my experience with homebrew has been consistently better.

[dogmaphobic]

No particular reason other than it's what I've been using for the past 10 years. Fink before that. I had homebrew installed a couple months ago just to look at it (while looking for ARM toolchain for the RPI2) but have not gotten around to use it. I wish for 48-hour days :)

[dogmaphobic]

Ok, going through my list of flagged message to look later, I bumped into this. Right off the bat, mavlink_rc_channels_t.rssi is always zero (firmware stable and master). I have the RSSI signal off the RX8 going into the Pixhawk's SBUS input (pin 103?).

With that said, should these below be set to something specific?

[LorenzMeier]

That is for RSSI via PWM on a PPM stream (a radio channel, in this case the first one). Not for the analog one that you're using or a plain PWM channel. The issue you're facing is a bug, not a config issue (or the default config is bad)

[dogmaphobic]

Anything specific I should try/do?

[LorenzMeier]

Run px4io status and look for either RSSI_PWM or RSSI_ADC. If you don't get the ADC flag its a config issue to be solved.

If its not config, the most likely issue is in this file, maybe in the init or math here:
https://github.com/PX4/Firmware/blob/master/src/modules/px4iofirmware/controls.c#L187-L199

Also maybe put a printf here and make sure we don't enter the condition by default:
https://github.com/PX4/Firmware/blob/master/src/drivers/px4io/px4io.cpp#L1701

Those are all the locations involved in generating the value, so one of them should be responsible.

[dogmaphobic]

Sorry but this is all new territory for me. I've added some printfs here and there to check some values (and to see if some portions of the code run at all) but I do not know where the output of those printfs are going to. They don't show up at the nsh console.

For what's worth, here is the output of px4io status (with the radio connected):

nsh> px4io status
px4io: loaded
protocol 4 hardware 2 bootloader 3 buffer 64B crc 0xe603d34c
8 controls 8 actuators 18 R/C inputs 2 analog inputs 0 relays
760 bytes free
status 0x2765 OUTPUTS_ARMED SAFETY_SAFE RC_OK SBUS FMU_OK MIXER_OK ARM_SYNC INIT_OK
alarms 0x0030 FMU_LOST RC_LOST
vservo 4302 mV vservo scale 10000
vrssi 3299
actuators -10000 -10000 -10000 -10000 -10000 -10000 0 0
servos 900 900 900 900 900 900 0 0
reversed outputs: [________]
18 raw R/C inputs 1494 1494 982 1492 982 982 982 982 982 982 1494 1495 982 982 1495 1488 998 998
R/C flags: 0x0018 MAPPING_OK
mapped R/C inputs 0x000f 0:0 1:0 2:0 3:0
ADC inputs 1787 4095
features 0x0008 RSSI_ADC
arming 0x0031 FMU_DISARMED IO_ARM_OK INAIR_RESTART_OK ALWAYS_PWM_ENABLE
rates 0x00ff default 50 alt 400
debuglevel 0
controls 0: 213 -315 -1119 0 0 0 0 0
controls 1: 0 0 0 0 0 0 0 0
controls 2: 0 0 0 0 0 0 0 0
controls 3: 0 0 0 0 0 0 0 0
input 0 min 982 center 1494 max 2006 deadzone 10 assigned 0 options 0x0001 ENABLED
input 1 min 982 center 1494 max 2006 deadzone 10 assigned 1 options 0x0001 ENABLED
input 2 min 982 center 982 max 2005 deadzone 10 assigned 3 options 0x0001 ENABLED
input 3 min 982 center 1492 max 2006 deadzone 10 assigned 2 options 0x0001 ENABLED
input 4 min 1000 center 1500 max 2000 deadzone 10 assigned 100 options 0x0001 ENABLED
input 5 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 6 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 7 min 1000 center 1500 max 2000 deadzone 10 assigned 255 options 0x0000
input 8 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 9 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 10 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 11 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 12 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 13 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 14 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 15 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 16 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
input 17 min 1000 center 1500 max 2000 deadzone 0 assigned 255 options 0x0000
failsafe 900 900 900 900 900 900 0 0
disarmed values 900 900 900 900 900 900 900 900
nsh>

When I turn the radio off, the ADC values change:

ADC inputs 1801 7

[dogmaphobic]

Found it. By default it goes to /dev/null. Running it manually now.

[dogmaphobic]

Sorry, got busy with something else. Back at this. I'm looking at the code that reads the ADC, scales and low passes the value. The math seems wrong and the filter has no history to compute from (rssi is not static and it's always reset to 0 on function entry).

The (unfiltered) code should be something like:

unsigned counts = adc_measure(ADC_RSSI);
/* use 1:1 scaling on 3.3V, 12-Bit ADC input */
unsigned mV = counts * 3300 / 4095;
/* scale to 0..100 (RC_INPUT_RSSI_MAX == 100) */
rssi = (mV * RC_INPUT_RSSI_MAX / 3300);

The low pass filter should be computed for counts, and then fed through the scale/normalize code. To do that, I would need to have some idea about the sampling rate and the PWM frequency (not to mention going back 20 years so I can remember what Chebyshev had to say about this...

Your current filter (v0 * 0.99) + (v1 * 0.01) oscillates too much, which would seem to indicate it's not smoothing properly. This is what the code looks like after I "fixed" it:

    if (r_setup_features & PX4IO_P_SETUP_FEATURES_ADC_RSSI) {
        unsigned counts = adc_measure(ADC_RSSI);
        if (counts != 0xffff) {
            /* low pass*/
            static unsigned _counts = 0;
            _counts = (_counts * 0.99f) + (counts * 0.01f);
            /* use 1:1 scaling on 3.3V, 12-Bit ADC input */
            unsigned mV = _counts * 3300 / 4095;
            /* scale to 0..100 (RC_INPUT_RSSI_MAX == 100) */
            rssi = (mV * RC_INPUT_RSSI_MAX / 3300);
            if (rssi > RC_INPUT_RSSI_MAX) {
                rssi = RC_INPUT_RSSI_MAX;
            }
        }
    }

Or I completely missed something...

[LorenzMeier]

That makes a lot of sense - could you try one order of magnitude larger coeffifiencients, something like 0.999f and 0.001f? Would be worth to experiment to see how long it takes to decay if you shield the receiver.

[dogmaphobic]

Ugh... Before I go crazy here (busted my cheap Chinese logic analyzer in the process), is there another way to read these (pseudo) PWM RSSI signals? This PWM -> ADC doesn't seem feasible based solely on software. I mean "pseudo" PWM because though the X8R specs says it's a PWM signal with a 1ms cycle and a ratio of 1%~99%, I could not see that on the bench. On my ancient scope, it looked more like a carrier with data bursts. At any rate, I ordered a new (real) analyzer and it should be here in the next few days. I had also previously ordered an EzUFH setup (converting my telemetry to 2.4GHz) so I will have two different types of receivers to test with. I need to see what the thing is sending before making assumptions on the software side...

[LorenzMeier]

You could set up a proper PWM input capture for that, but I'm out of bandwidth to do that. I will put your fix into place for now.

[LorenzMeier]

Ok, fix pushed. I'm closing this since the remaining work would be to improve the PWM RSSI input capture, but the basic functionality is there and the stronger lowpass will help to get a more reasonable reading.