Originally Posted by FlyAndRip

Which of the 5 pins is for telemetry? I will take a closer look at it!

The bottom pin.
Basically with whatever protocol loaded (no RX connected), you should see the module version and not "No MULTI_TELEMETRY detected".
Pascal

Originally Posted by hpnuts

The bottom pin.
Basically with whatever protocol loaded (no RX connected), you should see the module version and not "No MULTI_TELEMETRY detected".
Pascal

I can assure you that nothing is wrong with the pins.

I tried cleaning them with alcohol. and did a close inspection of the IXJT board.
Then i removed the back of my radio so the module goes further over the pins, still no luck.

Some times the module version is displayed.

When bound the protocol randomly changes. i have the feeling it has to do with the naming of the protocols as before it was DSM X 11ms, and now it is DSM X F2.

I believe the FrSky D16 protocol was renamed too as it it giving me issues as well

I don't know if the OTX version is responsible for the name change or the MPM firmware. Could you please look in to this?


As you can see the radio on the right works flawless with the module mounted.

Originally Posted by FlyAndRip

I can assure you that nothing is wrong with the pins.

I tried cleaning them with alcohol. and did a close inspection of the IXJT board.
Then i removed the back of my radio so the module goes further over the pins, still no luck.

Some times the module version is displayed.

When bound the protocol randomly changes. i have the feeling it has to do with the naming of the protocols as before it was DSM X 11ms, and now it is DSM X F2.

I believe the FrSky D16 protocol was renamed too as it it giving me issues as well

I don't know if the OTX version is responsible for the name change or the MPM firmware. Could you please look in to this?


As you can see the radio on the right works flawless with the module mounted.

There is nothing for me to look at... It's a hardware related issue.
Just looking at the pin doesn't mean it's working. There has been multiple reports so far that the solder joint of that specific pin is faulty on these modules. So use a soldering iron and redo the connection making sure to include some part of the track in case it is broken. Use a multi meter and trace the track to test the continuity...
Pascal

Originally Posted by hpnuts

What you are saying is quite confusing... If you are talking about the Devo protocol, temperature has been added in the v1.3.2.58 release (and above). For the temperature sensor to appear, you must have a temperature sensor connected at the time of the sensor discovery.
On the temperature sensors that Devo can handle, only the 2 first are supported (FrSkyD telemetry to OpenTX)
Pascal

There are two separate issues, one was the temperature sensor on the Walkera Master CP that was never discovered. It has only one temp sensor connected to the receiver and attached to the main motor. The main battery level was discovered however. The motor temp can be displayed as a telemetry value on any Devo Walkera radio and Jumper T8SG with Deviation software/firmware.
The second is the four temp sensors available from the WK-CTL01-D telemetry module that I have installed on my Walkera MX-400S and QR X400 quad copters. And you have explained it that only two are supported, so I can of course only see two. That's ok for now. The Walkera F12E radio and the Jumper T8SG with Deviation can detect all four so the data are sent. Is it possible to support 4 temp sensors in the Devo protocol implementation? The GPS works also, except the year in the date display is showing 1955, odd. Other than that the altitude, ground speed and coordinates are reported correctly (offset adjustment needed for ground speed).
I have several QRX350pro drones and several Scout X4s and I will test the telemetry on these soon and will report the outcome. I don't expect any problems there though.
Thanks for your development work and support. Much appreciated.

Klaus

Originally Posted by kmewes

There are two separate issues, one was the temperature sensor on the Walkera Master CP that was never discovered. It has only one temp sensor connected to the receiver and attached to the main motor. The main battery level was discovered however. The motor temp can be displayed as a telemetry value on any Devo Walkera radio and Jumper T8SG with Deviation software/firmware.
The second is the four temp sensors available from the WK-CTL01-D telemetry module that I have installed on my Walkera MX-400S and QR X400 quad copters. And you have explained it that only two are supported, so I can of course only see two. That's ok for now. The Walkera F12E radio and the Jumper T8SG with Deviation can detect all four so the data are sent. Is it possible to support 4 temp sensors in the Devo protocol implementation? The GPS works also, except the year in the date display is showing 1955, odd. Other than that the altitude, ground speed and coordinates are reported correctly (offset adjustment needed for ground speed).
I have several QRX350pro drones and several Scout X4s and I will test the telemetry on these soon and will report the outcome. I don't expect any problems there though.
Thanks for your development work and support. Much appreciated.

