The Treehouse Blog

Background

While shopping for my 2011 Toyota RAV4, I tried out vehicles that both had and did not have the factory navigation package. I decided that I basically didn’t like it. The one I purchased did not have the navigation package, but did have the “JBL” audio package and Bluetooth hands-free support, which seemed to work well.  After having some annoyance in mounting my aging Garmin nuvi (and having it stick properly), problems with the factory radio sometimes not working, and probably some pent up desire for a “project”, I embarked on finding a alternative.

Alternatives

I gave up on any cellphone-only solution since I needed to replace the factory radio anyway, and did not wanted a solution that appeared integrated (e.g., did not involve something with a windshield or bean-bag mount).

One set of options are the new head units that tether to your cell phone, allowing you to control your cell phone through the in-dash unit.  These generally involve HDMI output from your phone and use a Bluetooth connection for communicating touch screen interactions.  An example is the AppRadio series from Pioneer.  In researching this, it appears that the functionality is somewhat crippled out of the box, and that with a 3rd party app (ARLiberator).  I do think this notion has promise (and it did finally push me over the edge to buying the Slimport to HDMI adapter that works with my Nexus 4), but if I had to plug in my phone for each use, it mostly would be left undone except for extended trips.  This just did not seem to be the right answer.

The next option was a head unit that natively runs Android.  There brand name in this field seems to be Ca-Fi.  There are a number of knock-offs of this brand, the most common of which is being actively discussed on xda-developers.  I chose to get one of these units, and I will detail that adventure in upcoming articles.

This cost me too much time yesterday and today, so I’ll share it with the world in case I happen to save someone time.

I have been migrating hard drives within my Fedora 16-based server over the past months (yes, it’s taking way too long).  A project this weekend was to migrate the root file system from one drive to another.  The initial and final states are mdraid mirrors, but in the interim there are two degraded mdraid mirrors – one for the old, one for the new.  In attempting to boot from the new device, the boot would fail in dracut rescue mode.  I could proceed with mdadm -As ; exit but no matter what I looked at or tried, I could not get the process to proceed on its own.  In desperation, I tried adding mdadm -As into a custom dracut module or as part of the stock mdraid module – no luck. Eventually, after turning on and wading through all dracut debugging I could find, which didn’t really help other than making me read the dracut mdraid scripts, the obvious error was revealed. The format of the UUID field that dracut uses is matched against the output of mdadm --examine, and I had copied-and-pasted the output of blkid instead. Only after lining them up did I realize that although the identifiers are the same, the format is different:

blkid: c72b5415-c310-9955-c694-43f9004a021b
mdadm: c72b5415:c3109955:c69443f9:004a021b

The particular kernel line fragment is now: root=UUID=69c0f668-d395-4d45-b3df-5835240a0986 rd.md.uuid=c72b5415:c3109955:c69443f9:004a021b

So… if you’re setting rd.md.uuid in order for dracut to assemble your root array and it’s not working, make sure the parameter is formatted in mdadm style, and not blkid style!

Another tip on the subject: Always make GRUB2 changes using /etc/sysconfig/grub and/or /etc/default/grub and then re-build the grub.cfg file using grub2-mkconfig. Also, don’t use a symlink as a parameter for grub2-mkconfig -o. This will remove the symlink and write a new file at the location of the symlink, not the target. And hence, your changes won’t have happened.

Just a few notes on Android certificates – so I don’t have to re-google this in the future.

This is based on Android 2.3.7 / CyanogenMod 7.1.0.

Installing certificates (Settings – Location & Security – Credential Storage – Install from SD card) only looks on the root directory of the SD card for certificates – don’t bother putting them in sub-directories.  It also removes the file after installation.

If you have individual key and certificate files that you need to package into a PKCS12 for Android to import, the following works:

openssl pkcs12 -export -inkey Android.key -in Android.crt -certfile ca.crt -out Android.p12

(Courtesy: http://forums.openvpn.net/topic9062.html)

I recently installed Solaris 9 x86 on some unused hardware I had laying around.  The installation went fairly smoothly, which was good, given that previous attempts at creating a Solaris 9 x86 virtual machine on a variety of virtualization products proved fruitless.  I was unable to get the NIC to work, however.  It is an e1000-based chip, but a desktop version.  After applying all available patches, I had essentially concluded that the driver just didn’t properly support the card.  The behaviour was bizarre – using DHCP, the server would record the typical progression of messages, but the system would never finish configuring the interface.  With manual IP configuration, I would be unable to ping to or from the system, but ARP tables would populate.  Very confusing.  It seemed as if the card was working, but traffic was being dropped or filtered somewhere.  Eventually while trying to find information on the Realtek driver support, assuming I had to use a different card, I found a post regarding switching the system from APIC to PIC solving the problem.  I made the change in the BIOS, and the network card now behaves perfectly well.  Just thought I’d mention, in case some other poor soul encounters the same issue.

In order to count the pulses from my water and power meters, I purchased the Dual Counter from Hobby Boards.  For an enclosure, I purchased the temperature/humidity case which fit the board fine.

Per the how-to, the dual counter board expects to be connected to dry switches as input.  Since the water softener already powers the water meter, it would not be possible to connect it directly as input.  Also, I wanted to have LEDs to indicate pulses, for troubleshooting and direct monitoring.  To provide the dry contacts for the counter board, I decided to use optocouples.  I found a 10 pack of Vishay 4N37s on eBay, which seem to meet the need.

The water softener I have is a Water-Right Sanitizer Plus.  Removing the front cover of the control head reveals the connection of the water meter to the PCB using a 3-pin Molex KK connector – exactly the same as a common PC fan connector.  I purchased a fan splitter cable, connecting it between the PCB and meter.  I salvaged a fan connector from an unused fan and made an adapter to an RJ45, to bring the connection back to the counter board.  Empirically, I found that one pulse per second equated to one gallon per minute – or stated another way, each pulse represented 1/60th of a gallon.

The power meter I have is a GE I-210 / CL 200.  The manual indicates each pulse represents Kt (in my case, 1.0) watt-hours of accumulation, which is the same conclusion reached in a post by Jan Bottorff.  I had originally guessed a pulse was 1 kWs, as that was the most convenient and seemed reasonable, so I had to adjust this by multiplying by 3.6.  I taped an optotransistor to the plastic cover in front of the IR LED.  Unfortunately, I would receive a lot of false triggers when the meter was exposed to direct sunlight, so I covered the whole meter with a grey bucket zip-tied in place.  I’m not sure how well the utility may like this – perhaps I should put a sign on it to indicate what’s going on in case they stop by.

Counter Schematic

I may try to post pictures later.