Profile Corruption from 3rd Party Applications

Jay -- N0FB

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.
 

Rob N4GA

John. Good posts, good observations. Not sure "irradiate" ing the parties involved will do much..

Ha ha

I also use DPSDR and SSDR and the profiles are broken.

Don A at DPSDR reports that they have NO control over profiles and I can clearly see that. To change a profile while using DPSDR, I have to close out, open SSDR, change the profile, then reopen DPSDR.

I get the impression the 3rd parties have issues with Flex and profile routines.

N4GA 

Rick

Jay I'd love to hear off this group how well your Flex 6300 works with the DogPark software as I've gotten very frustrated recently with WIndows and problems dating back to my upgrade to the version just before the most recent. Lots of dominos issues, some I admit I caused. It's becoming too driven by the idiosyncrasies of Windows for someone like me who is not a computer expert. Rick, W2JAZ email rjlawn at gmail dot com. 

Peter K1PGV

What Rob said. 

Unless I'm missing a major point in the API, "profiles" are an SSDR concept.  They don't exist at the API level, so third party programs can't interact with any SSDR "profile" specifically.

Third-party programs interfacing to the radio can, at their option, provide a mechanism to save the settings that relate to that program.

Whenever you have multiple programs attempting to manipulate a single object (the radio in this case) at the same time, you're going to have clashes.  How well each of the programs handle this depends on how cleverly each of the programs is written.  If you have SSDR running, and you simultaneously have a third party program change settings on the radio, SSDR is going to see this and do... whatever it does.  This can include changes that are saved in SSDR profiles.

That's simply the nature of having multiple programs both trying to control the radio at the same time.

Peter
K1PGV

Jay -- N0FB

I'm not sure that I agree with your estimation Peter.  Profiles exist in the Radio in the database.  They can and are being called for use by all three of the listed applications cited in my original post.  New profiles are being created, existing profiles are being updated and saved and even deleted by these applications.

They don't just exist in SSDR.

Stu Phillips - K6TU

The clients have the same control over profiles as SmartSDR.  The bulk of the heavy lifting is done in the radio where state information is saved or restored.

With 1.6 profiles have become inter-twined in interesting ways - a good start is to read the manual and you will see how global, transmit and mic profiles are tied together, how they also interact with persistence and not least of all, how they are linked to different modes.

I am the author of the API interface code that is used in both the K6TU Remote app as well as in Don's dogparkSDR software for OSX.  I can't speak to Don's implementation in his client but I pass him updates regularly and we have had many design discussions comparing notes.  What follows is relative to K6TU Remote.

From my own use of the application on the iPad I believe that much of the "corruption" is a result of folks not disconnecting from the radio properly.  When the K6TU Remote app starts, it checks to see if there is a K6TURemote profile in existence - if there isn't, the app creates a new Global Profile from what ever the current state is in the radio (ie loaded global, transmit and mic profiles).  It does this BEFORE making any changes.

When the app is properly disconnected from the radio via the Disconnect button, the now current state is saved for both the transmit profile and global profiles called K6TURemote.

THEN, before exiting,  the profiles that were in place when the app was initially started are restored BEFORE the app exits.  This takes some time as the app waits for the radio to signal back to the client that the profile has completed saving (then loading) before returning the user to the Radio Chooser display.

I have been guilty myself of not waiting to see the Radio Chooser reappear before hitting the lock or Home button on the iPad.  If this is done, it is possible (in fact likely) that the K6TURemote profiles are still active.

So now you go and start SmartSDR and the state in the radio is da-da! K6TURemote and not your previously used profile that you thought you had.  The only *clue* may be that you see the transmit or mic profile says K6TURemote* - the * showing the profile has a different state than the saved version of the same name.

Recovery (documented on the K6TU.NET web site) is simple (and I agree annoying) - use SmartSDR to delete the profiles (global, transmit and mic) called K6TURemote - set the radio back to where you wanted it with a stored global profile of your choice, exit SmartSDR and restart the app.

I have had MANY discussions with the folks at FlexRadio - ideally (and at some point this will hopefully hit the priority list) I have asked for a way to tell the radio to turn persistence OFF and so allow the client to handle all the state save/restoration process.

If you contest in different modes as I do (all - phone, RTTY and CW), you will find the process of setting up and maintaining the different profiles is a time consuming task that requires extensive attention to detail - I have a spreadsheet that shows the different options for each profile so that I can a) set up the radio as I want it and b) have a verification checklist to compare what I've done with what I want.

I still have times when in a contest I do something (band change, mode change etc) and suddenly find myself "not in Kansas anymore".

Hope this sheds some "irraidiance" on the situation.

Jay - if you need specific help, I'm just an email away - the app hasn't been out for 6 months other than for the Alpha testers just FYI.

I'm sorry you are frustrated - a couple of emails would have cleared this up for you a long time past.

Stu K6TU

Peter K1PGV

Ah!! My bad. Sorry for propagating my own misunderstanding. And thanks for the definitive explanation!

Jay -- N0FB

Thanks Stu for your prompt reply.   

