Beamspring USB controller

[wheybags]

I wouldn't have gone that high normally, but I found my mam is going over to america soon, so shipping would have been free

[dorkvader]

dorkvader, i jelly ;_;
(I had jbidwatcher set to go to $200, would I have beaten you? )

I bid $75.

I'm trying to do local pick up since I'm only a few hours away, and I can save the $25 shipping fee. I think he's upcharging for shipping and doesn't want me to pick it up so he can profit more.

[xwhatsit]

Here's version 0.6 of source and schematics.

New stuff is mostly concerned with supporting the Model Fs and Beamspring Displaywriters in the same codebase, and of course the schematics and PCB layouts for those new controllers.

Concerning the standard beamspring specifically:
- Rev4 controller (schematics/PCB/firmware support)
- Revamped GUI layout to be less horrendous
- Support for solenoid driver (you will need the solenoid driver board, and a Rev4 controller, with the expansion port, unless you want to do some crazy ninja soldering directly to the ATmega32U2)
- Support for LEDs through that same expansion port
- Allows column skipping if (like with the 5251) you don't have any keys on that column—would speed up scanrate marginally
- Slightly slower overall scanrate for more noise robustness (solenoid can make scary stuff happen)
- Tweaked autocalibration, result will probably end up a bit higher

ibm-capsense-usb_0.6.tar.gz

(495.8 KiB) Downloaded 228 times

[xwhatsit]

And here is v0.6.1.

This fixes a reasonably major issue on Windows 7 64bit (I think?) which had major issues with the two keyboard descriptors (the fake padding of the boot-mode 6-key only interface was freaking it out and causing the NKRO descriptor to get sent STALLs).

There was also a major bug in the GUI util which prevented 8-row keyboards (Model Fs and Beamspring Displaywriters) from displaying their top four rows of scancodes on layers 1–3.

There was also a minor padding bug in the descriptor for the NKRO interface with the addition of the LEDs; neither Linux or Mac OS X cared, but it really annoyed Windows.

I've also got binaries compiled on Windows and Mac OS X, along with pre-compiled hex files for all the variants so far.

As always, use the old version of the util to put the keyboard into the bootloader first, then flash the keyboard. Afterwards, use the new version of the util to talk to it. Make sure you pick the right hex file to match your board type and revision!

You can download them all here: http://linode.cornall.co/ibm-capsense-usb/0.6.1/

[xwhatsit]

First Beamspring Displaywriter board.

Hopefully ship off for testing on Monday

[mr_a500]

- Support for solenoid driver (you will need the solenoid driver board, and a Rev4 controller, with the expansion port

Awesome. You have any boards made that I can buy yet?

[quantalume]

I have an extra Rev3 controller for anyone who doesn't need the solenoid capability. Actually, it wouldn't be that hard to solder a lead onto the processor pin to drive the solenoid board, which I intend to do at some point.

[xwhatsit]

I have an extra Rev3 controller for anyone who doesn't need the solenoid capability. Actually, it wouldn't be that hard to solder a lead onto the processor pin to drive the solenoid board, which I intend to do at some point.

Yes I've been mulling that over, the best way to handle that—with the Rev3 board, there's four pins on the right-hand-side of the microcontroller that are completely unused. If I set up the pins in such a way that one of the middle ones was an output and the other three were set as floating inputs, then you wouldn't need to be particularly careful with the soldering at all. You still need Vcc and GND of course though, which maybe would be easiest to steal off one of the bypass caps?

Technically the solenoid driver board requires two signals, `enable SMPS' and `fire solenoid', but you might be able to get away with bridging the enable SMPS signal just to Vcc (just technically not to USB spec, as will draw more than 100mA before it's enumerated).

[xwhatsit]

Awesome. You have any boards made that I can buy yet?

