Signal polarity different to 2.8.1 for LemonDSP, DSM2 and PPM external modules

[mha1]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

The "polarity" of signals sent to external modules LemonDSP, DSM2 and PPM are reversed compared to 2.8.1.

Example DSM2 outgoing signal recorded at CCPM pin of the module bay with 2.8.1 firmware is idle high

with 2.9.1. the signal is idle low

The same is true for external modules LemonDSP and PPM. At least external DSM2 and LemonDSP modules shouldn't work in 2.9 as of now. I'd ask LemonDSP and DSM2 owners to confirm.

Expected Behavior

Same signal polarity as in 2.8.1

Steps To Reproduce

• Hook up logic analyzer or scope to GND and CCPM pins of the module bay
• select external modules LemonDSP, DSM2 and PPM
• compare idle levels between 2.8.1 and 2.9 current nightly

Version

Nightly (Please give date/commit below)

Transmitter

Radiomaster TX16S / TX16SMK2

Anything else?

Firmware versions used:

• 2.8.1 release tx16s-d9d4a8a.bin
• 2.9 nightly tx16s-5465984.bin

[pfeerick]

In case you check before I do, for PPM, does changing - to + still work (but basically be reversed to 2.8?)

[mha1]

Yes, I checked this. +/- works but everything is reversed in 2.9. Same for SBUS normal/inverted.

[pfeerick]

Ok, so a walk down all the external modes, 2.9 yesterdays nightly vs 2.8.1, indicates:

Inverted:

• PPM neg
• PPM pos
• DSM2
• LemonRX DSMP

Unchanged:

• XJT
• MULTI
• CRSF
• R9M
• SBUS normal
• SBUS not inverted
• GHST

Broken?

• Flysky

Saleae Logic 8 captures:
3413-2.8.1.zip
3413-2.9.zip

[mha1]

Correct, confirms my measurements.

Please do me a favor while you have the LA hooked up:

• 2.9
• choose external modul SBUS
• confirm it's idle low. If not change polarity in SBUS external module settings (normal/inverted)
• record 5s of data
• zoom out and check pattern
• any unexpected garbage between SBUS frames?
• repeat a few times

[pfeerick]

Sorry, no. Even when doing a 60 second capture and monitoring analog it still seemed clear. Using same 2.9 nightly as before.
SBUS-60sec.zip (digital only)

[mha1]

That's alright, just means less work.

[mha1]

Not sure about external Flysky. It is initialized with .direction = ETX_Dir_TX_RX which looking at crossfire initialization seems to indicate half duplex (on SPort pin). So external Flysky should be ok with no signal on CCPM.

[mha1]

Leaves PPM and DSM2 as LemonDSMP TX is also initialized as DSM2 (with different frame rate)

[pfeerick]

Except... this is FLYSKY on 2.8.1

vs 2.9 (and yes, a much wider time period to further highlight the point)

So either 2.8.1 was wrong, or 2.9 is wrong ;)

[mha1]

My bad, you are right. 2.8.1 outputs serial data on CPPM for external Flysky, 2.9 doesn't as it seems to initialize the module port for half duplex on SPort. No clue what should be selected. Were there any complaints about external Flysky in 2.8.1? Isn't there a Flysky guy hanging out here? He's probably best to ask.

[pfeerick]

No issues that I know of... that is why I'm hoping it's expected change... Looking at you @richardclli 🤭

[mha1]

Do external AFHDS3 modules even exist? I only found 2a modules.

Edit: Found it: https://www.flysky-cn.com/frm302-canshu-1

says PPM/UART mode

[gagarinlg]

Do external AFHDS3 modules even exist? I only found 2a modules.

Patience

[pfeerick]

There's the FRM301, FRM302 and FRM303...

The FRM301 is the module used in the PL18 series transmitters
The FRM302 is the JR micro bay module like you found
I don't know much about the 303, other than IIRC it replaces the 302 and is very similar (protocol wise at least) to the IRM301 used internally in the EL18. Richard has been working on that. #2863

[richardclli]

No issues that I know of... that is why I'm hoping it's expected change... Looking at you @richardclli 🤭

Some information for references:

1. FRM302 is not supported since 2.8.0, as Raphael implemented the new protocol for the internal module IRM301 in EL18, the old protocol is removed completely. And that is why FRM302 will not work since 2.8.0
2. Flysky has already discontinued FRM302, and they think it is alright to stop supporting FRM302
3. FRM 303 will be announced soon, and FRM303 is already supported in EL18 since 2.8.1 and it did not use the S.Port for half duplex but use the PPM/Heartbeat pair for full duplex instead.
4. Because of the hardware bug and forced signal inversion of other EdgeTX radios, the current implementation will not work for other radio, and we need to wait for Flysky to amend another mode that use S.Port instead.

[pfeerick]

Thanks for that :) Are you able to double-check that the FRM303 is still working with a recent nightly?

[richardclli]

Let me check during weekend. It works in main sometimes ago, but well who knows.

[richardclli]

Let me check during weekend. It works in main sometimes ago, but well who knows.

Confirmed FRM303 still works in 2.9 with EL18. Check with version 1f82724.
So the signal is 2.8.1 is somewhat different with 2.9? They should be the same if it still works.

[pfeerick]

I was using the TX16S for the captures in #3413 (comment), so there could be something different happening there. But as long as it works on the EL18, all good, as it won't work with the TX16S in that mode atm anyway 🤭

[richardclli]

I see, TX16S use different mappings for Flysky now, and it is not working anyway. And why 2.8 has something, because I hhave tried to make it works in Tx16S, but not tried to do the same thing in 2.9, yet. The Serial API changes in 2.9 need different implementation.

[pfeerick]

Ah, that explains it... Thanks Richard :) As long as we know the reason, and it's not a 🐛, the show can go on! 😄

[richardclli]

Now the FRM303 works in TX16S with a simple mod similar to Access mod.
https://github.com/EdgeTX/edgetx/wiki/Flysky-FRM303-Mod-for-TX16S

[pfeerick]

I'm not sure atm if #3442 is connected to this issue, so re-opening for now.

[gagarinlg]

@mha1 could you please test
#3513

[mha1]

@gagarinlg Sure, but please be aware that this PR can't be verified with just a test on a single radio. The changes made are heavily influenced by the hardware design of the radios (UARTs, inverters, software controllable inverters, GPIO assignment, etc). So I can only contribute a Horus target (TX16s) but to come to a final verdict on this change you'd at least have to get results from NV14 (sw controllable inverters), and some Taranis type radios, e.g. X9D. See also discussion here #3415 (comment)

Test results on TX16s with firmware obtained from merge checks of this PR (https://github.com/EdgeTX/edgetx/actions/runs/4777343713?pr=3513):

DSM2 init (going from OFF to DSM2): ok

DSM2 (for all subtypes LP45, DSM2, DSMX): polarity idle high as in 2.8 -> ok

LemonRx DSMP init (going from OFF to LemonRx DSMP): ok

LemonRx DSMP: polarity idle high as in 2.8 -> ok

PPM (-) going from OFF to PPM -> not ok. This doesn't seem to hurt PPM modules as this only affects the first two or three frames. Yet, it doesn't look right.

PPM (-): polarity idle high as in 2.8 -> ok

PPM (+): polarity idle low as in 2.8 -> ok

[raphaelcoeffic]

PPM (-) going from OFF to PPM -> not ok

I can re-check that one. And give it a try of side-by-side tests with X9D+.

[mha1]

Thanks, and before merging we need at least feedback on NV14.