Klaus

You keep not reading my posts....
Pascal

Originally Posted by FlyAndRip

I can assure you that nothing is wrong with the pins.

I tried cleaning them with alcohol. and did a close inspection of the IXJT board.
Then i removed the back of my radio so the module goes further over the pins, still no luck.

Some times the module version is displayed.

As you can see the radio on the right works flawless with the module mounted.

Do you have two IRX4+ modules? If yes, what happens when you swap them over between the radio's? If the issue persists it could be a bad solder joint in the X10 Express radio as well... Alcohol doesn't fix bad solder joints, but reflowing solder does, like Pascal said.

Originally Posted by alm_nl

Do you have two IRX4+ modules? If yes, what happens when you swap them over between the radio's? If the issue persists it could be a bad solder joint in the X10 Express radio as well... Alcohol doesn't fix bad solder joints, but reflowing solder does, like Pascal said.

I only have 1 module. works fine on the old, not on the new.
Thats why i believe that there is nothing wrong with the module it self.

I'm not going to reflow the solder on a 1 week old radio. i'd rather sent it back, still waiting on response from the seller.

Originally Posted by FlyAndRip

I only have 1 module. works fine on the old, not on the new.
Thats why i believe that there is nothing wrong with the module it self.

I'm not going to reflow the solder on a 1 week old radio. i'd rather sent it back, still waiting on response from the seller.

Makes sense, let them deal with it. Unless you bought it from China.

Originally Posted by nvd07

Hi I just wanted to report I am very happy since I compiled and flashed to my MPM the latest available release (v1.3.2.61) from march.
I have seen a noticeable improvement with my spektrum DSMX receiver ( AR6335 , 6 ports but AS3X 12CH ).
Over the previous months with v1.3.1.58 I was experiencing sudden and very short drops of the throttle CH1 (while other channels remained undisturbed), just with this protocol/receiver. This occurred about once or twice per flight.

It is now completely solved, I did several flights this morning.

After the initial success above, I did more testing of several versions. It turns out I can get all of them to exhibit the throttle loss with my AR6335 Rx, however with v1.3.2.61 it happens around 18 min after Tx startup whereas I have landed the plane (at 9-10 min) so this explains why I did not experience the problem in flight. By running 30min on the ground at moderate throttle I was able to get it to happen though (several times).

Below is a picture with the scope on the Rx pins, RED is the throttle, BLUE is ailerons.
I do not believe it is a FAILSAFE , as everything is set to HOLD in my FAILSAFE and last, I confirmed this to operate as intended , by switching OFF the Tx on the ground : the motor keeps running.

The Throttle loss is like a gap in the refresh rate ; whereas I thought it would be a swing to -100% .
I see the ailerons CH2 seems affected too however unlike the ESC, you cannot hear this on the servos.

I hope the picture , showing the signature and the duration, would help finding where the issue comes from... Note this is FW v1.3.2.72 this time.
I will post more pictures of 'normal' operation.

this is looking at the Rx pins when apparently everything 'sounds' allright

I was surprised to see various changes in the refresh : mostly 22ms and sometimes 27ms or 5/6 ms ... is this normal ?

Originally Posted by nvd07

After the initial success above, I did more testing of several versions. It turns out I can get all of them to exhibit the throttle loss with my AR6335 Rx, however with v1.3.2.61 it happens around 18 min after Tx startup whereas I have landed the plane (at 9-10 min) so this explains why I did not experience the problem in flight. By running 30min on the ground at moderate throttle I was able to get it to happen though (several times).

Below is a picture with the scope on the Rx pins, RED is the throttle, BLUE is ailerons.
I do not believe it is a FAILSAFE , as everything is set to HOLD in my FAILSAFE and last, I confirmed this to operate as intended , by switching OFF the Tx on the ground : the motor keeps running.

The Throttle loss is like a gap in the refresh rate ; whereas I thought it would be a swing to -100% .
I see the ailerons CH2 seems affected too however unlike the ESC, you cannot hear this on the servos.

