IBM LPFK & Arduino Nano.

MMcM

13 Jun 2021, 05:33

That's disappointing. Do the LEDs on the LPFK turn on briefly when you first apply power to it? If you put it into loopback mode, do key presses "echo" via the LED underneath?

User avatar
raoulduke-esq

13 Jun 2021, 05:51

Neither of those things happen unfortunately. Not even a blink of light at any time from either keyboard upon connection or in loopback. New cable is on the way.

https://www.amazon.com/dp/B004Y4WRFY

Hoping for change!

MMcM

13 Jun 2021, 15:32

Okay. In the meantime it should be possible to isolate a power fault with just a cheapo multi-meter.
  • When not connected, does the cable have continuity for 1, 2, (row of two), and 5 (staggered one on middle row of three)?
  • When connected only to the device, is there continuity between 1 and 2?
  • When connected only to the converter, is there 5VDC between 1 and 5?
Power is all that's needed to see LEDs blinking sans communication.

User avatar
raoulduke-esq

13 Jun 2021, 19:32

MMcM wrote:
13 Jun 2021, 15:32
Okay. In the meantime it should be possible to isolate a power fault with just a cheapo multi-meter.
  • When not connected, does the cable have continuity for 1, 2, (row of two), and 5 (staggered one on middle row of three)?
5 appears to not be connected inside the cable, which fills me with joy. We'll see if the new cable is any better.

User avatar
raoulduke-esq

15 Jun 2021, 01:42

MMcM wrote:
13 Jun 2021, 15:32
  • When not connected, does the cable have continuity for 1, 2, (row of two), and 5 (staggered one on middle row of three)?
  • When connected only to the device, is there continuity between 1 and 2?
  • When connected only to the converter, is there 5VDC between 1 and 5?
Power is all that's needed to see LEDs blinking sans communication.
New cable came today adding another $13 to the pyre.
  • Appears to have continuity on all pins.
  • Yes
  • Yes
Blimey. No startup blink, no keystrokes registered, nothing in loopback mode...

Tried copying over your latest version and replacing my local. When I compile locally with

Code: Select all

make converter/ibm_lpfk:default
I get a converter_ibm_lpfk_teensy_lc_default.bin in my qmk_firmware dir. I do not know how to flash a bin to a Teensy LC using Teensyduino or QMK toolbox so instead I use

Code: Select all

make converter/ibm_lpfk:default:teensy
It compiles, I press the button when instructed, I get this:
Screen Shot 2021-06-14 at 7.31.02 PM.png
Screen Shot 2021-06-14 at 7.31.02 PM.png (167.54 KiB) Viewed 613 times
so I run the make command again and the Teensy is still in boatload mode and it works.
Screen Shot 2021-06-14 at 7.40.39 PM.png
Screen Shot 2021-06-14 at 7.40.39 PM.png (398.3 KiB) Viewed 613 times
QMK toolbox recognizes the device as QMK IBM LPFK keypad converter(FEED:6094:0001). No blink of LEDs, no keystrokes recognized, etc.

User avatar
raoulduke-esq

16 Jun 2021, 00:56

I'll add these to the body of evidence as well... Purchased NIB/sealed and nothing looks too crazy inside.
IMG_0657 copy.jpg
IMG_0657 copy.jpg (2.74 MiB) Viewed 568 times
IMG_0658 copy.jpg
IMG_0658 copy.jpg (3.6 MiB) Viewed 568 times

MMcM

16 Jun 2021, 03:59

Yes, everything looks newish. Did you try measuring power to all the chips? As I said earlier, for loopback mode all they need is 5V and the other signals don't matter. And if there were a short between 5V and ground, USB wouldn't work. Furthermore, I thought the power-on state was to light all the LEDs and the MCU had to run for them to turn off, though I could be misremembering that.

User avatar
raoulduke-esq

16 Jun 2021, 04:19

MMcM wrote:
16 Jun 2021, 03:59
Yes, everything looks newish. Did you try measuring power to all the chips? As I said earlier, for loopback mode all they need is 5V and the other signals don't matter. And if there were a short between 5V and ground, USB wouldn't work. Furthermore, I thought the power-on state was to light all the LEDs and the MCU had to run for them to turn off, though I could be misremembering that.
I will certainly try testing the chips. Is the compiling/flashing behavior (including make error) I’m getting the expected behavior? Should I be getting a .bin and loading it with :teensy in the make command?

MMcM

16 Jun 2021, 05:31

All these 74-series TTL chips have ground in the lower-left and +5 in the upper-right, so those are easy to check.

This is fine

Code: Select all

make converter/ibm_lpfk:default:teensy
For future reference, an equivalent that works with other kinds of MCUs that I usually use is

Code: Select all

make converter/ibm_lpfk:default:flash
But it ends up running exactly the same command.

The new qmk command line script has some subcommand that magically figures out what to load based on your directory, but I haven't adjusted my working style to use it.

Having it be a little flaky talking to the bootloader isn't that unusual. For me, it is usually bouncing the reset button because the board is at some kind of awkward angle. It starts loading and then I reset it all over again and it's confused. If it worked the second time and seems to enumerate to the OS as a keyboard, I don't think that's the issue.

User avatar
raoulduke-esq

19 Jun 2021, 02:07

MMcM wrote:
16 Jun 2021, 05:31
All these 74-series TTL chips have ground in the lower-left and +5 in the upper-right, so those are easy to check.
Curiouser and curiouser... It would appear the MAX232 onboard is the only chip getting power. Here I've circled the only spots on the board where I can detect 5v.
IMG_0658 copy.jpg
IMG_0658 copy.jpg (3.59 MiB) Viewed 470 times

