Archive for the ‘Uncategorized’ Category

Star Trek control panel

February 5, 2017

This is one of those things that starts out as ridiculous but just might work.  We’re putting in a door at our hackerspace, a pocket door, so obviously it has to be pneumatic.  I was asked how to control this door, and I had one answer: Star Trek Electronic Door Chime Think Geek wants $30, Ebay wants $28, the cheapest is Amazon at $25 and free shipping.  I ordered one right away with the intention of converting it for use as our door controller.

looks unmolested, doesn’t it?

I knew I would have to do three things:

  1. make the sounds triggerable on command
  2. take the inputs from the button and switch separate from their original use
  3. control that LED
  4. (optional) do something cool with that translucent bit at the top, maybe an RGB LED?

Let’s investigate the guts.

brb learning kicad

Unfortunately I did not take a picture before tearing into it, so here’s my recreation.  Top left, board with a single LED.  Below that is a board with a single membrane switch and that passes through the LED wires.  To the far left are two PIR sensors.  Out the bottom is the connection to the battery box. The right side has the speaker and volume switch.  The top right has the front slider switch.  The middle of the board has the switch to select which PIR sensor will activate the sound.

I didn’t really go into this with a plan, but step by step I made this sound board sing and dance.  The first thing was to pin out the PIR sensors:

didn’t use their own copper traces….

PIR sensors:
d1=orange=normally open (3.61v)
g1=green=normally closed (0v)
d2=purple=normally open (3.61v)
g2=grey=normally closed (0v)

That’s that.  I found that I could replace one with a microswitch and activate the circuit, perfect! I had to tweak the timings once I got it hooked into the microcontroller but I could control them digitally, good enough!

not PIR, this is the new microswitch

Next was the front switch board:

switch board
bottom=red alert

That’s fortunate, there’s one common and three different things to be pulled down in succession.  I decided to use the trick of defining a pin as an input to make it floating, which worked great.  For inputs I used three separate pins with pullups to detect which was being pulled low.

Last was the LED and button boards:

LED board
1=led positive (4.4v, floating battery)
2=led ground (current limiting resistor inline, switched)
resistor removed and shorted over

button board
1 – 6
2 – 3
4 – 5 button
5=4.38v (floating input)

The decode here is that the LED gets tied high, there is a SMT resistor on the main board, and the ground is switched.  The button is on pin 5 and pin 4 is ground, so all I have to do is pull that low to activate it with a microcontroller.  I really don’t like how that LED is wired so I removed the resistor on the board, jumpered over it, and wired the switched pin (3 on the board) to an input on the microcontroller (pulled up).  I then wired the LED to ground and one of my GPIO through a 100 ohm resistor I added.  The button also got wired to me as an input.

Here’s the story so far:


  1. LED
  2. simulate front switch
  3. simulate front button
  4. simulate PIR sensor


  1. sound board output for LED
  2. front switch
  3. front button
  4. extra button from me (to trigger as if it was a PIR sensor)

power circuit

In this configuration I could essentially man-in-the-middle the entire board, but I had one limitation.  The red alert is supposed to be a burglar alarm for a cubicle (just like the hail is supposed to be a doorbell) and thus cannot be stopped mid cycle.  I decided the best way to fix this was to wire a couple of transistors so that I could drop power to the whole board and thus kill any sound mid-play.  This is a very crude solution, but seeing as my music box is literally 2 epoxy blob chips, I’m going to just call this good enough as well.

The jumper near the label R19 is mine (for that resistor I removed) and the pin the PIR chip out put is actually pin 2, right under that white dot

Now I have even more control over the board than I did to start with, I have written code that would simulate an unmodified board (no PIR though) and augment it with the ability to interrupt the sound being played.  If you really really wanted to you could take the PIR sensor in as analog and output it as PWM and maybe it would work.  I didn’t bother because this device has 2 PIR sensors and a switch on the back to choose between left, right, or both to activate the sound.  If you want a PIR sensor, just leave one in and connect the arduino in place of the other.  You can even switch between them to preserve as much original functionality as possible.

as wired in final assemble

