Category Archives: Hardware

Simulink clone…now in C++

I took the plunge and decided to re-implement what I had in Python using C++. I had to change up my structure a bit, but I made the switch because of the following reasons:

  • The Qt Framework. While there are bindings for Python, I really liked Qt-Creator. Also, Qt is extremely cross platform (at least that is how it seems) and has a large amount of libraries. I’ve been messing around with it now for a bit trying to get a few things to work.
  • This is redundant of the above, but I really like the Qt Plugin system. After struggling with it for a bit, I finally was able to get a plugin to load. I will explain a little bit below exactly what I plan on doing with these.
  • As awesome as Python is, it doesn’t support true multithreading (it does multiprocessing…and to do what I wanted to do using multiprocessing would have required me to jump through some hula hoops)
  • C++ should have the potential to run faster than Python for mathematical things, which in this situation is a good trade off for ease of programming.
  • Writing the application entirely in C++ with Qt lowers the number of dependencies that would have to be installed on a client machine.

Now, the biggest advantages I see are: Speed and Extensibility. Python is extremely extensible, but it doesn’t have the greatest speed. C++ has the potential to run faster and then by using Qt, the extensibility part was brought in. I also prefer strongly typed systems since they keep me from stepping on my toes programmatically.

By far the coolest part of all this is the Plugins. After discovering that ALL communication between Plugins and the application must be done using interfaces, I realized that if I were to implement the entire thing using interfaces it could be extended to do many awesome things. So far, however, I have only really added interfaces to allow for adding computational “blocks” to the system for use in schematics. The system itself will define no blocks since I have decided to separate the engine from the actual blocks.

I will be posting later a bit about Qt plugins since that is what I have spent the most time on. Google was definitely my friend on that one. Most people it seems just use Qt Plugins for extending Qt itself rather than doing the “low level” extending the application stuff.

In terms of development time, C++ is quite a bit slower for me than Python. However, my potential to write good code is much higher since I am much more familiar with C++ coding conventions and I am more able to clean code while being confident nothing is being broken since in Python, there are no compile-time errors to tell you that you switched the arguments to a function.

Cloning Simulink…in Python

For a while now I have been working on a bench supply. As part of this I have been trying to get a PID controller to work. At first it was simple, but after asking my Dad about it (he does power electronics), he suggested that I use a cascaded PID loop for controlling the voltage and current using the voltage alone. I have sort of a bench model going, but I don’t really want to start construction until I have everything finalized since blowing things up and making mistakes is kind of expensive for my meager college student budget. Tweaking that without a working bench model that I am willing to blow up is kind of hard, so I started trying to figure out how to simulate it. Being partial to simulink (I’ve used it before with some nice pre-built blocks), I wanted to be able to lay it out graphically like control system diagrams usually show and I also wanted to be able to view plots over time. So thus was born my latest project: SimuPy.

Python seemed like an ideal language for this since I wanted it to look nice, be extensible, and be almost universally cross platform. I am relying heavily on the Qt library because it runs on almost anything and it has the ability to use slots and signals on pretty much any object as well. I guess another option would have been Java, but seeing as I don’t like Java that much, Python was what I went with. In addition, I am weighing a couple other options:

  • At the sacrifice of portability, I could make the interface half in C++ and half Python so that I still keep the extensibility without having the requirement of installing python on the person’s computer to get it to work. The simulation part would then turn into a python library that the program would load.
  • Write the entire thing in C++ for speed and true multithreading and use Python solely for extensions. This would be a little more difficult since I kind of leverage the dynamic typing thing that Python has going on.

