bitx and ubitx encoder replace ment

Richard E Neese


An excellent encoder, I use one on an HDSDR controller. 

With the detent mechanism removed to allow free turning the encoder gives a very smooth tuning action. 

Now that the encoder can spin freely the protruding crank handle will always come to rest in the down position so it has to be removed.

Also saves the cost of a separate tuning knob. 

Sascha Bohnet | DL5SMB

Sorry to bring back such an old topic, but might I ask how this infamous 100 PPR encoder  can be dissassembled / how  the detent mechanism can be removed?

I removed the 3 nuts, removed the 6 screws, removed the handle and can't figure out how to proceed further.

I could imagine the PCB needs to be removed next - is this correct? Is it enough to unsolder the 4 PINs on the bottom? It does not seem so.

I am a bit afraid of killling the thing if  i just proceed without a plan.

Alf Baranda

Robert please tell us how you eliminated the coder retention.
I'm also with the same dilemma, I don't know how to remove it and I'm afraid to destroy it.
I hope someone can clarify it for us.
Thank you.

Mark Hatch

I have tried both the 100ppr and a 24ppr with the kd8cec software. I saw a lot of missed steps on the 100 and the 24ppr was inconsistent in response. 

Are you you seeing something different or using something other than the ld8cec software?



Remove the knob handle, then, using a heat gun or hair dryer heat the silver knob insert to soften the adhesive and carefully pry off that silver insert to reveal retaining screws that can be removed. The mechanism will now come apart and you can remove the detent. Replace everything but not the handle.

Alf Baranda

Thanks Robert, as soon as I have a little time I will try.
I've been thinking about it for a long time.
The truth is that I don't like dials with retention.

Sascha Bohnet | DL5SMB

Thanks Robert, that was the push into the right direction.Now I was able to disassemble it and removed the detent.
I am building my second uBITX at the moment and am really excited to try out this encoder. Hopefully this weekend i will be ready to test the function.

Sascha Bohnet | DL5SMB

As this is still relevant to this topic I refrain from opening another thread and write here again.

I can confirm Mark's problems with the speed of the 100ppr encoder:
If the encoder is span slowly it works acceptable, but if the speed is increased, problems arise (See my reference video )

Has anyone found a way around this for KD8CECs software?

There are of course different ways which can be tried:

The following methods I thought of, but they are also burdening up some other problems (at least for me)

1.) My first idea was to simply change to a Arduino Nano Every to keep investements low and to gain something from the change. It's a bit faster, pin compatible and has interrupts everywhere but the eeprom is smaller and it will probably not work with the uBITX Manager. And it also does not compile as the softserial_tiny.cpp is incompatible and would require a rewrite (or a write out of the libray)

2.) Just changing the pins to interrupt capable ones and use another libray for the encoder.
This might be a solution as  Pin 2 and 3  are at the moment used for the CW key and TX-C (I think) which seems to control the low pass filters. I would need cut some connections and rewire here to make the software experiments possible with an unknown result.  Therefore I would rather just try a  software approach.

3.)Try to use portmapping to be able to read out the encoder faster. I found the FastDigitalWrite-Libray but I am not sure if it can be used with analog inputs.
KD8CEC uses the following code to check the encoders status:
byte enc_state (void) {
    return (analogRead(ENC_A) > 500 ? 1 : 0) + (analogRead(ENC_B) > 500 ? 2: 0);
The libray above only supplies
  • digitalWriteFast(pinNum, state) (sets or clears pin/port faster)
  • pinModeFast(pinNum, mode) (sets pin/port as input or output faster)
  • digitalReadFast(pinNum)(reads the state of pin/port faster)

So no support for analogRead. And I guess if it was possible to read out the analog ports digitally,
this would have been done by KD8CEC before using this workaround.

Does anybody have an idea, what could be done?