Archive for the ‘arduino’ Category

Custom file server

September 6, 2014

For the longest time I have been using my main desktop computer as my file server.  This comes mostly from the fact that I never upgraded my computer until enough of it died that it needed a whole new motherboard/CPU/RAM upgrade because I didn’t have any spare parts to revive the old one.  The problem with having a several terabyte file server full of NFS and Samba shared media as a dual boot environment gaming rig is that if I rebooted into Windows then no one (including me) could access the files.  I could have set up the Windows partition to share the drives as well, but Windows doesn’t really like EXT3 or NFS and I don’t like administering windows if I don’t have to.  This resulted in me playing no games (which is arguably not all that bad of an outcome) but I would like the option of playing something and then watching something streamed to my phone or laptop from my server without rebooting.

When Michigan Tech decided to gut and throw out an old HP 612a UHF signal generator I had to jump at it (they also threw out the VHF equivalent, but I hadn’t decided what to do with the one I had yet).  A friend suggested that I build it into a server and I took on the project after making a few measurements.  The bottom of the case where all the passive components and wiring went (remember this thing once held tubes) was just barely tall enough for an intel lga775 stock heatsink to fit, and the power supplies (because of course I had two) would mount just fine if de-cased first.

The case itself had some amenities.  It had a power plug, it had a 115/230 switch, and it had a roll out tray design.  This means that the computer can roll out of the housing while it’s being worked on which makes for great benefit in troubleshooting.  I cut off all the offending steel (not a lot) and added fan holes for the power supply cooling (not terribly well centered).  I got some semi-matched 3-bay 3.5″ cages from scrap computers and mounted them to the main body with brass sandoffs (a friend had a HUGE bag of these).  The holes for the power supply mounting and motherboard mounting are more-or-less standard so when it came time to… upgrade them it went fairly smoothly (upgraded specs mobo/CPU won’t change boot sequence making it’s sata ports useless and old power supplies blew up with PWM-ed load on the 12 volt rails).

that drink might be whisky, I don’t remember..

The computer booted off of one of the cheapest USB flash drives I have ever seen.  This drive had a PLASTIC housing, not a metal one, probably meaning pretty bad sheilding, but it works just fine and is a sandisk so it’s probably ok.  Two USB ports were located to the front panel for ease of interface, the VGA cable is permanently connected, but coiled up inside only to be taken out when troubleshooting.  The network cable is also patched to an external mounted jack, it’s hand-soldered to a board mount jack, so the signal is probably not the best but it’s not a gigabit NIC anyway and I’ve pushed near 100Meg speeds through it.

The two power supplies have their green (power on) and ground (black) wires in parallel, but the rest are floating relative to each other.  This doubles the number of 12 volt and 5 volt rails available however the motherboard is exclusively using one supply.  The cables at the supplies have been de-soldered and I pulled from my extensive collection of Molex and SATA connectors to put together a nice harness for this machine.  The fans are mostly dumb 12 volt computer fans so they are controlled through PWM-ing the power rather than the new ‘4-wire’ fans that have a logic-level PWM input.

The motherboard did not have nearly enough SATA connectors for my taste so I ordered 2 PCI-E 1x 4-port SATA cards and sone PCI-E 1x ribbon cable extenders.  Here is where some people may complain about signal integrity over un-sheilded ribbon, but I will state again that I have had no instability in this server since it was constructed.  The power and reset buttons are on the front panel along with a mains power switch that cuts the power to the supplies killing the whole rig and an ne-2 neon tube that shows the presence of AC power after the switch (tells you if it’s not plugged in or otherwise is without AC).  The fuses for the power supplies have also been run up front.

The custom part of this server that makes it more than just a case mod is in the font panel controller.  There is an arduino pro mini controlling the front panel, acting as a gauge driver and a fan controller.  The fan controller portion is simple, the fan power bus is switched by a big FET pulled from the power section of an old P2-era motherboard and that FET is controlled by the arduino.  The fan speed can be either full on, manually controlled, or temperature controlled.  The temperature comes from a thermistor (salvaged from a power supply) that is biasing a voltage divider read by an analog input.  If set to temperature controlled a PID controller tries to keep the center of the machine below 80F.  This frequently means the fans are always on, but that changes based on where the server is placed for cooling.  The manual control is exactly what it sounds like, an analog voltage read from a potentiometer is converted to a PWM duty cycle.  The mode is controlled by a rotary switch that has various resistors running into one analog pin to minimize pin count (and it was an odd pinout switch).

