SBUS data update frequency

[ludt]

Hello,

New on the forum, not sure to write at the right place...

I have developed an application on a Naze32 for a quadcopter with short acquisition/motor update time (less that 1ms at 500Hz).

I use a Taranis-plus with an X4R receiver connected to the board with SBUS and S.port for telemetry.

Using a graphic tool to tune the PIDs, and after several checks, I realize that the SBUS sends two times the same frame before update it.
In other words, the SBUS period is 9ms but the data is refreshed only every 18ms.

Is it normal? And for my curiosity, is it because of the internal data update frequency?

Thank in advance,
Regards from Chartres (France)
Ludovic

[Kilrah]

Depends what radio and firmware you're using, and how it's set.
If 16 channels are sent they are sent as 2 packets of 8 alternatively, so any given channel would only get updated after 18ms. If set to only send up to 8CH you should have 9ms updates.

[ludt]

I have a Taranis-plus with X4RS receiver using EU firmware, so mode is D16.

Setting to CH1-8 instead of CH1-16 gives a 9ms updates!
I noticed that setting to CH1-9 (9 channels) gives also a refresh of 9ms ?? a reason for that?

Thank you,
Regards

[Kilrah]

No, good question, could be a mistake... can you see if CH9 moves when set to 1-9, and if not whether 9 and 10 start responding together when you set to 1-10?

[ludt]

When set to 1-9 the CH9 moves but is updated each 18ms while CH1-8 are still updated each 9ms.

Would-it not be more simple to send one packet of 16 channels and update all channels every 9ms ? )
Is there a hardware limitation for that?

[Kilrah]

Packets contain 8 channels, that's just how the protocol is defined.

[MikeB]

Are you sure channel 1 is updating every 9mS and not 18mS when you have CH1-9 set?

Mike.

[Kilrah]

Yep, that would be highly strange and unlikely.

Note your flight controller could be filtering the input and make you believe that when it's not the case.

[ludt]

Hi,
Here is below what I get on CH1 and CH9 having CH1-9 set. CH1 is mapped to the Roll stick and CH9 is mapped to S2.
Sample is made every 2ms, channels update is made by another thread after having received the 25th byte of a frame.
Charts are both recorded at 3 to 4 seconds of interval.

channel 9

channel 1

To make an accurate generic filter on input, I would be good to know which part of the frame is updated (1-8 or 9-16) because the time at which I received the data may be or may be not the time at which the data is really updated... but I will find a compromise

Ooops sorry, Instead of CH1 you must read CH2 (I am zero based), so maybe the CH1 (zero for me) is updated every 18ms, I check this right now.

Ludovic

[ludt]

I think that I have found the trick:
if you set CH1-8 you have 8 channels at 9ms
if you set CH1-9 you keep 7 channels at 9ms (CH2 to 8) (CH1 alternates with CH9, so 18ms refresh for both)
if you set CH1-10 you keep 6 channels at 9ms (CH3 to 8) (CH1 and CH2 alternate with CH9 and CH10, so 18ms for the four)
and so on...

Thank's for your support
Regards
Ludovic

[MikeB]

That's what I expected from the design of the protocol.

Mike.

[Kilrah]

Except that when you set to CH1-9 OpenTX only sends data for CH1-8 every 18ms. So those new positions would come from nowhere...

[ludt]

Unless I am mistaken, according to the source code pxx_arm.cpp lines 254 and following, setting a number of channels above 8 (ex CH1-11) means that the channels from 9 to that number are sent one time in two (line 221) with the channels from 1 to the number of channels above 8, i.e. every 18ms. The others are sent on each frame, i.e. every 9ms.
So with the example of CH1-11, channels 1, 2, 3, 9, 10 and 11 are sent every 18ms and channels 4 to 8 are sent every 9ms.
Might be useful to know.

Ludovic