External R9M ACCESS module does not transmit channel information in f.port mode (telemetry works)

[Zaquron]

Describe the bug
Coming from OTX 2.3.14, i installed EdgeTX 2.6 with externalaccessmod and RC output disappeared from the receiver.
When the receiver is connected, the channel data sometimes refreshes once and stays there until turned off. Moving the sticks does not change the channel outputs.
Telemetry always works fine.

To Reproduce
-install EdgeTX 2.6.0

Expected behavior
RC channels should work through f.port

Screenshots

General information

• EdgeTX version 2.6.0 with externalaccessmod
• Hardware RM TX16S with R9M 2019 module (fw 1.3.0 flex)
• R9MX receiver (fw 1.3.2 flex)

Checked 3 times now, the whole setup works fine on OpenTX.
tested with - flex mode (868MHz) with R9MX receiver
- EU (LBT) mode with the same receiver
I guess there is something wrong with the externalaccessmod.

*edited for clarity

[brainbubblersbest]

F.port is only a thing that happens between hf module and receiver. Hf module communication with Radio is the same as with sbus s.port configuration.
Are you shure that there is nothing wrong between receiver and flightcontroller?
Which FC Do you use and how have you connect the receiver with it.

[Zaquron]

F.port is only a thing that happens between hf module and receiver. Hf module communication with Radio is the same as with sbus s.port configuration. Are you shure that there is nothing wrong between receiver and flightcontroller? Which FC Do you use and how have you connect the receiver with it.

The FC is a Mateksys F411 wing. It's connected to the R9MX receiver through a serial TX pin.
I went back to OTX and everything works. There was no change in hardware or receiver side firmware in any way, that's why i think this is an EdgeTX bug.

[brainbubblersbest]

I just like to request that you double checked This. 😉
Can you Check your Externalaccessmod wiring?
This is also a clear indication for Malfunctioning Inverter.
(can be possible)
TX to Module Bay Pin 1.
Pin 2 is for Telemetry.

You dont have a Scopemeter layin around somewhere? Or an old Accst Module and Receiver? 😅

[Zaquron]

I'll recheck wiring tomorrow, but pretty sure it wouldn't work on OTX if it was a hardware issue.
I happen to have an oscilloscope, but no serial analizer.
What should i check?
I could flash the module with ACCST but i don't have a compatible receiver so i can't test that.

[brainbubblersbest]

You need no Serial analyzer.
Oscilloscope is enough. Check rx tx Pins in the Bay.
(With r9m connected and running.)
Signal should Look clean and sharp.
Maybe there isnt even a Signal on tx. (pin1)

Every measurement thats done is good for bugtracking 😉

[Zaquron]

I did a few measurements.
If by pin1 you mean the top pin, then there is a signal on that one. (running OTX or EdgeTX)
It does not look clean and sharp, but looks just like the signal i measured under OTX

.

[scooper1]

That looks horrible. The levels are not consistant. Try a higher sample if available on scope

[Zaquron]

pin5 (the bottom one right under GND) looks like this:

[Zaquron]

well, it's a very basic and cheap scope...
Why does it work on OpenTX though?

[brainbubblersbest]

The s.port Signal Looks good. The Signal on pin1 does not.
Idk why it works with opentx. Maybe @rotorman can say something about that. (different processing or else)
I wouldnt Trust that it will work reliable with opentx for long time.
You can change module type to ppm to Check if you can Pick up a good Signal here.
And you can compare the Signal on pin2 with pin 1 to figure out if it's a speed limit issue of your scope

Another idea would be to solder in an external inverter like on x10/x12. These are tested on 400k Baudrates.

[rotorman]

@Zaquron can you show some pics of your hw-mod you did? The waveform in #1585 (comment) looks pretty distorted to me.

[Zaquron]

