Support Named model export for sharing model configs with others.

[DavidJJ]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

I have been asked multiple times to share my configuration for some of my models.
On my Spektrum radios I can go to : Model Utilities -> Export single model -> select model -> Export This produces a "01_myModel.spx" file that I can upload to RCGroups / github etc. Others can download that model and have a fully working setup that matches mine.

Nether OpenTX nor EdgeTX have an option like this. They only support saving all models to a backup file.

Describe the solution you'd like

It should be possible to have a menu item that says "export/import" that allows you to export / import the currently selected model to a file named after the the model in a format that can be imported by other radios running the same software.

It would be even better if the files were forward compatible: eg exports from version 2.3 can be imported in version 2.4...etc

Describe alternatives you've considered

The current way to do this is to backup all models to a file, reload that file into companion, delete all the models you do not want to share, then re-save that backup and share that backup with others. Which still doesn't seem to work when they import the file into companion.

Additional context

No response

[lshems]

See also #250

[elecpower]

Companion even in OTX has had the ability to have multiple models and settings files open and copy and paste between them so no need to delete the excess models before saving though admittedly only to an otx or etx file format.

Companion 2.8 via #1968 after reading models and settings from a radio or opening an existing otx or etx file, will have the ability to save model(s) to named yml files (default to model name) to a folder/directory of your choice. The saved yml file(s) can the be used as a template to create a new model in Companion or radios; or share with others.

Moving models between radio types, OTX, ETX and versions is never going to be perfect due to the number of potential combinations.

[pfeerick]

Another, although admittedly not as user friendly option has always been to simply copy the .bin (now .yml) file for the model and update the model index on the target radio (RADIO/model.txt, MODELS/models.yml). The caveat there though is a .bin will really only work on the same model radio, and while .yml will work on all radios, you may then run into the problem that Neil mentions of the right number and type of inputs. i.e. Spektrum have it easy since they only have a handful of radio models. OTX/ETX supports countless different radios, with all sorts of switch, stick, pot, slider combinations. Doing a copy-paste conversion through Companion will at least give you a heads-up as to what is going to be incompatible.

[lshems]

I really am waiting fro this long time.

A simple solution to missing switches would be to simply replace them by a newly to introduce source MIN, which equals to -100, and MID which would equal 0, similar to the already existing MAX that equals 100. Replacing all occurrences of non-existant switches with MIN would then we similar to defaulting these switch positions to -100, which is default for most users. At least it wouldn't wreck the setup. You could even check if there are switch alerts and set the missing switches to those positions using MIN, MID or MAX.

Missing trims could be set to MID.

If this convention would speed up development of a general export function on the RADIO, great.

I do understand that nowadays the SDcard is used during radio operation. So I wonder if it would work to 'backup' the model to the backup folder (as on BW radios), switch the sd card to the other radio, load the backup model there, and return both original cards. Then you would need to save that model to get it on the original sdcard??

[pfeerick]

Adding MIN and MID is also something I've had as a long term want - since it made no sense to me that there was only MAX (although, I do also appreciate the fact that once you have MAX, you can also create MIN by just inverting, and MID using an offset, but that is nowhere near as simple as just having the constants, and doesn't work for all inputs/mixes, etc).

Companion will now let you save/export individual models. With the new labels system on colorlcd radios, if you can figure out which model file is the one for your model, you can literally just copy it to another colorlcd radio (ensuring no filename clash) and the label system will automatically import the new model when you start the radio up. But it would be much better to have a proper export/import system, and I think this is being slowly worked towards - just need all the foundational stuff in place first.

[lshems]

I do use the MAX source when replacing a switch assignment with a fix input. But I had to write a special function also setting the source to -100. Just to replace a switch controlled input by the default switch position.

With MIN, MAX and MID available, in any script for assigning switches to a function by showing a list to a user, you can just include these in the list, allowing the user to define the default switch position of the 'imaginary' switch if he doesn't want a real switch to be assigned.

Think for instance about using two inputs with physical switches SA and SB assigned as source to allocate 9 flightmodes. Setting SB to MIN would simple disable the choice of 6 flightmodes and be similar to just having SB in up position. Your model remains fully functional.

Even a low number physical switch radio model loaded on a radio with a lot of switches, would allow to immediately unlock the other flightmodes again by having the user assign a switch instead of MIN.

Other example: use a model for a 4 servo wing on a 2 servo wing. No flaps needed, set the switch source on the flap input to MIN so 'flaps' are in default position, and that switch is free to be used for the second flight mode switch again.

I think it is a very simple and solid solution. The switch alarms during startup need to be checked anyway, so would provide a very nice way to determine the defaults.

[lshems]

Companion will now let you save/export individual models. With the new labels system on colorlcd radios, if you can figure out which model file is the one for your model, you can literally just copy it to another colorlcd radio (ensuring no filename clash) and the label system will automatically import the new model when you start the radio up. But it would be much better to have a proper export/import system, and I think this is being slowly worked towards - just need all the foundational stuff in place first.

I hate using companion. It should be there to create/maintain complex models,but should not be necessary for model exchange!

It is impeding a model exchange ecosystem.