Passthrough telemetry over CRSF (crossfire)

UnknownPilot · August 22, 2022, 9:49am

Just a very quick question: I’m still using PWM channel source for RSSI (actually LQ), as setting it to receiver protocol always gave me wildly fluctuating numbers instead of Crossfire’s trademark “99”. I noticed that this year however, all my craft show “100” instead. Is that to be expected due to some change in the meantime?

andyp1per · August 22, 2022, 11:16am

IIRC some minor changes were made to the meaning of RSSI at some point

UnknownPilot · August 22, 2022, 11:44am

Ok thanks, then it’s probably ok. What made me wonder a bit is that I have yet to see it drop from that 100, but then again I haven’t been flying very far out lately.

RizHass · August 22, 2022, 11:53pm

@yaapu @dkemxr has anyone tried running simultaneously both Yaapu script while connected to the PC via Wifi or Bluetooth?

My aircraft is running Yaapu over CRSF (No issue) but when I try to connect with Mission Planner using TCP it goes into some weird parameter retrieval mode forever. I am suspecting that the SerialX_Protocol should be 2 according to TBS documentation, but for Yaapu it is set at 23. This could be one issue.
Also when somewhat connected with MP, the HUD display shows aircraft “ARMED” when its not armed, additionally the plane shows up as a copter on the Mission screen (both on phone app and laptop) @Michael_Oborne

Giorgo · August 26, 2022, 11:19am

Sometimes I am using also connection to the phone MP via WiFi, together with Yaapu and MP is running - slowly, but running. I have Serial1 with prot. 23 for CRSF and Serial2 with prot. 2 for MAVLink. In AP I set also the SR2 timing according to Crossfire manual. I am still using TBS v.4.11, because they have some issue with BST protocol in the later revisions.

timtuxworth · August 26, 2022, 4:11pm

I"m pretty sure I see the same problem using Yaapu over ExpressLRS. Wifi connects to the FC, but usually times out downloading parameters. This happens with MP or QGC.

olliw42 · August 30, 2022, 10:37am

@yaapu
sorry for having to ask you again
I am making progress with adding support for your telemetry app to the mLRS project, and it successfully sends multi (0xF2) packets … at least your crsf debug lua script digests them happily (MANY thx btw for this script, extremely useful) … but:

It seems that you digest multi packets ONLY if they contain at least 8 datagrams:

github.com

yaapu/FrskyTelemetryScript/blob/master/HORUS/SOURCES/SRC/WIDGETS/Yaapu/main.lua#L1983


      
              -- hash support
              updateHash(data[i])
            end
            utils.pushMessage(severity, status.msgBuffer)
            -- hash audio support
            playHash()
            -- hash reset
            resetHash()
            status.msgBuffer = nil
            status.msgBuffer = ""
          elseif #data > 48 and data[1] == 0xF2 then
            -- passthrough array
            local app_id, value
            for i=0,data[2]-1
            do
              app_id = bit32.lshift(data[4+(6*i)],8) + data[3+(6*i)]
              value =  bit32.lshift(data[8+(6*i)],24) + bit32.lshift(data[7+(6*i)],16) + bit32.lshift(data[6+(6*i)],8) + data[5+(6*i)]
              --utils.pushMessage(7,string.format("CRSF:%d - %04X:%08X",i, app_id, value), true)
              processTelemetry(app_id, value, now)
            end
            status.noTelemetryData = 0

Why is this so?

I was actually hoping to only use the multi frames, and fill in as many as there are at a point in time (of course restricted to 1 to 9). I wouldn’t mind to send also single (0xF0) packets, but having to send e.g. 7 of them instead of one multi packet if 7 datagrams is not what I would consider ideal.

Any chance this can be dropped to 2 datagrams?

Or should I, if I only want to send e.g. 2 datagrams, just fill the other 6 with dummy data so that processTelemetry() won’t digest them?

Many thx again, Olli

yaapu · August 30, 2022, 10:48am

