13 years ago, I published my ThunderHead program. This was something I wrote for myself to bridge two pieces of junk I picked up at a hamfest. I figured I’d publish it on the web in case anyone else had the same combination. Turns out that at least two people in the world do!
Recently, Andre contacted me to let me know that the program was no longer displaying the correct year (August 2004 instead of March 2024). We quickly surmised that this was a bug in the Thunderbolt unit itself but that it could be worked around in ThunderHead. So, I decided to dust off this old project and make an update.
Challenge 1 – Getting the hardware working
A lot has changed since 2011. For one thing, I have moved. I was able to locate most of the pieces of the system (iPaq, cradle, Thunderbolt, antenna) but was not able to locate the power supply nor the DB-9 gender bender required to attach the iPaq to the Thunderbolt. I was able to get a new bender from Amazon. For the power supply I used my bench supply and some square pin leads to (very carefully) simulate the Molex connect. Thanks to tvb at leapsecond.com for posting pictures of what goes where.
Challenge 2 – The build environment
As documented in the original post, the PocketPC requires using Microsoft Embedded Visual Tools 3.0. This is basically a vintage version of Visual Studio. Thankfully I left enough information in my original article to be able to find the ISOs to download from archive.org.
I no longer use Windows as my primary OS. I did try to install Visual Tools 3 on a Windows 10 laptop I have but no dice. So, I decided to use UTM to run Windows XP inside of a virtual machine on my M1 Macbook. Yes, I get the irony of using an ARM to emulate an X86 which in turn targets and emulates another ARM.
This was a slow and somewhat painful experience. I was never able to get guest integration or folder sharing working correctly so I used FTP to transfer files in and out of the VM. This was clunky but got the job done. Perhaps a more patient person (or someone who was going to do this more than once) could have figured out that part.
Challenge 3 – Date math
As mentioned earlier, ThunderHead is actually working correctly and displaying the year, month, and day values provided by the Thunderbolt. The problem is that the Thunderbolt is not correctly handling the GPS week rollover that occurred in 2017. Since the raw week and time-of-week values are also provided, it’s a small matter of (correctly) re-computing the date from that data.
GPS time begins at the epoch of Jan 6 1980. Since the C runtime libraries operate in UNIX time (seconds since Jan 1 1970), it should be as simple as:
And using the tm->tm_year, tm->tm_mon, and tm->tm_day values. However, this code would not compile. It turns out that Windows CE uses a subset of the C runtime library and these routines are missing!
So, time to do it the old fashioned way. Five seconds of Googling led me back to leapsecond.com again where tvb posted routines to convert to and from GPS dates in C. I precomputed the GPS epoch as modified Julian date so that only MjdToDate was needed.
Challenge 4 – Trimble did what?
Imagine my surprise when ThunderHead displayed the date as Nov 11 2043. What is going on here?
I should have realized something was amiss when I used the Trimble Thunderbolt Monitor. As you can see from the screenshot below, the week number is 1283. How is that possible if GPS weeks are only a 10-bit number (0 to 1023)?
After much trial and error I decided to read the friendly manual. Page A-56 explains what is going on:
Understanding this, the fix was simple – just mask off the upper 6 bits so the week falls into the proper range again.
Challenge 5 – One last bug
Never underestimate date math. There lies one more problem with this solution. GPS and UTC are two different timescales. In 1980 they were the same, but since that time 18 leap seconds have been added to UTC. This means UTC is 18 seconds “behind” GPS.
As a user, I want to see UTC time. But the date I just computed is in GPS time. This means that at 23:59:42Z every day the date will incorrectly advance to the next day. There are many ways to fix this -few are correct. When working with date code, you really need to keep things simple and succinct. I say that because my date rollover still didn’t work correctly due to a stupid mistake I don’t care to provide details for! Suffice it to say that being able to only test rollover once a day made this project take a little while.
Rolling this altogether, here is what I emerged with:
This routine is called every time a primary packet is received. gpsCycle is a global variable that will need to be changed again in 2038, assuming any of the rest of this still works. I did make a number of other cosmetic cleanups and improvements to the code. After all, I have 13 more years of experience!
The new version can be downloaded from here.
Fuzzy Thinking 