Possible Favorites Bug

[RadioSDR1]

Does anyone know whether or not it is expected behavior for Favorites to not work correctly if the DSP Panel is not displayed when switching between Favorites?

The trouble I am observing is if the DSP Panel is not displayed and I switch between one Favorite to another, is that it “remembers” the mode and sometimes the frequency of the previous Favorite.

For example, suppose you start SDR Console with the DSP Panel open and then select a Favorite configured for LSB at some frequency in the 40m band. Now close the DSP Panel and select another Favorite configured for USB at some frequency in the 20m band.

Initially, the frequency, waterfall, and mode will change as expected. However, if you change frequency, there are two scenarios of dysfunction depending on how you change frequency.

The first scenario is suppose you first click on the title bar of SDR Console so as to bring the window into focus so that you can change frequency with the arrow keys. The moment you hit the arrow key, the mode and frequency will revert back to that of the previously used Favorite but the waterfall will stay in the correct frequency range.

The second scenario is suppose you instead immediately click on the waterfall to change frequency. In this scenario, the frequency will change as expected but the mode will revert back to that of the previously used Favorite. Also, if you hold down the CTRL key to manually enter a frequency change, the same thing will happen.

Neither of the above described scenarios will occur and Favorites will work as expected if the DSP Panel is simply open when switching between Favorites.

I am not sure if this observed behavior is a user error and/or misunderstanding, an SDR Console bug, an SDR Console feature , or some upstream programming constraint imposed by Micro$oft Windows.

[Max]

For example, suppose you start SDR Console with the DSP Panel open and then select a Favorite configured for LSB at some frequency in the 40m band. Now close the DSP Panel and select another Favorite configured for USB at some frequency in the 20m band.

Initially, the frequency, waterfall, and mode will change as expected. However, if you change frequency, there are two scenarios of dysfunction depending on how you change frequency.

I've tried to emulate this for each of the scenarios you have described and I cannot get it to behave other than normally and predictably. Odd one. Try a re-install or a reset perhaps?

https://www.sdr-radio.com/reset

Max

[RadioSDR1]

Hey Max. Really appreciate you trying to recreate this.

So I went back to test this again and eventually found there may be an additional variable which is whether or not the DSP Panel was in a docked or floating state when closed.

If it is in a docked state when closed, then this issue does not appear to be a problem (though I thought it happened whether docked or floating). Anyway, I am able to recreate the problem for sure if the DSP Panel is in a floating state and then closed.

And it may well be the DSP Panel when docked could be a problem too but if it is, there must be some other dependency I am missing. I'll play around some more. But so far and again when floating and closed in that state, it seems to be a problem. FYI also tested this in a new empty identity and still an issue there too. Though I did not do a reset, I'm a little afraid of losing my config. I do have SDRC installed on a PC that I seldom use so I could fire that up and test there if need be.

If you get a chance to retest with closing the DSP Panel in a floating state, let me know how it goes if you could. My confidence (at least at the moment) that this is a problem is high though there may be some dependencies I am missing.

Thanks!

[Max]

Hey Max. Really appreciate you trying to recreate this.

If it is in a docked state when closed, then this issue does not appear to be a problem (though I thought it happened whether docked or floating). Anyway, I am able to recreate the problem for sure if the DSP Panel is in a floating state and then closed.

Thanks!

OK. Good catch! Now I see exactly what you explained. So, hope you do not mind if I bullet point it for Simon to assess the behaviour quickly:

1: With RX DSP panel floating, select a favourite. Note the selected mode

2: Close the floating RX DSP panel

3: Select new favourite that recalls a different mode. The mode recalls from the favourite as expected, but then.........

4: Click anywhere in the waterfall to commence tuning, and the mode jumps back to the mode selected prior to closing the RX DSP panel.

5: None of this happens if, in stage (1) the DSP panel is in docked mode.

Cannot figure out a logic to this but no doubt Simon will see it immediately!

73

Max

[RadioSDR1]

Whew! It's embarrassing to post an issue somebody can't recreate!

FYI...I've played around even more and have experienced the problem with the DSP Panel closed in a docked state but have been unable to intentionally recreate it. However, the couple times it happened, I found when reopening the DSP Panel that it was in a floating state even though it was closed in a docked state. Anyway take this additional report with a grain of salt as I have been unable, so far, to make it happen on purpose. Though it seems it might be triggered, somehow, after some yet to be discovered magical cocktail of selecting various Favorites where the Favorites are in different modes like BC-FM to USB to SAM, etc.

