Store hardware calibration values separately to radio and model settings

[Miami-Mike]

Stick and pot calibration data are unique to every radio, so if possible, that data should be stored separately in the radio and not as part of the models and settings data, and therefore not included in otx files. If it was done that way then a new otx file created in Companion would work without recalibration in any radio of the type it was created for.

I don't know if this is possible or not, but perhaps it could be a third file to go along with the EEPROM.BIN and FIRMWARE.BIN files.

[pfeerick]

It's not part of the model settings now, but the radio settings. I get your point though, as OTX files (which the Companion uses, and encompass both model AND radio settings). Meaning it's necessary to import hardware settings from the radio if anything has changed regarding calibration of sticks, voltage tuning, etc. Which is just great if you remember after writing the OTX to the radio. 😮

[Miami-Mike]

I said "models and settings" because Companion says "Read Models and Settings From Radio" and the calibration data is part of what you get when you select that.

But anyway, for years I've felt that data shouldn't be part of the eepe or otx file, and there shouldn't be any way to copy those settings from one radio to another because there's no reason to do that.

[raphaelcoeffic]

We can probably try to place these data into a different file when going for YAML, but that could still a bit of pain to do so. It might have to wait for the next iteration.

[lshems]

There is a simpler scenario.

Read the radio, load the models in the read image, and restore the image.

You don't even need the radio calibration stiff to be stored on another place than the radio. Even backup doesn't make much sense, as recalibration is easy..

[pfeerick]

That is the use case the OTX guys would have envisaged, hence why this becam an issue at all. As what would preserving settings like trims, and other changes when you're out in the field. This is why it wasnt much of an issue, if you always start with reading the radio, and then copying any model settings in.

But there is a good point here still, i.e. what if you have two radios, and want to just write the same otx models to both. The simplest way would currently also overwrite the hardware calibration on one tx. Not ideal. There should be some mechanism to protect those settings - i.e. seperate file, having the option to not change those settings as a checkbox, etc.

And remember that hardware settings are more than the sticks and pots... This includes the voltage and current calibrations, and potentially stick and switch configurations.

[lshems]

You don't get my point.

The write models activity from a user perspective consists technically of a read, add to offline file and write.

So the user doesn't even know the entire flash us read first.

Like changing a page in a archive) you take the archive.folder out of the library, take a page out, put another page in, and put it back in the library.

[pfeerick]

Ah, ok, you were confusing me with bringing the model stuff into the equation (since you don't actually care about them in this scenario)... you actually mean read back the radio specific stuff, and then write it as part of the process of writing the model data. Yeah, that would be good... and also in line where I said "having the option to not change those settings as a checkbox, etc." ... either read them back, to preserve them, or over-write them with the stored values. Always give the user options, where possible.

[lshems]

I don't agree to the last sentence. Users are ignorant and don't read manuals. Don't 'give' them options.

Put all 'opitions' away until the ask for them.

Easy and expert mode. Lol. Just introduced it on my apps. Works really nice.

[pfeerick]

I'll remember that when we're working on the UI... you'll have not options at all then... not even one to run LUA scripts! 😛

You give the user options, where possible. Even giving the option for easy and expert is itself an option... In this case, you have the option for preserving radio settings, you set it to a sensible default, and hide it in the options screen with all the other options. User can go looking for it if they need it. Sheesh... thinking I was suggesting it be put on the front of the box in 60pt flaming red comic sans! 😆

[lshems]

Just kidding.

[elecpower]

I wouldn't put too much faith in saving and restoring hardware and calibration using the profile. These functions haven't been maintained for years and the data is out of step with newer radios and upgrades. There was even talk amongst OTX users an devs about dropping due to the issues and effort to keep another set of radio specific settings version controlled and converted as required and the use cases put forward were more nice to have and still there was the need to check and tweak after restoring. I'd favour keeping the physical radio specific settings eg calibration separate to generic radio settings eg analog names. Need to consider the model crash risk probability of restoring the settings from another radio and forgetting to review. I also favour prompting user on radio start up for the need to recalibrate if settings are no those just read from the radio. Though if separate file no need.