Topics

Keypad for Raduino...?

Arv Evans
 

Hello

I got tired of the minimalist input button scheme for my uBITX Raduino.  Found this
on-line, and am now working on code to make use of it for a homebrewed Raduino.

http://www.technoblogy.com/show?NGM

More info later when I get everything working.

Arv
_._

Mark Pilant
 

Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built. (Before I
found out about the PHSNA :-) It turned out to work very well. I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design. I had both in my design. Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key. (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder. (If I can find the time... too many projects :-)

73

- Mark N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA

Jack, W8TEE
 

On Sunday, June 24, 2018, 1:34:36 PM EDT, Mark Pilant <mark@...> wrote:


Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built.  (Before I
found out about the PHSNA :-)  It turned out to work very well.  I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design.  I had both in my design.  Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key.  (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder.  (If I can find the time... too many projects :-)

73

- Mark  N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA




Mark Pilant
 

Hi Jack.

I don't think I'd use an analog approach to it....
The "electronic code lock" keypad approach works great if you have lots of
I/O pins available. But where I was using an UNO, I was quickly running out
of I/O pins. So by using the analog approach, I only needed one I/O pin (as
well as +5VDC and ground).

As I see it, the trade off is mostly in the additional code needed for the
analog approach. Although as I've been doing software engineering for way
too long (O/S, real time, embedded, etc.) it wasn't a big deal for me.

73

- Mark N1VQW

Arv Evans
 

Mark  N1VQW

I built a similar SNA, but control it via USB/tty link from a Raspberry-Pi. 

The keypad idea of using a single ADC input to decode keystrokes seems
intriguing to me.  This morning I set up the code so it uses a range of voltage
values for each key, and added a time delay for debounce.  using a voltage
range window seems to give me latitude enough for using standard value
resistors in the R-matrix.  Initially I set up the code to just show the value as
each key was pressed, then rewrote it to use those values as targets. 
I divided the difference between voltage values for each key by 2 and used
that to generate the tests for each key.  Code is not efficient yet as it is just a
bunch conditionals but once it is working I can go back and make it pretty. 
Next question is how much will RF affect the keystroke voltage readings?

This activity is generating some interesting thoughts about possibilities for a
new Raduino design...with OLED display, Keypad, Rotary Encoder, RTC,
Si5351a, and more.

Arv  K7HKL
_._



On Sun, Jun 24, 2018 at 11:34 AM Mark Pilant <mark@...> wrote:
Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built.  (Before I
found out about the PHSNA :-)  It turned out to work very well.  I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design.  I had both in my design.   Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key.  (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder.  (If I can find the time... too many projects :-)

73

- Mark  N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA




Arv Evans
 

Jack

I did consider that approach, but my original intent was to use the minimum number of
Arduino pins that could still support desired functionality.  This should open up pins for
doing much more than the existing Raduino can do.  While first application will be for
uBitx and BITX-40, it may evolve into a more generic controller for other radio designs.

If nothing else it is a good exercise to help me recover some of the age induced loss
of C-coding skills. 

Arv
_._


On Sun, Jun 24, 2018 at 11:42 AM Jack Purdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
On Sunday, June 24, 2018, 1:34:36 PM EDT, Mark Pilant <mark@...> wrote:


Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built.  (Before I
found out about the PHSNA :-)  It turned out to work very well.  I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design.  I had both in my design.  Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key.  (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder.  (If I can find the time... too many projects :-)

73

- Mark  N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA




Jack, W8TEE
 

That whole idea of using voltage to determine keyer state makes me nervous. Even something as simple as corrosion on the contacts can make a difference. Take Field Day. Some CW operators bring their own paddle sets to the event and switch when it's their turn at the helm. It's possible for something that simple to make enough of a difference to screw things up. Farhan worked out a solution that was defined by the constraints within which he had to work. My solution is to throw a new processor with a small forest of pins at the problem, which I've done. Others have gone to a less pin-intensive solution for the LCD display (e.g., I2C or SPI), thus freeing up pins that can directly read paddle states. Many simply don't care because they don't use CW.

You are right, however, in that the problem has caused people to rethink the problem(s) and that's almost always good. After all, if the only tool you have is a hammer, it's not surprising that all problems look like a nail.

Jack, W8TEE

On Sunday, June 24, 2018, 4:28:06 PM EDT, Arv Evans <arvid.evans@...> wrote:


Mark  N1VQW

I built a similar SNA, but control it via USB/tty link from a Raspberry-Pi. 

The keypad idea of using a single ADC input to decode keystrokes seems
intriguing to me.  This morning I set up the code so it uses a range of voltage
values for each key, and added a time delay for debounce.  using a voltage
range window seems to give me latitude enough for using standard value
resistors in the R-matrix.  Initially I set up the code to just show the value as
each key was pressed, then rewrote it to use those values as targets. 
I divided the difference between voltage values for each key by 2 and used
that to generate the tests for each key.  Code is not efficient yet as it is just a
bunch conditionals but once it is working I can go back and make it pretty. 
Next question is how much will RF affect the keystroke voltage readings?

This activity is generating some interesting thoughts about possibilities for a
new Raduino design...with OLED display, Keypad, Rotary Encoder, RTC,
Si5351a, and more.

Arv  K7HKL
_._



On Sun, Jun 24, 2018 at 11:34 AM Mark Pilant <mark@...> wrote:
Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built.  (Before I
found out about the PHSNA :-)  It turned out to work very well.  I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design.  I had both in my design.   Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key.  (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder.  (If I can find the time... too many projects :-)

73

- Mark  N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA




Arv Evans
 

Jack

But......I thought this problem WAS a nail!  8-)

I did try 4 different keypads that have resided in my junkbox long enough to have
accumulated some dust and maybe even corrosion.  You are right, one of them (an
escapee from a long dead calculator) did show intermittent decoding, but after a bit
of exercise it now seems more reliable.  I built the initial resistor matrix external to
the keypad so I can try different keypads.  Maybe it would be worthwhile to try
making a discrete switch based keypad from 16 of the tiny push-switches that are
available for less than a cent each on Ebay? 

Long ago I purchased a few keypads which have plastic domes that click over-center
and make hard mechanical closures (with lots of contact bounce).  If I can find them
they will get tried in the present testbed.  Might be interesting to see what is required
to debounce those antiques. 

Being an ancient telephone engineer the concept of "sealing current" comes to mind
as a possibility for use based improvement of questionable keypads.  Another option
is that they are usually very inexpensive and thus the bad ones can be trashed with
no regrets. 

This is fun!  8-)

Arv
_._


On Sun, Jun 24, 2018 at 2:42 PM Jack Purdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
That whole idea of using voltage to determine keyer state makes me nervous. Even something as simple as corrosion on the contacts can make a difference. Take Field Day. Some CW operators bring their own paddle sets to the event and switch when it's their turn at the helm. It's possible for something that simple to make enough of a difference to screw things up. Farhan worked out a solution that was defined by the constraints within which he had to work. My solution is to throw a new processor with a small forest of pins at the problem, which I've done. Others have gone to a less pin-intensive solution for the LCD display (e.g., I2C or SPI), thus freeing up pins that can directly read paddle states. Many simply don't care because they don't use CW.

You are right, however, in that the problem has caused people to rethink the problem(s) and that's almost always good. After all, if the only tool you have is a hammer, it's not surprising that all problems look like a nail.

Jack, W8TEE

On Sunday, June 24, 2018, 4:28:06 PM EDT, Arv Evans <arvid.evans@...> wrote:


Mark  N1VQW

I built a similar SNA, but control it via USB/tty link from a Raspberry-Pi. 

The keypad idea of using a single ADC input to decode keystrokes seems
intriguing to me.  This morning I set up the code so it uses a range of voltage
values for each key, and added a time delay for debounce.  using a voltage
range window seems to give me latitude enough for using standard value
resistors in the R-matrix.  Initially I set up the code to just show the value as
each key was pressed, then rewrote it to use those values as targets. 
I divided the difference between voltage values for each key by 2 and used
that to generate the tests for each key.  Code is not efficient yet as it is just a
bunch conditionals but once it is working I can go back and make it pretty. 
Next question is how much will RF affect the keystroke voltage readings?

This activity is generating some interesting thoughts about possibilities for a
new Raduino design...with OLED display, Keypad, Rotary Encoder, RTC,
Si5351a, and more.

Arv  K7HKL
_._



On Sun, Jun 24, 2018 at 11:34 AM Mark Pilant <mark@...> wrote:
Hi Arv.

I used a similar keyboard for a Scalar Network Analyzer I built.  (Before I
found out about the PHSNA :-)  It turned out to work very well.  I did run
into a few issues worth mentioning.

Make sure you have some form of switch debouncing (software or hardware) as
part of the design.  I had both in my design.   Also, make sure you take into
account the resistor tolerances when determining the analog value for any
given key.  (Part of my SNA design was a set of calibration tasks, one of
which was the keypad.)

I'm building a uBitx with a TFT, and may include a soft keypad to augment the
encoder.  (If I can find the time... too many projects :-)

73

- Mark  N1VQW

BTW, feel free to look at the SNA code: https://github.com/pilant/N1VQW-SNA




Jerry Gaffke
 

I've got a black dial phone from perhaps the 40's. in the basement somewhere.
That would be very cool to have as the UI into my uBitx.
Won't want to get just too aggressive with the debouce.


On Sun, Jun 24, 2018 at 01:58 pm, Arv Evans wrote:
But......I thought this problem WAS a nail!  8-)

I did try 4 different keypads that have resided in my junkbox long enough to have
accumulated some dust and maybe even corrosion.  You are right, one of them (an
escapee from a long dead calculator) did show intermittent decoding, but after a bit
of exercise it now seems more reliable.  I built the initial resistor matrix external to
the keypad so I can try different keypads.  Maybe it would be worthwhile to try
making a discrete switch based keypad from 16 of the tiny push-switches that are
available for less than a cent each on Ebay? 

Long ago I purchased a few keypads which have plastic domes that click over-center
and make hard mechanical closures (with lots of contact bounce).  If I can find them
they will get tried in the present testbed.  Might be interesting to see what is required
to debounce those antiques. 
 
Being an ancient telephone engineer the concept of "sealing current" comes to mind
as a possibility for use based improvement of questionable keypads.  Another option
is that they are usually very inexpensive and thus the bad ones can be trashed with
no regrets. 

This is fun!  8-)

Arv Evans
 

😛


On Sun, Jun 24, 2018 at 3:05 PM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
I've got a black dial phone from perhaps the 40's. in the basement somewhere.
That would be very cool to have as the UI into my uBitx.
Won't want to get just too aggressive with the debouce.


On Sun, Jun 24, 2018 at 01:58 pm, Arv Evans wrote:
But......I thought this problem WAS a nail!  8-)

