Passthrough telemetry over CRSF (crossfire)

Development Team
41

Do we have bluetotth on microtx v2s? Never even tried wifi yet

42

With or without OpenTX support? We could extend them and let OpenTX eventually catch up? In the meantime they would be passed to lua because OpenTX would not have knowledge of those new sensors or we might simply create them as ardupilot custom frames, either option would require a full rewite of the telemetry decoding portion of my lua scripts :frowning:

43

ah, that explains it.

no, vice versa, wifi option on fullsize.

44

Ah thatā€™s not good. So maybe just donā€™t degrade the performance of the exitsing telemetry too much if you can help it.

45

No problems for mode 2, Iā€™ll need to experiment in mode 1, problem is with microtx v2 I donā€™t have a way to select rf mode 1 as you do, and even at 25mW crossfire is hard to force in mode 1 at the bench :rofl:

46

ā€œforce telemetryā€ option supposedly forces to 50 / 4 Hz mode only

47

reallyā€¦hahaā€¦I was looking for ā€œrf modeā€ā€¦Iā€™ll try, thanks!

48

Hi Peter,
A little off topic and possibly a dumb question but I have been trying to set up a Bluetooth connection like you have with no results. Would you tell me the settings you are using for both the Crossfire side and the mission planner settings for the UART you are using. I am trying to do this using channels 3 & 4 on a Crossfire Nano receiver. Iā€™m using channels 1 for the SBus connection.

Thanks

49

I use channels 3 and 4 on the nano set to mavlink rx and tx. I do not use channels 1 and 2 because I have enabled rc over mavlink on the nano.
I want to test rc over mavlink also.
The nano channel 3 and 4 are in my case connected to telemetry 1 in ardupilot. For me that is uart6 on the kakute f4 v2.
Then make sure when using bluetooth on the fullsize crossfire that you set bluetooth to mavlink and you should be good to go.
Connect your laptop or phone with Bluetooth to the crossfire. And when you open missionplanner or qgroundcontrol you should be able to connect.
With the latest update for crossfire you can also now use wifi.
I can now also connect my laptop over wifi to the fullsize crossfire. And when I open missionplanner start a udp connetion on port 8888 I am connect to the quad.

50

Thanks, Iā€™ll give that a try and report back.
Richard Powell

51

With OTX 2.3.10 the HUD at the transmitter does not move. But the corresponding telemetry values are present and change when the FC is moved.

1 Like
52

Hi, please set RC_OPTIONS bit 8 = 1 (add 256 to your current RC_OPTIONS value) and reboot, I do not use the sensors, I use custom telemetry frames

53

Hi Alex,

thanks, had of course only added 128 ā€¦ :grin:

54

Haha bitmasks are subtleā€¦ a common mistake I made myself :rofl:

Is it working?

55

Yeah, itā€™s on.

(20 Characters ā€¦)

1 Like
56

Hi Alex,

thankā€™s for the response. A few things to figure outā€¦

57

I upgraded to 4.05 and Bluetooth + MAVEmu is now worse. Not really any useable data and HUD no longer moving

58

@yaapu tested with adjusted tlm rate fw and updated x9d script. RSSI panel displays perfectly, thanks a lot! the aforementioned symptoms however stay unchanged.
i tested with RF mode forced to 1 too, that kind of delayed the stalling at GPS fix for a neglectable moment only. iā€™m under the impression that somewhere the link saturates, and i canā€™t wrap my head around how that might be related to sat fix, but itā€™s definitely reproducible and doesnā€™t happen without.

the yaapu debug screen btw shows zeros on all instances regardless of tlm present. is that expected behaviour?

on a sidenote i acquired a box of peroni to accompany the testing. i can confirm a noticeable improvement of my subjective disposition only, the telemetry issues however do not seem to respond equally wellā€¦

59

ahaha! After the right number of beers the issue will be negligible :slight_smile:

1 Like
60

@andyp1per @vierfuffzig Iā€™ve done some testing and unfortunately the results do not look very promising.
I changed the code to always respond to polling with a custom frame whose content is a sequence.
I then created a lua script to process the sequence looking for holes, the bigger the hole the bigger the frame loss.
I also printed the polling frequency, (the times ardupilot is given a chance to send a telemetry frame,I was expecting 150Hz, but the actual polling for telemetry packets is around 35Hz. @andyp1per Iā€™m plotting the AP_RCTelemetry::_schedule._avg_polling_rate .
The lua script registers around 30Hz for the incoming packets with a frame loss of 10%-15%, which is kind of like fport whereas sport has 0% frame loss.
This implies that the mode 2 scheduler should be tuned for 30 Hz including native + custom telemetry.
When switching to rf mode 1 I still see a polling betwenn 22Hz and 35Hz but my lua script gets a packet every few seconds, with a frame loss of 8000%-10000%, so my conclusion is that custom packets are dropped by the RX , I get these numbers with native telemetry disabled.