1.9.7 and API-based controllers

  • 3
  • Praise
  • Updated 2 years ago
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
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 Reply Likes
  • Contented

Posted 2 years ago

  • 3
Photo of Ken - NM9P

Ken - NM9P, Elmer

  • 3973 Posts
  • 1226 Reply Likes
I knew you would like it!  Wait until you play around with the different latency settings for filters, etc!

Ken - NM9P
Photo of John G3WGV

John G3WGV

  • 187 Posts
  • 35 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
Photo of SteveM

SteveM

  • 253 Posts
  • 40 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)
Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 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.
Photo of SteveM

SteveM

  • 253 Posts
  • 40 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

Photo of Kevin K4VD, Elroy

Kevin K4VD, Elroy

  • 775 Posts
  • 171 Reply Likes
Thanks for the link Steve. Good reading and questions answered.
Photo of James Whiteway

James Whiteway

  • 879 Posts
  • 193 Reply Likes
Wonderful project! Thanks for sharing!