So far, my current structure has everything based on a Model which contains Blocks. In addition, there is a simulation Context which holds information about each Block and where the simulation is in terms of the current step (simulations are stepped over time (dt)). Contexts are also where a Block will store all of its information that it needs to retain during the current step and in the next step. A Block is an operation over time in the flow of the simulation: it could be a simple addition, maybe a derivative or integral, or it could be a full PID controller. Blocks declare themselves to have a number of Input objects and Output objects. Inputs/Outputs are named and have a slot/function called set which sets the value of the input or output. Outputs have a signal called ‘ready’ which inputs connect their ‘set’ slot to. When an output’s ‘set’ method is called, it emits its signal. When an input is set and it sees that all inputs attached to its block are set, it performs a “step” on the block. In addition, there are 3 special blocks: An EntryBlock, ExitBlock, and ModelBlock. Entry and Exit blocks are used in models since a model can have “Entry” and “Exit” points. These points can be used to loop a value from an Exit to an Entry (if they have the same name) or can be used as Input and Output objects if the Model is placed inside a ModelBlock. ModelBlocks are blocks which contain a model which they execute in a child simulation Context to their context. In this way, blocks can be nested. If one creates a Model with 2 Entries and 2 Exits with a pair of those Entries and Exits having the same name and then the Model is attached to a ModelBlock, the ModelBlock will have 1 input and one output to corrispond to the free Entry and Exit on the Model. Models can’t be recursive, but they can be nested so as long as a higher level block doesn’t contain a block which at some child level contains the same higher level block, there can be some sense of re-usability and modularity to a simulation.

Blocks are subclassed into a package called model. The __init__.py file in the model package defines the basic form for a block and then the individual modules in the package define more specific blocks. The blocks then have their constructors cached by reflection so that a block can be constructed by simply naming its name. To extend the blocks available in a simulation, all that must be done is to drop the new module python file into the model folder. I am considering changing this a bit to separate out user-added modules from the “system” modules in kind of the same fashion as I did with the WebSocketServer where I had the files in a folder be loaded into the context of another package.

Simulations are to be stored in an XML format which is going to be more or less human readable and should preserve the look and feel of the simulation. I am still working on the exact format at the moment, but that is the next step.

As for the GUI, I plan on using Qt since it seems the most cross-platform (sorry GTK…Windows needs too much help to load you and PyDev in eclipse doesn’t like the whole introspection thing). I plan on releasing the project under the Apache License (but don’t yet quote me on that or hold me to it…I may choose a different license later once I get more of a feel for how the project would be used). Either way, I plan on publishing the source code on github since it looks like nothing like this really exists in a simple form. Sure, there are clones of Simulink to work with Octave and things like that, but it doesn’t look like there are few, if any, stand-alone applications that do this (except perhaps a paid program called logic.ly, but this should be able to duplicate the functionality of that program as well). I guess it is kind of a niche market since the only people who do this kind of thing usually can afford Simulink and Matlab.

For the record, I do have access to Simulink and Matlab through the University I am attending, but where would the fun be in that?

Case LEDs Software

So, I have just cleaned up, documented a little better, and zipped up the firmware and host side driver for the case LEDs. The file does not contain the hardware schematic because it has some parts in it that I created myself and I don’t feel like moving all the symbols around from my gEDA directory and getting all the paths to work correctly.

The host side driver only works on linux at the moment due to the usage of /proc/stat to get CPU usage, but eventually I plan on upgrading it to use SIGAR or something like that to support more platforms once I get a good environment for developing on Windows going. If you can’t wait for me to do it, you could always do it yourself as well.

Anyway, the file is here: LED CPU Monitor Software

Here is the original post detailing the hardware along with a video tour/tutorial/demonstration: The Case LEDs 2.0 Completed

The Case LED v. 2.0: Completed

After much pain and work…(ok, I had a great time; let’s be honest now)…I have finished the case LEDs!

