CRSF protocol for TBS Crossfire?

[oo20]

Through experimenting I found within the firmware version 9xr Pro version ersky9x-pf8r221 date 20.12.2017 that Full Size Crossfire reports transmitting modes through 9xr Pro Telemetry custom field "Cus6" (a value of 2 or 1 for Crossfire Op-Mode "Normal", and 1 or 0 for Crossfire Op-Mode "Forced Telemetry"). Confirmed while having someone read values as I drive away at 10mw / non dynamic. I'm thinking that Cus6 can be renamed to RFMD. In a FAQ / Support page I found that RFMD 2 = 150Hz Mode, RFMD 1 = 50Hz Mode, and RFMD 0 = 4Hz Mode (forced telemetry). http://team-blacksheep.freshdesk.com/su ... for-opentx I'll try a later 9xr Pro version when I upgrade my full size Crossfire (which is at V 2.31 which allows higher transmit power). Thank you!

[MikeB]

I don't have (or therefor use) any TBS crossfire hardware. When I receive a LINK telemetry frame, I store the TX_QUALITY in TSSI, the RX_QUALITY in RSSI and the first 6 items in the frame in Cus1 to Cus6 (Custom telemetry values).

Cus1: RX_RSSI1
Cus2: RX_RSSI2
Cus3: RX_QUALITY
Cus4: RX_SNR
Cus5: RX_ANTENNA
Cus6: RF_MODE

I may be able to do a bit better if I know what people want, creating new telemetry items. I had reached a limit where it wasn't easy to add more items, but I recently fixed that problem.

Since, with other telemetry protocols, Cus1 to Cus6 may be used for other things, I can't just rename Cus6. What you could do, for now, is use a scaler with source Cus6, and apply a new name in the scaler.

Mike

[nrw505]

I've been working on getting Hertz's crossfire script extended, and I've finally discovered that sending a packet with crossfiresend() in basic usually doesn't send what's asked for over the wire.

e.g.

Code: Select all

    transmitBuffer[0] = deviceIds[deviceIndex]
    transmitBuffer[1] = DEVICE_ID_RADIO_TX
    transmitBuffer[2] = requestParameter
    transmitBuffer[3] = requestChunk
    crossfiresend(FRAME_POLL_PARAMETERS, 4, transmitBuffer)

usually results in a packet of

Code: Select all

[238, 6, 44, 238, 0, 0, 0, 38]

going out to the module instead of the expected

Code: Select all

[238, 6, 44, 238, 234, 1, 0, 134]

I think I've fixed it in https://github.com/MikeBland/mbtx/pull/40 , if you could take a look that'd be ace.

[nrw505]

And now there's a mostly-working crossfire script at https://github.com/nrw505/ersky9x-crossfire-script

Note - only does enough to change power settings and enter binding mode on the Micro TX module so far

[MikeB]

I've done a change a bit differently (to minimise RAM usage, see comment on Github), pushed my changes and posted a new test version of ersky9x (on the test versions thread as usual). I've included your other changes, except indentation ones.

Mike

[nrw505]

Confirmed that 222c5 fixes the crossfiresend() issue.

Though now it gives me an "RX was still powered" warning when powering down while the crossfire module isn't connected to any receiver, just FYI

[MikeB]

The feature uses the RSSI value (being non-zero) to detect if the Rx was still powered.
What value do you have for RSSI with no Rx connected?
Please confirm you are using a 9XR-PRO? The "RX was still powered" is handled slightly differently on different radios.

Thanks for testing and spotting the crossfiresend() problem. I don't have any crossfire hardware!

Mike

Edit: I think I have the fix for that showing on the 'PRO when it shouldn't.

[nrw505]

Yes, 9XR-PRO. RSSI being reported is 0.

[nrw505]

On the plus side, it does still give the "still powered" warning when the RX is powered and RSSI is non-zero

[MikeB]

If you compile the firmware yourself, change line 3693 in ersky9x.cpp to:
if ( FrskyHubData[FR_RXRSI_COPY] )

Mike