Topics

QCX rotary encoder remote button issue #qcx #problem

G0UON - Jim
 

For better usability I decided to include a third button on my QCX20 build to mirror the functionality of the rotary encoder press, thereby allowing the tuning steps to be changed with this extra button.

This works…but not reliably. Intermittently (maybe 20-30% of actuations) the button will take the action of the right button, so switches the VFO from A to B for example. Pressing the rotary encoder knob works reliably 100% of the time.

Looking at the excellent manual I see that the buttons have been configured as an analogue multiplex into the microprocessor whereby each button has a different voltage defined. The right button is 4.55V, and the centre button is 5.00V, so maybe the voltage is slightly low using my off-board button but I've no idea why that could be (not checked it yet with a DVM though – will do when I have a moment).

Has anyone else had this issue or have any ideas how I might fix it?

73

Jim – G0UON

Alan G4ZFQ
 

(not checked it yet with a DVM though – will do when I have a moment).
Jim,

Yes do that. What sort of button is it, some are not metal-metal contacts?

73 Alan G4ZFQ

G0UON - Jim
 

Thanks Alan. The buttons are the basic cheapo ones (see pic). This style of button has been around for ever but to be honest I'm not impressed with the feel of these compared to similar-looking ones on old bits of kit I have. 

73 Jim – G0UON

Kārlis Goba
 

I can chime in that I observe a similar problem. I have soldered external buttons on ~5cm wires in parallel to the original left and right buttons, and one of the external buttons sometimes registers as the other, sometimes very insistently.

I think the problem might be in very minute details how the ADC is used to read button state. There might be a transition process that throws off the reading which works fine with the stock buttons. I am 99% sure this can be fixed with a firmware update, but... (sssh, let's not disturb Hans while he's hopefully polishing the QSX).

--
Karlis YL3JG

Skip Davis
 

Jim have you measured the voltage across your switch when pressed? It should be zero if not it might be a faulty switch. I’ve seen and experienced this before with these new breed of bargain parts.

Skip Davis, NC9O

Hans Summers
 

Hi Karlis, all

"There might be a transition process that throws off the reading which works fine with the stock buttons. I am 99% sure this can be fixed with a firmware update, but... (sssh, let's not disturb Hans while he's hopefully polishing the QSX)."

Attached here is a photo of my QCX-40 (with built-in 50W Amp); the buttons I use are a similar low cost type and I never have any problems with them. All the controls are mounted off-board. Everything works perfectly. I do use shielded/screened cable for all interconnections (audio AND to the buttons). I have three buttons on the front panel, one is just in parallel with the microswitch so can be used as a key if needed. The two toggle switches are On/Off and QRP/QRO. 

If the button does not work then I suggest checking the voltages carefully when it is pressed. You might want to use shielded cable to stop any interference coming from elsewhere. 

73 Hans G0UPL


On Thu, Nov 7, 2019 at 4:28 PM Kārlis Goba <karlis.goba@...> wrote:
I can chime in that I observe a similar problem. I have soldered external buttons on ~5cm wires in parallel to the original left and right buttons, and one of the external buttons sometimes registers as the other, sometimes very insistently.

I think the problem might be in very minute details how the ADC is used to read button state. There might be a transition process that throws off the reading which works fine with the stock buttons. I am 99% sure this can be fixed with a firmware update, but... (sssh, let's not disturb Hans while he's hopefully polishing the QSX).

--
Karlis YL3JG

jjpurdum
 

I have no idea how the encoder switches are being read, but usually it's with 1) polling, or 2) interrupts. The Nano has limited external interrupts, so perhaps Hans is using polling within the main loop() function. Given all that Hans has squeezed into the Nano, polling might be a little slow to show a state change. That said, if the external button is bogus 20% of the time and the encoder switch works perfectly, I'd start by replacing the external switch with one that you know is reliable. I bought some cheap push button switches and out of a purchase of 10, 2 have proven unreliable.

Jack, W8TEE