I did try 4 different keypads that have resided in my junkbox long enough to have
accumulated some dust and maybe even corrosion.  You are right, one of them (an
escapee from a long dead calculator) did show intermittent decoding, but after a bit
of exercise it now seems more reliable.  I built the initial resistor matrix external to
the keypad so I can try different keypads.  Maybe it would be worthwhile to try
making a discrete switch based keypad from 16 of the tiny push-switches that are
available for less than a cent each on Ebay? 

Long ago I purchased a few keypads which have plastic domes that click over-center
and make hard mechanical closures (with lots of contact bounce).  If I can find them
they will get tried in the present testbed.  Might be interesting to see what is required
to debounce those antiques. 
 
Being an ancient telephone engineer the concept of "sealing current" comes to mind
as a possibility for use based improvement of questionable keypads.  Another option
is that they are usually very inexpensive and thus the bad ones can be trashed with
no regrets. 

This is fun!  8-)

DuWayne Schmidlkofer
 

One of the easiest ways to do this might be to use a I2C expander configured something like this board from Microchip https://www.microchip.com/DevelopmentTools/ProductDetails/GPIODM-KPLCD
You could control the keyboard and display over I2C and free up the existing display pins for other uses.


--
DuWayne  KV4QB

Arv Evans
 

DuWayne