You have a Rev3 don't you? If you want I'll swap you with a Rev4 if you like (if you don't want to do ninja soldering); I normally use a skody old Rev1 board in my 3727. I have a solenoid driver board, with the ugly green wire modification as photographed earlier. Alternatively if you can wait I'll order some Rev2 solenoid driver boards with the modification intact.

I think I'm going to set up a combined group-buy thread with this and the Model F controllers here and over at GH, just to keep track of everything and so I might be able to order a whole bunch of stuff at once.

[mr_a500]

Thanks, but no need to swap. I'll keep my Rev3 as a backup and get a "brand spanking new" (hmm...never understood what spanking had to do with new) Rev4. I don't care about ugly wiring (I won't be putting it on display), so whatever solenoid board you've got will be fine.

[Muirium]

Spanking is just one of those golden words, and images, that wants to be everywhere!

[quantalume]

I'm having some trouble building the utility on linux. I first tried the version of Qt Creator that was available in my distro's package manager (OpenSUSE 13.1). It failed to find QCommandLineParser. As that version of Qt Creator was based on Qt 4.8.5, I decided to download the latest Qt 5.2.1 from qt-project.org. It still fails to find QCommandLineParser, even though it's sitting right there in the QtCore folder (but it's finding other header files in QtCore). I added the directory explicitly to the .pro file, and now it's finding QCommandLineParser but failing to find other header files in QtCore that are included within QCommandLineParser. What's going on here?

[xwhatsit]

Ah yes, I went to version 5.2 just to get QCommandLineParser (turns out on Windows they don't have getopt/getlongopt, Qt is nice cross-platform way to solve that).

I've never used QtCreator, but it sounds like you have a conflict with both versions. There's no official package from OpenSUSE for Qt5?

Do you have the command-line tools in your path? If you type qmake --version what does it say?

If qmake gives you the right version (or you can set up your PATH so it's pointing at the right Qt), try building it from the command line:

From ibm-capsense-usb/src/util/ directory:

Code: Select all

make clean
qmake
make

If you still have dramas, I'll put in a whole bunch of #ifdefs into ibm_capsense_usb.cpp to disable the command-line stuff under Qt4.

[nourathar]

Well done! One more beamspring dinosaur clunking away

And another one:

ibm3727.JPG (79.42 KiB) Viewed 13508 times

It being a rainy saturday afternoon, I finally got around to soldering the other two rev 3 boards I had the parts for, and putting one in my 3727. This time it was pretty painless; the soldering and uploading and configuring just worked ! The 3727 is even better to type on; it feels much more solid and high-quality, even though the 5251 doesn't exactly feel sloppy at all. I only have one key that sticks down once in a while (physically, that is), so that will be a good excuse to open it up (again).

ibm3727controller.JPG (150.7 KiB) Viewed 13508 times

Which leaves me one Rev 3 board, but am I right to think that I might be able to use that controller in my Kishsaver, using the new firmware and some creativity to connect the leads ?

I have an extra Rev3 controller for anyone who doesn't need the solenoid capability. Actually, it wouldn't be that hard to solder a lead onto the processor pin to drive the solenoid board, which I intend to do at some point.

Yes I've been mulling that over, the best way to handle that—with the Rev3 board, there's four pins on the right-hand-side of the microcontroller that are completely unused. If I set up the pins in such a way that one of the middle ones was an output and the other three were set as floating inputs, then you wouldn't need to be particularly careful with the soldering at all. You still need Vcc and GND of course though, which maybe would be easiest to steal off one of the bypass caps?

Technically the solenoid driver board requires two signals, `enable SMPS' and `fire solenoid', but you might be able to get away with bridging the enable SMPS signal just to Vcc (just technically not to USB spec, as will draw more than 100mA before it's enumerated).

I would be willing to try to solder a lead to that processor pin, and perhaps I'm overconfident now, but I'd think that soldering two leads should be doable too ?

[xwhatsit]

Nice job! I see you have a 5251 and a 3727—the 3727 is my favourite too, it just feels smoother and tighter somehow. I wonder if they're all like that?

Unfortunately it won't work in your Kishsaver—I had to start design a new board etc. for Model Fs (and also beamspring displaywriters). This is because the Model Fs and Displaywriters have a 16x8 matrix instead of a 23x4. So you need double the analogue stuff (so an extra LM339 and all the associated stuff).

If you want a Model F board I'm about to put up all the details regarding that today hopefully (well, once the lawns are mowed and I've fitted a new clutch cable and....), with links to the board on OSHPark and a proper BOM.

[Muirium]

Aha: a Great White!

http://www.ebay.co.uk/itm/IBM-Displaywr ... 4ad51a71af

This is the kind of beam spring that I've used in person. A huge beast, but a pleasant one. Now who's going to outfox me this time!?

[xwhatsit]

Yes I'm intrigued by these. I'm going to send off the first Rev1 Displaywriter controller of to Dorkvader tomorrow, so hopefully these will be USB fair game shortly too

[nourathar]

Nice job! I see you have a 5251 and a 3727—the 3727 is my favourite too, it just feels smoother and tighter somehow. I wonder if they're all like that?

weird thing is that the keyboard mechanically looks very much the same between the 5251 and the 3727, and still it feels different..

Unfortunately it won't work in your Kishsaver—I had to start design a new board etc. for Model Fs (and also beamspring displaywriters). This is because the Model Fs and Displaywriters have a 16x8 matrix instead of a 23x4. So you need double the analogue stuff (so an extra LM339 and all the associated stuff).

If you want a Model F board I'm about to put up all the details regarding that today hopefully (well, once the lawns are mowed and I've fitted a new clutch cable and....), with links to the board on OSHPark and a proper BOM.

ok, apologies for not following that thread better; i'll order that new board once it's up on OSHPark, I guess i'll have most of the parts still anyway..

and..

thanks again for doing this !

[xwhatsit]

