QR code screen dump of flash/EEPROM settings

[frazierjason]

Add a simple QR barcode encoder that dumps all the flash/EEPROM settings to a 2D barcode on the screen, which can be captured and converted back to a human-readable settings list. The capture-and-convert function would be external via a smartphone app. Users can back up with a snap of the camera (any camera at all), cherry pick what they want from the captured settings later using the app, and review/edit the radio directly in the field without a PC or editing a USB stick. It could also help with debugging when people can trade and compare settings online easily. QR Version 25 at low error correction could hold the entire EEPROM in binary with 117x117 resolution, which can be doubled in size on even the 320x240 screen to facilitate image capture. Happy to take comments and gauge interest before digging further into this.

A potential C library to do this work: https://github.com/ricmoo/QRCode

[ghost]

to restore the settings you still need an USB device.... but the idea is not bad

[frazierjason]

Correct, that's why I am recommending the QR code route, which does not store any files in the radio. The "restore" operation is performed manually by the end user inputting everything themselves while consulting the QR code data (reformatted for humans of course).

The external application could trivially store these backups with nicknames, to compare later against the current working settings in the radio and highlight just the deltas to be changed.

Another thought: besides using file-based restore, how about the smartphone sending the settings back to the radio using the CAT USB serial connection? The FT817 command set does allow for read/set EEPROM data. Most Android phones today can do serial with an OTG connector -- iOS is a tougher sell due to Apple's iAP restrictions. This notion might be expanding my idea further than intended though.

[df8oe]

I am sure it is much easier to export complete EEPROM in a binary via USB.

But that is not the way we want to implement it. Often EEPROM structure changes (when new parameters must be stored) so it would be a nice idea to have configuration exported and imported as plain text files (like all config files in Linux). But we must implement functions which translate binary from mcHF to text and (much more complicated, because there must be many plausibility checks) text to binary for restoring. Not an easy and simple task, and will 100% not fit in 512KB MCUs.

[frazierjason]

For sure, text-based import/export would be much better. If you can refer me to some other logged issues, I can take a look and maybe first crack at it. Parsers are my thing. I love parsers.

To clarify, in your previous response do you mean QR code feature will 100% not fit in 512KB MCUs, or you mean any import/export feature (even just handling plain text) will not fit? The above mentioned QR source and header is only 770 sloc, and includes only stdlib, stdint and string.

[df8oe]

Nothing of those will fit. We only do have a few kb to the border of 512KB MCUs (firmware must be smaller than 512KB - 32KB bootloader size - 32KB virtual EEPROM size and we are already scraping at this edge. Maybe new NR code will fit (it will increase a little bit) but I do not think anything else will fit. We already discussed that development will continue for MCUs with bigger flash size and will stop for 512KB devices. But that is not the point we shall discuss. Implementing parsers would be great. But pay attention: RAM is nearly at the end. You have to code in a way that you do only need very low RAM or modify existing code to claim some RAM from other functions and give it back when parsing finished.

[db4ple]

See here: https://github.com/df8oe/UHSDR/wiki/Backup-and-Restore Right now backup and restore works, human readable output is not as trivial as it seems, if we don't want to spend a lot of manual work in keeping things in sync, if new parameters are added (which is very easily done on the code side).

[df8oe]

Discussion maybe continued at #1460