Open lshems opened 3 years ago
lshems
commented
3 years ago This would also allow for easy distribution of single models. OTX files with the radio profile embedded is an unheard of problem for sharing stuff, because most people don't understand the radio profile is included, containing also calibration and other stuff!!
They will just ruin their setup on any exchange and then stop exchanging. gone model sharing community for color radios.
pfeerick
commented
3 years ago That is indeed a missing feature... the ability to back and also restore via the UI... this allowing easy exchange of model files (bar lua script, image and sound dependencies). UI screens should also be included in the import.
raphaelcoeffic
commented
3 years ago If you guys have nothing against it, Iād like to introduce that when switching to YAML. I had a try at this a looong time ago. The issue at the time was that it required a ZIP file, and the only library I could find makes heavy use of the stack, which is rather limited on the platform. We could however bypass it and use plain file copy instead.
lshems
commented
2 years ago @raphaelcoeffic
Any updates on this? I really would like to use the backup folder to save a model from one radio type, and restore it in the field to another radio type, just by restoring it from a switched SDcard.
The popup is already there when creating a new model on the color radios in edge 2.7. So just populate the picklist with restore, show the backup folder .yml files, and allow to restore which will just add that file to the models available on the radio.
pfeerick
commented
2 years ago Once https://github.com/EdgeTX/edgetx/pull/1374 is in, we can look at this sort of functionality. Part of this is a moot point now though now with templates...
Or, perhaps, do you think this is something that to be added to the SD card browser? i.e. a yml file could have an "Import model" option? Then it gets added to a "imported models" category (or label, in the future)...
lshems
commented
2 years ago Once #1374 is in, we can look at this sort of functionality. Part of this is a moot point now though now with templates...
Or, perhaps, do you think this is something that to be added to the SD card browser? i.e. a yml file could have an "Import model" option? Then it gets added to a "imported models" category (or label, in the future)...
I still believe this is very useful. Yaml file model import through browser would be perfect.
This is not the same as templates. It can be used as such, but is much more flexible.
lshems
commented
2 years ago Another approach would be that all yaml files in the models directory are listed in the 'non-labeled' category and thus all yaml files are checked upon startup and listed based on the models file contains the categories for the labeled ones. I think you need to do that now also,to check if labelled models exist at all.
dlktdr
commented
2 years ago Another approach would be that all yaml files in the models directory are listed in the 'non-labeled' category and thus all yaml files are checked upon startup and listed based on the models file contains the categories for the labeled ones. I think you need to do that now also,to check if labelled models exist at all.
In the #1374 PR this is how it currently works. Just copy the .yml file into the models folder. As soon as the radio boots it will find this new file. It will show up under "Unlabeled" If the model didn't have and labels listed in it. Should be a lot easier to just copy the .yml between radios now.
It's in a state in needs extra people testing it before it gets merged, feel free to give it a try.
lshems
commented
2 years ago Nice. Great minds think alike lol.
I can download a test companion or do I need to compile myself (which I can't). I would LOVE to be test. This is what kept me from migration all to edge.
pfeerick
commented
2 years ago @lshems You should be able to download both firmware and companion (when relevant) from the Checks tab of any PR if the PR is merge-able (meaning it doesn't conflict with changes in the upstream main). I've hopefully resolved that, and the firmware and companion builds are running now. š¤
edit: I swear I remember there being a Companion component as well, but it seems like that was either another branch or pulled for now... so it's only present in firmware right now.
dlktdr
commented
2 years ago upstream
Yes companion to a different branch. Have some work to finish that yet. Going to try to finish in the next week or so so there is time before Sep to test.
pfeerick
commented
2 years ago No problem... will start playing with the new firmware soon, and do the last few bits of tidyup as there's still a few things to tidy up due to main branch changes that didn't quite make it across properly... to be expected with all the changes from LVGL and translation collisions, etc...
lshems
commented
2 years ago I'll do some tests on firmware then as well. Just popping a card in different radios is not to much of a hassle.
No issues switching between color and BW?
pfeerick
commented
2 years ago Generally there shouldn't be, other than the obvious... if one model is using switch 7, and the other transmitter only has 5 switches... age old problem of square peg and a round hole š (but at least in our case I think we just drop the extra switches... I can't say for certain I've checked to see what happens... probably did and forgot... š ) ... let us know how you go! š·
lshems
commented
2 years ago I would have no issue with dropping switches.
I normally preprocess ALL switched in an input. If I have a setup that uses 7 switches on a 5 switch radio, I assign two inputs to max and weight -100. This forces the same behaviour as a switch in up position.
I did propose to make that a radio feature once. That would solve the round and square peg problem once and for all.
On a limited radio you would just have to configure which switches are linked to physical switches and which to defaulted dummy switched.
When working on the sim, I need file access for LUA so set the imu to SDcard. Then I also need local .bin files and a matching models.txt file in the RADIO directory.
I can manage that since I know how to tweak the .bin and the models.txt file. But it is really annoying that I cannot import binfiles from the model directory to have them in the otx file structure, and vice versa, as is possible on the B/W radios.