Might work fine but one of my objectives is to reduce parts count to just what is
necessary for the functionality I want.
That is what drove me to using just one ADC input for the keypad.

Arv
_._


On Sun, Jun 24, 2018 at 3:26 PM DuWayne Schmidlkofer <duwayne@...> wrote:
One of the easiest ways to do this might be to use a I2C expander
configured something like this board from Microchip
https://www.microchip.com/DevelopmentTools/ProductDetails/GPIODM-KPLCD
You could control the keyboard and display over I2C and free up the
existing display pins for other uses.


--
DuWayne  KV4QB



Mark Pilant
 

Hi Jack.

That whole idea of using voltage to determine keyer state makes me nervous.
Even something as simple as corrosion on the contacts can make a difference.
True.

But then again I figure if I know how it works, and with some appropriate
debug code always built in, it would be pretty easy to track down a keypad
problem. Partially to address this issue, my SNA code has a min and max for
each key value and includes a calibration menu item to determine the average
value to use (which is then used to calculate the min and max). Not only does
this work for resistors that are slightly different values (but still within
tolerance) and can handle a slight variation in contact resistance as well.

If I wanted to really minimize contact issues, I'd use something other than a
(USD) $5-$10 keypad :-) I used the cheap one because the SNA started out as
not much more than a simple proof of concept. Funny how proof of concept
projects become the final project :-P

