New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added full support for MULTIPROTOCOL (incl configuration via controller). #122

Merged
merged 7 commits into from Jun 7, 2017

Conversation

Projects
None yet
7 participants
@mikeller
Member

mikeller commented Nov 6, 2016

Added support for serial MULTI protocol (serialMode == 5).

Make it build under Arduino 1.6.11.

Switched protocol number to 0x1b for 'OPENLRS'.

Changed Tx channel value calculation to use 'servoUs2Bits'. Thanks to @csurf for pointing this out.

Added multiprotocol configuration support.

Added profile selection.

Added profile switching.

Finished profile switching, added Range Check.

mikeller added some commits Aug 30, 2016

Added support for serial MULTI protocol (serialMode == 5).
Make it build under Arduino 1.6.11.

Switched protocol number to 0x1b for 'OPENLRS'.

Changed Tx channel value calculation to use 'servoUs2Bits'. Thanks to @csurf for pointing this out.

Added multiprotocol configuration support.

Added profile selection.

Added profile switching.

Finished profile switching, added Range Check.
@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 12, 2016

Member

I've tried this out on HWTYPE=5, and have a couple comments, without looking thru much code. Tested against OpenTX 2.2 RC8.

-PPM doesn't seem to work anymore.
-Channel end-points are reduced and 'wrap around' as the end points are reached. Is this a limitation of protocol or a scaling issue? If it's a protocol limitation the ends should at least be 'capped' instead of going to the opposite end. (SUMD output mode on RX)
-SmartPort telemetry also doesn't seem to work, in MULTI mode. It's receiving packets, as I get the 'rssi buzz', This was working fine for me in 3.8.8 in SmartPort mode on the taranis. Could this be a hardware limitation, as both the MULTI input and SmartPort output are forced to the same baudrate? Or, is there another telemetry mode that is supported with MULTI?
-When the High power mode is set in OpenTX, the red LED is turned on. This LED is usually used to indicate 'bad things' like a nonworking TX module or lost packets. I think this should be changed to be on in 'low power' mode.
-Bind function, low power / range test mode, and normal uplink packets are working fine!

This is a great functionality addition and looking forward to merging this soon along with the configurator changes.

Member

DTFUHF commented Dec 12, 2016

I've tried this out on HWTYPE=5, and have a couple comments, without looking thru much code. Tested against OpenTX 2.2 RC8.

-PPM doesn't seem to work anymore.
-Channel end-points are reduced and 'wrap around' as the end points are reached. Is this a limitation of protocol or a scaling issue? If it's a protocol limitation the ends should at least be 'capped' instead of going to the opposite end. (SUMD output mode on RX)
-SmartPort telemetry also doesn't seem to work, in MULTI mode. It's receiving packets, as I get the 'rssi buzz', This was working fine for me in 3.8.8 in SmartPort mode on the taranis. Could this be a hardware limitation, as both the MULTI input and SmartPort output are forced to the same baudrate? Or, is there another telemetry mode that is supported with MULTI?
-When the High power mode is set in OpenTX, the red LED is turned on. This LED is usually used to indicate 'bad things' like a nonworking TX module or lost packets. I think this should be changed to be on in 'low power' mode.
-Bind function, low power / range test mode, and normal uplink packets are working fine!

This is a great functionality addition and looking forward to merging this soon along with the configurator changes.

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 12, 2016

Member

Hi @DTFUHF, thanks heaps for testing.

-PPM doesn't seem to work anymore.

Could this be a case of the controller's PPM out now being wired to the serial RX on the TX module? It works for me with PPM in and serial RX being connected to PPM out, if i splice an R100 into the serial RX connection.

-Channel end-points are reduced and 'wrap around' as the end points are reached. Is this a limitation of protocol or a scaling issue? If it's a protocol limitation the ends should at least be 'capped' instead of going to the opposite end. (SUMD output mode on RX)

That's weird, MULTI -> SUMD works fine for me with current scaling. Might be a case of different controllers using different limits, but even then it shouldn't wrap around. My code is tested against ersky9x.

