Topics

bitx and ubitx encoder replacement / Software Issues (too slow)

Sascha Bohnet | DL5SMB
 

Hey, It's me again :-)

Still working on this problem - and since I think I am not the only one who wants to get this encoder working,
I am keeping to this thread.

My next approach to this problem was switching to an I2C adapter.

This way I could free up some digital pins, formerly used by the parallel connection of the display.

The idea was that maybe another rotary encoder libray works better than the standard solution. If thats is not sufficient,
maybe there is still the possibility of using a pin change interrupt libray or port mapping.

So I started making adjustments in the code and inserted the quite popular rotary libray by Ben Buxton,
but it is not working correctly yet. As soon as power is applied the frequency starts going up.

If I push the button I am able to get into the menue. There I can choose within the first layer of
options "Select band, "select VFO"... but as soon as I enter the second layer (80m, 40m, etc)
all band start changing permanently, as If soneone would turn the encoder very fast.

And if the putton is pushed again, a random band is choosen and the VFO starts running up again.
Turning the rotary encoder again does nothing - whatever direction or speed I use. It's still running up.

I assume the problem is caused by the interaction of the two functions

enc_read() (original) in file ubitx.ui (which I modified to this)
            and
doTuningWithThresHold() in file ubitx_20

I thought I understood  vaguely what exactly enc_read() does in the original version, but it seems this function does not simply give back
an increasing or decreasing number.  For example I don't get what purpose the additional "enc_speed++;" is serving.
I don't see where this is relevant in the code or where this is used later.

After playing around a bit I inserted a "delay(1)" within the rotary code before the value is given back. This stopped the VFO
from going wild and allowed tuning again.

But issues persist:

a.) if the encoder is turned to fast, it hangs again (maybe like with the original code?)
b.) in the second layer of the menu no signals of the encoder are recognizes. The menue does not go wild, but you cannot
     choose anything either.

Does anybody see what it is that I am doing wrong?

I once also tried the old mechanical encoder again with the new library at the digital ports.
With that one i needed 20 complete turns in the fuirst layer of the menu to get to the next option ("Change bands" to "Change VFO A").
Maybe this is also relevant.

It would be nice if anyone had some suggestions.

Sascha






 

Sascha Bohnet | DL5SMB
 

I totally forgot that changing the title breaks the contiguity.

There is the original thread.

Sascha Bohnet | DL5SMB
 

So, I played some more and found a simple solution that works for me.

As I could not figure out, why the new library was not working, i rewired the encoder to the analog inputs
and  reloaded the original code - but, based on my earlier findings, made two changes:

Within the enc_read() function, I changed both delay(1) commands to delayMicroseconds(1),
so the function looks like this.

With this change of code I seem to get my 100 pulses per rotation - though the faster I go the more pulses get swallowed.
But I think this workaround is bearable :-)

I also tried fiddling around with the millis(), exchanging them for micros(), but this was more pain than it was worth,
though maybe I just tried the wrong values (I tried 1 and 500 instead of the default 50).

Maybe this helps someone - I just wanted to document what I found for everyone else who does not have too much experience in programming.

Sascha
 

Jack Purdum
 

Keep in mind that the delay() function is a blocking function. That it, it uses its own interrupt service routine so if you're using an ISR for your encoder and it calls delay(), all kinds of weird things can happen, all usually bad. This is while I wrote MyDelay() which is constructed from non-blocking calls.

Jack, W8TEE

On Friday, August 23, 2019, 8:37:39 PM EDT, Sascha Bohnet | DL5SMB via Groups.Io <saschabohnet@...> wrote:


So, I played some more and found a simple solution that works for me.

As I could not figure out, why the new library was not working, i rewired the encoder to the analog inputs
and  reloaded the original code - but, based on my earlier findings, made two changes:

Within the enc_read() function, I changed both delay(1) commands to delayMicroseconds(1),
so the function looks like this.

With this change of code I seem to get my 100 pulses per rotation - though the faster I go the more pulses get swallowed.
But I think this workaround is bearable :-)

I also tried fiddling around with the millis(), exchanging them for micros(), but this was more pain than it was worth,
though maybe I just tried the wrong values (I tried 1 and 500 instead of the default 50).

Maybe this helps someone - I just wanted to document what I found for everyone else who does not have too much experience in programming.

Sascha