Yes gang...I didn't catch a spelling mistake on the word irradiated...it should have read eradicated.   Auto-Correct happens....Let's move on.

I guess I wonder why you would automatically "Save" profiles upon exit your applet.  I would rather have explicit control of when a profile is saved.   These profiles, at least in my mind, are a starting point during the operating session.   I will make many tactical changes to settings as required by the conditions.  I don't necessarily want these changes to become of the profile (even the default) from what I set up originally.  If the changes are to be incorporated, I want to manage it myself.  It would seem that your tactic of always saving at the end of a "correctly terminated session" ensures that an unintended but corrupted default profile will always start up on the next session.

You know you business better than I.  Just a possible other tact would be to create a set of default profiles which provides a steady state and then never allow them to be changed (at least in your App).  Manage the profiles last used by K6TU Remote by writing the profile names to a file on the IPad and then calling those profiles on Remote startup.  If those profiles becomes corrupt, the user can then change to your pristine "default" profiles and start over with a known steady state.  I know, at least at this time, you can't prevent other client programs from changing settings in a profile created by K6TU Remote...even to the K6TURemote profile.  That's a problem for Flex Radio to fix.

I will definitely reach out to you on E-Mail for further assistance on this.  Alas other developers of new clients such as on Linux or other OS's will have the same issues you have encountered.   This is why I felt the Community to be the appropriate venue to bring up this problem.   Part of the problem must be fixed by Flex Radio and it is having an affect on their customers whether they choose to use SSDR or a 3rd party app like yours.

Again...thanks for your response.  What you have accomplished already is very impressive and has added to my enjoyment of my 6300.  Thank you!  

I hope a response might be offered by both Don Argo from Dog Park and Flex Radio engineering on the issue.

Don Agro

dogparkSDR has no direct control over the contents of any profile. It can create, delete and load a profile by name.

When it connects to the radio dogparkSDR will load the named profiles it last used.

Before it disconnects from the radio dogparkSDR will save the named profiles in use.

In the preferences dogparkSDR allows you to save a named profile, create a new named profile or delete a named profile.

In all cases dogparkSDR waits till the radio is finished performing any of the above.

Jay -- N0FB

Hi Don.  Many thanks for your efforts.  Again, I would much rather have control over when settings are being saved to a named profile.  I do not want a profile to save on its own on shut down.  Here's why:

After start up of DPSDR or SSDR, I'll select a profile to match with my intended mode of operation.  During that session, I'll make many tactical changes to settings to suit the conditions I'm working in at that time.   If I were to simply exit DogParkSDR, you are going to overwrite the profile, as if I wanted all of those tactical changes to become permanent in that profile.  I do not.   I want to be able to return to the profile the way I set it.  If I want to make changes to the profile, I'll make the manual changes and then save it to the profile myself.

Does this explanation help?  Is it reasonable?

Thanks again Don for adding native OSX control of my 6300 (along with Stu).  Big fan of both pieces of software.

Don Agro

Your explanation helps and it makes sense but typically modern Mac applications save state automatically without the user having to explicitly request a save. Perhaps this is a situation where you would want to create a new profile for transient changes that won't be saved into your reference profile ? Remember dogparkSDR will load the last profile that it used not the last profile that SmartSDR used.

Jay -- N0FB

I understand why a OSX Application would typically save on exit, however, this is not a homogenous environment.  This is decidedly a heterogenous environment from a Radio Client standpoint.  You have folks like me who utilize SmartSDR, K6TU Remote and Dog Park SDR depending on how I feel or the needs of the individual session.

Again, I would recommend that the active profile not be saved on exit.  If upon startup of a new session DogParkSDR calls the last used profile, I'm completely fine that it doesn't contain any of the tactical changes I made on my last session.  The profile selected is just the starting point for my session.  I would much rather control myself when something is going to be save to a profile I worked hard to get it just the way I wanted it.

Thanks again Don for your consideration.  73

Don Agro

If you create different profiles for different clients then they will not interfere with each other and saving the dogparkSDR state will not affect your SmartSDR Profiles.

Stu Phillips - K6TU

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!

Don Agro

As the profiles in the radio and API evolve to better support multi-client environments dogparkSDR will attempt to take full advantage of the changes.

Jay -- N0FB

Hi Stu, thanks again for the great post with such valuable information.  I fully understand that both K6TU and DogParkSDR are "Labor of Love" projects for you and Don.  I also understand that you and Don are not going to get rich off of either of these products.  Lastly, I under that the final solution of 3rd Party applications corrupting is not going to be solved by K6TU, DogParkSoftware, or frankly by Flex Radio.  