Can you test if the RX output works ok with PPM (that's what I did during development to get a 'known good' reference)? Also, n.b. SBUS signal scaling is broken, this is fixed in #123.

-SmartPort telemetry also doesn't seem to work, in MULTI mode. It's receiving packets, as I get the 'rssi buzz', This was working fine for me in 3.8.8 in SmartPort mode on the taranis. Could this be a hardware limitation, as both the MULTI input and SmartPort output are forced to the same baudrate? Or, is there another telemetry mode that is supported with MULTI?

Yes that definitely is the case. ersky9x automatically sets the telemetry serial parameters to be identical to the MULTI settings if multi is used. Don't know if OpenTx does the same.

-When the High power mode is set in OpenTX, the red LED is turned on. This LED is usually used to indicate 'bad things' like a nonworking TX module or lost packets. I think this should be changed to be on in 'low power' mode.

This is nothing new. When output power is controlled by a hardware switch, then the red LED is turned on when it's switched to high. All I did was copy the functionality from there. It can be removed if it's not desired, but should probably be removed from the switch based functionality then as well, to be consistent.

-Bind function, low power / range test mode, and normal uplink packets are working fine!

Good to hear.

Member

mikeller commented Dec 12, 2016

Hi @DTFUHF, thanks heaps for testing.

-PPM doesn't seem to work anymore.

Could this be a case of the controller's PPM out now being wired to the serial RX on the TX module? It works for me with PPM in and serial RX being connected to PPM out, if i splice an R100 into the serial RX connection.

-Channel end-points are reduced and 'wrap around' as the end points are reached. Is this a limitation of protocol or a scaling issue? If it's a protocol limitation the ends should at least be 'capped' instead of going to the opposite end. (SUMD output mode on RX)

That's weird, MULTI -> SUMD works fine for me with current scaling. Might be a case of different controllers using different limits, but even then it shouldn't wrap around. My code is tested against ersky9x.

Can you test if the RX output works ok with PPM (that's what I did during development to get a 'known good' reference)? Also, n.b. SBUS signal scaling is broken, this is fixed in #123.

-SmartPort telemetry also doesn't seem to work, in MULTI mode. It's receiving packets, as I get the 'rssi buzz', This was working fine for me in 3.8.8 in SmartPort mode on the taranis. Could this be a hardware limitation, as both the MULTI input and SmartPort output are forced to the same baudrate? Or, is there another telemetry mode that is supported with MULTI?

Yes that definitely is the case. ersky9x automatically sets the telemetry serial parameters to be identical to the MULTI settings if multi is used. Don't know if OpenTx does the same.

-When the High power mode is set in OpenTX, the red LED is turned on. This LED is usually used to indicate 'bad things' like a nonworking TX module or lost packets. I think this should be changed to be on in 'low power' mode.

This is nothing new. When output power is controlled by a hardware switch, then the red LED is turned on when it's switched to high. All I did was copy the functionality from there. It can be removed if it's not desired, but should probably be removed from the switch based functionality then as well, to be consistent.

-Bind function, low power / range test mode, and normal uplink packets are working fine!

Good to hear.

Show outdated Hide outdated TX.h Outdated
Show outdated Hide outdated TX.h Outdated
@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 12, 2016

Member

I think I found the problem with PPM, please see the comments in TX.h.

Will check into scaling SUMD vs. PPM.

Also will contact OpenTX re: matching serialRX and telemetry baud rates. I did confirm that smartport still works when in PPM mode.

Good point on the LED and switch - I still don't like it, and agree both should change.

Member

DTFUHF commented Dec 12, 2016

I think I found the problem with PPM, please see the comments in TX.h.

Will check into scaling SUMD vs. PPM.

Also will contact OpenTX re: matching serialRX and telemetry baud rates. I did confirm that smartport still works when in PPM mode.

Good point on the LED and switch - I still don't like it, and agree both should change.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF
Member

DTFUHF commented Dec 12, 2016

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Ok, fixed the PPM / PPM init delay problems.

Re smartport: I cannot help much with that, that's never worked for me, even with PPM. I am using FrSky, and that works fine.

Member

mikeller commented Dec 13, 2016

Ok, fixed the PPM / PPM init delay problems.

Re smartport: I cannot help much with that, that's never worked for me, even with PPM. I am using FrSky, and that works fine.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

Confirmed it works in FrSky(D) telem mode... and I scoped the output when in sport mode and it looks fine, so this is likely an opentx issue.

Member

DTFUHF commented Dec 13, 2016

Confirmed it works in FrSky(D) telem mode... and I scoped the output when in sport mode and it looks fine, so this is likely an opentx issue.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

Indeed OpenTX forces this MULTI-type to Frsky D mode.

Member

DTFUHF commented Dec 13, 2016

Indeed OpenTX forces this MULTI-type to Frsky D mode.

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Ha. So it's only the SUMD / scaling issue that's left?

Member

mikeller commented Dec 13, 2016

Ha. So it's only the SUMD / scaling issue that's left?

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

Looks like it, yeah :)

Same issue is happening with PPM, I'll look a little further.

Member

DTFUHF commented Dec 13, 2016

Looks like it, yeah :)

