High Voltage Keyboard

Every mad scientist type should have their own organ/keyboard.  This is necessary tool when contemplating 'evil'.  (at least, according to some classic movies)

Figure 1:  Capt Nemo's pipe organ from "20,000 Leagues Under the Sea" (from wikipedia)

Capt. Nemo's pipe organ is impressive.

High Voltage Keyboard

My keyboard is not very loud and visually, it is a turd.

Figure 2:  The High Voltage Keyboard

One problem is that I have no musical ability, I don't play any instruments or have any vocals.  So, why build a keyboard?  'Cause I can!

Introduction:
This "musical keyboard" uses flyback transformers to create an audio modulated high voltage arc discharge.  Each key controls a driver board.  When activated, the key applies power to a high voltage transformer.  The transformer makes an arc, which is modulated at a set frequency.  This frequency produces audio.

Disclaimers:
    -This project deals with high voltage (greater than 3KV) at some significant current.  Do not die from this if you attempt to recreate the circuit.
    -I have never played a musical instrument and know next to nothing about any instrument.  The last musical thing I did was maybe 30 years ago, and that was choir.  Pianos/keyboards have black and white keys.  This keyboard has no keys you would consider "black".

Figure 3:  A better view of the keys

Why this project?:
I work for a company that manufactures neon power supplies.  We buy the high frequency (20KHz) transformer from a manufacturer in China and then stuff the PCB's domestically.  On one of the mid range power supply transformers, we were occasionally having the secondary wires burn out near the pin on the transformer that mounts into the PCB.  Before the problem was resolved, I ended up with several handfuls of units with slightly burned up secondary coils.  The coils were easy enough to repair by hand, but not acceptable to be sent to a customer.  So, I had roughly 50 of the coils and I asked myself:  "What could be done with these coils other than throwing them in the trash bin?"   This was how the High Voltage Keyboard project started.  However!  Since these coils were in the mid range power output, I was not able to get much of an arc from them.  So, I ended up using a higher power flyback transformer.

Figure 4:  A single driver board and flyback transformer

Before I decided on the higher power flyback transformers, a couple of other circuits/transformers were reviewed.  First, an automotive car ignition coil was evaluated, but it was found the car ignition coil would not create an arc when modulated above roughly 3KHz.  A high (20KHz), modulation rate is needed to create the audio tones in the arc.  Secondly, I at looked at several types of solid state tesla coils.  There are several fine examples of small sized tesla coils that create an arc of 3cm or less and have a very small footprint.  Since most of these tesla coils relied on feedback from the high voltage to find the resonance point, having several of these operating in close proximity to each other seemed like a bad idea.

Since a single arc is capable of reproducing music, is having 25 separate arc's with a set tone really necessary?   There are a couple of reasons I went with the separate notes for each key rather than just a single arc discharge.  Keep in mind, that I know next to nothing about music.

Keep it simple:
Whenever possible, I tried to use things I had on hand to keep costs down.  This had an impact on many parts of the design:   some components on the PCB, the wood used for the frame, the white paint, etc.

Circuit board hardware:
It was nice to work on a somewhat long term project that has no microcontroller.  A microcontroller could have been used to generate the audio modulation rates or to multiplex the keyboard keys.
The circuit is based around U2, an IR2153D.  This is a self-oscillating half bridge driver.  The front end oscillator of this IC is similar to the industry standard 555 timer.  D4 and C7 are a high side floating supply offset voltage.  (to turn on Q1)  The IR2153D drives two, n-channel MOSFETs.  These two FETs do the high current switching to the transformer.  There are four variable resistors on the schematic.  R4 and R5 control the roughly 20KHz frequency and pulse width of the transformer.  R8 and R10 control the audio range (100Hz to 600Hz) frequency and modulation.  Many more details are in the schematic.  Look up datasheets for further information.

Figure 5:  High Voltage Keyboard Schematic

keyboard frame:
The frame of the keyboard was built out of plywood and 2x4's.  I knew I wanted to have 25 keys on the keyboard, so I figured out how much area each circuit board and transformer assembly would take up.  With that info, I sketched a general outline of grand piano on the plywood and then cut it out with a jigsaw.

Figure 6:  The unpainted keyboard surface

