Topics

uBITX rotary enconder

Jose Matos
 

Hi DR fellows
Just asking if anyone is thinking to change the rotary encoder of the uBITX to an optical encoder due
the not good quality of the uBITX encoder. 
can it is possible?
I found this on ebay: https://www.ebay.es/itm/Rotary-Encoder-400P-R-6mm-Incremental-Optical-Shaft-Working-Measurement-5-24V-SH/252550089532?hash=item3acd288b3c:g:uVsAAOSwmLlX4i36

best 73s
José
CT1FKN

Jim Sheldon
 

Jose,
I have one of those and it outputs 400 pulses/revolution.  This may present problems for the software to read properly as the standard uBITX encoder puts out about 24 pulses/revolution.  The software to read the encoder would have to be changed to make that optical one work right.

Jim - W0EB

Jim Sheldon
 

Jose,
It will not work right.  I have one and I connected it to my Raduino to actually test it (using my home made test set).  At 400 pulses per revolution of the shat, it sends pulses to the Raduino many times too fast and you have to turn the shaft very very slow to get it to keep from jumping digits forward and backward.  It has open collector outputs and the internal pull up from the Nano does not give enough current to make the encoders output transistors work properly.
If you try to connect one of these to the uBITX you will not be very happy.  Save your money.

Jim, W0EB

Michael Hagen
 

Would probably have to use the 2 interrupts to read the encoder.  Do the frequency change in the interrupt, not set flag and process in main code.

I did that with the regular (less pulses) encoder on my BitX.  But it depends on how fast things go and length of code in interrupt.


73's

Mike, WA6ISP


On 2/6/2018 11:56 AM, Jim Sheldon wrote:
Jose,
It will not work right.  I have one and I connected it to my Raduino to actually test it (using my home made test set).  At 400 pulses per revolution of the shat, it sends pulses to the Raduino many times too fast and you have to turn the shaft very very slow to get it to keep from jumping digits forward and backward.  It has open collector outputs and the internal pull up from the Nano does not give enough current to make the encoders output transistors work properly.
If you try to connect one of these to the uBITX you will not be very happy.  Save your money.

Jim, W0EB

-- 
Mike Hagen, WA6ISP
10917 Bryant Street
Yucaipa, Ca. 92399
(909) 918-0058
PayPal ID  "MotDog@..."
Mike@...

Michael Monteith
 

After I saw the post and responses I was wondering too.  I ran across this that might help.  If nothing else it helps with doing fast digital writes.

Quadrature Encoder too Fast for Arduino (with Solution)

If you do this let me know. 

73, Michael
KM4OLT

John Scherer
 

I know this is an pretty old post but I have some info that might help others too.  I have been playing with a modified version of that exact code on Jim's (W0EB) wonderful BITeensio board with a Teensy 3.6 processor, and I'm able to read my 1024ppr optical encoder pretty much as fast as I can spin it.  The 1024ppr encoder is pretty useless for the uBitx unless I added routines to divide the ppr (way)down, but I also have several ENA1J-B28-L00128L encoders which I do plan on using in my uBitx.  These are very nice and have square wave output and no de-bounce needed.  Now I just need to figure out how to replace the existing encoder non-interrupt based routine with this code..


On Wed, Feb 7, 2018 at 12:01 PM, Michael Monteith wrote:
After I saw the post and responses I was wondering too.  I ran across this that might help.  If nothing else it helps with doing fast digital writes.

Quadrature Encoder too Fast for Arduino (with Solution)

If you do this let me know. 

73, Michael
KM4OLT

 
--
John - N0CTL - Fulltime RV in a 40' motorhome

Adrien F4IJA
 

I've installed this one : http://www.tobeca.fr/f4ija/doku.php?id=ubitx:rotary
 Since I've red a post of another ham. Working well in my case. beware of the wiring I needed to invert the logic of rotation.
--
73's
Adrien F4IJA
https://www.qrz.com/db/F4IJA

Werner de Vos
 

What’s the benefit of using this encoder instead of the standard one? 

Adrien F4IJA
 

The one I've? I feel it smoother ans quieter and global better quality. 
--
73's
Adrien F4IJA
https://www.qrz.com/db/F4IJA

 