The big part of the front panel is the meters.  There are two beautiful meters that I have backlit (and the backlight is on an analog voltage control by potentiometer) and a 5 digit 7-segment display meter that fit perfectly where the old wheel didin the front panel.  The digital displat sows exactly what it originally did, ‘Megacycles’.  In this case meaning the current CPU clock speed (which is governed) in Megahertz.  The two analog meters show the RAM and CPU usage and have trimpots on the back to set the scale, well, they’re pots anyway…  Commands are given to the controller over a USB to serial link (knock off FTDI cable) and a python script.  The Script was originally bash with a bit of python because I’m bad at bash math, but it became python with a bit of bash because it’s marginally faster (unless I could run the whole thing in bash).

Because this server is running headless I wanted to make sure it came up and shut down correctly, the way I did this was to make a script that played music using the ‘beep’ command and set it designated on startup, and another on shutdown.  It’s actually fairly easy to get your scripts to launch like any other daemon in linux using this tutorial.

There were a lot of parts for this I modeled in Solidworks and 3d printed because it’s really easy to make LED and button holders that way for oddly shaped holes.  The scripts, arduino code, and solidworks files are on my github here and all the pictures in this post (along with others) are here.


Reverse Engineered Bubble Display

June 15, 2014

I was at hamvention a few weeks ago and ran across some digital stopwatches, the salesman made me an offer I couldn’t refuse so I got all four.  Each had a bubble display inside, but not in a terribly useful configuration.  The displays have nine plastic lenses, but only numbers two, three, four, five, seven, and eight are populated.  that’s a froup of four, a space, then another group of two.  I should also mention that I don’t actually need any more displays, but they always seem so useful that I can’t help myself.  I wrote a generic matrix driver and threw it up on my github here (I swear I’ve written this code a million times, so here it is for general use). The number on the back says “LTB-1467S” T8416 Made in Taiwan, so if anyone else needs this pinout hopefully google will lead them here.

IBM 122 key follow up (2)

May 11, 2014

First post

First follow-up

OK, I finally got around to doing those custom keys.  They’re not the best, but I plan to do it better with what I have learned in the process of putting together this continuing adventure.  Here’s my initial draft of key designs (I’m still looking to put a save key somewhere, not sure where though)

This part was completed at the fabulous i3Detroit hackerspace in Ferndale MI (of which I am currently a member).  Previously I had hoped that I would just be able to mark the keys with the laser cutter, but predictably it just melted and didn’t actually discolor as I had hoped.  I considered using the vinyl cutter to mask and then paint the keys, not fine enough.  I could laser a mask out of something and paint it which I determined to be too much work.  I could also use the laser to cut the keys and wipe paint into it, but all the examples for that show a smooth surface and not only are these keys curved, they’re textured.  The easiest way to do it would be to use the laser to bond a paint to the surface, but I needed a ‘paint’ that would cure to the plastic and I could wash the rest of it away.  Further experiments will be tried using conventional ceramic glaze, but today we had the right tool for the job: Thermark.

Thermark is a fantastic (and fantastically expensive) product that will bond to metal (and plastic as we discovered) with a relatively low power laser.  Our first experiments were preformed on a sheet of polystyrene and apparently wildly out of focus because we were using power levels around 50% and today when I did it we couldn’t go above 30% for raster text.  The first approach was to get the proper font (mostly Helvetica) for the keys and replicate them by rastering across the surface of the key and laying down a beam whenever that pixel should be darkened.  That didn’t work.  It sorta worked, and with much post-processing I’m certain we could make it work, I just don’t want to.

The laser cutter we’re using is the FullSpectrum HL40-5g 40 watt laser cutter and use software called RetinaEngrave.  That software is both fantastic and terrible.  To be honest it may have some of the features I want, but that just pushes it to a UI problem instead of a feature implementation problem.  When you just want to cut something out, or draw a picture into a piece of material it’s fine.  When you want to do fine detail work and have control over the laser for doing extremely fine (and low power) things like this it just doesn’t cut it.  It may not be the computer-side software’s fault however, the controller in the laser cutter isn’t doing it’s job correctly either.

Verticals lost (before cleaning)

Verticals lost (after cleaning)

