setting parameter not repeated if time expired

[kniuk]

Reading parameter is done till success - which is correct. However writing(setting) parameter is done once, when not succeeded the next command is just parameter read. Example:

parameter A=100. changing parameter A to 101 - if successful in first attempt then A=101 when first attempt expires then second attempt is read command so the value refreshes to A=100

Please see video of loading parameters and then trying to change IMAX value. https://photos.app.goo.gl/qCVz6mQaDvyv3utn8

P.S. Is it normal to have so many retries in reading and writing parameters ?

[kniuk]

Here is a screenshot of the debug output. First command is PARAM SET (0x17), second and third is PARAM REQ (0x14)

[kniuk]

I've watched your lecture on Yaapu telemetry and mavlite: https://youtu.be/62tWYHXc7PY And from what I saw my problem with data loss on uplink is not a common thing, at least not in such a degree I am experiencing.

[kniuk]

I did some probability calculations and this is what I came up with: We want to send a 4 frame command. Each packet has a chance of 15% it will be lost (knowledge from @yaapu lecture) LuaGCS is sending each frame 2 times (knowledge from @yaapu lecture). That makes probability of both complementary frames being lost 15%*15%=2,25%. Probability of one frame (send 2 times) being send successfully is 97,75% (100% - 2,25%) Success for us is whole command (4 frames) received correctly. Probability of that is 97,75%^4 which is 91,2992%. So total error rate is about 9% - which is not so bad IMHO. 2 retransmission (3 tries total) would get us to error rate of 0,07% ! This is just one way talking, I guess we would have to take response error rate into consideration... However my real life observations are much worse though

[yaapu]

As I said your setup is not performing as expected, cannot say why, increasing the number of retries will help you but damage others . I cannot personally test every single setup, I tested r9mm, r9mini on R92019 flashed with ACCST on flex@100mW, never tested LBT nor FCC, I got very smooth telemetry, bidir worked just fine with about 1 parameter downloaded per second on my Horus and about 1.5 parameter per second on my Taranis. I also tested fport on r-xsr on ACCST v1, FPORT and FPORT2 on access 2.1, all this on MatekF405Wing, CubeOrange, mini-pix, kakuteF7, omnibusf4pro and pixracer. At times I had issues like those you described, telemetry would loose packets and status text messages would get corrupted but it was a setup issue not an inherent fport issue, in those setups I solved all issues by switching to an external inverter.

[kniuk]

I have: Matek F765Wing R9MM with ACCST v20190201 FPORT FLEX firmware, R9M 2019 Tx module with ACCST 20190117 FLEX firmware Jumper T16 with 2.3.10 official OpenTx firmware

R9mm is connected to UART6 RX with recommended settings from https://ardupilot.org/plane/docs/common-FPort-receivers.html BRD_ALT_CONFIG =1 SERIAL7_PROTOCOL =23 SERIAL7_OPTIONS =15 RC_OPTIONS =0 (no Fport Pad option, when I set RC_OPTION=8 then I get rc control but no telemetry) RSSI_TYPE =3

My cable connecting FC and Rx is about 30cm long. I watched signal at FC side with an oscilloscope and it has nice sharp slopes and levels 0 - 3,3V OpenTx FLEX options are: 862MHz, 100mW (tried also 25mW) I have also tried FPORT LBT firmware v20190201-rx / v20190117-tx. I will try another (fresh) R9MM-OTA this weekend. Have you heard about any issues with Matek F765?

[kniuk]

As I promised yesterday I did some testing. This are my conclusions.

What I tried without success to make LuaGCS perform better. -use another R9MM with short wires and ACCST 20190201 FLEX firmware -change serial port to SERIAL2 (UART1 on Matek F765) -change pin on R9MM to inverted signal (with changing SERIALx_OPTIONS to do not do the inversion of course) - that is using Frsky built in inverter i guess which has poor reputation in some of their receivers.

After that I uploaded ACCST 20190201 FLEX non FPORT firmware to R9MM and tried my luck with SPort -I connected R9MM SBUS pin to RX6, set SERIAL7 (UART6) to 23 (RCIN), SERIAL7_OPTIONS to invert Rx -I conencted R9MM SPORT pin to TX4, set SERIAL6 (UART4) to 10 (SPort passthrough), SERIAL6_OPTIONS to invert Rx, Tx and halfduplex And voila! your LuaGCS script started to work flawlessly!

IMHO that excludes problems with a quality of signal inversion because bidirectional SPORT is working great now. (in my case it is done internally in F765 CPU, since I am not using R9MM built in inverter, so I guess your suggestion with external inverter is not valid for me) IMHO it narrows things down to FPort implementation in Ardupilot (4.10dev from 02.12.2020)

What do you think @yaapu ?

[yaapu]

I really have no clues, but I'm still pretty positive that it's not an fport protocol implementation issue but rather an fport "setup" issue so more on the side of the serial/inversion. Did you post your issue here? https://discuss.ardupilot.org/t/frsky-fport-support-testers-wanted/50669/240

[kniuk]

I haven't posted on discuss yet about my issues with FPORT. However I tested YaapuGCS 1.01 on my buggy FPORT setup and it works as expected. It retries when no response after SET command. Works great. Thank you.