PowerDistributionUnit

PowerDistributionUnit Background Hardware Inspection What I learned J14 Pinout Software Testing First Pass Back to the Hardware Back to the Software Conclusion

Background

I found some 'flaky' APC AP9217 PDUs in the trash and grabbed a few to play with. These have 8 power plugs that can be individually toggled which is infinitely useful for cycling the power on anything. As well as documenting how I modified this device this page is meant to serve as a general hardware hacking HOW-TO since it is a pretty easy to follow example.

• MasterSwitch: AP9217 Product Page

These units had the power cords cut so I spliced in a standard computer power cable by cutting off the one end and soldering the correct wires together. Still once I powered it up nothing happened. I'll refer to the data sheet but I am guessing that the missing smart slot cartridge is needed to control the system.

Be super careful when splicing power cables because there are tons of color standards and just matching color to color may not be safe.

Hardware

Inspection

By opening up the case (according to Makezine I now *really* own this puppy) I can see there isn't too much going on here. I start with the power section I see the AC input line passes through a reset switch, then to the PCB. Neutral connects directly to the PCB as well as each AC outlet, and Ground is attached to the case as well as the 3rd prong of each AC outlet. The other prong of each AC outlet connects to the PCB in line with a relay. 8 outlets, 8 relays. It is pretty obvious that somehow the electronics energize or de-energize the relay to control whether or not the input AC is connected to the AC outlets in the PDU. There are also 8 leds - they probably indicate the state of the power for each outlet. There's only a few ICs and no MCU as far as I can tell. By looking up each chip I can probably figure out how the circuits work. Taking the PCB out confirms that the LEDs and relays are in the same circuit. Luckily it looks like a 2 layer board so visually following traces will be much easier.

What I learned

The general concept is simple - there is a bank of relays that connect to the line contact in each 120VAC plug. The input line is simply connected to each output through these relays so toggling the relay allows you to break the flow of electricity to any given outlet. Additionally there is a bank of LEDs that correspond to the outputs so you can tell which are on or off. The relays are NO (normally open) which means that the outlets are off by default which is probably the safer state but unfortunate. This means that the relays have to be constantly energized for the attached device to remain on. These PDUs should probably always be plugged into a UPS to ensure power ripples don't trip the relays due to a under-energized relay coil.

The relays are controlled by a UCN5821A (Serial input latched driver) and this is the key to driving this board. The APC design powers the logic of this chip with 5V (it also runs at 12V) which is perfect for me. I should be able to hijack this chip and control it with an AVR, ideally this is all that's needed to replace the missing APC controller.

Serial Interface and timing for the UNC5812A:

• Data is latched on clock rising edge
• Data is loaded directly into control register when strobe is high (not what I want)
• strobe occurs after all data has been transmitted
• strobe is complete on strobe falling edge

The control software should then bit-bang this interface thusly:

drive strobe low
for 0 to 7:
  drive clock low
  load next data bit
  drive clk high to latch data bit
drive strobe high
drive strobe low to latch input buffer to output register in 5812A

J14

J14 connects the Smart Slot controller to the relay board inside the PDU. Since I don't have the controller I need to make one. J14 is the controller's only link to the world so J14 should contain all of the control lines for controlling the relays as well as some power to power the controller.

Pinout

After tracing the connections with a multimeter I found that J14 does indeed have all of the signals needed to control the 5821 and thus the relays. There is a 4001B NOR gate buffering between J14 and and the 5821A so hopefully it's just a buffer and doesn't have some crazy protection circuit built in. There appears to be a 2K resistor between J14 signal pins and the NOR gate (presumably to limit current).

J14 Pin	Function
2	Gnd
6	5V
8	Clock
10	Data In
11	NOR Enable
13	Strobe

• /OE (output enable, active low) connects to ground thru a diode like this: /OE---|<|-----GND

Software Testing

The first thing to remember with embedded software is it is generally a long drawn out process getting it to work. This is especially true when you are reverse engineering the circuit board as well. Hook up the hardware to your AVR loosely. At this stage it is much more important to be able to probe things with the multimeter than have it look nice. Once everything is tested and working you can button up the whole system in a pretty little package. If you do that too soon you are going to waste time taking everything apart again. DO NOT glue anything down at this stage unless you really hate life and need to suffer.

First Pass

Most of my initial findings hold true but my program doesn't work (big surprise). Here is how the debugging process is going. I have very few tools at home but should be ok. I only have a ISP programmer (so no JTAG debugging) and a multimeter (so no capturing signals). To work around this I have sprinkled avr_getc() throughout the program to pause the program at various points. This is a poor mans breakpoint and at least allows me to verify the program logic.

I quickly found that the signals I need to drive the 5821A (CLK, DATA, STROBE) behave as I would expect on the PCB. Since I know the AVR is generating the correct pulses with the correct timing I'm at a loss for why its not working. Well, that's not true, but it means that I now have to verify that the signals are getting to the 5821A.

LIkely Issues At this point