You are right, however, in that the problem has caused people to rethink the
problem(s) and that's almost always good.
I couldn't agree more. Maybe other will get some ideas from my SNA code. (I
haven't done a whole lot more with it since I picked up an HP 8591E spectrum
analyzer with a tracking generator. Although I was pleased to see my little
SNA agreed with the HP SA :-)

73

- Mark N1VQW

GM4CID
 

The 16 key TTP229 capacitive touch keypad might be worth considering as an easy low cost external keyboard solution for the uBitx,
it worked well for me on another Arduino project

See http://hobbycomponents.com/sensors/585-ttp229-16-key-capacitive-keypad

Another interesting possibility is using an Android phone or tablet as a touch screen controller
communicating bluetooth to a module at the uBitx.

73 Bob GM4CID

Mike Woods
 

I have one of these keypads (which includes a resistor matrix  built in for connecting to an analogue pin)

https://robotdyn.com/button-keypad-4x4-module.html

I have yet to deploy it ... a future project.

Robotdyn also has an i2c controller for capacitive keys and the associated keypad

https://www.aliexpress.com/item/16-Keys-Capacitive-touch-TTP229-module-I2C-bus/32672496161.html
https://www.aliexpress.com/item/Capacitive-Touch-keypad-for-Capacitive-module-16-keys/32673211969.html

Mike ZL1AXG

On 25/06/18 9:11 PM, Robert McClements wrote:
The 16 key TTP229 capacitive touch keypad might be worth considering as an easy low cost external keyboard solution for the uBitx,
it worked well for me on another Arduino project

See http://hobbycomponents.com/sensors/585-ttp229-16-key-capacitive-keypad

Another interesting possibility is using an Android phone or tablet as a touch screen controller
communicating bluetooth to a module at the uBitx.

73 Bob GM4CID


--
Mike Woods
mhwoods@...

Arv Evans
 

Bob GM4CID

That capacitive keypad is interesting, especially vecause it apparently has I2C bus
interface capability.  Since the Raduino design already includes I2C for the Si5351a
and in my case for an RTC, the keypad could probably share the same bus.
Price is not excessive which is a big plus as well.

Thanks for the info.

Arv K7HKL
_._


On Mon, Jun 25, 2018 at 3:11 AM Robert McClements <gm4cid@...> wrote:
The 16 key TTP229 capacitive touch keypad might be worth considering as an easy low cost external keyboard solution for the uBitx,
it worked well for me on another Arduino project

See http://hobbycomponents.com/sensors/585-ttp229-16-key-capacitive-keypad

Another interesting possibility is using an Android phone or tablet as a touch screen controller
communicating bluetooth to a module at the uBitx.

73 Bob GM4CID

Jerry Gaffke
 

Could work.
Though scanning a keypad with i2c will consume a lot more processor time
than just reading some IO pins.