Pursuant to the V-USB licence, I am releasing my hardware schematics and the software (which can be found here). However, it isn’t because of the licence that I feel like releasing them…it is because it was quite fun to build and I would recommend it to anyone with a lot of time on their hands. So, to start off let us list the parts:

  • 1 ATMega48A (Digi-key: ATMEGA48A-PU-ND)
  • 1 28 pin socket (Digi-key: 3M5480-ND)
  • 2 3.6V Zener diodes (Digi-key: 568-5907-1-ND)
  • 2 47Ω resistors (Digi-key: 47QBK-ND)
  • 1 39Ω resistor (Digi-key: 39QTR-ND)
  • 1 15Ω resistor (Digi-key: 15H-ND)
  • 3 100V 300mA TO-92 P-Channel MOSFETs (Digi-key: ZVP2110A-ND)
  • 3 2N7000 TO-92 N-Channel MOSFETs (Digi-key: 2N7000TACT-ND)
  • 1 10 Position 2×5, 0.1″ pitch connector housing (Digi-key: WM2522-ND)
  • 10 Female terminals for said housing (Digi-key: WM2510CT-ND)
  • 1 4-pin male header, 0.1″ pitch for the diskette connector from your power supply (You can find these on digikey pretty easily as well..there are a lot)
  • 2 RGB LEDs (Digi-key: CLVBA-FKA-CAEDH8BBB7A363CT-ND, but you can you whatever you may find)
  • 4 White LEDs like in my last case mod
  • 1 Prototyping board, 24×17 holes

The schematic is as follows:

Schematic (click to open full size)

The parts designations are as follows:

  • R1: 15Ω
  • R2: 39Ω for the Red channel
  • R3: 47Ω for the Green channel
  • R4: 47Ω for the Blue channel
  • LED1-4: White LEDs of your choosing. Make sure to re-calculate the correct value for R1, taking into account that there are 4 LEDs
  • LED5-6: The RGB LEDs. The resistor values here are based on the part I listed above, so if you decide to change it, re-calculate these values.
  • Q1-Q3: The P-Channel MOSFETs
  • Q4-Q6: The N-Channel MOSFETs
  • Z1-Z2: The zener diodes
  • U1: 16Mhz Crystal
  • C1-2: Capacitors to match the crystal. In my circuit, I think they were 33pF or something
  • CONN-PWR: The 4-pin connector for the diskette
  • CONN-USB: The USB connector. You will have to figure out the wiring for this for your own computer. I used this site for mine. Don’t forget to twist the DATA+ and DATA- wires if you aren’t using a real USB cable (like me).
  • C3: Very important decoupling capacitor. Place this close to the microcontroller.

As I was building this I did run into a few issues which are easy to solve, but took me some time:

  • If the USB doesn’t connect, check the connections, check to make sure the pullups are in the right spot, and check to make sure the DECOUPLING CAPACITOR is there. I got stuck on the decoupling capacitor part, added it, and voila! It connected.
  • If the LEDs don’t light up, check the connections, then make sure you have it connected to the right power rails. My schematic is a low-side switch since the LEDs I got were common anode. I connected both ends to negative when I first assembled the board and it caused me quite a headache before I realized what I had done
  • Double and triple check all the wiring when soldering. It is pain to re-route connections (trust me…I know). Measure twice, cut once.
Although I already have a link above, the software can be found here: Case LEDs Software

So, here are pictures of the finished product:

LEDs shining magenta

LEDs shining orange

LEDs shining green

With its guts hanging out

The mounting viewed from the outside

Mounted onto the front fan grille

Case LEDs version 2.0

So, as usual after I completed my LED case mod I asked myself, how can I could make it even cooler? Thus was born the idea for Case LEDs v. 2.0.

The Idea: Wire up some LEDs so they are controlled by the computer to vary their intensity or something based on the CPU usage.

The Implementation: Using RGB LEDs, some small MOSFETs, and a microcontroller make a USB controlled light generator that takes as input a number representing CPU usage.