On Thursday, November 7, 2019, 7:35:22 AM EST, G0UON - Jim <jim@...> wrote:


For better usability I decided to include a third button on my QCX20 build to mirror the functionality of the rotary encoder press, thereby allowing the tuning steps to be changed with this extra button.

This works…but not reliably. Intermittently (maybe 20-30% of actuations) the button will take the action of the right button, so switches the VFO from A to B for example. Pressing the rotary encoder knob works reliably 100% of the time.

Looking at the excellent manual I see that the buttons have been configured as an analogue multiplex into the microprocessor whereby each button has a different voltage defined. The right button is 4.55V, and the centre button is 5.00V, so maybe the voltage is slightly low using my off-board button but I've no idea why that could be (not checked it yet with a DVM though – will do when I have a moment).

Has anyone else had this issue or have any ideas how I might fix it?

73

Jim – G0UON

Kārlis Goba
 

Hans, I could agree on shielding when the QCX is transmitting. However, it's not really the case here, as I never get bogus button clicks even when sending. It's just that when I press the right button, it often registers annoyingly as the left button. I don't think the button lines are picking up any noise. I'm using very similar buttons as Jim originally reported, and they shouldn't really have resistance in hundreds of ohms, let alone thousands. I will check with scope, perhaps there's another gotcha hiding somewhere.

--
Karlis YL3JG

Hans Summers
 

Hi Jack, Karlis,

QCX does NOT use a Nano, and does NOT use Arduino at all :-)   No blasphemy please!! Only the processor ATmega328 is the same as some popular Arduino models. There is no other similarity. I do not believe I could have squeezed in so much functionality if I had been using Arduino. Those the processor is the same (therefore the same 32K Flash memory is available for programs), in the Arduino there is a lot of stuff built-in that takes plenty of space all by itself. See how many KBytes are required just to flash an LED on and off...

QCX uses a mixture of polling and interrupts. Both have advantages and disadvantages. I mix them to provide the necessary responsiveness and latency as required by the various functionality. 

Normally the only ADC operational is the audio, this is sampled at 12ksps. If a button is pressed, the ADC is switched momentarily to measure the button voltage. This is all interrupt driven. The actual response to the button press is by polling, as it is relatively non-time-sensitive. The event itself having already been registered. Software debounce is employed. 

Karlis, I agree, no transmitting is going on... I used shielded wires just because I didn't want to take any risks. It's strange that I never observe any button issues, neither with the supplied buttons on the board, nor the buttons on my QCX-40-monster, which are on 10-15cm of cable. 

73 Hans G0UPL

On Thu, Nov 7, 2019 at 4:42 PM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
I have no idea how the encoder switches are being read, but usually it's with 1) polling, or 2) interrupts. The Nano has limited external interrupts, so perhaps Hans is using polling within the main loop() function. Given all that Hans has squeezed into the Nano, polling might be a little slow to show a state change. That said, if the external button is bogus 20% of the time and the encoder switch works perfectly, I'd start by replacing the external switch with one that you know is reliable. I bought some cheap push button switches and out of a purchase of 10, 2 have proven unreliable.

Jack, W8TEE

On Thursday, November 7, 2019, 7:35:22 AM EST, G0UON - Jim <jim@...> wrote:


For better usability I decided to include a third button on my QCX20 build to mirror the functionality of the rotary encoder press, thereby allowing the tuning steps to be changed with this extra button.

This works…but not reliably. Intermittently (maybe 20-30% of actuations) the button will take the action of the right button, so switches the VFO from A to B for example. Pressing the rotary encoder knob works reliably 100% of the time.

Looking at the excellent manual I see that the buttons have been configured as an analogue multiplex into the microprocessor whereby each button has a different voltage defined. The right button is 4.55V, and the centre button is 5.00V, so maybe the voltage is slightly low using my off-board button but I've no idea why that could be (not checked it yet with a DVM though – will do when I have a moment).

Has anyone else had this issue or have any ideas how I might fix it?

73

Jim – G0UON

