Fixed: Toyota Highlander Brake Light

Note: This post has nothing to do with wireless. 

Toyota Highlanders are well made cars - I bought a 2004 for my wife who later upgraded to a Sienna minivan, so I took the Highlander for myself.  It's at 100,000 miles and still going strong.  However, apparently they have a known problem where the brake lights on one side will intermittently stop working.  I've had people pull up next to me at stop lights and tell me I have a light out, then I get home to find the light is fine.

Then recently the light went out and stayed out.  I replaced the bulbs but they remained out.  Fuses were fine, my trusty Fluke 77 said voltage was getting to the assembly.  Posters in Toyota forums said that dealers are asking $40 - $140 for diagnostic, plus possibly $300 to replace a "circuit board"...?  Sounds like a scam to me.

I did some searching online and found reference to how the contacts on the bulb holder will get compressed and not make proper contact. (Kudos to Berto for the original post and Kujath for the photos.)  Kujath suggested using a flat-blade screwdriver to bend the contacts a bit, but I think a needle-nose pliers works better since you can control the amount of bending.  I did both bulb holders and the lights are working just fine. 

TK-890 Amateur Radio Mod

Over the past weekend a friend of mine asked if I would help him convert his Kenwood TK-890 mobile to work on the ham bands.  I wasn't sure how successful we'd be, since most every online search came up with at best little information or at worst flat out statements saying "Nope, can't be done."  As it turns out, it can be done.  Kudos to Tim K for his notes posted to Radio Reference which gave enough hints to make this happen. 

In general this is how it went.  My friend wanted his radio to work on the Bay-Net repeater system, which operates 443.225 with a +5 MHz TX split.  TX was fine, but RX was giving a steady "beep-beep-beep..." which indicates PLL unlock.

In the PLL section, under the copper foil, are three adjustment pots: A = TC302, B = TC303, and C = TC301.  (Don't ask why they're out of order.)  According to the Service Manual, Pot A sets the PLL for the low end of the receiver range, Pot B sets the high end of the receiver range, and Pot C sets the TX PLL.  The goal is to monitor test point CV with a voltmeter and adjust for minimum voltage during RX and TX.  This requires re-programming the radio's test frequencies to match the band of interest, so you'll need the KPG software and cable. 

Once we had the PLL voltages minimized for RX and TX, I found that the radio's TX frequency was way off, so a frequency alignment was needed.  This again required the KPG software - for some reason we couldn't get the radio into Panel Test/Tune via the control head.  It was easy enough with the KPG, once we realized you need to press "Enter" to lock the modified value. 

Other things like adjusting the BPF and checking deviations should be done.  In the end, the conversion was very easy and the radio is working well on the UHF amateur band.

Android's UTC vs GPS Clock Error

Official Blog: Time, technology and leaping seconds

Google's Site Reliability Team blogged back in 2011 that "Having accurate time is critical to everything we do at Google."  This is an interesting statement, in light of the known issue with Android (i.e. Google) having a known clock error which equates to the difference between GPS Time and UTC Time. 

First reported back in 2009, the Android clock error is the result of the device's date/time being locked to the GPS time signals, but as I discovered and reported in 2010 the GPS driver fails to apply the time correction.  As of this writing the error is on the order of 15 seconds, and will increase over time.  The reason that GPS and UTC time differ is due to various factors, but the largest is that the two time systems are increasingly divergent due to "leap seconds" which are small corrections applied every couple of years to UTC time which attempt to keep the UTC year aligned with the "Solar year". 

You might argue that 15 seconds is not an issue, and for the majority of users this is true.  However for scientists, some professionals, and even amateur radio operators the error can cause huge problems.  In the amateur radio world we use smartphones to track the location of satellites and the International Space Station.  Depending on their orbit, most sats are visible in the sky for at most 15 minutes.  So the error in time means that an antenna pointed at the satellite will be incorrect by at least 3 degrees, possibly more. 

The thread on Android Google Code about this issue has grown quite long over the years.  I asked for users to report if their devices had the bug; over the years every post has been a "yes" with the one exception being a Nexus 4 running Android 4.2.1.  A response from the Android team has never been posted.  It would seem that "Having accurate time is critical to everything we do at Google" is a bit of a stretch - because clearly it's not even worth talking about when the inaccuracy is on Android.

Update: I picked up a Nexus 7 running Android 4.2.2 and find that the time issue is resolved!  So to be fair, the issue existed for a long time but "Jelly Bean" seems to have resolved the issue.