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

[sircrashalot]

I have been reading through this and are my assumptions correct that crossfire is working on the 9XR PRO? I am about to order the micro module for long range flying. I have updated to the latest firmware ersky9x-A4r223.

[MikeB]

Yes, crossfire protocol is supported by erskyTx on most radios, including the 9XR-PRO.

Mike

[sircrashalot]

I got the Crossfire Micro module finally and all i can get working are the first 4 channels. its not seeing any of my switches. all i did was change the protocol in the protocol menu to crsf from dsm. What am i missing. For the time being i flashed my 9xr pro over to the opentx version that supports the 9xr pro. Its quite a bit buggy but it works.

[MikeB]

I'm not aware of any problems, in erskyTx, with the CRSF protocol, it always sends 16 channels, so if 4 work the next 12 should also work.
What do you have in the mixer lines for channels 5 to 16?

Mike

[sircrashalot]

What is the correct firmware that I should be on? I have been pulling from the test version page.

[MikeB]

Unless noted in the description under the test versions, they are the "latest", fully functioning versions, so you should be fine.

What do you have in the mixer lines for channels 5 to 16?

Mike

[sircrashalot]

I went through and remapped the mixer channels for the switches and they seem to be working now

[juliannojungle]

Hi! Sorry to get into the middle of the conversation, but I need some direction.
Is it possible to have CRSF protocol on the Turnigy9x with stock board m128 and telemetry mod? Or there's some processing power limitation? I'm using the full crossfire TX (the one with oled screen on it).

I've read most of this thread and got some info, but couldn't get to a conclusion.
- It uses bi-directional serial on pin 5. That's just firmware or do I need any other mod to have that? I did the telemetry mod with JR pin 2 with 470R to processor pin 2 and JR pin 5 to processor pin 3.
- It the processor talks to the module at 400k baud, but some radios uses 200k.
- Mike implemented CRSF on erskyTx, but I can't tell the difference from er9x. Is that the one for arm processors like Taranis?

I've read on github the following:

16 channels sent every 2.5ms now @ 200KBauds with CRC

which indeed leads to the 200k baud rate said here, but in this issue from TBS branch, it appears to be a lot less:

data is only being transmitted from FreedomTX to the external module at 50Hz

As far as I know, that 50Hz is the link between TX and RX, but they stated that being the rate between radio and module, which got me confused. If that's true, there should be no reasons for Turnigy9x not be able to run that.

I installed the "er9x-128.hex" and the module recognized as being "PPM 8Ch". Changing the protocol to SBUS on model menu, the module displays "FUT 12Ch".

[Kilrah]

The "data is only being transmitted from FreedomTX to the external module at 50Hz" is about controlling an external third party module on the Tango2 radio, so not related to crossfire at all.