You know how it goes, sometimes. (Maybe.) You get an idea for a thing you want to try, and it's just kind of barely outside of your grasp -- your skills, your knowledge, whatever it is, just don't quite get you there. You take a stab at it, and you get stuck somewhere along the way. Two things can go next here, really, when this happens. Option 1, of course, is that you give up, take whatever you learned from it, and you go about your life. This is an eminently reasonable response that eminently reasonable people have. No shade here, honestly, seriously.

But sometimes, for whatever reason, Option 1 is off the table. Option 2 is insidious, and basically involves the thing plaguing you for years. Lots of years. You come back and take another go at it every once in a while, and maybe you get a little further each time. Or maybe not. Either way, an innocent toy project, more and more, becomes a nemesis. I dunno if this happens to anyone else, but, well, uh, this happened to me. 11 years ago. And out of nowhere, this time around, I have, at last, defeated it.

Around July 2009, I took an intro-to-signals-and-systems class, and decided that, since I had taken a 200-level class on the matter, I clearly knew everything I needed to know on the subject, and that I could probably write a toy to demodulate this signal that Mr. Bellard posted, even without having any DVB-T hardware (or any DVB-T specific knowledge, for that matter). I wrote some very simple tools, and instantly got stuck. I took another swing in August 2009, and didn't have a whole lot more luck; I was lost in a world of Fourier transforms and orthogonal frequency division multiplexing and inter-symbol interference and channel equalization and something was wrong but I didn't know what.

My git history shows that around May 2011, I picked it up again, apparently one Sunday morning at 7 in the morning. I assumed I must've been on a flight somewhere -- that's when I always seem to pick this up. One commit message gave me the hint that I must've beaten myself up pretty good at finding that some of the actual heavy-duty math was basically right, but "...the number of bytes copied per row was incorrect". I put it down for a few months, walking away until October of that year, and then again around Thanksgiving.

Another few years passed. October 2015. Something got me stuck, but I didn't know what. Channel equalization or something like that was back haunting me again; another few years pass. These Trying Times In Which We're All In It Together were filling me with burnout; on a plane to Boston to visit my folks, I had no interest in doing any work that I had committed to anyone else that I'd do, and paging through my disk and looking for a distraction, I found my nemesis again.

You know, the funny thing about projects like these is the sense of anticlimax. Spending 11 years flipping through an opaque specification and a handful of papers to implement carrier recovery algorithms and what-the-hell-ever else. Then, all of the sudden, you run strings, and you get: Ballard's Network; Balears Picture. You've cracked the last piece of it. Anyone else who's heard you think about this project before has long since forgotten, and anyway, it's not anyone else's mortal enemy, it's you that it's been haunting. Sometimes there's that flash, "ok, that was cool. Why in the hell did I do that?"

I did learn a lot. I feel a lot more confident in my understanding of how digital signal processing works, I'll say that. OFDM felt like a magical concept, and even any kind of practical use of a Fourier transform seemed far from my grasp.

All of this is to say, though, that I oughta do this more often. There's this weird void now where this project was. I wonder what I'll fill it with. I've had my eye on trying to understand error-correction codes, and the math behind them; that one's been stalking me for a while, too. There are lots of things that haunt me, really, and have for years. Maybe some of them always will. But knocking off 11 years worth of one of them might just be a symbol for some of the others.

The code is on my GitHub, if you want.

A few months ago, I wrote a little review of the Wahoo ELEMNT BOLT, and a miniature teardown of the software on it. I was surprised to find that it, in fact, ran Android, but that the license compliance story on it was not great. Over the intervening time, though, I've been exchanging some mail with Chip Hawkins, the CEO at Wahoo, and it sounds like they're working on getting the licensing story all fixed up there -- and, to my surprise, that engaging with the enthusiast community is something that they are interested in! So, this post has a short update on some of those discussions, and my experiments so far in modifying the thing.

