In August 2017 I went on the Ben Heck show to build an IoT device quickly. We built the hardware, firmware, and app, in just a few hours.
Part 1:
Part 2:
In August 2017 I went on the Ben Heck show to build an IoT device quickly. We built the hardware, firmware, and app, in just a few hours.
Part 1:
Part 2:
A science museum needs interactive exhibits, and this is an exhibit that can easily be extended, is easy to setup and install, is robust and safe and easy to maintain. Exhibits can easily cost tens of thousands of dollars, but this one can grow to any size budget but the top of the line is still under $4k. The idea is a periodic table of motion, where each cell, instead of an element, is a type of mechanical motion. Inside the cell is a description of the motion, a button to activate it, and an actual example of a working machine that uses the principle. Simple machines (lever, pulley, gear, etc.) are at the top of each column, and they increase in complexity. For an example of the variety of types of motions I want to capture and show off, see http://507movements.com. This project is very educational and interactive, and distills the basics of mechanics into individual and easy to understand concepts, building on them to show advanced motion mechanisms.
See the full project logs at https://hackaday.io/project/6682-periodic-table-of-motion
Originally intended for Burning Man, this device has usefulness more and more in our world as people embrace biking. Cars have had this feature for years; push the button on your keys and the car honks and the headlights flash. Why can’t we have that for bikes? This devices use a long range Bluetooth Low Energy module so you can find your bike from up to 100 yards away. Customizable flash patterns, remotes paired to your own anglerfish, waterproof, and you can ride in style with a blinky to alert traffic and passersby of your awesomeness.
My hackerspace Sector67 was approached this winter with a problem; the local minor league baseball stadium (Madison Mallards) fast pitch sign was old and no longer working, and they wanted some help fixing it up. In exchange for our expertise, they promised significant advertising and publicity, and they would have us be special guests at a ‘maker’ day during the season.
For the impatient, here’s the finished product:
We took them up on the offer and had a field trip to the stadium to see what was already there. There are two main parts to this project. First, there’s the sign itself. Second, there’s the press box, where the radar gun and the sign controller sit. The previous method was to have the person running the scoreboard watch the radar gun and type the speed onto a controller. There was no accounting for the angle of the radar gun, and it required a person to act as the middle man. They wanted to automate this part of the process. With the sign, they wanted it to work again. After seeing their existing setup, it didn’t take long for us to decide they needed an upgrade and we would start from scratch.
The stadium let us borrow the radar gun, the only part of the process we intended to keep. Reverse engineering it wasn’t too bad. We were able to find a manual and figure out that the three pins coming out into the handle were two for the battery and one for a serial signal. Once we connected to this signal, it was trivial to decipher it (9600 baud ASCII text). We designed a 3D printed part that would take the place of the handle and supply power to the radar gun as well as grab the serial signal.
Yes, those are nails. They worked perfect.
After that was the box to replace the controller. This box would read in the serial signal, compensate for the angle, and send out a signal to the sign. At first we played with XBee for a wireless transfer. This ended up being so unreliable and so difficult to get set up that we decided to give up. Besides, long term support is important for this kind of a project, and something wireless is a lot more difficult to diagnose and debug than wired. So we went with RS485, which is perfect for long distances, and there was already a pre-existing cable from the previous sign. I threw in a screen and some buttons for good measure (to let the user adjust the angle), and a switch to turn it all on, and we were good to go. Now the only thing a user has to do is flip the switch to turn it on, then push the power button on the radar gun, and it works.
Next was coming up with a sign. We’ve used the P10 red LED modules before on the bar bike, so we had some experience. For this one we purchased the outdoor waterproof ones. We also got power supplies and a controller card. There is some code on the web for controlling these guys directly, but it’s a lot of work and I didn’t have the time or inclination to figure it out. So we went with the controller card. I should note that the prices for these parts is ridiculously cheap. The LED modules are $6.50, the power supplies are $8, and the controller card was $50. So we had all the major components for the sign for just a few hundred dollars, and that’s because we ordered extras of everything in case of failures. We designed and cut an enclosure and attached the modules to the frame, then wired everything up. The wiring is simple; power up each column, data across each row. Two power supplies power two columns each.
Getting the controller card working was tricky, though. There is no documentation on the protocol, so I tried sniffing the packets being sent to it, but couldn’t make sense of them. There was no API, and after repeatedly pressing the Chinese company for resources, they sent some sample code and a dll, but it would only work on windows. We were trying to avoid Windows and go with a cheap (and low power) linux PC or Raspberry Pi, but in the interest of time, we ended up bailing on that and just getting a very old and cheap Windows XP laptop. Fortunately, it had a serial port, so we could hook a RS485 to RS232 converter to it and we were able to communicate quickly with the press box.
The controller card comes with some windows software for setting up the sign and displaying content, but it was difficult to get it to show real time data. What we ended up doing was writing a python script which would monitor the serial port and upon receiving a speed would write that speed to a file. One of the options in the other software for controlling the sign (called LEDSHOWT9), was to display the contents of a file, and update every N seconds. So we picked that option. Now every few seconds LEDSHOWT9 will look at the file, and take the contents (either the speed or a blank), and show that on the sign. Tada! It’s a hack, but it works. If inclined, maybe I’ll write up something better and do animations or something. But probably not.
Here’s the final product.
This post is about my attempt at a technological solution to gun problems. I built a working prototype, but ultimately I believe that this is not a solution to the problem of mass shootings. There is no technological solution that will prevent someone who is sufficiently motivated from doing significant harm yet still afford us the freedoms that make us human. However, what I built can help prevent people from harming others with weapons sometimes. It has some legitimate circumstances in which it could be very effective.
I was approached by a guy who recognized my wireless communications skills and proposed an idea to me. He had been thinking since the Sandy Hook shooting about how guns could be made safer, and thought that some kind of token that people wore that could disable weapons would be a great solution. Essentially he wanted to create a movement where people carried these tokens that emitted a disable signal, and he thought that governments could be convinced to mandate that all guns listen for this signal and refuse to fire when the disable signal is detected. That was where we started.
Clearly this idea had problems. First was socio-political. Getting a government to mandate this would be impossible, getting people to trade in their guns would be impossible, preventing gun smuggling would be impossible, and establishing exceptions for military and police would be a loophole filled nightmare that would render the system useless. The next problem was technological. A token that’s always emitting a signal would run out of batteries quickly. A weapon that could automatically disable itself would be tricky. And a system that only deactivates if it hears a deactivate signal can easily be foiled by… aluminum foil. Wrapping the gun in aluminum foil would prevent the signal from reaching the antenna.
It took a lot of back and forth to come to a final solution, and it still has flaws. But we’ll get to that later. And I have no way to address the political or social problems; I’m a technical guy and that is a job for someone else. Here’s what we ended up with:
1) An enable token with a button that emits an ‘enable signal’ repeatedly while it’s turned on. We’re using Bluetooth Low Energy because this is exactly the sort of thing BLE was designed for. Low energy wireless communications. The enable token is paired with the weapon so that only that enable token can enable that particular weapon. This means the weapon will not enable unless the enable token is on, and within range. This prevents people from using stolen weapons, or getting into their parents’ guns, or accidentally firing, and can also prevent a gun from being used against its owner. This enable token alone is what makes this system great. There are far more accidental shootings, shootings with stolen weapons, and attacks against the owner than there are mass shootings, and an enable token paired to a gun would prevent a lot of those. But the enable token also serves another important purpose. Remember how you could just wrap a gun in aluminum foil so it doesn’t get any disable signals? Well if the gun needs to hear an enable signal, it can’t do that while covered in aluminum foil. So the fact that the gun has to hear a signal to enable means it must be capable of hearing a signal to disable.
2) The weapon with a receiver (and optionally a transmitter). The weapon has an electromechanical device that is connected between the safety and the firing mechanism. When the safety is diesngaged, this module is powered on, and when it hears the right enable signal, and no disable signals, it will allow the gun to fire. As soon as it hears a disable signal or stops hearing the enable signal, it will disengage and the weapon will not fire.
3) A disable token that emits a ‘disable signal’ every few seconds. Essentially this beacon says to any specially equipped guns “please don’t fire near me.” Any weapon or enable token within range will immediately disable itself. Another advantage of using Bluetooth Low Energy is that many cell phones are now coming with BLE capability built in, which means eventually a cell phone could be emitting this disable beacon. So people wouldn’t need to carry an additional piece of electronics; it would be an app they could download and run in the backgroun
4) Finally, a fourth device can plug into a wall and emit a disable signal regularly. It could also be listening for enable signals that would indicate someone is trying to enable a gun. And if the gun were emitting a signal saying “hey, I’m a gun and someone is trying to fire me” it could listen for that as well. It would have a siren and possibly other ways to indicate authorities that a gun was trying to be used in a certain area.
I ordered some fake guns from Amazon, some Bluetooth modules from BlueGiga, and designed some parts for the enclosures. Writing the software for the Bluetooth modules, building the circuits, 3D printing the parts, assembling it all, and testing it, took a relatively short amount of time. A few weeks, really, and that was just in my spare time. It’s only prototypes, so I wouldn’t want to mass produce them the way I built them, but for a working prototype, it works and looks acceptable.
One thing I skipped was designing the electromechanical part that would prevent a gun from firing. I justified this by saying that many guns would be different in their implementation, and I don’t have a real weapon to develop for, and we were trying to prove the wireless concept.
Here are a few of the problems I ran into.
This is my contribution to the conversation. I built something that has the potential to solve some problems for some people. But after developing and considering the situations in which this might not work, and the motivations behind the gun makers, legislators, gun owners, and gun shooters, this system, and any other like it, has too many holes and challenges to make it a cure-all for gun control. We shouldn’t be applying technology like this to guns because it defeats their purpose and doesn’t solve the real problem that exists with the person holding a weapon.
After Erin took me on a ski trip to Salt Lake City for Christmas 2010, I was far behind in the Christmas Karma. For 2011 I planned to take her to a resort in Wisconsin Dells, which is sort of like the Las Vegas of Wisconsin, except with water parks instead of casinos. Of the many resorts, I decided on Kalahari based on recommendations of others and some research on the web. But just telling her wasn’t a great way to do the presentation. I wanted her to unwrap something.
I’ve been working for a while on a portable electronic scoreboard, so I had all the materials to make a good LED sign with the name. The day before we were to leave for Kansas, I started the project. The idea was to make a big LED sign that said Kalahari on it. It would be battery powered, and a switch would turn it on when the box was opened so that it wasn’t on the entire time and running out of battery. That was as far as I got in planning before I started building.
I borrowed a rechargeable battery from Sector67 to use as the power supply, then laid out the LEDs on a prototyping perf board covered with sticky black nylon paper. It took a couple tries to get it all to fit on the available board with legible letters and decent spacing. Then I found a switch that would work. The circuit was simple. The switch connected the + voltage to the board and the ground went directly to the board. The LEDs were connected with a resistor and two LEDs in series, and all those strings were in parallel. This meant a huge current drain, but I was limited to a power supply with only 6 volts, so I didn’t have much choice. This also meant a LOT of soldering and a lot of current limiting resistors. There was an odd number of LEDs, so I put an extra one on the back side so that the circuits were all the same.
With all these LEDs packed into a small space, it was very bright, so I struggled with a few different ways to do the presentation. I ended up taping the board behind a piece of paper so that the paper would diffuse the light a little. It ended up working great. The paper covered everything, including the switch. When the box was closed it was off, and when it was opened the switch was triggered, turning on the sign.
The girlfriend was happy, so the project was a success.
The next time I do something like this I’ll use less LEDs and instead of doing a sign of LEDs I think it would be better to have a piece that had letters cut out and was backlit by only a few LEDs. I also would have spent a lot more time on what was surrounding the sign. Using regular paper and crayon to draw was the best I could do with the limited time and resources I had, but it wasn’t enough for me. Construction took far longer than I expected, and I was a little disappointed with the results. I was working late into the night to solder it all together, and I barely had any time to work on the rest of the package. I can do better.
Since I’m moving in a few months to an apartment of significantly reduced size, I am starting to reduce the size of my collection of stuff. One thing I’ve been carrying around is everything from my college career. I have every syllabus, paper, homework assignment, handout, midterm… in total it was three boxes full of binders. This represents tens of thousands of dollars of education, though, and I wasn’t entirely willing to part with it. I started scanning pages with a scanner. I had a process that was giving me up to 6 scans per minute. The quality of the scans was good, but the speed was not fast enough, and there were too many manual parts to the process. I needed something faster.
I realized that a photo of a piece of paper would be faster than having a scanner do it, and if lit well enough and with a good enough lens, it would be just as good as a scanner. I rigged up a tripod with an extended arm to hold my camera, and I put a white background on the desk and marked some lines where the paper needed to be to be in the shot. Since I don’t have a fancy DSLR with a remote, and pressing the button manually was way too much effort and moved the camera around too much, I rigged up a piece of twine so that by pulling down on the twine I could get the camera to take a shot. I tried pulling the string for a while, which was pretty fast, but still not as efficient as possible. I tied the twine to a ruler and used the ruler as a foot pedal, giving me both hands to move the pieces of paper as quickly as possible. The light sources were just regular white compact fluorescent bulbs, placed to put as much light on the paper as evenly as possible.
The resulting contraption bumped my speed up to 15 pages per minute on average. Sometimes it was higher depending on if I was dealing with loose notes or stapled sheets. Having the shutter controlled by my feet gave me a huge advantage, and I was able to fly through all 3 boxes of papers in a few evenings much faster than I expected. Now I have it all on my computer, which should probably still be sorted, but at least it’s not taking up any physical space, and I don’t have to feel any sense of loss when I recycle my stacks of papers.
Last night I made some changes to my mouse; we’ll see if they’re improvements or not. Originally I was dismantling it to clean it. Something had gotten inside the wheel and was causing it to scroll inconsistently. Once I got inside, though, I saw an opportunity to tune it.
First was the clicking on the wheel. This is accomplished with a spring, and is sometimes annoying, especially since I like to give my scroll wheel big long spins to quickly move around on a page. Removing the spring was pretty easy.
Second, I noticed a weight added to the inside. I’m not entirely sure what the weight accomplishes, other than making the mouse that much harder to move, so I took it out, too.
If I need, I can easily put the parts back in, but at the moment I’m rocking a lighter, smoother mouse.
A while ago I built a computer input device using a laser pointer and regular usb web camera.
It was a pretty simple setup, and I used a lot of existing tools as a jumping off point. Here’s a writeup of my work and details for how to replicate it and what I learned.
First, a video overview:
At a minimum:
Optionally:
Technically speaking, the laser is completely optional. In fact, during testing I just had a desktop computer with the camera pointed at a sheet of paper taped to a wall, and I drew with the laser pointer on that sheet of paper and used that as an input device. With the projector, you can turn the setup into a more direct input, as your point translates directly to a point on a screen. But that’s just a bonus. This can be done without the projector.
Take the camera, point it at something. Shine the laser inside the area where the camera can see. That’s it in a nutshell. However, there are some additional considerations.
First, the more direct the camera, the more accurate it will be. If the camera is off to the side, it will see a skewed wall, and because one side is closer than the other, it’s impossible to focus perfectly, and one side of the wall will be more precise than the far side of the wall. Having the camera point as directly as possible at the surface is the best option.
Second, the distance to the surface matters. A camera that is too far from the surface may not be able to see a really small laser point. A camera that is too close will see a very large laser point and will not have great resolution. It’s a tradeoff, and you just have to experiment to find the best distance.
Third, if using a projector, the camera should be able to see slightly more than the projected area. A border of a few inches up to a foot is preferable, as this space can actually be used for input even if it’s not in the projected space.
Fourth, it’s important to control light levels. If there are sources of light in the view of the camera, such as a lamp or window, then it is very likely the algorithm will see those points as above the threshold, and will try to consider them part of the laser pointer (remember white light is made up of red, green, and blue, so it will still be above the red threshold). Also, if using a projector, the laser pointer has to be brighter than the brightest the projector can get, and the threshold has to be set so that the projector itself isn’t bright enough to go over the threshold. And the ambient light in the room can’t be so bright that the threshold has to be really high and thus the laser pointer isn’t recognized. Again, there are a lot of tradeoffs with the light levels in a room.
I wrote my software in Java. There are two libraries that I depended on heavily:
The JAI library is not entirely essential, as you could decide not to translate your coordinates, or you could perform your affine transform math to do it and eschew the large library that will go mostly unused. The neat thing about this transform, though, is that it allows for the camera to be anywhere, and as long as it can see the desired area, it will take care of transforming to the correct coordinates. This is very convenient.
The JMF library exists for Windows, Linux, and Mac. I was able to get it working in Windows, but wasn’t able to get it completely working in Linux (Ubuntu Jaunty as of this writing), and I don’t have a Mac to test on.
The basic theory behind the project is the following; a laser pointer shines on a surface. The web camera is looking at that surface. Software running on a computer is analyzing each frame of that camera image and looking for the laser pointer. Once it finds that pointer, it converts the camera coordinates of that point into screen coordinates and fires an event to any piece of software that is listening. That listening software can then do something with that event. The simplest example is a mouse emulator, which merely moves the mouse to the correct coordinates based on the location of the laser.
To implement this, I have the JMF library looking at each frame. I used this frameaccess.java example code as a starting point. When looking at each frame, I only look at the 320×240 frame, and specifically only at the red value. Each pixel has a value for red, green, and blue, but since this is a red laser I’m looking at, I don’t really care about anything but red. I traverse the entire frame and create a list of any pixels above a certain threshold value. These are the brightest pixels in the frame and very likely a laser pointer. Then I average the locations of these points and come up with a single number. This is very important, and I’ll describe some of the effects that this has later. I take this point and perform the affine transform to convert it to screen coordinates. Then I have certain events that get fired depending on some specific things:
For most of these events, the raw camera coordinates and the transformed coordinates are passed to the listeners. The listeners then do whatever they want with this information.
Calibration is really only necessary if you are using the coordinate transforms. Essentially, the calibration process consists of identifying four points and mapping camera coordinates to the other coordinates. I wrote a small application that shows a blank screen and prompts the user to put the laser point at each of the prompted circles, giving the system a mapping at known locations. This writes the data to a configuration file which is used by all other applications. As long as the camera and projector don’t move, calibration does not need to be done again.
Here is a video of the calibration process.
Here is the camera.zip (3.7mb). It includes the JAI library, the base laser application, the calibrator, and an example application that just acts as a mouse emulator.
Below are a couple snippets of the important stuff.
This first part is the code used to parse each frame and find the laser point, then fire the appropriate events.
/** * Callback to access individual video frames. This is where almost all of the work is done. */ void accessFrame(Buffer frame) { /***************************************************************************************/ /********************************Begin Laser Detection Code*****************************/ /***************************************************************************************/ // Go through all the points and set them to an impossible number for (int i = 0;i<points.length;i++){ points[i].x = -1; points[i].y = -1; } int inc = 0; //set our incrementer to 0 byte[] data = (byte[])frame.getData(); //grab the frame data for (int i = 0;i<data.length;i+=3){//go through the whole buffer (jumping by three because we only want the red out of the RGB //if(unsignedByteToInt(data[i+2])>THRESHOLD && unsignedByteToInt(data[i+1])<LOWERTHRESHOLD && unsignedByteToInt(data[i+0])<LOWERTHRESHOLD && inc<points.length){//if we are above the threshold and our incrementer is below the maximum number of points if(unsignedByteToInt(data[i+2])>THRESHOLD && inc<points.length){//if we are above the threshold and our incrementer is below the maximum number of points points[inc].x = (i%(3*CAMERASIZEX))/3; //set the x value to that coordinate points[inc].y = i/(3*CAMERASIZEX); //set the y value to the right line inc++; } } //calculate the average of the points we found ave.x = 0; ave.y = 0; for (int i=0;i<inc;i++){ if (points[i].x!=-1){ ave.x+=points[i].x; } if (points[i].y!=-1){ ave.y+=points[i].y; } //System.out.println(points[i].x + "," + points[i].y); } //System.out.println("-------------------"); if (inc>3){//if we found enough points that we probably have a laser pointer on the screen ave.x/=inc;//finish calculating the average ave.y/=inc; PerspectiveTransform mytransform = PerspectiveTransform.getQuadToQuad(mapping[0].getX(), mapping[0].getY(), mapping[1].getX(), mapping[1].getY(), mapping[2].getX(), mapping[2].getY(), mapping[3].getX(), mapping[3].getY(), correct[0].getX(), correct[0].getY(), correct[1].getX(), correct[1].getY(), correct[2].getX(), correct[2].getY(), correct[3].getX(), correct[3].getY()); Point2D result = mytransform.transform(new Point(ave.x,ave.y),null); in_space = !(result.getX()<0 || result.getY() < 0 || result.getX() > SCREENSIZEX || result.getY() > SCREENSIZEY); if (!on){ fireLaserOn(new LaserEvent(result, new Point(ave.x, ave.y), last_point, last_raw_point,in_space)); on = true; } if (in_space && !last_in_space){ fireLaserEntered(new LaserEvent(result, new Point(ave.x, ave.y), last_point, last_raw_point,true)); } // System.out.println(result.getX() + "," + result.getY()); // System.out.println(last_point.getX() + "," + last_point.getY()); // System.out.println("----------------------"); if (result.getX()!=last_point.getX() || result.getY()!=last_point.getY()){ fireLaserMoved(new LaserEvent(result, new Point(ave.x, ave.y), last_point, last_raw_point,in_space)); } else{ fireLaserStable(new LaserEvent(result, new Point(ave.x, ave.y), last_point, last_raw_point,in_space)); } if (!in_space && last_in_space){ fireLaserExited(new LaserEvent(result, new Point(ave.x, ave.y), last_point, last_raw_point,false)); } last_time = 0; last_point = new Point2D.Double(result.getX(), result.getY()); } else if (last_time==5){//if it's been five frames since we last saw the pointer, then it must have disappeared if (in_space){ fireLaserExited(new LaserEvent(-1,-1, ave.x, ave.y, (int)last_point.getX(), (int)last_point.getY(), (int)last_raw_point.getX(), (int)last_raw_point.getY(),in_space)); } fireLaserOff(new LaserEvent(-1,-1, ave.x, ave.y, (int)last_point.getX(), (int)last_point.getY(), (int)last_raw_point.getX(), (int)last_raw_point.getY(),in_space)); on = false; in_space = false; } if (ave.x>0 || ave.y>0 && ave.x<CAMERASIZEX && ave.y<CAMERASIZEY) fireLaserRaw(new LaserEvent(-1,-1, ave.x, ave.y, -1,-1, (int)last_raw_point.getX(), (int)last_raw_point.getY(),in_space)); last_time++;//increment the last_time. usually it gets set to 0 every frame if the laser is there last_raw_point = new Point(ave.x,ave.y);//set the last_point no matter what last_in_space = in_space; /**************************************************************************************/ /********************************End Laser Detection Code*****************************/ /*************************************************************************************/ } public int unsignedByteToInt(byte b) { return (int) b & 0xFF; }
This next part is pretty standard code for adding event listeners. You can see which laser events are getting passed. I intentionally made it similar to how mouse listeners are used.
Vector<LaserListener> laserListeners = new Vector<LaserListener>(); public void addLaserListener(LaserListener l){ laserListeners.add(l); } public void removeLaserListener(LaserListener l){ laserListeners.remove(l); } private void fireLaserOn(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserOn(e); } } private void fireLaserOff(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserOff(e); } } private void fireLaserMoved(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserMoved(e); } } private void fireLaserStable(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserStable(e); } } private void fireLaserEntered(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserEntered(e); } } private void fireLaserExited(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserExited(e); } } private void fireLaserRaw(LaserEvent e){ Enumeration<LaserListener> en = laserListeners.elements(); while(en.hasMoreElements()){ LaserListener l = (LaserListener)en.nextElement(); l.laserRaw(e); } }
It’s no secret that I love my car. It’s been extremely dependable, has treated me very well, has a good personality and an adventurous attitude, and doesn’t ask for much (it’s a 2000 Chrysler Neon, and yes, I mean Chrysler). I’ve had it for almost 10 years and put over 100,000 miles on it myself in addition to the 20,000 that were on it when I got it used. If I were to get another car, I’d look for something exactly like the one I have.
But once in a great while it will have small issues. Once a wiring harness broke loose and cause the rear lights to go out. Other than that, it’s worked very well and could probably go for another hundred thousand miles without problem.
About a week ago I put my key in the door to unlock it and found that it turned freely. I had to unlock the passenger side and then unlock the driver side from the inside. For a few days I drove around without locking the door. Monday I finally got an opportunity to examine the problem. I was able to disassemble the door relatively easily. It was fairly straightforward except for the part where the window handle was connected, but I managed to find the service manual online and pop the handle off. Then I could get in to the lock mechanism and see where the problem was. It didn’t take long to discover the problem. The rod that connects the lock mechanism to the key had slipped off. The piece that held it on was missing. Figuring it was probably at the bottom of the door frame, I felt around and identified it. Yep, there was the problem.
That piece should be symmetrical. The piece that had broken was about 2 millimeters wide and because of that the thing slipped off the lock and was no longer holding the rod in place. It didn’t take much jostling for the rod to fall out.
I didn’t have any parts exactly like that, and I was up to the challenge of fixing it with parts that I had around the house. I made a crude washer out of a piece of scrap tin from a can. Then I made a springy curl of stiff wire that would take the place of the part that broke. I installed onto the lock mechanism and played with it a little to make sure it was stuck pretty well. I tried to take it off to adjust it a little, but couldn’t even get it off without some serious effort, so I just left it on there. I tested it thoroughly before putting the door back together. With the door completely reassembled, I tested it out some more, and it worked exactly like it had originally worked.
I’m kind of glad that my car is mostly mechanical and doesn’t have a lot of electronic parts. Electronic locks or windows would have made this a much more difficult operation. I’m also happy that I was able to build the parts that I needed from scratch and basic tools. Plus, I always enjoy doing things with my hands and seeing the results and saving money in the process.