Robots need lights

In my spare time I mentor a FTC team.   This is the third year mentoring and each year I try to stretch the boundaries a bit as a way to inspire my team members, stretch the imagination, and show them that if they think it, they can likely do it.

This year, I decided it was time to break out the Hitechnic Protoboard that had been sitting around unused since we acquired it three years ago in a bulk buy of equipment from a defunct team.  I had an addressable LED light strip laying around in the garage and decided that drivetrain running lights would be cool.  This would require an Arduino to drive the strip via Adafruit’s Neopixel library.

FIRST’s rules however are quite strict with respect to microcontrollers on a robot.  If used, they must derive all power from the Hitechnic protoboard and the board can only supply 8mA from the 5V pin.   Hooking an Arduino up to a multimeter I quickly discovered it consumes almost 30mA at idle.  There are ways to reduce power consumption, but I wasn’t going to get where I needed to be.  So I took a blank ATmega328, burned an Arduino bootloader on it with a Leonardo and used it barebones on a motherboard. 

Current consumption in this configuration is well below 8mA and would work for the project.  The lights are on and we are drawing 1mA (note that the LED strip is drawing power external to the circuit supplying the mC, and the current requirement applies only to the mC).   In the photo above, the large breadboard has both LM7805 and LM7803 circuits and is supplying 5V power to the light strip and 3V power to the smaller breadboard with the ATmega328 on it.  Running the mC at the lower voltage is what allows us to get the current consumption way down and the protoboard has a 3V pin so we are good.

The FIRST rules state that LED lights themselves may draw power from the main robot battery pack , but since this is a 5V strip, a 5V regulator is required.  On average the strip draws about 600mA which caused the LM7805 to get hot enough to smell within a short period of time.  A bunch of math and reading of datasheets indicated that a heatsink with a thermal resistance to air of no more than 13.75 C/W would be enough to keep the LM7805 cool enough to satisfy the robot hardware inspectors.

From there it was simply a matter of setting up input pins, using the an NXT brick to drive a set of Hitechnic protoboard output pins into the ATmega328 (running Arduino software), reading the input pins and displaying the appropriate pattern on the LED strip.   We use one of the interrupt pins to tell the arduino when it should go reread the pin state.  The photo below shows what’s happening on the output pins of the protoboard by using a Salaea logic analyzer to show pin state as they change.

The project taught the team members about voltage, current, heat transfer, microcontrollers, binary number systems, and a smattering of Arduino sketch programming.  The electronics are all mounted on the robot, the light strip goes on this weekend.

Software here: https://github.com/cmacfarl/Arduino

It’s not rocket science

A while back I bought an Estes model rocket kit for my niece and nephew. Upon opening the package and seeing this

I thought, “Lame.”

So I set about making a custom launch controller. The idea behind the controller was to further spark the imagination of the kids. To that end, it has four ports, a countdown LED, and configurable launch patterns.

I wanted it to look somewhat retro and have lots of stuff to interact with prior to launching a rocket. The idea being to extend the amount of imagination time before igniting the rocket motor. It struck me that just pushing a button doesn’t give a kid a whole lot of time to play the role of the engineer in the launch room.

The controller has four different launch patterns controlled by the two switches at the top to the right of the on/off switch, a countdown LED, four switches at the bottom that provide safety override for the four launch ports and an LED ringed launch button.

The fifth port on the right side in the photo below is 12V in, the four on the left, are 12V out to the rocket’s electronic ignition fuses.  Hooking this up to a car battery works quite well.

The enclosure was designed in Autodesk Inventor and cut from 1/4′ (sides and bottom), 1/8″ (top) acrylic on Crashspace’s laser cutter.

Internally it’s controlled by an Atmel ATmega328 which drives transistors to switch the 12V out to the electronic ignition fuses, displays the LED pattern corresponding to the launch pattern, and runs the LED countdown.  There’s a small coin battery inside the case running the LEDs and arduino.