Some things we learned when making this keyboard: the laser takes time to warm up (and more importantly the controller isn’t compensating).  That means if it’s been off for a second then there is a notable ramp up curve to the power output  of the tube (do more expensive ones just use mirrors and leave the beam on the whole time?).  This became a problem because The vertical lines would only blip on for the shortest time and the laser wouldn’t get up to full power.  If there were any way to raster in the other axis on top of the same design to get a uniform pattern then it’d be fine but RetinaEngrave doesn’t do that.  To fix this we tried slowing down the laser, but that melted the plastic in the parts where the tube was on for an extended period of time.  We tried turning down the power as well but those two never seemed to balance and give us the consistency we wanted.  There was then trying to stretch that axis (theoretically just telling the laser to turn on earlier) but that turned into a slightly bloated interior set of letters (which could be made to work, but I don’t really like that solution: I shouldn’t have to tweak the source material like that to compensate for the tool, I’d rather fix the tool).  Finally we threw out the idea of rastering the font in favor of a nice vector font.

too slow, melted and pooled thermark (before cleaning)

too slow, melted and pooled thermark (after cleaning)

With a vector font we can get a longer beam-on time rather than blips and we can do a fill of the to get any size font we want.  The downside is that I’d have to abandon Helvetica (I’ll be honest, by this point it was Mukti Narrow) for a more common Sans font.  The promises of the Hershey Text from none other than Evil Mad Scientist Laboratories were great in their beautiful blog post about it.  It delivered… sorta… eventually.  First: the version you need is in not as it’s a script for the eggbot originally.

tried widening the letters, bled together a bit (before cleaning)

tried widening the letters, bled together a bit (after cleaning)

Once you’ve figured that out then you get to discover that our laser warm up problem has reared it’s ugly head again.  When doing vector letters the first letter of a line would be too light, even the time it takes for the beam to scan back to the beginning of a line on a 12mm wide key has caused it to cool down and not be nearly as dark.  The problem then with noticing it and doing just that key again is that if you only do one pass the tube still won’t have warmed up since it’s still the first letter.  If you run a pass too light then try to make up for it with more passes you’ll run into the distinct non-linearity of the laser power.  The hotspots on an initial light print will balloon out of control to splotches before you get the letter looking dark enough to be done.  The key is the fewest passes to get the job done.

uneven application of thermark (before cleaning)

uneven application of thermark (after cleaning)

You need to actually run two passes over the first letter of each line in addition to running the rest of the cut.  By the end I was doing two passes routinely since it does one cut, then repeats it rather than doing all of the cuts and starting over for another pass.  There is also the concern that we’re not always in the most crisp focus since the keys are curved.  I’m not all that concerned about that  but it could be an alternate reason for the darkening problem (but the verticals problem in the raster letters seems to prove out my theory).  The next time I do this I’m planning on manually editing the Hershey Text created lines to look more ‘Helvetica’.  That being said by the time I got to the last 2/3 of the keys I had a process down.  That process is detailed here:

1) First I traced (all of this in Inkscape) a nice rectilinear picture of a key that had some text in the same position as the text I wanted to mimic (single line, double line, single character, etc…) .  To do this I laid down the snap-lines horizontally and vertically on the top and bottom of the text and the entire key.

2) Then I generated the vector font using Hershey Text.

3) I resized the font (after locking the ratio) to the size of the text on the key I wanted to replicate.

4) I resized (once again, lock those ratios!) the entire outline of a key with text group to be exactly 12mm wide (what I measured the key caps at).

5) Once I had the key the way I wanted it (all vector in this version) I printed it to RetinaEngrave.

6) In RetinaEngrave I disabled the outline (but a perimiter trace still goes around it so I can use that for alignment).

7) I placed the blank keycap (thermark applied with q-tip as evenly as I could manage) on a strip of masonite as a stand (the keycap isn’t level and I didn’t want to build a proper jig just yet).

8) Once aligned I fired a vector engrave with 0.2% power (tube doesn’t seem to come on if the software has it set any lower than that), 80% vector current % (because you can actually go lower) and two passes (to eliminate the dim letter problem).  As far as we can tell the software won’t try to turn on the laser unless power is set to 0.2 or higher, less than that is possible with the vector current % setting, but not much below 50% of that (we used thermal paper as a test bed).

9) Wash with isopropyl alcohol (or honestly probably anything).

As you can see they’re not all straight, or uniformly placed, or uniformly dark… whatever, I’ll try again later.  I personally think the method I have outlined here makes halfway decent keys.  Redo is a raster one, the best we got it, we ran out of keys to test with otherwise it would have gotten the vector treatment too (and New Tab is done over a very light failed stop key (we really ran out)).  A big thanks to Unicomp for still making these keycaps (and blank ones too)!

All the fantastic close up pictures were taken with a Sony a580 digital camera that had a custom adapter designed and 3d printed to fit our Nikon SMZ-2B binocular microscope.  The the 3d model for that will be updated when I get it.  Gallery with more up-close photos is here.  My vector adventures are on git here and I have a post on th vinyl coming up.  

