yashsingh1/xdaforums huggingface dataset:
[Mechanical keyboards] krbjmpr:
Yup, that is the panel that I am using. Swap the 2 -1 and 4-3 to restore order. It took me a few moments to figure out what I had done wrong.

The +5v was confusing to me as well, as up to this point I had not seen a 5vdc bus used like this. Turned board over, and confirmed that the switch pins along edge of pcb are 5v, and pins along inside edge of controls side are 5vdc as well. I would guess that it lends some additional resistance to noise as well. Noise level would have to be awful high to trip an input. Active High inputs.

I do need to measure current, and see where exactly the trip threshold lies. I thought this encoder featured actual analog inputs, but it doesn't look like it. I really could have used an X-Y plot for an idea that I have in my head. And speaking of which, I need to remember to grab my other meter from work. It has the resolution to check very small current flow.

Have also been looking at capacitance solutions. Did not realize that the wires tacked onto the 4-pad switches (Amazon ASIN B0BXDMJKXF) would be so touchy, nearly as much as the intended pads are. Some way of insulating them further will be needed to use successfully. Maybe I can use RG316 coax with grounded shield. There is a calibration routine that is run at startup if switch is not in use.

Thinking that once I get this finished, gonna work on a arduino solution. Make a nice control / automation panel, haven't played with software latch or hardware latch for relays yet. Arduino for additional switch inputs, but it appears that I have 20 at my disposal. Still too early to tell just yet.
[Mechanical keyboards] Renate:
A capacitive solution is ok, but if you are extending wires you will need to be able to program the limits yourself.

A handy-dandy fixed purpose board may or may not allow that.

OTOH, it should autozero on startup but the range may be limited.

I use a generic capacitive sensor (12 inputs) on a water tank.

The difference between water there or not is about 5 pF.

I forget what the base value was, about 20 pF?

Handling contact inputs robustly is more than loose wires and a 50k pullup/down internal to a µC.

I had a friendly competition with someone on this theme.

To prove my design was fairly robust I drew 1/2" sparks from a neon sign transformer off the case while operating the pushbuttons glitch free.
[Mechanical keyboards] krbjmpr:
Interesting...

I was thinking how to integrate tank sensors into the display panel. Hence desire for analog inputs.

Currently using SeeLevel2 system, and though it works, looking for something a bit more robust and resilient. Sensors are okay, display leaves much to be desired.

I have no issues cutting a hole in top of tanks and using a top-mounted sensor that hangs into tank.

Small steps, need to get display working first.
[Mechanical keyboards] Renate:
I do propane with an Infineon "3D" magnetic sensor. Good for ~1%.
[Mechanical keyboards] krbjmpr:
Soldered the header extension cables to the 2pin cables coming off the encoder. The 5 wires (male header) are somewhat unstable in switch connector, had to use heat shrink to stabilize. It isn't really bad, just will be a bit of a PITA if have to change for any reason other than switch position on the encoder.

Now have 12 switches ready to be assigned. Was hoping to use Accessibility Universal Switch to at least control media, but no. There is limited actions that can be assigned, I remember there being a lot more, but may have been a specialized app running. As it is, for Global Actions, I can select / assign: Back, Home, Recents, Open Notifications, Open Quick Panel, Volume Up, and Volume Down. For Screen Actions, I can assign "Tap Screen" and "Touch and Hold Screen", both being specific areas. If I can figure out how to create shortcuts to open apps windowed, then would be able to leave a small sliver of screen preset with apps shortcuts. That would give a rudimentary method of app switching. But overall, still limited to what the external switches can actually do.

It looks like Key Mapper will become a permanent resident. Also started playing with Activity Launcher (also open source) to create shortcuts to activities. Of course the most interesting ones require root, which I will not be doing on test device. *My* target is rooted (of course) so will be able to take advantage. Again, goal is to create a universal type of interface that has high repeatability when attempted by others.

Capacitance switches... I think that you are 100% correct that calibration will run, but it may not be able to account for a changing environment like when a wire moves, vibration, etc. I think that using Cat5/6 will go far in this regard. Will only be able to run 4 switches per cable, but it is cheap, easy to work with (especially compared to the likes of RG316). Haven't figured out how to connect switches to ethernet yet without using breakout / punch down boxes, but may not have to worry about it much if the wires can just be immobilized before the ethernet transition. May also be connecting the unused "blue" wires to ground, and creating something of a twisted pair. Perhaps that will help with capacitance. Small steps...
[Mechanical keyboards] Renate:
I had a Tinkerkit DMX module that listed for $50 that I bought at clearance for $5.