A mess of wires, with the eagle schematic I did just to keep my head straight while soldering everything up.

 

Software was written using Atmel’s AVRStudio.  e.g.  No arduino bootloader on that ATmega328 running an arduino sketch.  Straight up, old fashioned, C.

Living in the middle of a large metropolitan area, figuring out how to safely test the device was a challenge.  I initially used 12V auto light bulbs to verify the basics worked, but lets face it, that’s not nearly as fun as fire and smoke.  So I built a test rig, inserted some engines and had some fun.

Software can be found here: https://github.com/cmacfarl/LaunchController.git

Saving a broken LG L246WP LCD monitor from the landfill

My LG L246WP decided a few weeks ago that it was going to start refusing to turn on in the morning.  I’d press the power button a number of times before it would turn on.  This got progressively worse until one day it decided it was completely dead.  A little googling around revealed that others had a problem with capacitors going bad on LG monitors.  It was dead anyway, so I decided to take it apart and see what I could find.

The case on this model has no visible screws.  To take it apart you need a very thin pliable putty knife.  Wedge it underneath the seam around the edge and you should be able to pry apart the snaps holding the faceplate on.   Once the faceplate it off, the backplate unsnaps in a similar fashion.  It took a little work, but the end result is:

Removing the LCD panel exposes two circuit boards.  Given that I was having a problem getting power to turn on I decided to remove the board with the three pronged power plug.  NOTE: there’s a 450V capacitor hiding underneath with exposed leads facing you.  Do not take apart a monitor without fully understanding capacitor discharge and the dangers therein.  A fully charged, high voltage, capacitor can KILL you.

The two exposed circuit boards.  Be very careful as there are exposed leads here and you can’t see what danger may be hiding on the other side.

After removing the power entry board, I indeed found swollen capacitors.

The caps are 3300mF/10V.  My local electronics store only had 3300mF/16V caps on the shelf.  However, LG engineers were nice enough to include enough space on the board for the larger 16V rated caps.  Perhaps this is the problem to begin with?  Was the design originally for a larger capacitor, but they used 10V caps for cost savings therefore eventually resulting in this problem?

After desoldering the bad caps and soldering in the new caps.
Note how the new 16V caps fit the outline of polarity diagram on the circuit board exactly. A clue perhaps that the original circuit was designed for a larger cap?

Once the puzzle was put back together a power on test lit up the power on leds.  The cost to fix was $1.40 in capacitors.  Not bad considering manufacturers have moved away from WUXGA (1920×1200) resolution in favor of the inferior (1920×1080) HDTV resolution.

The not-a-gainclone LM3886 amplifier

A while back the Denon amplifier I’d had since 1991 decided that it had had enough and would no longer perform as an amplifier.  The idea of going to the local electronics retailer and buying a new one was distasteful, so I decided to build an amplifier around an LM3886 from National Semiconductor.

Disclaimer: What’s described below uses voltages on the mains side of the transformer that can cause serious injury or kill, do not disassemble your amplifier based upon the description herein.  Also note that this is not a finished product and close examination of the photos may find hot exposed wires.  e.g Danger.  Proceed with caution.

Early on I decided that I’d reuse the Denon’s chassis and that I’d just basically throw something together based upon the National datasheet.  e.g. no regard for what makes a gainclone (google gainclone) a gainclone. e.g no fancy expensive toroid transformer, little regard to capacitors (ok I did buy Panasonic FC caps from Digikey with the LM3886 order, but they weren’t exactly expensive), no regard to short feedback paths, etc…

The result is

The transformer is reused from the Denon.  I do not know what it’s amperage is but figured it must be enough.  There are two taps, I chose the taps that are about 20-0-20.  The other set of taps are around 30-0-30 and resulted in a rectified voltage at the absolute limits of the LM3886.  The 20-0-20 taps give about |V+| + |V-| = 52V.  Listening tests reveal this to be plenty loud at even half volume.

