Beamspring USB controller

[kps]

I think in total the board will be about 40mm max high, including the connector depth. If anybody has a Displaywriter and is able to tell me, please let me know. Otherwise I will modify it to use the 90° system.

Borderline. It's difficult to measure exactly, since the case tapers forward slightly. The measurements to the inside back here are a little conservative, and 40mm might actually fit, but a 90° mount is probably safer.

dw.jpg (110.13 KiB) Viewed 6468 times

[xwhatsit]

Cheers kps!. I'll modify it then. Thanks very much

[xwhatsit]

Ordered.

[nourathar]

euhm, apologies for asking what must be rather obvious, but not to me:

I finished soldering my rev3 board and compiled the firmware with no problem, but I can't seem to find how to flash the hex file..
I am on Arch Linux, I have avrdude installed and the closest I got in my looking around is this command line I've seen that is used for arduino:

Code: Select all

avrdude -F -V -c arduino -p m328p -P /dev/ttyACM0 -U flash:w:blink.hex 

I get some of this, but I'd need to know what the right values are for -c and -p and I don't understand what I am seeing after -U either...
In the last months or so I have been using arduino's quite extensively, but only with scripts that seem to invoke avrdude differently, I installed the command-line utility just now..

[Game Theory]

IIRC: I used FLIP. http://www.atmel.com/tools/FLIP.aspx which made it relatively easy.

[nourathar]

IIRC: I used FLIP. http://www.atmel.com/tools/FLIP.aspx which made it relatively easy.

thanks for that, the alternative for FLIP on Linux seems to be dfu-programmer:
http://dfu-programmer.sourceforge.net/

that is now installed, but my board does not show up anywhere, neither under

Code: Select all

lsusb

nor when I do

Code: Select all

sudo dfu-programmer atmega32u2 get ID1

also not when I short one or both of the 'prog' or 'reset' pads on the board, even though I can measure 5V over them: so I got at least some of the soldering right !

How should I do this ?

and I suppose that after I do get this to work eventually, I should flash the beamspring_5251_usb.hex file, but should I also flash beamspring_5251_usb.eep to the EEPROM ?

[quantalume]

I normally avoid Windows like the plague that it is, but FLIP and Tom's utility work so well there that I just hold my nose and make an exception. Are you sure you're not trying to use the firmware from the other converter which relies on the original internal controller?

[nourathar]

I could try windows, but I have the feeling that my problem now is that something is not right with the connection: either my soldering or my understanding of what needs to be done to flash the atmel chip. With some arduino's one needs to press a 'reset' button to be able to initiate flashing / uploading, and on the beamspring pcb there are two pairs of pads that used to be switches in previous revisions, one labeled 'prog' and one labeled 'reset'.

What do they do ? When using FLIP, do you use these pads at all or can you start the flashing from FLIP ?

[quantalume]

Assuming your 32u2 has the correct bootloader, it will be ready to accept an image as soon as it starts up. After programming it the first time, you will need to use the pads to put it in programming mode, or use Tom's GUI utility.

[nourathar]

ok, thanks, then I think I screwed up some of the soldering, I am going to check my connections and such
(assuming it has the correct bootloader, but normally these come preloaded, no ?)

[nourathar]

ok, thanks, then I think I screwed up some of the soldering, I am going to check my connections and such

didn't properly solder the USB-connector; was the first part I put on thinking it was big and easy, but in fact it is the most tricky part to solder because the leads are mostly hidden, so you can't remove excess solder afterwards.. so now the firmware is uploaded and works !

[quantalume]

Yeah, should have the DFU bootloader from the factory. The chip should show up as a USB device even before programming it. You can use the lsusb command before and after plugging it in to see if it is recognized. If not, then there has to be a problem with the processor, xtal, connector, usb resistors or cable.

Edit: glad to hear you got it working! Welcome to the club!

[xwhatsit]

Sorry I saw this a couple of hours late—glad you got this sorted!