In the 3 weeks since I put the white LEDs in my case I have been working on this thing in my spare time (mostly weekends…homework has just been swamping me during the week) and this past weekend I finally got it to connect through the USB using the V-USB library and so I have made a lot of progress. At the moment it is perfectly capable of displaying CPU usage by way of color (it is really cool to watch), but I still want to add a few features before I release the source code (and I also need to test it to make sure it doesn’t crash after 2 days or have some horrible memory leak in the host software or something…).

Since I am running linux, the host software was developed linux specific, but later I will add support for Windows since I plan on installing Windows on my computer for gaming at some point. There are two parts to the software: The device firmware and the host software. To minimize USB traffic, the firmware does the conversions from cpu usage to RGB and also the visual efffects. All the host software has to do is read the cpu usage and tell the device about it.

The hardware isn’t incredibly complex: It uses an ATMega168A microcontroller (I am going to be aiming for a smaller 14-18 pin microcontroller eventually…this one is just too big and it would be a waste) to control some MOSFETs that turn on and off the LEDs. The LEDs I got were some $0.55 4-PLCC ones from Digikey which I have soldered some wires to and secured with hot glue (my first try looks awful with the hot glue everywhere…the 2nd one looks amazing since I figured out that hot glue melts before heat shrink shrinks so I could put the glue inside the heat shrink). There are 2 MOSFETs per LED channel in a complementary logic configuration. Since the LEDs are common anode, the MOSFETs control the cathode wire and so there isn’t an inverting effect (put in a 1, get out a 0 and vice versa) like what usually happens with complementary logic. The whole system runs at 3.3V since I didn’t have any 3.6V zener diodes to use for the USB pins to keep the voltage levels in check so that it would be able to talk to the computer. Apparently the voltage levels are very strict for USB and my first few tries of getting this to work didn’t communicate with the computer because of the voltage levels coming out of the USB pins. After I changed the voltage to 3.3V it worked perfectly on the first try. Eventually this is going to connect to one of the internal USB connectors on the motherboard with power supplied by the same 4 pin connector I used for my white LEDs. I am debating running it entirely off USB power, but I am still not sure since that would limit any future expansion to 500mA of current draw and with the planned configuration it will be drawing between 250-300mA already.

Anyway…I plan on making a tutorial video of sorts along with pictures and schematics since in reality aside from the programming this was an easy project. I just need a week or two to get all the parts soldered together and the program finalized and then I’ll know exactly how much this thing costs to build.

Modifying my computer case

The computer

In November I purchased the parts for a new computer since mine was getting very old (I got it in 2006 and even then it wasn’t exactly top of the line). I put it together and it has been performing admirably for a couple months now. I was researching graphics cards and it occurred to me that I would have to move my hard drive up a slot to fit a large graphics card in my case.

After moving stuff around inside

So, I opened the case and started moving stuff around. I also decided to re-organize the cables so that they wouldn’t be dangling precariously above the CPU fan by stuffing them behind the HDD cage. During that process I took some strain off the SATA cables (they are kind of stiff and I think they were putting undue stress on the sockets on the motherboard, so I moved them around so that they wouldn’t be so convoluted). After finishing all this it occurred to me that my case would look sweet if I were to add some LEDs to it. I then set out to install some LEDs.

The grille and power connector

In the front of the case there is a plastic piece that covers the metal body of the case and also holds the power button, reset button, and HDD light. This case has a grille on it to allow air to pass through into the front fan (if I had one installed).

I decided that this grille could look awesome if it had some backlighting. I had considered using a lighted fan for this purpose before, but since fans are mounted on the inside of the case it would project the shadows from the internal metal structure onto the plastic grille, ruining the effect. I decided to mount some white LEDs on the inside of the plastic piece pointing towards the inside of the case so they could shine on and illuminate the part behind the grille to give a “glowing” effect. Here is what I used:

  • Some spare really thick black matte cardstock my sister let me have (she is into artsy things)
  • 4 White LEDs that I had lying around
  • A 15Ω resistor to limit the current (4 LEDs @ 25mA each comes to 100mA at a voltage drop of 3.5V)
  • A .1″ header I had in a parts box
  • Some wire
  • Some tape