You could reprogram it to just be a general purpose USB to 4 relays.

I still use it for odds and ends testing like reset lines and power sequencing.

You can also do a "battery-ectomy" on the tablet.

It requires reusing the BMS or using suitable resistors.

I'm running a Walmart Onn 8" on a 4V buck converter.

I'm no fan of short/long press differentiation.

It means that on a short press it will react on release and not press.

If you give your Intent the flag Intent.FLAG_ACTIVITY_NO_ANIMATION then the apps will switch instantaneously. I like that.

Did you ever measure input current?

You may find that things get whacky when you turn on your windshield wipers or something.

A car environment is quite hostile.
[Mechanical keyboards] krbjmpr:
Current

Haven't measured switch input current yet. Will do that at work today. Quiescent current of encoder is 30-low 40s mA measured using a USB Power Analyzer. When I check today, will also see what kind of response key Mapper gives to pri and secondary joystick inputs.

Battery

'Battery-ectomy' is in the plans eventually. The tab active series have pogo pins along bottom long edge for charge and usb functionality. My tab active3 has an actual 'no battery mode' that when enabled, it expects power from pogo or USB. Battery can be left in place, or removed. The family also sports user-removable batteries.

That being said, I do plan on gutting a battery, and setting term3 / temp sensor for 80°. Vehicle battery will need to be modified, at least heavier wiring. I get horrible voltage drop when starting, and can see it in output of 5v Buck converters I have tested in past. plan is to separate starting and 'everything else batteries. Got 24 headway 38120 cells on the way...

ONN

Funny you mention Onn tablets. Few years ago, walmart had 7 or 8 inch models on clearance. Thought these would be great on forklifts in warehouse. And they were. Connected to WiFi, ran SAP client easily, but screen refresh / scroll made several drivers nauseus. The tablets also did not tolerate the vibrations of forklift very well. After 2 weeks, returned all 12 back to Walmart, and got my $120 back. Yup, $10 a piece, clerk had stashed behind counter. 2020 model I think.

Have you seen jitter in yours when scrolling / switching apps?

App Switching

No intent needed for killing automation. I killed that in dev options. I should have mentioned that. While in there, also turned on "Show Taps" to make instructional screen recordings easier to follow along. And USB Debug. And app alternate source, etc. I wish could get wireless debug to remain enabled permanently. Haven't figured that out yet. For Shizuku use mostly, so no big deal.

Short/Long switches

Key Mapper has short by default, long and double are options. I can't tell you if encoder triggers on rising or falling edge. Key Mapper just says the keyboard code present and if repeated or not. I do plan on modifying source code to add triple press, but think that will be the longest practical. May be able to use apk editor, haven't been that far yet.
[Mechanical keyboards] krbjmpr:
Current

Encoder itself sraws 30-50mA, probably closer to 35 as it tendsbto bounce between 30 and 40.

All inputs have a .5mA (half mA) draw when shorted.

Voltage on 5vdc bus was 4.96vdc at time of measurement.

Oddly, the LED ports are labeled +5v and GND, but joystick is labeled as ground, but is actually +5v with same current draw. Though I have draw, key mapper does not seem to recognize the joystick switches. So still stuck at 12, but is possible to have board read analog voltage. Kindvof pointless if cantbget Android to easily see the data.

Draw remains the same regardless of mode the PCB is in, red / blue light.
[Mechanical keyboards] Renate:
So, better than I thought, ~10k.

Still, if you have problems you can throw resistors in and make it a few mA.

Are you sure that it's not joystick pots?

Do you have the full HID report descriptor out of this thing?

It's easy if you're on Linux or have a hardware protocol analyzer. :p
[Mechanical keyboards] krbjmpr:
Nope, not potentiometers, though there is a mod to enable linear signals.

No full hid descriptor yet. I have found a couple references to driver change as well as an environment change when connected to MAME or Winblows.
[Mechanical keyboards] krbjmpr:
I did find a bit more information.

-This encoder is based on CY-822B.

-Current draw is 30-40mA, not 50mA (mistype on my part)