Commodore 64 usb keyboard

April 6, 2014


As I type this the keyboard in my thinkpad t60 is going, so all these keyboard projects are good.  I found that the guy who created the firmware I’m using to interface the ibm 122 key to my computer also developed one that will take a raw matrix and use the same great config file structure to create a usb keyboard.  There are a bunch of options for debouncing, blocking, scanning, and even muxing inputs and outputs to use a matrix larger than the free number of pins on the ’32u4 (or just use the existing hardware in the keyboard).  This project was essentially a proof of concept for my arcade machine keyboard controller so now that this works I can start designing and wiring up the matrix for that.

The first thing I did was get the pinout for the keyboard matrix, then I found that one key is not part of the matrix, so I threw it on one of the rows and made it a new column with undefined keys below it.  Now I have to define a key matrix in the config file, no problem.  I just looked at the documentation, copied an existing config file and went to town.  Some of the keys were in interesting since either the closest key didn’t exist, or I had used it elsewhere I had to use dummy keys.  I chose the “LANG_#” keys since I figured even if one of the keycdes got through the OS would just shrug and forget about it.

The macros I was good at this time around, once I decided what I wanted the keys to do it was just a matter of writing up the commands and bracketing them wit a macroblock.  Enter problem number one, the macroblocks have a fixed length.  I didn’t bother to figure out how many macros could go in one block, I just broke them up into logical blocks and then it worked.

The next one I encountered was that for some reason the PD0 and PD1 pin (arduino D3 and D2) didn’t like being used for scanning.  I don’t know what about them but when I moved to PF1 and PF0 everything went smoother.  For this project I used the olimex-32u4(since the board doesn’t matter, just the mcu) and I decided to cut all the LED jumpers (there are 3) just to be safe.

Now I had a matrix, being read reliably, outputting scancodes more or less properly.  There was still a problem with some keys’ shifted functions not working properly.  I bumped my macro block for the shifted chunk above the general re-maps and that cleared right up.

To sum up the config file: all keys do more-or-less what they say on top.  The odd F-keys are the main buttons, the even ones are done by holding down the commodore key (windows key).  The british pound key is the backslash/pipe key.  My favorite mod was making the “wasd” keys into the arrow keys (since the commodore arrow keys are a mortal sin) using the windows key.

That’ it.  I now have a working commodore 64 keyboard as a usb keyboard.  The project this is for isn’t quite a secret, but despite hackaday’s warning I’m not posting about it just yet.

my config file: here

IBM model M…122key?

March 17, 2014

I was at an electronics thrift store recently (I’m not advertising here partially because I don’t care that much, partially because there’s another one still there and I may go back for it).  to get something, but while I was wandering around this caught my eye.  I originally called it an “IBM Model F” but that’s wrong, it’s a Model M, but it has 122 keys.  It does self identify as a “Plt No F3” but that may be a coincidence.  What I can tell you is that it’s a part number 1390876, was made in 1987, and someone warrantied it until 1998 (maybe?).

How’s that saying go? “This is my keyboard, there are many like it, but this one is mine”.  Well, in this case there are none like it… anymore.  I decided that there were some aspects of a bunch of different keyboards I wanted to incorporate into the layout of this one.  I started by deciding what I wanted in my keyboard.  First I wanted to make sure all the keys had a useful function.  Second I wanted to use as many keycaps from the original layout as possible.  Third I wanted to have numlock on at all times (or rather never have the keypad do anything but numbers and math symbols).  Next I needed to put back a windows key on a keyboard distinctly lacking one.  The arrow keys had to be restored to a sane configuration.  Finally I wanted to have commonly used key combinations assigned to single keys.

The keyboard as it originally looked

