Headlight Wiring - Plan, Participate, Prevail

So, after perusing the Internet trying to figure out how to implement electrical headlights, I finally knuckled under.  I had seen a few people use full actuators, and others who used some old Mazda Miata or Ford Probe headlight motors.  With the costs of actuators running to $200 a piece for a 4" movement (and needing one for each side), I realized I was too cheap.  I had to do the Probe conversion.

I ran to the closest junk yard, and found a mid-90's Ford Probe.  I pulled the motors and arms attached to the motors and paid about $30.  I ran home and tested them against the battery.  Woohoo! They both worked!

Next, I had to wire them up.  I didn't want to cut into the old harness at all in case I wanted to back this out some day.  So, I grabbed three spade connectors - these would plug into the current 3-prong headlight connector (the one for brights AND regular beam).  I also bought a new 3-prong connector. These would be soldered together with three wires coming off as "taps".  These three wires (one is battery negative, the other two are battery positive when the high beams are on, or the low beams) feed (via two 1 amp diodes to prevent both lights from coming on) into a 12 relay (SPDT, or Single Pole Double Throw, where when on, one is connected, but when off, another terminal is connected).  This is wired to a fuse and to a battery connection.  When the high beams or the low beams are on, it triggers the relay to power one line, and when neither are on, the relay switches back to the other.  These two feed the motor trigger signals.  A second "power" is also run to the motors, and a negative battery connection.  I tested this (test often is vital to make sure it works) via a breadboard first, with LED's to make sure I had things connected right (e.g. when one light was on, the signal light was on, and when the other light was on, the same signal light was on, but one light did not cause the third light to come on).

Once I knew I had the circuit right, I had to implement it. I grabbed a solder "bread board", and soldered everything into place.

Then, I tested it against the real lights and motors.  Success!  I threw on electrical tape to protect things, and applied epoxy to the bread board to seal it in.  When the epoxy had set, I applied more electrical duct tape to ensure it wouldn't cause other problems.

Once it was all wrapped up, I installed it, and tested it once more just to make sure it was good.  Congratulations!  Now I just need the headlight units back from the painter, and I can finish the front end of the car!  Here's my shopping list.

