SOLVED - 122 Key Lynk Model M - WORKING with Soarer's Converter

[orihalcon]

FIX IS TO USE VERSION 1.03 of Soarer's Firmware.  Version 1.10 and on seem to break the compatibility of the Lynk model M.

____________________________________________________________________________

I recently got some brand new Lynk 122 Key terminal model M's (Part Numbers LX-122-US / 901022-50) with the intention of adding LEDs and internal Soarer's converters to make them available to those who might want them but not have the time or are unable to do the mod themselves. 

After receiving them, when I tried them with Soarer's Converter, I get pretty much the same non-legitimate scan codes (nothing but "R06" in HID_listen for example) for every key pressed.  There is of course no output either because of this.  The kicker is that about 1 in 20 or 30 presses of the exact same key registers the CORRECT scan code for that key instead of the useless "R06" in this example, which proves that the controller board is capable of working, but there's something that keeps it from doing so consistently.

The exact same issue is described here:
http://geekhack.org/index.php?topic=57632.0

The control board looks identical to one of my other older Lexmark manufactured Model M's except that one resistor is shifted over one place and I tried moving the resistor to match the other one and that didn't make a difference.  The main controller IC are both made by Lexmark, but the part numbers are different, pretty much proving that Lexmark did manufacture the Lynk ones as well, but there’s something different about them controller board hardware-wise.

I've tried adding pull up resistors to both clock and data and have tried all three different scan code sets (code set 3 is auto detected and that is correct).  I also swapped both capacitors from the known working Lexmark one and the Lynk, and the Lexmark one continued to work while the Lynk one still did not, confirming that the capacitors are still good. I also swapped the blue oscillators which again made no difference.

I also tried using that identical control board from the Lexmark with the keyboard part of the Lynk and it does generate real scan codes consistently, but the membranes on the Lynk have a slightly different matrix so some keys don't register at all whereas other keys usually register as a key shifted over a letter or two.  This proves that the actual membrane and hammers are good (which isn't really a surprise seeing as the boards are brand new), but also makes it so that I can’t use older controller boards since the matrix is different. 

At this point I’m out of ideas on how to fix this and what to do with the boards if I am unable to get them to work since they are non returnable.  I could part them out as brand new cases and keycaps, but it seems a shame to do that to a brand new model M, let alone a bunch of them.

[0100010]

Do you know if the Lynx 122 ever worked?  Sounds like the chip isn't flashed or is corrupt (but I am not an expert).

[berserkfan]

For starters have you tried hooking up to a Model M terminal keyboard controller? These are very common since many people buy these behemoths for cheap to get a set of buckling spring caps. Maybe we should see if the controller is the issue.

[Grendel]

Getting correct codes once in a while would point to the converter having problems receiving them. This could be caused by the signals out-of-spec (levels to low, timings off, ringing.) If you can, hook up an oscilloscope to the data/clock lines and take a look at what exactly is going on betw. the board and the converter.

[orihalcon]

Thanks for the input everyone!

I've tried the converter with three different new Lynk 122 keyboards and they all have the exact same behavior.  The thread linked in the original post was from another guy that had the exact same issue with his, so I'm thinking they all behaved this way from the factory, but something about the Lynk terminal must have compensated for the oddball signals that it is outputting that isn't correctly recognized by Soarer's converter. 

An oscilloscope definitely sounds like a good way to chase down the problem, but I don't have one or any experience using them.  I agree, the fact that the correct scan code does come out at least sometimes (though it is rare) does support there being something about the signal which isn't up to spec.  I was really hoping that pull up resistors would fix it if it was a simple low voltage issue, but that has made no difference in my tests.  Could be something where one of the original resistors on the board needs to be a different value, but again, I am not sure how to chase down how each resistor affects the circuit and an oscilloscope would be needed to see progress in the signal changing more towards what it should be.

Using the Lexmark Terminal Model M controller always outputs real scan codes, the scan codes usually are off by a key or two whereas some keys don't produce a scan code at all because the membranes are a slightly different patterning.  The rare times that the original Lynk controller does output a scan code, it is always the correct one for the key that was pressed.  Since this is consistent and the keyboards are new, it leads me to think that the actual IC isn't corrupt, but that the signal is slightly off.

As an added bonus, I've decided that for the person that finds the fix, I will also reimburse the $40 paid for the test keyboard, so if you are confident in your abilities, you could end up with a free new 122 Key Model M and $100 cash. 

Again, If a fix is found, I will post for everyone else so that they can fix theirs as well. 

Seems pretty likely that oscilloscope skills and general knowledge of the controller circuit will be needed to find the solution.

[Oobly]