I hope the picture , showing the signature and the duration, would help finding where the issue comes from... Note this is FW v1.3.2.72 this time.
I will post more pictures of 'normal' operation.

What you are showing sounds more like a RX bug... I mean the RX timing output should not depend on what is being receiving in any form. Even if you receive garbage the RX should still use the last known good value and output it at its on pace. Then after sometime if it does not receive anything that's where failsafe quicks in.
Have you checked if this RX has a firmware upgrade available?

Just by curiosity, what's your Multi setup? a picture of the model protocol config?

Pascal

Originally Posted by hpnuts

What you are showing sounds more like a RX bug...

Very possible as it would also explain why no other DSMX users are reporting the same problems as mine...

Originally Posted by hpnuts

Even if you receive garbage the RX should still use the last known good value and output it at its on pace.

Ok thanks it is very interesting to hear this!

Originally Posted by hpnuts

Have you checked if this RX has a firmware upgrade available?

I had not checked. So today I registered my serial # and looked it up. Even though I purchased the Rx in 2020, it looks like I am lacking a 2015 upgrade. But from the history they show, I think the 2015 upgrade would not be be solving this kind of bug. So I do not think it is worth purchasing the expensive cable which is required for any of these upgrades...

Originally Posted by hpnuts

Just by curiosity, what's your Multi setup? a picture of the model protocol config?

Yes curiosity is good as my settings could be wrong here!
So, I do the bind in AUTO, result is shown, then, as my AS3X mode + master gain is assigned to CH8 (in the Spektrum android app for the Rx), I then have to manually increase the channel number (in the protocol menu for the MPM ) from 7 to ... 12. I might be wrong here though.
I always assumed that going towards 10/11/12 would make no difference and would not disturb the Rx ?
The thing is, the Spektrum manuals do not say how many channels exist beyond the 6 physical ports; but the CH8 (which I learned from rcgroups) works fine for the mode/master gain, and I was able to see recently that the Spektrum app allows up to AUX6 (=CH11 if I understand ?). So in reality my best guess would be 11 channels...

Originally Posted by alm_nl

Makes sense, let them deal with it. Unless you bought it from China.

I have tested a crossfire module from a friend, and it works fine with telemetry.
Now i'm really confused.


Old Radio: MPM works
New radio : MPM issues.
New radio : Crossfire works.

Tried Opentx Firmware: 2.3.9 / 2.3.10 / 2.3.11
Tried different MPM Firmware versions

So what to blame now?

Originally Posted by nvd07

Very possible as it would also explain why no other DSMX users are reporting the same problems as mine...


Ok thanks it is very interesting to hear this!


I had not checked. So today I registered my serial # and looked it up. Even though I purchased the Rx in 2020, it looks like I am lacking a 2015 upgrade. But from the history they show, I think the 2015 upgrade would not be be solving this kind of bug. So I do not think it is worth purchasing the expensive cable which is required for any of these upgrades...


Yes curiosity is good as my settings could be wrong here!
So, I do the bind in AUTO, result is shown, then, as my AS3X mode + master gain is assigned to CH8 (in the Spektrum android app for the Rx), I then have to manually increase the channel number (in the protocol menu for the MPM ) from 7 to ... 12. I might be wrong here though.
I always assumed that going towards 10/11/12 would make no difference and would not disturb the Rx ?
The thing is, the Spektrum manuals do not say how many channels exist beyond the 6 physical ports; but the CH8 (which I learned from rcgroups) works fine for the mode/master gain, and I was able to see recently that the Spektrum app allows up to AUX6 (=CH11 if I understand ?). So in reality my best guess would be 11 channels...

What could be interesting is to capture what happens to the pulses when you turn off the TX (or the module or change the RX number which is all equivalent from the RX perspective).
Pascal

Originally Posted by FlyAndRip

I have tested a crossfire module from a friend, and it works fine with telemetry.
Now i'm really confused.


Old Radio: MPM works
New radio : MPM issues.
New radio : Crossfire works.

Tried Opentx Firmware: 2.3.9 / 2.3.10 / 2.3.11
Tried different MPM Firmware versions

So what to blame now?

As I said before the multi module hardware. I've never pointed out the radio to be the source of the issue.
Again, it's either the connector pin 5 solder joint and connected trace or the telemetry signal is too weak for the radio.
Pascal