jjpurdum
 

I didn't mean to imply that they could just drop a Nano into the QCX. I was simply stating the Nano as a frame of reference, since that is probably more recognizable than stating the ATMega328P. Given the shallow resource depth of the 328, it should be obvious that there is no (Arduino) bootloader present. And, yes, I have run the Blink program and am familiar with how much is actual program code verses the bootloader. At 16MHz, even polling is more than fast enough for human actions...to the processor, continents drift faster than human reaction time. At the end of my post, I stated that it was unlikely that something native to the QCX was at issue, and that the issue was likely caused by the switch.

Jack, W8TEE


On Thursday, November 7, 2019, 9:02:16 AM EST, Hans Summers <hans.summers@...> wrote:


Hi Jack, Karlis,

QCX does NOT use a Nano, and does NOT use Arduino at all :-)   No blasphemy please!! Only the processor ATmega328 is the same as some popular Arduino models. There is no other similarity. I do not believe I could have squeezed in so much functionality if I had been using Arduino. Those the processor is the same (therefore the same 32K Flash memory is available for programs), in the Arduino there is a lot of stuff built-in that takes plenty of space all by itself. See how many KBytes are required just to flash an LED on and off...

QCX uses a mixture of polling and interrupts. Both have advantages and disadvantages. I mix them to provide the necessary responsiveness and latency as required by the various functionality. 

Normally the only ADC operational is the audio, this is sampled at 12ksps. If a button is pressed, the ADC is switched momentarily to measure the button voltage. This is all interrupt driven. The actual response to the button press is by polling, as it is relatively non-time-sensitive. The event itself having already been registered. Software debounce is employed. 

Karlis, I agree, no transmitting is going on... I used shielded wires just because I didn't want to take any risks. It's strange that I never observe any button issues, neither with the supplied buttons on the board, nor the buttons on my QCX-40-monster, which are on 10-15cm of cable. 

73 Hans G0UPL

On Thu, Nov 7, 2019 at 4:42 PM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
I have no idea how the encoder switches are being read, but usually it's with 1) polling, or 2) interrupts. The Nano has limited external interrupts, so perhaps Hans is using polling within the main loop() function. Given all that Hans has squeezed into the Nano, polling might be a little slow to show a state change. That said, if the external button is bogus 20% of the time and the encoder switch works perfectly, I'd start by replacing the external switch with one that you know is reliable. I bought some cheap push button switches and out of a purchase of 10, 2 have proven unreliable.

Jack, W8TEE

On Thursday, November 7, 2019, 7:35:22 AM EST, G0UON - Jim <jim@...> wrote:


For better usability I decided to include a third button on my QCX20 build to mirror the functionality of the rotary encoder press, thereby allowing the tuning steps to be changed with this extra button.

This works…but not reliably. Intermittently (maybe 20-30% of actuations) the button will take the action of the right button, so switches the VFO from A to B for example. Pressing the rotary encoder knob works reliably 100% of the time.

Looking at the excellent manual I see that the buttons have been configured as an analogue multiplex into the microprocessor whereby each button has a different voltage defined. The right button is 4.55V, and the centre button is 5.00V, so maybe the voltage is slightly low using my off-board button but I've no idea why that could be (not checked it yet with a DVM though – will do when I have a moment).

Has anyone else had this issue or have any ideas how I might fix it?

73

Jim – G0UON

ajparent1/KB1GMX
 

When one hears hoofbeats we don't think of zebras.  Think horses.

My first two thoughts are poor buttons, I've used them and they are terrible
tot he point of removing them and finding something better!   They were to
say the least high resistance contact, and some exhibited a great deal
of contact bounce.  I suspect contact corrosion or material quality was
an issue.

The other is it really wired as believed, and yes a twisted pair of wires may
be preferred.  Too many times as believed correct was "one off" and just wrong.

Also whats being used for ground?

Allison

G0UON - Jim
 

Thanks for all your replies guys.