Several small lengths of 2x4 were used under the plywood to make the plywood more rigid.  2x4's were also used as feet.  The edges of the plywood top seemed a little sharp, so I used a rounded over bit on the hand router.  Unfortunately, it seems like about half the time I use a router, I end up damaging or destroying the piece I'm working on.  The rounded over bit has a bearing on the bottom to set the depth.  This bearing lost contact with the plywood in two areas:
    1)  The plywood had delaminated on the bottom.  Damage shown:

Figure 7:  Hand Router mess up

    2)  The plywood had a knot in the wood on the bottom.  Damage shown:

Figure 8:  Grr, darn router

For item 1, the delaminating was glued back to the rest of the plywood and then the area was sanded down.  Item 2 was a little more difficult to repair.  A small block of wood was made with a rounded over edge.  The outline of the block was then traced onto the main sheet of plywood and cutout with the jigsaw.  The small block was then glued in place on the main sheet of plywood.

Figure 9:  The patch installed on plywood

After the small block of was installed, all of the holes for the circuit board holes, transformer holes, were drilled in the plywood.  The keyboard tray was installed and then the whole thing was primered and painted white.

System wiring:
To keep assembly simple, most of the wires were kept on the top side of the keyboard.  Running the wires on the bottom would have been much cleaner looking, but they would have been a headache to install.  The pair of wires for each key was twisted together using a drill.  This twisting helps to reduce any inference from other arc discharges on the assembly.

Figure 10:  The current meter, power switch and IEC connector

The push button switches for the keys use an elastomeric type of pad.  The original buttons had a really annoying loud click when they were pressed.

Figure 11:  Elastomeric pushbuttons under the keys

Follow up thoughts:
The keyboard turned out well.  Although it took way too much time to assemble.  It's nice to actually finish a project.

Kinect Pin Art (FAIL)

Back in the winter of 2011 to the spring of 2012, I worked on a project that did not go well. The idea was to take Kinect (a motion sensing camera from Microsoft) depth information and use the information to move a matrix of pins. The goal was to simulate a low resolution "pin art" toy in near real time.  The pixels did move based on depth information from the Kinect, but all of the 60 pixels were not finished.  It would have been nice to have a video of the operational pixels, but I did not get one at the time.

Figure 1: A pin art toy from E-bay

I recently saw this video from a group of 5 people from MIT:

The idea is similar to my Kinect Pin Art project. Although, they did a much, much better job of implementation.

Here is the hardware video I put together:

Since Hack-a-day has been asking for "failed" projects, this is my contribution.

There were two main difficulties:

1) Get the depth information from a Kinect sensor.

2) Build a 6x10 matrix of linear motion pixels.

Hardware:

The main difficulty was getting an array of pixels to move in a linear fashion over 1 to 2 inches. The least expensive way I could come up with linear motion in near real time was using a series of mini servos attached to the pixels through bicycle cables. The figure below shows only the bottom hobby servo tray installed on the plywood base.

Figure 2: The bottom servo tray installed early in the development

The "pixels" were the top half of Bic ballpoint pins.

Software:

Visual Basic Express 2010 was used to gather depth information from the Kinect sensor. In the figure below, the depth information is shown on the image near the middle. The user clicks and drags a rectangle over the middle image. The little green squares represent where the depth information would be gathered to be sent out to the servo controller.

Figure 3:  The desktop software in operation

The off the shelf servo controller could drive 32 servos.  There were two of them to drive the 60 servos needed for the display.

Why did the project fail?

Mostly, the hardware was my downfall. The bicycle cable and pixels tended to bind up at random times. PVC boards were used to hold the pixels. The drill holes through the PVC boards needed to be about 2.5 inches long. Drill bits tend to wander around some when going through PVC. Several different things were tried to prevent the pixels from binding up: aluminum tubing, and a bicycle cable alignment board. (see the images below)

The hardware as it stands today (there were only two servo trays attempted):

 Figure 4:  Two of the pixels sticking out of the pixel holders

Figure 5:  Aluminum alignment tubes for the bicycle cable

Figure 6:  All of the hardware

Looking back on the project, there are several things I could have done differently:

