
This is how we made a button with adjustable depth needed for pushing it.
A & B: screws
C: metallic plate mounted under the button surface
D: cables mounted in the screw and metallic plate (if they connect the button is pressed)
E: Foam pushing the surface up towards screw A.
F: The button surface with a hole for screw A
note: This assembly is to be built in all 4 corners of the button.
- november (1)
- oktober (10)
- december (1)
- november (2)
- oktober (4)
- september (16)
- november (3)
- oktober (7)
- september (15)
- november (1)
- oktober (10)
- september (20)
- augusti (14)
- december (1)
- oktober (2)
- september (1)
- augusti (12)
- december (1)
- mars (11)
- februari (16)
- januari (32)
- mars (9)
- februari (11)
- januari (12)
- april (4)
- mars (6)
- februari (8)
- januari (6)
Add new post
Search the blog
Labels
Blog Archive
It's easy to have as many LED's as you have outputs on your microcontroller but what happens when you need more of them?
In our project we used the Sun SPOT which has five I/O ports of which one had to be used for input leaving us with only four ports. This would have been fine if we had only four LEDs but we had in total 18 (three colours multiplied by six sides). Well, actually we had 3x9x6 LEDs which makes it a total of 162 LEDs. They were connected in parallell of nine so only 3x6 outputs were needed.
This is where shift registers come in handy. They allow you to store multiple digital values (1/0) for later reading using only one output (well, three actually, but the other two are not data as such, only control for the shift register).
- STR makes the shifted bits appear on the outputs.
- CP is used for telling the shift register to "shift" all values one step further.
- D is used for the data that you want to shift out. It is read by the shift register when CP is cycled.
Pseudo code
- Set STROBE to 0
- For each LED
- Set CLOCKPULSE to 0
- Set DATA to either 0 or 1 (LED on or off)
- Set CLOCKPULSE to 1
- End for
- Set STROBE to 1
byte[] data = { 0, 0, 1, 0, 1, 1, 0, 1, 0, 1, 0, 1, 1, 1, 0, 1, 0, 0 };
static IIOPin D = EDemoBoard.getInstance().getIOPins()[EDemoBoard.D0];
static IIOPin CP = EDemoBoard.getInstance().getIOPins()[EDemoBoard.D1];
static IIOPin STR = EDemoBoard.getInstance().getIOPins()[EDemoBoard.D2];
STR.setLow();
for (int i = data.length - 1; i >= 0; i--) {
CP.setLow();
D.setHigh(data[i] > 0);
CP.setHigh();
}
STR.setHigh();
Note that the loop is actually going backwards because the first bit you send will actually be available on the last pin of the shift register, something we didn't realize until after the circuit was soldered.
Shift registers for RGB LEDs
The shift register we used is called HEF4894B and is a "12-bit store and shift register" which is a nicer way of saying it can hold 12 bits. Here's the datasheet (PDF).
We connected it like this:

Three of the ports on the Sun SPOT was connected to STR, CP and D respectively. These were used for controlling the shift register.
The LEDs were connected on the outputs of the shift register in triples of RGB for each side.
For getting all LEDs to work, we had to daisy-chain two shift registers making the total number of bits expand up to 24 bits. Connecting two shift registers was quite easy. Just connect the same STR and CP from from the first one and connect the first ones OS' (Output Serial on negative clockcycle, should work with regular OS but we tried OS' first and didn't dare tamper with it) output to the seconds D input.
The power feed for the LEDs was connected on the VDD input on the shift register. Ground was connected to VSS.
As you can clearly see in this demonstration video, the RGB values are shifted out in triplets for the effect of wandering colours. Normally you wouldn't send the STR before all bits are sent but if you want this effect, send it after each triplet.
All was good.
Problem:
Once testing our new multi coloured RGB LEDs, we ran in to some problems with the direction of the light. When mixing the different colours the red, green and blue light components all went in different, quite straight directions instead of blending in to one colour.
Solution:
We simply used sandpaper on them. The result was LEDs with more multidirectional light which made the different colours blend more smoothly together. Not perfect but a great improvement. One minor effect on the downside is that the light intensity decreased a notch.
Problem
The cheap RGB LEDs aren't exactly even in colour. The red can be much brighter than the green and blue or vice versa.
Solution
There's a simple fix for this. Just use different resistors for each colour. One way to determine what resistors you should get is to try first with potentiometers, preferably one with high granularity (depending on how your LED's are connected, you will need different values).
Our setup was 9 LED's connected in parallell per resistor which means that the combined resistance should be about ~5 Ohms according to some guide we found online (google for LED calculator). We had three of these ELFA 64-721-61. They can be rotated 20 times from ~0 to ~200 Ohm which gives you a resolution about 10 Ohms per rotation. It was enough to get the values we were looking for (although in retrospect we should have gone with the 0–50 Ohms for even higher resolution).
Just hook all the LED's up and put the resistor between the current and the LED's and start screwing. Use some simple switches to turn each colour off as you try to match their respective brightness.
When the brightness is to your liking, just measure the resistance of each potentiometer to find out what regular resistors you should use in your circuits.
This is just a short description of a problem we had, and wheren't really able to solve due to time-constraints, but it is a pitfall that you can avoid pretty easily.
We where building an interactive boxing-bag, where the user would hit a the bag and trigger home-made buttons. Our buttons worked well in the early tests but when we put them in the bag we ended up with large issues in getting the SunSPOT to register a pressed button. We thought that this was an issue with the buttons never making contact. We spend a lot of time and effort on fixing the buttons, and of course it turned out that the buttons where the issue at all.
We where registering hits on the SunSPOT in a polling loop, ie the main program-loop read the inputs on the spot, processed it and sent data on a hit. Due to the polling nature of the program and the fact that the time our buttons got pressed where really short they never registered on the spot. Ie. in our bag the time the buttons made contact (ie. closing the circuit) was a lot shorter than the loop that ran on the spot making us miss a large proportion of triggers.
We never really solved this issue but ended up using the Phidget (it's event-nature was a lot easier to work with), so I can't really present a solution to you but keep in mind that this CAN be an issue in applications with very low time-constraints.
I would like to know how the "Klossen" group made all the (54?) LED light and change color (sorry guys, but I'm planning a different project were i have to use a lot color changing LEDs)
We had the problem that the light-thread (thin light) had to be fed with alternating current and the transistor, which had the base connected to the Arduino, was supposed to let the alternating current through when it was fed from the Arduino. The transistor didn’t like the AC so we had to get around the problem somehow. In an earlier stage we bought the DC-inverter which makes AC out of the DC, coming from the batteries inside.


