PXX protocol

Ya sport telemetry with r9 seems correct, getting the basic volts, current n rssi displayed as in inav. But for Qlrs there's some values displayed but not tally with inav configurator. I've tried mavlink enc displaying through serial lines on mission planner and telemetry looks correct there. Something's going on in qlrs » devo sport message relaying but unfortunately I'm not smart enough to solve.

The telemetry codes listed at the bottom of this page look correct. You've done the hardware mods and Qlrs software configuration listed on that page?

Do you have an FTDI adapter or logic analyzer that could be used to make a capture of the telemetry data?

Sport signal is taken directly from M0 pin into devo, as I understand correctly the additional resistor is only needed if using sbus in conjunction with a telemetry capable frsky rx as a relay.
I have a ftdi adapter but I'd need some pointers how to capture the telemetry data needed as I've not done it before.

Edit: after reading back some pages, to capture sport data using ftdi I'm suppose to connect sport signal to ftdi rx pin and read data using Realterm? Is this correct?
Mine is a clone version of ftdi adapter which doesn't allow rx tx inversion, can I use it for this purpose?

The connection info is correct, but without an inverting FTDI the data probably won't make sense. Probably still worthwhile to test just to see something's coming out. If it is decoded correctly that would be a surprise. Data rate is 57600, 8 data bits, no parity, 1 stop bit. If the data is inverted as expected there will probably be data displayed but in Realterm the Status box on the right of the Display tab will have some of the error indicators flickering.

Ok got some data capture but dunno what to make of it. There's actually some telemetry showing but looks like it in the background and some number or character flashes on and off on the devo screen.

It's not valid data but at least shows something is coming out. The sport data signal is likely inverted.

There's a test version here if you'd like to try it. The TESTSER protocol is modified to accept inverted data on the rx pin. Use the loopback protocol option. The tx pin will then have the data uninverted. Feed that into the FTDI and capture the data. Hopefully it'll be correct sport data.

Just wanna confirm I'm getting this right, feed the sport signal from lora module into the stereo plug ring n feed output from stereo plug tip to ftdi rx pin?

You've got it. I think the default data rate for TESTSER is 115200. Check the protocol options to be sure. The protocol option settings need to match the realterm port settings. In valid data there will be many "7E" values.

ok will get back here hopefully with some data soonest possible

I can't capture any data from plug tip tx, checked TESTSER is 115200 8N1 as in ftdi and realterm. I tried connecting plug ring rx and I can see data capture with the mentioned 7E values. What am I doing wrong?

The test build is updated (d43e4f9). I had to make a fix in the code. Please try with this build.

Here's the capture from the latest testser, data looks the part hope it's what you're looking for.

Very helpful, thanks! The data looks good except bytes are occasionally missing. Without a data capture directly from the Qlrs it's not possible to deduce if they're missing from what Qlrs is sending or if they're being dropped in the tx. But I've bench tested with a continuous data stream into the tx and haven't seen dropped bytes.

Test build is updated (2daa1d6). This version checks the telemetry crc and ignores bad packets. Testing with the captured data in the emulator the bad telemetry values don't occur anymore.

Bad news, it's still displaying wrong telemetry in devo screen.

The value of 900 in the Temp2 spot is what is in the data in the capture2.txt file. It is the value being provided by Qlrs. The s.port packet is 7E981010048403000054.

The 687... value for altitude is not in the capture2 file. Was there anything different about the receiver/FC setup when you got this value? Maybe make another (longer) capture to try to catch this. With the data in the capture2 file the value is always 0.

I'll try to get a longer capture later tonite. I've also got a locally sourced ftdi coming, hoping it'd do rx tx inversion.

Here's a full 5 min of capture data. Just to answer your question, same connections from before.. nothing changed. Just flashed testser connected plug tip for data capture and reflash test build reconnected plug tip to view the telemetry in devo.

All the altitude telemetry packets in this capture have value 0. When I use this data in the emulator the telemetry value always displays 0.

When running the test build is the 6878658 value consistently displayed in the altitude box, or does it flicker with other values? If it's a steady value it may be something Qlrs only sends when it is receiving a PXX signal.

With the added crc check in the test build the captured data does not cause any erroneous values to be displayed.

The 687 value is steady. Is the basic values like rssi n volts also have 0 value in the capture? I'm guessing there's nothing more I can help with unless I can capture data directly from qlrs module? Hope the new ftdi gets here soon, n it's the rite one.

Yes, all the displayed values match what is in the capture.

Looking over the data again I noticed a few unusual sensor id values. Going back to this page , it lists the following non-standard sensor id numbers:
These are not in the s.port spec or in opentx. All except the first two appear in the captured data. Does this make any sense with what you know about Qlrs telemetry?

For testing I've added a test build(93d878b) to map these sensors to the following display spots:
ALLCELL - APID_CUST_RSSI
CELL1 - APID_RX_RSSI_REG_VAL
CELL2 - APID_RX_SNR_REG_VAL
CELL3 - APID_RX_PACKET_LOST_VAL
CELL4 - APID_MAV_BASE_MODE
CELL5 - APID_MAV_SYS_STATUS
CELL6 - APID_MAV_CUSTOM_MODE

Ignore any decimal point that may be in the display for these items. In the captured data only CELL1, 2, and 3 are non-zero.