Feature request: Selectable serial outputs instead of PPM

[DTFUHF]

Expanding on the DSM2/DSMX serial protocol that is already available but limited to 6 channels, I'd like to see some serial protocols available on the PPM output pin in the module bay. Specifically SUMD, but also SBUS, expanded Spektrum, etc. would ensure a broad range of compatibility with radio modules that accept a serial input. PXX is difficult to decode on lower end hardware (AVR) and has not seen widespread acceptance. PPM latency is high vs. these serial protocols, especially on 16 channels.

[fujin]

++++:100:

[mlyle]

Or just turn up the DSM to use more channels. :P

[DTFUHF]

I'm not able to do this, it's limited to 6 channels.

[mlyle]

@DTFUHF -- not sure I understand. http://wiki.paparazziuav.org/wiki/DSM The actual protocol appears capable of carrying 18 channel streams.

[DTFUHF]

Yes, but I'm unable to do this in OpenTX.

[bsongis]

Why not SBUS on the PPM Pin.
Or perhaps we could use the S.PORT Pin for sending pulses in whatever serial format (there is an hardware serial on this pin), and Heartbeat Pin for receiving Telemetry.
Because bitbanging on the PPM Pin uses CPU ...

[DTFUHF]

I would definitely be open to any form of serial TX on the module bay pins.

[kilrah]

The only 2 pins we can drive in there are pin 1 (usually PPM), which in terms of hardware driving possibilities is a timer output, and pin 5 (smart port), multiplexed, inverted serial port.

On pin 2 we can receive only, inverted serial port.

[MikeBland]

Is this related to this project?: http://www.rcgroups.com/forums/showthread.php?t=2165676.
Er9x and ersky9x (including on the Taranis) are supporting this serial protocol, on the PPM pin. It is a variant of the DSM hack protocol.
Also, for serial receive, on ersky9x I have "bit-bang" code working to receive serial data, both inverted and non-inverted, on a processor pin. This works by making sure all other interrupts are a lower priority, then using an "interrupt on pin change" interrupt at the highest priority to detect the edges on the serial input and decode them into a serial data stream.

[phobos-]

Seeing so many Taulabs guys I'm guessing it's for Taulink module, or OpenLRS. IMO adding SBUS or 115200+ baud Serial protocol on pin 5 transmitting all 16 channels with some kind of interrupt similar to XJT heartbeat would be the best and quickest approach with least latency.
@DTFUHF why you need it specifically on the PPM pin, I think you already have telemetry serial port wired to pin5 (TX) and pin2 (RX), why not use that instead? At least in your deluxe tx.

[DTFUHF]

TauLabs guys are here since we were discussing this issue in #taulabs on freenode IRC :)

I don't require any specific pin, the functionality itself benefits more people than just me. But I do have pins 1 and 2 connected to RX on some hardware.

[bsongis]

[bsongis]

For the moment 16 channels sent every 5 ms with SBUS protocol on S.PORT Pin. But careful it's inverted serial!

[mlyle]

@bsongis Nice!

[DTFUHF]

Very nice, thank you :)

[Nub]

Awesome! Can't wait to give her a test!

[fujin]

This is soo sooo sooo rad

[DTFUHF]

This is working for me, here is a build for Taranis, with PPM_UNIT=US HAPTIC=YES

(link removed)

Note, the output is on pin 5 (lowest pin)

[Machtap]

Getting firmware incompatible with the Taranis+ download, can anyone smarter than me test it to confirm and/or compile a taranis+ binary with this change?

[DTFUHF]

Yeah sorry about that, I'm not sure how to compile for taranis+.

[bsongis]

make PCB=TARANIS PCBREV=REVPLUS

[DTFUHF]

Hmm, that's what I've done, and that's the second person reporting it isn't working. Sorry but I don't have a Taranis+ to check.

(link removed)

Looks like the .bin is not overwritten, it must be deleted first.

[kilrah]

That's again a non-plus firmware.

[DTFUHF]

OK, one last time, at the link above, did make clean before building again.

[kilrah]

Still the same it seems, but as you're always using the same filename I'm not sure I got the latest version.
Note that the make arguments must be as shown i.e. in caps and without spaces before/after the "=".

[mikeller]

@MikeBland , @schwabe : Sorry that wasn't as clear as I wanted it to be, as it was from mobile.

