Profile Corruption from 3rd Party Applications

  • 2
  • Question
  • Updated 3 years ago
  • (Edited)
I'm a bit frustrated.  Please read this post in that light. 


I've been using 3 different clients to access my 6300.  I'm using SmartSDR, Dog Park SDR, and K6TU Remote.  It would appear that the proper methodology to create, use, save Signature Series profiles (Mic, Transmit, and Global):  
  1. Has not been communicated properly to the 3rd Party application developers 
  2. Does not work via the API outside of SmartSDR
  3. Can only work correctly in SmartSDR because there are other required functions or methods used by Flex Radio which are not part of the published API.
  4. *This users ability to operate the 3 applications appropriately
I am in hope that number 4 is the likely culprit, however I feel it may be one or a combination of 1-3 are at play (my vanity run amok).

When operating the radio after a Factory Reset-Database Reset, all applications function correctly.  After time and use creating/deleting/changing profiles through either Dog Park SDR or K6TU Remote things go south.   The general indication is that upon start up, the user is unable to change bands.  Attempting to do so causes the active slice to disappear and the radio becomes unresponsive.  These symptoms remain until a Database Reset is performed again, removing all customized or newly created profiles.  Once the symptoms show up on one client, they exhibit on all (SmartSDR, DogParkSDR, and K6TU Remote).
If this is not user error, the use of 3rd party clients is untenable.  Unless it is fixed, I won't be paying for any new updates or buying transmit licenses.    Dog Park Software and K6TU need to work with Flex Radio software engineering to share ideas on how to irradiate this issue as it affects all 3.


I would recommend that Flex Radio adds a new attribute to the profile database which identifies the profile as belonging to a specific client (SmartSDR, DogParkSDR, K6TU or any other).   This will allow the developer to segregated and filtered profiles created by their own product from being used by and corrupted by other developer's products.

I am using:
  • SmartSDR 1.6.21
  • DogParkSDR 1.02 (build 19)
  • K6TU Remote (current version, IOS not reporting an update available)
Again, if this is "user error" my most humble apologies.  Show me the errors of my ways and I'll be a happy camper.  I have been dealing with this problem for 6 months or more and have not able to find the secret sauce which makes these applications live happily with each other.
 
Photo of Jay -- N0FB

Jay -- N0FB, Elmer

  • 535 Posts
  • 212 Reply Likes

Posted 3 years ago

  • 2
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
Alas this issue isn't so straight forward as to defer profile changes to the user.

Let's start with the fact that the radio is a super set of capabilities supported by the sets of current clients.
  • SmartSDR (Windows) is the gold standard and exposes all the features in a specific radio
  • dogParkSDR & K6TU Remote support different subsets of the radio capabilities
  • SmartSDR (Maestro) will support a subset of the features (for example, less slices, maximum 2 pan adaptors etc).
At present SmartSDR doesn't load a "default" profile for itself when it starts.  No surprise here - the assumption when it was written was "what other client?" so it assumes that the state of the radio is as it was last left when SmartSDR (Windows) was quit by the user.

This assumption is no longer the case - the radio could be in any state (or not) left by the previous set of clients run since client A was last run.

You have a combination of:
  1. Persistence
  2. Profiles (global, transmit and mic)
  3. Client capabilities
  4. Client stored state (window positions, pan layout etc)
The reason for the named client profiles was an effort on my part (which Don "inherited") to be able to prevent a different user experience when running the iPad client after running SmartSDR WITHIN THE CONSTRAINTS OF THE DEVICE/APP.

For example, you last had SmartSDR running with 8 pans and 8 slices - you quit and sometime later run the iPad client.  The iPad supports (my choice - I wrote it) ONE pan adaptor and a maximum of two slices.  If I connect to the radio and set myself as the GUI client, the radio recreates what was last open - I have no choice but to simply close out the pans/slices I don't support.

Further, there are some aspects of the client that are in fact stored in the radio - for example, the color gain, black level setting, auto black settings for the waterfall, mode selected step size for tuning etc are ALL client managed but the radio is used to store their state so that if you run SmartSDR on two different computers, you get the same experience on both without any change on your part.

Persistence is yet another layer of complexity overlaid on profiles...  without consulting a manual or spreadsheet, what radio settings are persisted, which are over written by profile state etc?  No so easy is it?

