1.9.7 and API-based controllers

I've just upgraded to 1.9.7 and I'm very impressed so far. Three key issues for me that seem to be greatly improved:

The CW break-in is significantly better. Gone is the bleed through of RX noise in the audio stream as the radio goes to TX. The break in is now truly superb.
The audio clicks while tuning with an external controller seem to have gone completely.
Tuning with an external controller seems much smoother and more responsive.

The latter two observations are using my home brew controller, http://g3wgvflex.blogspot.co.uk/. I've not tried with the Maestro yet but as it's the same API I expect it to be similarly much improved.

So, software gurus at FlexRadio: thanks, you've done a great job.

73, John, G3WGV

John G3WGV

200 Posts
37 Reply Likes
Contented

Posted 3 years ago

3 years ago

Ken - NM9P

4241 Posts
1355 Reply Likes

I knew you would like it! Wait until you play around with the different latency settings for filters, etc!

Ken - NM9P

Comment

View previous…

2016-09-14T16:00:40+00:00

John G3WGV

200 Posts
37 Reply Likes

Creating steep skirted filters is a CPU intensive activity, so the steeper you make them the more time it takes to do the processing, resulting in higher latency. Flex now gives you the option to have super sharp filters OR have minimum latency. There's also two intermediate steps that provide a balanced performance.

In practice, I should think the only time you would worry about latency is when you are dealing with highly synchronous traffic that has critical timing. Not being a data modes person I don't have any specific examples.

Play with the settings - the effect is instantly apparent.

73, John, G3WGV

2016-09-14T18:12:56+00:00

SteveM

277 Posts
44 Reply Likes

"the steeper you make them the more time it takes to do the processing, resulting in higher latency"

Respectfully John, this is not quite correct. Latency occurs in real-time DSP processing for a couple of reasons, computational complexity is not one of them.

One reason latency occurs is that filtering causes delay, period. Typically, the delay is proportional to the width of the filter. Since increased selectivity requires a wider filter, it also increases delay.

Another source of latency can be algorithmic. For example, if at any point in the algorithm samples are processed en masse, you have generated latency proportional to the size of the sample group.

(Edited)

2016-09-14T19:06:08+00:00

Kevin

931 Posts
272 Reply Likes

Steve... does this go for analog as well as digital filters? The more filter poles the more latency? I have never had an issue with latency on any rig I've owned and not sure the amount of latency we are talking about here would be discernible by just listening.

I still haven't tried the different settings but I will.

2016-09-15T17:15:28+00:00

SteveM

277 Posts
44 Reply Likes

Kevin, sorry to respond so late. I shut off email alerts awhile ago. Here is a link that compares analog and digital filters. Halfway down your question is answered.

https://en.wikipedia.org/wiki/Digital_filter#Comparison_of_analog_and_digital_filters