-As the Mythbusters say “When in doubt, lubricate!” (or some thing like that). Anyway, the bicycle cables could have used some generous lube.

-Instead of drilling such long holes, a couple of pre-drilled boards (like pegboard) would have helped out greatly for holding the pixels.

-Several parts of the hardware assembly screams out for either 3D printed parts or machined parts.

Anyway, if there are any other ideas on improvements to the hardware, I would like to hear them in the comments.

Internet Enabled Sump Pump Monitor

This project attempts to solve a problem.  Here is a picture of the project with the cover off: 

Figure 1:  System view of the Internet Enabled Sump Pump Monitor

 About three years ago, I moved into a new house with an unfinished basement.  The basement has flooded many times due to a sticky tar substance that comes in from the waterproofing of the foundation.  The tar was smeared on the outside of the foundation during construction.

Figure 2:  Parts of the sump pump monitor

Anyway, the tar comes into the sump well and either plugs up the sump pump or causes the float switch for the sump pump to lock on or off.  The tar/oil has also locked open several check valves on the output.  

This is a quick video I made of the system installed on the sump pump:

 

I have tried several things to keep the tar away from the sump pump.  One item I tried was putting window screen around the edge of the sump well.  Some of the tar did stick on the screen, but when there was a heavy rain, the window screen pushed in and stopped the float on the sump pump from activating.

Figure 3:  The tar can be seen on top of the water and on the window screen

I have two possible nicknames for my sump pump (sump well):

            1)  Exxon Valdez

            2)  Deepwater Horizon

Paper towels are occasionally used to clean up some of the sheen on the top.  The oil sticks to absolutely everything.  WD-40 works well for removing the oil if it gets on my skin. 

This project monitors the sump pump without effecting its operation.  There are two things monitored:

            1)  Is the water level too high in the sump well?  If so, send an alert email and activate an audio alarm.

            2)  Has the sump pump been on too long? If so, send an alert email and activate an audio alarm.

I didn't want the project to control the sump pump in case the MCU locks up or doesn't not behave correctly.  "Do no harm" is the motto I'm going by. 

Since this was a project I wanted to get done somewhat quickly, I decided to use an off the shelf board.  I choose the Seeeduino Ethernet board, which is an arduino with an Ethernet port.  This is my first arduino board and the first time I'm using the arduino development system.  It's ok, but I much prefer AVR-GCC and AVR studio.  Although, the Ethernet library in the arduino was nice.

Figure  4:  Internet page for the sump pump monitor

Shown above is the web page.  There was one activation of the sump pump 1 minute ago and one activation about 49 minutes ago.  Minute data that is older than 8 hours drops off the table.

An IO gear Ethernet to wireless 802.11 adapter was used to complete the internet connection.  An LCD from 4D systems was used to display user information.  An ip address in browser can also be used to look up some of the status information.

Figure 5: Water level float

If the water level gets too high, the float above will hopefully activate before the oil stops it from moving.  The float came from ebay.  It seems to have a magnet on the float and a hall effect sensor in the main body.  It is shown above in the activated  position.

There are some commercial sump pump monitors available.  But, they tend to be pricey. 

            http://sumppumpmonitor.com/

            http://floodnot.com/

Plus, I'm not really sure how the tar would effect the operation of either of these units.

 Figure 6:  The current sensor for the sump pump

The above image shows the neon transformer in it's housing.  The transformer was assembled around the "hot" wire of the electrical cord running to the sump pump.  This induces a small current (voltage) in the neon transformer that then goes out the black and white wires to the main arduino board.

Figure 7:  The LCD main screen

The LCD is read the following way:

            Line 1:  Title

            Line 2:  This is the IP address of the board on my locale network

            Line 3:  The Arduino is using 103 bytes of ram

            Line 4:  The water float is not activated

            Line 5:  The sump pump is not on

            Line 6 and 7:  The sump has been turned on 51 times

            Line 8:  Counting down to turn off the LCD

            Line 9:  The number of seconds the sump pump has been on

            Line 10:  If the user presses the "EEPROM reset" button for 15 seconds,  51 -> 0

