I couldn’t go straight to 3.0.1 from a reported “2.0”, I had to first flash 2.5.1 and then flash “repartioner” and then flash 3.0.1 and even then it claimed failure, but seems to be working. Needless to say discovering these steps on the net was non-trivial.
1 Like
Ok, I have tried setting up your settings on a Durandal and am getting some very weird behaviour that is definitely related to ELRS. My guess is that something in the protocol consumption code is consuming all the CPU because of CRSF invalid packets from ELRS (has happened before). Not going to be a quick fix I am afraid, but I will certainly dig deeper.
2 Likes
Ok, issue was you having the lost model sound on a switch 
So I have your setup working, no sign of lag or notchiness. You need to provide a few more details:
Please also use Plane 4.3.1 so that we are talking about the same setup.
3 Likes
I am terribly sorry for my late reply, I didn’t check the forum since nobody mentioned me.
I bought an H743Wlite, Betafpv 2.4g SuperD, and a Betafpv microtx 1w to start another build and to see if that would resolve the issue.
On a completely stock (save for the radio/serial related parameters) Ardupilot 4.3.3 firmware and ELRS 3.2 with the mentioned hardware I still have the stick lag, without the lost model sound switch setting.
What other details do you need?
Thank you so much for your time.
Send a log. Did you set the RC_OPTIONS bit to fix the ELRS baudrate?
1 Like
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.
1 Like
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.
1 Like
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.
1 Like
Ah cool - yes the GCS feedback is always laggy, I suspect because of mavlink, but the actual control should be good.
2 Likes
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
1 Like
Hello! Today I can ask you a question on this topic?