Identify actuality of RC_CHANNELS_PACKED packet

[rogercrsf]

Hey @AlessioMorale , thank you for this CRSF parser, it helped me a lot already, please lmk if there is a way I can donate you for this effort?

I'm looking for a solution to aggregate several physical links into one, so looking for a way to identify the sequence number of a packet to decide which one to execute considering I have two receivers connected to Flight Controller.

What I mean, theoretically, it is possible that for example B packet is received first compared to A, while transmitter sent A first and then B.

So how the receiver does know which packet should be "executed" and which is to drop? I guess there should be some sequence number or similar, but how one can parse/know it?

Could you please provide any hint in case you have any knowledge on that? I'm motivated enough to compensate you the time spent on that, please.

I was looking into bunch of the directions already. Found this spec - https://www.openrcforums.com/forum/download/file.php?id=17402, but it says nothing about sequence number, only defines packet types and their size + some more information. From that (and from your material) I learned that I need to analyse 0x16 packet, which is RC channels packed. And I've identified which channel corresponds to the my joystic moves. Like here it is sent with 14s channel, I see how the value differs, when I change joystic position:

But how one can identify the sequence number of a packet, I afraid it is handled at RX side itself, and I cannot see this information when RX sends instructions to Flight Controller? Is there a way still get this info somehow?

[Artem-N]

Hey @AlessioMorale , thank you for this CRSF parser, it helped me a lot already, please lmk if there is a way I can donate you for this effort?

I'm looking for a solution to aggregate several physical links into one, so looking for a way to identify the sequence number of a packet to decide which one to execute considering I have two receivers connected to Flight Controller.

What I mean, theoretically, it is possible that for example B packet is received first compared to A, while transmitter sent A first and then B.

So how the receiver does know which packet should be "executed" and which is to drop? I guess there should be some sequence number or similar, but how one can parse/know it?

Could you please provide any hint in case you have any knowledge on that? I'm motivated enough to compensate you the time spent on that, please.

I was looking into bunch of the directions already. Found this spec - https://www.openrcforums.com/forum/download/file.php?id=17402, but it says nothing about sequence number, only defines packet types and their size + some more information. From that (and from your material) I learned that I need to analyse 0x16 packet, which is RC channels packed. And I've identified which channel corresponds to the my joystic moves. Like here it is sent with 14s channel, I see how the value differs, when I change joystic position:

But how one can identify the sequence number of a packet, I afraid it is handled at RX side itself, and I cannot see this information when RX sends instructions to Flight Controller? Is there a way still get this info somehow?

Looks like there are no channel numbers in the payload of 0x16 packet since the channels' values are just packed into contiguous array which you just need to index through. (enumerate in python) Usually 3-rd channel is "gas", in my case, and used only 7 channels.

[AlessioMorale]

Hi @Artem-N, apologies for replying so late.

Is it so important to lose some frame for your application? If not, I would suggest a different approach:

• Retrieve data from both rx
• designate one of the two as active
• Constantly monitor the payload_link_statistics info and when it drops under a set threshold, switch to the other radio.
• Add some hysteresis to avoid switching back and fort when both values are close to the threshold.

Alessio

[Artem-N]

Hi @Artem-N, apologies for replying so late.

Is it so important to lose some frame for your application? If not, I would suggest a different approach:

• Retrieve data from both rx
• designate one of the two as active
• Constantly monitor the payload_link_statistics info and when it drops under a set threshold, switch to the other radio.
• Add some hysteresis to avoid switching back and fort when both values are close to the threshold.

Alessio

hello Alessio, first of all, thank you for your work on channel parsing🙌 your proposal sounds interesting, but I seem to have solved my problem. However, there is another thing - when I work with the sbus protocol, the packets are all valid, when I work with crsf protocol, there are quite a few broken packets, is it possible that the hardware is not configured correctly somewhere?

[AlessioMorale]

I would check the uart rate calculation. There may be a slight error in the actual baud rate, causing the issue you're observing. You can also try to increase or decrease the value by something between 1-100 and see what happens. I had a similar issue with a usb/serial adapter and changing the value to a slightly lower(or maybe higher) value fixed the issue.

[Artem-N]

Really appreciate for help, I'll try playing around with those settings, sounds like a good idea! and in any case you saved me incredibly, good luck to you.