Hi @olliw42 you need to check the dev branch, I made the length variable when I added support for ELRS, check here

github.com

yaapu/FrskyTelemetryScript/blob/15f07b720fdd25d905d3b95aa44cb26d4ee22307/HORUS/SOURCES/SRC/WIDGETS/Yaapu/main.lua#L2041


      
          -- MAIN LOOP
          --------------------------------------------------------------------------------
          --
          local bgclock = 0
          
          

          

          
-- telemetry pop function, either SPort or CRSF
          local telemetryPop = nil
          
          
local function crossfirePop()
              local now = getTime()
              local command, data = crossfireTelemetryPop()
              if (command == 0x80 or command == 0x7F) and data ~= nil then
                -- actual payload starts at data[2]
                if #data >= 7 and data[1] == 0xF0 then
                  local app_id = bit32.lshift(data[3],8) + data[2]
                  local value =  bit32.lshift(data[7],24) + bit32.lshift(data[6],16) + bit32.lshift(data[5],8) + data[4]
                  return 0x00, 0x10, app_id, value
                elseif #data > 4 and data[1] == 0xF1 then
                  local msg = {}

and here

github.com

yaapu/FrskyTelemetryScript/blob/15f07b720fdd25d905d3b95aa44cb26d4ee22307/HORUS/SOURCES/SRC/SCRIPTS/TOOLS/Yaapu Debug CRSF.lua#L37


      
          local flushtime = getTime()
          
          
local function processTelemetry(data_id, value)
            if packetStats[data_id] ~= nil then
              packetStats[data_id].tot = packetStats[data_id].tot + 1
              packetStats[data_id].count = packetStats[data_id].count + 1
            end
            io.write(logfile, getTime(), ";0;", data_id, ";", value, "\r\n")
          end
          
          
local function crossfirePop()
              local command, data = crossfireTelemetryPop()
              -- command is 0x80 CRSF_FRAMETYPE_ARDUPILOT
              if (command == CRSF_FRAME_CUSTOM_TELEM or command == CRSF_FRAME_CUSTOM_TELEM_LEGACY)  and data ~= nil then
                -- actual payload starts at data[2]
                if #data >= 7 and data[1] == CRSF_CUSTOM_TELEM_PASSTHROUGH then
                  local app_id = bit32.lshift(data[3],8) + data[2]
                  local value =  bit32.lshift(data[7],24) + bit32.lshift(data[6],16) + bit32.lshift(data[5],8) + data[4]
                  return 0x00, 0x10, app_id, value
                elseif #data > 4 and data[1] == CRSF_CUSTOM_TELEM_STATUS_TEXT then
                  return 0x00, 0x10, 0x5000, 0x00000000

yaapu · August 30, 2022, 10:50am

also remember to set the correct packet count in the frame, check here

github.com

ArduPilot/ardupilot/blob/0b1f959ede961448c659a5d54b8bffe580b87c6d/libraries/AP_RCTelemetry/AP_CRSF_Telem.cpp#L1410


      
              _telem_type = get_custom_telem_frame_id();
              _telem_pending = true;
          }
          
          