Go head and bullet-point away!

P.S. I don't know if you have ever tried reproducing the Noise Reduction 4 bug I reported over the summer that occurs when switching between many (but not all) modes. This one drives me nuts because every time I switch between FM to AM or to USB/LSB, I have to change a setting on NR4 and then put it back in order to quiet the waterfall garble sound down. In fact, my recent exploration of the Favorites feature lead to me finding this Favorites quirk/bug because with a Favorite it remembers Noise Reduction settings so as a workaround to the NR4 issue I now have Favorites with slightly different NR4 settings for each mode (or for the modes that cause a problem because not all do). Had it not been for the NR4 problem, I probably would not have explored Favorites. Just wanted to toss that out there in case you feel frisky reproducing that one should doing so have some influence with Simon.

Thanks a ton!!!

[Max]

.......every time I switch between FM to AM or to USB/LSB, I have to change a setting on NR4 and then put it back in order to quiet the waterfall garble sound down. In fact, my recent exploration of the Favorites feature lead to me finding this Favorites quirk/bug because with a Favorite it remembers Noise Reduction settings so as a workaround to the NR4 issue I now have Favorites with slightly different NR4 settings for each mode (or for the modes that cause a problem because not all do).

No problem. Will try and take a look later. Always short of time but will give it a go when I get a spare moment!

73

Max

[jdow]

If the DSP panel is closed and not merely hidden there probably is no way to pull settings out of it. "It's in the middle drawer of my desk!" "Wait, what? You don't have a middle drawer in your desk. There is only a hole where you pulled it out."

{^_-}

[RadioSDR1]

@Joanne. Ya, well, the observational evidence suggests the state of the DSP Panel when closed does in fact govern the aforementioned behavior of the Favorites function. It is a counterintuitive assertion I make.

Perhaps the real bug is that the DSP Panel is not really "closed" when one closes it in a floating state. If that is what is really happening, then the true nature of the bug would be why does the DSP Panel appear to close but doesn't really.

Nonetheless, Max said he duplicated it. Are you doubting Max???? Or just the precise nature of the problem?

[jdow]

This sort of problem happens when windows and their sub-elements are closed in the wrong order. This can easily happen when windows are floating vs docked when the program closes. At any rate that is where I would look for the error were I Simon.

Window B is opened by (or owned by) Window A. Window B opens C which the user makes a floating window. Normally closing A would call a save state function in B which would do the same for C. But if C is divorced from B as it is floated then C would never get its save state call and would simply close, with or without divots for the OS to clean up. If that is clear enough you and Max should be able to verify this AND Simon might be able to find the bug much easier. You've been doing that. It's good. I was simply noting where I'd seen it before. That is why I suspect some of the bugs you are reporting are all related. The Microsoft Foundation Classes, which Simon says he recreated rather than used directly, have save state/load state functions that are separate from open and close functions. And that says nothing about show and hide window functions which can confuse users and rushed programmers who want to make sure the save state and close window functions are called once when the program closes.

{^_^}

[RadioSDR1]

@Joanne. I defer to your software engineering knowledge with your theory which is way more than mine. And your theory certainly sounds plausible as stated. If that stimulates some thinking for Simon that saves him some time, all the better.

If I have your ear for a moment Joanne, any theory on what's behind the NR4 issue I reported awhile back?

Just to recap briefly, if you turn on NR4, it's great. Then suppose you change mode from say LSB to SAM. You get noise in the form of a garbled water sound. Simply changing any of the three slider settings and putting it right back to where it was originally (or leaving it changed) gets rid of the noise. This problem started with the update to NR4 last summer which actually was a major improvement overall except for this little nuisance. Note that changing from some modes does not create a problem such as from LSB to USB or AM to SAM. But changing from LSB to Wide-L or AM to FM does trigger the problem.

One anecdotal commonality I noticed recently but have not yet reported until now is that if changing to a mode that shares the same Step setting, then there's no issue. For example, there's one shared Step setting for LSB and USB and another shared Step for SAM and AM. But there's a separate Step setting available for both Wide-L and Wide-U therefore the problem would be triggered by going from LSB to Wide-L. So again it seems changing to a mode that shares the same Step setting isn't a problem. But changing to a mode that has its own Step setting is a problem.

Not sure if that Step observation is a coincidence or a clue. Anyway, if you have any ideas that could be translated and expressed in engineer's speak that might pique Simon's interest, have at it.