On 2025-02-02 07:25, jjpurdum via groups.io wrote:
Character displayed in first position, character displayed in second
position - etc. Then
erase and rewrite ONLY those characters that have changed.
Updating the characters used in the frequency display uses very little
time.
*** Yet it is very disruptive to the audio. Why is that? I think it's
because interrupts are disabled during SPI transfers.
Tracking what has changed and what hasn't changed would likely
take more time and updating the entire string.
*** Microseconds. Literally zilch. And during the process of this figuring,
interrupts are open, and the audio continues.
The real time eater is
the updating the spectrum/waterfall displays. The waterfall is less of
an issue because it's only changing 1x512 pixels on each pass.
*** For some reason - that I don't really understand - the spectrum/waterfall
is not a problem.
I *suspect* that we are leveraging an internal function of the display to do
partial scrolls or block moves.
Since you can "see" which signals are active, I'm less concerned about
the audio _while _tuning than the audio when you _stop _tuning.
*** Jack, I respectfully disagree. Smooth tuning is VERY important. When I'm
zeroing in on an SSB signal or tuning past a CW signal, I want to hear it.
Tuning around with my ancient Signal/One is more pleasant than tuning around
with the T41 - although once you get there, the T41 receives better.
Personally, at least half the time I spend in front of a ham radio is just
tuning around. The equipment manufacturers understand this: Just think of all
the elaborate main tuning mechanisms that have been used over the years.
I think that the tuning can be seriously improved without loading down the
radio to any appreciable degree. Just leaving out the update of the inactive
VFO is making a big difference. Tuning only affects the main VFO. Why are
we erasing and rewriting the inactive one - that doesn't change while tuning?
... let those people who think optimizing is so easy
make the improvements to those things that are working.
*** Working on it Jack. I am not a guy who takes software challenges lightly.
Not any sort of programming genius or cowboy. But I don't think this particular
one is too hard. I did embedded software for a living for 20 years, and I
developed a pretty good nose for what's hard, and what's not hard.
The first most obvious thing is to have a global variable for each display item
that tells us *WHAT IS BEING DISPLAYED NOW*? If the new thing to display is the
same as what's being displayed now, we don't mess with it. Why change it if it's
already right?
Working toward minimal audio disruption from display changes will make the tuning
useable - but still not nice. To make it *nice* we will need to look at the big fat
*tick* that happens at every encoder event. That is IMHO a harder nut to crack. But
I remember the old encoder system with the encoders directly connected to a couple of
I/O ports as being much smoother.
- Jerry, KF6VB