Currently, my PR (openLRSng/openLRSng#117) expects the protocol in MULTI to be set to FrSkyD (https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Multiprotocol/Multiprotocol.h#L535). With this setting, the type of telemetry is used by er9x (as far as I can tell 'HUB format'), works with the 'FrSky' format that is implemented in openLRSng.

In this respect, the telemetry format that is used when the new 'OpenLRS' protocol (https://github.com/pascallanger/DIY-Multiprotocol-TX-Module/blob/master/Multiprotocol/Multiprotocol.h#L559) is configured should be the same that is used for 'FrSkyD'. (For OpenTx, if the telemetry format is not automatically determined by the protocol that is selected, then this discussion is not relevant.)

Can you please let me know when test versions implementing the 'OpenLRS' protocol become available?

[MikeBland]

If you are using ersky9x, then the output option is already selectable by number.

[mikeller]

That's a valid point. Well this allow me to select FrSky Hub telemetry at 100000 8E2?

[pascallanger]

Yes telemetry, when in serial mode, is using the same setting 100000 8E2.

[mikeller]

Good point, will try when I'm at home.

[MikeBland]

On ersky9x, as long as you have "Usr Proto" set to FRSKY in the telemetry menu, then you should find selecting MULTI with OpenLrs as sub-protocol will give you FrSky hub telemetry at 100000 8E2.

[mikeller]

Thanks, have switched the protocol Id on the Tx module, all works fine.

Btw, @MikeBland, in er9x the protocol number displayed for yet to be defined protocols seems to be off by one: 'OPENLRS' that is keyed on 0x1b is displayed as protocol number 26.

[mikeller]

For those still following this, I've finally gotten around to implementing configuration support:

openLRSng/openLRSng#122

In addition to serial RC data and telemetry, this supports the following functions on the RC controller:

• profile selection (via 'RxNum', 0 keeps the configured profile);
• high / low power;
• adjustable low power level (via 'Option', level 0 - 7, -1 keeps the configured level);
• binding
• range check.

Currently it's only tested with orangeRx 1W TX, 9XR Pro, and ersky9x.
As always, feedback is appreciated.

[schwabe]

I cannot test that since I don't have the hardware. But I can change the paramter description in OpenTX.

Change RxNum to Profile, change Option value to Power Level and limit range to -1 to 7.
What is the range of allowed RxNum for openLRSng? 0-4?

And high/lower power and power level seem to be redundant or am I missing something? Or should I just hide the low power checkbox for orls?

[mikeller]

@schwabe: Yes please, getting appropriate menu labels would be appreciated.

openLRSng supports profiles 1 - 4, RxNum 0 just goes with the profile that has been preselected in the openLRSng module config, so maybe show a - instead of 0?

I would leave high / low power in there for 2 reasons:

• the high / low power bit is part of the MULTI spec, so not supporting it on the TX doesn't make sense;
• openLRSng already allows the user to use a switch on the TX to select low / high power. The 'high' checkbox in the menu is logically OR'd with the 'high' switch position, so selecting 'high' on either of them will set the output power to high.

[geekness]

If I want to try this on my Taranis and DTFUHF Delux Module, what do I need to do?

This is a very long thread and Im a little unsure of what's actually been done.
I think you've implemented a bidirectional link for telemetry, that's a bit faster than the normal PPM stream, plus the ability to change the OLRS settings from within the Taranis?

[geekness]

Will this feature make it into 2.2.0?

[schwabe]

the feature is already in 2.2. As for the DTFUHF side I have no idea what you have to do.

[DTFUHF]

@mikeller was nice enough to write the OpenLRS part, now that there are opentx 2.2 release candidates out it's probably time to wrap up our end of things too :)

[mikeller]

@kh4 has been reviewing the code, and I've made some changes based on his review, so this should be about good to go now. No idea what the timeline for the next release of openLRSng is though.

@geekness: If you want to try it, you have to build from openLRSng/openLRSng#122 (or I can build for you if you aren't set up for it). You'll also have to use the configurator from openLRSng/openLRSng-configurator#30 in order to be able to select 'MULTI' in the 'Serial port speed' dropdown.

On the hardware side, you'll have to connect PPM out on the controller to serial RX on the TX module.

Please let me know how it's working for you.

[geekness]

@schwabe thanks for the heads up.
@DTFUHF good idea
@mikeller I'm not setup to build the files, but if you could do it for me, it would be much appreciated.

On the hardware side, you'll have to connect PPM out on the controller to serial RX on the TX module.

I have the deluxe JR module which plugs into the module bay of the taranis. Do I need to change how the pins align?

Can somebody give me a brief explanation of the benefits of using this new updated method? I vaguely understand, but I'd like to know exactly what it is that I am changing so I can make full use out of it.

[mikeller]

@geekness: Here you go:

TX-4.zip
Looking at

, you might be lucky and just have to change the jumper towards the top right of the picture from 'PPM' to 'serial'. If that doesn't work, one way to do is to connect the PPM input to the serial RX on the inside of the module.

[DTFUHF]

Hey OpenTX guys, this Multi-mode is forced to FrSkyD telemetry. Is there anyway to get SmartPort telemetry as well? Or better yet a way to select between the two modes?

Otherwise - this is working great and I can't wait for the 2.2 release.

[DTFUHF]

Also - the Multi output appears to be 0-2048 without extended limits enabeld, where the spec suggests 204-1843 should be +-100% is this a bug?

[schwabe]

Thanks for noticing the output of the multi. That looks wrong. I will have to look into that.

For the telemetry protocol. That is current tied to the protocol you select. E.g. DSM gives you spektrum telmetry; Frsky D16 gives you sport; Flysky FS2A gives you Flysky telmetry and the rest gives you FrskyD telmetry.

I am currently implemeting a multi telemetry protocol that allows the module to indicate the type of telemetry instead of hardcoding it and also allowing extra messages. WIP in is here, but it is not tested at all yet and the protocol is also not final:
https://github.com/opentx/opentx/blob/schwabe/multi_telemetry/radio/src/telemetry/multi.h

That might also interesting if you want to send to send extra status of your module or something similar.

[schwabe]

I have decided to close this issue. I think for now the multi/OLRS protocol is good enough to fulfill this issue and further improvements or bugs are better solved in new issues.

The 120 vs 100% bug is fixed when the #4151 pull request is merged.

[yanivasy]

The Model Setup (within Taranis x9d plus) according to the OpenTx 2.2. manual ( https://opentx.gitbooks.io/manual-for-opentx-2-2/content/model_setup.html ) includes an option to output an SBUS by the external RF module bay.
After flashing to OpenPx 2.2.0 (including the multimodule build option), I can't find such option.

1. Is such option available in OpenTx 2.2 ?
2. If not, Is it available in any other version/build option?
3. if not, can such an option be compiled as was done in the past by "bsongis" ?

Thanks in advance,
Yaniv.

[kilrah]

It will come in 2.2.1.

[schwabe]

Not yet, see the open pill requests