ELRS 3.3.2 telemetry sensor lost issue

[uranus36]

Current Behavior

The sensors from my FC (pitch, roll, GPS speed....etc of INAV) could lost suddenly and can't recover until I power cycle my plane. At the meantime, the sensors of the RX (RSSI, RQLY, TQLY....Etc) are still alive. And I can still control pitch , roll , yaw actions without problem.

Sensor lost suddenly

Steps to Reproduce

Power off my plane and power on again immediately. Then the FC sensors could be recovered for about 20 something seconds. And the sensors will be lost again.

Possible Solution (Not obligatory)

Details

Your Environment

Firmware: INAV 7.1 RC1
FC: speedybee F405 wing
Plane : Fixed wing P39
TX : Radiomaster TX16S with Edgetx 2.8.3. EMAX ELRS transmitter 915.
RX: Bayck 915 RX
ELRS setting: 100Hz Full
Telemetry ratio :1:2 or 1:32

• TX hardware: EMAX ELRS 915
• RX hardware: Bayck 915 RX
• Handset model: Fixed wing P39
• OpenTX version (including nightly number): Edgetx 2.8.3
• ExpressLRS version (TX & RX MUST MATCH): TX:3.3.2,. RX:3.3.2
• Packet Rate: 100Hz full
• Telemetry Ratio: 1:2 or 1:32
• user_defines:

[schugabe]

Can you try to restart just the FC and keep the rx powered and check if this also recovers the sensors.

RSSI/LQ are handeled by the rx directly and all other sensors are are received from the FC and if restarting the FC fixes the issue it would point to a FC issue.

[uranus36]

Can you try to restart just the FC and keep the rx powered and check if this also recovers the sensors.

RSSI/LQ are handeled by the rx directly and all other sensors are are received from the FC and if restarting the FC fixes the issue it would point to a FC issue.

I replaced with a new BayckRC 915 RX, it seems like the sensor lost issue is no longer exist . It's so weird . How come the FC can execute my command without any problem , just the telemetry from FC have problem . Thanks for your rely !

[mmosca]

It could be a wiring issue. The fc will receive data on one pin and send telemetry data on another.

Changing the rx may have fixed the wiring issue.

Restarting the whole setup may jiggle stuff around and get it to work. But it is all guesses. Does it still happen if you switch back to the same rx?

[davetheghost]

recently had a fly away that displayed this same behavior on first flight after flashing iNav 7rc1 -- and currently I'll occasionally hear my TX say sensor lost, even with BetaFlight 4.5

What's strange (hindsight is always 20/20 or better) -- I was trying to configure the LED strips before flight, and "Throttle Response" would only display with right stick pulling down, as if to tilt the quad backwards, toward you, with it facing forwards. its like the sticks were swapped and in Mode 1.

I didn't set this, TX settings didn't change, and building EdgeTX -DDEFAULT_MODE=2 was definitely set. To make it even stranger, on my 2nd quad with BF 4.3 -- which i plugged in a bit later..

Throttle arming flag wouldn't go away. I pondered a while, and went to CLI and ran diff all, to find it saying in red that 3 settings to be "corrupt" -- rc_min rc_max and some other one -- all 3 dealt with defining the min, mid, and max PPM, as in 988/1500/2012 or whatever.

Only possible changes done to 2nd quad were attempts to make it land on failsafe by using a throttle value of 1337 to land - however, flipping failsafe switch while on receiver tab in configurator puts aileron, elevator, and roll to 0, throttle to 988ish, and if im not mistaken channels 9 and 10 or 11 and 12 are also set back from 2/3~3/4 to 1/3 or 1/4.

Sucks to watch $300 fly away, and nothing I did could control it -- disarming, flipping failsafe switch, even turning off TX to force a failsafe. Don't exactly recall at which point the TX began saying sensor lost, but the only GPS coordinates telemetry reported are right on the roof, about 20ft behind take off location. 12 minutes until complete RX/TX comms lost -- drove in the general area it flew, and did not get a signal.

FC: SpeedyBee F405 V4
Main firmware: Betaflight 4.5
Problem Firmware: iNav 7rc1
TX: RadioMaster Zorro
TX FW: EdgeTX 2.11, self built from main branch
RX: BetaFPV Nano
ELRS: 3.3.2

This time, though, I'll be sure to have a separate battery soldered and secured in case main cell gets disconnected -- considering even a secondary MCU which is fed GPS data and 900mhz RX to transmit it.

[mmosca]

Do you have logs from edgers/blackbox or a way to reproduce the issue?

inav diff probably could help as well.

I fly the same fc with inav 7.1 on one of may main planes and don’t see the issues.

edit, f405v4, not wing, so I don't have the exact fc

[mmosca]

Btw, did you follow the release notes and do a full flash erase while flashing inav 7.1rc?

Strange things could potentially happen, if not.

[b14ckyy]

