Support for external Multiplex MLink JR type module

[mha1]

This adds support for external Multiplex MLink JR type modules that work on PPM and are able to deliver digital telemetry data (like Multiplex HFMG3 M-LINK 2,4 GHz HF-Module)

Summary of changes radio:

• added new telemetry protocol decoder utilizing the new serial/module API
• extended radio UI for 128x64, 212x64 and color LCD radios to allow sub-type selection of telemetry protocol for the generic external PPM module type (NOTLM for no telemetry, MLINK for HFMG3 type telemetry). Further telemetry protocols for the generic PPM module type can be easily added if required.
• extended Yaml encoder/decoder to reflect the sub-type selection made for the generic external PPM module type
• added two now sensors for g-rates (sensor Acc) and MLink Special (sensor Spcl) to MLink telemetry
• extended telemetry timeout to 2s as RSSI will be updated only every 800ms with 15 sensors being received.

Summary of changes Companion:

• extended Companion UI to allow sub-type selection of telemetry protocol for the generic external PPM module type
• extended Yaml encoder/decoder to reflect the sub-type selection made for the generic external PPM module type
• extended model writer to output sub-type selection made for the generic external PPM module type

Radio:

Companion:

Yaml radio and Companion:

moduleData:
  1:
    type: TYPE_PPM
    subType: MLINK
    channelsStart: 0
    channelsCount: 16
    failsafeMode: NOT_SET
    mod:
      ppm:
        delay: 0
        pulsePol: 0
        outputType: 0
        frameLength: 0

[mha1]

@pfeerick Thanks for your suggestion. I changed the "NOTLM" sub-type texts to:

• "No Telem" for 128x64 (this is the max numbers of characters it can take)
• "No Telemetry" everything else including Companion

What do you think?

[mha1]

@pfeerick anything else I can do? can we go ahead with this?

[elecpower]

@mha1 Michael have you checked Companion telemetry sensors tab to ensure new sensors are displayed and with correct units, precision etc?

[mha1]

@elecpower Neil, thanks for your review.

Following your requests I changed PpmSubTypeStrings to

static const QString ppmSubTypeStrings[PPM_NUM_SUBTYPES] = {
    tr("No Telemetry"),
    tr("MLink")
  };

Both new sensors "Acc" and "Spcl" are displayed as expected:

[mha1]

Need to put this on ice until @raphaelcoeffic works the magic to solve the shared interrupt problem for target Taranis, see #3329

[froqstar]

Where can I even get such a module? Seems to be discontinued?

[mha1]

@froqstar

Where can I even get such a module? Seems to be discontinued?

Yes, they are discontinued but you get them second hand as many were sold at the times.

The reason why I implemented this is there still is a community out there hanging on to their Multiplex receivers and telemetry stuff using those modules, especially in central Europe. You might ask why they don't use an internal or external MPM as it offers the MLink RF protocol and also handles telemetry. The reasons are mainly distrust in the MPM implementation and more serious legal concerns. Check out the MPM implementation. Even if the MPM MLink RF protocol implementation works fine it is still kinda basic and there is no arguing about that, it is not complying to EU regulations. It implements the RF protocol like an FCC protocol meaning doesn't implement LBT or any other means to comply with EU regulations.

The implementation I chose reuses most of the EdgeTX MLink telemetry code for the MPM MLink telemetry. It is basically just a minimal extension to the UI, means of selecting the source of the digital telemetry data (SPort pin) and a simple decoder for the telemetry data as the external module delivers the data in a different format. It also adds two forgotten sensors which are now available for MPM MLink too.

All in all it is a low flash memory consuming extension allowing legacy users to migrate their MLink JR modules to a modern radio with EdgeTX.

[mha1]

@pfeerick please consider 2.9 again. I was just waiting for soft serial to be fixed. Think it's done, see #3382 and #3329

[mha1]

Argh draft again, soft serial fix for target Taranis has side effects for some radios e.g. X7 access.

[mha1]

If soft serial is ready this is ready ...

[ParkerEde]

I have now created this PR together with
#3329
#3349
#3374
#3382
tested. Both with a Horus X10S Express, and with a Taranis QX7S ACCESS. The functions ext. PPM Telem: MLINK, as well as internal ISRM with R8pro and several sensors were checked. Everything runs smoothly. Good work.

[ParkerEde]

I tested this PR again with the latest MAIN+#3329 using Horus X10 Express and Taranis QX7 ACCESS. Everything runs great.

[mha1]

@pfeerick Sorry to bug you again. This relatively simple PR was tested over and over again after many problems were found (and fixed) not caused by this PR but necessary (not only) for this PR to work. Re-testing included Taranis (X7access, x9d+, x9d+2019), Horus (tx16s, x10access) type radios and of course Companion to cover all bases. So I am confident it'll work fine without any side effects to important stuff. But as the foundation needs to be perfect it is required to merge #3419, #3415 and #3329 too.

Please consider a bundled merge into main. 2.9 main of course 😉

[pfeerick]

It should happen soon, 2.8.2 is finally out of the way, so can start thinking about 2.9 again. :)

[mha1]

U moved to a different continent?

[mha1]

@pfeerick I think this is good to go too

[mha1]

force pushed to keep PR up to date after merge of #3329

[pfeerick]

LGTM on TX16S and X9D+2019. telemetry via sport emulator working good, companion reading and writing properly, hope it makes for some happy MLink users :)

[mha1]

Thank you very much. It takes all kinds to make a world ...

To make some kinds happy #3597 needs to be solved too. It was visible on your and Raphael's logic analyzer screenshots but I started counting the channels only yesterday.

[pfeerick]

Sometimes it take a while for the penny to drop 🤭

[mha1]

I know, patience is a virtue