Same issue is happening with PPM, I'll look a little further.

Show outdated Hide outdated TX.h Outdated
@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Ha good point. And from the look of it, openLRSng doesn't do constraining on the input.

I still think we should be doing a conversion that preserves the important points 1000, 2000, so we rather do clipping at the ends. Your thoughts?

Member

mikeller commented Dec 13, 2016

Ha good point. And from the look of it, openLRSng doesn't do constraining on the input.

I still think we should be doing a conversion that preserves the important points 1000, 2000, so we rather do clipping at the ends. Your thoughts?

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

OpenTX full-swing is 0-2047 on the multi protocol without 'extended limits' selected, which seems to ignore the suggested range - so yes, I agree, those should be mapped to 1000-2000. So the new equation will be

value = ((value * 1000) / 2048) + 1000

basically what you had before... without the subtraction

Member

DTFUHF commented Dec 13, 2016

OpenTX full-swing is 0-2047 on the multi protocol without 'extended limits' selected, which seems to ignore the suggested range - so yes, I agree, those should be mapped to 1000-2000. So the new equation will be

value = ((value * 1000) / 2048) + 1000

basically what you had before... without the subtraction

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Looks like OpenTx has a bug there. ersky9x properly implements Multiprotocol, with full swing being 204 to 1843. I think since this is the official spec this is what we should be going for.

Member

mikeller commented Dec 13, 2016

Looks like OpenTx has a bug there. ersky9x properly implements Multiprotocol, with full swing being 204 to 1843. I think since this is the official spec this is what we should be going for.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

Hopefully they do fix it, in this case the equation is
value = ((value * 1000) / 1639) + 875

Multi OpenLRS
0 875
204 1000
1024 1500
1843 2000
2047 2124
Member

DTFUHF commented Dec 13, 2016

Hopefully they do fix it, in this case the equation is
value = ((value * 1000) / 1639) + 875

Multi OpenLRS
0 875
204 1000
1024 1500
1843 2000
2047 2124
@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

value = ((value * 1000) / 1639) + 875 should evaluate to the same as value = (((value - 204) * 1000) / 1639) + 1000 (for integers), and I left it in that form to make it more obvious where it was derived from. But if the performance overhead is a problem I can change it.

Member

mikeller commented Dec 13, 2016

value = ((value * 1000) / 1639) + 875 should evaluate to the same as value = (((value - 204) * 1000) / 1639) + 1000 (for integers), and I left it in that form to make it more obvious where it was derived from. But if the performance overhead is a problem I can change it.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 13, 2016

Member

Well, the problem is when value is less than 204, a perfectly valid case

Member

DTFUHF commented Dec 13, 2016

Well, the problem is when value is less than 204, a perfectly valid case

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Fair comment, should be int32_t. For some weird reason my build on my TX seems to be converting input < 204 into output < 1000 correctly, even though this should result in an integer underflow.

Member

mikeller commented Dec 13, 2016

Fair comment, should be int32_t. For some weird reason my build on my TX seems to be converting input < 204 into output < 1000 correctly, even though this should result in an integer underflow.

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Dec 13, 2016

Member

Try now.

Member

mikeller commented Dec 13, 2016

Try now.

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF Dec 21, 2016

Member

Sorry for the delay. This is working great now.

Member

DTFUHF commented Dec 21, 2016

Sorry for the delay. This is working great now.

@geekness

This comment has been minimized.

Show comment
Hide comment
@geekness

geekness Jan 6, 2017

Is this closed now, and is the updated firmware available on the chrome configurator for the deluxe JR module?
Will this enable me to get telemetry from my Sparky2.0 FC (Dronin) into my Taranis without any extra hardware?

geekness commented Jan 6, 2017

Is this closed now, and is the updated firmware available on the chrome configurator for the deluxe JR module?
Will this enable me to get telemetry from my Sparky2.0 FC (Dronin) into my Taranis without any extra hardware?

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Jan 6, 2017

Member

