Open phileville opened 1 year ago
The saving of the backup point could be done in main firmware, but the restore would probably have to be done in the bootloader - probably not a good idea to change model/radio settings while the main firmware is running. That may make the restore simpler also.
For legacy users, this will also make sense, as this is exactly how backup and restore worked for EEPROM.
The saving of the backup point could be done in main firmware, but the restore would probably have to be done in the bootloader - probably not a good idea to change model/radio settings while the main firmware is running.
Couldn’t it work like the USB Storage - shutdown everything before restoring and re-load all the YAML files afterwards?
That is how I envisioned it would work..
I'm thinking more along the lines of it's good to not do any more things in the main firmware that can take the whole system out while online than we have to. As there will always be that person that tries to do a restore while the transmitter is actually in control of something and ignore all the warnings. People get complacent... why take the props off to test... it won't chew my face off! famous last words...
I do not think that it would be that hard to safely achieve this... Before restore sequence begins, the radio checks to makes sure that it is not bound to anything (RSSI =0?). If that state is not met, then the restore sequence terminates. I would hope that USB Storage and gamepad mode already do something along those lines, but I honestly never tried to connect via USB while connected to a model. Edit Ok, so I just tested on my radio and you are able to put the radio into USB Storage and gamepad mode while a model is connected. That seems like an issue to me. Once you disconnect form USB storage mode, the model will failsafe.....
The caveat there is that this only works for links with telemetry. i.e.. If I use my DSM2 RXs (which don't have telemetry), the radio doesn't have any idea the receiver is active. So the determination needs to be made that it's an acceptable risk/edge case for non-telemetry (or telemetry links with telemetry disabled) to be not handled. Please do not for one minute read/interpret this to mean me being against the idea (as I think it is a good one), I am just trying to ensure all possibilities are considered.
i.e. does the check need to change depending on the link capabilities?
1) if the telemetry/RSSI/USB check says it is active, no, you can't do a restore... period... and inform that the link needs to be shut down, else allow the restore to proceed. 2) if running a link that either has no telemetry, or can have the telemetry disabled (meaning we need to be able to check for these conditions), do we put a warning up that ... I don't know... requires you to tick the confirm box before you can press the restore button. i.e you can't just hit ENT, ENT and it just triggers the restore.
i.e. do we only need 1 or 2, or do we need to do both 1 & 2 always, to cover all bases? It's not like you do a restore every other day, so it being ... awkward ... isn't a problem. Plus you want to minimise the chance of restoring the wrong backup, and blowing away a working config that you didn't back up (how's that for a nice circular problem? 😆 ) ... while not nannying the user too much. 🤪
I think having the restore function in the bootloader is the safest way.
Yes, I can agree with restore being in the bootloader - it is not quite how I envisoined it, but it is most likely the best way. Assuming that adding "Rollback to Restore Point" it to the boot loader is possible. Kind of sad that we have take into account that some user might actually try to do a system restore while flying... or turn off their radio while flying... But this is the world we live in. Maybe this would be a cool feature to have for 2.10.
Could the system check that no model is selected or that a special model slot is created “Backup/Restore” or “No Model Selected” that has to be selected in order for any operations that are potentially unsafe?
Is there an existing issue for this feature request?
Is your feature request related to a problem?
Currently, the only way to make a backup of your radio and model settings is by using EdgeTX Companion or manually copying the folders to your computer. This is not a convenient option if you are routinely making changes to your models through EdgeTX on the radio.
Describe the solution you'd like
What I would like to have is a feature that when activated, makes a copy of your radio and model folder to a date/time stamped “backup” folder on your SD card. Additionally, you can “rollback” to a previous date/time, by selecting the appropriate folder and then the feature copies the backup files back to the radio and model folder and then reboots the radio.
How this could work –
I do not think that SD card space would be an issue since the .yml files are so small and most people are upgrading their SC card to 8, 16 or 32gb
Describe alternatives you've considered
No response
Additional context
I am sure there are many other use cases and variations of this that could prove this to be useful. There are some other related enhancement requests, but they seem to be asking for a version of the EEPROM backup functionality, where my solution is to just keep it simple and make copies of all the files (not zipping) to backup folders, so really it should not be too hard. Clearly the restoring point might be a little more tricky, but I am guessing it is doable.
https://github.com/EdgeTX/edgetx/issues/2949