Update frequency of radio in trainermode to low if feeded via Sbus (servo movement jerky)

[Gerold68]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

I have a X9E with latest 2.9 EdgeTx. If trainer mode get his data from a sbus receiver connected via serial port, the servo movement is jerky. If trainer mode is feeded via wire, servo movement is smooth. If trainer mode is off, servo movement is smooth.

Expected Behavior

Same smooth servo movement in trainer mode, independent of the trainer source.

Steps To Reproduce

1. connect a sbus receiver to an uart that is used for sbus input
2. setup uart for sbus input
3. setup trainer input to master/serial
4. activate trainer mode

Student radio's input will be jerky.

Version

2.9.0

Transmitter

FrSky X9E / X9E Hall, Radiomaster Boxer

Operating System (OS)

No response

OS Version

No response

Anything else?

No response

[raphaelcoeffic]

For a more precise context, this was using a ELRS receiver @ 100 Hz / 8 channels, right?

[Gerold68]

Yes, ELRS receiver is @ 100 Hz / 8 channels used to the Trainer's Rx. Same for the connection to the plane.
The external module is setup with 400K, 100 Hz, Ch1-Ch16

[mha1]

Any progress on this? I see more users having the exact same problem.

@raphaelcoeffic any idea? think #4047 could solve it?

[Boxxxer64]

Same Problem here.
EdgeTx 2.9 Elrs 3.3 Tx16s MkII and Zorro.

[gagarinlg]

I can confirm this with something close to current main. I will take a look tomorrow

[gagarinlg]

So, those are my findings:
When the ExpressLRS packet rate between student and teacher radio is set to 333 Hz full, it just works

What happens on slower apcket rates is, that the reading of the sbus trainer data and the transmission of packets to the ExpressLRS TX module is not synchronised, so that there are timing differences which lead to lost packets.
The correct solution would be to trigger the sbus trainer handling everxtime a byte is received to check if there is a full packet and then start parsing and sned this data to the mixer.

Conclusion:
a real fix needs a lot of rework on how trainer stuff is handled in the mixer, in the mean time just use 333 Hz full between the radios, you do not need the huigher range of 100 Hz full there anyways.

[Boxxxer64]

Thank you for the quick response. I just tried it briefly with 333Hz full. it is slightly better, but not flyable.

[gagarinlg]

In my test setup it looked good. 100Hz full to the RX for the model and 333 Hz full between student and trainer.
On the model side I used an RM ER6 + a cheap analog servo

[Boxxxer64]

I use er8gv with hv digital Servos. Mks or Kst.
Between teacher and Student radiomaster RP2.

[gagarinlg]

Which packet rate do you use between trainer radio and model and what which PWM rate do you use on the RX outputs?

[Boxxxer64]

Tx16s teacher 100hzFull to er8gv
Studend 333hz to rp2

Pwm Output i think 50hz. I nothing change there.
I‘m at flying Field at Moment. Can look later.

without the Wireless Student all works perfekt. With cable works also.

[Boxxxer64]

Here some News?

[gagarinlg]

Yes, some work going on to update and integrate an older PR that redid sbus trainer input and adds CRSF, sumd and Ibus Trainer inputs

[Boxxxer64]

Thanks nice to hear

[Boxxxer64]

Fix in 2.9.1?

[gagarinlg]

No, it is not that easy

[Boxxxer64]

After some people said the problem had been solved, I started testing again. unfortunately unsuccessful. it still jerks. Was anything changed or fixed?

Here some Video
https://youtube.com/shorts/odqPO0pepOY?si=1oS7RrgznMaIWKop

[raphaelcoeffic]

The correct solution would be to trigger the sbus trainer handling every time a byte is received to check if there is a full packet and then start parsing and sned this data to the mixer.

Regardless of whether or not we can use RX DMA, we can make use of the Idle IRQ to trigger processing of packets (via the timer task), assuming these are sent without holes in them (which should be the case, AFAIK).

That would allow to have a much lower latency when processing these packets. This technique is already used for telemetry packets (depends on protocol, I think).

Here is an example:

void telemetryFrameTrigger_ISR(uint8_t module, const etx_proto_driver_t* drv)
{
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;
  xTimerPendFunctionCallFromISR(_poll_frame, (void*)drv, module, &xHigherPriorityTaskWoken);
  portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

This function is then called from the idle callback handler with the proper parameters.