Serial out for LRS boxes

I've finally got a moment to try the new CRSF protocol on my Jumper T8SG Plus. The problem I'm running into right now is I'm unable to configure the channels of the receiver to make it talk to my quad. It doesn't seem like TBS offers any sort of desktop software to configure the receiver. This is normally done via the Lua scripts on OpenTX. Is there any planned support for this in the near future? I think it's the only missing link.

hexfet wrote: I've made a first pass at the CRSF protocol. Test build (5026091) is available . This build only supports the RC channel values. No telemetry or configuration yet. No Crossfire module to test with but output looks good on analyzer.

On the T8SG-Plus connect the top and bottom JR pins together. I confirmed with TBS support that if the CRSF signal is present on both pins their module will accept the CRSF protocol on the bottom pin. The CRSF protocol signal will also appear on the tip connection of the trainer port jack on all transmitters.

To use select the CRSF protocol. Please report results.

I finally managed to get a response by excluding the top pin and redirecting it to the bottom input of the CRSF module, but when I jumped the top pin to the bottom pin with a wire it no longer worked. It seems when the CRSF module receives the same input from both the top and bottom pins it doesn't work.

On the plus side the CRSF protocol does work!

I decided to cut the pin and slide it out. At least I can slide it back in and re-solder if I need to. I'm happy to report that Crossfire works on the Jumper T8SG Plus! The channels all seem to work and I do see telemetry. Now for a range test!

Hello! I do not understand all this well, and do not know very well English. After reading this topic, I realized that there is a high probability that the jumper T8SG Plus will have full support for the crossfire protocol. Did I understand everything correctly? If so, then this is great news, I really like jumper T8SG Plus and firmware deviation! I do not want to change my radio!

yes there is PPM - S-BUS - CRSF protocols on the external module bay, flash latest nightly.

Whiffles wrote: I finally managed to get a response by excluding the top pin and redirecting it to the bottom input of the CRSF module, but when I jumped the top pin to the bottom pin with a wire it no longer worked. It seems when the CRSF module receives the same input from both the top and bottom pins it doesn't work.

On the plus side the CRSF protocol does work!

Thanks for the testing and detective work! Glad you found the issue and a solution. I've emailed TBS support with a link to your post and asked them to take a look. It seems the answer they gave previously is not correct. Are you running the latest TBS firmware?

For configuration I'm thinking some screens under the protocol options, but haven't looked into how difficult that would be. The protocol documentation is clear on how to send the configuration information but I'll need to look at the lua scripts to understand how the screens should be organized. It will be some time before there's something to test.

Can somebody post a link for this update? Cant find it

The CRSF protocol is included in the nightly builds.

For the issue of having to disconnect the top JR module pin from the Crossfire module, TBS responded that it shouldn't be necessary, but "It's possible the high datarate overloads the PPM module." Good news is they volunteered to send me a unit for testing, which will also be useful for developing the configuration screens.

Trimmed the top pin and it worked for me as well! I'll give it a try tomorrow in actual flight.

Ok thanks for all your engament in this protokoll. Im really looking forward to receive my crsf and test all that stuff.

Worked well for me! Didn't realize the module bay is always on? Or was there a setting when I switch to a different protocol. Otherwise I got to remember to unplug it when I am flying the frsky quads.

Since I had everything working I did a quick latency test with the crossfire serial out in the same way I've done my other tests.

docs.google.com/spreadsheets/d/1LPpkwxKV...SvI/edit?usp=sharing

Looks to be a little slower then taranis on opentx or ersky9x.

Haven't looked at the code at all, but my guess is that 0-5ms mixer calculation adding most of the latency (that you already changed on other protocols) ?

hexfet wrote: For configuration I'm thinking some screens under the protocol options, but haven't looked into how difficult that would be. The protocol documentation is clear on how to send the configuration information but I'll need to look at the lua scripts to understand how the screens should be organized. It will be some time before there's something to test.

I had a look at the Lua scripts and they seem pretty simple. I think they just request the configuration options from the receiver directly. It responds with each option to build the menu dynamically. When a value is changed it's sent to the receiver in real time. Shouldn't be too hard to code I don't think.

brycej wrote: Worked well for me! Didn't realize the module bay is always on? Or was there a setting when I switch to a different protocol. Otherwise I got to remember to unplug it when I am flying the frsky quads.

Yes, in the t8sg plus the module bay power pin is always active. The CRSF protocol does stop sending when a different protocol is selected.

brycej wrote: Haven't looked at the code at all, but my guess is that 0-5ms mixer calculation adding most of the latency (that you already changed on other protocols) ?

After my last post I realized I could also test the SBUS and CRSF protocols. Since their timing is simple I experimented with adjusting it dynamically based on actual mixer runtime. Typical mixer runtime value for 6 simple mixers settles at 350 microseconds. Since you were benchmarking FrskyX I also implemented the dynamic adjust there, but due to other processing in the protocol the minimum time given to the mixer to run is 500 microseconds. Since my small quad uses SFHSS I also implemented it there (350 us). Also added a protocol option to SBUS to adjust the packet period from 14 to 6 milliseconds in steps of 1. So with the latest test build CRSF should have a stick input to serial output latency of about 0.4 to 4.4 milliseconds. Then measured delay would also have the radio and fc delays.

Test build reduce_latency is updated ( 4acdab9 ). Source here .

• Reduced latency added for SBUS and CRSF
• Reduced latency improved for FrskyX and SFHSS
• Protocol option in SBUS to adjust packet period in milliseconds

Awesome! Thanks for that work! I'll run it through the latency test tomorrow while I still have everything setup.

Here are the results:

docs.google.com/spreadsheets/d/1LPpkwxKV...SvI/edit?usp=sharing

It seemed like it helped a bit. The fastest runs were almost a 1ms faster then opentx and ersky, and seemed to get rid of that bimodal distribution it had before. But overall it the average sample is still about 2-3ms slower then opentx and ersky9x.

Also when I have the crossfire or frskyx protocol selected on the t8sgv2 plus I can't hold the button to shut down the transmitter, when I switch protocols then it works fine.

Slightly offtopic: but here was the frsky_x results as well: docs.google.com/spreadsheets/d/1MlGdLWIP...ypg/edit?usp=sharing

Tab: deviation test code summary has just the testcode comparsion

tldr; Roughly 0.3-0.5ms faster then the previous test build you had.

Test build is updated ( 0e17017 ). The power button issue is fixed. The Frsky protocol is updated with dynamic adjustment of mixer runtime.

Not sure why the range of latencies is so large. Worth looking at.

I've been flying Crossfire on my Jumper T8SG Plus for the past few days and it works great! I don't feel any latency and my LQ rarely drops below 99%. I haven't pushed it yet, but I'm really happy with it. Now we just need a way to configure the module and the receiver. I've been swapping the module to my QX7 to make changes using the Lua scripts, but most people don't have that option.

Thanks for testing! Are you using the nightly build or the reduce_latency test build?

Planning to work on the configuration settings when the test unit arrives. It has started the trip.