Weird APC Back-UPS ES 650 BE650R-CN overvoltage behaviour

Today there is a sustained overvoltage at around 130V. I'm told they paralleled a bunch of feeder lines because of work being done today. I found out about this because an APC Back-UPS ES 650 (BE650R-CN) malfunctioned, and I noticed the "decreasing voltage" light on the line-interactive UPS which I used as the replacement.

I was told that the BE650R-CN was beeping a lot in the morning and that it stopped supplying power. When I plugged in and turned on the UPS without any load or computer connection, it initially seemed to start normally. However, when the power on self test was supposed to finish and the UPS was supposed to switch back to external power, it instead started repeatedly clicking as if it was switching back and forth between external and UPS power.

After seeing this, I took out the battery and tested it. The battery seemed charged, at over 13V, and it was capable of powering a car headlight. Later, when I put it back in the UPS, I could power a 100W incandescent lamp. The on/off button sometimes sticks and fails to pop up, but other than that, the UPS seems fine. It supplies external power, even though the external voltage is still 130V. The upper limit is set to 139V.

I'm left wondering what happened. Did I run into a firmware bug, which was fixed by removing the battery for a while? Could the sticking power switch cause this? Is the upper voltage limit stored in non-volatile memory, or was it possibly lower before and reset by removing the battery?

Building Rockbox simulator in Windows using Cygwin

When building the Rockbox simulator under Cygwin in Windows, an important thing to keep in mind is that the simulator is normally being cross compiled. It is being built within Cygwin using Cygwin tools, but it's built to run outside Cygwin, as a normal Windows application.

When using the sdl package from http://download.rockbox.org/cygwin/, tools/configure doesn't need to be told about the cross-compiling because sdl-config adds the -mno-cygwin switch. That switch tells the old GCC 3.4.4 compiler to build a standard Windows application instead of a Cygwin application. The switch is only really meant for compiling parts of Cygwin which must not depend on Cygwin, but it works.

If you instead use SDL from libsdl.org, the -mno-cygwin flag won't be added and an attempt will be made to compile the simulator as a Cygwin application. This fails with many errors in /usr/include/sys/reent.h because Rockbox firmware/include/_ansi.h is included instead of /usr/include/_ansi.h.

If you try to use the -mno-cygwin flag in Cygwin gcc-4, you'll be told "The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler."

The MinGW-w64 project provides good up-to-date MinGW compilers. Cygwin packages are available from within Cygwin setup. It's possible to use that compiler and SDL from libsdl.org by setting CROSS_COMPILE=i686-w64-mingw32- when running configure.

With either the old Cygwin compiler or i686-w64-mingw32-gcc, there are linking problems with multiple definitions. Those can be ignored by adding -Wl,--allow-multiple-definition to GLOBAL_LDOPTS in Makefile.

My VFD display project

In 2004, I built this project around a vacuum fluorescent display (VFD). I bought the VFD at American Science & Surplus when visiting a friend in Chicago. It is clearly designed for a piece of consumer audio equipment with tape and CD players. There are various audio-related indicators at the top, a 12 character 14 segment display in the centre, and two bar graphs and a two digit 7 segment display at the bottom. I use it to display Winamp status, CPU load, and a few other things. Here's a closeup of the display:

A VFD is basically an array of triode vacuum tubes. Thin and almost invisible wires stretched across the display form the cathode. They emit electrons when heated. The phosphor coated display segments are anodes. When they're significantly more positive than the cathode, they attract electrons which make the segment glow. To reduce the number of pins, segments are connected together and the display is multiplexed via the grids. To light up a segment, a positive voltage needs to be applied to both the corresponding anode and corresponding grid.

Special purpose chips are typically used to drive VFDs, because required grid and anode voltages are higher than logic voltages. I chose the Allego A6812. The chip contains drivers, a shift register for loading contents serially, and latches so that output can continue while new data is loaded. The cathode also requires its own driver circuit. Because the cathode is also the heater, there is a significant voltage drop across it. If it was powered by DC, one side of the display would be brighter than the other, and so it needs to be powered by AC. I built the driver using a 555 timer and an H-bridge. Here is the driver circuit board before the display was placed on top:

I first tried out the display using an MC68705P3S which had a small bootloader for loading code into RAM via the parallel port. This was convenient because normally, code needs to be written into a 2716 EPROM and copied to the MC68705P3S, and then the microcontroller and EPROM need to be erased via ultraviolet light before the process is repeated. After this experiment, I started working on the permanent firmware, basing it on the firmware from my LED sign. Here's a photo with the unused initial circuit on the breadboard, and the start of the final circuit on perfboard:

I had a lot of TTL chips which I easily removed from a large ISA card, and I ended up adding several of those plus some other chips to the project. I added various capabilities: 6 digital outputs, 4 analog inputs (via an ADC0804 with multiplexing via a 4016), and a shift register to accelerate loading of data into the sign. (Many modern microcontrollers have similar functionality integrated into the microcontroller chip itself.) Here is a closeup of the almost completed main board:

One of the last things I added was a simple step up converter, so the VFD anode voltage is derived from the 5V supply that powers everything else:

Like with my LED sign, the case consists of quarter inch plywood. This time, I made the case by myself. Drilling edgewise into plywood isn't hard if done slowly and carefully. Here are a few photos of the case, progressing from the two boards connected together to the final painted case:

The firmware started out with the software serial code and command interpreter from my LED sign. Thanks to various optimizations, serial communication is at 1200 baud. This time, the command prompt offers only basic functionality, because I focused a lot more on functionality that's meant to be used from software running on a computer. From the command prompt, software can enter into what I call "byte mode", where commands are efficiently encoded into bytes, and they can be sent without any waiting. In that mode, the sign can multitask, scrolling a message without interruptions, while accepting other commands. That mode is also optimized for sending bar graph values and changing numbers at individual locations in the display.

The last thing I added was standalone ability to function as a clock, with multiple "alarms" changing the parallel outputs. The crystal oscillator provides good accuracy, and it was easy to calibrate the clock based on drift observed overnight.

The software controlling the sign currently runs as a Winamp DSP plugin. That is because the main function of the sign is display of Winamp status. It's not something I really need, but I really like it. When Winamp isn't playing, the bar graphs display CPU activity. This part is really useful if I turn off the monitor for some long operation, or to monitor CPU usage when running full screen software. It also helps spot anomalous activity, such as an application taking up 100% of one core.

I've used the digital outputs for various purposes. At first, I used the clock and alarm functionality to turn on my computer when it's time to wake up. Later, I used it to upload code to MC68705P3S microcontrollers for various experiments. Most recently, I used it when first trying it the TLC5940 for my RGB lamp. I didn't do as much with the analog inputs. One is connected to a photocell, and another to a thermistor, but I don't really need that data.

You can download the firmware from Dropbox and see a few more photos in the album.

My LED sign

I made an LED sign about 14 years ago. It consists of a 72×7 array of 5mm red LEDs. The LEDs are flangeless, which allows tight packing on standard perfboard.The array was easy to build: I just bent the pins over and soldered them together, adding electrical tape to isolate between rows and columns.

The case consists of quarter inch plywood with an acrylic front. My dad helped me with that, because it involved some tricky drilling lengthwise through plywood. I designed and built all the circuitry inside. Here's the sign with the front removed:

You can see spacers made from bits of hardwood flooring, and a bit of circuitry. The circuitry drives rows via transistors which have low saturation voltage. Here's a closeup:

The circuit boards simply slide out of the front. They consist of one board with the LED array and row circuitry, and another board with the microcontroller and column circuitry. The components face outward, and the wiring is in the centre. Here is the other side of the sandwich and the empty case:

The microcontroller controls the sign via a chain of 74HC374 octal D flip-flop chips. It outputs 8 bits, pulses the clock to latch data in the first chip and move data to the next chip, and repeats the process. While this is going on, the outputs of the last chip in the chain are disabled, which blanks the sign via the row drivers. To provide sufficient current for the rows, 7407 buffers are used. Current limiting is via the yellow DIP resistor arrays. Here is a block diagram:

The microcontroller is a Motorola MC68705P3S, from the 6805 family. I chose it because I had the chips, programmer and toolchain from a previous project. It is a very basic 8 bit NMOS microcontroller with 112 bytes of RAM and 1668 bytes of EPROM. Unlike modern microcontrollers such as the MSP430 family, it has very few registers: the accumulator, index register, program counter, stack pointer, and condition code register. Also, output levels are similar to TTL, so the first 74374 in the chain is a 74HCT374. Here's a closeup of the area around the microcontroller:

The sign works via a serial interface at 600 baud. That may seem ridiculously slow, but it's the perfect speed for receiving new columns for horizontal scrolling. A slow speed is also required due to the microcontroller's limitations. The external oscillator is 4 MHz, but 4 cycles correspond to one instruction cycle, and all instructions take several cycles. There is no UART or DMA hardware on the chip, and everything is done via a timer interrupt and assembler code. The timer interrupt runs at three times the baud rate, so when a start bit is detected, subsequent bits can be sampled in the middle third of the bit. The electrical interface to the serial port is via a MAX232 chip at the other end of the board.

Firmware functionality is quite basic. There is a command line interface with a few functions for direct human use and a few functions which work with raw binary data. The human interface consists of an interactive drawing mode, printing of text via the on-board character generator, sign clearing, lamp test, and returning the sign contents in human-readable form via the serial interface. Due to limited EPROM space, the on-board character generator just supports one font with uppercase letters and some symbols. Other functions support scrolling up and to the left, uploading arbitrary bytes, and uploading groups of columns. These functions allow uploading of raw sign contents, where a character generator running on a computer can provide additional flexibility.

On various occasions I spent time working on PC software for the sign. I first built an interface library. Then I built a server which accepts requests from clients, along with a library that clients use to connect to the server. This allowed multiple programs to use the sign at the same time. Finally, I added support for messages which appear at most and/or at least for a specified time. This should allow the sign to be used for notifications. However, I never used it for a sustained period, because such a large notification display isn't very practical.

Besides looping a short message, there is no support for standalone operation. That means the sign is not able to display various messages with effects one would see on a LED sign that's used for advertising. I don't regret this lack of functionality, because I don't think I'd find that useful. However, if I was building something like this now, I would definitely use a more powerful microcontroller which could support that and more. I thought of replacing the MC68705P3S, but that only makes sense if I have some usage in mind.

You can download the firmware from Dropbox if you're interested. I developed it using the Motorola Portable Cross Assembler (PASM) version 1.0 toolchain.