The spider wires

I started out by soldering the header to some wires to take the 5V and GND line off of the small .1″ power connector in my computer. I then put the resistor on the positive rail and then split everything off into 4 wires (8 in total: 4 power, 4 ground). The result looked rather like a spider in my opinion. After that it was a relatively simple job of soldering the long lead of the LEDs to the positive rail and the other side to the negative rail. Thus, the LED assembly was completed.

Matte board and aimed LEDs

The more difficult part was attaching the matte board to the metal part of the case and then aiming the LEDs. The matte board was necessary because without it the LEDs reflected a little too well off the metal of the case and they could be clearly seen through the grille. I cut the matte board into two pieces large enough to cover the metal on either side of the grille and used tape to hold it in place. One hitch came up with the wires going to the front of the case: the hole for the wires was right beneath one of the grilles and was not easily covered by the cardstock. I ended up just basically laying the cardstock over the hole and wires and moving them around so as to not be visible through the grille. The next bit of matte board I used was to create a shroud of sorts around the HDD and power lights since the LEDs were bright enough that they shined through the bezels for those lights as well. I then spent a while aiming the lights until I was satisfied and then I put the computer back together so I could enjoy my new lights.

The Final Effect

All in all my specs are as follows:

 

A followup on the Dot Matrix Clock

Since I never quite finished the story about my dot matrix clock, I see no reason why I shouldn’t write a bit of a continuation of my current developments. Shortly before I left on my mission for my church in November 2009, I received my boards for the dot matrix clock and assembled them. However, I ran into a problem: The displays would turn off after the voltages on the gates of the row driving mosfets reached a certain voltage and when the voltage was at a level where it would turn on the display, it had some problems with turning on and off the LEDs. Now, after I left on my mission I would think about this once in a while and I figured out the problem: I was using N-Channel mosfets with only 5V or less of gate driving voltage so they wouldn’t turn on/off all the way. I am sure there are more problems than just that, but I keep kicking myself for using N-Channel mosfets instead of using P-Channel. Had I used P-Channel, the problem would have been avoided and this whole thing would have worked great. For the moment, however, this project is on hold since I am designing and building a few things that I will need in the long term here at college since I can’t lug around a power supply and an oscilloscope.

So, in summary, if I were to do a re-design I would change the following:

  • The row drivers would be P-Channel mosfets. This would require using something other than a 4->16 demux for a gate driver unless I could find one with inverted outputs. Even with that I would probably put some very small gate drivers (if they exist…the size restriction might be too much) as a buffer to ensure the mosfets were turning on and off properly.
  • I would factor in larger tolerances. If there was one design lesson I learned from getting these boards it is that I need to make sure that I make the holes for things a little larger. It would definitely make assembly easier.
  • The PIC18F4550 would be replaced for a ATMega of some sort or maybe even a small FPGA. I was running into speed problems with the 18F4550 with getting refresh rates up (I know this is contrary to previous posts, but I was starting to have problems getting 30-60fps like I wanted…even though the image wasn’t showing up anyway because of the mosfets). The 12MIPS speed was just a tad too slow and so I think if I were to use a 20MIPS ATMega it would work a lot better. Also, the tools for ATMega seem to be a little more opensourced than the ones for the PIC. I say this because avrgcc runs much better on my Linux machines than the various C compilers for the PIC series. Also, my AVR programmer (a USBASP) has very good native Linux support.

Now all that is left for me to do is to figure out how I can modify the boards I have so that I wouldn’t have to drop $70 again…

Back again

 

After serving a two year mission for my church, I have returned! While on my mission I didn’t have much chance to work on my various projects, but I sure thought a lot and wrote down a lot. I also managed to build some pretty interesting things (OK…maybe not that interesting).