I suggest trying to hook it up to your PSU 5v supply (or a USB hub with external power supply), to see if it's getting enough juice. That big chip on the board is actually a processor and it needs a lot more power to operate (0.5W just for this chip) than most newer PS/2 or USB boards. That doesn't explain why the Lexmark board works, but it's something more to try.

[orihalcon]

I suggest trying to hook it up to your PSU 5v supply (or a USB hub with external power supply), to see if it's getting enough juice. That big chip on the board is actually a processor and it needs a lot more power to operate (0.5W just for this chip) than most newer PS/2 or USB boards. That doesn't explain why the Lexmark board works, but it's something more to try.

I just tried it with a powered hub and that didn't seem to make a difference.  Thanks for the suggestion though!

[Oobly]

Okay, worth a try. Well maybe you can learn how to program EF6805U3 microprocessors and replace the firmware then A bit too much hard work I think, though.

You say you've tried 4.7kOhm pullup resistors on the clock and data lines and you've tried forcing the converter to each of the 3 scancodes?

I'm out of ideas then unless you can get hold of an oscilloscope to trace signals or you replace the controller with a Teensy or design your own. It is just a simple matrix membrane after all. If you make your own controllers you don't need converters.

If you use a Teensy 2.0 you can modify the Phantom firmware for extra rows and custom layout.

[berserkfan]

I looked at my own model M terminal controllers and can see this



Not sure why one controller had so many components and the other had so few. Externally they looked the same.

There are 28 connectors so I'm guessing a teensy 2++ is necessary? But it should be easy to run jumper cables from the main board to a teensy. Since you are going to replace the controller with a teensy anyway, why not just run jumpers straight to the teensy and see if that works?

I hope I didn't waste your time with this suggestion.

[orihalcon]

I looked at my own model M terminal controllers and can see this
(Attachment Link) (Attachment Link)


Not sure why one controller had so many components and the other had so few. Externally they looked the same.

There are 28 connectors so I'm guessing a teensy 2++ is necessary? But it should be easy to run jumper cables from the main board to a teensy. Since you are going to replace the controller with a teensy anyway, why not just run jumpers straight to the teensy and see if that works?

I hope I didn't waste your time with this suggestion.

All suggestions are welcome!

I know for some terminals, different scan code sets were supported, and some of it might also be speaker related for those models that had the speaker.  It's pretty clear that the extra components aren't necessary for core functions since the ones with fewer components work exactly the same.

I probably wouldn't want to replace the main IC with a teensy since it would be pretty expensive and require a lot of unsoldering and time to remove the IC without damaging the solder pads since it is so large.  If I was doing this to just one board, it would be interesting to experiment with, but I have several that I want to get working and I've already invested quite a bit in them so far.

I really think that the signal just needs to be modified in some way with a change of one of the onboard resistors or other components since it sometimes does output the correct scan code after repeated pressing of one key.  I just don't have any oscilloscope skills or knowledge of the actual circuit to know what to modify to bring it up to the regular spec.

Any oscilloscope masters out there?

[berserkfan]

I know for some terminals, different scan code sets were supported, and some of it might also be speaker related for those models that had the speaker.  It's pretty clear that the extra components aren't necessary for core functions since the ones with fewer components work exactly the same.

I probably wouldn't want to replace the main IC with a teensy since it would be pretty expensive and require a lot of unsoldering and time to remove the IC without damaging the solder pads since it is so large.  If I was doing this to just one board, it would be interesting to experiment with, but I have several that I want to get working and I've already invested quite a bit in them so far.

I really think that the signal just needs to be modified in some way with a change of one of the onboard resistors or other components since it sometimes does output the correct scan code after repeated pressing of one key.  I just don't have any oscilloscope skills or knowledge of the actual circuit to know what to modify to bring it up to the regular spec.

Any oscilloscope masters out there?

No soldering needed to remove these controllers.

Why not post pictures of your own controllers? Some people on geekhack have eagle eyes and can quickly spot a resistor that needs to be changed or something. Other folks have lots of experience. It may be that Lynx keyboards are actually no different than other terminals and you merely got a bad batch which could be fixed with replacing just one component.

At worst, you can probably recover initial costs because there's a movement to build a 122-terminal using Cherry MX pcb and unicomp casing. So you can always sell the parts and not lose a cent.

[Melchior]

What tools do you have?

I'd check that there is ~5V(or 3.3V ?) power on all IC's at least.

Some multimeters have crude duty cycle / frequency counters - might be good to see if there any activity from the crystal and/or clock (or address selector, whathaveyou)...

You'd be surprised how cheap (8Ch) Logic analysers have become, they can be had for $10USD on ebay....

