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. 

Spectrum Analysis of a Smart Meter

We got our smart meter installed this past week, so of course I had to take a look at the RF signals coming from it. The results were very interesting!  I used the spectrum analyzer on an Anritsu S412E LMR Master™, which is fast enough to capture the 20 - 200 millisecond pulses in the 902 - 928 MHz ISM band coming from the PG&E electric smart meter (the meter itself was actually made by GE).

Summary of my findings?  As I expected, there's far more RF energy in the air from the TV and FM broadcast bands and cellular signals than from the smart meter's short-duration pulses.  You have to really hunt for the smart meter signals, which are buried underneath a lot of other stronger signals.