There were a couple of problems I had during the software development phase.  First, I could not get the Ethernet to work when I was running the ATMEGA328 at 16MHz.  The Ethernet would work when I had the divide by 8 fuse on.  The source of the problem was the AVR ISP MKII programming header.  It was loading down the SPI line going to the Ethernet chip on the Seeeduino Ethernet board.  Second, there seems to be no way to turn off the 4D systems LCD through software.  So, I ended up using a P-channel MOSFET to cut power to the LCD.  This acts to prevent burn in on the LCD. 

The schematic is shown below. 

Figure 8:  Schematic of the sump pump monitor

Here is the Arduino source code.

Defense Against The Dog Arts!

DEFENSE AGAINST THE DOG ARTS!

Here is the video:

This project uses six ultrasonic emitters on bicycle to be repulsive to a dog.

Dogs tend to be a problem for most cyclists.  Residential areas are by far the worst.  There seems to be some wiring in a dogs head that makes them insanely aggressive when they see a person on a bicycle. 

There are several things you can do to help protect yourself from dogs.  Some suggest yelling  things like "Bad dog!", "go home!" or obscenities.  I have tried this and found it to be completely useless.  I had a friend that would carry ammonia in a squirt bottle.  He would squirt the ammonia on the ground and when the dog smelled it, the dog would completely forget about chasing you and go investigate the strong smell of the ammonia.  I never tried this.  Others claim that a capsaicin based spray is the only way to go.  But, windy days can effect your aim.  I even found that a small revolver was invented in France specifically for shooting a dog from a bicycle.   It was a revolver without an external  hammer so the hammer would not get stuck on clothing.  (click here)  That seems a bit extreme.  The final way is to use high pressure sound waves to get the dog to move away from you.  There are two ways to accomplish this.  The first is a CO2 based horn.  If a CO2 canister from an air rifle were used to generate high frequency noise, the output could be tremendously loud.  (there are off the shelf dog whistles, but they do not have any sound intensity ratings.)  Since I like the electronics more than the mechanical side of things, I decided to build a custom circuit board and enclosure to power 6 ultrasonic emitters.

What ever you do, you want to first avoid getting hit by a car, wrecking, or getting bit by the dog.

From what I have read on the internet, smaller dogs can hear higher frequencies than a larger dog.  But, since smaller dogs have little chance of catching a cyclist, there is not much a threat there.  So, I used four emitters at 25KHz and two at 40KHz.  (I had the 40KHz emitters from a previous project)  

For the main MCU, I used an Atmel ATmega644.  I needed an MCU with three timers for the different frequency outputs.  Besides, I already had the MCU.   (the board in the picture above uses and ATMEGA32)  When a dog is heard getting close, the rider flips a toggle switch under the seat on.  The emitters then start doing their thing and hopefully drive the dog away.  I put a human audible piezo emitter next to the toggle switch to let me know it is working.  (this is much better than an LED, I would have to look at the LED, which would take my eyes off of the road and the dog)

The code is written in AVR studio and uses the GCC compiler.  Most of the time, the software is at the ultrasonic transducers resonant points.  (25KHz and 40KHz)  But, the software does move around the output frequency some to get a "siren" effect. 

Did it work?