-Both joysticks are mirrors of each other, so potentially only 4 more switches possible.

-The analog / digital modes don't apparently do anything for me without some piece of software being aware of joystick inputs. And a config file detailing what to expect. This based on RetroPie, Mame, etc having issues with some switches, and config file needing to be edited.

-Keymapper does identify the board, as DragonRise something or other, so might be able to find more information there. Delving into the Android system is going to require root, perhaps adb will work if only the tablets had adb shell (dammit!) functionality.

-As it stands, I have 12 switches to play with, with possibility of adding 4 more. I think it may be easier / faster / more practical to add another encoder board into the fray and gain 12 more switches. The PCBs based on the CY-822A are able to be modded for 10kohm pots for joystick (4 inputs labeled as AU, AD, AL, AR, identified as H+, H-, V+, V-), potentially for acquiring data from a changing voltage. Half a mA should prevent loading sensors, but time may tell.
[Mechanical keyboards] Renate:
Discrete inputs make sense for an arcade console, but something matrix compatible would be more useful for what you want, wouldn't it?

I do 16 buttons with 8 wires, but of course there are no diodes so you can't do multiple at once.

I have a 25 key MIDI keyboard (with diodes) that I built using those Adafruit elastomer keys.

(I used it to send out macro sequences on a desktop.)

There's always the problem of labelling the keys.

I used to like the square buttons with a clear cap under which you could put either a paper or plastic printed label.

If your use is dashboard labelled buttons would be cool. For head-banging steering wheel, less so.

If you do decide to add resistors, 0805 SMDs could be easily "globbed" on from the unused third pin to the center pin.
[Mechanical keyboards] krbjmpr:
Agreed, matrix would be FAR more customizable and functional. But, it tends to dampen diy enthusiasm as it becomes more complex to implement a custom panel. Remember my target audience is anticipated / intended to be as technically 'know-how' endowed as we are. KISS!

Ideally, a keyboard encoder that features screw input connections would be ideal. Something like Ultimarc's Ipac/Ipac2/MiniPac. Cost is high, and still need to map majority of inputs on host, and perhaps media control keys as well.

I tried modding 10key pads, ghosting never was a problem, at least in my usage, as only a single switch was pressed. It was stupid easy to tack on wires from serial extension cable to 10key row/col on micro, then use a serial breakout to connect switches to. But, still only allowed a 4x4 matrix if used shield as return, 4x3 otherwise. The 'zero delay' boards gave 12 switch inputs, no matrix needed, with possibility of 4 more inputs from joystick / dpad. The additional input is the last little bit to iron out. As it is, I am happy with having 12 switches, and nearly ready to write the instructable.

For the end user, I will let them worry about keys / switches / labelling. Maybe there will be a steam punk aficionado that will want to knife switches, miniature or 5000Amp utility grade versions. Hah!

My implementation, now that logic has nearly been settled, will include aesthetics. The 1x4 touch pads are junk. Already had 1 'snap dome' collapse, keeping input closed. Luckily it was on Vol+, so no big deal, and the encoder wasn't phased a bit with continuous input. I will exorcize that today with an exacto knife. Or maybe just leave it as it really doesn't bother me, but a cut up switch, in midst of rats nest of wire, would.

Got a wild idea this morning. Use el-tape as substrate, lay silver tape trace on top down the length, and connect to +5vdc. Use 'fish paper' to create stencil / holes layer. Print icons / logos / whatever in negative image onto clear / matte finish plastic transparency sheet. Lay out individual silver foil traces (perpendicular and ultimately to switch inputs) behind each logo. Stack all together neatly and vacuum seal / thermal laminate. Now I have a switch panel, back-lit through logo, with individual outputs. Not sure how switches will respond to 90vac backplane (el-tape), so may need to decouple to an actual ground. Thin, highly flexible, cheap, well, I have the el-tape and driver already. Probably run the mess through dip switches so can isolate errant performing switches

Alternative is stack a few sheets of transparencies, notch out for smd edge illuminating LED, and use that as backlight. Could even drive, with appropriate series resistance, the LEDs via dash / console lighting. Adjust brightness to same as rest of console. If go this route, probably extract LED elements from led strip. Cost effectiveness (200+ for $15), and test all at once.
[Mechanical keyboards] Renate:
Backlight would be nice.