So either the whole rest of the board is busted? Or is there some signal it's supposed to receive to activate the rest of the board?


Appreciate the flashing tips- I'll give :flash a shot next time just for the convenience of being general purpose!

MMcM

19 Jun 2021, 05:45

Don't assume that the pin numbers on CN1 are related to the pin numbering of the DIN standard.

The pin you have circled on U2 is 14. (The dot on the lower-right is next to pin 1. Count left from there to 8, then cross over and count right.) This chip has 16 pins. Vcc is two to the right of there. You can see from the photo that this is definitely connected to pin 14 of U3. There is a big old trace with C25 written in the middle of it. That chip only has 14 pins, so that's power, too. I bet it's connected to the rest of them, too, but you could check.

Is pin 5 of CN1 really connected to pin 5 of the DIN socket here? I rather suspect it's connected to pin 3.

More importantly, is +5V from your converter really coming into that pin? We're aiming to confirm that this is managing to power these chips.

User avatar
raoulduke-esq

19 Jun 2021, 18:00

First- thanks for the troubleshooting steps. I really appreciate your help!

I'll include some photos as I go for the sake of documentation.

The socket includes helpful numbers that make identifying which colors correspond to which pins even easier.
IMG_0668 copy.jpg
IMG_0668 copy.jpg (643.64 KiB) Viewed 425 times
The socket goes:

1 = Brown (ground)
2 = Red (ground)
3 = Orange (TX)
4 = Yellow
5 = Green (5V)
6 = Blue
7 = Purple
8 = Gray (RX)

This matches from top to bottom what one finds on CN1.
IMG_0667 copy.jpg
IMG_0667 copy.jpg (735.11 KiB) Viewed 425 times
So on the back side, 5th pin down (green) is 5V. I get 5.1v there with multimeter.
Screen Shot 2021-06-19 at 11.37.07 AM.png
Screen Shot 2021-06-19 at 11.37.07 AM.png (172.53 KiB) Viewed 425 times

IMG_0658 copy.jpg
IMG_0658 copy.jpg (565.02 KiB) Viewed 425 times
I probed every other point on the board.

Pin 8 on CN1 reads -5.66.
The two pins on R37 read 5.1.
Pin 14 on U2 reads 5.1.
Pin 16 on U2 reads 0.
Pin 14 on U3 reads 0.
C6 reads 5.1.
C4 and C5 show about 0.1 or 0.2

Everything else shows no voltage.

jmaynard

19 Jun 2021, 18:09

Hm. I'd want to know how +5 gets from the junction of C6 and R31 to the board's +5 bus. There's where your problem lies - or at least one of them.

User avatar
raoulduke-esq

19 Jun 2021, 18:32

Indeed. Here we can see a tracing of what is currently happening... Maybe we can identify also the path of what should be happening?
Front.jpg
Front.jpg (2.06 MiB) Viewed 412 times
Back.jpg
Back.jpg (792.9 KiB) Viewed 412 times

MMcM

19 Jun 2021, 20:14

Okay. I see what is happening. I apologize for not noticing this earlier.

First off, the wires on both the DIN-8 socket and the PCB connector are the same as here and fine. Moreover, they are in EIA color code order: Brown, Red, Orange, Yellow, Green, Blue, Violet, Gray.

However, the cable that I have, which came with it, reverses the signals on each row. Did yours come with a cable? I know you've swapped it out a few times and apparently the latest one you have is straight through.

So, you need to reverse the signals on your converter to match what is, in fact, the order on the board. But not the one coming from the standard(?) cable.

User avatar
raoulduke-esq

19 Jun 2021, 20:31

Interesting, but nothing needing an apology :) Mine did not come with a cable so these are just straight-through serial cables where 1=1, 2=2, etc.

So to reverse on each row on the plug on my converter it should be:
1 no change because ground
2 no change because ground
3 5v
5 TX
6 RX

Did I understand that correctly?

MMcM

19 Jun 2021, 20:47

raoulduke-esq wrote:
19 Jun 2021, 20:31
Did I understand that correctly?
Yes. Give that shot.

User avatar
raoulduke-esq

19 Jun 2021, 22:53

Bingo.
IMG_0671 copy.jpg
IMG_0671 copy.jpg (3.61 MiB) Viewed 353 times
Thanks for all of the back and forth on this and for this solution!

User avatar
raoulduke-esq

20 Jun 2021, 02:36

MMcM do you experience the following with yours?

- Load default keymap
- F keys register nice key presses as expected
- Media keys do not to anything except register as single keypresses in the console
- Add EXTRAKEY_ENABLE to rules.mk to enable media keys; re-flash
- Media keys now function like a held typematic key even though I only press once. So I press volume down and the volume continues going down and then it's like the key stays held down until I unplug the converter.

MMcM

20 Jun 2021, 04:10

Good call on EXTRAKEY_ENABLE. Looks like it got lost in the conversion to the expanded info.json.

The stuck media keys seems to be a timing problem with how QMK tries to pretend Chibios isn't async. Since there are no up transitions, it clears the matrix on the very next scan. But if the previous report hasn't completed, that gets dropped or something along those lines. Anyway, I added a delay before the auto-release that I hope will take care of this. Let me know.

User avatar
raoulduke-esq

20 Jun 2021, 05:29

MMcM wrote:
20 Jun 2021, 04:10
Let me know.
That did the trick!

It's been a really lousy week - lots of suck at work, death in the family, etc. Getting this thing working was a moment of joy; thanks for doing so much to make that happen.

Post Reply

Return to “Workshop”