Getting multiple values from single key

[reryro]

Hi Alan, great work on this. But I've got a couple problems. I'm working with the same Sony tuner you used and I've wired the switch board matrix to the same GPIO pins as you did (just not necessarily in the same sequence).

First problem: flask_api.py doesn't seem to run (I added some debug logging, but log file isn't created), so I don't get any response to my key presses. I wanted to confirm the wiring before I proceed any further, so I wrote a test-keys script that mostly uses your keypad matrix handling code, and when I run it:

Second problem: each button gives me a different output value every time I press it. Strangely, each button will generate 3 or 4 different values and keep repeating those same values as I repeatedly press that button -- but a different set of 3 or 4 values for each key, with some overlap. I thought it was a bounce issue, so I added debounce, but same result.

Any idea what's happening here? And why don't you see any bounce issues with your code -- does pad4pi or Rpi_gpio include that?

Lastly, any thoughts on why flask_api doesn't run? I followed all the install instructions, especially the "docker compose up -d" which you note "should always load on its own going forward".

[alanb128]

Hello @reryro that is strange behavior on your key presses. Did you remove the original microprocessor and fluorescent display from your control board? Also make sure you don't connect that board to the Pi's ground pin. I did not use any debouncing because mine didn't seem to need it. I also suggest trying to get the keys working outside of Docker and moOde audio, perhaps on plain Pi OS. Hope this helps and good luck!

[reryro]

Yes, I did remove both the IC and the display, and I also ran my test script outside of Docker and Moode. And no, I didn't connect the switch matrix to Pi ground or Vcc -- even though every schematic I've seen online for wiring up switch matrices show power connections, both positive and ground.

I'm going to try 10k pull-up resistors on the inputs (or is it outputs? I'll have to double check that) and see if that helps...

But I still have the issue of flask_api not running -- any ideas on what I may have missed there? I don't have much experience with Docker, but I'm sure I followed all the steps.

[alanb128]

It's a bit tough to troubleshoot the key press issues - even control boards of the same model may have subtle differences. I would say go back to basics - maybe even build a simple 2x2 or 4x4 key matrix and test the code...
For flask_api are you sure the container is running? You could check by running docker ps and see if the container is crashing (uptime would be short, like 30 seconds) I'll be revisiting this project again in the near future so hopefully I can simplify it a bit.

[reryro]

I really appreciate you taking the time to respond, so much so that I'm not going to wear out my welcome with a continuing series of questions, so I'll just say this -- it's really been so frustrating to invest so much time in acquiring the parts, disemboweling the tuner, and then wiring it up to the Pi and spending dozens of hours trying to tweak the code to make it work, that I just can't bring myself to give up on it. I like too much the concept of re-using all those great buttons, so I'm going to see if I can cut the board traces and connect the switches directly to individual GPIO pins. I just hope I can find enough available after satisfying the DAC hat and display needs.

I look forward to your "revisit" of this project -- especially if that results in further insights into the "mysterious" matrix. There's one aspect of that that I have a hard time wrapping my head around -- the fact that it scans for a pin that's gone low, and then while it's low, it scans again for another pin's change in state, in order to identify which unique switch was closed. But these scans take a discreet amount of time to process, and all the while, debounce delay must be introduced in order to suppress any spurious signals -- but too much delay and you've lost the signals of the two pins. I'm just not sure how that timing works (and in my case, doesn't) and how to go about tweaking it without making it even worse.

Thanks again, Alan.

[alanb128]

You're welcome! Before you give up and start cutting traces though, check for cold solder joints on the push buttons/diodes. Two of my tuners had that and it was very tough to track down the issues it was causing.

I might eliminate the key matrix in my next revision even though it has actually worked fine for me but I agree its operation is mysterious!

[reryro]

Ah, interesting! And a great suggestion -- if you saw it on two different chassis in a such a limited sample, that tells me that it's very likely a widespread problem. I'll check mine today. Thanks, and congrats on the catch. I'd never have thought of that!

[reryro]

No response expected on this, just thought I'd update on the off chance anyone is following this thread (my sympathies to you). I went thru the board, resoldering all of the switches and the diodes, though I may have missed some of those. The results were different from before, so I apparently fixed some problems, but alas, there were still problems.

So I gave up on the matrix -- I cut all the board traces around the switches and connected directly to them. Since I didn't have enough GPIO pins for all the switches plus the DAC plus the LCD, I inserted a MCP23017 I/O expander between the switches and the Pi. Then I first coded it in a simple polling algorithm -- that worked perfectly (after discovering and fixing some incomplete trace cuts). But not happy with perfection :-( I decided I'd rather use the MCP23017's interrupts and get rid of the polling.

That has introduced its own problems -- interrupts sometimes not executing, switch bounce causing the interrupt clear to fail, lengthening bounce delay causing even more interrupts to be missed, etc. So, I guess I'm going back to polling...or maybe I'll just switch to crossword puzzles to occupy my mind...