Urgent: S.BUS input on 4.0.1 is stuttering often 100-300ms, up to 500ms

VDLJu · January 27, 2020, 8:51am

Hi,

After using 4.0.1 for few flights, I observed that it feels like there is lag on RC input. One time I just ARMED the drone and it got the RCIN failsafe and it DISARMED immediately (so there was a >500ms pause on RCIN).

After looking on to the log files, the RCIN logging was looking like it is not logging properly. I disregarded that and started to diagnose the problem as hardware problem by replacing RC receiver and simplifying the setup as far as possible, with no help. I also tested it by having just cube + carrier board + receiver and I got the same problem. Later I started testing if the AC firmware has a play on the problem and I found that AC 3.6.12 and AC 4.0.0 works well and the RCIN is not stuttering/pausing. But when I reinstalled the AC 4.0.1 it started to stutter again.

See the RCIN values where there is an arrow. In this image there is stutters from 100ms to 200ms.

Here is logs from same platform running on different AC versions:
See RCIN channels 1 and 2. The RCIN is all good on 3.6.12 and 4.0.0.

You can download the logs from there, and check using MP, which shows the problem more clearly.

rmackay9 · January 27, 2020, 9:58am

@VDLJu,

Thanks for the report, I’ve added it to our Copter-4.0 issues list so it won’t be forgotten and I’ll bring it up on the dev call tomorrow.

tridge · January 28, 2020, 8:58am

just letting you know that I am working on this. I am modifying the IOMCU code to add debug pulses at key points then examining the timing with a logic analyser. I think I have reproduced the issue, but it is going to take some time to pin it down

tridge · January 28, 2020, 10:05am

I think the fix is to increase the constant 2000 at this line:

github.com

ardupilot/ardupilot/blob/master/libraries/AP_RCProtocol/AP_RCProtocol_SBUS.cpp#L229


    }
    uint8_t b;
    if (ss.process_pulse(w0, w1, b)) {
        _process_byte(ss.get_byte_timestamp_us(), b);
    }
}


// support byte input
void AP_RCProtocol_SBUS::_process_byte(uint32_t timestamp_us, uint8_t b)
{
    const bool have_frame_gap = (timestamp_us - byte_input.last_byte_us >= 2000U);
    byte_input.last_byte_us = timestamp_us;


    if (have_frame_gap) {
        // if we have a frame gap then this must be the start of a new
        // frame
        byte_input.ofs = 0;
    }
    if (b != 0x0F && byte_input.ofs == 0) {
        // definately not SBUS, missing header byte
        return;

I think a value of 3000 will be sufficient.
you then need to rebuild IO firmware with Tools/scripts/build_iofirmware.py
I will be working on this more tomorrow

tridge · January 29, 2020, 2:29am

Here is a PR that fixes the issue:

Here is a binary for CubeBlack for testing:
http://uav.tridgell.net/tmp/copter-CubeBlack-sbus-fix.apj
Please test!

VDLJu · January 29, 2020, 8:01am

Tested the firmware. No issue on 10 out of 10, about two minute tests each. I downgraded and verified that issue is still reproducible on 4.0.1 and then upgraded back to 4.0.2 sbus fix firmware and issue was no longer reproducible.
Also I didn’t notice nothing out of ordinary while testing.

I assume that using a test firmware could be risky, so I don’t do test flying.

tridge · January 29, 2020, 8:02am

great, thanks!

not a really high risk as Randy has already flown it, but it depends on how expensive a vehicle this is

VDLJu · January 29, 2020, 8:14am

Ok. Well it is relatively expensive, as it is built on custom CF molded parts and titanium frame. I think I will wait for next release candidate, if it is scheduled to be released soonish. Then it’s clearer what is included on that build.