Somewhere along the line I thought I broke my code for simulating the PIR sensor (spoiler: don’t #define the same variable twice and expect it to work).  My remedy for this was to look into the TM2291 chip connected to the horrorshow of capacitors and resistors.  This chip turned out to be a dedicated PIR sensor reader chip.  Most of you won’t have ever dealt with this because you but modules that have something that does this onboard, but this device had 2 PIR sensors MUXed into one driver chip… I did not want to decode that.  I found an example circuit and picked the pin I thought must be the output to the sound chip.  After I desoldered the chip and connected in place of it everything worked (no it didn’t. but it was around this time I found my code bug).  Now I could also be rid of that switch on the back of the PCB.

polarity marked, it’s important

With the switch desoldered I had room to just about fit my FTDI header out the back.  One important thing: the RAW and the Vin on the FTDI header are not as connected as you might think, which led to some head scratching from me.  Here is the final layout as I have it now.

kicad’s going slowly

The diode is so the batteries don’t get charged from the ftdi header (but it can still power the unit).  The switch at the top is mine for triggering things instead of the PIR (glued where the PIR was).  You can see the NPN/PNP circuit I mentioned before to kill power to the board (and the power for that coming from the FTDI input, not any other pin on the pro mini).  The LED has a new resistor, and the button boards now go to the pro mini.  The arduino has a bunch of control lines running to the original board, but the volume switch was left alone.  This literally shorts out a series resistor with the speaker, I didn’t think it was important to make that variable.  You can see how I now have central control of all the inputs and outputs, which was the plan all along.

removed parts (and all the shitty wire)

The code I think this will be running in production is the command based one I uploaded here.  It’s overly modularized, but it works well.  Another hint: 8Mhz does not divide equally to give close enough to 115200 baud for input, even though the output comes through readable.  That’s a fuckin’ pain to diagnose.  I used 9600 this one time, as you can see.  My functions:

WOOSH does exactly that, plays that sound.
ALERT does the same as WOOSH, except it will be left in alert mode so the LED will blink
HAIL plays the hail sound
NONE sets the virtual switch to no sound, but can be used to cancel the blinking without playing a sound
KILL kills the current playing audio
ON turns the LED on
OFF turns the LED off
PASS passes through the LED state from the board, useful in alert standby mode or to see the blinking while playing the red alert sound
BLINK sets the board to red alert mode, does not trigger sound, LED blinks slowly
SWITCH returns the state of the front switch (0, 1, or 2)

The button on the front and the new button on the side asynchronously send 3 or 4 out serial, but they are debounced and only do it once per press.

That square board is mounted 180* off, and I cut the post/glued in the speaker to accommodate it.  Completely un-needed.

That’s it, I’m done, it works.  I anticipate this (maybe two) being serially linked to an ESP8266 (it wants 4.5 to 5v power, but 3.3v serial is fine) which will run the solenoids, read pressures, and talk MQTT.  If I’m really hurting for pins I can make the second one respond to different commands, make it talk different numbers, and hook them in parallel with a couple diodes, but that’s silly…

the code is here.

the rest of the pictures are here.

mini-sucker (gravity sucker)

February 5, 2017

This past weekend (this post has been in the queue for a while…) there was the Ferndale Pig and Whiskey Festival.  I spend a lot of time at i3Detroit and was convinced to help out at this event. We have a large device aptly named the moneysucker as it consists mostly of a water cooler bottle, a shop-vac and a long tube.  That particular one is triggered by a non-contact mains switch and has a spiral of lights running up the tube.  Over the years that has been made sturdier and nicer, but now it’s hard to move and impossible to shrink without essentially breaking it and rebuilding it after.  The one I built is a sucker in name only; it is a water cooler jug, an arduino, a neopixel strip, and an IR presence sensor.

The first version I built used an arduino pro mini, but that died just as we were supposed to leave for the event.  My best guess is the little SOT23-5 linear regulator on the chinese knock-off board was not up to the task of stepping 12 volts down to 5 (even though I was not powering anything but the ir sensor and arduino with it).  The fix was to replace it with a full-size real-deal arduino, no expense was spared (although it wasn’t my expense).  The IR sensor had the LEDs pointed straight out, and I decided that I’d rather have them mounted at a right angle to make the board mounting easier.  That was a bit of a mistake.  Those LEDs are very sensitive.  All the sensor is is a comparator and a potentiometer to set the bias, so the level it triggers at can be set (theoretically a distance).  When I unmounted the LEDs the alignment became somewhat of an issue.  If I were to do it again I would convert the sensor to a beam break sensor, and heatshrink around the 5mm LED body to keep directionality.  This would invert my signal, but the pin change interrupt does not care.  The pin change interrupt is indifferent to your small mortal worries.

The code was a modified version of the adafruit strandtest.ino example expanded to the length of strip I was using.  I chose a default state I liked (the rainbow and rainbowCycle subroutines) and one I liked for the instance of having money inserted (theaterChase, white) and pulled out the rest of the calls.  The interrupt is triggered on a pin state change  so no mater what I use for a sensor (reflective, beam break, etc…) it will trigger a blinking state.  The theaterChase subroutine was also tweaked to be more intense and shorter.  The delay passed in the subroutine call was shortened from 50 to 20,  and the number of cycles was shortened to 3 instead of 10.

the code is here.

the rest of the pictures are here.

serialderp – completely non-autonomous arduino robot

August 11, 2016

This is an extension of the pervious robot, derpderp.  A friend wanted something to use for makerfaire Detroit to show off a bluetooth attached armband.  That sensor interfaces with python on a raspberry pi 3, and since I have some experience making python controlled robot platforms I volunteered to help.

The code I wrote just conflates the original derpderp code (which I use to drive the robot) with the wheelchair robot code that I use as a framework.  The additional things are setting the servo angle (what used to be the lidar platform), turning the light on and off (added to the lidar platform), and getting the temperature and humidity from an onboard sensor.  When making this change I found that the battery wasn’t working so I dug up the charger.  Then I found it wasn’t charging… so I tore apart the charger and bypassed the fuse.  It still wasn’t charging so I tore apart the battery and bypassed the fuse.  Then it finally worked, but that battery was so anemic anyway I decided to upgrade it.

The original battery was a 9.6v 500mAh battery, I replaced it with a lithium jump pack.  I had bought this jump pack for my car with an unreliable battery (which I eventually replaced) and somehow ended up running it over in my driveway.  I don’t even remember taking it out of my car and the next day it’s in pieces on the driveway.  After looking it over it still looks intact.  The plastic is shattered and the box that goes between the battery and the jumper cable clips has been crushed and the open frame relays inside will never function again.  That box, as far as I can tell, has a microcontroller in it that just supervises the closing of a bunch of little parallel relays to connect the care battery in parallel with the lithium pack (no protection whatsoever).  To me that means that I now have a connector and cable that will give me an unregulated voltage that I am glad to use for my motor power.  The charger board for the jump pack has a variable dc-dc on it to make different voltages, a usb port, and a flashlight.  I took the flashlight off and drove it at about 20mA with a resistor and a FET off the regulated 5V I’m making on the robot.  That’s the headlamp on the robot and it’s steerable with the servo as well as PWMable.  The control board is now only useful as a charger for the bare lithium pack as the battery voltage is not passed through it before hitting my robot.

The commands are:

sCmd.addCommand(“HUM”, humCMD); //no args

sCmd.addCommand(“LIGHT”, lightCMD); //0 – 255

sCmd.addCommand(“TEMP”, tempCMD); // if ‘1’ then F, if ‘0’ then C

sCmd.addCommand(“TURN”, turnCMD); // sets turn -1000 to 1000

sCmd.addCommand(“SPEED”, speedCMD); // sets speed -1000 to 1000

sCmd.addCommand(“ANGLE”, angleCMD); // sets angle of servo, 20 to 160

That’s a fairly easily controlled robot.  I don’t know exactly how the project went because I was on vacation for the week leading up to makerfaire, but there were some problems sending the commands from a raspberry pi (and I still don’t know why, it was over USB).

code is here.

pics are here.

autonomous version is here.

derpderp – Autonomous arduino-based robot

July 15, 2016

Here is yet another autonomous little robot that rolls around avoiding walls, this one was also made for a hackathon much like the venerable wheelchair robot.  The difference here is that insistence that code be developed on an SBC slowed development to the point that many features had to be dropped.  The point of this robot is to venture into unknown territory and send back sensor readings (distance, temperature, humidity, light level, barometric pressure) so you don’t have to go in blind.  The need for autonomy come from us not having a camera with which we could drive the robot.  The goals as best as I can remember:

  • autonomous exploring (drive forward, avoid walls)
  • wireless telemetry
  • large array of sensors
  • manual over-ride
  • make duck noises

The only things that got implemented out of these were the first two.  I put a lot of effort into making the only touchscreen we had (a SainSmart 2.8 inch TFT LCD) work as a UI for telemetry and control but was no able to make it work.  I still cannot even after buying the adapter for the arduino mega.  Usually I’m able to get around shitty documentation by digging through the code of the libraries, but this one beat me.

The large number of sensors… We had a BH1750 Digital Light Sensor, never got it to work.  We had a BMP180 Barometric Pressure/Temperature/Altitude Sensor, didn’t have time to make it work.  An HC-SR04 ultrasonic sensor, also never made it do anything.  A DHT22, the simplest sensor we could have installed… nope.  So, we had absolutely no sensor readings but it had a bunch of stuff plugged in so it looked impressive.

The actual navigation was done using a LIDAR Lite, which is a really cool i2c lidar sensor.  This was borrowed from a FIRST team and unfortunately no longer resides with the robot.  I thought about getting another one, but it’s just too expensive to put on a robot that I actually have no use for.  The chassis was the absolute biggest, most expensive RC car that walmart had to offer.. a New Bright 1:10 Radio Control Ford Raptor Truck, Black/Green.  No, I wasn’t much impressed either.  For a chassis this had loose ball joints, an anemic little lithium battery pack, and a motor that was rather poorly geared for torque.  But if the chassis was perfect then we’d have no fun accounting for it later.  The motor control comes from a Sparkfun Ludus Protoshield (which I got in a ding/dent deal and is not labeled like that on mine).  The control is just two-bit direction and a pwm line for speed.

Sparkfun ProtoCAT board

Being in the IEEE lab at MTU we had the advantage of a 3d printer.  They may have taken away the band saw and drill press because someone took off the safety switches and didn’t either restore them or hide them well enough, but we could still make small plastic parts over the course of several hours.  We made a bracket to hold the LIDAR to the servo and cut up a chunk of an old computer case to affix the servo to the chassis.  Now we had a chassis with enough sensor to let it move.  You may notice this is the exact same setup as the wheelchair robot with the exception that it’s smaller and much lower power.  When you have a hammer and all that…  It should not surprise you that the same person wrote the code for that as this one.

The wireless part was going to be a whole custom interface between two esp8266s to allow for touch-screen control and telemetry… Well, when it came right down to it I flashed the wonderful ESP-Bridge firmware to an esp8266 and clamped that onto the serial port of the arduino uno.  That worked for a very short while and then stopped.  I then replaced the esp8266, put a voltage divider on the rx pin, flashed it again and then it kept working… oops.  This theoretically gave manual control and some sensor data, but in fact it just gave updates from within the code.  That meant a constant stream of almost nonsense that looked pretty impressive to the lay-person.

The duck sounds were actually going to be quacks made by a speak-n-spell I found at goodwill, but hacking that never actually happened.  That may be an upcoming post, because using one of those for a speech synth has always been a plan of mine.

The battery was the same one that came with the RC car, a 500mah 9.6v lithium pack with charger.  Really anemic for this use but it worked for the little while we needed it to.  I upgraded that with a later revision.  The bus power is provided by a little 3A adjustable dc-dc regulator from ebay that got set to 5V and had the POT glued down.  This is much better than the linear regulator that would just dump 50% of the power from our tiny battery as heat.

The code is here

The pictures are here

the hackathon post is here

Wheelchair robot

June 29, 2016

Back in college (yeah, those were the days) I was in a hackathon with a couple other guys.  What we decided to do was to build a robot platform out of a wheelchair.  While researching for this article I found out that we are not the only ones to do that with this style wheelchair, but I think we implement the most functionality.

We chose to interface with the existing controller since it already does what we want.  Power was not an issue as you can see the battery voltage is brought right to the controller and helpfully labeled.  The inputs and outputs were:

  • in: power state (using an analog pin and LED)
  • in: power switch (manual control passed through our code)
  • in: speed up switch (manual control passed through our code)
  • in: speed down switch (manual control passed through our code)
  • out: power relay (controls the power switch on the pcb)
  • out: speed up (controls the speed up switch on the pcb)
  • out: speed down (controls the speed down switch on the pcb)
  • out: speed/speed2 (sets the position of the virtual analog stick)
  • out: turn/turn2 (sets the position of the virtual analog stick)

In addition to these we also used the usb-serial converter on the serial lines to communicate with the laptop.  Through incredible self restraint we didn’t implement the horn functionality.

Here is our modified controller.  You can see the joystick connection is modular so we could probe the lines in circuit before connecting our controller to them.  That proved absolutely essential because this controller is a little smarter than you might imagine.  The joystick has 2 separate potentiometers for each axis which we drive with identically controlled pins on the arduino pro mini.  The controller also throws an error when the virtual joystick goes too far out of the range of the mechanical joystick.  we have capped these pwm outputs using a helpful map function:

speedOut = map(speedVar, 0, 1023, 50, 210);
analogWrite(SPEED_OUT, speedOut);
analogWrite(SPEED_OUT2, speedOut);
turnOut = map(turnVar, 0, 1023, 50, 210);
analogWrite(TURN_OUT, turnOut);
analogWrite(TURN_OUT2, turnOut);

This allows us to work in 1024 increments of turn and speed while knowing we won’t trip the internal protections against an unplugged or shorted joystick.

The code written here is non-blocking and runs in a continuous loop.  It checks to see if any switch is pressed and does the corresponding command if needed.  It then checks to see if there are any serial commands that need executing (I’ve used this serialcommand library before).  Once it executes any needed commands it sets the virtual joystick based on the internal variables stored for the position.  It checks to see if it has been more than 3000 loops since the last command given, and if so it re-centers the joystick (a crashed python program sent it driving off since we no longer had a spring return joystick).  The commands it takes are :

  • TURN [0-1023]
  • SPEED [0-1023]
  • SPEEDLEVEL [-1,1]
  • POWER [0,1]

Turn and speed set the joystick position (512 is center), speed level pushes the relevant up or down speed button (which just scales the joystick, increasing or decreasing the max speed), and power turns on or off the wheelchair controller (not our controller).  Since these commands just push buttons it is not possible to know if you are at the max or minimum speed (we did not read any more LEDs, but you could).  We did, however, implement the power LED.  When you want to turn on the controller it checks to see if it is already on and then sets the joystick to center, presses and holds the button for 100ms, then releases the button.  This is also part of a safety interlock to keep the wheelchair form just taking off when turned on.

The power connector passes 12V for charging and is labeled as such. I didn’t do that part, I promise.

The power connector passes 12V for charging and is labeled as such.  I didn’t do that part, I promise.

The next bit of software I didn’t write.  We interfaced this robot with a laptop and a kinect for doing depth mapping.  You can see that code here and your interpretation is about as good as mine, but I will try.  I will say that this code is sending speed, turn, and power commands as one even though I am processing them individually.  The speed up and speed down are not used (we used the manual switches in the robot).  The logic in the python code looks at a center depth, a left and right side.  If the robot is clear to move forward it does, else it goes left, else it goes right, else it backs up.  The behavior is very simple and the movements around our oval-shaped hallway were interesting.  There’s enough lash and randomness in the mechanics of the wheelchair to make sure it never gets stuck even without more complex self-correcting code.

That’s it.  How to make a wheelchair based robotics platform and how to interface that low-level arduino control to a python script.

pictures are here.

code is here (forked in case he wants to bring it down)

2.4Ghz analog camera scanner

June 29, 2016

This story has a part ‘back in the day’ and a part just a couple months ago.  Let’s start with the most recent part.  I decided that I want cameras around my house.  I didn’t say in my house, I said around my house.  I would like to be able to see my front yard, back yard, driveway, and maybe even down the street a bit.  I want cameras inside, but this is absolutely not the way to do it.  I came by a number of analog cameras with 2.4ghz transmitters, but the receiver I had used analog tuning.  I never worked out whether it would pick up all 4 channels of camera (there are 4 in the standard I’m familiar with) or just fine tune on 1 but either way I decided that using analog tuning is harder than it needed to be.  I went on ebay and picked up a 4 channel receiver with a switch going between channels.  With that I got all 4 of my cameras on different channels and able to be picked up by the receiver.  In the process I found a camera outside that picked up my hackerspace (probably by the landlord based on where it was and was pointed).  Now, even if I didn’t already not want these cameras inside… I would like to think this would have done it.

Before I go on with this hack (which is, as always, half finished) let me bring you back to my inspiration for this one.  If you look up the origination of the term ‘wardriving‘ which is what I grew up doing (driving around picking up people’s wireless networks and using/breaking into them) you will find ‘wardialing‘ which is basically robo-calling for modems.  This was popularized (if not originated) by the movie WarGames because before Matthew Broderick was doing his best Gene Wilder impression, he was impressing girls with his computer skills.  This is a different kind of automated scanning attack, the one I’m thinking of is ‘warspying‘.  Eleven (!) years ago Systm launched and had an episode with a howto for building a handheld unit for detecting and displaying unencrypted wireless cameras.  I wanted to use that technique to drive this switch from a raspberry pi (or any other computer with gpio).  Where they used a small pile of discrete I/O to accomplish a dedicated scanner I used a simple demultiplexer, a 74155, to control 1 of 4 lines with 2 GPIO.  Since I only need one line grounded at a time I can use this technique to save pins.

You can see from this switch diagram (or the description in the Systm video) that the switch has 6 pins and 4 positions.  If you ground the two center pins then you ensure that one of the outer 4 pins is grounded in each switch position.  Rather clever for what would otherwise have been a more complicated mechanism. That being said, this doesn’t scale very well.

I really wanted to replace the whole board here, or at least make the unpopulated stuff work but that just never happened for me.  For anyone else with one of these modules, now you know what’s inside so you’re prepared before you go tearing it apart.

Now you can see how I made a camera receiver interface with a raspberry pi.  If you send 00 out two pins you get channel 0 of video, if you send 01 you get channel 1, same for 10 and 11.  Until this actually gets used with GPIO I have set up a 2×3 jumper block with power down one side, ground down the other, and the two data lines in the middle so they can be pulled high or low.  There is no ‘off’ since that wouldn’t matter, the video capture card is connected straight to this module and there is no need to switch it out for anything else.  If you needed to it could be done with a 4051 analog mux though.

pictures related to this project are here.

TTL POV globe redesign (part 1)

June 28, 2016

Back in college I built a POV globe.  I was really not happy with it, mostly because it’s something I felt could be done with discrete hardware more easily.  The first part to getting the POV globe in chips is to work out how to store the lines and retrieve them.

The big plan includes using a bigger chip with bank switching for animations and maybe even higher bank switching for going between animations.  This means that we need X address lines for 2^X lines, Y address lines for 2^Y frames, and Z addresses for 2^Z animations.  Eventually I would like to have a dynamic clock divider so we can have a variable speed motor and still scale the line frequency to keep the image all displayed in one revolution.  For now I have put together a clock out of a 555 timer, and decoders for the 28C64 EEPROM made from 74LS161 chips.  The EEPROM was programmed using the TL866 programmer to a sequential pattern as an example.  You can see that this chunk of the circuit iterates through the addresses and the outputs are tied to LEDs.

<video showing reset circuit>

<video showing addresses counting up>

<video showing changing the clock speed changing (blink pattern in the chip)>

Next time maybe I’ll have a dynamic clock divider circuit.

here is the code.

Door Iris

June 28, 2016

At i3Detroit we had a door (as seen it the scrolling, scaling web 2.0 bliss that is i3’s main page [just go to the wiki for important stuff]) that frequently got opened into groups of people standing by the front door.  The groups stand there because despite this door always having existed someone decided that a good bottleneck for people is right there, in the way.  Other hackerspaces have paperwork filled out elsewhere in their space, places where you can sit down even, but not us.  I chose not to solve the problem of people congregating because it didn’t seem interesting.  Instead the problem to be solved was that the door was a bit too opaque.  We could, of course, put a window in the door.  The issue was that the door worked fine most of the time as its old opaque self, and we really only needed a window then there were people on the other side of the door.  An on-demand window.  A mechanical iris for the door of course.


This idea and the plans to laser cut it were blatantly stolen form the internet.  I don’t remember where I got the file I ended up using to cut it out, but it is hosted on i3’s wiki here.  The thing that we added to that is a car window motor spline.  This particular spline comes from a motor used by a FIRST team some years ago.  To model it I just drew 2 concentric circles in inkscape, did some math to calculate the offset of the spline edges from the center, and traced it out.  I provide it here if you happen to have the same motors we had (I don’t remember what brand or model they were.

The PIR sensors are pretty standard, but I wanted to jazz them up a bit.  That, and it’s easier to debug if you can see what’s going on.  I was inspired by the ‘electric eye’ description in stories about old-school home automation and added a FET, resistor, and orange LED to light up the shell of the PIR sensor whenever the output is triggered.  Based on my knowledge of historical electronics I would guess that the ‘electric eye’ in those stories is a big freakin cadmium sulfide cell that they pass motor current through.  That being said, tuning one of those systems is no way to have a relaxing weekend if you have a deadline anytime soon.

So now we have sensors for people and an actuator for the door.  Now we need limit switches.  My preferred way of detecting the limits of this mechanism is to use limit switches.  You could use motor current, but that is likely to vary over the life of the motor, wire, solder joints, etc. You could implement a rolling boxcar filter to pick out where the current should be based on the assumption it will be changing slowly over time but that relies on good sturdy mechanical connections and not much slop.  It’s also much harder to program, and harder on the wooden gears needing to put stress on the whole system to know when to stop.  The key aspect of using limit switches instead of motor current is that it does not stop if you put your finger in it.  I am of the opinion that if you put your finger in it then you must not care about it enough and deserve what happens to you.  I have also intentionally put my finger in it and with the motor moving on 5 volt power it doesn’t hurt that much.  To address how to fix this (because if the motor does not reach the limit switch then it never stops) I made the code so the iris opens upon reboot.

<Link to video I can’t figure out how to embed>

With limit switches you can tell when you’re closed, you can tell when you’re all the way open, but you cannot detect an intermediate state.  This becomes more complicated when you talk about having two limit switches and two triggers on the same gear.  Because of how far the gear rotates to make a full movement of the mechanism it was not convenient to have one magnet and hall effect sensor.  I decided to add 2 sensors and two magnets.  This means that there is one position where the drive gear and ring gear can meet in order for the limit switches to work.  This gets tricky if anyone dis-assembles the mechanism and moves it by hand.

The only remaining question was how to power the motor.  It turns out that the motor that’s designed to run at 12V works great at 5V.  The problem with using a logic and motor power supply together is that when the motor browns out and resets the microcontroller you get a nice infinite loop of opening and closing.  A nice chunky power supply solves that problem.  We switched the motor with relays because the coil current draw isn’t an issue and dissipating the heat a FET would generate is also not how I like to spend a relaxing weekend.

<laser cutter porn>

The mechanical assembly was done with chrome 1/4-20 hardware, washers we lasercut out of a single thin sheet of polyester, coconut oiled wood (which we hastily cut on the wrong side, it’s not a symetrical design) and brass flat head wood screws.  The scale was wonderfully coincidental, we were given the porthole which had an ID of 7″.  When we scaled that to the whole project it turns out the 1/4-20 hardware worked great.  The porthole got a lasercut sheet of acrylic to replace the non-existent glass and a translucent ‘i3’ vinyl logo in the center.  The arms that move even got a real gold leaf treatment.  The mechanical build went smoothly and waited for a motor current based control board.  When that didn’t appear I put it into permanent install with my code and limit switches.

The code is supposed to do as follows:

10 open the iris

20 close the iris

30 if either of the sensor lines goes high

40     open the iris

50     stay open until 2 seconds after both sensor lines go low

60     close the iris

70 goto 30

It bounces around a bit and one of the sensor wires has fallen off inside the door (don’t use connectors when you can fit an iron in there, seriously) so it only opens from movement outside.  It’s not perfect, but it’s perfect enough that no one has been motivated to change it in the year and a half since we made it.

pictures and videos here.

code here.


Drill chuck replacement

June 28, 2016

For any of you plagued by modern power tools, I have a reminder for you.  Even if you have to get a drill to finish a project right now and your only option is a speed chuck there is still hope.  Just because you had to buy a new tool doesn’t mean you need to be stuck with crap forever, upgrade it! By using a hammer, a large allen key, and some stiff impacts (don’t burn up the motor trying to do this with the drill) you can remove that new crappy chuck and put on a nice old Jacobs chuck with a key.  Gone are the days of skinning your palms when you try to get a drill bit in and out.  Or the instances when you just can’t get enough torque to keep that hole saw from spinning.  With your newly installed chuck and key you have the needed mechanical advantage that makes a drill worth using.  Ever wonder why not even the cheap companies use a keyed chuck on their larger models? That’s right, you can’t get the needed torque.

Hacked LCD (given composite input)

June 22, 2016

There was a time that I would take any display that I could get my hands on and try to find a composite video signal inside it.  With that information I could modify it to take composite input from my source and I’d have a portable little lcd that I could use with my commodore 64, or raspberry pi, or… game console… this was before the C.H.I.P. or other single board computers with composite became popular.  That technique is still useful today because of the continued prevalence of composite video and the ubiquity of displays that can eat it somewhere inside.

The patient is this audiovox under-cabinet television and radio.  Let’s have a look inside.

My that’s a lot of empty space! if you look closely you can see where a dvd module would go, if this unit had one (!).  I have already hacked this one so there are some things missing.  First, you can see a lack of any RF cans full of tuning equipment, so this can’t pick up video or audio over the air anymore.  I’ll show you a picture of the back soon, but for now look at how sparse the board is (there’s more underneath but look at the unpopulated bits up here first).  There’s a section off to the right that looks to me like a modem.  I don’t know what that was for, really.  If anyone has an idea please let me know because I’m interested.  There’s also a set of unpopulated parts (including what looks like a mains section ) on the left side of the board.  That could be if there wasn’t an off-board power supply, I’m not really sure.  Looking at the parts that are present you can see a long DIP chip with some hefty capacitors, that’s the audio amp.  The connectors just above it in the picture go to the speakers.  The pole of odd stuff at the top of the board is the power supply for the VFD, there’s nothing else that would need those parts on this board.  Let’s rotate.

There’s my hack and you can see where the radio and TV tuner went.  You can also see I didn’t drill those holes, there was an option on this model to come with composite input.  I didn’t try to reverse engineer the extra feature, I just removed the other stuff and used those inputs.  Rotate again.

You can see there’s a bunch more stuff unpopulated, and the section I thought was an unused mains power supply says caution.  Enhance.

Wrong section but I can talk about it anyway.  I find this a little strange, I don’t usually see atmel ICs in the grade of consumer electronics I dissect.  I will point out I could reprogram this to add features and basically do whatever I want.  I would rather… no, this is public and if I use some colorful example someone will use it as evidence to convict me of something.  Let’s just say I won’t be doing that today.  Reposition.

Ok, here’s where I patch in the audio.  I tapped off two pins that I found near the amplifier and I removed the 4051 feeding it so that only our audio is heard.  Reposition again.

Here’s a tricky one, I actually fired up a video game, took a probe, and started injecting composite anywhere on the board I thought likely to work.  I could have probably guessed as well, but this worked really well, especially with no tuner trying to drive the screen black.

This is inside the LCD itself, there was a board to control brightness, contrast, and stuff.  You can see the ribbon that goes between the LCD and the body, I didn’t want to touch that.  So there you have it, that’s how I repurposed a thrift store screen into a portable LCD for use with my raspberry pi.  If I desired there’s plenty of room inside for the pi and a bunch more hardware, the power supply would work well too.  This currently tests composite cameras for my insecure 2.4ghz camera setup that I’m planning around (not inside) my house (post coming soon).

All photos here.