I've just measured the resistance of the button (but whilst still connected to the PCB) as ~1ohm, whereas the rotary encoder button is ~0.5ohm – a very small resistance but maybe enough to trick the processor. The actuated voltage is 5.05V but it seems to not be instantaneous. So it certainly looks like the button is the culprit. I've just recalled that one of the buttons I'd bought from eBay was totally u/s which is why one of the buttons is red in my pic above. Looks like a dodgy batch of buttons…

73, Jim – G0UON

Kārlis Goba
 

And my buttons measure 0.5-1 ohm. I cannot possibly see how 1 ohm in series with 3.3k (R45) or 1k (R44) forming a voltage divider with 10k would make a difference.

5V * (3.3k / 10k) = 1.65V on the ADC pin
5V * (3.3k + 1 ohm) / 10k = 1.6505V, or half a millivolt. Less difference than ADC could possibly register.

The 1% tolerance on those resistors is in tens of ohms.

For the connection I use 2 unseparated wires from a ribbon cable run in parallel. Solder them in parallel to the original button on the PCB. 

--
Karlis YL3JG

Hans Summers
 

Hello Karlis

It's a mystery, for sure. I don't know what could cause this problem - hardware or firmware... In all the thousands of QCX out there, a percentage of which (including mine) are using off-board buttons - this is the first time this has come up. I will have to contemplate whether there is anything I could do about it in firmware. IF I could figure out a way to reproduce it here. I could almost ask you to send me one of those buttons you have but that seems really ridiculous... as you say, 1 ohm, 5 ohms, matters nothing... so this is a real mystery... 

73 Hans G0UPL

On Fri, Nov 8, 2019 at 10:31 AM Kārlis Goba <karlis.goba@...> wrote:
And my buttons measure 0.5-1 ohm. I cannot possibly see how 1 ohm in series with 3.3k (R45) or 1k (R44) forming a voltage divider with 10k would make a difference.

5V * (3.3k / 10k) = 1.65V on the ADC pin
5V * (3.3k + 1 ohm) / 10k = 1.6505V, or half a millivolt. Less difference than ADC could possibly register.

The 1% tolerance on those resistors is in tens of ohms.

For the connection I use 2 unseparated wires from a ribbon cable run in parallel. Solder them in parallel to the original button on the PCB. 

--
Karlis YL3JG

Kārlis Goba
 

Just checked with a scope. The buttons are very noisy, it's not the resistance or pickup. They just generate a very quick and random train of pulses for about 1ms which coupled with the ADC capacitance gives a very random rising/falling signal, and somewhere in all that zigzag QCX reads the value and assumes the wrong voltage band with all the debouncing since it's probably not tuned for such extremes. So it is a hardware problem, unless somehow a super robust debouncing can be implemented for us, the users of cheap and crappy buttons.

--
Karlis YL3JG

Luc ON7DQ
 

Hans & others,

Just to add some momentum ... I also had this problem, but didn't consider it too serious to report.
But in my QCX20, using the internal buttons, never had any problem.
In my QCX40 I used off-board buttons (also the cheapo chinese ones), see picture (buttons were in the cover and soldered to the wires later).
the wires are somewhat twisted but not shielded.
I just did a test : go into the menu 10 times, then go to menu 4.1, change keyer type , and use the right button to exit.
This failed 6 out of 10, the right button put me back in 4.1 

Luc ON7DQ

Hans Summers
 

Ok Luc, Karlis

So I should make some firmware change to try to more fiercely debounce your crappy buttons. 

If you would send me some ones that show the symptoms, I will do it. 

73 Hans G0UPL

On Fri, Nov 8, 2019 at 2:57 PM Luc ON7DQ <on7dq@...> wrote:
Hans & others,

Just to add some momentum ... I also had this problem, but didn't consider it too serious to report.
But in my QCX20, using the internal buttons, never had any problem.
In my QCX40 I used off-board buttons (also the cheapo chinese ones), see picture (buttons were in the cover and soldered to the wires later).
the wires are somewhat twisted but not shielded.
I just did a test : go into the menu 10 times, then go to menu 4.1, change keyer type , and use the right button to exit.
This failed 6 out of 10, the right button put me back in 4.1 

