Flexcontrol - superscrolling

  • 1
  • Problem
  • Updated 4 years ago
  • In Progress
  • (Edited)
I have disabled, rather than reducing, my com port buffers.

I was playing around with my Flex 6300 as a general coverage receiver and was spinning the Flexcontrol quite rapidly to change frequency within a reasonably short period. The tuning would continue for many MHz after the Fcontrol had stopped being used and I could not even stop it.

Is there any way to stop this excessive scrolling other than to stop using the Flexcontrol?

I even managed to get SSDR to read a negative frequency and could not get it to go above 0 Hz again.

Mni Tnx and HNY to all

Photo of Guy G4DWV/4X1LT

Guy G4DWV/4X1LT

  • 1687 Posts
  • 387 Reply Likes
  • festive and optimistic

Posted 4 years ago

  • 1
Photo of Tim - W4TME

Tim - W4TME, Customer Experience Manager

  • 9130 Posts
  • 3453 Reply Likes
Official Response
We have modified the adaptive accelerated tuning algorithm in the next version of SmartSDR.  However, your problem sounds like issues with the USB port the FlexControl is connected to.  

When you spin the dial you are instructing the radio to perform a lot of tuning operations, even when the accelerated tuning algorithm kicks in when the knob is rotated faster.  Tuning the radio hardware is a fairly fast operation.  Representing that tuning change on the SmartSDR console may not.  There are several reasons for the behavior you are seeing.

1.) Windows may be queuing the tuning commands.  Please refer to the HelpDesk Help Center article How to Mitigate FlexControl Latency to minimize the latency with the USB com port.  It the USB controller is shared with other devices, especially one that are polling devices, that can cause the behavior you have described.  Also, if the USB port is a USB3 port, it can have issues with USB 1.1 devices; try connecting to a USB 2.0 port if possible.  We have even had to recommend to some customer that they get a USB 2.0 add-on card and use it because the USB3 controller on their motherboards just didn't work well.

2.) The delay can be associated with the ability of the graphics adapter to render the display fast enough for the multiple tuning operations that the radio is performing when you spin the knob.  If it can't keep up, then there is a queuing lag.  We see this mostly on systems with integrated graphics because they render slower.  One reason is that they use system RAM rather than dedicated graphics ram.  In these cases, replacing the integrated graphics with a add-in graphics card resolves the issue.  This issue is compounded if the width of the panadapter is wide, if the panadapter has to tune as a consequence of the slice being tuned and if there are multiple slices visible.

3.) The Tune Step is set too high.  With a large tune step setting, rapidly rotating the FlexControl can result in large jumps in tuning.

And lastly. if you want to make large changes in frequency of a slice, spinning the FlexControl knob is not the most efficient or precise way to tune the radio.  Direct frequency input only performs one tune operation in the radio and one display rendering operation rather than possibly thousands in less than a few seconds.

Your report of a program crash leads me to believe something else is going on that is system related and not a systemic software defect.  I see you have a HelpDesk ticket opened on this issue, so the issue of the crash should be investigated first.