No, unfortunately this is still waiting to be merged.

Member

mikeller commented Jan 6, 2017

No, unfortunately this is still waiting to be merged.

@geekness

This comment has been minimized.

Show comment
Hide comment
@geekness

geekness Jan 6, 2017

Without wanting to be pushy or rude, is there a time frame where this will happen?

geekness commented Jan 6, 2017

Without wanting to be pushy or rude, is there a time frame where this will happen?

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Jan 6, 2017

Member

No, you're right, I am wondering the same.

Member

mikeller commented Jan 6, 2017

No, you're right, I am wondering the same.

@geekness

This comment has been minimized.

Show comment
Hide comment
@geekness

geekness Jan 6, 2017

Will this change enable me to connect a generated sbus signal to the 1W Rx, to be used as a Tx, and then transit that to the aircraft?
https://github.com/bolderflight/SBUS/blob/master/README.md
https://forum.pjrc.com/threads/41281-Help-integrating-SBUS-library-for-teensy?p=129475&posted=1#post129475

geekness commented Jan 6, 2017

Will this change enable me to connect a generated sbus signal to the 1W Rx, to be used as a Tx, and then transit that to the aircraft?
https://github.com/bolderflight/SBUS/blob/master/README.md
https://forum.pjrc.com/threads/41281-Help-integrating-SBUS-library-for-teensy?p=129475&posted=1#post129475

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Jan 7, 2017

Member

Not really. MULTIPROTOCOL is a different protocol to SBUS. But there is support for SBUS input into the openLRSng TX in the existing code.

Member

mikeller commented Jan 7, 2017

Not really. MULTIPROTOCOL is a different protocol to SBUS. But there is support for SBUS input into the openLRSng TX in the existing code.

@JFingerle

This comment has been minimized.

Show comment
Hide comment
@JFingerle

JFingerle Feb 22, 2017

I would really like this feature to be merged. Is there any way I can support you? I could e.g. test it.

JFingerle commented Feb 22, 2017

I would really like this feature to be merged. Is there any way I can support you? I could e.g. test it.

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Feb 23, 2017

Member

Hi @JFingerle. Thanks for your offer. @DTFUHF, who is a maintainer of openLRSng, has already tested it, and I have applied the fixes and improvements that he recommended. I don't know why this hasn't been merged yet.

But additional testing with different hardware configurations, and feedback and recommendations for improvements is certainly welcome. Let me know if you need assistance with building the firmware (and what TX you need it for).

Member

mikeller commented Feb 23, 2017

Hi @JFingerle. Thanks for your offer. @DTFUHF, who is a maintainer of openLRSng, has already tested it, and I have applied the fixes and improvements that he recommended. I don't know why this hasn't been merged yet.

But additional testing with different hardware configurations, and feedback and recommendations for improvements is certainly welcome. Let me know if you need assistance with building the firmware (and what TX you need it for).

@zipray

This comment has been minimized.

Show comment
Hide comment
@zipray

zipray May 11, 2017

hi mikeller,This firmware need a hardware modification?

zipray commented May 11, 2017

hi mikeller,This firmware need a hardware modification?

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller May 11, 2017

Member

Yes. The PPM out of the controller needs to be connected to the RX pin of the module. Depending on the type of module, this can be done internally, or with a custom cable between controller or module.

Member

mikeller commented May 11, 2017

Yes. The PPM out of the controller needs to be connected to the RX pin of the module. Depending on the type of module, this can be done internally, or with a custom cable between controller or module.

@omegapraim

This comment has been minimized.

Show comment
Hide comment
@omegapraim

omegapraim May 14, 2017

Hi guys. Thanks for your work. Already almost 6 months I fly on multiprotocol + taranis. The receiver works on the SBUS excellently.
Bugs did not follow. But there is one question. How to make it so that when working at the receiver and the transmitter, the green LED glowed brightly. During normal operation and when the beacon operates, the diode shines very dimly, where in the code it can be fixed?

omegapraim commented May 14, 2017

Hi guys. Thanks for your work. Already almost 6 months I fly on multiprotocol + taranis. The receiver works on the SBUS excellently.
Bugs did not follow. But there is one question. How to make it so that when working at the receiver and the transmitter, the green LED glowed brightly. During normal operation and when the beacon operates, the diode shines very dimly, where in the code it can be fixed?

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller May 15, 2017

Member

