band change persistence ...

  • 1
  • Question
  • Updated 3 years ago
  • (Edited)
I believe this is a change incorporated in v1.6.21.77, and surely a change to facilitate the needs of contesters. However, I am finding it annoying enough to write this post. I am not a contester and most likely have requirements others do not. And so it goes .. 

I have included a screen-shot of four unique bands, but the same behaviors occur with just two. Scenario - I usually set the top panadapter to display the 15-meter AM window only. A narrow band of ~30khz. The bottom panadapter window displays the entire 15-meter band. I monitor the top window for activity, but usually bandswitch the bottom window to check propagation on multiple bands. Let's assume I am using a 6300 with two slices. (I am using a 6500).

I bandswitch the bottom panadapter to 17-meters, perhaps look at 20-meters too, and then back to my 15-meter spectrum. Now, with this new release, I no longer have my full 15-meter spectrum view as I did before, but essentially a copy of the top window. Indeed, if I had initially selected a different mode for the bottom panadapter, the new instance inherits the mode and scale of the top panadapter. I can see contesters wanting this behavior, but in this context it is not beneficial. 

Creating a new panadapter when one exists for that band, I have no issue with creating a duplicate instance. However, once changed, I would have preferred to have the mode and scale persist thru bandswitching on that panadapter.

I am sure this used to work differently, though I might be missing something.

Comments?

W7NGA  dan
San Juan Island, Wa. 


Photo of W7NGA

W7NGA

  • 445 Posts
  • 189 Reply Likes

Posted 3 years ago

  • 1
Photo of W7NGA

W7NGA

  • 445 Posts
  • 189 Reply Likes
I have also noticed that if I load a global profile, as I did on the first image, if I bandswitch the 15-meter window and return to 15-meters, it can have a different mode and scale that I can only relate to something set previous to this profile being loaded. It will not be what was set initially. Not expected.
Photo of W7NGA

W7NGA

  • 445 Posts
  • 189 Reply Likes
I am pleased to report that after rebooting my 6500 this impertinent behaviour has vanished.
Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
OK, I'll accept that this is my error. What problem was it you were reporting?
Photo of W7NGA

W7NGA

  • 445 Posts
  • 189 Reply Likes
Basically, set up a panadapter on a band, bandswitch to another band, return to the original band to find that the mode, display width, bandwidth all changed to something different. If another panadapter was open to that same band it seemed to inherit those values. Rebooting has restored a predictable behaviour that makes sense.
Photo of W7NGA

W7NGA

  • 445 Posts
  • 189 Reply Likes
Yes, something is definitely wrong here but I cannot identify a repeatable series of events that leads to the problem. Here is something new ... take note of the slice frequency versus the display frequency scale at the bottom of the window. They do not match!

Photo of Walt - KZ1F

Walt - KZ1F

  • 3040 Posts
  • 645 Reply Likes
Just out of curiosity, which frequency is correct?

It's missing the side pointers to the other, in that case A, slice. Slices are assigned 0->n. The fact that is your B slice means the A slice is missing. Well, you originally were given an A slice. You added a B slice. You could have deleted the A slice, leaving only B slice. Where you selected band and changed to either 40 or 20... I am guessing you were on 20 and selected 40, it gave you a pan moved to 40 but left the slice alone, meaning it remained on 20. If it is trying to preserve the original slice, this would all make sense.

It could 'push' the original slice, give you a new one on 40 then pop the slice off if you returned to 20. That would be problematic though. I think it would make more sense to just reset to an A slice on the new band. But then I am not designing ssdr.
(Edited)