I also use this type of optical rotary encoder. It is much better and the feel is just perfect.
Between the encoder and the Radiuno I have a extra Arduino to adapt the pulses and divide them to not overrun the Radiuno.

I found a sketch by Jim Smith - G3ZQC and Glenn Percy - VK3PE to perform this task perfectly and only added some stuff for my project.

Try it !

Regards and 73's
PE1MHY
Guido

John Scherer
 

I've seen that code Guido, but there is more to that code.  For others coming here and seeing the link to the code above.  Please see this link for more info on how to implement it. But basicly, you program that code into a small microprocessor, something like a ATTiny85, though others even use a Nano.  You then connect you high-pulse count encoder to the processor, and it outputs a divide/N signal that you then feed to yourRaduinos encoder inputs:

test2

Jack, W8TEE
 

Wouldn't it just be easier (and less expensive) to buy an encoder with a lower ppr? Mouser sells good quality Bourns 20ppr encoders for under $2.


Jack, W8TEE

On Monday, September 23, 2019, 11:07:33 PM EDT, John Scherer <jrsphoto@...> wrote:


I've seen that code Guido, but there is more to that code.  For others coming here and seeing the link to the code above.  Please see this link for more info on how to implement it. But basicly, you program that code into a small microprocessor, something like a ATTiny85, though others even use a Nano.  You then connect you high-pulse count encoder to the processor, and it outputs a divide/N signal that you then feed to yourRaduinos encoder inputs:

test2

--
Jack, W8TEE

John Scherer
 

Hey Jack!  Easier?  Sure, ok.  But its not always about what easy, is it.  If it were, we would just buy all of our ham gear and be done with it.  That being said, whats mentioned above isn't that difficult.  I used and attiny85 that I programmed with the ArduinoIDE.  Works like a champ.  The one thing I would love to add is, when I change the step size in the uBitx, I would like to have the radio change the divisor on the fly.  For 10 Hz step, divide by 2, for the others by 4.  The goal would be for about 2.4 kHz span per one knob revolution when 10 Hz is selected, and about 12 kHz when 100 Hz is selected.

My reasons for going to a higher PPR optical encoder over the mechanical encoder that most use was all about the feel.  Most optical encoders have bearings and makes for very smooth operation.  The encoder in my uBitx is 128ppr and the Nano just isn't up to that task.  It could likely be made to work but I'm no expert with the code or ISR's.  I also have the BITeensio board and I can tell you that with its Teensy 3.6 processor and  a few simple mods to their encoder routines, I was able to read my 1024 ppr encoders (overkill for sure) as fast as I could spin it, without missing a beat.  Point being, we really need a faster processor in the raduino, something like the Teensy 4 would be pretty interesting.  The Teensy 4 could open the door for having some fun with digital audio filters, better spectrum display, etc.

Sascha Bohnet | DL5SMB
 

I also installed one of these famous 100ppr ebay encoders.

The speed of the Nano is a restraint for sure, but in my case it was totally sufficient.

The probem I faced was the programming of the encoder function. It was written for the low-resolution mechanical encoders,
not for the faster optical ones. I just replaced two commands ("millis" to "micros") in the KD8CEC's source code and my encoder worked.

https://groups.io/g/BITX20/message/71360

Jack, W8TEE
 

Agree, and I have some interesting things I want to try with the 4.0 Teensy. For a while, JackAl used a software timer to track the rate at which the user was "spinning" the frequency knob. If the rate when above some user-defined threshold, we upper the increment factor by 10x. It worked fine, but seemed awkward to us. Because we use a touchscreen with the JackAl, we just put a "floating" cursor above the current frequency (shown here above the '3' digit) and the user can tap the '<' or '>' to move the

Inline image

frequency increment value. Not the best solution, perhaps, but it works. Plus, if you don't like it, you have the source code to change it if you want.

Jack, W8TEE


On Tuesday, September 24, 2019, 6:26:37 AM EDT, John Scherer <jrsphoto@...> wrote:


