Having filled up the last page of my store bought dive log, I decided it was time I started printing my own log sheets. I wanted a template that could fit in a small binder (half letter (5.5″ x 8.5″) or A5), where there was enough space on the page to log two dives and that gave me ample space for comments while providing the standard diving data fields. Unfortunately, I could not find anything that suited my needs so I decided to put together my own.
The layout is compact and text has been kept to a minimum: you write the units yourself. Once it has been printed (on good paper stock and double side preferably), cut the sheets in half along the dotted line, punch holes if you want to store them in a binder and go log some dives.
For those interested in the source, here it is. Suggestions for improvements are welcome!
On several occasions lately, I’ve had to transport long objects or gain access to the rear strut mounts in my Toyota Corolla. On most cars, this would have meant to simply pull a lever in the trunk and fold the back seat down but for some reason, Toyota had made this an option on my vehicle (the North American VE model).
So in order to be able to take advantage of the full length of the car, I had to remove the rear seat, which is not that difficult and only requires a socket wrench, but still massively inconvenient. While undoing the seats, I had originally thought of a way to make removal easier and tool-less in the future, but did not decide to make the modification. Until now, with winter at my doorstep, I’m convinced fold-down seats are going to prove themselves quite practical should I want to go skiing.
The mod is quite easy and requires no specialized tools or knowledge. The end result is that you will be able to lift the backrest up and lay it flat on top of the bottom cushion, exposing the opening to the trunk . Since the seat belts are bolted to the frame, disturbing the seating should not have any effect on their function. However, you might end-up discarding a part I call the V frame, which could possibly have some structural or security importance, I’ll get to it later. Lastly, I’m not going to post a full disclaimer, this is the internet so you’re following this guide at your own risk. If you or your passengers get hurt because of this modification, nothing can be held responsible but you and your judgement.
Removing the rear seat
Bottom cushion out
Taking the rear seat apart is nothing really complicated. The bottom cushion is held to the frame of the car by only two plastic clips that are approximately lined with the two front seats. You can even feel them by running your hand under the cushion along the outer edge. Pry them out with a sudden pull and they should give.
Backrest out
Next, undo the three bolts holding the back cushion to the frame. There is a bolt in the middle and two at the extremities close to where the seat belts attach to the frame. Lift the backrest out and set it aside outside the car. At this point you can re-install the bottom cushion to make working in the car a bit more comfy. Finally, push out the black plastic cache that separates the trunk and the interior.
If you just wanted your rear seat out only as a temporary measure, stop here. The car is perfectly drivable in this state. You might notice the road vibrations becoming somewhat louder but that’s entirely normal given the amount of noise insulation you just removed.
Removing the V frame
V frame removed
What I refer to as the V frame is the coincidentally V shaped piece of pressed sheet metal bolted right in the middle of the opening to the trunk. It’s in the way but if it does not bother you you can certainly keep it there. I, for one, decided to remove it because I did not deem it to be critical for the safety or handling of the car. First, Corollas with factory installed fold-down back seats do not have it and I’d be really surprised if their frame was any different than the standard model to account for the added structural integrity. Second, if it’s purpose was to give the body more stiffness, the V would be upside down. It could have a part to play in case of rear collisions, but my theory is that it’s meant to add support to the rear seat. So If you agree with my logic, you can go ahead and remove the six bolts that hold the V frame in place.
Fastening the bottom cushion
Bottom cushion fastened
Last major step is fastening the bottom cushion. It has three metal prongs that would normally slide under the backrest part of the seat, but since it will now become loose, the bottom cushion needs to be attached to the frame. Once you have re-installed the cushion, simply drill holes where the prongs are. Rest assured, the metal is not very thick and your fuel tank is a safe distance below. Once that is done, use properly sized sheet metal screws and washers and thread them through the holes you just did to hold the cushion down.
Of the metal prongs on the bottom of the backrest that used to be screwed to the frame, the middle one get in the way and should preferably be removed. Its not absolutely necessary, but it will make installation easier. This procedure can be accomplished with a bolt cutter or a metal saw. There is another prong right next to the one you just cut that is meant to slide under the seat cushion; leave it in place.
Finally, slide in the backrest, thread the seat belts in their correct position and set it so the metal loops below the headrests pair up with the hooks on the frame. Give it good tap so it sits correctly and you’re done. Nobody should ever notice this little trick but I’m sure its going to prove itself very useful.
Done! You can now transport dead bodies in your trunk without having to cut them up.
Going way back to 2006 actually, to my very first electronics project, a digital clock with an analog twist. I had very little experience in programming let alone electronics and back then, user-friendly prototyping platforms were not that common and mostly underground; the arduino had only came out the year before.
The clock with its faceplate removed
For many evenings in my dorm room I battled with a bunch of components and a serially programmed Microchip PIC16F628. I recall having loads of trouble getting inputs to the chip functioning, with the minutes and hours buttons activating or refusing to work with a mind of their own. The internet was not of much help but in the end I figured it out: pull-down resistors. No wonder I could not find anything on the subject, for someone with the least bit experience in electronics, it’s one of the most elementary concepts, akin to trying to troubleshoot a TV that’s not plugged in. For beginners attempting to learn electronics by themselves, its nothing but trivial.
Eventually, I succeeded in putting a working clock together on the breadboard that I had. Back in my basement over the next break from school, I soldered the whole thing on a perfboard and equipped the circuit with a face plate. The programming is rudimentary, the circuit is much less than optimal and in spite of the 32kHz watch crystal, there is still a bit of drifting but I could not have asked for a better learning experience. Some LEDs have burnout, but even after those years, it’s still doing a fine job at reminding me that time is ticking.
Note: this post about an electronics project has been sitting as a draft since 2011 so some of its content might appear outdated. Regardless, I’ve been using the device since then so I figured I should commit it to posterity.
To my computer, its simply a USB keyboard, nothing less, but to me its a remote I can use on any platform with no line of sight. I decided to name it the keyMote. Sounds a bit odd to my ears but its a fitting name.
Here is how it works. There are two parts to this system, the remote, which is battery powered, and the base, which is hooked up to a computer. The remote is a simple keypad (In the case of the prototype, its a numeric keypad, but really, it could be any interface) with a transmitter hooked up to it. The base, the other end, is a receiver with USB Human interface device functionality, in other words, a vanilla USB keyboard. When a button is pressed, the remote sends the identifier of that button to the base which then looks up in a table the keystrokes this identifier is mapped to and sends those to the computer via USB. What button is mapped to what keystroke is entirely configurable using a serial terminal interface (shell) to the base. It can be anything, Ctrl-C, Alt-Shift-F, PageUp, etc. Getting it to interface with your program is then simply a matter of configuring keyboard shortcuts.
The use case
Here is the actual use case that spawned the idea. I was doing some plumbing work in my kitchen with the computer playing songs in the background. It then hit one in the playlist that I especially hate (but keep for nostalgia), but I was in no position to change it as it would have implied bending out of underneath my sink, walking to my computer and then hitting Ctrl + Shift + Right to skip to the next tune. I use Linux and at that time, the media buttons on my keyboard were not operational, I knew very few remotes would work on my platform and finally, I had no line of sight with the computer, so infrared was out of the question. Agreed, a wireless keyboard would have done the trick, but those tend to be limited in range, and well, they are still keyboards, so you have to do the key combinations yourself and are somewhat cumbersome to lug around. So I thought: Why not get something that will emulate my hands typing the keyboard shortcuts?
I looked around for possible off-the-shelf solutions, but none of them were well supported under Linux; basically they all required drivers and were proprietary and as we all know, anything with a driver is dependent on company support an will get dumped sooner of later. The keyboard idea was starting to get some traction. It was the obvious medium to go with, the USB human interface device standard has been around for a decade or so and will likely stick for a few more but more importantly, it is understood by most OSes. Failing to come across anything that would suit my purpose, I set out to develop one from scratch and after a bit of work (or a lot, depending where you come from), I had what I wanted: a simple, rugged self-contained system with no drivers attached, plenty of battery life and a way to make it type whatever I want. Currently, its mapped to my MP3 player, sound controls, Video player controls and some programming IDE functions. It could very well launch applications, toggle the visibility of certain windows (via the window manager), start scripts; it can do anything a keyboard can do.
The system
The main hardware components are an arduino, a wireless receiver and transmitter pair and another microcontroller hooked up to a battery in the remote. I started off with trying out wireless communication on the arduino IDE but soon converted to C/C++ for the added flexibility once I was past figuring out the libraries.
Base
The base software is mainly an interface between two libraries, VirtualWire and V-USB along with a shell to configure the mapping between remote key codes and key strokes. VirtualWire is a library that makes exchanging bits (a lot harder than the datasheet implies, what you send on TX is quite what you get on RX) between vanilla wireless interfaces very straightforward. V-USB is a marvelous implementation of the USB protocol on the AVR using nothing but bit-banging. It’s quite limited in capacity but it’s extremely lean and makes USB accessible for anyone with the patience to understand the protocol. While the actual serial shell is a fair chunk of code, it is needed only for configuration, so this project is mainly composed of glue code and basic electronics. The arduino’s USB connector is used for serial shell functionality, where using commands it is possible to consult statistics about the system, get debugging data, but more importantly map key Ids to key strokes. The other USB connector is the actual keyboard.
The base schematic
Since I had an arduino to spare, I decided to implement the USB and wireless interfaces as a shield rather than build a specific circuit. Really, the only hurdle was the weird spacing between pin 7 and 8 (why?), but that got solved by soldering angled headers to the side of the perfboard at an offset with the holes they would normally fit in. The wireless receiver was a breeze to connect but the USB interface was slightly more complex, with a couple of zener diodes and resistors to get the correct line levels.
Two versions of the base were created but they only differ in the way they look.
Base version 2
Base version 1
Base version 1 opened
Remote
The base is mostly software but the remote is mostly electronics. The code is essentially a loop that intercepts keypad presses and sends them out through the transmitter to the base. Since it’s battery powered, the complexity of the firmware lays essentially in the power management code as the electronics cannot be left on running at full power all the time.
Remote prototype schematic
I built two different versions of the remote. The prototype which used another ATMega328P (same MCU as the arduino) featured an off-the-shelf keypad and a USB connector with a MAX 1555 for charging. The MCU is left in its deepest sleep mode all the time and is only waken up when a key press occurs. As a result, power consumption is in the order of nano amperes which yields a battery life of a couple months under normal usage when hooked up to a 900 mAh LiPo battery.
Remote version 2 schematic
The second version goes even further into increasing battery life. The ATMega328P, overkill for this application, is replaced with an ATTiny84 and the keypad interface is hooked up a circuit that turns on the micro controller and the transmitter from a fully off state only when a key is pressed. It’s using the same battery as the prototype but the power usage is so minute that after close to two years I have not yet exhausted the battery and measuring the drain is beyond my multimeter’s range. Granted, usage has been on and off due to me leaving for extended periods of time but still, that’s a pretty decent statisctic. So much so that I had plans to convert it to a solar cell and supercapacitor design but sadly, all my prototyping efforts led to failure.
Remote prototype
Internals of the remote prototype
Internals of the remote version 2
The result
It was quickly put together and yielded a result of fairly high quality and convenience for the effort. I’m not saying there is no room for improvement, but it was refreshing to do a project that was not plagued by unforeseen complexity and feature creep. I’ve been using both remotes for the past two years and have been getting months of battery life for the prototype and for its successor, well, it’s still running after two years. Range wise, I can send commands at a distance of about 10 meters through several walls so it more than sufficient.
Since I have no plans to revisit the project in the near future, I’m publishing the source code and the schematics (made with gEDA) up for download on a GNU GPL license. Take note that some of the third-party libraries use a different license which is specified in their respective folders. Should you have any questions, do not hesitate to reach me through the comments or the contact page.
Last out of the workshop are four knife blocks made from cherry, oak (not obvious), walnut and two exotic flavours: padauk (red) and purpleheart (purple). To keep cost low, the large cherry/oak pieces were laminated from scraps bought for cheap at the lumber yard.
The design is somewhat unusual as the poor precision of my tools would not allow me to build a completely enclosed block like is most often seen. An added benefit however is that the slots are all of a similar size, so no need to look for the proper spot when dropping a knife in.
