search

betaflight / betaflight-tx-lua-scripts

Collection of scripts to configure Betaflight from your TX (currently only supported in OpenTx)
GNU General Public License v3.0
584 stars 142 forks source link

BF 3.4 + 3.5: FrSky receivers (R-XSR, XSR, R9M, ...) (non-inverted mod) on FPORT, lua v1.0.2 - has problems with saving values #151

Closed RipperDrone closed 5 years ago

RipperDrone commented 6 years ago

All kinds of glitches:

Taranis FW is 2.2.2 RC5, lua scripts running somewhat more stable on BF3.4 than on 3.5... :-/

Issue has been fixed for R-XSR by FrSky firmware update plus commit / PR to BF code, but ist's not yet fixed for other receivers like XSR, R9M...

mikeller commented 6 years ago

What firmware do you have on your RX?

Also, providing information about the versions, and a config diff, like you were asked to do when opening this pull request, will greatly improve the chances of anything being done about your rant.

RipperDrone commented 6 years ago

No intention to make it understood as a rant / see smilie in title.

I didn't provide all the details since I thought it might be a general issue (also mentioned in some other issue reports before) that the latest lua script still does not cover all the new timings of BFf3.4+ regarding FPORT protocol.

Anyway, here's the details you asked for:

mikeller commented 6 years ago

@RipperDrone: For some reason I get a 404 when trying to open your diff. Can you try 3.5.0-RC1? betaflight/betaflight#6397 disables sending of the per-ESC telemetry data, reducing the bandwidth going through telemetry.

RipperDrone commented 6 years ago

Diff link updated. Will test 3.5RC1 next...

RipperDrone commented 6 years ago

mixed results:

Quad1 = OBF4 / HGLRC 20x20 stack: All telemetry fine with BF 3.4 stable Quad2 = DYSF4PRO

RipperDrone commented 6 years ago

Flashed Quad2 back to BF3.4 - again script working but for 2 pages Rates and Motor PWM (no values shown, others are fine)...

Guidus93 commented 6 years ago

Also here, no values on Lua with 3. 5,it was working with 3.3 and 3.4 TOO. RXSR with stock eu firmware and Fortini Is there something I should check on cli parameters?

RipperDrone commented 6 years ago

must have to do with altered tele frames + timings...?

klutvott123 commented 6 years ago

With 3.5.0 RC1 i stopped getting "sensor lost" all the time, but as soon as i switch to the telemetry page with the lua script i get "sensor lost" after a few seconds. I don't get any values on any pages of the lua script either. If i don't switch to the lua script everything is fine and telemetry works perfectly.

Tried 3.3.3 again just to test and it shows values on most of the lua pages( not PWM and VTX). I can change and save values, but if i do it too much it's "sensor lost" again. With 3.3.3 i have to wait for a few minutes for the sensor to come back. Rebooting FC/transmitter does nothing. "sensor lost" seconds after switching on.

I'm starting to suspect that the issue is with the R-XSR as it seems like most people with these issues are using it. Those using other receivers had issues with ESC telemetry enabled. Also @mikeller mentioned in #120 that the R-XSR has a 8051 microcontroller instead of the stm32 that the other frsky receivers are using and suggests that it might not be capable of handling the same number of sensors.

I might get a X4RSB to see if there's any difference.

Using SPRACINGF3 clone, R-XSR f.port 180615 beta firmware(tried all firmwares), Taranis q x7 with opentx 2.2.2 RC5.

RipperDrone commented 6 years ago

R-XSR FPORT was spot on with BF3.4 (had all the probs you described before thqat) on many FCs like OBF4, OBF4SD. On DYSF4PRO, 2 telemetry pages over lua were not displaying values, all the others are ok. So since firmware version 180228, the R-XSR seemed to work almost by 100%. But then, with BF3.5RC1, none of the values / pages was working anymore.

It's true the R-XSR has a different MCU, and @mikeller has done a great job in adjusting frames frequency, timing and so forth. But it still seems there is some timing glitch in BF3.5 now...

mikeller commented 6 years ago

@RipperDrone: Unfortunately, given we have got SmartPort and FPort, a number of different RX, all with a number of firmware versions, 'making it work' is more like 'herding cats'...