[Oobly]

...
I probably wouldn't want to replace the main IC with a teensy ...

Just to clarify, what myself and berserkfan are suggesting is NOT replacing the main IC on the board, but replacing the whole controller board with a Teensy 3.1 or Teensy++2.0. The 3.1 has 34 IO lines and the ++ has 46 so either of them would have enough pins to connect the membrane contacts directly and have some output lines left for adding LED's if you felt like it. The most complex part would be coding the firmware, but you could modify the Phantom firmware to work with the Teensy++2.0 without too much work I think. You'd also have to map the membrane to modify the layout in the firmware to match.

That way you don't have to play around trying to get scancodes out of a board you don't know a lot about and you won't need a converter at all.

Then you can mount it in the case with the MiniUSB port at the cable exit.

[Halvar]

Soarer's controller (not converter) firmware runs on the Teensy 2++ if I'm not mistaken, and it can be configured for a Model M.

[0100010]

How would one attach the membrane traces to the Teensy directly?

Cut the existing board?  Custom board similar to xwhatsit's?

[berserkfan]

How would one attach the membrane traces to the Teensy directly?

Cut the existing board?  Custom board similar to xwhatsit's?

didn't you see my Model M controller pictures?

Model M membranes have membran-ed leads coming out that feed into the controller via the belkin or whatever connectors you can see in my photos. These connectors also take standard jumper cables which will fit the standard pins on a teensy w pins. So it is just a question of swapping the original keyboard controller with a teensy, then figuring out the matrix.

At least, that is what I think. Probably will be proven wrong within a few posts.  )

[Halvar]

To connect it directly to a teensy might be hard 

You need what I think is called "FFC connectors".

[orihalcon]

Hmm, I know it probably is doable to switch out the controller, but the time and expense (especially for the larger teensy that would have enough pins to do it) and added learning curve for how to program it wouldn't be worth it for me.  Other issue is that I'd want the end result to have the same easy to use Soarer's converter programming, which would probably be disrupted as the matrixes would have to be mapped as well.

I really think the stock setup is really close to working since it sometimes registers the correct scan code instead of the usual invalid ones.  Something must be slightly off with the actual output signal.  Could be low voltage that the standard pull up resistors aren't correcting or maybe even too high of voltage.  Maybe the signals are too short?  Only way to know for sure is with an oscilloscope which I do not have. 

I guess if I can't find someone that wants to take a stab at it, I might get a lower end oscilloscope and experiment with that.  I imagine the learning curve for those is somewhat steep as well, but the overall time cost would be a lot less than replacing the stock controller since I have a bunch of these Lynk keyboards that I want to get working.  Plus, It would be good to share a simple solution with everyone, which may just end up needing to change or remove a resistor from the stock controller. 

Any suggestions on a somewhat simple to use oscilloscope that would work for this project?  I'm still thinking that it would be a lot easier for someone with oscilloscope experience to figure out though. 

I also was thinking that if shipping or the upfront $40 cost mentioned above ended up being the costly part, I could just send the controller instead of the entire board.  You'd just need to tap the membrane pins to mimic key presses and look for the signal abnormality.  Not having to send out the whole heavy keyboard would keep the cost down for me and I could mail some controllers out to anyone who wants to try to figure it out and pay the return shipping.  You'd still get the $100 reward if you find a solution that I can reproduce and there'd be no upfront costs. 

Any takers?

[orihalcon]

Ok, so I bought an oscilloscope.  This one looked like it should have enough features to figure this out:
http://www.amazon.com/gp/product/B00GQNN70A/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

Probably will just end up selling this oscilloscope right away after I (hopefully) figure out the problem.

My guess is that it's going to be a steep learning curve since I've never used one before outside of a single college physics lab several years ago...  I assume put channel 1 as clock, and channel 2 as data and compare between the a Model M controller that works and the Lynk 122 that doesn't and hope for something obvious. 

From there, I assume I'll need to start switching controller components like resistors and capacitors until I can get the signal to look more like the one that does work.  Are there any Oscilloscope tutorials on Geekhack or elsewhere that anyone would recommend?

Are there any known guides out there on how the controllers work or how certain resistors and capacitors affect the final output signal? Somehow, I doubt it, but figure it can't hurt to ask.

Thanks for all the input so far!  Will definitely post a Lynk 122 fix if I find one!

[berserkfan]

Hi Orihalcon

I know its off topic, but do you mind telling us how/ where you get the SDRL connectors for your cables? A friend of mine wants to make his own model M cables and he said getting the SDRL part was the hardest part.

[orihalcon]