Thanks for testing, @omegapraim. I really wish one of the maintainers finally merged this, all the reports so far have been overwhelmingly positive. @DTFUHF, @kh4?

I always assumed that the fluttering LED was thought as some sort of 'all is ok' canary, and never given much thought to it. It is switched here:
https://github.com/openLRSng/openLRSng/blob/master/TX.h#L861
https://github.com/openLRSng/openLRSng/blob/master/TX.h#L930

Member

mikeller commented May 15, 2017

Thanks for testing, @omegapraim. I really wish one of the maintainers finally merged this, all the reports so far have been overwhelmingly positive. @DTFUHF, @kh4?

I always assumed that the fluttering LED was thought as some sort of 'all is ok' canary, and never given much thought to it. It is switched here:
https://github.com/openLRSng/openLRSng/blob/master/TX.h#L861
https://github.com/openLRSng/openLRSng/blob/master/TX.h#L930

@DTFUHF

This comment has been minimized.

Show comment
Hide comment
@DTFUHF

DTFUHF May 30, 2017

Member

OpenTX 2.2 has been released, so this can go ahead....

Member

DTFUHF commented May 30, 2017

OpenTX 2.2 has been released, so this can go ahead....

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller May 30, 2017

Member

I wasn't aware that this is in any way shape or form dependent on OpenTx being released. Support for this has been in a released version of er9x for about 6 months now...

Member

mikeller commented May 30, 2017

I wasn't aware that this is in any way shape or form dependent on OpenTx being released. Support for this has been in a released version of er9x for about 6 months now...

@DTFUHF DTFUHF merged commit 8d0d077 into openLRSng:master Jun 7, 2017

@mikeller mikeller deleted the mikeller:add_multiprotocol_configuration_support branch Jun 7, 2017

@omegapraim

This comment has been minimized.

Show comment
Hide comment
@omegapraim

omegapraim Jun 11, 2017

Hello to all again. Found a very annoying problem. Of a scheme to avoid powered by USB. If you use Multiprotocol, when connecting the USB cable to the LRS off Taranis begins to show signs of life, but in the end it all leads to the fact that the switch chip (a small 6 foot) goes down, and stops LRS to determine the presence of Multiprotocol via UART. Solved only by the replacement of the chip. Before I had the simple version of the PPM with no issues. Good luck to everyone

omegapraim commented Jun 11, 2017

Hello to all again. Found a very annoying problem. Of a scheme to avoid powered by USB. If you use Multiprotocol, when connecting the USB cable to the LRS off Taranis begins to show signs of life, but in the end it all leads to the fact that the switch chip (a small 6 foot) goes down, and stops LRS to determine the presence of Multiprotocol via UART. Solved only by the replacement of the chip. Before I had the simple version of the PPM with no issues. Good luck to everyone

@mikeller

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Jun 11, 2017

Member

@omegapraim: Yes, there are a couple of caveats there:

  • if you are using Multiprotocol, you have to disconnect the TX from the controller before connecting it to the FTDI adapter, since the same serial port is used for Multiprotocol and USB firmware update / configuration;
  • as always, make sure that your FTDI adapter is set to 3.3V and not 5V, or else you risk frying the serial port.
Member

mikeller commented Jun 11, 2017

@omegapraim: Yes, there are a couple of caveats there:

  • if you are using Multiprotocol, you have to disconnect the TX from the controller before connecting it to the FTDI adapter, since the same serial port is used for Multiprotocol and USB firmware update / configuration;
  • as always, make sure that your FTDI adapter is set to 3.3V and not 5V, or else you risk frying the serial port.
@omegapraim

This comment has been minimized.

Show comment
Hide comment
@omegapraim

omegapraim Jun 11, 2017

I understood you thanks for the tip.

omegapraim commented Jun 11, 2017

I understood you thanks for the tip.

@danielsmd

This comment has been minimized.

Show comment
Hide comment
@danielsmd

danielsmd Jun 29, 2018

Hello
I don't know how to use Github, but I have a clarification.
Is this (fix/request) implemented in the master branch?

danielsmd commented on 04b7b33 Jun 29, 2018

Hello
I don't know how to use Github, but I have a clarification.
Is this (fix/request) implemented in the master branch?

This comment has been minimized.

Show comment
Hide comment
@mikeller

mikeller Jun 29, 2018

Owner

No, not yet.

Owner

mikeller replied Jun 29, 2018

No, not yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment