Archive for category Hardware
Dot Matrix Clock: Display board assembly
Posted by Kevin Cuzner in Dot Matrix Clock, Hardware, Programming on October 7, 2009
Well, here it is. The moment I have been anticipating for a good while: The boards came in and I assembled them. I made a few videos and took a few pictures. I won’t post the videos yet since I am still going through them and making sure that I don’t go and make a fool of myself.
After getting that far, I believe my camera died. Anyways, I assembled the breakout board and completed all the parts of the display. I did not solder down all the display modules to the pcb because I am going to be fiddling around with the resistors on the column sinks and I didn’t want to have to desolder a display before being able to do anything else. The next day, I started testing:
As for testing and stuff, it mostly works. I made a few errors in both the hardware and the software, but I at least got the LEDs to turn on (I have not, however, gotten them to turn off properly…). My original program which should have been immediately portable to the hardware did not work so well and I ended up writing the entire display portion of the program in assembler: Apparently doing a variable bit shift on a 32 bit number takes up a very…long…time when compiled in C for the PIC18F. The main issue with the original program was that when I expanded the display size to 40×16 it suddenly had no refresh rate to speak of. This was mainly a product of the way I had organized memory. I had stuck the entire display into an array of long ints so that access to individual pixels could be done almost entirely by index. Sadly, when the size of the display was multiplied by 10 the computation of the bitmask began to take too long and made it impossible to properly refresh the rows. The assembly program I made to replace this organizes memory in the same fashion that I believe VGA cards organize the memory: Everything in one big long array which has no end-of-row designation and just wraps around when it is displayed. This ended up being much faster and hopefully it will work for the finished product.
As for the hardware problems, I have several. First of all, I made the primary mechanical engineering mestake when designing the package footprints: I didn’t factor in tolerances. All the through-hole parts BARELY fit. In fact, I have to coax everything in using a craft knife to get the pins lined up exactly before the part will even go in. The button pins are going to have to be sanded down since there is a taper to the pins that was not in the datasheet which makes the pins too large for the holes. The next big problem is that the column sinks are behaving very strangely. After the voltage into the LEDs passes above 3.3V or so some of the columns just stop sinking while others stay on. I have a few ideas to find out exactly what is going on here, but I have no real plan of action to fix that as of yet. My final problem is that I somehow managed to lift a pad when soldering down a resistor. How this happened I am not sure, but I think it has to do with cheap board construction and using a solder wik that is too big. I barely managed to find a trace to solder to, so it is kind of fragile even with the hot glue I used to secure the wirewrapping wire I used as a trace extender. The next time I do this I am putting a via in EVERY trace that runs into a pad, even if it doesn’t need one just for this sort of situation.
Anyway, aside from the mentioned problems the boards turned out pretty well. Olimex was fast and relatively polite. Their construction wasn’t too bad (aside from the pad, but that may have been mostly my fault) and the boards shipped right on time and arrived right on time (to the day, in fact). Overall I would say this whole board experience wasn’t bad and since it mostly worked I will say I didn’t waste my money.
Dot Matrix Clock: Renderings of the display board
Posted by Kevin Cuzner in Dot Matrix Clock, Hardware on September 12, 2009
I finished modeling the entire board in blender today, so here are a few different views of the clock:

Front with plastic/plexiglass cover

Front without the plastic/plexiglass cover

Back of the board (sorry the board->board connector is blacked out..the lighting sucks)

Front of the board without the case of display modules

Back of the board without a case
I created these images in blender by exporting images of the various pcb layers from eagle, compositing them in gimp into front and back images, and uv-ing then onto the board. All the components were done by looking at their datasheets of course.
Dot Matrix Clock: Open sourcing the display schematic
Posted by Kevin Cuzner in Dot Matrix Clock, Hardware on September 9, 2009
Following the suggestion of a friend, I am going to open source a portion of the software (when it comes) and the display schematic. After I get the board and finish up the software I plan on releasing this as a kit. So far it is looking like the kit is going to cost somewhere between $110-$140. I would supply the board with the controller already soldered and programmed.
As it stands, the hardware features are as follows:
- 40×16 display with two LEDs per pixel giving 1280 LEDs
- Constant Current LED sink chips to prevent varying brightness problems with the display.
- PIC18F4550 Microcontroller running off the PLL on a 16Mhz oscillator giving 12MIPS throughput
- 41-pin high density board to board connector. A breakout board is included since development without one would be nearly impossible.
- 4 buttons. These are not connected to the display microcontroller, but can be read through the board to board connector.
- 8-bit parallel bus with CS, R/W, and CLK pins for communicating with the microcontroller in the fastest way possible. I have not yet decided on a maximum clock speed, but the clock is on an interrupt enabled pin.
The planned basic software features are as follows:
- Built in font(s). These would not be restricted by rows or columns and would be placeable by specifying start coordinates. I may also add the ability to have either user fonts and/or variable width characters.
- Pixel-by-pixel control of graphics. Each dot has 16 possible colors (4 brightness levels per color in each pixel…two colors). This would also allow direct memory “dumps” into the display for the possibility of animated things (assuming you have a powerful enough processor on the master side of the bus).
- Triple buffering to prevent overwriting the buffer currently being displayed. This may be extended to allow animations by switching buffers, but I am not sure if I have enough memory yet.
- At least 15fps throughput. 30fps is my target.
- Bootloadable using only bus commands, no POR required. I may or may not make the bootloader protocol public, but I am leaning toward making it public.
- More to come if I accomplish these and still have some clock ticks left over…
As for the board gerbers, I am going to keep them to myself. I spent nearly a year on the board design and I think I need to have at least some profit come of it before I release it to the world for some crazy board outsourcer to steal and clone at half the price I managed to get it fabbed at. I’ll tell you this much: Eagle’s autorouter can’t handle the entire thing and there are well over 300 nets (not airwires…nets), so good luck.
Now for the schematic. Here you go:
Now, before someone goes on yelling about how much the BSS138 sucks as a MOSFET I guess I should say that I have replaced it with a much better one that can actually source the current I need it to. The BSS138 has a couple ohms of RdsOn, so I replaced it with a MOSFET that has around 0.25Ω RdsOn. Enjoy.
Dot Matrix Clock: Down to two candidates
Posted by Kevin Cuzner in Dot Matrix Clock, Hardware on August 14, 2009
Well, just a short update here. I think I will probably be at home for another month or so, so I am going to go ahead and order the dot matrix clock display board. However, I need to decide between a surface mount crystal or a through hole crystal. I think my post on edaboard.com pretty much sums up my dilemma:
I have two possible versions I have been designing for some time now. Since it is looking like I am going to be home long enough to finish it I guess I should get it fabricated. However, one thing needs to be decided before I order it and that is whether or not I should use a Through-Hole or Surface Mount crystal.
Originally I was going to just use a through hole crystal, but after having a friend of mine look over the board as another set of eyes he pointed out that my crystal traces were over 3in long and had several vias in them. So, we identified a spot where a surface mount crystal could go with no vias and 0.5″ traces. The criteria for fitting in this space was that the crystal had to be no more than 7mm long, 3mm wide, and 1.5mm tall. The obvious problem here is that nothing really fit in that space except for a crystal made by Abracon that is 3.2×2.5×0.7mm. Now the problem is size: is the crystal too small?
My resources: 0.015″ solder, 1/32″ spade tip (on a variable temperature soldering iron), solder wick, and a relatively steady hand (successfully soldered a .4mm pitch 64tqfp by hand without overheating it).
Things I don’t have: A magnifier, reflow oven
Things I don’t have but could get: Heat gun, solder pasteI don’t have enough experience with this sort of thing to answer it myself and I really can’t afford to buy two versions of this board. Is using a crystal this small really worth it?
Well, hopefully I will have that problem solved before the end of the month so I can place my order as soon as Olimex comes out of their summer break (for some reason, Europeans take a month long vacation from work in the summer…how odd…).
What is this with premade stuff??
Posted by Kevin Cuzner in Hardware, Programming on July 27, 2009
I was recently talking to a friend online after conferring with him about my dot matrix clock circuit board layout (now to rev. 3.4) when he mentioned that all people have to do nowadays to become a hardware “hacker” is to go buy an premade Arduino kit, attach it to some other premade piece of hardware, and load a premade program into it. More and more I have noticed this to be true. People no longer design and program their own stuff; they just buy something and say they hacked it together. Although I think having a standardized hardware to work with for embedded stuff like what I mainly do would be nice, I don’t see the fun in assembling and programming somebody else’s code into somebody else’s device. What is the novelty in that? Where is the learning?
Even with this trend I have seen a few other examples of people coming up with something cool using premade hardware. A good example is from my History of Creativity class I took my first two semesters at BYU. At the end of each semester each student had to create and present a “creativity project” which showed creativity at some level and related it to the class. My second semester, one person in the class made something that absolutely astounded me in its simplicity and how obvious it was to construct. He basically made a multitouch enabled touch screen using an LCD with the backing taken off, a bunch of infrared LEDs shining into a glass plate, and a camera with a remote control bezel over the lens. He hooked up the webcam to the computer and used open source software to interface it to his computer as a multitouch human interface device (HID). He said it cost him about $200 mainly because of the monitor he bought and cannibalized. I was impressed. I was so surprised I hadn’t thought of doing something like that. It’s things like that with premade stuff that I find awesome. I had never before seen a monitor like this and from what he said it was the cheapest yet from a quick look around on the web.
Now why would it bug me that people are using so much premade stuff? Well, it puts people like me who design their own custom boards and software without using very many ready made libraries or a premade circuit layout into the shadows. It really does. When I say something like “I built this…take a look…” people then ask “Oh, where did you buy that?” I never buy stuff and say I built it. I believe the only kit I have ever purchased was a solar racer from solarbotics when I was younger. Other than that everything I have made was from my own self. The only time I buy something is because I can’t make it for cheaper. People buying all this premade stuff kind of dulls the novelty of people using “custom” hardware on computers and the like. Its like what happened to CB radios: When everyone was on clogging up the channels the novelty was lost. Although I have never been into CB radios, I can see the point of that. Something is novel because its something few people do. When I first started with microcontrollers in 2005, very very few people I knew had experience with them. Now, its like everyone is buying their Arduino’s and sumo bot boards, programming them with some premade software, and setting them loose as their own creation. Of course, there are the people who go buy these things but then make up their own projects with them. I happen to know one person who has a sumobot that he made from premade boards that he installed a webcam on, programmed some interface software, and now has a person (or rather, bright colored object) seeking robot.
The only way in my mind that people redeem themselves from falling into the bandwagon of buy it yourself fake hacker stuff is by expanding it to fill another need. Innovation is what drives the world nowadays, not invention. The only people who can invent things now are people with clean rooms and lots of money. Since there aren’t many of those people in the world, the vast majority of us “normal” people have to suffice for innovation. Being in the United States, I would mainly refer to improving American innovation so that I can live in a country that has cooler innovations than other countries, but since the internet is a global audience its better to say that the world should be more innovative.
Ghetto Chronometer
Posted by Kevin Cuzner in Hardware, Programming on June 27, 2009
For once, I did something simple. I have always wanted to know how fast my potato gun shoots and I have also known how to find out, but I had never gotten around to actually building something to measure the speed of a moving object. I built this almost completely out of parts that are available at your local radio shack and hardware stores. The device consists of a 2″ PVC pipe with two sets of infrared diodes/detectors placed in holes spaced a foot apart which are connected to a PIC microcontroller that I have programmed to act as a “stopwatch” measuring in microseconds. Once a time is captured, the value is written to EEPROM for later gathering at the computer.

The Ghetto Chronometer. It looks rather like a pipe bomb doesn't it?
Parts List
I noticed while building this that I was using parts that were originally purchased on radioshack (aside from the microcontroller) and the home depot/ace hardware. Here is the list of parts with a few prices:
- (2) Infrared Emitter/Detector sets ($3.49, radioshack)
- (2) 330Ω 1/4W resistors ( $0.02 apiece if you get the 500 piece resistor set, otherwise $0.20 apiece in the 5-pack; radioshack). This value can be fudged just about anywhere as long as it doesn’t drop below 90Ω or so. The lower the value, the more chance of breaking the infrared emitters. The higher the value, the less light the emitters give off (which increases the chance for noise). Use the values on the back of the package to calculate the exact resistor value if you want a fully bright light. I think about 37Ω or so will push 150mA through it with a ~3V drop.
- (1) ~470Ω 1/4W resistor. This is for the yellow and green LEDs
- (2) 5mm (T1-3/4) LEDs, yellow and green. These can be picked up at radio shack for various prices depending what package you get them in.
- (1) solderless breadboard (what I used) or those grid pcbs (both at radioshack)
- (1) 7805 (5V) Regulator ($1.59, radioshack)
- (1) PIC16F628A or a BasicStamp. The Basic Stamp is available at radio shack for an exorbitant price, but the PIC can be purchased for about $3 at most parts suppliers (look on octopart.com for prices). The programmer is not included in this estimate, but I built the programmer described in the WinPic manual for less than $20 (google it). I currently use a K128 USB Programmer.
- (2) 4.7K 1/4W resistors, same story as the 330Ω except you shouldn’t adjust this one.
- (2) >=100uF, <=500uF capacitors (radioshack again, not sure on price…depends what you get)
- (1) 9V battery clip (radio shack. price depends on the type)
- (1) 9V battery
- 16″ of PVC pipe 1/2″ larger than your current barrel size (leaves clearence for the emitter/detectors)
- Enough bushings to get the above PVC down to your barrel size for attachment (mine took two…stupid hardware store)
- A PVC connector 1/2″ larger than your current barrel size for connecting the device to the bushings
Instructions
These instructions assume enough knowledge to construct a circuit on a breadboard from a schematic along with enough mechanical skill to saw and drill stuff.
- Attach (I would solder them, but you can twist and tape if you like) relatively long wires to the ends of each infrared emitter and detector. There should be two of each in total. Make the wires different colors per pin on each device so that they can be distinguished later. Make a note of where each wire went on the back of the package they came in which should have an internal diagram for each part if you got it at radio shack. Twist each pair of wires together so that each device has a long twisted pair of wires coming off of it.
- Heatshrink or tape each lead coming off of the emitters and detectors individually and then per device. This is so that no short circuits happen and so that the device is easier to insert and remove from the PVC.

