Adding radio persistence capabilities

  • 22
  • Idea
  • Updated 6 years ago
  • Implemented
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.
Photo of Alan, K2WS

Alan, K2WS

  • 14 Posts
  • 6 Reply Likes

Posted 6 years ago

  • 22
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9198 Posts
  • 3558 Reply Likes
Alan,

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

W4EG

  • 43 Posts
  • 6 Reply Likes
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.
Photo of Jim K4JAF

Jim K4JAF

  • 371 Posts
  • 114 Reply Likes
I agree, persistence should be in the first version available to the general public, if not, hopefully it wont be several months away.
Photo of Beppe IK3VIG

Beppe IK3VIG

  • 56 Posts
  • 15 Reply Likes
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 )
Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1571 Posts
  • 772 Reply Likes
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
Photo of Michael - N5TGL

Michael - N5TGL

  • 308 Posts
  • 103 Reply Likes
"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.
Photo of Jim

Jim

  • 17 Posts
  • 6 Reply Likes
Adding persistence is a no brainer. It should be added even before 1.0......but 1.1???????
Photo of K4EAR

K4EAR

  • 138 Posts
  • 17 Reply Likes
As bare-bones as 12.17 is to me, it's a t take the 5000 offline yet :-)
Photo of Tim K8XS

Tim K8XS

  • 48 Posts
  • 8 Reply Likes
Please re-word to make it readable.TNX
Photo of K4EAR

K4EAR

  • 138 Posts
  • 17 Reply Likes
All the text I typed did not appear nor was editable
Photo of Jim K4JAF

Jim K4JAF

  • 371 Posts
  • 114 Reply Likes
AGREE, persistence should be soon in 1.0. Jim K4JAF
Photo of W8SJV

W8SJV

  • 14 Posts
  • 3 Reply Likes
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.
Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1571 Posts
  • 772 Reply Likes
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
Photo of Mike - W8MM

Mike - W8MM

  • 220 Posts
  • 50 Reply Likes
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/P...

http://a3.mzstatic.com/us/r1000/005/P...

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.
Photo of W8SJV

W8SJV

  • 14 Posts
  • 3 Reply Likes
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
Photo of W4EG

W4EG

  • 43 Posts
  • 6 Reply Likes
Great analyses ... Thanks :)
Photo of Ken - NM9P

Ken - NM9P

  • 4239 Posts
  • 1351 Reply Likes
Excellent discussion, everyone! I love the thought of customizable, exportable, selectable rig profiles. Keep dreaming those ideas!
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1057 Posts
  • 1097 Reply Likes
Persistence data will be stored in the radio so that you can move between clients and have the same experience
Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1571 Posts
  • 772 Reply Likes
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
Photo of Steve K9ZW

Steve K9ZW, Elmer

  • 1571 Posts
  • 772 Reply Likes
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
Photo of Steve - N5AC

Steve - N5AC, VP Engineering / CTO

  • 1057 Posts
  • 1097 Reply Likes
This is the current plan, Steve
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9198 Posts
  • 3558 Reply Likes
Official Response
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

This conversation is no longer open for comments or replies.