On Mon, Jun 25, 2018 at 08:02 am, Arv Evans wrote:
That capacitive keypad is interesting, especially vecause it apparently has I2C bus
interface capability.  Since the Raduino design already includes I2C for the Si5351a
and in my case for an RTC, the keypad could probably share the same bus.
Price is not excessive which is a big plus as well.

GM4CID
 

Arv,

The TTP229 capacitive  keyboard has two pins labelled SCL and SDO but unfortunately they are not I2C.

The way that they work is SCL is clocked frequently up to 16 times and during each clock cycle SDO is
checked. If a key is pressed SDO will return a Low, the count stops and the clock count equates to
the key number. Hope that makes sense, not easy to put into words.

So this device will require the use of two digital pins.


Regards,

Bob GM4CID

Sample code below :-

 // Routine to read if a key is pressed and return its value
byte Read_Keypad(void)
{
   byte Count;
   byte  Key_State = 0;
   for(Count = 1; Count <= 16; Count++) // Pulse the clock pin up to 16 times and read the state of the data pin on each pulse
   {
      digitalWrite(Clock_PIN, LOW);
      if  (! digitalRead (Data_PIN)) // data pin low store the current key number
         Key_State = Count;
      digitalWrite(Clock_PIN, HIGH);
   }
   return Key_State;

Arv Evans
 

Jerry

I'm still sticking with my resistor matrix on an ADC port, mostly because I already have the
keypads and this effort is for my own use.  When it is finished (if it gets finished) someone
else may want to duplicate the design as a commercial project, but I'm not going to take on
that level of effort and involvement. 

It seems that the time delay for debouncing a mechanical scanned keypad versus that for
polling an I2C slave may be about equal...?  For the resistor matrix and ADC approach it
now looks like just reading the ADC once (or more if required) in each pass around
"void loop()" will be adequate. At present I'm doing a double read if the value is not zero to
insure that the keypress is valid.  Time to do these reads seems adequate for debounce
requirement.  If the second read is still non-zero it is taken as a valid keystroke and calls
a routine to interpret ADC-to-character and handle the entry.

Arv
_._




On Mon, Jun 25, 2018 at 9:23 AM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
Could work.
Though scanning a keypad with i2c will consume a lot more processor time
than just reading some IO pins.

On Mon, Jun 25, 2018 at 08:02 am, Arv Evans wrote:
That capacitive keypad is interesting, especially vecause it apparently has I2C bus
interface capability.  Since the Raduino design already includes I2C for the Si5351a
and in my case for an RTC, the keypad could probably share the same bus.
Price is not excessive which is a big plus as well.

Arv Evans
 

Bob GM4CID

Okay.  Thanks for the heads-up.  I might have some day proceeded blindly thinking
that this was an I2C or TWI data bus.  Guess that is another reason why I am going
ahead with my existing junkbox keypads and resistor matrix approach. 

My guess is that there probably are I2C keypads, or that some sort of bus adapter
IC would work, but I'm not going there for the immediate future.

Thanks,

Arv  K7HKL
_._


On Mon, Jun 25, 2018 at 9:38 AM Robert McClements <gm4cid@...> wrote:
Arv,

The TTP229 capacitive  keyboard has two pins labelled SCL and SDO but unfortunately they are not I2C.

The way that they work is SCL is clocked frequently up to 16 times and during each clock cycle SDO is
checked. If a key is pressed SDO will return a Low, the count stops and the clock count equates to
the key number. Hope that makes sense, not easy to put into words.

So this device will require the use of two digital pins.


Regards,

Bob GM4CID

Sample code below :-

 // Routine to read if a key is pressed and return its value
byte Read_Keypad(void)
{
   byte Count;
   byte  Key_State = 0;
   for(Count = 1; Count <= 16; Count++) // Pulse the clock pin up to 16 times and read the state of the data pin on each pulse
   {
      digitalWrite(Clock_PIN, LOW);
      if  (! digitalRead (Data_PIN)) // data pin low store the current key number
         Key_State = Count;
      digitalWrite(Clock_PIN, HIGH);
   }
   return Key_State;