I'm having some trouble building the utility on linux. I first tried the version of Qt Creator that was available in my distro's package manager (OpenSUSE 13.1). It failed to find QCommandLineParser. As that version of Qt Creator was based on Qt 4.8.5, I decided to download the latest Qt 5.2.1 from qt-project.org. It still fails to find QCommandLineParser, even though it's sitting right there in the QtCore folder (but it's finding other header files in QtCore). I added the directory explicitly to the .pro file, and now it's finding QCommandLineParser but failing to find other header files in QtCore that are included within QCommandLineParser. What's going on here?

If you download version 0.6.2 (go to http://linode.cornall.co/ibm-capsense-usb/0.6.2 ), that will now build under Qt4 (you just won't have the command-line goodies).

[quantalume]

I found Qt5 in the SUSE package manager, but that didn't seem to help any. I was able to get version 0.6.2 built, but it looks like it needs the 32-bit version of libhidapi-libusb to run, which I can't seem to find anywhere. Oh well, no big deal, I'll just continue to use windows for the utility.

One nice thing about firmware 0.6+ is that my keyboard is a lot more reliable now. I was having trouble finding a threshold at which all the keys worked consistently. It's rock solid now. Thanks for all the work you've put into this.

[xwhatsit]

Hmm weird that it wants 32-bit version of libhidapi-libusb; if you're running 64 bit and compiled it as 64 bit it should want the 64 bit version of libhid (i.e. the one it's been compiled against). Did you tell Qt Creator to compile it as 32 bit by accident? I think you can do that, not very familiar with Qt Creator as I mentioned; things seem pretty foolproof from the command-line running Arch Linux, but I couldn't say how the SUSE guys set it up.

That's interesting you were having problems before. I've allowed much more time for the caps to drain between columns now; it slows down the scan rate a touch but does give more leeway. Was it a difference between columns or a difference between rows? If rows, what tolerance did you use for the 100K drain resistors? If columns, was it partcularly a problem between the very first column and the others?

If it's working good now then great, but I'd like to understand why there was an improvement

[quantalume]

It was mostly a difference between columns. I had to turn the threshold up to around 140 (auto threshold suggested around 95) in order to pick up the first column (F1, F3, etc.), but then certain other keys would start showing up as pressed even though they weren't.

Once I got Qt5 installed, I used qmake and make from the command line. Something seems to be broken with Qt on SUSE, which is strange given that KDE is SUSE's flagship desktop.

[xwhatsit]

Ah I see, good. Yes the first column has been the one where I've had issues in the past. I believe this was down to the caps not being allowed to drain fully between columns previously; so when the first column is strobed again at the beginning of a new cycle (where we've been allowed to rest for a while, after servicing the USB stuff), the keyboard is completely `flat' and you get a different result. The longer sleeps between columns now mean the keyboard should be pretty flat at the beginning of any strobe.

[quantalume]

I wonder if you've thought about adding another translation or macro layer to the firmware. The reason I ask is that I use the lefthand cluster of keys on my 122-key boards for editing commands (Ctrl-C, Ctrl-V, etc.). Maybe just a table in kbd.h that gets processed in kbdFillReport or kbdFillNKROReport?

[wheybags]

Aha: a Great White!

http://www.ebay.co.uk/itm/IBM-Displaywr ... 4ad51a71af

This is the kind of beam spring that I've used in person. A huge beast, but a pleasant one. Now who's going to outfox me this time!?

I won't ruin your bid this time ;_;

[Muirium]

Knowing exactly how big that keyboard is, I'm wary of trying to bring one over the Atlantic. It's the second biggest keyboard I've ever used. The largest being one of those crazy huge Xeroxes!

[mr_a500]

You're bidding on that thing Muirium? I'm currently the highest bidder, but I won't increase my bid if you want it. I know you don't have a beam spring yet. (...but if I see a Kishsaver, watch out! You've already got one of those.)

[scottc]

I want it!

Now who's going to outfox me this time!?

You won't know until the last second!

But really, the shipping on this is really not so bad: £40 is a lot less than I've seen some of those ship for before! Best of luck getting it!

[mr_a500]

I suggest we settle it like this:

[xwhatsit]

I wonder if you've thought about adding another translation or macro layer to the firmware. The reason I ask is that I use the lefthand cluster of keys on my 122-key boards for editing commands (Ctrl-C, Ctrl-V, etc.). Maybe just a table in kbd.h that gets processed in kbdFillReport or kbdFillNKROReport?

Yes a macro system is definitely planned once I can grab some development time.


I wouldn't mind a Displaywriter; the layout looks pretty good, and it's probably no wider than a 122-key Model F? Being the last beamspring IBM made it should either be the peak of quality or the cheapest and nastiest.


BTW: we might try and shift discussion over to here: http://deskthority.net/marketplace-f11/ ... t7993.html to avoid duplication between the different ibm-capsense-usb controllers.