Luc ON7DQ

Dave New
 

Hans,

Here is an excellent article on debouncing, by Jack Ganssle:


He walks you through all the issues of debouncing switches in both hardware and firmware.

I particularly like the multiple input debounce firmware showing in Listing 3 in part 2.  With a little thought, it can be easily adapted to a non-interrupt polling scheme, if need be.

I used a polling adaption of this in a little project using the STM32F4VE eval board (which can be had on Amazon for an amazing $10), which had on-board micro-switches.

The ST Micro eval boards are amazingly low cost, and the ST Link USB programmer required to flash them is also on Amazon for about $10.

Tons of fun for $20.

73,

-- Dave, N8SBE

-------- Original Message --------
Subject: Re: [QRPLabs] QCX rotary encoder remote button issue #qcx
#problem
From: "Hans Summers" <hans.summers@...>
Date: Fri, November 08, 2019 6:59 am
To: QRPLabs@groups.io

Ok Luc, Karlis

So I should make some firmware change to try to more fiercely debounce your crappy buttons. 

If you would send me some ones that show the symptoms, I will do it. 

73 Hans G0UPL

On Fri, Nov 8, 2019 at 2:57 PM Luc ON7DQ <on7dq@...> wrote:
Hans & others,

Just to add some momentum ... I also had this problem, but didn't consider it too serious to report.
But in my QCX20, using the internal buttons, never had any problem.
In my QCX40 I used off-board buttons (also the cheapo chinese ones), see picture (buttons were in the cover and soldered to the wires later).
the wires are somewhat twisted but not shielded.
I just did a test : go into the menu 10 times, then go to menu 4.1, change keyer type , and use the right button to exit.
This failed 6 out of 10, the right button put me back in 4.1 

Luc ON7DQ

Hans Summers
 

Hi Dave
 
Here is an excellent article on debouncing, by Jack Ganssle:


He walks you through all the issues of debouncing switches in both hardware and firmware.

Nice article! 

All the buttons in QCX use the same firmware debounce that I developed for the original Ultimate kit, which was then re-used on all subsequent kits (Ultimate2, Ultimate3/3S, VFO, Clock, ProgRock). I have found it to be very reliable (until now!) for several years now. 

A more difficult debounce challenge was the rotary encoder. I did quite a lot of research on this and found nothing that worked well. Debounce was either done in hardware with resistors and capacitors, which makes me shudder in uncontrollable horror, or was done very poorly in firmware. I developed my own method which I later did find an internet example of, far more eloquently written than mine, that involves a state machine for the debounce. Logically it was equivalent to the scheme I had developed but was more nicely explained. SOMEWHERE I have documented this rotary encoder scheme I use, in an article - I forget where. 

Hardware debounce is fine but, if you have a microcontroller involved anyway then I much prefer to do it in software. Then you have easy control over everything, you can develop much more sophisticated debounce schemes than in hardware, and at zero component cost. Also you can change it later via a firmware upgrade if needed. 
 
I used a polling adaption of this in a little project using the STM32F4VE eval board (which can be had on Amazon for an amazing $10), which had on-board micro-switches.

The ST Micro eval boards are amazingly low cost, and the ST Link USB programmer required to flash them is also on Amazon for about $10.

I'm familiar with ST boards too and have many here. An STM32 micro is at the heart of the forthcoming QSX and U4B projects. 

A nice feature of the timers in the STM32 is that they can be configured to handle all the rotary encoder logic without any processor code, including debounce. Very cool. 

73 Hans G0UPL

G0UON - Jim
 

Hans,

So I should make some firmware change to try to more fiercely debounce your crappy buttons. 
 
If you would send me some ones that show the symptoms, I will do it. 
 

 Happy to send you my problematic button. Can you email an address?

 Thanks for being so responsive on this (and every issue!). 

73, Jim G0UON