Fortunately, I hardly drive at night and then I wouldn't need 3 different forms of maps, solar power monitoring...

There's 24 hours in the day. Why would you have to drive in the ones with no sunlight? :p
[Mechanical keyboards] krbjmpr:
24hours... Because 2nd shift has very little traffic compared to 1st (going) and 3rd (returning).

Which reminds me...

Still need to figure out how to put a 10bazillion candle power spot light on a tracking gimbal mount. You know, for backlighting. Or forelighting. Just plain ol' spotlighting until offender turns off high beams.
[Mechanical keyboards] krbjmpr:
Had a decent day today.

Put the ZD encoder onto Win. Using a generic Microsoft driver from 2006 for game controller, all buttons are working, so is joystick. Figured out the mode. Red Light = 2 pin connectors for joystick. Blue Light = POV. Not sure what difference is, beyond XY axis and POV, but the inputs are shared / mirrored.

The Key Mapper app is able to distinguish between multiple devices, based on first 5 digits of ID. Not sure if all the ones (meaning ZD encoder) have same ID though. Will find out in a couple of days. If they are separate, then can just add additional units for additional switch capacity. If the same, then add additional *other* units for additional switches. I am good with both.

I don't know why I didn't check before, but the tablet (Wifi one) does not register the ZD encoder as an input. Makes sense as it does not try to present itself as a keyboard. Its a bit odd that a 3rd party utility can see it though. Have tried various key mapper apps, but none seem to do any better than the one that I have chosen to use.

On a different note, gave some more thought to switches that fit my particular needs. The radio surround has a nice little half inch "fake spacer" at the top that is within easy reach of driver. Not really enough room for a membrane switch, or even a mini-pushbutton, But, should be able to do capacitance switch, eventually. Until I get time, will just tolerate the existing membrane. Next year's project I guess. Add it to the list.
[Mechanical keyboards] krbjmpr:
You had previously asked...

I have my linux box up and running with duct tape and baling wire.

If I have the ZD encoder connected, how would I go about retrieving the HID report that you inquired about?
[Mechanical keyboards] krbjmpr:
Output of lsusb -v (removed extraneous)

Bus 001 Device 008: ID 0079:0006 DragonRise Inc. PC TWIN SHOCK Gamepad

Couldn't open device, some information will be missing

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 1.00

bDeviceClass 0

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 8

idVendor 0x0079 DragonRise Inc.

idProduct 0x0006 PC TWIN SHOCK Gamepad

bcdDevice 1.07

iManufacturer 1 DragonRise Inc.

iProduct 2 Generic USB Joystick

iSerial 0

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 0x0029

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 0

bmAttributes 0x80

(Bus Powered)

MaxPower 500mA

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 2

bInterfaceClass 3 Human Interface Device

bInterfaceSubClass 0

bInterfaceProtocol 0

iInterface 0

HID Device Descriptor:

bLength 9

bDescriptorType 33

bcdHID 1.10

bCountryCode 33 US

bNumDescriptors 1

bDescriptorType 34 Report

wDescriptorLength 101

Report Descriptors:

** UNAVAILABLE **

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 3

Transfer Type Interrupt

Synch Type None

Usage Type Data

wMaxPacketSize 0x0008 1x 8 bytes

bInterval 10

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x01 EP 1 OUT

bmAttributes 3

Transfer Type Interrupt

Synch Type None

Usage Type Data

wMaxPacketSize 0x0008 1x 8 bytes

bInterval 10
[Mechanical keyboards] Renate:
Does lsusb -vvv make a difference?

I've got an executable that works on RPi. It might work on whatever you've got?

Do you see anything under /dev/hid?
[Mechanical keyboards] krbjmpr:
No, no difference. Ran lsusb with both switches, output appears to be the same.

Do not have a dir at /dev/hid

Debian 11, xfce
[Mechanical keyboards] Renate:
Oops, I think I meant a device (not dir) /dev/hidraw0

If I clean my desk I can probably find a RPi, that's mostly Debian.

Oh, I did.

sudo ./hid /dev/hidraw0

05 01 Usage page (Desktop)
09 06 Usage (Keyboard)
a1 01 Collection (Application)
...
[Mechanical keyboards] krbjmpr:
hmm

sudo ./hid /dev/hidraw0

returns sudo: ./hid: command not found
[Mechanical keyboards] Renate:
Of course. hid is my executable.