/*
           Get up to PASSTHROUGH_MULTI_PACKET_FRAME_MAX_SIZE packets of passthrough telemetry data (for slow links)
           Note: we have 2 distinct frame types (single packet vs multi packet) because
           whenever possible we use smaller frames for they have a higher "chance"
           of being transmitted by the crossfire RX scheduler.
          */
          void AP_CRSF_Telem::get_multi_packet_passthrough_telem_data(uint8_t size)
          {
              size = MIN(size, AP_CRSF_Telem::PASSTHROUGH_MULTI_PACKET_FRAME_MAX_SIZE);
              _telem_pending = false;
              uint8_t count = 0;
              AP_Frsky_SPort::sport_packet_t buffer[AP_CRSF_Telem::PASSTHROUGH_MULTI_PACKET_FRAME_MAX_SIZE] {};
              // we request a PASSTHROUGH_MULTI_PACKET_FRAME_MAX_SIZE packet array, i.e. 9 packets
              if (!AP_Frsky_Telem::get_telem_data(buffer, count, size)) {
                  return;
              }
              _telem.bcast.custom_telem.multi_packet_passthrough.sub_type = AP_RCProtocol_CRSF::CustomTelemSubTypeID::CRSF_AP_CUSTOM_TELEM_MULTI_PACKET_PASSTHROUGH;

olliw42 · August 30, 2022, 11:42am

@yaapu
ok, MANY thx for the quick response
and the clarification

my reason to not consider dev (again LOL) was hoping that I could say “hey, it works with yaapu stable release”
(IMHO, many folks in this OTX/ETX community are quite conservative with non-stable stuff…)

since dev is so much better than the stable, may I kindly ask, do you have any time plan for a next release?

yaapu · August 30, 2022, 12:20pm

yeah, you’re right, dev is better and actually nobody reported significant bugs about it, I should promote it to stable

I took a look at yout mLRS project, very very cool!

olliw42 · August 31, 2022, 8:40am

mLRS: many thx, sir. I am starting to get happy with it LOL

I am sorry but with digging deeper further questions come up again, so sorry for having to bother you again. It’s now 3 questions actually

WAYPOINT 0x500D
In this datagram, is bearing supposed to be nav_bearing or target_bearing?
VFR_HUD 0x50F2
It is obviously not used anymore in ArduPilot, but MavToPass digests it. So I wonder, is there any benefit of also sending VFR_HUD?
When I do I appear to see issues with the throttle sent by both AP_STATUS 0x5001 and VFR_HUD 0x50F2, i.e. their different format seems confuses the lua app (I sometimes see neg numbers, and that’s at least my “explanation”). This would suggest to better not send VFR_HUD.
But VFR_HUD gives the airspeed.
In order to have both ground and air speeds, would it in your opinion make sense to send two times VEL_YAW 0x5005, with groundspeed and airspeed?
(note, this is only between radio and tx module via 400kbps crsf, so no bandwidth issues)
Sign handling
For some data negative values are represented with an extra sign bit.
In the MavToPass code one finds that sign bit to be set explicitly, but in your ArduPilot code I nowhere can find such code pieces. I also note that your prep_number() is different from MavToPass’ prep_number()
So, I wonder - and my question would be if you can confirm this - do you do it as follows: Your prep_number() always adds a sign bit to the result, but if it is not present in the passthrough packet, it is then “overwritten” when the full u32 is composed by shifting the next value to its location. Yes/no?

many thx again

olliw42 · August 31, 2022, 8:42am

btw, small spelling error in this line: ardupilot/AP_Frsky_SPort_Passthrough.h at master · ArduPilot/ardupilot · GitHub, 0x5003

yaapu · August 31, 2022, 10:47am

Just a quick reply with a question, you are forging crsf telemetry packets from mavlink which will save bandwidth but will require code changes in case of frsky/crsf telemetry protocol changes (new frames), did you consider making it transparent to CRSF telemetry frames as well (escluding status text messages which can easily be created from mavlink) bandwidth would be not too high

yaapu · August 31, 2022, 11:11am

I use AP_Vehicle::get_wp_bearing_deg() and the implementation is vehicle specific:

ArduCopter/Copter.cpp:725:bool Copter::get_wp_bearing_deg(float &bearing) const
ArduPlane/ArduPlane.cpp:689:bool Plane::get_wp_bearing_deg(float &bearing) const
ArduSub/ArduSub.cpp:333:bool Sub::get_wp_bearing_deg(float &bearing) const
Rover/Rover.cpp:467:bool Rover::get_wp_bearing_deg(float &bearing) const

Plane for example uses nav_controller->target_bearing_cd(), in general it follows mavlink’s NAV_CONTROLLER_OUTPUT

You can ignore VFR_HUD.
To send both airspeed and ground speed check the code here, you’ll see that there’s a bit to set when the frame contains airspeed, the telemetry widget auto-detects this
ardupilot/AP_Frsky_SPort_Passthrough.cpp at b6a5eb064c1595435c6f14ed2f75b9b44836f375 · ArduPilot/ardupilot · GitHub
what you ask is not clear to me, sign bits should not be overwritten when shifting, they should be 0 unless set to1 by prep_number, I’m sure I’m missing something though!?!

olliw42 · August 31, 2022, 11:12am

Just a quick reply with a question, you are forging crsf telemetry packets from mavlink which will save bandwidth but will require code changes in case of frsky/crsf telemetry protocol changes (new frames), did you consider making it transparent to CRSF telemetry frames as well (escluding status text messages which can easily be created from mavlink) bandwidth would be not too high

I’m not sure I understand your question
in the tx module (when it is in “crsf mode”) I do two things with the mavlink messages which are coming from the receiver:

I extract data to send “native CRSF” telemetry frames to the radio. It are those which are so to say defined by TBS, and which you also would get with e.g. a TBS system. It are those which in EdgeTx/OpenTx you get by discovering sensors, and you can handle them by all normal OpenTx/EdgetTx means.
This is in mLRS since a while: mLRS/mLRS/CommonTx/crsf_interface_tx.h at main · olliw42/mLRS · GitHub.
I extract data from them to send CRSF packets with the passthrough format to the radio, so that your lua script can be used (in full). That’s what I am working on (it’s essentially all already working great, only the data may not be all perfect)

I do NOT send CRSF packets over the air link, in order to save e.g. bandwidth. That is, there is no conversion on the receiver side, the data over the air is still native MAVLink. It’s all just tx module side. (it’s a bit like you would have a SiK radio and a Mav2Pass module on the tx side)

Does this answer it?

I guess it’s a general problem of any protocol when it changes.

yaapu · August 31, 2022, 11:16am

yes, I do understand what you do, I just asked if you considered sending FRSKY telemetry frames over the air and pack them in CRSF telemetry frames on the TX, except for status text messages the required bandwidth would be really low.
But I also understand that your solution is the best bandwidth wise.

olliw42 · August 31, 2022, 11:30am

ah
no, I myself do not have plans to work with FrSky frames at any level
but you know, it is open source … anyone can add this… LOL
Sending them in addition to the MAVLink stream indeed would help with protocol changes & additions, but I think it’s not like that it changes every day (I think that mLRS won’t be the slowest part in the chain)
If one only wants the FrSky-type telemetry, i.e., no MAVLink over the air, then I think that ELRS would be a great option.

olliw42 · August 31, 2022, 11:46am

hm, so no easy answer LOL. I guess I need to dig deeper
so in your opinion it indeed would be a viable approach to just send two VEL_YAW 0x5005 “at the same time”, one with airspeed and one with groundspeed, right?
I am just trying to ensure I understand your code. Sure, there shouldn’t be a sign bit where it shouldn’t be, the question was just how you achieve that in your code. I do not see any code pieces which would handle the sign specifically, but your prep_number() always adds it to its return result, so it appears to me it is “masked out” in your << operations higher up. E.g. here ardupilot/AP_Frsky_SPort_Passthrough.cpp at master · ArduPilot/ardupilot · GitHub it seems to me it works because the prep_number(current)'s sign bit is overwritten then by the next line.
Do I get this right?
Wouldn’t it e.g. mean that the values are not clamped to range, but that a negative bat current would show up as positive bat current?

yaapu · August 31, 2022, 11:59am

hm, so no easy answer LOL. I guess I need to dig deeper

I’d use target_bearing, or in general bearing toward next waypoint.

so in your opinion it indeed would be a viable approach to just send two VEL_YAW 0x5005 “at the same time”, one with airspeed and one with groundspeed, right?

Yes, even though in ArduPilot I do not sample both at the same time but with a couple hundred millis time separation, but if you do it’s even better, just remember to set the “airspeed” bit

requires some more thinking