deep darc archive

It very much saddens me to discover that the comments table from the MySQL database has for some reason disappeared during the migration process. Poof. Gone. I have no idea what happened to it, but it is gone without a trace. As a result, all of the comments on this website have been lost. This is quite distressing, especially considering the immense value the comment threads on various posts added.

If I somehow manage to recover the comments I will do so, but at the moment it looks like a total loss.

Late last week, my web and email hosting provider decided to switch servers. It was a total cluster-fudge. My server-side email sorting script (via procmail) totally broke. SSH logins were no longer allowed. And let's not even go over the website itself—I couldn't even figure out where it was serving files from.

With my patience running low and my annoyance high, I decided that this was a good opportunity to switch to a VPS at a different company. It has been a slow process, but things are now starting to slowly come back online. Comments are still busted, but I'll get those back online soon.

Anyway, In light of this mess, I hope to totally revamp the website at some point over the next few weeks so that it will be easier to maintain and nicer to look at.

Over a year and a half ago, I put some money into the Hexbright Kickstarter and promptly forgot about it. Earlier this week a box appeared on my doorstep with a brand-new Hexbright Flex, "the world's first open-source LED light".

Notable features:

• Light output over 500 Lumens. CREE XM-L U2 LED.
• TIR (Total internal refraction) lens.
• Waterproof solid aluminum housing.
• Comes with a 3.7v 2400mAh 18650 rechargeable lithium-ion battery.
• USB rechargeable, comes with micro-usb cable.
• USB programmable. It works just like an Arduino...!
• Built-in three-axis accelerometer. (!?)

This flashlight is probably one of the most over-engineered devices I own, and I love it, but I'm sure you are wondering, "It's a f'ing flashlight. Why bother programming for it? There is only so many things you can do with one button and 500 lumen LED..."

Well, I thought that, too. But after trying the factory firmware and a few of the samples, I realized that this is actually a very interesting human interface problem. Just how should a flashlight behave? What behavior makes it feel right? What is the bare minimum that a flashlight needs to be able to do to be considered seriously?

As some of you know, I've been working on a CoAP stack for embedded devices for some time now. Things have gotten to the point now where I'd like see if other people are interested in using it and/or contributing. So today I am announcing that I am making my first release: SMCP-0.6.

I seem to be one of those rare people who don't actually work for Google, but love Google Plus anyway. (We do exist!) In case you've been wondering what I've been up to, your best bet is to follow me there. Unlike my Facebook account, my Google Plus profile is public: so everyone should be able to follow me.

I'll make longer, more detailed, more formal posts here when I have time, but for the vast majority of my posts, comments, and pictures will be available only via Google Plus.

Again: If you want to see the cool stuff that I'm up to, follow me on Google Plus.

A while back I informally proposed the radio-frequency URI scheme, x-freq. I've since written a simple parser for this scheme so that if anyone wants to adopt it that they can do so as easily and correctly as possible. I've released this code into the public domain¹. You can find it here on Github.

The incentive for using this code instead of rolling your own x-freq URI parser is that implementing a correct URI parser is a deceivingly difficult task. I wrote this because I didn't want everyone who wanted to use the x-freq URI in their programs to end up writing their own slightly broken parsers. People invariably tend to not read specs for this sort of thing and just go on their gut. I'd like to avoid that by providing this canonical implementation to the public domain. You are free to use and abuse this source code to your heart's content, with or without attribution.

To put it bluntly, this code is far more likely to be correct than what you would likely write in a short period of time. If you want to use x-freq in your C program, at least use this code as a starting point.

If you happen to find problems, bugs, or want to suggest improvements, check out the project page on Github.

I am really getting frustrated by the fact that the development tools for just about every embedded platform are Windows only. No Linux support, and most certainly no support for OSX. (The same thing applies to amateur radio software, but that is a rant for a different post)

Writing and compiling the code isn't (usually) the problem—GCC and SDCC are both well supported on Linux and OSX, and between the two I can write code for nearly every architecture I would ever need to. The problem I'm talking about is support for devices like programmers and debuggers—devices necessary for actually getting the code onto the chip I'm trying to develop for.

Nothing quite dampens my enthusiasm for a platform like having to fire-up VMWare to upload new code or debug a problem. For example, I recently picked up an STM32F4-Discovery board from ST Microelectronics, which is a development board for their nice 32-bit ARM Cortex-M4 STM32F4 microcontrollers. The board has two USB ports: one connected directly to the STM32F4 microcontroller, and the other dedicated for in-circuit programming. What software do you use to program this lovely demo board? The ST-Link software. What is the only platform it runs on? Windows.

What a waste of time.

I understand that development resources are limited for things like this, and that these companies want to target the platform that they perceive is used by the majority of their customers. However times are changing.

The thing is, the majority of my frustration could be relieved by manufacturers doing one simple thing: document the USB protocols for their programmers and debuggers. If I had this, I could write the programs necessary to program and debug their platforms on Linux (or OSX) myself.

I found this situation so frustrating that I was actually considering snooping the USB traffic of these devices so I could reverse engineer the protocol. I've since realized that there are much more interesting things that I could be doing with my limited free time. If the manufacturer can't even take the simple step of documenting their protocol then their platform just isn't worth my time.

Hey, TI and ST: If you are listening, please make an effort to at least document the USB protocol that your USB-based programmers and debuggers are using. If you could do that, then people like me will fill in the gaps in your development environment for you. Sounds like a good deal, no?

Over the past few weeks, I've been thinking that it would be useful to have a URI format for describing a radio frequency or channel. Such a URI scheme would be useful for hyperlinking to a specific frequency from a link and for exchanging radio frequency lists between devices, programs, and people. (Think QR-codes)

I looked around to see if such a URI scheme had been developed, but I couldn't find anything. Since I think such a scheme would be useful, and I would like to use such a scheme in the future, I decided to go ahead and throw together an informal proposal for what such a scheme would look like and how it would work.

For now the scheme identifier is "x-freq" because it is experimental at this point. If this scheme is ever formalized into a real standard then the "x-" prefix would be dropped. UPDATE: (2014-01-08) According to RFC6648, the practice of prefixing "experimental" protocol identifiers with "x-" is now deprecated. As such, you should just use "freq" as the scheme identifier instead of "x-freq".

Here are the use cases that I would like to be able to specify this this URI scheme, along with some examples:

• A specific single frequency.
  Ex: <freq:107.9m>
• A frequency with a repeater input shift.
  Ex: <freq:145.23m-0.6>
• Split receive and transmit frequencies.
  Ex: <freq:145.93m/435.75>
• Modulation type and other parameters.
  Ex: <freq:145.23m-0.6?m=fm;dv=5;ts=100>