Chronometer Schematic
- Assemble the circuit per the schematic. The schematic uses the PIC microcontroller, so it will have to be modified for a basic stamp.
- If you used the PIC, program the microcontroller with fps.hex in this file. I have also included the assembly listing for anyone who is interested
- In the 16″ length of PVC, drill two sets of holes directly across from each other 2″ from either end. They should end up a foot apart.
- Attach the bushings and connector to the PVC. Which ever end you attach these to is called “start” in the schematic. The projectile (potato) should travel from “start” to “stop”.
- Duct tape what ever you assembled the circuit on to the PVC in the fasion shown in the picture of the device above.
- Insert each emitter/detector set into the holes on the PVC. They should be lined up with an emitter on one side and a detector on the other. The potato will interrupt the beam of light going between the emitter and detector.
- If the device is going to be used outside, it might be good to put duct tape or electrical tape over the ends of the emitters/detectors so that no light leaks into the 16″ tube. Light leakage can cause considerable interference since the lights are not modulated in any way.
- Load your potato gun.
- Attach this to the end of your barrel and turn it on
- Fire. The green LED should light up if it caught the speed correctly, the yellow one will light up if there was an error.
- Read the microcontroller’s EEPROM. The time it took in microseconds for the potato to go one foot should be written in locations 0×03 and 0×04, most significant byte first. Use a hex->decimal converter to get the value, multiply it by 0.000001, and take the inverse. This is the FPS of your gun. Subsequent firings will be written in locations 0×05 & 0×06, 0×07 & 0×08, and so on. It should remember where it was last written between runs until you reprogram it or run out of space.
How it works
Overall its pretty simple: A potato interrupts the “start” beam which starts the 16-bit timer and it interrupts the “stop” beam a few microseconds later which stops the 16-bit timer. After the timer is stopped, the value of the timer (which also happens to be the number of microseconds between the start and stop pulses) is written to the internal EEPROM at the address specified in location 0×00. The green LED is then turned on and the microcontroller wants for the next “start” interruption. If there is an error (like the EEPROM not being able to write or the timer overflowing), the yellow LED lights up and the microcontroller waits for the next start pulse.
The microcontroller runs on the internal oscillator which gives 1MIPS. The 16-bit timer is connected to the internal oscillator with no prescaler so that it increments every microsecond (1MIPS = 0.000001 per instruction) when the timer is turned on. Since it is a 16-bit timer, it can time a maximum of 65535 microseconds or 0.065535 seconds. This gives a minimum speed of 15.26fps and a maximum speed of 1,000,000fps. I guess this could be used on a rifle, but I am pretty sure the emitter/detector pairs would have to be switched out with something with less lag time.
To test to see if the infrared emitters are even working try looking at them through a digital camera. A digital camera has better eyes than we do, so it can see infrared as a whitish/purpleish light. The emitters are rather narrow beam, so they will have to be pointing right at the camera to be visible. Oh, and if any part of this heats up, thats bad. Nothing on this should generate much heat, including the regulator. The whole thing should draw about 50mA with the parts listed above.
Things to add
Obviously, there are some things that could be done with this to make it even cooler. Some of my ideas:
- Add an LCD screen that shows the milliseconds it took (or even fps)
- Store the value in feet per second instead of milliseconds. I would have done this in the first plac, but I don’t feel like finding out how to do division like that in assembler.
- Add a serial interface so that it can hook up to a computer and report its findings. I was originally going to do this, but I didn’t have enough 0.1uF capacitors for my MAX232 chip.
- Something to prevent the wires coming off of the emitters/detectors from getting bent if the gun roles around.
- …