• 2x Ford Probe headlight motor
• Brackets (had to make these out of porch 4" post end caps from Home Depot)
• 3x Spade Connectors
• 1 3-Prong Headlight Connector
• 2x 1 Amp Diodes
• 1 solder board from Radio Shack
• Wire (red and black)
• Epoxy

If anyone wants to convert, it's not too difficult!

Corvette Rallys Sold - Paint Picked Up

Well, I got tired of having the Corvette Rally's sitting in the garage taking up valuable floor space.  I put in an add online, and sold the rallys, tires, stainless trim rings and center caps.

 

The rallys were online for the last three weeks.  I think they found a good home.  I know I could have pulled (asked for) more, but I just didn't want to deal with eBay, etc, and thought I'd sell locally.  I was surprised that they sold as quickly as they did (and I'm okay with the price they were sold at).  They'd be used in restoring a 1967 Camaro - perfect!

The beautiful thing is that the actual sale of the rallys came just hours after I learned that the cost from the painter in replicating the paint would be around $400.  Add in the $200 for the cost of a half pint of base color and a half pint of pearl, and we're sitting at $600.  Ouch.  However, this could be valuable information if the painter can do it, and could be worth it to know how many layers of base color, and how many layers of pearl, mixtures, etc.

So, here is the paint information, codes, and labels.  The bill came to $185.71 - The main color was $67.20 for a half-pint, and the pearl was $106.60 for a half pint :

First, the main (base) color  (#908362):

Next, the pearl half pint :

The color chip :

That chip came out too dark, so I had to try one with a flash :

That one looked a little better for the representation of the color.

I delivered the parts and paint to him and he said he'd try to get to it next week.  That would be a huge step toward being finished.

I did find a new color that I thought would be awesome while I was at it for the next project (perhaps a motorbike).  It's Grandeur Blue over Sterling Silver :

CentOS 7 - xscreensaver

I really hate this Gnome interface - badly.  It requires so much clicky-clacky/mouse-moving work that I instantly feel like I'm in Microsoft Windows again.  I prefer a nice, simple Window Manager that is simply that - a window manager.

I have a laptop that I have installed CentOS 7 to - after completely forgetting with a desktop installation - that doesn't have a viable screen saver (unless I choose to go with that abomination called "Gnome").  See, I can't deal with Gnome.  I tried KDE for a week, and half of the time, I couldn't unlock the KDE/plasma screen because it never presented the unlock on it.  I realized that CentOS was not going to make a good desktop/laptop operating system unless I could get to a decent Window Manager and screen saver.

So, I did what every intelligent, awesome, amazing, and brilliant individual would do.  I went down the rabbit hole.  Seriously, I should have taken the blue pill and pretended that Gnome was just awesome - but I don't think I could get beyond comparing it to slicing my wrists and doing pushups in salt water with a hint of lemon juice in it.  I grabbed Xfce (nice - this one came in packages from the Fedora Project epel repository).  However, the EPEL Fedora Project repository still did not have xscreensaver.  That's a serious risk to me.  The last thing I wanted was someone coming by, finding the laptop unlocked, and me returning to find Justin Beiber as my wall paper.

So, I knew I had to compile xscreensaver from scratch.  I ran out and downloaded it from http://www.jwz.org/xscreensaver/download.html and extracted it.  I found a couple of missing packages (aside from the development packages I'd installed previously), and found those in yum :

yum --enablerepo=base --enablerepo=updates --enablerepo=extras --enablerepo=epel --enablerepo=rpmforge install xorg-x11-server-devel.x86_64 libXt-devel libXpm-devel motif-devel

Then..., I tried to compile it :

make distclean
./configure --with-motif
make

I kept running into undefined functions for pthread_join and pthread_create, and thought I was missing a library - but I wasn't.  Down that rabbit hole, I realized I had to patch it.  I tracked down (from the error message) that it was trying to assemble the bsod screensaver and getting those functions, so I opened up the Makefile and started checking it to see how the -pthread was being passed.  After tracking it down, I created the following patch :

diff -rupN xscreensaver-5.30-base/hacks/Makefile.in xscreensaver-5.30/hacks/Makefile.in
--- xscreensaver-5.30-base/hacks/Makefile.in    2014-09-11 11:07:53.000000000 -0600
+++ xscreensaver-5.30/hacks/Makefile.in 2014-09-12 09:48:05.017172709 -0600
@@ -671,7 +671,7 @@ truchet:     truchet.o      $(HACK_OBJS) $(COL)
        $(CC_HACK) -o $@ $@.o   $(HACK_OBJS) $(COL) $(HACK_LIBS)
 
 bsod:          bsod.o          $(HACK_OBJS) $(GRAB) $(APPLE2) $(XPM)
-       $(CC_HACK) -o $@ $@.o   $(HACK_OBJS) $(GRAB) $(APPLE2) $(XPM) $(XPM_LIBS)
+       $(CC_HACK) -o $@ $@.o   $(HACK_OBJS) $(GRAB) $(APPLE2) $(XPM) $(XPM_LIBS) $(THRL)
 
 apple2:                apple2.o apple2-main.o  $(HACK_OBJS) $(ATV) $(GRAB) $(TEXT)
        $(CC_HACK) -o $@ $@.o   apple2-main.o $(HACK_OBJS) $(ATV) $(GRAB) $(TEXT) $(XPM_LIBS) $(TEXT_LIBS) $(THRL)

Simply put - the bsod compile instructions missed having the THRL (pthread library) environment variable passed to it.  That was the ONLY patching I had to do.  It still didn't compile because of the xscreensaver-demo until I symlinked the following Directory :

 cd /usr/include/
 ln -s gdk-pixbuf-2.0 gdk-pixbuf

Compiled just fine!

Paint Color Matching

I have good news and I have bad news.  First, with both door panels in, a good days worth of work could finish off the interior of the car.  With that in mind, it's time to start looking for a painter for the headlight units.

I called up some paint supply people, and got a recommendation - Larry at Vision Body & Paint, 11265 S 1300 W, South Jordan, UT (801-755-2084).  We talked for a little bit, and (since the paint was done with a gold pearl) now I have a good plan of action.

The color code I had last time was PPG Shimmering Shamrock, 908632 (UPDATE: I'm dyslexic, the code turned out to actually be 908362) 2-coat system.  Calling the supplier again (KC Auto Paint, 1600 S Redwood Road), and they said over the phone that it wasn't green - it was blue.  So now, I've got to run to the supplier with the part again, see if they can match it, grab a pint of stuff (they can mix the color for me), and run it over to the painter to let him try it out.  I think this one trip will cost me $300, but here we go!

UPDATE - I picked up a half pint of base color and a half pint of pearl, and delivered it to a new paint shop - we'll see how well he can match it.

'77 Door Panel with '78 Sport Mirrors and Remote

Wow.  The second door panel is now installed.  This was a bit different, since it wasn't designed for the bullet mirrors and the "remote" mechanism - I had to install it before the door panel was installed.  Here's what I did.

First, I had to mark where the remote connection would be coming through the door panel.  For this, I installed the door panel at the top, and swung it down to put a mark on the black plastic on the back of the door panel.  Then, using that mark, I drilled a vertical hole through the panel.  The problem was that the remote adapter goes through the panel at an angle.  I drilled a second hole through the panel at an angle.

With the approximate location of where things had to be cut, I grabbed my Dremel, and (using the back side of the chrome trim for the remote as a template) started cutting the approximate location:

Once through the trim metal, I found that the "vinyl" for the door underneath.  I used the Dremel again to cut through that, and found black plastic underneath that, too.  Beneath that was the foam, and then the back side of the panel, which was black plastic.  Cutting it out :

I then used the Dremel again to cut around and expand the "square" cut that was a template, making it very much an oval (which is what the chrome trim piece looks like).  Once I was close, I placed the trim piece in position and used an awl through it to mark where the two holes to hold it in place would go.  Then, I drilled them out :

With the trim piece in place, I started to look like it really belonged there :

I had a few minutes to install the door panel :

Looks like it was made that way!

"AfterGlass" - One Door Panel and One Dash Panel

Finally,  some visual progress! After adjusting the door glass, I was finally able to start installing some interior again... and got some work done on the right side. I did run into a few issues, though. First, even though the dash pad and the dash panel were made by the same company,  and purchased at the same time (7 years ago), they didn't match up so well. I had to redrill holes in the lower left pad and used finishing washers to prevent the screws from going through the vinyl all the way. Looks a little odd,  and maybe it's supposed to be done that way, I don't know -I've never seen the dash installed. Nor the door panels.

But, here I am having the right panels installed. Happy for me!

CentOS 7, Pidgin, and OTR

I recently upgraded to CentOS 7 for my desktop (probably a mistake, but that's what I do). I ran into a problem - I couldn't find the OTR plugin. I checked the EPEL repos - and I couldn't find what I needed. I could find the pidgin-otr-debuginfo RPM, but not the straight pidgin-otr plugin. Hrrrm. I need the plugin, so here's how I got it. http://rpm.pbone.net/ is a great little resource for finding packages from other distributions, so I ran out there and grabbed the libotr, libotr-devel, and pidgin-devel packages for RedHat EL7. I needed a couple of other packages that are available in the standard CentOS repository to give me the requisites, so fired off the following :

yum install libpurple-devel.x86_64 libgcrypt-devel.x86_64 gtk2-devel.x86_64

I then installed the pilfered RPM's grabbed through rpm.pbone.net :

rpm -ivh libotr-4.0.0-4.el7.x86_64.rpm libotr-devel-4.0.0-4.el7.x86_64.rpm pidgin-devel-2.10.9-1.el7.x86_64.rpm

Once I had the basics down, I needed to grab the source code for the plugin. I grabbed this from https://otr.cypherpunks.ca/ (the "OTR plugin for Pidgin" download). I extracted it, and ran through the normal compilations :

tar -xzf pidgin-otr-4.0.0.tar.gz
cd pidgin-otr-4.0.0/
./configure
make

Then as root :

make install

However, upon restarting pidgin and checking "Tools" -> "Plugins", I couldn't see the "Off-The-Record" plugin showing up. I reviewed the results of the make install, and found it installed to /usr/local/lib/pidgin/. So, I copied the files in place :

cp /usr/local/lib/pidgin/pidgin-otr.* /lib64/pidgin/

I restarted pidgin again to get it to pick up the changes, and viola!