For future reference, if you have dfu-programmer installed (that's what I use), you can just type `make dfu' and it will compile and use dfu-programmer to flash it in one hit. Much more handy to use in a compile/test development cycle than FLIP (big horrible Java program as far as I can see—don't know how people get any development done on Windows, all the tools require taking your hands off the home row!).

To put it back into programming mode (other than using the GUI util, which has a button for said purpose), that's when you can short out those pads. Press reset, press prog, release reset, release prog. I used to use two screwdrivers, but find it more reliable with a couple of bits of screwed-up tinfoil Obviously not necessary to do this unless you made a cock-up with the flashing or program itself.

Well done!

[nourathar]

thanks ! and thank you for making all this !

but so far I have been unsuccessful in getting any input: when I plug it in, dmesg | tail tells me stuff like:

Code: Select all

[58624.850674] usb 4-1.5: new full-speed USB device number 113 using ehci-pci
[58625.191368] hid-generic 0003:0481:0002.0014: No inputs registered, leaving
[58625.191480] hid-generic 0003:0481:0002.0014: hidraw1: USB HID v1.11 Keyboard [TC Beamspring-USB] on usb-0000:00:1d.0-1.5/input0
[58625.194821] hid-generic 0003:0481:0002.0015: hiddev0,hidraw2: USB HID v1.11 Device [TC Beamspring-USB] on usb-0000:00:1d.0-1.5/input1
[58625.199035] input: TC Beamspring-USB as /devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5:1.2/0003:0481:0002.0016/input/input12
[58625.199199] hid-generic 0003:0481:0002.0016: input,hidraw3: USB HID v1.11 Keyboard [TC Beamspring-USB] on usb-0000:00:1d.0-1.5/input2

so that looks ok now, I think, but keypresses don't actually do anything.
I fired up a laptop with Windows 7 and your utility runs (the first time after booting Windows it crashes, but the second time it seems to run properly), but I get the hourglass when it finds the controller, and that does not stop.

So I think not all of my soldering worked out perhaps (even though I do not see anything that looks strange), I replaced the 18pF capacitors with the 22 pF you suggested later (I forgot about that, and I hope I did not damage the pads on the pcb), but no difference. Any suggestions where to start looking ? I will continue this tomorrow !

[xwhatsit]

Have you used the GUI util yet to set up the board?

I'll paraphrase these instructions I sent the other day for using the GUI util:

- Start increasing the threshold until keys you press register onscreen (the background surrounding the dropdown box will turn dark). I'd expect that number to be around 100-140.

- Now you can go through and assign each scancode

- At the end, you'll see there'll be a couple of unused points on the matrix which don't correspond to any key and appear as though they are pressed (or released) all the time. Be sure to assign those as either (PRESSED) or (RELEASED). This is used by the autocalibrate function.

- Once you are happy, press the `Store in EEPROM' button, otherwise the next time the power goes off or you unplug your keyboard you won't have saved anything

- It'd also pay to test the autocalibration by trying the Auto-calibrate button

What is your board by the way? I have example configs for 3278s, 5251s and 3727s under beamspring-usb/src/util/src; just hit `Import Layout'.

EDIT: Sorry I see the bit on the end about the GUI util under Windows. I've found Windows to be a little odd with the GUI util, it sits there for a long time wanting to install drivers from Windows Update or some nonsense (doesn't need drivers—it's HID!) before it gives up. It should work nonetheless once the OS has finished banging its head against the wall.

I haven't uploaded a pre-compiled binary for the GUI util under Linux, but it's easy enough to compile, you just need Qt and hidapi.

Don't worry about the 18pF vs 22pF—if this wasn't working you wouldn't have it appearing over USB at all.

[nourathar]

I would be happy to compile the GUI under Linux, but I did not find the source anywhere ?
The GUI looks great btw, pretty much self-explanatory I'd say !

EDIT: duh, never mind, found the source...

[nourathar]

got the util to work under QtCreator, running it as root for now (until I sort out some kind of permissions issue), when I ask it to autocalibrate it gives 1022, which seems high ?

and so far no luck in getting keys to register..

[xwhatsit]

Autocalibrate won't work until you tell it which keys are which (it uses the dummy (PRESSED) and (RELEASED) scancodes as described above—these are nodes on the matrix which IBM left unused for actual keys, but presumably were used as I have used them, for calibration on startup).

Try setting the threshold manually to 131 and see how that gets you. For example on my board, I find at about 120 or so I get nothing, and at 140 everything is on—it's a fairly delicate balance, hence the autocalibration (once you've got it sussed out). Anything higher than 1023 is going to cause the DAC to wrap around and go back to 0.

What's your board? If it's one of 5251, 3727 or 3278 try importing one of the example layouts in the source folder, then try autocalibration. It's obviously important you choose the right one, as those (PRESSED)/(RELEASED) calibration keys are in different places on different models.

[nourathar]

Hi Xwhatsit,

I'm doing this on my 5251 and I imported the layout already before I started the autocalibration. Later today I will try again setting it by hand, but there was no difference between having it on 1 or on 1022, so I don't think that is going to work out. If I understand you right, 1022 is actually the maximum value so then all keys should be on all the time ?

[xwhatsit]

Yeah they should be all on at once. I'd maybe check at 200 or so just in case, it's possible if there was an off-by-one error etc. then 1022 might wrap around already, but I don't think so.

It kind of sounds like we might need to check some of the hardware now. Even with no keyboard plugged into the controller you should be able to get all the `keys' to register as you ramp up the threshold.

I normally test the controllers first before I solder on the connector or chassis ground wire by plugging them in, leaving them set blank, ramping up the threshold until all the keys are just flickering, on the edge of registering, then running my finger across the edge connector pads. You can see all the keys light up as you move across the pads, like a touch-sensitive piano.

First thing I'd check is the DAC output. If you put your multimeter (or scope if you have one!) to measure the voltage at the bottom side of R3 (the 20K resistor in the middle of three at the far right of the board), you should see the voltage vary between 0 and 5 volts as you change the threshold between 0 and 1023. In the same way, you should see the voltage at the top of the same resistor (R3) change between 0.8 and 1.6V over the same threshold values.

If this isn't happening, there's probably something up with the DAC. Make sure it's up the right way (it doesn't have very good markings, but on the batch I have, the X should be at the bottom of the board). If this looks OK, check that there are no shorts around the top-right corner of the ATmega32U2 (these are where the SPI pins are). The clump of three resistors on the back (R11, R15, R16) would also be something to check for shorts, in theory you could bring the capacitors all the way to either 0V or 5V with a short there and the DAC would run out of range.

I think the shift registers (74HC4094) and comparator (LM339A) are likely to be OK, unless you've soldered them backwards or something. Should be easy enough to check from this image: http://uploads.oshpark.com/uploads/proj ... eQCA/i.png . It will be hard to tell if the shift registers are pulsing with a multimeter as the pulses are very short, but they are flicking from 0V to 5V then back to 0V briefly around 700 times a second or so. You might be able to place an LED with the short lead on pin 1 of the edge connector, and the long lead on pin 2, and you should see it glowing dimly.

If you have the opportunity to take some high-res photos of the controller we might be able to spot something. It will be something small and silly I'm sure—99% of it is already working!

[nourathar]

thanks for the detailed instructions !

EDIT: see next post for reason why it didn't work....

I did the following:
measured accross all resistors and capacitors to check for shorts, all looks good, only funny thing is that some resistors show up as approximately half the value I soldered in, but I guess that has to do with the circuit ? more specifically r16 measures around 8.7K, r15 around 20K, but I checked and the resistors I put in are the right ones.
To be sure, I heated all connections again, and added some solder on the leads of the IC's, in case I have been overenthousiastic with the solder wick. But that did not change anything.
Measured all the pins of the Atmega with the multimeter for shorts too.
Measured between pin1 and pin2 of the edge connector and that gives 0.7 V, between pin2 and pin3 it gives 0.0V. I don't have a scope, but that 0.7V might be the average of the pulsing going on ?

I changed the treshold value in your GUI utility, while measuring the bottom of R3 / pin 3 (?) of the DAC.
That is where the problem is: whatever the treshold value, the bottom of R3 stays 5V, the top always stays 0.8V (which is also weird ?). But why ?

I guess the main thing to check is the orientation of the comparator and the DAC, which I mostly figured out from this picture by quantalume:



for the LN339 pin 1 is at the top of the board, for the DAC pin 1 is towards the bottom of the board, the bottom being the edge connector, right ? I looked at the voltage on all the pins of the comparator with my meter, and when looking at the inputs, all keys suddenly lighted up, so I think that is ok, which leaves the DAC I would say.
On my DAC it says 'DKVD', and when looking as in the picture above, the text is the right way up.
Perhaps I ruined it by overheating it ? Should I just pop in my spare and see if it makes a difference ?
Do I have the right part ? This is the one I have:
http://nl.farnell.com/microchip/mcp4726 ... t=192-5047

Here two picts of my board, I put it in the scanner at 600dpi:

beamspringfront.jpg (455.94 KiB) Viewed 6286 times

beamspringback.jpg (389.3 KiB) Viewed 6286 times

tantalizingly close but not fully there yet !

[nourathar]

DUH !

in order to answer my own question:
No, it is not the right part, I've been using the DAC of a previous version, because I was confused at first when I ordered the parts. Now I hope I also ordered the right ones....

and it explains nicely why it doesn't work....

apologies for the confusion and the noise !

Uhoh!
Unfortunately it won't work with the old DAC, as the MCP4726 is I²C, not SPI. The firmware could probably be modified to bit-bang I²C over the SPI lines, as long as the pinout is the same. But still not ideal.

edit: yes, I did actually order the DAC101S101 later, I guess I just put in the first six-legged ant-sized part I found..

[nourathar]

Ok, after my first experience in soldering SMD I now also tried desoldering SMD and my advice is to avoid the latter at all cost !
After putting in the right part, however, and after finding some alternative for a ruined solder pad, I am now typing this on a 5251 beamspring !

super nice, thanks xwhatsit !

[xwhatsit]

Terrific!

Ha that's excellent! Yes those little SOT23-6 parts all look the same, buying a label maker and a compartmented box was a very good decision

For future reference, to desolder those little SOT23-6 chips and similar, instead of trying to remove solder then lifting them off, you're better of blobbing on more and more solder until the whole chip (or at least both sides) is a big molten ball of solder. The large mass of solder means it stays liquid for longer, and you can easily lift it off before it cools. So far the chip has survived every time for me when I've done this—remember during leadfree reflow soldering the chips are well in excess of 200°C for a good minute or two. It's a lot less stress on the board and component compared to the labourious pin-by-pin THT desoldering I reckon.

Well done! One more beamspring dinosaur clunking away

[nourathar]

For future reference, to desolder those little SOT23-6 chips and similar, instead of trying to remove solder then lifting them off, you're better of blobbing on more and more solder until the whole chip (or at least both sides) is a big molten ball of solder. The large mass of solder means it stays liquid for longer, and you can easily lift it off before it cools.

that's an interesting idea: amazing how many tricks there are to let physics help you solder these tiny parts..

Well done! One more beamspring dinosaur clunking away

ibm5251clunkingaway.JPG (182.98 KiB) Viewed 6167 times

well, thanks to you, mostly !
Clunking it is indeed, what a nice noise !
(but I wonder how long I will be able to use this without complaints about the sound)
And I have to get going with renovating the shield, before my beard hairs andsuch clog up the mechanism..

[xwhatsit]

Sweet!

I see somebody else with VMS (vertical monitor syndrome). I'm 50% in remission for that (dual monitors, the other one is horizontal ). Jealous of the trackball. Suits the beamspring rather well I think.

[xwhatsit]

So, slightly disappointing news; got the solenoid driver PCBs and assembled one in a state of excitement.

It charges up nicely to 9.1V in a blink of an eye, drawing very little current while doing so. It also mashes the solenoid in a very satisfying manner.

However, after turning on the solenoid, a very interesting thing happens:

- The current limiter chip (MIC2009A) goes into current-limiting mode and starts reducing output voltage
- It immediately starts to get very hot
- It hits 135°C shortly after (maybe 100-200ms), which is its thermal protection level, and switches off output entirely
- It then cools down slightly, enough to turn back on (still in current-limiting mode), and immediately heats up again
- Rinse and repeat

Even if you turn off the solenoid output immediately it does the same thing. The problem is the boost converter (MIC2250)—which gives us the 9V—has been sucked dry and wants to get back up to 9V, and will draw large amounts of current while doing so. So every time the current limiter gives it a sniff, it then hammers the current limiter again. Eventually after maybe 10 seconds or more it gets enough juice in the caps to be happy and it will get back to normal.

It's all happening because I overlooked the fact that the MIC2009A limits current in a `linear' fashion. When MOSFET (or any semiconductor) is partially conducting (i.e. not fully on or fully off), it acts more or less as a variable resistor and turns all the excess energy into heat. The MIC2009A is very small (SOT23-6) and certainly doesn't have a heatsink, so gets hot very quickly (before the boost converter can recover and stop drawing so much power).

It's even worse, because the hotter it gets, the lower the current limiter gets set (because MOSFETs increase in resistance with die temperature). Luckily the MIC2009A has over-temperature protection built in, which kicks in, but then we're so hot that we really need to remove the output load entirely for it to recover, otherwise it just goes into thermal cycling.

As far as I can see from the datasheet, the MIC2009A is actually designed to work like this (it's not a failure mode per se), so I've done nothing wrong apart from use it inappropriately.

A bit disappointing. If I run it off my bench power supply with the current limit set to around 300mA, then MIC2009A never kicks in and I can hammer the bejesus out of the solenoid very happily, without drawing too much current.

I'll have a play around with the boards a bit more. The MIC2009A has an inverted `fault' output that kicks in when it current limits or hits thermal overload; I might try and ninja-solder that to the enable input of the MIC2250 boost converter, so that it will turn off the MIC2250 while it is current limiting. This should induce more `switched' current limiting and hopefully stop the chip from getting so damned hot. The MIC2250 also has a 1ms soft-start built in after it is enabled (or re-enabled), so that might help mitigate things. I might also try getting rid of one of the big electrolytics immediately on the output of the MIC2009A.

If that doesn't work, our options are thus:

- Build a discrete current-limiting circuit with nice fat juicy MOSFETs or BJTs in DPAK or TO-220, which can handle some heat (hey, if my benchtop power supply can do it...)

- Ditch the boost converter and switch the solenoid directly off 5V with the MIC2009A (it is, technically, a current-limited load *switch* and is designed to be used in this way, as long as I put a kickback diode in to handle the inductive spike). However the solenoid doesn't sound quite as good off 5V.

- Bite the bullet and put a pair of screw terminals on the board so people can wire in their own external 9V power supply. Much easier, but feels a bit like cheating!


Ahhh analogue stuff. Maybe this is why my job title is `software developer'

[mr_a500]

Oh crap. I feel like my dog just died. I don't have a dog, but you get the idea.

[xwhatsit]

This is `development' Challenges are fun. If everything works perfectly first time you don't learn anything. Now I know more than I ever would have otherwise about `current mirrors' and what `thermal resistance of junction to ambient (θja)' means and how to use the number

Might require a few iterations but in the worst case, as above, I can always take the easy route out and require a wall-wart or something.

[woody]

Now I know more than I ever would have otherwise about `current mirrors' and what `thermal resistance of junction to ambient (θja)' means and how to use the number