Connections look ok to me, but there is definitely a hardware issue here.
When i connect the probe to pin1, the module loses telemetry even on OpenTX.
Now i have no idea how to fix this. :(
Changing mainboard is beyond my budget.

[Zaquron]

BTW just came back from the field where i had 2 flights on OpenTX.
Not a single glitch,

[rotorman]

On the USART3 header to the left of main STM32F4, I cannot clearly see from the image if the TX and RX wires connect or not - also flux should be washed off with PCB cleaner, as it is not only corrosive, but also lightly conductive.

Nevertheless, if with the same radio OpenTX firmware works OK, then there must be a software issue somewhere. I do not have R9M myself to test though.

Can you measure the top pin (PPM/SBUS of JR-bay) once more under OpenTX and under EdgeTX to see if you can spot a difference in the waveform?

[Zaquron]

Resoldered and cleaned off flux:

Waveform on EdgeTX

Waveform on OpenTX

[rotorman]

Your solder job looks good, the waveforms look the same on OpenTX and EdgeTX, although both have very rounded corners.
Hmm... would you have a logic analyzer, like Saleae, to check if the data stream from the radio is also similar?

[Zaquron]

Sorry, i don't have a logic analyzer.

[Zaquron]

Did anyone ever measure this with an oscilloscope? Maybe it's the same mess in every transmitter.

[rotorman]

I had a look at TX16S schematics and accessmod and I think it might work better without the following two highlighted components - remove only if you are adventurous enough:

[Zaquron]

I have a damaged mainboard (battery charge control circuit went up in smoke) so i might give this a try.
Does this affect anything else?

[brainbubblersbest]

Did anyone ever measure this with an oscilloscope? Maybe it's the same mess in every transmitter.

I only measured the waveform with th external Inverters on x12s. And ive done that with a fluke/philips pm97

[rotorman]

Does this affect anything else?

Removing the two components listed affects only the external RF-module.

[Zaquron]

I did a little experiment. Changed the main PCB to the old one and did the suggested modification.
Signal still looks like this:

IMHO this is a software problem.
Can someone please take a look at the code?

[ViorelX]

I have the same problem: T18 radio with R9M, which works fine in OpenTX, but it doesn't work in EdgeTX (only telemetry is transmitted.)

[Zaquron]

Is there any chance someone with the skills will take a look at this? Please?

[brainbubblersbest]

I would Do this. But I dont have access to a RM TX16S.

[ViorelX]

The problem might be not specific to RM TX16s. I have Radioking T18.

[brainbubblersbest]

Yes. First Post was rmtx16s.
I only have a X12s with additional Inverters.
And for me everything works.

[raphaelcoeffic]

@Zaquron is that only with F.PORT output, or in general with this module? @brainbubblersbest can you please confirm: your R9M ACCESS works properly on the X12S with external access mod & edgetx?

[brainbubblersbest]

@raphaelcoeffic this seems related:
#260 (comment)

[brainbubblersbest]

aaand: can copy the exact behaviour as descripted.
F.port and sbus/s.port works. Channels in the FC. Full Telemetry in the Radio

But only under setting "fcc"
915/868/eu" wont work.

I´m using flex Firmware, so i should be able to choose what i want.

[raphaelcoeffic]

@brainbubblersbest ok, so let me summarise:

• All 4 modes allow to bind successfully,
• but the channels only work with FCC.
• 915/868/EU does not transmit channels properly.

[brainbubblersbest]

Yes checked that again.
All True.
I can try to record 915/868/eu/fcc with logic analyzer.
If that is somehow helpfull.

[pfeerick]

@brainbubblersbest I finally ordered a FrSky R9M 2019 /w R9MX receiver + a R9SX receiver so I can work on the FLEX UI stuff, so may also be able to help with this... (and/or will be asking you how to get started with it! 😁) Will probably be a couple weeks before it arrives though.

[raphaelcoeffic]

@brainbubblersbest I finally ordered a FrSky R9M 2019 /w R9MX receiver + a R9SX receiver so I can work on the FLEX UI stuff, so may also be able to help with this... (and/or will be asking you how to get started with it! 😁) Will probably be a couple weeks before it arrives though.

You’ll need external access mod as well ;-)

[Zaquron]

Any news on this? I'm itching to use EdgeTX but can't until it's fixed.

[brainbubblersbest]

@pfeerick can you take a close Look into this please?
I know from a few users go back to opentx because of the non full working r9access function in edgetx. (inav /fixed wing /frsky group.

Please Tell me if I can help you somehow.

[MomoRC-tech]

Working fine in my case with:
a) TX16s, R9M 2019 (ACCESS), R9MX, MAMBA APP F722, INAV 3.0.1.
b) as a), but with Matek stack in flying wing
edgetx 2.7.1
cmake -Wno-dev -DPCB=X10 -DPCBREV=TX16S -DDEFAULT_MODE=2 -DGVARS=YES -DPPM_UNIT=US -DHELI=NO -DLUA=YES -DHARDWARE_EXTERNAL_ACCESS_MOD:BOOL=ON -DCMAKE_BUILD_TYPE=Release ../

[Arvycka]