My initial post led off with this arguably clickbait-like statement that the device was in violation of its myriad licenses, so I think it is only fair to the Wahoo team to give an update on where that stands. As of the time I write this, source isn't available for the GPL components, and attribution isn't in place for the Apache components, but as far as I can tell, Chip and his team are pretty serious about getting this squared away. They have a release pending that has been occupying basically all of their engineering time, which also will have some UI changes; so, for the attribution components, they plan to include those in the new UI, rather than running a fire-drill to retrofit that a branch that is unlikely to see another release again. This makes sense to me. My impression is that the next release will have attributions included, then, and kernel source for that release will go out with it, too. They seem to understand what components they need to release source for, and where to look for other licenses that they need to include. So, my claim is that anyone who wishes to be mad about there not being source available yet, should wait for the next release -- it does sound like they are trying, and have a plan to get into compliance! The Android app already has an attributions tab, which is a good start, and I hope that they get the on-device software squared away soon too.

Chip also gave me some information on doing some hacking on the device, which is exciting. They plan to release a recovery image (for Android people, this is a full update.zip, including boot, /system, and userdata images) along with the next release, but until that is ready, one caveat to all of the following is that would-be hackers must be extremely careful, because there is currently no image available to restore a device from unless you create one, and further, that if you modify the root filesystem, then the device will no longer be able to take over-the-air updates until you restore it from backup.

With all those warnings said, here are some tricks to get you started messing with the device. I mentioned in my previous post that the device had an ADB daemon running, but it wasn't accessible; as it turns out, there is a key shortcut to get access to it! If you press the power button and the up button on the right side at the same time, the ADB daemon should unlock. Chip notes that it's best to press them a few times in a row in order to ensure that the event actually happens; after you do that, unplug the device from your computer, then plug it back in, and you should be able to adb shell in. For me, the ADB daemon was already running as root, but if this wasn't the case for you, I am told that adb root should work.

Since there isn't a recovery image available yet, I recommend that the first thing that you do is to make your own. To get a bare minimum backup of the system image on your device, you might want to run something like for i in boot system recovery nvdata ; do adb pull /dev/block/platform/mtk-msdc.0/by-name/$i elemnt-backup-$i.img; done, which will grab a backup of, at least, everything you need to reflash a known-good bootable configuration onto your device.

Once you have boot and system partition images, you are now in a much safer position to explore the device. The other step that you might want to take is to unlock the bootloader on the device, so that you can flash those images again if you need to. The ELEMNT devices run Fastboot, but they have a very finicky version of Fastboot running on them; as far as I can tell, after every command, you need to unplug and plug the device back in, or else it will not respond to you again. Unlocking the bootloader will wipe any data that you have on the device, so make sure to back up anything that you want (either using ADB, or over MTP with Android File Transfer) before you do it!

To boot the device into Fastboot, turn it all the way off, then hold the "down" button on the right side while pressing the power button. If everything goes well, it will give you a black screen, and present a Fastboot interface over USB. Run fastboot oem unlock on your computer side; you'll get a message like "waiting for user" or something of that nature. When you do, press the power button once, and wait; you'll eventually get a message like "erasing user data...", and then the device will be unlocked. To be sure of that, you can unplug and plug the USB connection back in, and then run fastboot getvar all; in there, you'll see the message "unlocked: yes". When you're ready, you can then run fastboot continue, and your device will continue to boot. If you get yourself into trouble later, you can restore your backup with something like fastboot flash:raw boot elemnt-backup-boot.img, and similarly, fastboot flash system elemnt-backup-system.img.

I had been putting this post off for a while, since I had planned to try to modify the .apk that runs the thing. Sadly, I never really got time to do that. But I did get mail from Chip saying that he didn't have objections to people redistributing modified system ROMs -- and modified BoltApp.apks. So what I'm hearing is that, for the enterprising hacker with spare time, this could be a fun toy! He notes that the launcher is pretty careful about monitoring the main app for crashes, and that there are intents that you can send the launcher to make it happier; I tried decompiling the launcher, but found that the version of Android that runs on the device is not compatible with any of the de-odex tools that are out there. So that also sounds like future work.

Anyway, I'm still using mine. I still wish it would boot faster, and especially that it would restore a paused ride faster. I also wish that it would show me sunset times. But I've put a few hundred miles on mine by now, and it hasn't eaten a ride yet. And that makes it better than my Edge 510.

(click for full writeup)

There is, truly, no kill like overkill. This is a story of how I spent untold tens of hours of engineering time designing and retrofitting an upgrade for the headphones amp that I keep at my desk to support a microphone input, and all for no real good reason. I jumped through contortions at every stage to get there. But, it was fun -- and that's what matters.