Can you try the 180615 version for r-XSR (under 'Beta firmware for FPort)?

RipperDrone commented 6 years ago

Yes, I know. Will update the OBF4 where RX is easier to access. On my Airdancer with the DYSF4Pro, I would have to tear a lot of soldering and shrinks apart since the RX is buried deep underneath the center FC section which is tied down / constrained by short ESC cables and shrik wraps around the arms. Extremely painful, trying to avoid this. When on a promising track, I can test with other rigs, though...

It seems that the worst combination right now is the DYSF4PRO / R-XSR FPORT, where I don't get ANY of the lua telemetry pages populated with readout values. This rig has BLHeli32 individual ESCs which issue telemetry data. I have tied those 4 telemetry pins together and attached them to one UART.

RipperDrone commented 6 years ago

Did some testing now, rather more frustrating than enlightening... :-)

Can there be anything around timings which is FC target specific? (since Lua with R-XSR works on many other FCs with BF 3.4). Timings of FC MCU itself which might be taken as a reference for choosing the lua / tele frame timings? Basic cycle setting 8kHz/8kHz on most of my F4 builds, MCU load around 10%... all R-XSR hardware-modded for inversion ('P inverted' pin connected)

RipperDrone commented 6 years ago

to try flashing latest R-XSR FPORT beta firmware w/o rebuilding the whole quad: Is there a way to flash the RX over serial passthrough in the meantime so I could stay wired up as it is?

RipperDrone commented 6 years ago

found something: Lua rate page has been empty in BF3.3 as well under certain circumstances... https://github.com/betaflight/betaflight-tx-lua-scripts/issues/117

RipperDrone commented 6 years ago

@Guidus93 can you share your CLI diff (link to shared cloud doc to save space here would be Golden) and your FC type + wiring, please?

RipperDrone commented 6 years ago

So far, we have at least DYSPROF4, SPRACINGF3 and an unknown FC NOT showing ANY values in lua script fields on Taranis X9D and QX7 (OTX 2.2.2RC5) with BF3.5RC1, however showing values at least in most fields / on most pages (e.g. except 2 pages) in BF3.4 (along with other glitches like sensor lost messages occasionally)...

Very weird. First of all, we need to find the differences btw 3.4 and 3.5RC1 to make BF3.5 work at least as well as BF3.4, then support work to eliminate the sensor lost messages etc.

RipperDrone commented 6 years ago

Could it be PR https://github.com/betaflight/betaflight/pull/6300 causing the difference BF3.4 <-> 3.5 maybe?

Other PR's related to S.Port / telemetry IMHO: #6382, #6397. So we can narrow it down to these 3 PR's?

klutvott123 commented 6 years ago

