FlexControl Overrun

Mark Erbaugh

I am running SSDR 1.3.8.126.

When I try to use the FlexControl to make a large change in the VFO rapidly, I find that SSDR doesn't seem to keep up and I end up chasing the desired frequency.  IOW, If I rapidly "spin the dial" from 7.300 to 7.200, SSDR follows more slowly, then tunes down to say 7.190 then, because I've spun the dial in the opposite direction to correct it then tunes up to 7.210, etc.

It appears to me to be a classic case of the FlexControl commands being held in a buffer while SSDR tries to catch up.

Steve W6SDM

Yeah, a few of us have pointed that out.  Flex is aware.  When you give the Flex Control a healthy spin, you end up half a MegaHertz away before it slows to a stop.  Somehow, there needs to be a limit on how much can be buffered so that this doesn't get away from you.

Tim - W4TME

Essentially, the radio is doing when you have instructed it to do.  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.

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 hundreds in less than a few seconds.

I hope these suggestions help everyone understand what is going on and the multiple system dependencies involved with something that seems as trivial as tuning the 6000 with a FlexControl.

Steve W6SDM

And all this time I though it was because Stu, based on his QTH, was putting some really high-end silicon grease on the ball bearings in the Flex Control. 

Yeah, there are a lot of systems that have to interact in response to just tuning.  Now that I see a way to adjust the buffers of a specific USB port, that just might be the ticket.  Thanks, Tim.

Michael - N5TGL

I've adjusted buffers, bought a GeForce GTX 750 Ti, and my tune step isn't any larger than it was with PSDR, yet I still have the overrun problem.  This is a problem that needs investigation and resolution, not explanation.    When I stop spinning the knob, the tuning should stop.  Right then, not when it pleases.  Within the panadapter window, that's the way it works, however if you get to a panadapter edge, and the window has to scroll, then the overrun problem happens, and it doesn't even have to be a large change.

The radio may be doing what it is commanded to do, but it's not helpful that it's in a time warp when it does it.

[Deleted User]

Yes I agree. Mine has been doing it since I purchased it. I've watched it tune right out of the 40 meter band while trying to quick tune on a signal.

I was told it is "adaptive tuning" and tune slower.

Paul, WB5AGF

This sounds akin to what I asked about recently :

"Is A Slight Tuning Latency (~100 - 300 mS) Typical For SmartSDR/FLEX6500 ?"

https://community.flexradio.com/flexradio/topics/is-a-slight-tuning-latency-100-300-ms-typical-for-s...

- Paul, WB5AGF

Michael - N5TGL

I would encourage everyone who is having trouble with this issue to hit the "me too" box at the top of the post.  Upvoting makes things happen.

I disagree that "the radio is doing when you have instructed it to do" -- I haven't told it to keep tuning after I stop.    No other radio I own does this, and my 6700 (or any 6xxx for that matter!) shouldn't either.

Tim - W4TME

What SmartSDR is doing when the radio tunes and what PowerSDR does graphically is so very different.  PowerSDR does significantly less graphics rending per tune operation. 

Asher - K0AU

I had this problem big time with Intel embedded graphics and solved it with an ATX minitower and a GeForce 750ti.  SSDR is a thin CPU client, but an apparently-somewhat-demanding GPU client. 

Semantically interpreting every x degree twist of the knob as a tune step is probably not what the user means.  A vigorous twist to the right usually means something like "tune up at a predictable rate until I stop twisting"  The faster the twist the higher the rate.  If you want to get fancy you can add a physics engine and pretend there's a flywheel with some overshoot.  A slow twist means "I'm now tuning precisely and want you to follow me up or down by the step size."

Stu Phillips - K6TU

Accelerated tuning detection is implemented in the firmware in FlexControl.  However, the acceleration algorithm is turned OFF for some reason by SmartSDR.

The FlexControl logic detects multiple tuning steps in quick succession and is capable by default of aggregating them together into one command sent to SmartSDR/.

DDUtil support an excellent implementation of this accelerated tuning - I have no idea why it has been turned off in SmartSDR.

I spent a LONG time implementing this algorithm and getting it to function correctly plus there are a number of configurable controls in the firmware that allow this to be fine tuned.

I've never been able to get FlexRadio to implement accelerated tuning as i designed it - either in SmartSDR or PowerSDR.

DDUtil has it right!

Stu K6TU

Mark Erbaugh

Stu,

Thanks for the info and the work on the FlexControl. I'm using N4PY software and tuning seems to work better with it. Do you know if N4PY supports the acceleration algorithm?

I've been meaning to try out DDUTIL. I really like being able to reconfigure my "shack" by adding new software to the computer.

73,
Mark

Stu Phillips - K6TU

I don't know if Carl implemented the acceleration algorithm of not...  basically the knob integrates tuning steps over unit time (which is configurable) and then sends an aggregate command to the host when the time is up.

DDUtil implements the acceleration by increasing the size of the tuning step in a sequence from 1,5,10,25,50,100,250,500 Hz etc.  What ever is configured as the base step, that is what gets tuned for a single movement of the encoder.  If you move it faster and say three steps are integrated over time, then DDUtil commands a single tuning step that is 3 further along in the sequence.

So for a base step of 10 Hz, turning the knob fast enough to get three steps integrated in a single period would tune 100 Hz.

The integration time period is configurable so you basically have the integral of dv/dt - which is acceleration! :-)

We implemented this in DDUtil because of the issues of a queue of tuning commands building up between the radio and PowerSDR.  Happily that has gone bur-bye in SmartSDR.

Ironically when this same issue is implemented in SmartSDR it should really cut down on the overrun scrolling when tuning a slice at the edge of the pan.

Stu K6TU

Stu Phillips - K6TU

As a follow up - I've had a number of Email exchanges with Eric at FlexRadio this morning and I clearly owe him an apology for poor communication regarding this issue.  We were both communicating but my explanation of the intended approach didn't come across clearly.

That is now fixed and we're looking at a solution which I think will help significantly!

Major Kudos to Eric!  I get the opportunity to look over his shoulder and he is an excellent designer and programmer!  With clearer communication on my part, we will get there!

Stu K6TU

[Deleted User]

WOO HOO Cant wait.

Michael - N5TGL

This is great news!  The community WORKS!  

Eric-KE5DTO

I think I owe an apology for taking this long to understand the issue.  Regardless, progress is being made now.  Thanks to Stu and others for bringing this to our attention.