I designed the iPad client with ease of use and an iPad like experience in my mind.  I wanted something that was streamlined, easy to use and with a clean layout.  As you can see, I chose in the current version not to expose profiles at all but rather to have a single global/transmit profile that recreates the experience with continuity from the last time you used it.  That was my expectation and was clearly communicate from the 20+ alpha testers who have a ton of valuable feedback and in some cases, outright rejection of my ideas (we won't go into how control presentment changed as a result - enough to say the alpha-testers made this a MUCH better experience!).

So it was my choice based on the design/feedback from the testers to make sure that the state was saved when the app exited and to use profiles as a way of addressing the client capabilities challenge.  I'm sure that over time this aspect of operation will get revisited as FlexRadio adds additional capabilities to the radio and the API.

In closing this longer than intended response, both persistence and the state stored in profiles are opaque to the different clients until you start the radio, set the client state (GUI or no GUI) and  then observe what the radio fires at you.  Ditto for profiles - want to know what's in one?  Load it and see.

FlexRadio hasn't yet exposed the export file format of the profiles from the radio and (hint - its not XML) I don't intended to reverse engineer it.  For now, the solution will remain having the client save its own profile when it exits.

You can be certain that I have had many discussions with the guys at FRS about this - they understand, they are amazingly open and understanding but they have a priority list driven by their own product development and product needs.

Progress is incremental and forward!

Stu K6TU

PS: In closing, if folks don't subscribe to the K6TU Remote or K6TU Control apps, how many future releases do you think I will be motivated to develop?  Only slightly :-) - I have many other things I can think about applying that development time and effort to that would improve my contesting and personal radio pleasure.   At the end of the day, if I had not wanted the app for my own personal operating, it would never have been developed.  

Just saying - thought provoking not intended to be confrontational...  With the unique capabilities of the FlexRadio, the apps are constrained to FlexRadio owners - even at 100% adoption, it wouldn't be an (even distant!) alternative to the day job!
Photo of Stu Phillips - K6TU

Stu Phillips - K6TU, Elmer

  • 642 Posts
  • 256 Reply Likes
Well, the STANDARD will get set by FlexRadio when they have the cycles and the need to remove this issue.

In the meantime, we will all do as best we can.  

The process of swapping profiles is one that takes time - typically 2 to 3 seconds before the radio issues the completed response.  I've not been able to screw things up when using the standard operating procedure of disconnecting the iPad app via the Disconnect button.

If that isn't working for you, I'd love to know and help you capture a trace to help me debug the problem.

To be clear to everyone, this is not an issue of CORRUPTION - the profile information does not get corrupt.  what is happening is that the process of using one or other clients is not restoring or recovering the profile you expected.

The client specific profiles for both dogparkSDR and the K6TU Remote clients are deliberate in their behavior and save the current state of the radio in their own profiles.

If you mistakenly use one of these profiles with SmartSDR then you will not get what you expected.

I'm done and signing off this thread.  Time to get ready for the next contest!

Stu K6TU
Photo of Jay -- N0FB

Jay -- N0FB, Elmer

  • 535 Posts
  • 212 Reply Likes
I am going to flatly disagree with you Stu.  Corruption of something is occurring.  When the 3rd Party application clobbers the profile, there is nothing I can do other than do a factory reset to fix the problem.  SmartSDR will come up with a panadapter with no slice on the last band utilized. Deleting or re-saving profiles will not fix the problem.  The Band Buttons are disabled and do not function, therefore you can not select any other band to operate from.  Only performing the aforementioned factory reset on the radio fixes the issue.  The user must then reload or rebuild any profiles.  A real PIA!

I'm signing out of this thread.  You, Don and Steve can figure out what the right tact is.  I know that this is not a near term fix. There are a lot of other higher priority issues in the pipe:  Finalizing Maestro, WAN, and station automation.  I just want this is to remain on someone's list for to receive some programmer's TLC when there are some unused cycles available.
(Edited)
Photo of Don Agro

Don Agro

  • 123 Posts
  • 72 Reply Likes
Steps to reproduce this reliably would certainly be a help since I have not been able to reproduce this even once with dogparkSDR and SmartSDR. Also, shouldn't this be a help ticket ?
Photo of Jay -- N0FB

Jay -- N0FB, Elmer

  • 535 Posts
  • 212 Reply Likes
It should be help ticket indeed.  I already planned on calling Flex as they did not chime in here on the thread.   I'll endeavour to provide you and Stu a set of reproducible steps to document the problem.
(Edited)
Photo of Don Agro

Don Agro

  • 123 Posts
  • 72 Reply Likes
Thanks Jay, being able to reproduce the problem reliably in a few steps should help point us all in the right direction.