in Flex mode 868MHz or 915 MHz?

[MomoRC-tech]

915MHz

[federikk]

I had problem on flex 868, menu missing in tx ui, no servo movements Went back to otx at the moment, but can't wait to go ETX. i've just too many access stuff

[Zaquron]

who do i have to bribe to get this fixed? ;)

[brainbubblersbest]

#2147 #2146
Hey @Zaquron I Think @pfeerick has ordered a R9m Module.
He's also my last Hope into this. I don't tried the functionality on the r9m as it seems that nothing changed in the Code expect the new GUi translation.

@raphaelcoeffic have you implemented something from this issue while moving to the flex layout?

[Arvycka]

Pre-2019 (non-ACCESS) R9M is working fine in EdgeTX. With ACCESS only EU f.port is messed up, if I recall corectly. I also went back to OpenTX because of this.

[raphaelcoeffic]

As it seems, there was an error in the UI that could have caused what you see: normally, you should not have to choose the subtype (FCC/EU/915/868). Which frequencies / type is used is decided by the module FW (FCC vs EU vs FLEX) and in case of FLEX, which frequency you choose at binding time (pop-up menu).

So what happened is that the sub-type menu sets the subType attribute, which is then blindly sent to the module, which ignores the packets, are they are considered illegal (unknown sub-type bits).

Summary: the sub-type menu should be removed and subType must be set to 0 (which is what happens when FCC is selected in the sub-type menu).

[Zaquron]

As it seems, there was an error in the UI that could have caused what you see: normally, you should not have to choose the subtype (FCC/EU/915/868). Which frequencies / type is used is decided by the module FW (FCC vs EU vs FLEX) and in case of FLEX, which frequency you choose at binding time (pop-up menu).

So what happened is that the sub-type menu sets the subType attribute, which is then blindly sent to the module, which ignores the packets, are they are considered illegal (unknown sub-type bits).

Summary: the sub-type menu should be removed and subType must be set to 0 (which is what happens when FCC is selected in the sub-type menu).

I can't wait to test this.
Hope it is merged soon.

Thanks a lot man!

[raphaelcoeffic]

@Zaquron normally we test things before they get merged ;-)

[Zaquron]

@Zaquron normally we test things before they get merged ;-)

Those are two separate sentences. ;)

Though i'm still trying to figure out how i could compile a firmware for my transmitter with this fix included.
My knowledege is still very limited in this matter...

[rotorman]

i'm still trying to figure out how i could compile a firmware for my transmitter with this fix included.

You can just fetch the GH built firmware under: https://github.com/EdgeTX/edgetx/pull/2211/checks (click Run tests and package firmware and then see under Artifacts to download the zipped firmware file of PR 2211).

If you wish to build your own, you can use https://gitpod.io/#https://github.com/edgetx/edgetx/tree/r9m-access-fix-subtype w/o having to setup a local build environment (see for further instructions https://github.com/EdgeTX/edgetx/wiki/Building-radio-firmware-in-a-webbrowser-with-Gitpod ).

[pfeerick]

You just beat me to it Risto - and he'll need to self-build (i.e. using gitpod) since the externalaccessmod opt is needed.

i.e. for the TX16 the cmake line for that would be:
cmake -Wno-dev -DPCB=X10 -DPCBREV=TX16S -DHARDWARE_EXTERNAL_ACCESS_MOD=ON ..

[Zaquron]

Thank you!
I'll give it a try.

[raphaelcoeffic]

Test firmware for TX16S, X10 and X12S is available here: https://github.com/EdgeTX/edgetx/files/9415034/pr2211-test-firmwares.zip

[ViorelX]

Thank you very much too, but, unfortunately, I am too busy to try it soon. Maybe 1-2 weeks later.

[Zaquron]

It works fine now. :)
I'll do some flight tests on the weekend if i get to it.

One weird thing popped up though (probably unrelated to the original issue)
My RPM sensor is lost occasionally but starts refreshing again in a few seconds.
I will report the issue if i can reproduce it with a different setup.

[brainbubblersbest]

Ok. I tested this. Having no sbus or f.port. Channel output. i cant access the receiver options either to change from f.port to sbus or f.Port2

[raphaelcoeffic]

i cant access the receiver options either to change from f.port to sbus or f.Port2

i believe you have another issue, possibly related to what has just been fixed in #2504.

[brainbubblersbest]

Im home from Hospital and can Finally check that.
I dont comment anything the last Days for Sure.🤔?