Our kitchen timer has been acting up recently, and with Thanksgiving quickly approaching, I needed to do something about it. The push button for the start/stop function has been getting harder and harder to use. In the past, I’ve cracked it open and cleaned out the pad underneath the rubberized button membrane, but this time, doing this didn’t work. I also wanted a more permanent fix.
I decided to replace the membrane switch for that function with one of these tactile buttons. I just had to make sure that the solder pads would line up. I worked out an orientation in which the solder pads would match the pushbutton pads, as you can see in the next image.
The only issue is that rather than the rubber membrane sitting flush with the board, it now had to accommodate the shape and size of the switch along with the button which extended out quite far. I used a pair of diagonal cutters to nip away at the rubber from behind to recess the switch into the button itself, Ben Heck style.
You can see this in the top right of the gray membrane. The two contact pads have been removed, and instead there is the hole, into which the switch recesses. The hole was made fairly crudely, but it works!
It’s been accidentally abused over the years, and as a result, the screws on the bottom no longer hold it together as the plastic has broken enough. The strip of electrical tape around the base does well to hold it together while still looking super stylish! NOTE: It’s not actually very stylish, but rather, functional and should last for many years more to come. No reason to throw it out, when an hour or so of work will get it fully functional again!
This post was originally posted on Scott’s blog here.
from BleuLlama on November 30th, 2012
0 Comments
This Tuesday at 7pm, we’ll be welcoming Rob Bishop of the Raspberry Pi Foundation to do a workshop. He’ll be bringing in a bunch of Raspberry Pi’s to play with and hack on during the event. The workshop is, as always, open to the public so we welcome anyone that’s interested in attending. This would be a good time to either start learning about Raspberry Pi’s or take your project to the next level.
Please sign up for your free ticket here: http://interlockraspberrypi.eventbrite.com/
Here are some links to get you started if you’ve never heard of the project:
Officially Raspberry Pi Website: http://www.raspberrypi.org/
RBP Quickstart Guide: http://www.raspberrypi.org/quick-start-guide
RIT’s ARM Developer Day: http://www.rit.edu/news/story.php?id=49538
UPDATE 11/29/2012: Check out a few pictures from the event: 1 2 3 4 5
from Antitree on November 26th, 20120 Comments
About a year ago, Interlock members were offered to go in on two group purchases, coordinated through the mailing list. The first was for Freeduino kits, with the boards pre-populated with the USB controller chip and mini-B socket. The second was for strands of individually-addressable RGB LEDs which can be controlled with an Arduino using this
Adafruit WS2801 library.
I indulged in each, getting one Freeduino kit as a soldering-skills confidence-building project and to give me a second Arduino-compatible device in case I wanted to start do something possibly destructive of my “store-bought” name-brand Arduino. I also got a single 50-light strand of the LEDs.
Well, as it turns out, I didn’t solder together the Freeduino until a couple of months ago. But I started playing with the LEDs almost right away, demonstrating them at our open house in the spring. I haven’t done a whole lot with them, other than play around with the color space a little bit by having them display cyan, magenta, and yellow (eg, the combinations of the other two colors leaving out, respectively, red, green, and blue).
The main problem I had starting out was that I wasn’t quite ready yet to start messing with external DC power supplies capable of delivering more than the half-amp or so that a USB port can supply. Reportedly, each LED can draw up to 60 milliamps, so there was no way I could use the out-of-the-box example code from the library, which lights up all the lights in the strand.
I could have had it just light up a half-dozen or so of the lights, I suppose, but I wanted to try all the lights, just not at once. I soldered onto the end of each of the four wires a bit of lead clipped from through-hole parts for other soldering projects to give me something I could shove down into a breadboard connector or into the Arduino connectors. Red is 5V, blue is ground. White is data and green is clock (I think, but see the code).
So, here’s my modest modification of the example code, in which I modify the ColorWipe function to first turn off any previously-lit lights before lighting up a new light with the given color. It’s a bit lazy, having a fencepost error on each end of the strand, trying to turn off (eg, set to black) the light number -1 and failing to turn off the last light in the strand. I’ve come to think of that as the “last color used indicator” feature.
--- libraries/WS2801/examples/strandtest/strandtest.pde 2011-12-13 00:43:49.000000000 -0500
+++ strandshort.ino 2012-11-24 17:29:53.829648206 -0500
@@ -16,7 +16,7 @@
// Set the first variable to the NUMBER of pixels. 25 = 25 pixels in a row
-WS2801 strip = WS2801(25, dataPin, clockPin);
+WS2801 strip = WS2801(50, dataPin, clockPin);
// Optional: leave off pin numbers to use hardware SPI
// (pinout is then specific to each board and can’t be changed)
@@ -37,8 +37,9 @@
colorWipe(Color(255, 0, 0), 50);
colorWipe(Color(0, 255, 0), 50);
colorWipe(Color(0, 0, 255), 50);
- rainbow(20);
+/* rainbow(20);
rainbowCycle(20);
+*/
}
void rainbow(uint8_t wait) {
@@ -75,8 +76,13 @@
// good for testing purposes
void colorWipe(uint32_t c, uint8_t wait) {
int i;
+ int j;
+ uint32_t black;
+ black = Color(0,0,0);
for (i=0; i < strip.numPixels(); i++) {
+ j=i-1;
+ strip.setPixelColor(j,black);
strip.setPixelColor(i, c);
strip.show();
delay(wait);
from deejoe on November 26th, 20120 Comments
I’ve been toying with the idea of setting up an IRC bouncer (“BNC”). A BNC is a process that acts in a similar manner to a proxy: I connect to it, and it connects to the IRC network. The advantage of this, for me, is that it can stay connected to the network even when I’m not: logging conversations and messages and holding on to my nickname for me.
I initially started with a blank slate: an install of Ubuntu Server 12.04 LTS in a virtual machine (thanks to our wonderful netadmin team). Almost immediately I realized I had a problem though: the VM was behind a firewall and NAT, with only a single firewall rule and port forward for SSH.
One of our members recently sent out a message to our mailing list about doing some cool things with SSH. So I thought it would be a great opportunity to take advantage of this new knowledge. In order to set this up, I needed to have SSH open and accessible on another machine. For convenience sake, I made this the machine that I was going to connect to the BNC from.
For the purposes of this article, I’m going to refer to the two computers in question as “bwvm” which is the Ubuntu Server virtual machine, and “bwhome” which is my MacBook Pro on my desk (“bw” being my initials — clever, I know).
The first thing I did was setup SSH keys so that I didn’t have to use passwords when connecting back and fourth between these two computers. I’ve done this a few times before but it isn’t something I do on a daily basis, so I followed this excellent guide from Paul Keck on doing so: HOTWO: set up ssh keys. The gist is that you generate a public/private key-pair on each computer (ssh-keygen -t dsa) and then copy the contents of the resulting id_dsa.pub public key file to the authorized_keys2 file on the opposite computer (i.e. bwvm’s id_dsa.pub contents go into bwhome’s authorized_keys2 file). Now I can SSH back and fourth freely.
Next step: install and configure a BNC. At first I started with psyBNC. I ran into some troubles with that though, in that for some reason it would only allow me to use super insecure passwords (instead of the insanely complex ones that I’d generated with 1Password) and it refused to connect to some of the IRC servers I wanted to connect to. I spent some time troubleshooting but ultimately decided it wasn’t worth the hassle and went with a recommendation to use an easier to configure BNC: ZNC.
I got ZNC installed and configured and began the process of forwarding the port via SSH. The command I’m using to do so looks like this:
ssh bwhome -R 4242:localhost:31337 -N
When run from a shell on bwvm what this does is links port 31337 on bwvm to port 4242 on bwhome (which to me is localhost — the computer I’m sitting at). So what I can do now is run a /connect localhost 4242 in my IRC client, and be connected to the BNC running on port 31337 on bwvm without bugging the netadmin team for another port forward and firewall rule!
This is a bit convoluted, but works. At the moment, the process looks like this (sitting at bwhome):
me@bwhome:~$ ssh bwvm
me@bwvm:~$ ssh bwhome -R 4242:localhost:31337 -N &
[switch back to bwhome]
me@bwhome:~$ irssi
/connect localhost 4242 (BNC password)
The result:
(Yay! IRC goodness)
Instead I’d like to simply run one command from bwhome, without having to initiate a shell session with bwvm. This should be possible by simply switching some of the command around. To do that it will likely end up looking something like this (again, sitting at bwhome):
ssh bwvm -L 4242:localhost:31337 -N &
(actually it looks exactly like that)
One distinct advantage of this method (using SSH) over having a firewall rule and a port forward is an added layer of security: in order to access my BNC someone would have to be able to SSH into my VM. Note that I don’t have to use SSL when connecting to the BNC, because all of the traffic is already tunneled over SSH.
For anyone wondering what app that sexy screenshot came from, it is Linkinus from Conceited Software – an IRC client for OS X — using the Erstwhile theme. Very retro.
from Ben Woodruff on November 23rd, 20120 Comments
This is a continuation of a previous article. Quick summary: I tried to build a device for dumping an EPROM via Arduino, and I constructed a device that had no chance of working. Oops.
This post will continue where that one left off. I’ll walk through some of the process to hopefully get to a solution that works…
To summarize the overall project; I want to build a device that will illuminate an UV light-erasable ROM (EPROM) device, and also dump out its contents. I will then take the contents, display them as a graphic, and animate them over time as the bits fade away into an erased oblivion.
When we last left this, the above circuit was what I was going to work with. The Arduino would shift out a 16 bit address, which will be stored in the 74HC595 serial-in, parallel-out shift registers. Those would output to the address lines of the EPROM device. The 8 data line outputs of the EPROM then are read in directly by the Arduino. I started to look around for the parts, and I was planning to buy them from Sparkfun.com, for a very reasonable price. I was all set to place the order, but then I started thinking about other ways to sample the data, and then it hit me…
In the late 1980s, I had an Amiga 1000 computer (see previous post about restoring it). We used Macintosh SE computers in High School, and as a result, we bought the “AMAX” Macintosh emulation system for the Amiga. It was a lot easier to carry a floppy or two, rather than a SE or SE/30 in a plastic milk crate, not to mention that MacWrite was a substantially better word processor than TextCraft. 
AMAX consisted of software you run that emulated the Mac’s hardware, as well as a “cartridge” that plugged into the floppy drive port of the Amiga. I remember hearing that they went with the floppy drive port because it was the only appropriate port identical on all Amigas that were available at the time. (Amiga 1000, 500, 2000).
The cartridge served two functions. First, it let you plug in a Mac floppy drive right into the Amiga so that you could read and write 800k Mac floppies directly. There was something about Amiga drives and Mac drives supporting a different number of drive speeds, so full Mac compatibility on the Amiga’s drives was directly impossible. Future versions of AMAX that used an internal card on the Amiga 2000 worked around this issue. It was possible to make a floppy that supported just the sectors/speeds that were the same on both, but they only stored 272k of content. But I digress…
The other function of the cartridge was that you needed to plug in Mac roms into it, which the software would read in as it starts. Rather than storing the ROM on the Amiga, this protected the copyrights or whatever. But the important thing here is the function. I had picked up a few AMAX cartridges for $2 apiece at the awesome Active Surplus on Queen Street in Toronto a bunch of years back, so I dug one out.
Left-to-Right, you see: Amiga D23 floppy connector, for connecting it to your Amiga, two 28 pin rom sockets, two 74LS393s, one 74LS165, a resistor, some diodes, a 74LS139, the Mac D19 floppy connector on the bottom, then the Amiga D23 floppy connector for adding additional Amiga floppy drives.
I’ve started to trace out the circuit, but it became obvious quickly that it was optimized for board layout rather than what I would consider to be a sane arrangements of data lines. For example the 8 data output lines of the ROMs go into the 74LS165 PISO shift register out of order, so they need to be reshuffled once captured in the host computer.
Instead I decided to desolder the chips! My guess at the original function is something like: the Amiga issues a clear to the 74LS393 binary counter chips, ganged together to yeield a 16 bit output, rather than two dual-4 bit outputs. This will reset their 16 bit output value to 0. The 74LS165 parallel-in, serial-out register then latches the 8 bit output from the ROM, and provides it through shifting to the Amiga via the floppy port. From there, you need to simply pulse the clock on the ’393, and it will increment through every address. Then you just latch and shift in the data. There’s also a 74LS139 demultiplexer, which might be responsible for sequencing through those events, or perhaps something to do with the Mac floppy drive. I had a slight mishap and lost the 74LS165, which is okay since I didn’t need it for this project anyway. Regardless, $2 plus some time — I’m already ahead and I haven’t even removed the D23s yet (which are the same size as Amiga RGB Video connectors! Perfect for another project…)
For fun, here’s the board with no components on it.
With a slight change in gears I can adapt my design to use the parts I now have in my toolbox thanks to my desoldering tools. Instead of the Arduino shifting out an address, it will instead do the process described above. It will first clear the 393s, then alternately cycle between clocking out a pulse to increment their values, and reading in the value directly. Since I’m accessing the ROM data from start to finish, sequentially anyway, this solution works out perfectly. I also show four LEDs in the above diagram. Three for various status, one for UV illumination.
Here is a close up of a 27C128 part. This one has Pac-Man programmed onto it… of course. You can see through the quartz window, and down onto the EPROM silicon itself.
Here we see the pins on the Arduino, and how the connect to the shield’s bus connections, along with the LEDs. I could draw this up in a computerey drawing program, but sketching it out in Sharpie on graph paper is just quicker… and more Mimsian.
Here are the two 74LS393′s. You can see their connection to the address lines on the ROM, as well as the cascading of the counter, e.g. from 1QD to 2A, and from 2QD to 1A on the second chip.
And the wiring for the 28 pin socket, including the 3 pin (two-way) jumper so that i can use smaller 24 pin parts as well.
About the UV illumination… The data sheets for the EPROMs show that they should be erased with 253.7 nanometer light, at 15-20 minutes, 2.5cm distance at 15 Watt/seconds per cm^2. I dont know how to measure this with respect to LEDs, but I’m going to just wing it and see what happens. The sheet also says that 253.7nm is the optimal wavelength for erasing them, but anything below 400nm should work. I believe the UV LEDs I have are somewhere between 350nm and 400nm, so it should work. The other issue is that the LEDs are substantially less powerful, probably a tenth to a hundredth the power. We’ll see once we get this going, but I expect it will take on the order of weeks to erase a rom, rather than minutes.
The good thing about this project, in comparison to using EPROMs functionally, is that you want speed of erasure for functional use. I personally found that my eraser worked on most of the devices I own in about 10 minutes. I would often have a chip or two in the eraser, while programming and debugging others. It worked out fairly well. For this project, it’s completely okay if it takes on the order of hours to erase a device. I’ll find out how well it works once I get it going. I may use more than one LED just to speed it up a little, in case it takes on the order of days instead of minutes or hours.
I started laying out the board at home, wiring in just the LEDs, and figuring out the best layout for the chips. I used the DIY shield for Arduino from AdaFruit.com as the foundation to build this upon. I wanted to leave space for possibly using larger chips in the future, so what is the bottom of the board here has space for a few extra data lines if i re-route that red power line. The ’393′s are layed out so that the one on the right, which addresses bits A0-A7 has four of its lines directly lined up. This was to try to make it a little easier to wire up.
I bought some wire wrap wire for address, data, and control lines, and did most of the work of wiring those up one evening at Interlock. I used red for control (counter clear, clock data cascade lines) as well as eprom address lines. I used blue for data lines. In the above pictures you can see how the wires were routed around (there was some more writing on the bottom, obviously.) You can also see how the UV LEDs are mounted with some stiff solid core wire. I reduced the number of LEDs to two plus the UV LEDs for no real reason at all. (There is an Arduino underneath there somewhere…)
On the two images above, you can see a jumper on the left of the first image, bottom of the second image… this changes what one pin is used for. For smaller EPROMs, pin 26 of the 28 pin footprint is used for VCC, powering the chip. In the larger packages, VCC is moved to pin 28, and pin 26 is used for Address line 13. It’s confusing. A table that shows all of the pinouts doesn’t really help too much, but it was necessary so that I could figure things out for wiring it up.
Next is firmware. I wrote a pretty simple program for the Arduino that simply enables the EPROM, resets the counters, then clocks through the addresses, reads them in and sends that data down through the serial link. After getting the enable lines wrong (active low, rather than active high), I managed to get it spitting out actual accurate ROM contents. As you can see in the above, it read out of the ROM (right half) 0xf3, 0x3e, 0×00, and so on. In a disassembly of Ms PacMan on the left, you can see these bytes in cyan, just to the right of the red numbers 0000, 0001, and so on.
The other half is a simple program that runs on a host computer that simply reads in serial data and logs it out to a file. That content looks like this:
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
I’ve now had this running for 12 hours with no change in the bits at all. I’m thinking that it will require running for upwards of a week or two to have any affect on bits. I may need to just drop the Arduino and ROM shield into my eraser to get the results I’m looking for… or at least a “control” to prove that the idea has a chance of working from here.
If nothing else, I now have a way to read EPROMS from an Arduino. Awesome!
from BleuLlama on November 14th, 20120 Comments