PM'd you about the connectors.

[orihalcon]

Well, I tried the oscilloscope out, took me a while to figure out how to get it to show me what I wanted, but I think there's enough info there to hint at what is going on. 

I compared the output of pressing and holding the letter "Q" on both the Lynk and an IBM 1394100 since the controller boards almost look identical with the exception of the placement of 1 resistor (which I have tried moving to match without success).

The IBM gives a momentary signal, flatlines immediately, and then a different signal when the key is released. 

The Lynk shows its signal constantly while held down, and it gives a short different signal after release.

Other big differences are that the IBM starts with high voltage and drops down to create a signal and uses a uniform more rapid clock pattern.  The Lynk starts low and increases voltage to create the signal and has a slightly longer initial clock voltage drop and fluctuates slower.

Pictures attached.

So it looks like there's a different protocol entirely being used here, but I still find it odd that Soarer's converter does identify the key press every 20 presses or so, even though the signal looks a lot different.  I used the same Soarer's converter on both with default settings.

Can anyone identify that protocol?

[hasu]

Seems like Lynk keyboard spits out valid XT code(code set 1), I don't know why the converter misses this signals. Did you try forcing it XT protocol?

Code: [Select]

force set1


[0100010]

I have nothing more to contribute to OPs issue, but in searching to try to learn more about this issue I found a lot of info that I had not seen before.

Model M PS2 controller layout : http://www.kbdbabel.org/schematic/kbdbabel_doc_ibm1394796.pdf
Blue Cube USB adapter direct : http://zevv.nl/play/misc/ibm-usb/
Model M controller direct wire : http://geekhack.org/index.php?topic=14647.0
Additional pull up resistor control mod : https://freeshell.de/~luis/model-m/jszybowski/index.htm
Similar controller picture from Sandy's page : http://sandy55.fc2web.com/keyboard/keyboard.html

OP - I assume the resistor you moved was the one from R5 to R15.  Can only find data on PS2 controllers, nothing on terminals.

[orihalcon]

Thanks for the input everyone! I didn't really consider XT as a viable contender since the board was nearly identical to the 1394100, but I guess that would make sense now that I've dug out my XT Model F and compared the output.  I had tried force set1 in the past and tried again with no luck with the Lynk just now. 

I thought it might help to have an XT sample using the same scope to see if there are any noticeable difference, and it turns out that there is!

Looks like a difference in clock speed (not sure that is the correct term) and that has got to be the problem.  I've stacked the oscilloscope screenshots of the XT model F (which does work with the converter) against the Lynk using the same scales.

Now that I look back at the Oscilloscope output of the 1394100, seems the clock speed there is also faster there too.  Seems like that is the standard across different protocols and the Lynk is slow.

Any ideas on how to speed that up by changing any specific board components, or is that likely not possible?

[Grendel]

I would suggest to contact Soarer and point him to this thread, normally I wouldn't expect a clock speed variation on this scale to break the converter. Something he needs to take a look at IMHO.

[Oobly]

I noticed the clock speed difference in the earlier post, been a bit busy to answer here. Check the crystals on all the boards (the blue blob close to the big chip) and compare the markings. They usually have the frequency marked on them. If the Lynk has a different frequency marked on it, try switching the crystals between the boards. If it's the same frequency, the difference signal speed is probably due to the coding on the main processor and will be hard to change.

[hasu]

I would suggest to contact Soarer and point him to this thread, normally I wouldn't expect a clock speed variation on this scale to break the converter. Something he needs to take a look at IMHO.

+1
Soarer has made no post for this several months, I hope he did not bail on us and his converter
The most desirable story will be that he comes back and gets the reward.

Thanks for the input everyone! I didn't really consider XT as a viable contender since the board was nearly identical to the 1394100, but I guess that would make sense now that I've dug out my XT Model F and compared the output.  I had tried force set1 in the past and tried again with no luck with the Lynk just now. 

Hmm, Lynk is slow but seems to me very straightforward signaling for XT. No wonder to me that other XT coverter can handle Lynk.

My wild guess is that Soarer had fix of XT protocol to support wild 'Leading Edge' keyobard at v1.10 and this may cause this problem. I think older version has somewhat straighforward implementation. Try v1.03.

[orihalcon]

I actually did try switching the blue crystal / Oscillator earlier and that didn't make a difference.  Both were marked the same.

