Fixed Bandstack Register code

Hi All,

The ui-enhance branch of the code has a fix for the BSR issue, which fixes the precision of frequency, mode, and filter selection. I also fixed up the band tab shortcuts, which now match those listed in the manual.

For those of you compiling your own code (linux users mainly), you may try this out right now:
git clone https://gitlab.com/eliggett/wfview.git -b ui-enhance

For everyone else, I’ve made a merge request to the master branch, and we should have some built binaries out on our Downloads page in the next few days.

Commit logs in case you’re interested:
https://gitlab.com/eliggett/wfview/-/commits/ui-enhance

73, and have a good weekend,

–E
de W6EL

Thank you, Elliott! I will await the Windows 10 build, and I am continually amazed at the stability of the test release!

One small item to put on the ‘sometime in the future list’: can a ‘decay’ feature be added, maybe with a time parameter, to the Peak display in the Spectrum scope? It seems to continue to add to the point that it is much greater than recent signals and is a bit misleading. Also, what is the scale for the Spectrum display. It seems that it shows the 7300s 0 to 80 db in a range of 0 to 150 somethings?

Much appreciate your effort and will look for the next W10 build release.

Hi Dave,

The current code simply compares the latest value to the highest received. If the latest value is higher, then that value replaces the older highest value. In this way, it holds the highest received until either the scope moves over or the user presses Clear Peaks. When my AC fan comes on, there is a nasty hash that sweeps entirely across 40 meters, and basically the entire “peak” plot goes to half-scale… So I hear you, not always useful.

There is a lot of interest in a decay feature, and it is something you can expect in the next release (or sooner). We might add some adjustments for the decay time or “mode”. I’d actually like to see what we do on the S-Meter on the plot, which is an average of so many seconds of data, plus the peak from that same set. I guess we’ll have to try it to see how cool it is. We’re also looking at adding overlays to show markers of stored points, passband, and maybe dx clusters!

Thanks,

–E
de W6EL

Sounds like it is under control, Elliott, and I will await future addressing of this. Very good! I find myself ‘Clearing Peaks’ somewhat frequently. Overlays sound potentially useful!

Thanks again! You folks do very good work!

note that I keep master also in sync if we deem a feature/change to be stable.

The BSR fix is also in.

Was this included in the 2021-05-07 Windows Test Build? I downloaded it and, although the frequencies now appear correct when I change via the BSRs, the mode is still incorrect if I switch from a LSB band to an USB band or vice versa. For example: I am on 40m/LSB. I switch to 20m. It stays LSB even though if I would have switched directly on the 7300 it would have been USB. I change it to USB, either on the radio or via wfview and switch back to 40m on wfview. It stays in USB. I change it to LSB and switch to 20m. 20m is still USB this time but if I switch again to 40m, it is also USB.

Let me know if I can provide any more information or try anything else.

Thanks,

Hi Dave,

I would think that the fix would be in, but then again, our windows builds take place across the pond, so sometimes a date can mean a different thing between there and here.

One posibility is that the rig is responding correctly but that the wfview interface is showing the wrong mode. Can you try your experiment (going from 20-40 meters using the BSRs and expecting USB/LSB changes) while watching the face plate of the rig, to see if the rig is changing modes?

Thanks,

–E
de W6EL

Sure, Elliott. The rig is echoing what wfview shows - incorrect mode. Curiously, the frequency fix seems to be included in the build.

It is acting as though, when it is changing bands and saving the current values before switching, it is not overriding the Mode with the one associated with the new selection. Does it mirror the band registers entirely outside of the rig or does it rely on the rig’s registers?

Hi Dave,

The flow of the program is as follows:

  1. Read the BSR from the rig, including frequency, mode, data mode status, and selected filter

  2. Update the UI to the mode and filter selected

  3. Command the rig’s frequency

  4. Command the rig’s mode

  5. Command the rig’s filter

  6. Command the Data mode ON or OFF

  7. Query the rig for current frequency (sync UI to current rig selection)

  8. Query the rig for the current mode, data, and filter (sync UI to current rig selection)
    So in theory, it should work… and it seems to on my end with my IC-7300. I’ll have to ask Phil if the latest windows build has all the fixes in it or not, because I did make two separate commits for this issue, one for frequency and one for mode.

Hopefully we get this straightened out soon.

Thanks,

–E
de W6EL

I’m betting on that the frequency fix was included but the mode fix was not.

Thanks, Elliott.

The fix is in, Elliott! BSR all seems working well now. Using the 2021-05-09 Windows build on my 7300.

Thanks!

Hi Dave,

Glad it worked!

–E
de W6EL

I spoke a bit too soon, Elliott. In general, the BSR starts out working and selecting the correct frequency and mode, but sometimes, if I don’t touch the radio but do everything via wfview, I see this:
If I simply change bands via the BSR buttons, all is fine. However, if I alter the frequency in a band with double-click in the spectrum display and fine-tune with the mouse wheel, then select another band, sometimes the radio and spectrum display will show the new band and frequency, but the frequency display in the lower-left of the wfview screen shows the old frequency on the previous band. If I click the same band select button again, it catches up and shows the correct frequency, so it seems to miss getting an update sometimes on BSR change. Also, if I continue changing bands with the BSR buttons, at some point it does not remember the frequency I have tuned to, and instead goes to a previous frequency for that band. This behavior remains until I restart wfview.

Let me know if you need more info.

Thanks,
Dave

Even if I restart, it seems to forget where I have been on other bands, and returns me to previous frequencies - not the ones I last used on the band.

Hi Dave,

I’ll look into it. We have pretty solid code for changing frequencies and modes, so this sure is baffling.

Thanks,

–E
de W6EL

Please try it yourself on a 7300, if possible. Change bands, tune around, change bands…
I hope you can see the behavior.

Hi Dave,

Ok, got the 7300 connected and what I am seeing, is that I can toggle between different bands (using the band buttons on the band tab), and I see wfview correctly parsing the BSR data and switching modes/frequencies accordingly. I did it over and over, it seems correct.

Then I thought I’d start altering things. And this is where I saw unexpected behavior. If I specified a frequency on 40 meters and a mode, I expect that if I jump to 20 meters and then back to 40, I would end up right where I left off on 40 meters. But it seems like the rig BSR isn’t being updated. I end up right back where I was at the beginning of the testing, before I made changes to the operating frequency and mode.

Really not sure what to make of that.

Anyone else seeing unusual behavior?

Thanks,

–E
de W6EL