On the mission, my two most interesting things I built were a small coilgun (also called a gauss gun) and some large headphones for a deaf lady. I had the most fun with the coilgun since it required the most effort on my part to create. It is housed in the case of a broken airsoft gun and is powered by a camera flash charger and two camera flash capacitors.

The Coilgun

Coilgun without the case

The Coilgun without it's case

The coilgun is constructed of a relatively simple circuit which draws power for a camera flash charger from a AA battery (housed in what was the magazine for the airsoft gun) connected to two photo flash capacitors. There is an SCR connected in series with the coil (the green thing) which use the capacitors as a power source. The trigger uses very tiny snap action limit switch (it was the smallest I could find at a reasonable price) to trigger the SCR (through a 20K resistor). The total cost for parts was $10 since the case was free and the camera flashes were free. The working voltage is about 330V or so which is normal for photo chargers, but when building it I managed only to shock myself once.

Coilgun with the case

Coilgun with the case screwed on

It shoots nails or anything else magnetic cut to a specific length so they are just a little inside the coil. The gun doesn’t have much power (I would more call it a “nail tosser” than a gun), but it is fun to use because of the high pitched charging sound makes the gun sound bigger than it actually is (more bark than bite you could say).

Coilgun without top

Coilgun with the coil exposed

There is a 1000V diode in reverse across the coil to prevent damage to the SCR and also a 1MΩ resistor across the capacitors so that they don’t retain charge for years and shock some unsuspecting person wondering what is inside this strange looking gun. I have had great fun with this project and someday I hope to build a much larger multi-stage one. Of course, lack of funds will keep that one out of reach for a little while at least, but it is something to work towards.

The Headphones

Headphones needing glue (note rubber bands)

The Headphones with the ear pads rubber banded on

In one of the apartments I lived in I was with some other missionaries who served a deaf congregation. Their ASL teacher was mostly deaf (she had 1% hearing in one of  her ears) and so she could listen to music occasionally. She was using some high quality DJ headphones to do this since she had to turn the music up really really loud for her to be able to hear it. Sadly, she let a friend borrow them and they got broken. So, one of the other missionaries who also enjoyed building things volunteered him and myself to construct new headphones for her. He built the case and I did the electronics. Electronically, it was a simple project since it was just taking a cheap iPod stereo and extending the wires out to fit into the case in the shape of headphones.

The completed headphones

The completed headphones

The basic design was to use a hamster ball cut in half with coat wire bridging the two speakers. Socks sewed onto cardboard with a cotton filling would be used for the ear pads. An old belt would serve as a size adjuster. The headphones actually turned out pretty nice and were very loud and had pretty good sound quality considering that they were made out of a really cheap iPod speaker set. The only problem was that when they were turned up high the quality would drop dramatically due to clipping/overloading/whatever you call that noise a stereo makes when its turned up to loud. She had to use them at that volume and while she was able to hear the music she asked ‘what is that strange noise on top of the music?’ and so they ended up being returned and the missionary who built the case bought the cost of the electronics from me and he used the headphones after that.

I have also had many ideas relating to future projects which I will post here when I am ready. Within my first few weeks back I constructed a new computer which should help me out and I hope for it to last at least 5-7 years. I will be posting about that soon as well.

Dot Matrix Clock: Display board assembly

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.

The boards unadultered

The boards unadultered

After soldering the MOSFETs and the column sink

After soldering the MOSFETs and the column sink

After soldering a few more column sinks

After soldering a few more column sinks

All the ICs soldered on the backside (and on the front, but you cant see that)

All the ICs soldered on the backside (and on the front, but you can't see that)

After soldering the diodes and resistors

After soldering the diodes and resistors

The completed back of the display board

The completed back of the display board

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:

The breadboard setup

The breadboard setup

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

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 with plastic/plexiglass cover

Front without the plastic/plexiglass cover

Front without the plastic/plexiglass cover

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

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

Front of the board without the case of display modules

Back of the board without a case

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.