Do you even have a /dev/hidraw0?

I forgot, you can also get this in:

cd /sys/bus/hid/devices
cd <something like 0003:1234:1234:0001>
cp report_descriptor mycopy-somewhere

Then post that.
[Mechanical keyboards] krbjmpr:
Yup, got hidraw0 (and 1, 2)
[Mechanical keyboards] Renate:
05 01 Usage page (Desktop)
09 04 Usage (Joystick)
a1 01 Collection (Application)

a1 02 Collection (Logical)

75 08 Report size (8)
95 05 Report count (5)
15 00 Logical minimum (0)
26 ff 00 Logical maximum (255)
35 00 Physical minimum (0)
46 ff 00 Physical maximum (255)
09 30 Usage (X)
09 31 Usage (Y)
09 32 Usage (Z)
09 32 Usage (Z)
09 35 Usage (Rz)
81 02 Input (Variable, Absolute)

75 04 Report size (4)
95 01 Report count (1)
25 07 Logical maximum (7)
46 3b 01 Physical maximum (315)
65 14 Unit (20)
09 39 Usage (Hat switch)
81 42 Input (Variable, Absolute)

65 00 Unit (0)
75 01 Report size (1)
95 0c Report count (12)
25 01 Logical maximum (1)
45 01 Physical maximum (1)
05 09 Usage page (Buttons)
19 01 Usage minimum (Button 1)
29 0c Usage maximum (Button 12)
81 02 Input (Variable, Absolute)

06 00 ff Usage page (65280)
75 01 Report size (1)
95 08 Report count (8)
25 01 Logical maximum (1)
45 01 Physical maximum (1)
09 01 Usage (1)
81 02 Input (Variable, Absolute)

c0 End collection

a1 02 Collection (Logical)

75 08 Report size (8)
95 07 Report count (7)
46 ff 00 Physical maximum (255)
26 ff 00 Logical maximum (255)
09 02 Usage (2)
91 02 Output (Variable, Absolute)

c0 End collection
c0 End collection

So, it's a five axis 8 bit joystick with a 3 bit hat sensor and 12 generic buttons.

There's also a vendor secret 8 bit input.

There's also seven vendor secret 8 bit outputs (LED control)?
[Mechanical keyboards] krbjmpr:
I have no idea about "secret 8bit input" at 81:02 or output at 91:02.

LED outputs are, at least currently, an all or nothing. They are either on or off, defaults to on, don't know if they can be turned off.

Will have to go back at some point and play with joystick portion. Using Android / Linux / Windows, could not see any response when joystick connections shorted to ground. The typical connections for this encoder is via switches, not pots, though there are mods to give analog / potentiometer functionality back. Basically, the mod is installing a few resistors, so manufacturer may have just left those off to save the .0003Yen as most users will be switch input on joystick.

Will have to see if I can get Key Mapper to look for additional data, edit apk after looking at source, I guess.

How did you view the file?
[Mechanical keyboards] Renate:
They could be PWM for all I know.

You can try sending 7 bytes to /dev/hidraw0 and see what happens.

Normally joystick + buttons + wacky vendor stuff would all use separate report IDs. This doesn't.

It's that hid executable that I haven't gotten around to really releasing, but I use it still.

If you have the actual binary in a file you can analyze that directly.

If you have a device (on *nix) you can iotctl the device and get the descriptor that way.

I use it mostly to analyze my microcontroller executables to make sure that I'm saying what I mean.

It's a common screw-up to "edit by comment".

Before:

0x75, 0x04, // Report size (4)

Oh, no, I have to make it bigger:

0x75, 0x04, // Report size (8)

Oops! You have just "editted by comment".

0x75, 0x08, // Report size (8)

That's better!
[Mechanical keyboards] krbjmpr:
I must have missed something. Editing comments?
[Mechanical keyboards] Renate:
The stuff in green is the actual code, the red is comments.

Normally, if I change my mind on something I have to change both.

I change the green to make the program do something else, I change the red to correctly document what the green is doing.

If I just change the red, that's "editting by comment" and the program behaves the same as before.
[Mechanical keyboards] krbjmpr:
Ahh, got it.

In an attempt at making the keypads easier to locate at night, I painted them with an acrylic glow-in-the-dark paint.

Don't do that. It looks terrible. And flakes off quite easily. Into my coffee mug.