There are two bridge rectifiers but that’s because I screwed up with the initial implementation of the power supply.  The rectifiers were reworked such that the two are effectively just one (a waste of $2.00 in diodes) and |V+| = |V-| with the correct connection of common.

You can also see here why people go through the time and trouble to etch circuit boards.  The rectifier implementation results in a mess of wires.  It would be far cleaner on a PCB.

The transformer and a ground loop isolator to reduce hum.  Also note that, not wanting to kill myself with mains power I added a chassis ground.  The original build of the Denon did not include a grounded plug.  I cut the end off of a spare grounded power cord I had and used that instead on the power from the Denon cord entering the chassis.  For safety’s sake I also installed a GFI outlet at my bench power outlet and ensured that it was grounded properly.

The amplifier board itself at the bottom of this picture.  It’s simply a buildout on a protoboard of the example circuit in the LM3886 datasheet from National Semiconductor.  The input and volume pot are hanging off the right side, the speaker connections are wirewrapped on the left side.  Power is coming from the single DC supply on top, which is contrary to most examples I’ve seen which have separate DC supplies for each channel.  In my build, this really proves not necessary.

Note that I’ve already decided my heatsinks are not large enough.   I’ll have to build another with a layout that will accomodate larger sinks.  Listening to the Brahm’s violin concerto (there’s only one, unfortunately) at a moderately loud volume the heatsinks are uncomfortably warm.  Listening to Rush’s Signals album the sinks are “damn that hurt” hot.

Otherwise, for something that cost about $40 in parts, not including my free, reused, transformer,  and with little to no regard to the audiophile convention as to what should be done with this opamp, I am very, very happy with the results.  Yes, you can put this thing together in a rather haphazard fashion and it still sounds great.  I have to hand it to the engineers at National.  Not only for a great chip, but also for the fantastic datasheets that they are known for.

The ultimate goal is to enclose it in the stripped Denon skeleton.  I’ve just been having too much fun listening to it to disassemble it long enough to hide it in the chassis yet.

Desolation

The road from the top of Panamint Valley to Trona. Oddly enough, I saw no burros.

Virtual serial ports in ESX 4.0

I’ve been trying to figure out how to get serial ports as named pipes to work out of a guest os in VMWare for a while and finally discovered the magic incantation.

Search around on the web and you’ll find all sorts examples that show you how to configure a serial port as a named pipe and then instruct you to reference the named pipe from the host’s operating system.  However, despite what I tried, and despite what the official VMWare documentation said on the subject, the pipe refused to appear in the host’s filesystem.

The cause: Between ESX 3.5 and ESX 4.0 VMWare changed how the serial ports are configured and neglected to document this change.  All of the existing web pages that reference this subject deal with ESX 3.5 and before.

The first piece of the puzzle, use the vSphere client to configure a new serial port as a named pipe.  Select Server for the near end, and a process for the far end.   The name of the pipe must be fully qualified and it must reside in either /tmp or /var.  It can not reside in /vmfs.  Example: /tmp/serial1

The second piece of the puzzle lay in /etc/vmware/configrules.  This file, completely undocumented at the time of this writing, restricts how you can configure your guest os.  The default implementation prohibits the creation of pipes in /tmp or /var.   Note that this makes it impossible for serial pipe configuration to work from the vSphere client alone. In order to relax this restriction you must do the following

Comment out

#  reject regex_case “^/tmp/?”

In the

rule “No System Files”

section, and add

accept prefix_case “/tmp/”

to

rule “No Files Under /usr Except Virtual Media”
rule “Virtual Serial Port Device Backend”

sections.

Restart your guest OS and after the bios has booted you should see any named pipes you’ve configured.  Note that these pipes will be bound in order to /dev/ttyS0, /dev/ttyS1, etc in the guest OS.

Example: From the guest OS:

[hostname:~]$ echo foo > /dev/ttyS0
results in the following appearing on the ESX host when binding socat to the named pipe:

[root@hostname tmp]# socat /tmp/serial1 –
foo