• I misunderstood the datasheet and am driving the chip with the wrong timing (very likely)
• The pinout is wrong so the correct signals are going to the wrong places (also pretty likely)
• The signal isn't getting to its destination for some hardware reason. (there is more to the circuit that I thought)

I always verify the hardware path first. No amount of software will fix a circuit that you aren't using correctly. By measuring the DATA line at the 5812A I can see that the correct signal is arriving at the DATA IN pin (the 1's and 0's in my software output match the voltage levels at the pin). I know that the data is getting from the AVR to the 5812A so that's not the issue. Trying the same with the CLK and STROBE signals does not yield what I want though. Ah-Ha! Remember there is a NOR gate between the 5812A and AVR - first I need to check that the signal is getting from the AVR to the NOR input. If this is the case than I know its the NOR gate that is stopping the signal from getting to the 5812A (remember, I know the AVR is generating the correct signals on CLK, DATA, and STROBE). More testing shows that the inputs to the NOR gates get the correct signals but the output always stays low on CLK and STROBE.

Note: This makes me question whether the DATA signal was acutally getting through. I'd better go back and verify that.

Of course NOR gates each have 2 inputs, one of which is DATA, CLK, or STROBE (so a total of 3 gates used), the other input has to be the problem. Sure enough the other input to CLK and STROBE (I'm ignoring DATA because I think its working correctly) are tied together, and what's worse is its HIGH - that means that regardless of my signal input the output will be LOW (its a nor gate after all). At least the 'other' inputs are tied together so once I solve this for one, I have solved it for them all. As a bonus if I was wrong about DATA being ok, it's 'other' input on the NOR gate is most likely tied to the other 'other' inputs.

Back to the Hardware

It was painstaking work, even on a two layer board, to try and follow all the traces but I needed to better understand the circuit to make it work. Obviously there is some way to control the 'other' inputs on the NOR gates which is acting as an enable. It is most likely one of the IO pins in J14 but which one? Also while I'm in there I should verify that DATA doesn't pass through an effected NOR gate as well.

The result (of taking the whole PDU apart and pouring over the circuit board for what felt like hours was this:

As you can see, this isn't the most legible schematic but it does help me explore the circuit. I can see that driving J14.11 low should drive 'other' low and enable the signal to pass through to the 5821A.

Sure enough there is an ENABLE signal in J14. Hopefully that's all that I missed. One other oddity is one of the filter caps on D50 seems to be installed backwards...

Back to the Software

Now that I think I understand the hardware I can add a little code and everything will work right? Wrong...I was seeing weird behavior but was able to flick on a couple relays (totally random relays but the fact that they were activating meant some signals were getting through). I wanted data to stay HIGH, but it would get driven low when I drove CLK high and vice versa. Long story short is I did my bitwise math wrong and was squashing one signal when I toggled another. In hindsight it was a stupid mistake but one that is easily overlooked

PORTA |= (1<<CLK); //this is correct
PORTA &= (0<<CLK); //whoops, that's not what I want

PORTA &= nCLK; //that's what I want, nCLK is the 2's compliment of CLK

With this minor change to the 'clear bit' commands the pdu springs to life. woot! 'bout frikin time. There's still plenty that can go wrong so until I'm fully satisfied I'm going to do a temporary button up. I'll just hot-glue the controller in place in case I need to take it out again. At some point I would like to hook up the onboard relays to some terminal blocks on the PDU case but for now I need a break from this thing.

Conclusion

I'm very pleased that I was able to build a controller for this PDU and I actually have a use for it which is more than I can say for most of what I build. The initial inspection of the hardware told me 80% of what I needed to know to control it. As usual the last 20% was 80% of the work but it paid off. I approached this exactly the same way I do any new electronic design bring-up. One advantage is you can be pretty sure the hardware is solid - APC didn't get a good reputation from crappy hardware, however, one huge disadvantage is you have to deduce the schematic as you go but that adds to the challenge. One nice things is that most electronics basically work the same so it gets easier to make educated guesses on how your unknown hardware works.

Here's the new APC MasterSwitch user manual:

• USB connection (via FTDI chip, linux users are all set, mac and windows need drivers)
  • 9600 8N1
• Only give one command at a time since only the first command will be processed, the others will be ignored.
• Commands:

  'E'	End of Command, when this character is seen the controller will process the command buffer (uart buffer)
  'rX'	Refresh onboard relays, relay will be energized for a short time, then de-energized. Use for small DC loads to reboot (i.e. router, modem). X is bit pattern to apply (0-7)
  'nXXX	APC PDU Control. Write the bit pattern XXX to the PDU. Must be 3 digits, 000-255, LSB=Relay 8, MSB=Relay 1
  'f'	Flush command buffer
  'H'	Help - not implemented

Example:

• Turn on Relay 1: Send the serial string: 'n128E'
• Turn on Relay 8: Send the serial string: 'n001E'

Source Code

• apc_masterswitch.tar.gz: APC MasterSwitch Controller source code
• AVR pinout
  • Signal: CLK - PORTA0
  • Signal: STROBE - PORTA2
  • Signal: DATA - PORTA3
  • Signal: ENABLE - PORTA4

-- ChristopherPepe - 15 Feb 2008