I really liked some of the historical things this keyboard brought to my attention.  There are a bunch of symbols that are present on it that I’ve never seen before.  The number one has a shift function of a pipe rather than an exclamation point.  The problem is that the pipe key looks the same as it does on more modern keyboards.  That’s actually a broken pipe symbol which used to be a different character (but for some reason the broken pipe symbol remained on the keyboard while the use moved to the pipe).  The alternate function of the six key was a bar with a hook on the end which I have been told used to represent a logical “not” state.  I’m pretty sure I can’t pass that as a HID keycode and have any modern operating system handle it.  The exclamation point is occupying a key with the “cent” symbol, which falls into that category of ‘symbols we don’t really use in modern computing’.  I liked how the numpad didn’t have numlock functions defined on it, but unfortunately the plus sign is occupying the spot the enter key does (and I use that one a lot).  I do have another key to play with however as there are two normal sized keys above it rather than the large key that’s usually there (and I put the small return key on one of them, and a carrot on the other).  The number of keys that IBM didn’t even bother to define I found interesting.  The function keys are plentiful, but I wanted them to be ‘f’ keys, so I switched those.  The pointed brackets (or greater-than/less-than symbols to some of you) were on the same key, I thought that was interesting, but I decided to mostly put it back to qwerty in the major ways.  I kept the funky enter key (‘field exit’ it says) and that moved the pipe key down.  The left shift key is smaller on this keyboard, I chose to put the windows key there.  The arrow keys got moved to it’s proper configuration and I put a context menu key below it (what else would I do there?  The left ‘alternate f keys’ I decided to take direction from the sun keyboards and map things like copy, cut, and paste there.  I also added some others I found useful in web browsing (the ‘untab’ key as I call it was present on the keyboard, but in the cluster above the arrow keys) and one that my Lenovo T60 taught me about (next web page).  The top row of the f-keys I went with media keys, a print key that was on the keyboard originally, the scroll lock cluster (which isn’t on this keyboard anyway, and I didn’t need scroll lock) and the escape key.

Sorry about that, there’s no real logical place to break that block of text up that wouldn’t just be arbitrary.  I liked that some of the keys had symbols and no text as opposed to modern ones (backspace, tab, caps lock, shift, untab, return) and some had less than entire words (del, ins).  The controller is the brainchild of a fantastic guy on the geekhack forum by the handle of Soarer.  I found out by reading the entire forum thread here that the code (or maybe documentation) wasn’t released for so long that someone else developed an alternative that now has other and different compatibilities (which is kinda cool).

The hardware is trivial, it’s just a Teensy 2.0, a keyboard connector and nothing else.  The teensy is really great for being stupidly cheap and able to act as a USB HID device.  The teensy 3.0/3.1 is out, but that’s a full 32bit arm processor and so many levels of overkill that I couldn’t bring myself to consider it for this project.  I chose to add the three indicator LEDs because this keyboard doesn’t have them.  I also chose to add the reset button in case I wanted to put on a new teensy firmware and didn’t want to open the case.  The last feature I added was that I broke out all the aux inputs as 1/8″ headphone jacks.  I did it wrong.  I shorted the ring and tip together and connected them to the aux input and the shell to ground.  I should have connected the shell to ground and the tip to signal.  I now have to use stereo male phono connectors because mono ones short it out and have the key constantly pressed.  I really like the aux inputs for things like footswitches, I mapped them to left and right, (for surfing image galleries) space for a pause key, (watch this space for a laser line break switch using a comparator) and page up and down for surfing blogs.  The footswitches I had were normally open and normally closed.  Opening it up, bending the leaf switches apart, and flipping the switch over was all it took to make it normally open and work with the controller.

In the end I decided to label the keys with my dymo letratag (free after rebate from black friday a long time ago) and I have transparent keycaps on order to make them all the same height (and protect the labels).  I’m also looking into having key caps printed up, but it may not be possible (the company says they do it but some people say they’re unresponsive).  The firmware for the keyboard is seperate from the re-mapping and macros.  The config file is compiled into a binary form and uploaded to the microcontroller.  The code allows for all sorts of cool features and the documentation tells all about it, but I’ll mention a few things here.  You can make macros without using any modifier keys (alt, ctrl, shift).  You may also want to use a more conventional ‘MAKE’ ‘BREAK’ keypresses rather than the ‘PUSH’ ‘POP’ that are supposed to restore the keypresses to the original state.  I had problems using my ‘shift-tab’ key with the ctrl key to make ctrl-shift-tab so I chucked all of the ones I wanted to use in combination (and my config file reflects that).  I also had a problem with the PAD_ASTERISK keywhere I remapped things in the wrong order, causing two keys to be the ‘carrot’ key (the fix was to make the PAD_ASTERISK a macro from it’s original key rather than a remap.  I think that’s all the oddities I found, but I didn’t even try to use the layers function or some of the other stuff.

The world’s most obnoxious keyboard now has USB!

Continuing adventures!

Arduino library for SCC 1080 displays

January 19, 2014

This project was originally started as part of the i3 Detroit OpenAccess control system for RFID entry.  I promise I’ll write an entry on that soon, but I’ve got to shake down all the bugs first.  These displays that I got to play with are specifically 1080-s4-13-x-x, which according to the manual means that our displays have four lines of twenty 5mm characters each, 2-RS485 serial ports, 13 buttons, no memory, and no clock.  Because these are the only two displays I have, theirs are the only features I implemented.

My setup was originally on the Open Access Control 3.0 shield for the arduino mega 2560, this shield has a SN65HVD05 on it’s hardware serial port 3 and has the Rx/Tx pin connected to pin 16.  That’s the thing about adapting an RS232 port to RS485, RS232 is full duplex, meaning it can transmit and receive simultaneously, RS485 is half duplex using one pair of wires as a differential twisted pair for both transmit and receive.   The twisted pair differential signaling is better for noise immunity, but because of that it takes twice as many wires to run full duplex.  The full duplex equivalent of RS485 is RS422, but that’s a less popular standard for a number of reasons.  When adapting RS485 to RS232 the adapter chip has a pin to enable receiving RS485 signals to RS232, and another pin to enable driving the RS485 signals from RS232.  These pins are usually opposite polarity so that one digital IO can control switching from Tx mode to Rx mode.  This particular use of the display only connects to serial port 1.

The following information is just on the features I implemented, some features were not present on the devices I handled, some features I didn’t find useful, and some features I couldn’t figure out, that’s why they weren’t included.

There are two modes I used these displays in: single unit mode, and multi-drop mode.  Single unit mode is exactly as you might expect it, one display connected to one serial port taking commands directly.  The multi-drop mode adds a packet format to the device as described in the manual I have linked to above and the code I link to down below.  In multi-drop mode any number between 1 and 255 can be used as a display address except 4, 4 is the end byte in the message protocol.  These codes may seem arbitrary, but they somewhat faithfully implement the ASCII table’s control characters (start of text, end of transmission, etc…).  The commands for single unit mode and multi-drop mode are the exact same, except the multi-drop ones are wrapped up in a packet with an address in it.

There are four modes for taking input from these displays, we’ll go over them one at a time.

Buffered/half duplex mode allows the characters to be written to the screen at the current cursor position without host intervention and also placed in a buffer, the UP arrow key backspaces, the DOWN arrow key places the down character in the buffer.  The buffer is dumped when the ENTER key is pressed.  I don’t like this mode because it alters the display from a known state without telling the host.

Buffered/full duplex does the same thing as buffered/half duplex, except it doesn’t alter the display.  I don’t like this mode either because you can’t tell if the UP key is pressed, and in order to know when any key is pressed you have to hit ENTER (this also applies to the buffered/half duplex).

Instant/half duplex allows the characters to be transmitted when they are typed, but also puts them on the display.

Instant/full duplex is my preferred mode, it outputs keys to the serial port when they are typed and also doesn’t display them (like an old school dumb serial terminal).

These displays have all sorts of features, I really like them.  One interesting feature is the ability to set any of the functions to any if the available ports (or an internal 800 character buffer).  What I mean by this is the available ports (in my case serial ports 1 or 2, the buffer, or a null port) can be mapped to where the display either takes a specific kind of input, or sends a specific kind of output.  Those specifics are as follows:

Main input port: takes ASCII, control codes, and escape codes.

Data output port: when the display needs to send data to the host.

Key control port: used to send keys to the host.

Repeater port: parrots out the contents of Main input port, for use with long cable runs

I personally didn’t use the Repeater port, and I had everything else set to serial port 1, but there’s something interesting about the Key control port.

Since the Key control port can be set to an 800 character buffer, it can be used to buffer a lot of key presses, but more importantly the buffer can be polled in multi-drop mode to figure out who sent those key presses since you can’t set what value the number keys return.  In instant/full duplex mode with the key control port set to the internal buffer the key presses are stored in a buffer that can be polled by the host (polling each multi-drop device separately so you know where the key presses came from).

The control codes are very striaght-forward, I implemented the following:

0x0C => clears display, sets cursor to home position

0x10 => the text following will be blinking

0x12 => the text following will not be blinking

0x14 => sets the cursor position, although my implementation only allows you to set the line

0x15 => turns cursor on

0x16 =>turns cursor off

By following the examples I have built into the library it could be expanded to allow all the control codes to be used, but I didn’t find the rest useful.

The escape codes are actuated by sending 0x1B followed by a single ASCII character.  I assume the escape codes are different from the control codes because the control codes are implementing the unprintable command part of the ASCII table while the escape codes are able to be entered simply by typing the ASCII character for ESC and another ASCII character at the terminal (something an operator could do).  The escape codes I implemented are as follows:

0 => resets the display

1 => disables the keypad

2 => enables the keypad

5 => bargraph on a given line (and clears out the rest of the line)

B => read buffer

C => clear buffer

In order to use my code properly the displays need to either be in Single Unit or Multi-Drop mode, the keypad needs to be set to Instant/Full Duplex, the Main Input Port and Data Output port need to be set to a serial port (I used port 1) and the Key Control Port needs to be set to the internal 800 character buffer (4).

The functions I have implemented are pretty easy to understand after my explanation here and a quick glance at my example code and the library itself.  The information provided here is for the use of anyone who needs it, if you have any questions feel free to comment.  The thing is, these displays are really expensive, I only got to play with one because it was donated to this project, so most people who use these displays are doing so with “Industry Standard” everything, so they don’t need to know how to talk to them with anything a bit more reasonably priced.  If you should happen across one of these things though, jump on it.  They are easy to talk to (now) and really slick looking.

You can find my code here, the READMEs are at least a bit descriptive, some of the test code is old and doesn’t use the current revision of my libraries (or use them at all).  I intend to put up the code for reading buttons very soon (next couple hours) as I only realized the thing about the buffer while writing this.

ADDENDUM: I spent a while with this article written as you see above and attempting to get the button reading working from the buffer.  I couldn’t do it.  I know how it should work (or how I think it should work as the manual I have is different from the firmware on the displays in front of me).  I know that once I post this I will get around to trying again and it will work, but for now it’s being posted with the button reading code non-functional (in multi-drop mode, I got instant/full duplex working with the key control port set to the main serial port, but it’s mostly useful if you only have one display so you know which display sent the button).  And, of course after I submit this is when I will get around to cleaning up the library.  For now common sense would dictate that the higher the number the example sketch, the most updated it is (although I can be counted on to violate common sense at every turn, so take that with a grain of salt).

4017 based keypad matrix scanner

June 27, 2013

So, here’s  a simple concept I modified to be a lower pin count and fewer processor cycles less.  The original example I found here used a 74hc595, which is an 8-bit shift register) to scan one bit through the register and through some clever trickery with pull ups and pull downs read out serially what row and column that button is in.  My modification did away with the shift register (which you have to prime with one bit every time you scan) and replace it with a decade counter.  The decade counter does just what we’re using the shift register to do, scans one bit out many outputs.  The decade counter can start in an unknown position, but the start up reset circuit (a diode, capacitor, and resistor to temporarily pull the line high until the cap is charged, then pull it low always after that) sets it back to a known state.

I haven’t seen anyone else try this particular setup before, partially because if through some cosmic radiation (or something more likely)  and a bit gets flipped then you’ll be off-by-one for the rest of your days.  This can be gotten around by triggering the reset line before every read, but I’ll try my hardest to keep the pin count down.  The next problem is that the decade counter resets after ten cycles, not eight.  This should be able to be remedied by tying the reset line to the 9th output, but I haven’t had much luck making that work.  The solution  I came up with is to manually clock the device twice after every shiftIn().  My code here makes it easy to implement the keypad polling in whatever code you’d want.  This could be expanded to a 4×4 matrix with minimal modification (it was originally designed for such, but I’m not using one).

The circuit is fantastically simple to wire and to code for.  I didn’t have any circuit board I was willing to sacrifice to this temporary setup so this is some old wire wrap board (no copper).

This was to be used in the OpenAccess system, but it was abandoned like lots of other parts.

Teensy 3.0 based dumb POV globe

June 27, 2013

So, here’s a completely custom design I had, a POV globe done in 9 hours.  The motivation was easy, I am the president of the Michigan Technological University IEEE Student Lab, and we needed to have lots of blinky things to show off to prospective freshmen touring the university the next day.  We had some old stuff, but I had heard that there was a group on campus that couldn’t manage (over a number of years) to build a working POV globe.  I immediately stated that it should be a trivial task and that I could do it easily.  This statement was, of course, met with a suggestion that I should build one… so I did.  This is it:

I have to say that the big seam on the right was closed much better the first time I used it, and the paint jub on the base was done by a friend who wanted to help with the project.

The main parts of this are as follows: a computer power supply, a PC fan, a strip of metal bent into a ring, some foam board for the sides of the ring and the base, a 555 timer based PWM circuit, a Teensy 3.0, a battery, and some LEDs.  First I’ll go over my design philosophy for the base.  The base is literally made of a computer power supply and a PC fan screwed down to it as seen here:

The blades were broken off the fan so there would be no massive air currents or problems caused by having no air to suck up from the bottom.  The metal ring was simply hot-glued on to the ring and balanced so that there was minimal wobble.  The PWM circuit seen closer here:

As you can see, it’s a very simple circuit, I built it right on to a DIP-8 555 timer chip and have had no problem using it this way.  The reason I chase to do a PWM circuit rather than just use a POT as a voltage divider to vary the speed of the fan is that the fan is designed to run at 12v and is most stable (has the most torque) at that voltage.

Now, let’s look at the Teensy circuit:

So there are two things I have to say about this: I know it’s overkill, and the schematic is slightly wrong.  It should have the LED that’s going to pin P13 should go to P16.  I couldn’t figure out why that pin kept outputting data/clocks/noise on that pin, so I just re-mapped the output pins in an array in the code.  It was pointed out to me that if I had latches on the outputs that I could be assured the columns always turned on at the exact same time, but that’s for another later version which I’ll talk about later.

The battery is a cellboost single lithium ion cell + charger + step up converter to output 5v.

I thought it was the easiest solution considering I couldn’t use a slip ring connector to deliver power since the only axle was the PC fan and I wasn’t going to hack that apart any further than I had to for reliability’s sake.

At this point I feel I should address the lack of any timing mechanism.  I didn’t add a timing mechanism for three reasons, one: I didn’t have a slip ring connector to pipe in the tachometer from the fan, and two: I didn’t have a hal-effect sensor handy (the easiest way to get timing), and three: I didn’t have time.  The timing is done simply by setting the delay in the code to a sane value and fiddling with the POT until it processes very little.

Now that I have a spinning blinking thing, let’s pick something to display.  The earth is the most obvious thing that comes to mind, so I did it.  I got a picture of the globe as a Mercator Projection because of the way I placed the LEDs it meant simply dividing the picture into squares and representing the land/water data as binary.  I did that using this picture:

Yes, I did it manually, but hold on, that’s not the worst thing.  once it was represented in binary in code I just had to iterate through the columns and rows and write out the value in the array.  That’s not so simple when you’ve got the syntax for boolean evaluating operators wrong in arduino.  The absolute first revision of the code used one loop, the main loop, and a whole bunch of digital writes.  I feel kinda dumb, but I was also up for about 36 hours at that point.  The final code is here, and the github repo also has some other stuff in it related to this project, like a presentation I prepared to explain what I did.

There’s a glitch in Australia that was fixed in a later revision

I have an updated design that uses a parallel EEPROM and a bunch of discreet logic.  I will have a post about it soon if I can find the paper I wrote it down on.

Rre-purposing an HP laserjet control panel

June 27, 2013

One of the things I salvaged that I didn’t think would be that easy to get working was this HP control panel.  It turns out someone else has already done the legwork to get it working for the most part.  The original source I have for my specific control panel is here.  That site has a really good description of these HP modules, but I can certainly say they are not all the same.  It seems to me that the VFD controller (m66004) is SPI, there is also a shift out register (74hc595), and a shift in register (74hc165).  All of these devices being SPI you can control them all with very few wires.  The module I have has a VFD and 8 buttons, I have an m66004 and 74hc165 on my board.  There is also another version that uses a 74hc595 to drive LEDs as an output.  The arduino library doesn’t need to be modified to remove the LED driver code, but you just don’t have to use the LED output functions.  The board I have also has 9 buttons, one more than the shift register can support.  It appears that the 9th button is connected to the 2nd and 8th button inputs meaning that it cannot be detected independent of the other two and those other two cannot be detected together without incorrectly detecting that the 9th button has been pressed.  The code is 0-indexed, so it’s buttons 1, 7, and 8 that are tied up and button 0 is the first LED.  The demo code has everything in it to demonstrate how to use the functions.  The part I find most interesting is how easy it is made to define custom characters.  Here is my version of the code that does my best to detect the 9 buttons and doesn’t use the LED output commands that don’t apply to my board.  The original arduino library hosted here may have more button functions implemented than mine (there are button isPressed, wasPressed, and wasReleased for people that want to poll constantly or just check periodically).  

Siemens PLCD5583 arduino library/demo

June 26, 2013

OK, now I pulled one of these off the front of a rack mount server (dell, I think) and it’s really a pretty old design.  This display uses an 8-bit data bus for the character to display, and a 4 bit address bus to pick the digit to display it on. They also have a plethora of other features: individually flashing characters, blinking the display, brightness control, lamp test, and clear.  First: the flashing characters.  You can set a register for each character to set that character as either flashable or not, and set the characters that can flash to flashing or not.  There is a second bit that can be set to blink all the characters at the same time.  Next we have the lamp test function: this one sets the character to all on, and all the segments are on to see if any of them are out.  The clear function is pretty obvious, the brightness control has three bits of control from off to full brightness.  The code I have here on github is not a library (yet) mostly because I think I should use shift registers to minimize the pin count.