Serial out for LRS boxes

This is probably a very niche category, but I just implemented SUMD serial out of the trainer port to interface with my openLRS box. It has much less jitter than the PPM did which is nice.

I don't have a crossfire module to test, but it looks like implementing that serial protocol (IDK about telmetry) would be pretty easy as well.

Link to repo?

I don't have it on a repo currently. I'll try to figure it out, but I think it only changes one file and adds one file. I have a github account so I guess it's time to figure out how it works.

For now I've attached the two changed files. It's just an edited version of ppmout.c to use serial.

This is my first try at github. Does this work?
github.com/Elmeerkat/deviation

Looks good. Need to add an entry to protocol/Makefile.inc so a module gets built for limited memory builds. Is it possible to restore the state of extended audio at de-init?

Convention is to make pull requests from branches, so best to move the changes to a branch before making a PR. Makes it easier for others to test and keeps history cleaner.

@hexfet: restoring extended-audio is not necessary, as it get's reevaluated at the next protocol load

edit: I can't remember the exact reason, but I had an issue with resetting extended audio on deinit. It was somehow connected with Protocol_Init() first calling Protocol_DeInit()...

@hexfet
so I should keep my fork, but put the changes in BRANCH_5.0? Is that right? And then when the code it ready a pull request is made?

EDIT: wait, do I make my own branch under my fork called something like serialout? and then once it's done I submit a pull request from there? Sorry for all the questions!

Right now I just set the baudrate to 0 on deinit because that's what I saw in the FRSky protocol that has s.port out on the serial port. Should I also do? I wasn't sure why some protocols do it and other do not.

@Moeder I don't have audio on my TX. Is there a way I can test that with the emulator or something? Or should I just leave it to the next protocol load?

Yes keep your fork. No don't add your changes to BRANCH_5.0. New development goes in a new branch you create that's based on the upstream master branch. You'll need to backtrack a little since the changes are already in your local master. Those changes should be moved to their own new branch, so your local HEAD is back to the same as upstream/master. Then push all those changes to github so that repo is in the same state as your local one. Out of time right now else I'd look up the commands...

Thanks, working on it now

EDIT: I think I've done it correctly.
github.com/Elmeerkat/deviation/tree/serialout

Perfect. Now you can go ahead and make a pull request. If possible, also fork deviation-manual and add descriptions to ch_protocol.rst

So if I want to add the other serial protocols (S.Bus, CSRF, etc) do you think it would be better to have them under separate protocols, or all under one protocol called serial with an option to select each one? I believe CSRF and FPORT have the option for telemetry as well.

Then maybe I can start attacking another protocol that I am able to test.

Separate protocols would be easier to maintain, so I'd go this way. Also, the 7e has limited RAM available and Deviation actually swaps in and out protocols on model change, so simpler and smaller protocols are preferable (not that CRSF is a simple protocol, it's not).

Will this be plug and play with the Serial in mod for the TX as described here? shown here...

www.rcgroups.com/forums/showthread.php?1...=Serial#post38822305

I hadn't seen that! Glad OLRS is getting some development. I'll look at the code

The sole developer of qlrs is putting out feelers for serial control of his Lora TX as well. it would be great for Deviation to be an alternative to OpenTX.

I have opened a topic some time ago here at the forum on Support for LORA modules, referring to QLRS system.
It would be great if we could, natively support it, without serial or ppm links.

(Further more LRS systems are using LORA,such as TBS Crossfire, with very good results)

Hi guys,
thx for working on deviation. Just flashed my 12S last week. Works great!

Elmtree mentioned CRSF would also be possible.
I have a crossfire module laying around here. I cannot code good enough to implement the CRSF protocol myself, but if it is done, I could run some testing on it.

I don't have too much time right now because of school. Once I'm less busy I'll finish up the SUMD protocol and look into X-Fire again. Maybe emailing TBS for advice could work as well.

I'd love to see Crossfire support. The new Jumper T8SG Plus has a module bay, so this would be a huge step forward for Deviation to support CRSF modules.

Some guys are running them on spectrum tx why can’t I do the same on my devo8s? I really would like to change my quads to crossfire without having to buy a new tx.