Send a log. Did you set the RC_OPTIONS bit to fix the ELRS baudrate?
How do I record & view logs? I am not particularly savvy with Ardupilot.
RC_OPTIONS was set to 512 which was bit 9.
You need bit 13 set as well on RC_OPTIONS:
13: Use 420kbaud for ELRS protocol
https://ardupilot.org/copter/docs/common-downloading-and-analyzing-data-logs-in-mission-planner.html
Got it. This log is just from the bench and me wiggling around the sticks.
https://drive.google.com/file/d/1CSJLHZWLqqvpwbcCrI5ZMm9wfYxrh7_r/view?usp=sharing
I had to upload to google drive as it was complaining about filesize for some reason (despite it being below the stated 4.4 MB)
Bit 13 is just 8192, correct?
Bit 13 is 8192
The log might look laggy, but difficult to tell since I donât know hard fast you are wiggling the sticks. Can you do it again and wiggle each axis the fastest you are able and tell me what frequency it should be (i.e. how many wiggles in 5s for instance). Try and do them all the same.
Can you reproduce on 3.0.1? I am reluctant to try 3.2 given the issues I had last time upgrading.
Certainly worth raising a bug with ELRS folk.
Nevermind. I am an idiot that forgot to set BRD_ALT_CONFIG to 1.
The original problem of laggy response still prevails. I will revert to 3.0.1 and produce a log file shortly along with an approximate stick wiggle frequency.
I apologize for the stupid error.
Here you go, same link as before: Problem - Google Drive
I was wiggling the sticks at about 4Hz.
Note that while the output of the RX occasionally suggests that I did not reach the stick travel limit I did in fact complete the full deflection. The stick position would update once I had already started moving it the other way due to this refresh rate problem weâve been trying to solve.
Software is the same except this time I remembered to enable BRD_ALT_CONFIG and ELRS is v3.0.1
Interesting, the log says 2Hz:
So I believe you - the question is why. Can you post your params again, I probably asked you for these already, but just want to be sure I am testing the same thing. Will try when I have some time - which might not be for a week.
I described it wrong, 4 travels from one point to another per second but 2 full back and forth travels per second. The updated params are in the google drive folder.
Take your time. I appreciate your help with troubleshooting and your painstaking guidance. In the mean time I think Iâll raise an issue in ELRSâs GitHub and mess around with params.
Have a nice week
So that is essentially what the log shows. So I am uncertain how to show in software what you are experiencing physically. How are you determining that the output is âlaggyâ?
When I first encountered this problem it was with the R9 ELRS system hooked up to my planeâs ailerons. You could visibly see the ailerons lagging behind my stick input and resolution was lost which seemed consistent with QGCâs readings.
As soon as I got my WLITE and my 2.4ghz setup I connected to QGC and you could see the outputs lagging behind my stick inputs so I naturally assumed the same thing was happening since I tested it with the R9 and the aileron servos. Maybe you were right and it was the lost model sound thing that was causing some interference, and I simply didnât realize because of the inherently laggy stick display in QGC which wasnât the case in other configurators (such as BF and INAV).
I just connected a servo to the WLITE and it works perfectly, I seem to have trusted QGC too much.
Either way, I apologize for my ignorance.
Ah cool - yes the GCS feedback is always laggy, I suspect because of mavlink, but the actual control should be good.
Posted this topic earlier today, but it seems possibly relevant here.
Should we be using ELRS on UARTs with DMA enabled on both RX and TX? I chose SERIAL4 on the Cube Orange because it has DMA on the RX pin (there are no fully DMA enabled UARTs on CubeOrange-bdshot targets).
Incidentally, I upgraded from ExpressLRS 3.0.0 to 3.2.0 on all of my hardware today with very little issue. I do have a stubborn HappyModel JR bay module that I suspect is simply defective (it often fails to respond via the Lua script, regardless of version), but everything else worked as expected.
On H743 it doesnât matter so much because it has a good FIFO - you can run without DMA. On F4 you probably need DMA on both RX and TX
Hello! Today I can ask you a question on this topic?