1.9.7 and API-based controllers

John G3WGV

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:

1. 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.
2. The audio clicks while tuning with an external controller seem to have gone completely.
3. 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

Ken - NM9P

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

Ken - NM9P

Kevin

Ken... could you explain in this or a new thread what the latency settings actually do and what it means for the average ham (assuming I'm kinda average). Maybe there's enough new material in this update for one of your video tours?

Kevin - K4VD

John G3WGV

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

James Whiteway

Wonderful project! Thanks for sharing!

SteveM

"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.

Kevin

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.

SteveM

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

Kevin

Thanks for the link Steve. Good reading and questions answered.