Hey Jack!  Easier?  Sure, ok.  But its not always about what easy, is it.  If it were, we would just buy all of our ham gear and be done with it.  That being said, whats mentioned above isn't that difficult.  I used and attiny85 that I programmed with the ArduinoIDE.  Works like a champ.  The one thing I would love to add is, when I change the step size in the uBitx, I would like to have the radio change the divisor on the fly.  For 10 Hz step, divide by 2, for the others by 4.  The goal would be for about 2.4 kHz span per one knob revolution when 10 Hz is selected, and about 12 kHz when 100 Hz is selected.

My reasons for going to a higher PPR optical encoder over the mechanical encoder that most use was all about the feel.  Most optical encoders have bearings and makes for very smooth operation.  The encoder in my uBitx is 128ppr and the Nano just isn't up to that task.  It could likely be made to work but I'm no expert with the code or ISR's.  I also have the BITeensio board and I can tell you that with its Teensy 3.6 processor and  a few simple mods to their encoder routines, I was able to read my 1024 ppr encoders (overkill for sure) as fast as I could spin it, without missing a beat.  Point being, we really need a faster processor in the raduino, something like the Teensy 4 would be pretty interesting.  The Teensy 4 could open the door for having some fun with digital audio filters, better spectrum display, etc.

--
Jack, W8TEE

John Scherer
 

I always liked that screen layout Jack.  UI design for these small displays, well any display really, and especially when its for the masses, can be an exercise in futility. Its hard to be all things to all the people ;-)  But this layout puts everything you need all on one screen.  Simple and sweet.
--
John - N0CTL - Fulltime RV in a 40' motorhome

John Scherer
 

It just came to me that, the circuit I posted above and designed by Glen - VK3PE, would be super easy to modify to have two different division ratios.  Rather than using D0 as a direction output, just configure it as an input and have it divide by 2 if its high, or 4 if is low.  Divisors could be anything but you get the idea.  The all I would need is an output from the teensy / nano to reflect the step size chosen to flip the bit
--
John - N0CTL - Fulltime RV in a 40' motorhome

Skip Davis
 

Jack I like the way you implemented changing frequency steps right there on the screen, it is clean and efficient. I hate to have to dive into menus to fine useful functions that I use frequently, and changing tuning steps is one of those I use on my other rigs.

Skip Davis, NC9O 

On Sep 24, 2019, at 09:27, Jack, W8TEE via Groups.Io <jjpurdum@...> wrote:

Agree, and I have some interesting things I want to try with the 4.0 Teensy. For a while, JackAl used a software timer to track the rate at which the user was "spinning" the frequency knob. If the rate when above some user-defined threshold, we upper the increment factor by 10x. It worked fine, but seemed awkward to us. Because we use a touchscreen with the JackAl, we just put a "floating" cursor above the current frequency (shown here above the '3' digit) and the user can tap the '<' or '>' to move the

<Figure010.jpg>

frequency increment value. Not the best solution, perhaps, but it works. Plus, if you don't like it, you have the source code to change it if you want.

Jack, W8TEE


On Tuesday, September 24, 2019, 6:26:37 AM EDT, John Scherer <jrsphoto@...> wrote:


Hey Jack!  Easier?  Sure, ok.  But its not always about what easy, is it.  If it were, we would just buy all of our ham gear and be done with it.  That being said, whats mentioned above isn't that difficult.  I used and attiny85 that I programmed with the ArduinoIDE.  Works like a champ.  The one thing I would love to add is, when I change the step size in the uBitx, I would like to have the radio change the divisor on the fly.  For 10 Hz step, divide by 2, for the others by 4.  The goal would be for about 2.4 kHz span per one knob revolution when 10 Hz is selected, and about 12 kHz when 100 Hz is selected.

My reasons for going to a higher PPR optical encoder over the mechanical encoder that most use was all about the feel.  Most optical encoders have bearings and makes for very smooth operation.  The encoder in my uBitx is 128ppr and the Nano just isn't up to that task.  It could likely be made to work but I'm no expert with the code or ISR's.  I also have the BITeensio board and I can tell you that with its Teensy 3.6 processor and  a few simple mods to their encoder routines, I was able to read my 1024 ppr encoders (overkill for sure) as fast as I could spin it, without missing a beat.  Point being, we really need a faster processor in the raduino, something like the Teensy 4 would be pretty interesting.  The Teensy 4 could open the door for having some fun with digital audio filters, better spectrum display, etc.

--
Jack, W8TEE
<Figure010.jpg>