Yeah, I would have asked Soarer first, but figured that I would try my best to solve it on my own, since I know he's busy.  Buying the oscilloscope myself and getting the output would probably make the question a lot easier for him to answer now since I now know what the actual problem is.  I'd definitely send Soarer the $100 for adding support for this board and I'll try contacting him in a week or two if I can't get anything else figured out myself.  That would be easiest for everyone and there would be no special workarounds required.  I also might see about commissioning a "turbo mode" feature, since I think that is really all that is missing in terms of possible features (at least that I've thought of).

I'll have to try the Version 1.03 and get back to you guys. 

Thanks again for all of the suggestions!

[hasu]

Yep, we definitely need him. To disassemble and patch the binary is not productive labor

And his "turbo mode" is how to detect change of switch matrix immediately, so it does not relate to converter.

[orihalcon]

Ah, I was thinking of a "turbo mode" more like telling the keyboard to emulate key press and release and specify the frequency for doing so.  Could be useful in gaming I figure where you are supposed to manually rapidly press a button over and over to fire for example.  Could just hold the a key down and have the Soarer's Converter do the heavy lifting!

[orihalcon]

Problem solved! Hasu's comment about trying version 1.03 instead of the current 1.12 did it.  Something about updating the XT protocol to support other models later on broke the function for the Lynk version.  Hope that helps someone else out there!

[berserkfan]

I feel very happy to read this.

Hate it whenever I hear that some poor geekhacker can't make the stuff he invested money in work. So all 122 keys are fully programmable if you use Soarer 1.03? Have you fully run this to make sure its ok? (Because if you rely only on the default quite a number of keys on a M122 terminal are in weird places, and if they can't be reprogrammed for standard modern layouts that will still suck.)

[orihalcon]

I feel very happy to read this.

Hate it whenever I hear that some poor geekhacker can't make the stuff he invested money in work. So all 122 keys are fully programmable if you use Soarer 1.03? Have you fully run this to make sure its ok? (Because if you rely only on the default quite a number of keys on a M122 terminal are in weird places, and if they can't be reprogrammed for standard modern layouts that will still suck.)

Yeah, A lot of the keys are in weird places, but it seems that each key does generate a unique scan code.  Only problem that I have found is that the "Dup" key which is where the "home" key normally is and the F19 Key, generates C1 and B0 scan codes respectively, which are not named in Soarer's documentation (those codes were discontinued in .997).  I don't want to go back that early because of the possibility of bugs.  I don't think those keys can be remapped without Soarer updating the code while reverting the XT recognition back to how it was in 1.03 so that they keyboard still works.  I just messaged him asking if he would be willing to do that for a price for his time. 

I figure there's lots of other keys that "home" and "F19" can be remapped to, but it would be awesome to have all of the keys working though!

[hasu]

hmm, C1 and B0 are HID codes or scan codes received from keyboard?
Can you post output of hid_listen which you get when pressing "Dup" and F19?

If former can you remap with FAKE_18 and FAKE_01? These codes are depricated but it seems to me they can be used yet.

[berserkfan]

Did Soarer respond to you first time round? Hope he's still around!

[orihalcon]

Hasu, you were right, you can still use the depreciated names and now everything works! I just assumed that you couldn't since the documentation says that "they should no longer be used." 

As for Soarer, last time I heard back from a question I had was April 10th, and I was asking him if he would be ok with me making pre-built Soarer's converters and I also offered him a commission on each unit sold.  He said he was fine with me selling the converters but that he didn't need a commission at all...  Here we are 6 months later, and I still don't have some made, but I'm hoping to within the next month.

Soarer's profile shows that he's been online recently, but my guess is that he is busy with other projects at the moment.   

[hasu]

Great.

So, in the end the keyboard -- Lynk 122 Key terminal model M's (Part Numbers LX-122-US / 901022-50) -- speaks a bit slow but straightforward XT protocol and can work with Soarer's converter *version 1.03*(not after 1.10-) and probably other XT converters also can do the job.

This is not the best ending but not so bad. Of course, the best was that Soarer comes back to release new version and get the reward.

disclosure: I got the reward from orihalcon

[ezrahilyer]

I assume the ones that went up on Ebay today are yours? they look very nice. :-)
I just posted in my own thread about them, before I looked at your thread.

Looks like you really worked hard to get them running!

[orihalcon]

Yep, the ones up on ebay now are mine.  Having the main remapping done in advance will help some people I hope.  If you look at the key map that I posted in the auction, it's kind of all over the place in terms of where the scan codes are, but they all remap just fine!

I think the build quality, Soarer's Functionality, and two tone keys of the Lexmark trump the ones you can buy from Unicomp now.  I'm more of a fan of the two tone keys instead of all grey that Unicomp offers now.  I think their new PC-122's probably even cost a little more when you figure in shipping.

It's also a cool feeling to type on something that was manufactured almost 20 years ago and have it be brand new!