Re: Keypad for Raduino...?

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




Join BITX20@groups.io to automatically receive all group messages.