Changing FPORT_MIN_TELEMETRY_RESPONSE_DELAY_US to 100 in fport.c got rid of the "sensor lost" for me when opening the lua script. Still no values on any pages. Then i increased FPORT_TELEMETRY_MAX_CONSECUTIVE_TELEMETRY_FRAMES to 10 and now i get values on all pages except PWM and VTX(don't know if i'm supposed to have vtx values since i don't have a vtx.). Still a little slow. Takes a few seconds to load pages but i can change values and save them. Just flew 4 packs and did a little pid tuning with no problems other than one quick "sensor lost". Works for my setup but might not for other setups. I can see how getting this to work for every setup is like "herding cats".

Also compiled 3.5.0 with fport.c from 3.3 and that also works(still no PWM and VTX). I think it's because 3.3 didn't have the restriction on consecutive telemetry frames at all.

mikeller commented 5 years ago

@klutvott123: FPORT_MIN_TELEMETRY_RESPONSE_DELAY_US is something that was directly specified by FrSky, so making it shorter will potentially lead to problems with future versions of the RX firmware, since that's the spec they make it for.

FPORT_TELEMETRY_MAX_CONSECUTIVE_TELEMETRY_FRAMES had to be introduced to prevent buffer overruns on r-XSR. This is superseded by the change introduced in betaflight/betaflight#6098 that allows the RX to signal to the flight controller when it's ready to get another telemetry frame. But this requires RX firmware support. Currently the r-XSR 'Beta firmware for FPort' supports this, and there is XSR firmware in the works for it.

klutvott123 commented 5 years ago

@mikeller Thanks for explaining. I just reflashed my R-XSR with the latest 180615 beta fport firmware just to be sure and now it's working without changing FPORT_MIN_TELEMETRY_RESPONSE_DELAY_US and FPORT_TELEMETRY_MAX_CONSECUTIVE_TELEMETRY_FRAMES. I was sure i was on 180615 but must have had 180228 instead(have been switching between the two to test).

The PWM and VTX pages are still empty. Do you know what might be causing this?

RRAlex commented 5 years ago

Same issue here on OpenTX 2.2.2 and BF 3.4.1 with F.Port 180228:

Lost telemetry & slow update (though I can't compare, this is my first build...)

klutvott123 commented 5 years ago

@RRAlex Try the 180615 beta firmware. That fixed it for me. Telemetry works and no more "sensor lost".

RRAlex commented 5 years ago

@klutvott123 Oh, I see, didn't realize there was a beta, will try that and give some feedbacks, thanks!

atomiix commented 5 years ago

Same issue here on OpenTX 2.2.2, BF 3.5.0 and X4RSB with F.Port 171114 (last nonEU version). Some "sensor lost", slow update & empty PWM & VTX.

klutvott123 commented 5 years ago

In https://github.com/betaflight/betaflight/blob/master/src/main/interface/msp.c line 1240:

case MSP_ADVANCED_CONFIG: sbufWriteU8(dst, gyroConfig()->gyro_sync_denom); sbufWriteU8(dst, pidConfig()->pid_process_denom); sbufWriteU8(dst, motorConfig()->dev.useUnsyncedPwm); sbufWriteU8(dst, motorConfig()->dev.motorPwmProtocol); sbufWriteU16(dst, motorConfig()->dev.motorPwmRate); sbufWriteU16(dst, motorConfig()->digitalIdleOffsetValue); sbufWriteU8(dst, gyroConfig()->gyro_use_32khz); sbufWriteU8(dst, motorConfig()->dev.motorPwmInversion); sbufWriteU8(dst, gyroConfig()->gyro_to_use); sbufWriteU8(dst, gyroConfig()->gyro_high_fsr); sbufWriteU8(dst, gyroConfig()->gyroMovementCalibrationThreshold); sbufWriteU16(dst, gyroConfig()->gyroCalibrationDuration); sbufWriteU16(dst, gyroConfig()->gyro_offset_yaw); sbufWriteU8(dst, gyroConfig()->checkOverflow);

The bottom 6 lines are new from 3.4. I tried commenting them out just to test and that got the PWM working again. I can't see why it's not working with the above code. The FC just sends all those bytes and the lua script uses the first 9. I tried sending the MSP_ADVANCED_CONFIG command in a terminal to see what exactly comes out but didn't have any luck with that.

atomiix commented 5 years ago

@klutvott123 I can confirm, I went further and tried to comment each line one by one and it's the line sbufWriteU16(dst, gyroConfig()->gyroCalibrationDuration); which cause the issue.

So, I did set gyro_calib_duration = 128 in the CLI and the PWM page was working again !

klutvott123 commented 5 years ago

@atomiix I just set it to 128 too and it's working now. Thanks!

This has to be some kind of bug because i have something like this happening on the PID page too. Some combinations of pid gains just makes the page blank. Right now if i set the pitch I to 60 and roll I to 55 it stops working. Earlier i had a case where setting yaw I to 55 it stopped working. I could set it to 54 or 56 and all other values but not 55.

Same thing also happens when setting the d-term notch filter center frequency to 125 and the cutoff to 75.

atomiix commented 5 years ago

@klutvott123 I had exactly the same problem when I was tuning my PIDs, that's what led me to try another value for gyro_calib_duration

atomiix commented 5 years ago

It seems that under certain circumstances, F.Port frames are dropping packets.

I got the line elseif bit32.band(mspRemoteSeq + 1, 0x0F) ~= seq then of the file src/SCRIPTS/BF/MSP/common.lua (line105) being called with the page PWM (which means packet drop). It occures only on F.Port, I tried back with SBUS/SmartPort and it's working well.

But I'm not competent enough to investigate more on the F.Port protocol 😅

mikeller commented 5 years ago

@atomiix: There are a number of places where telemetry frames can be dropped:

klutvott123 commented 5 years ago

@mikeller I just read the f.port protocol documentation and did some experimenting. If i set any value on any lua script page to 125 or 126 it stops working. 126 is the FPORT_FRAME_MARKER 0x7E and 125 is the FPORT_ESCAPE_CHAR 0x7D in https://github.com/betaflight/betaflight/blob/master/src/main/rx/fport.c. This makes me believe the f.port bytestuffing isn't properly implemented somewhere.

https://github.com/betaflight/betaflight/blob/98616d469012e5287f35c9302bbea70d1e8b920d/src/main/telemetry/smartport.c#L274 This looks right to me so i assume the f.port frame is correct when sent to the receiver. Is there a chance that it's not properly "unstuffed" at the receiver side and not getting sent to the transmitter at all when the data contains 125 or 126?

Using betaflight 3.5, R-XSR with 180615 beta f.port firmware.

klutvott123 commented 5 years ago

Did some more testing. I set my PIDs so that the PID page stopped working. I wrote a python script that sends the MSP_PID command to the FC and prints the received data. The combination of pid gains that makes it stop working has a CRC of 125(FPORT_ESCAPE_CHAR 0x7D). Now i really think this is a bytestuffing issue.

Maybe it's in f.port firmware since @atomiix says it's working with sbus/s.port. Can't test it myself since i have only one uart. Just ordered new FC. Will test with sbus/s.port then.

mikeller commented 5 years ago

Good find, @klutvott123!

On the flight controller side, FPort uses the same byte stuffing that SmartPort uses: https://github.com/betaflight/betaflight/blob/98616d469012e5287f35c9302bbea70d1e8b920d/src/main/rx/fport.c#L237-L239

But where I can see a potential difference is that, because with FPort, the frame delimiters are used for RC control and telemetry frames on the same connection, any occurrence of a stray delimiter would have way worse consequences than on SmartPort, where the RC control is unaffected.

My suspicion is that the lua API that we are using to inject the MSP data expects the data to be byte stuffed when it is sent, or is simply buggy and does not do the byte stuffing correctly.

klutvott123 commented 5 years ago

@mikeller Some more details which i should have added: When setting a value in the lua script to 125 or 126 and saving, it get's sent correctly to the FC. It's when the script tries to update the page again that it fails and all fields are blank. When i check the configurator i can see the value that i just set in the script. So it's working when sending data from transmitter but not when receiving.

You may be right about the lua API. I just had a quick look at some of the opentx s.port code and it looks like it's unstuffed correctly. Will investigate some more.

mikeller commented 5 years ago

Thanks @klutvott123 for looking into this. Shout out if you need help.

bhuism commented 5 years ago

+1

klutvott123 commented 5 years ago

@mikeller So i have done some testing and made some observations.

I soldered a UART module directly to the f.port pad on my FC and printed the data while the lua script was sending the pid command 112. I set my yaw I gain to 125 so that the frame had to be bytestuffed. The data for the pids is split up into four frames, is bytestuffed correctly and the CRCs are correct so no problems there. Just had to make sure.

Then i modified the function that processes frsky telemetry data in opentx to check for the byte sequence i'm interested in and print that frame directly to the transmitter lcd, bypassing lua completely. Works fine for the frames that aren't bytestuffed but for the bytestuffed frames i get nothing. This makes me think that the bytestuffed frames aren't received at all.

I had my transmitter turned on for a while and suddenly got a "sensor lost". Looked at the telemetry screen and saw the fuel sensor blinking with the value 124. It was gone until the fuel sensor reached 127. So the sensor got lost when the fuel sensor frames were bytestuffed.

I also think i know why the lua pages are updating so slowly. For uplink data frames the CRC is calculated from all the bytes in the frame. APPID bytes included where the first byte is the frameID that isn't the same everytime. Sometimes the frameID causes the CRC to become 125 or 126 and then the frame has to be bytestuffed. The lua script then has to request the data again and again until none of the data or CRCs of the frames are bytestuffed.

Can also confirm that s.port works correctly.

RipperDrone commented 5 years ago

Wow, @klutvott123 - you have finally found the explanation for what has been plaguing so many users for a long time. Wonderful work, thank you! Now it seems about how to do bytestuffing / destuffing the correct way, without the influence of channel values 125, 126...

Will this have to be done with FrSky devs, or is it something on the BF code side?

bhuism commented 5 years ago

@klutvott123 awesome!

klutvott123 commented 5 years ago

@RipperDrone I'm not 100% sure yet. I'll have to do some more investigating.

Just did some testing with https://github.com/betaflight/betaflight/blob/9ed2914489fc12e60bcb1d8af1bdb65677518aa2/src/main/telemetry/smartport.c#L274 where i commented out the if else statement that takes care of bytestuffing on the FC side. Then i added serialWrite(port, c); below so that no bytestuffing is done on the data sent from FC to RX. Still using my pids for testing this and when i set any value to 126 it works. I get the correct sequence of bytes in opentx. The byte that comes after the pid value that is set to 126 is also shown correctly. Still doesn't work with 125.

@mikeller is there a chance that the f.port firmware expects to do the bytestuffing itself? The length of an uplink dataframe is 8 bytes according to the documentation. When bytestuffing is done on the FC side the frame length exceeds those 8 bytes.

mikeller commented 5 years ago

@klutvott123: To my understanding of the FPort spec, byte-stuffing should be done by the sender. But this could be a bug, or an inaccuracy of the spec.

In the case of it being a bug, it could also be limited to the firmware for certain RX models only.

I will try to get an answer from FrSky on this.

RipperDrone commented 5 years ago

@mikeller Is there anybody from FrSky active on BF GitHub so we can tie that rep/dev into the coding himself/herself? Reverse engineering the protocol details by @klutvott123 might be a tedious task to do...

RipperDrone commented 5 years ago

Sry for being too unexperienced to really comment in a knowledgeable and helpful way, but what I understood so far is there seems to be a mismatch btw sender and receiver regarding bytestuffing logics. Actual values of 125 (0x7D) seem to be interpreted wrongly as a bytestuffing yes/no flag, so the value itself is not transmitted properly anymore. I skimmed the telemetry.c code for occurrences of the FSS_DLE (=0x7D) flag and found several places where the value itself is still transmitted, but e.g. in this one, it isn't: image

Anyway, we desperately need a FrSky dev here to look into the receiver side / their protocol details to resolve it quickly... :-/

Or is it even on the OpenTX side where frames / bytestuffing are getting messed up?

klutvott123 commented 5 years ago

@RipperDrone That code is for receiving s.port/f.port data and it works correctly. In betaflight f.port is implemented as it says it should be in the f.port documentation. The only thing is that in the documentation it says bytestuffing should be done by "sender". Sender could be interpreted both as FC and RX as they are both senders.

Heres some example data from my FC f.port pad:

126 8 1 48 53 0 112 112 0 0 176 126 <-- MSP_PID 112 from lua script

8 129 50 23 15 46 45 25 50 119         <-- First frame sent by FC containing PIDs

126 25 0 228 0 31 248 196 7 12 96 0 3 24 0 0 0 0 0 0 0 0 0 0 0 0 84 66 126

126 8 1 0 0 0 0 0 0 0 246 126

126 25 0 228 0 31 248 196 7 12 96 0 3 24 0 0 0 0 0 0 0 0 0 0 0 0 84 66 126

126 8 1 16 0 0 0 0 0 0 230 126

8 129 50 8 51 27 40 125 93 0 72   <--Second frame sent by FC. 125 is yaw I gain. Here it's bytestuffed as 125 93
RipperDrone commented 5 years ago

Got it. So your concern is we might have a duplicate byte stuffing situation, done both by FC and RX, so frame format is busted since only one stuffed byte is being removed by OpenTX / RC? Exciting...

klutvott123 commented 5 years ago

@RipperDrone Yes, that's what i'm leaning towards right now. With bytestuffing disabled in betaflight and sending frames containing the value 126 it looks like the frame is bytestuffed by the RX since it arrives in opentx but not when sending 125. Maybe some incomplete debug code left behind. I don't know. Won't be pointing fingers just yet. If only i could have a look at frskys f.port code, but i doubt that's ever going to happen.

opentx will just keep unstuffing as long as the defined packet size isn't exceeded. Here's the function that does it in opentx if you want to check it out https://github.com/opentx/opentx/blob/17b4aa24668bc4b223dd0613a48d2cc050e39358/radio/src/telemetry/frsky.cpp#L39 . The data sent to this function is popped straight from the telemetry FIFO.

klutvott123 commented 5 years ago

I think i can confirm that there's bytestuffing going on in frskys f.port firmware. Set my yaw I gain to 126. The databytes sent from FC to RX are:

51 27 40 126

The databytes that comes out in opentx before any processing is:

51 27 40 125 94

This is with the codechanges i described above that disables any bytestuffing of data to be sent in betaflight. Still no idea why it doesn't do it when the frame contains 125.

bhuism commented 5 years ago

I love it, feel a work around is around the corner, no pun intended 😁

mikeller commented 5 years ago

@klutvott123: I did a couple of tests with r-XSR and XSR, and they both seem to be handling this in the same way, which is weird since they do not share the codebase, making it unlikely to be an unintentional bug.

Can you run the tests above to see what 125 comes out as?

@RipperDrone: Unfortunately most of the FrSky engineers do not speak English, making communicating with them only possible via proxy. But I am working my contacts to try and get them to look into this, and comment on it. Also, there are different teams responsible for the firmwares for XSR, r-XSR, and R9, making this even harder.