Can you please test the telemetry behavior with this build here: https://1drv.ms/f/s!Ar6QsGgoXRgqyPk8iOYA_eGtgz0T-w?e=A4mIfl

there was a telemetry related change since RC1, maybe that changes something, so we don't test already fixed issues.

[davetheghost]

that, I don't recall, however, i have made it a practice to erase flash on every FW upgrade -- though, it may have been unchecked since I hadn't used the iNav configurator in a while before then

When I first built the Master5HD, iNav was the first FW I flashed. sat here a couple hours, making sure motors were in correct location and spun in correct direction, ensured RX and TX had same packet rate, responded correctly on receiver tab, even broke out a protractor to set the compass CW 270 flip, with -300 roll to compensate for the 30* tilt. also set alt hold, pos hold, and flight mode switches. (no beginner wants acro! )

took it outside, powered on, waited for 6 GPS sat lock, and eased into it to hover about head level, then activated alt hold and pos hold -- 3d lock. thrilled! "i built this thing" -- but i didn't care for how tame angle mode was, found myself flying the beater bc it was more fun, so I flashed betaflight.

In terms of problem at hand -- even with BF 4.3 and/or 4.5, I'll hear a single random "Sensor Lost" now and again -- and with the fly away, I believe it was within a minute or two after that I got many sensor lost messages.

So for now I'm just running EdgeTX 2.10 rc2 and BF 4.5 rc2 on the F405, and 4.whatever was the last supported version for the F411 on the beater.

it just poured down raining most of the night -- gonna be a bit before flying the Master5v2 -- tho i'll fool with the beater later today -- with TX logging

[davetheghost]

Can you please test the telemetry behavior with this build here: https://1drv.ms/f/s!Ar6QsGgoXRgqyPk8iOYA_eGtgz0T-w?e=A4mIfl

there was a telemetry related change since RC1, maybe that changes something, so we don't test already fixed issues.

I am not going to flash something randomly linked outside github -- or iNav for that matter. Considering ArduPilot for bells-n-whistles mission style flight. Or, when I have funds for a new beater (when this one breaks, or if I miraculously find Master5HD -- sure.

[b14ckyy]

This firmware is the current INAV 7.1 pre-release state from 4 days ago. Its not a random custom build. Consider it a RC2.
If we are supposed to help you with the issue and find the cause, you need to help us as well to understand the issue that no one else sees so far ;)

[davetheghost]

Valid point -- however -- if another fly away happens, and I cannot find/track it -- I'd be out another $300, and would likely sell the remaining RC stuff I have, to say the least.

[b14ckyy]

But as you have valid safety concerns, here is the branch, you can compile it yourself directly from GitHub alternatively: https://github.com/iNavFlight/inav/tree/release_7.1.0

regarding the Flyaway. Make sure your nav system works in the first place. Maybe run a waypoint mission with RTH to test range instead of manual controlling it so it will always come back in the end.

[davetheghost]

But as you have valid safety concerns, here is the branch, you can compile it yourself directly from GitHub alternatively: https://github.com/iNavFlight/inav/tree/release_7.1.0

regarding the Flyaway. Make sure your nav system works in the first place. Maybe run a waypoint mission with RTH to test range instead of manual controlling it so it will always come back in the end.

I did meticulously test it with BF 4.5rc2 -- even shit brix when I turned off TX and it went away from home location to descend to fixed altitude, then flew here. First few times I'd just go across yard, and 2 or 3 times it either had bad altitude reading or something bc it'd full throttle straight up.

It definitely works -- was within 3 days of receiving the M10 GPS -- the M8 I have is slower than molasses. M10 grabs 17 satellites within 2 mins of flying. magneto responded correctly, as I face 270 W, and to my right is 360/0 N. Sticks were mysteriously swapped, I believe. I seen a glimpse of SPEKTRUM something when switching to the receiver tab at some point... it immediately switched, and is likely a default setting, and/or whatever it switched to is an alias to that spektrum channel order.. IDK.

I've enabled logging on my TX as a special function when armed, and will note time when it announces sensor lost, then review the log. However, I can't promise reproduction as I've scaled back from bleeding-edge builds to release candidates.

Regardless, I don't know how the freaking thing was able to arm even with sticks swapped, as roll/pitch are both at 1500 with no input.

[mmosca]

@davetheghost I suspect your issue is not related to the original issue reported here.

The original issue was only related to telemetry. Sticks responded normally and he didn't fail safe.

Fell free to open another one, either on INAV or here, but without logs or a way to reproduce it, it will be very hard to confirm it is a software bug, let alone fix it.

[davetheghost]

I mean, I didn't have telemetry on the fly away -- a bunch of sensor lost announcements, no updated GPS coordinates, only TX/RX Quality and RSS, for approx 12 minutes, until connection lost -- also random Sensor Lost annoucements here and there. Apologies for derailing, though intention is genuine along with similar experiences as OP.