I have not had a dog chase me since the box was installed on my bicycle.  But, I did try it out on my cat, Willie.  I disabled the human audible peizo emitter near the toggle switch before the test.  (I didn't want that to skew the test.)  The video is at the top of the post.

In all honesty, Willie is 18 years old and doesn't hear well.

Anyway...   Here is the schematic (PDF warning)

Here is the source code, zipped up.

A Microcontroller based Interrupter Gear

Figure 1: The hardware

During World War I and slightly before World War II, military fighter aircraft had machine guns mounted to fuselage of the plane. These machine guns were mounted right behind the propeller. The first question that comes to mind is how can the gun fire and not hit the propeller blades as they are spinning? Some planes had special steel plates mounted to the propeller to keep the bullets from shredding the propeller.

Figure 2: A machine gun shooting through a propeller.

(I had fun with this one. Sometime, I should use a color other than black and maybe draw some wings)

There are a couple of reasons hitting steel plates in the propeller is bad. First, it introduces a physical shock to the propeller. Not good if you would like to remain in the air. Second, it adds weight to propeller; there by slightly reducing the max RPM of the propeller, making the plane go slower. Third, it wastes bullets. You would like all of the bullets to go out into the wild blue yonder.

Most planes of the day used something called an “Interrupter Gear” to time the firing of the bullets between the blades of the propeller. To see much more information on the Interrupter Gear, check out this link:

http://en.wikipedia.org/wiki/Interrupter_gear

There is a nice drawing on the page showing how the cam wheel and cam follower worked inside of the planes. So, this was done mechanically in the 1910’s to 1930’s.

My first thought was this could be updated by using a microcontroller coupled with an infrared sensor to sense the position of the propeller? Doing the project in small scale significantly lessens the chance of bodily harm, which is just awesome. The gun I used is an Airsoft pistol. For those of you unfamiliar with Airsoft pellets and guns, they are a family of plastic guns that shoot a plastic pellet. You can think of it as a miniature version of paintballs, except the pellets do not explode when they hit you.

The hardware

The pistol I originally chose for the project was battery powered and semi automatic. (A semi automatic pistol fires a pellet each time the trigger is pulled until the clip is empty) The problem I ran into was when a solenoid pulls on the trigger; a DC motor inside of the gun starts to compress a spring inside of the gun. Once the spring is fully compressed, the “hammer” is released and the gun is fired. It took about a second for the spring to compress. When you have a propeller that is spinning at 500 RPM, that is 8.3 revolutions per second. (500 RPM / 60 seconds = 8.3) There are two blades on the propeller I am using. The one-second delay between activating the trigger and the pellet firing was a showstopper.

The second pistol I used was a spring loaded Omega M650. This gun can send a pellet out of the barrel at 100 feet per second. The top has to be pulled back by hand to cock the gun.

Figure 3: This is the Airsoft gun used in project

The really nice thing is it takes only 20mS to 22mS from the solenoid on the trigger being activated to the pellet leaving the end of the gun. The pellet was detected by using a Sparkfun infrared sensor. This is how I determined the delay: Probe A on the oscilloscope was attached to the signal going to the solenoid. Probe B on the oscilloscope was attached to the IR sensor output at the end of the barrel. The oscope was setup to trigger once on Probe A. When the trigger was pulled by the solenoid, I could see a blip on the oscilloscope screen:

Figure 4: This blip is the pellet leaving the end of the gun.

If the propeller is spinning at 500 RPM, we know it takes 120mS for one rotation to occur. (60 seconds / 500 RPM = 120mS or 0.12 seconds) Since there are two blades, we’ll be seeing a blade every 60mS. Since the delay between activating the solenoid and the pellet leaving the gun is at maximum 22 milliseconds, we have no problem placing the pellet between the propeller blades.

Is the microcontroller even needed?

My thought process when I started the project had the microcontroller setting the delay between when the propeller is sensed and when the gun should be fired. If we use logic gates to immediately fire the gun when the button is pressed, this will work great unless the time between sensing the blades is 20mS to 22mS. Also, if the propeller blades are at multiples of 20mS to 22mS the pellet will hit the blade. So, it looks like a microcontroller is needed to dynamically set the delay for the solenoid.

A way to test the delay between the propeller and when the gun should fire is to setup a red LED to turn on when the pellet should be coming out of the gun. An excellent way to do this is to setup the LED so it is 90 degrees away from the propeller sensor and gun. The LED can turn on and you can see the reflected light on the propeller.

Figure 5: Infrared Sensors and the Solenoid

Once the software was completely working, I ran 20 pellets through the gun to see if any pellets would hit the propeller blade. None hit the blade. A better test would be to modify the software slightly to see if I could get the pellet to hit the spinning propeller every time. So, I added into the software a define statement “defHitTheBlade”. If you want the pellet to the hit the blade, remove the comment “//” at the beginning of the line. The pellet would hit the propeller about 4 out of 5 times. It was hard to find the pellets after they hit the propeller.

Each blade on the propeller is 0.5 inches wide in front of the Airsoft gun. The gun is 1.15 inches from the axis of the propeller. So, if we use Circumference = 2 * Pi * radius = 7.2 inches. So, we can figure if a blade is in front of the gun for 1 inch / 7.2 inches = 14 percent of the time.

The software isn’t too complicated. When the user presses a button, the analog comparator interrupt counts the time (using Timer 1) between the propeller blades passing the infrared sensor mounted under the gun. Once we know how fast the propeller is going, the software then looks for analog comparator interrupt and counts 1.5 times the time between the blades, minus the time it takes the pellet to come out of the gun.

The circuit was created on the solderless breadboard. Three power supplies were used. A 5V wallpack for the microcontroller, a 24V power supply for the solenoid, and a variable power supply for the DC motor (1 to 3V).

Figure 6: The schematic for the Interrupter Gear project

Overall, circuit worked well. Trying to hit the propeller with the Airsoft pellets was fun, it really let me know the system was working. Onto the next project… (the next one should be a little more practical)

Here is the source code for the microcontroller:

AVRGCC C source code

The Relocation of Robin

For those of you not familiar with American robins, the male bird is territorial. When he sees his reflection, he thinks it’s another robin and he tries to fight. The result is hours of “trying to run off” the other bird. Of coarse his reflection doesn’t leave.

Figure 1: An American Robin

A robin has been pooping all over a hand railing in front of my house. The robin has also been thumping on the window trying to fight his reflection. (Nickname: Evil Robin) My first attempt to remedy the pooping was to tape trash bags over the windows so he wouldn’t see his reflection. After a week, I took down the trash bags figuring he had moved on. He had not. So, I taped the trash bags to the window for another week. He found the back porch window to attack. Also, he had started eating mulberries, which made is poop stain the railing with spots of purple. A rubber snake was placed on the railing in the hopes of scaring away the robin. He pooped on the rubber snake.

Figure 2: The Robin Poop on the Railing

My next ideas were to either buy an owl decoy or build one out of cardboard. These ideas were scratch in favor of trapping the robin and relocate him to a distant location.

Being a new homeowner, the demands of the house seem to take several hours a day. Coming from apartment life, this has been a difficult change. So, the idea was to complete the trap quickly and easily. Building the trap, assembling the circuit on a solderless breadboard, and writing the ATTiny13 code took about 3 evenings.

Figure 3: The actual robin doing the pooping (image taken though a window screen)

Two words are needed to see how the trap was put together: cardboard and packaging tape. The cardboard box was originally used to hold several dozen-egg cartons. A mirror is placed in the back of the box to allow the robin to see his reflection. The lid flaps on the cardboard box were removed and replaced with a single piece of cardboard to act as the “flap”. The flap needed a little more strength near the edge. So, strengthening ribs were created out of cardboard and taped onto the edge of the flap. The flap is held open by a solenoid attached to a wood dowel. The wood dowel is taped permanently to the egg box.

Figure 4: Various parts of the trap

Figure 5: Solderless breadboard on the side of the cardboard box

The ATtiny13 microcontroller acts as a comparator for the analog voltage output of the Sharp sensor inside of the trap.

Figure 6: The sharp distance sensor in the trap

When the microcontroller determines the voltage from the sensor is above the set value, the output to the solenoid is changed from a high to a low. This turns off the solenoid (by turning off the n-channel FET) that is holding open the gate of the trap. Gravity then takes over and the lid closes. Two magnets from a “shaking powered flashlight” are used to help keep the door shut. Two pairs of pliers are taped in the bottom of the trap to allow the magnets to keep the corners of the door closed.

Figure 7: Robin trap schematic (a PDF is at the bottom of the post)

The sensor outputs an analog voltage based on the distance to a reflective object. The operational distance of the sensor is from 10cm to 80cm. The object we are looking for in this case is the robin.

The solenoid typically is powered when the circuit is turned on. The flap is opened on the trap and it is align so the solenoid keeps the trap open. When an object is detected by the distance sensor, the flap is released from the solenoid and the robin is trapped.

Figure 8: The solenoid on the wood dowel

Did it work?

The trap was set on the front porch, near where the robin likes to sit on the railing for about a week. (When it wasn’t raining) Apparently, the trap was visibly so frightening to the robin, he never came back. So, did the trap work? Yes, it took care of the robin problem; No, it didn’t catch him. Maybe I should have gone with the 4 feet tall cardboard owl।

Schematic

Source code for the Attiny13

Hex file for the Attiny13