Adding radio persistence capabilities

Alan, K2WS

The state of each slice Rx's control settings( freq, mode, BW, AGC-T, Decay time etc.) must be supported with v1.0. How frustrating would it be to the new user coming from PSDR or EIKY radios, if all these features reset to default when band changing or powering up? The user release of SSDR v1.0 would appear like a beta-version to regular users - especially if this very important feature is delayed for months. Note: This topic was created from a reply on the Why are radio settings not saved when I shut down the FLEX-6000? topic.

Tim - W4TME

Alan, At this time Persistence is scheduled for SmartSDR v1.1, although we will take your feedback under consideration. Thank you for your input.

Jim K4JAF

I agree, persistence should be in the first version available to the general public, if not, hopefully it wont be several months away.

Beppe IK3VIG

Tim, persistance (in all its parameters) "must be" in 1.0 version, DAX support too....we can't speak of new era of Radio without it (using external audio interface of 15 years ago is not very new )

Steve K9ZW

In addition to Persistance the Profiles (multiple setting saved presets) of PowerSDR was very useful. An additional tweak that could be helpful is a boot without Persistence option as SmartSDR boots. As the software evolves it could be useful and as an easy recovery if settings we're working out. Rather than a hard reset to default it would be sort a "safe mode" boot "just in case." 73 Steve K9ZW

Michael - N5TGL

"The user release of SSDR v1.0 would appear like a beta-version to regular users - especially if this very important feature is delayed for months. " I couldn't agree with you more. We signed up for the preview, knowing we'd have to put up with limitations. I do not think that customers that get a "production" release that doesn't include persistence would be so understanding. If I was in that position, I know i'd be extremely teed off.

Jim

Adding persistence is a no brainer. It should be added even before 1.0......but 1.1???????

W4EG

Please, tell me this is an oversight to let it go until v1.1... This should be the one of the upmost urgent item needed to be implemented.

K4EAR

As bare-bones as 12.17 is to me, it's a <60 second reset. I could do a database reset with PSDR 2.6.4 in a couple minutes...committed to memory for so long. Remember back 5-6 years ago with the Flex 5000 in its' infancy. I'm anxious too, but my expectations have been tempered over the years from the advent of SDR1000. Good things will come, but don't take the 5000 offline yet :-)

Tim K8XS

Please re-word to make it readable.TNX

K4EAR

All the text I typed did not appear nor was editable

Jim K4JAF

AGREE, persistence should be soon in 1.0. Jim K4JAF

W8SJV

Where will the persisted data be stored, in the radio or with the client? This will definitely impact usability for multiple local clients and future remote operation. Perhaps a combination of persistence locations would be appropriate, even in the cloud! Whatever method is chosen needs to be clear, easily understood and perhaps portable.

Steve K9ZW

This is a good observation - perhaps some sort of "chooser" to select where persistence the settings table is being loaded/saved from/to? Or a two-tier Persistence Option - where at basic level the settings live at both the radio and the client, are compared, and if matching within parameters are used without further interaction. At the advanced level menus and reconciliation protocols come into play - a non-match, certain settings outside of parameters in an otherwise close match, existence of a flagging-event (multiple active configurations detected, cross platform detected, multiple/changed hardware detected, other key triggers, or by user selection then a menu system is available. Interesting logic tree to consider - hardly trivial as it might seem at first blush. Interesting! 73 Steve K9ZW

Mike W8MM

My company's product has a smartphone app that (among other things) can be used to program various settings and options of the hardware. The settings are persistently stored in the hardware (NVRAM). The app has a feature called "Profiles" that stores different setups under user-defined names. The "Profiles" are available in a drop-down box format that makes them easy to chose among. The user simply sets the features desired and saves it to a "Profile" and makes up a descriptive name for it, like: "Ohio highway driving", or "Commuting", etc. The app maintains the last used "Profile" in the smartphone, independent of the hardware. On power up or when launching the app, the app connects to the hardware and attempts to assert the last used "Profile", the app checks the feature/settings state of the hardware. If the app finds disagreement between the profile selected and the hardware state, it asks the user whether to change the hardware to the new profile or should it save the current hardware setup to a new "profile", or opt out and proceed with no changes to the hardware state. Another cool feature is the ability to "export" "Profiles" from the app to a friend by e-mail so they can try the settings by importing them to their hardware as a "Profile". http://a2.mzstatic.com/us/r1000/039/Purple6/v4/19/54/b4/1954b4d2-11f5-d37a-d567-c6814c02adfa/mzl.hbdklxax.320x480-75.jpg http://a3.mzstatic.com/us/r1000/005/Purple4/v4/ac/cf/75/accf7538-7ff7-5158-9e9e-b27a1e3f28f7/mzl.wgwpsbvy.320x480-75.jpg For Flex-6K radios, favorite operating personalities stored for recall should be maintained in the SmartSDR files by local or remote users. The Flex-6000 hardware should maintain a local copy of last used settings in its persistence memory. Perhaps remote users should get a pop-up that says "You are about to change the settings of the remote radio. Please confirm this action.", whereas local users could assert their settings directly with one click. The exporting of radio setup files among users could be a very cool way to share knowledge in Flex-space.

W8SJV

Steve & Mike, Steve, you are right it's not trivial! After thinking about both of your excellent comments and considering what would be the best way to implement persistence, it seems to me that, first, several typical use cases should be generated. These would then be used to test any proposed architecture for suitability before implementing it. I can think of several cases I would use personally: 1 - Simple local operation near the physical radio (rag chew/contesting/etc.) 2 - Operation on same local network away from the radio. 3 - Remote operation on equipment I own or take with me. (Smartphone/Tablet) 4 - Remote operation on other's computer equipment. (take "Profiles" along on a Flash Drive) 5 - Remote Demo operation of the Hobby/SDR (with/without Internet access) 6 - Third party remote operation of the radio. Might need to EMAIL a "Profile". That said, Mike I do think the multiple "Profile" scenario you suggest would work very well. It allows for simple no setup operation using the radio's stored settings or a preconfigured setup of your choice. It's really fun to think of the possibilities! John - W8SJV

W4EG

Great analyses ... Thanks

Ken - NM9P

Excellent discussion, everyone! I love the thought of customizable, exportable, selectable rig profiles. Keep dreaming those ideas!

Steve K9ZW

For convenience, and in order to not set the bar so high that Persistence is pushed off a long ways, should Persistence be divided in to: Simple Persistence - the level we'd expect in a single user (basically stored settings similar to how PowerSDR did it) and Complex Persistence - where profiles, remote/local voting logic and multi-client/radio-servers come into play Obviously "Simple Persistence" could happen earlier in the development process. 73 Steve K9ZW

Steve-N5AC

Persistence data will be stored in the radio so that you can move between clients and have the same experience

Steve-N5AC

This is the current plan, Steve

Steve K9ZW

Question - what if I have one client and several 6000 series radios in various locations? Would also be useful to have a settings-storage feature so a radio reset to factory defaults (say from service) is "bore sighted" to the operators preferences from stored data. 73 Steve K9ZW

Tim - W4TME

We will be adding basic persistence to SmartSDR in or before version 1.0 and more advanced persistence capabilities will be included in future releases