Profile corruption by 3rd Party applications is a real problem.  It can only be remedied when all of the 3rd Party work in conjunction with Flex Radio to come up with a STANDARD for creating, updating, and deleting profiles.  This should include when and how to perform the requisite functions.  All 3rd party developers must, from that point, adhere to this standard methodology so that they don't step on each other's profiles.  Only then will this become a non-issue.  This is why i created this thread to point out that all 3 of your companies (plus others that I don't know about) have a shared issue which needs to be addressed.

The only means that a customer has to affect change is to advise the developer of an issue, word of mouth of how the developer reacts and responds to customer issues, and finally with the power of the purse.

As a workaround, I can certainly create my own profiles for each specific Signature Series client I plan to use. I will then need to be extra vigilant on selecting the profile(s) specifically created for that client.  It is an axiom of GUI development to display only valid selections to the user.  It is almost always considered bad form to display a control which is populated with invalid selections.

You both have my deepest appreciation and awe for your programming prowess.

N0FB - QRT

Stu Phillips - K6TU

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 **** 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

Jay -- N0FB

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.

Don Agro

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 ?

Jay -- N0FB

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.

Don Agro

Thanks Jay, being able to reproduce the problem reliably in a few steps should help point us all in the right direction.

Eric-KE5DTO

I think there are multiple issues on the table here.  First, Jay's problem (subject of this post): The fastest way to get a resolution on this type of issue is to document the steps necessary to reproduce the problem.

If SmartSDR will load once the problem happens, then you may be able to open SmartSDR and Export the Profiles/Preferences and send them our way.  Short of this kind of information, it is tough to nail down what the problem may be.


Second, there is an ongoing architecture question about how Profiles work and how 3rd party applications should interact with them.  This is an issue that will be handled on a priority basis.  The more of you that have this problem and raise your hand, the higher the priority.

It is an unfortunate reality that there are many more things we would like to do than we can actually accomplish in any given amount of time, so it is necessary to prioritize the things we work on.  There are many factors that go into this priority: number of users affected, severity of the issue (is it a minor annoyance with an easy workaround or does it brick the radio?), alignment with business priorities, etc.  

Take it from me that prioritizing the defects that come across our inboxes is no simple task.  Nor a quick one.  We have a multi-hour weekly meeting with a process for handling this and it is painful.  There are few things more debilitating than talking for hours about all the things that are broken or that could be better in the products that we pour our hearts and souls into.  Yet we consider it necessary to maintain the level of excellence that our customers expect of us.  At the end of the day, this is what matters.

We care about you - our customers - and want to hear about the issues that keep you from having a great time using our products.  Please tell us about them!  We consider our customers like our family.  If you aren't satisfied, then neither are we.  We can't fix something we aren't aware of, so please, by all means -- communicate with us!

Please be patient with us as we address issues as best we can given priority and resource constraints.  We don't rush out fixes because we have found this just creates more problems.  We talk through solutions, implement them, test and then peer code review them before releasing Alpha versions for folks to beat up.  It is a time consuming process, but it ensures the quality that you are counting on from us.

If you just heard "blah blah blah", then what I'd love for you to take away from this is:

We care.  Tell us about the things that bother you.  We can't promise immediate fixes for everything, but we promise that we are listening and will do our best to deliver the best experience possible.  And we will have fun doing it!

Bob G W1GLV

right on Eric. I like the way you guys handle a problem.

DrTeeth

@ Bob, definitely agree with you on that one. Stu's posts are also very informative and his level of support excellent. It almost makes me want to buy an iPad, LOLZ ;-). The only Apples in this house come from trees.

Jay -- N0FB

Eric, thank you for your response. It is well taken.  

The intent of my original posting is to point out that each developer is "doing things their own way" when it comes to Profiles. This can sometimes lead to poor interoperability between platforms as is illustrated by my post.

In my previous life, I built and supported cross platform applications and development environments (Mac/Windows).  It is always tempting for a developer, who lives in a platform specific silo, to think "the way that I do things is right" and/or "If this causes a problem for the other platform, what do I care?  That's their problem."   I am not in anyway saying that Stu or Don have taken this tact. Quite the opposite.  They have been exemplary. I'm saying that without direction, it is understandable that each developer will go on their own tangent.

As Flex Radio is the ultimate owner of the development environment, it should dictate (without being dictatorial) how a well mannered client application should work certain portions of their product....no matter the platform of the client.   By doing so, all client platforms enjoy harmonious interoperability.  This means less frustration and greater satisfaction overall for the customer.  This ultimately creates higher profits for Flex and the 3rd Party developers. 

I fully understand that there are some very high priority development work on your plate which directly affect the bottom-line (Maestro, WAN, Station Device Interoperability).  My post was to raise the awareness of not only the 3rd Party developers, but Flex Radio.  I see this as an issue of fully communicating vision and architectural direction more than it is a request for Flex Radio Development / Developer cycles.  Flex Radio, while taking in consideration the challenges of the 3rd Party Developers, should define how this subsystem is intended to work and how development for profiles should be approached.

Thanks again for your response.  Please see my posting as my hand being raised and held high.

Eric-KE5DTO

We agree.  This is in no way directed at Stu or Don, but in the absence of good docs, developers can get VERY creative.    We have a strong working relationship with both of these guys and they are both talented developers.  I'm confident we will come up with a solution that works for all parties involved.

Stu Phillips - K6TU

Necessity is the mother of invention or put another way, where the is a will, there is a way!

:-)

Stu K6TU