Archive for January, 2014

Wake-On-Lan Powerstrip

January 20, 2014

For the one of you that has this blog as an RSS feed you’ll probably have figured out I’m not staggering posts, I put the information out there just as fast as I write it.  I’m not looking to build a community, but more to be indexed on google so that people who are looking for help on specific subjects can get it.

This is a project that is a blatant rip-off… I mean derivative of a hack made by a friend of mine over at the i3Detroit hackerspace. His hack used the Wake On Lan feature to reset a server, mine could be used in the same way, but I tend to use it as a fancy lightswitch.  That article I linked to has a fantastic description of component choice that I won’t try to duplicate here, I’ll just go over the implementation I used and how it differs from his.

I will first start by saying that this design has gremlins.  It took me way longer to transpose the circuit from paper to breadboard and have it work, and I gave up trying to convert from breadboard to protoboard around attempt five or six and just started soldering components together and rolling up the breadboard circuit into a solder blob (which functions to this day).  I have since designed a board for this project.  I plan to eventually roll it into a tindie (or kickstarter kit campaign) but until I get around to that you can do it yourself with the provided schematic and eagle board files.  Feel free to make a surface mount one as well if you feel that adds much benefit (it’s just a cost savings in board fab and parts, the size is already as small as needed (as small as the network card is).

design document

My modification to the circuit uses the output pulse from the 555 timer to trigger the clock input of a D-latch (wired as a flip-flop) through a FET.  Let that sink in for a minute, read it over a couple of times slowly.  The last bit uses another FET to drive a relay based on the output of the flip-flop (a relay attached to the power strip).

breadboarded circuit

OK, so let’s start with the “through a FET” part.  A Field-Effect Transistor is a transistor that has an amplification curve such that it is effectively an on/off switch.  That means that while it is truly analog, if we use it right it can very easily be used to just pass whatever current you need with a small signal.  In this case I’m using it as a buffer so the 555 timer chip doesn’t have to drive the flip-flop directly.  This is overkill, but with the amount of trouble I had making this work in the first place I though it wise.

Now we’ll tackle the “D-latch wired as a flip-flop” part.  So, this may be a well known configuration (and having a bachelor’s degree in EE now I should know that) but I came up with it independently of anyone else.  The latch takes whatever is on the input and puts it on the output when the clock pin is twiddled (rising or falling edge, I’m not sure).  The chip I chose has a complementary output, that means they have the opposite of the output on another pin, so when the output is at 5 volts, the complement is at 0 volts and vice-versa.  I used this to my advantage.  I wired the complement to the input so that whenever I clocked the chip the output would change to the opposite as I latched in the complement to the output.

The modification I suggest is that rather than oscillating the output you could have two network cards with two MAC addresses and when you WOL one it turns on the relay, and the other turns it off, regardless of the state beforehand.

blobs that work so well

After this picture was taken I decided that having the neon lamp indicate status would be preferable because the one on the powerstrip sucked.  The blob on the left is the 555 timer, the one in the middle is the latch, and the one on the right is the relay.  The whole thing is built into a computer power supply body and powered off of a salvaged 5 volt wall-wart.  The software I use is either wakeonlan for linux or any wake on lan client for android and I can blip the power from the internal network.  If I can ssh into a server on the network from the outside then I can blip the powerstrip from anywhere on the internet.  That is not really useful because there is a small chance of the circuit bouncing (an RC damper could help) and my current one doesn’t turn it off, it only changes the state.

whole thing

There it is, a way to use up all those PCI network cards wasting space on your shelf.  No code, COTS parts, and you can flip a bit on your network.  This is essentially a network attached bit, get 16 (one for on and one for off) cards and you can have a very very slow 8-bit bus.  Throw on two more for a strobe line and you could bit-bang a dot matrix printer on the network.  The cool thing is that you can literally solder the input 8p8c (RJ45 to some of you) jacks in parallel since they’re passively receiving.

The eagle layouts will go up just as soon as I go home and upload them.

EDIT:

Eagle layouts are up now, I invite you to do better (because it only took me a night).

design for though hole component version

LCD monitor repair (again)

January 19, 2014

OK, so this is one of those days that starts with big plans and gets derailed seemingly because those plans were so well thought out.  I come from a group of people that spend their days just repairing things because they’re there.  We have taken it in stride to develop techniques for repairing commonly thrown out items and apply our experience to new items as we get a hold of them, but we rarely document our work or share our knowledge beyond the confines of our lab.  This is the story of what happened when I tried to document what I figured would be a routine repair on a common model LCD monitor.

I never know what to put in this text

Our Patient

The monitor (as you can see) is a Dell 1907FPt 19″ widescreen LCD monitor.  The first thing I recommend when you have a device of any kind to repair is to look up that model (or series) and see if anyone else has encountered problems with it.  Hopefully you’ll run across a helpful blog post of someone who took the time to explain the steps they took to debug and fix theirs, so you can cut down on the time it takes to fix yours.  I, of course, didn’t do that.  I have no idea what the common failure modes of this monitor are and what the commonly accepted fixes are, so I blazed my own trail to some hilarious consequences.  Seriously, do as I say, not as I do.  For every blog entry of a moderately successful hack/repair I have there are a dozen failed ones that could usually be avoided by spending some more time researching and less time breaking things.  In the future I hope to post my failures with notes for future pioneers, but my successes are usually still around after the fact so photos are easier to take (since I almost never take them during the event, but months after).

Now, having opened more than my fair share of Dell monitors I thought I’d itemize just what steps are involved.  First you need to remove any visible screws, this usually just consists of the four phillips head bolts on the back (seen above).  Next you need to insert a spudger (yes that’s a technical term, look it up) into the gap between the monitor back and the bezel.  That separation into two pieces is the entirety of the plastic casing on this model.

seriously, adding content in secret? I already have a title and caption, what else can I possibly add to this image in this way?

step one

tabs exposed

keep going, almost there

and there you go, dis-assembled

Once you get the back off of this monitor you will inevitably hear a clatter as something falls to the floor and hides among the junk there until you figure out what exactly was missing so you know what to look for.  What you are looking for is a small plastic button and spring that retains the base to the monitor.  The button is a Dell thing, they have brackets on their stands that allow you to use your monitor with only that stand and not that of another Dell monitor.  These stands are “tool-less” which is slang for “our main consumer base can’t operate a screwdriver”.  The monitor itself has VESA standard mounting holes, but the stands are mostly useful for the monitors with which they came (although I may explore the hacking I have done on these stands in a later post).

The button and spring, free without the back

carefully remove this ribbon cable and the double-stick tape that holds it to the monitor casing

Now we need to just keep removing screws and remember where they came from.  You can usually ditch the shielding if you don’t care about potentially harmful interference as covered in FCC part 15.

remove one cover over the inverter wires

and the other

remove the inverter wires from one side

and the other, while you’re at it remove the screws that hold the monitor to the controller board housing on both sides

the panel without any controller, power supply, or inverter

now remove the screws that hold the heatsink to the casing

screws seen here (note they are flat, they mount flush with the panel

power supply board has had it’s screws removed

mains plug with screws removed

screws in question

Not pictured (I know, with all these pictures I forgot one) is the removal of the logic board’s retaining screws and the mounting hardware for the d-sub connectors (VGA and DVI, although DVI’s not a true d-sub).

controller board

Here is the controller board.  There were no bad caps on it, which is a shame since that would have been an easy fix (unless the problem caused a chip failure).  On the bottom are the ports exposed to the outside.  DVI, VGA, USB-b, and a dual stack USB-a.  This particular monitor has a four port usb hub built in (which I’ll go into later).  The port on the right side of the board is for a two-usb port daughter board for the hub (only passives if anything).  The ribbon port on the right is for the front panel controls (bonus points to those of you who remembered that ribbon from earlier).  It is noteworthy that different versions of Dell UltraSharp monitors use different pinouts for the cable with different numbers of features, but they all seem to use the same size cable and connector so they are interchangeable as far as that goes (buttons have different functions, or no function at all).  The port on the left is for power input (it could be pinned out, but I didn’t as they’re usually labeled).  The top port is the LVDS signals to the LCD panel.

close up on VGA and DVI port electronics.

So, the three chips here are two i2c EEPROMs and one chip that I assume is the receiver for the VGA signal.  The eight SOT-23 packaged devices to the left are probably FETs being driven by the differential signalling on the DVI port (the same as the monolithic analog receiver for the VGA port.  The EEPROMs are of note because they hold the EDID information for each port, they tell the computer that’s connected to the monitor what resolutions are supported.  The noteworthy fact is that these type of EEPROMs are massively useful as they’re easy to reprogram and use in things like PCI network cards, motherboard BIOS chips, and USB peripherals.  The chip with the little white sticker on it is probabbly the i2c EEPROM that holds the settings for the Genesis main controller, setting what the settings on the LVDS panel are.

This is interesting to me because you can now buy generic LVDS driver boards and inverters to make use of that surplus laptop LCD panel and I have this thought that I could re-purpose one of these drivers to be used on a different panel.  This phenomenon changes the standard answer to the question of “I can hook the composite signal of my n64 to this old laptop panel” from “No.” to “Maybe.”.

USB hub

So, this circuit is interesting, it’s a USB hub.  The USB hub is entirely separate from the controller that drives the LCD except for power.  I have in the past had good results tracing out the power for the circuit seen here and cutting power to the rest of the board to use it as a stand-alone hub.  The thing about powered and un-powered hubs is that in most of the hubs I’ve seen is that the 5 volt power is hooked directly to the input 5 volt line on the USB-b port.  The un-populated chip on the upper right side of the board is probably another one of those ubiquitous i2c EEPROMs that would hold the USB Vid:Pid pair (as seen in that older article on the logic analyzer).

Here is the problem, the backlight doesn’t work.  The symptoms are that when you power it on one of the coils fizzes and then the over-current protection kicks in and kills it.  Presumably the coil had shorted, so I did the inadvisable and replaced it with an inexact replacement coil.  That coil fizzed as well, so I figured there was a problem further upstream.  Probably a broken FET that’s passing too much voltage or something, but I never found that out.  My solution was… very hackish.  I replaced the inverter with a new one.  A new one salvaged from an HP film negative scanner lightbox.  I don’t have pictures of that, but the inverter is exactly the came as one out of one of those blue inverter boxes from the mid 00’s that drove the ever classy blue cold cathode tubes (you know, the ones that are really shitty quality and explode periodically).

crazy solution being tested

In this picture I have removed the coil (no more arc-ing (fizzing)) and powered the inverter from the 12 volt out put designed for the amplified speakers that are an optional extra for this and most model Dell monitors.  The problem is that the backlight still shut off after a few seconds.  Time for some more fast-and-loose hacking.

underside of working inverter

So, without tracing out the circuit here I can see a bunch of diodes and resistors tied to the high voltage section of the transformer.  The thing I can assume from here is that a network like that can be used to sense the voltage (through dividers) and waveform (through dividers or zeners) of the output of the step-up transformer.  This type of closed-loop control is advisable so you can shut down parts of the circuit without blowing anything up.  It is also the enemy of simple hacks like this.  Let’s look at the section I modified.

lobotomized is more like it...

“modified” board

So, of note here is that I removed pretty much everything.  The red stuff is glue used to hold the components down before they were soldered in (or maybe to take the mechanical stress off the solder).  This part of the board was gutted and I assumed I’d have to feed the signal from the other inverter to the sense circuit for this one.  I didn’t.  It just works.  Who would have figured.

I was debating putting that quote in this text, but I get few enough views as it is I can't afford to waste a joke

you’ve had some cowboys in here…

The final configuration, complete with plastic sheet for insulation and hot glue for adhesion.

It works!

That’s it.  That’s how a simple post on a “standard procedure” repair became a Frankenstein’s monster post.

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).