Previous Articles »
« Recent Articles

Windows and Embedded Development

Saturday, October 22, 2011 by darco

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?

Radio Frequency URI

Friday, September 30, 2011 by darco

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>
Read the rest of this entry »


Sunday, September 25, 2011 by darco

ARISSAT-1 SSTV Image (Filtered)

Hey look! It's Earth! I think...

This is the first SSTV image I've ever captured. It was sent from ARISSat-1 at 2011-09-25T18:47:11Z and recorded on my computer using a Yaesu VX-8DR and a homebrew j-pole I recently constructed. Yeah, it looks like crap, but... well... IT'S FROM SPACE!

The reason it craps out at the end was because of doppler shift, and the fact that I'm not dynamically tuning my radio to account for it. I guess I need to get a computer-controlled radio next... And a good yagi.

Amateur Radio

Friday, September 9, 2011 by darco

The home automation project that I've discussed a lot on this blog got me interested in how radios work. When I started it all seemed a bit magical.

Then I went ahead and built the IM-Me Spectrum Analyzer, and I was fascinated. I could now see how the radio spectrum was being used in real-time. I started to wonder, what were those blips around 430-460MHz? It turned out a large chunk of it was an amateur radio band. My curiosity piqued, and I knew what had to happen next.

I got my amateur radio license (Callsign: N6DRC) a few weeks ago, and I love it. I highly recommend anyone even remotely interested in electronics, radio, or public safety to go out and get at least the technician-class license. Best twelve bucks I ever spent.

From the public safety perspective, when TSHTF and your power is out and your cell phone doesn't work the hams are the only ones who can communicate easily. I don't want to be just another casualty who is at the mercy of others when the big one hits. I want to know what's going on around me in an emergency situation, and be able to let others know when I or someone I care about needs help.

From the curious engineer perspective, the deeper I dive into this stuff the more parallels I see with the world around me and the projects I've been working on. For example, a new approach for the soil moisture sensor might be to treat the length of the sensor as an unterminated transmission line. My measuring the time and magnitude of the reflections I should be able to calculate the dielectric constant of the soil and thus determine its moisture content. Maybe.

Square One

Thursday, September 8, 2011 by darco

bad-sensors/DSC_2389 It has been a few weeks since I have updated this blog about how the whole soil moisture sensor project is going. I've had lots of ups and downs along the way, and I've learned quite a bit more about electrical engineering and materials science that I didn't have a firm grasp of before I started this project. Unfortunately, I've encountered a significant technical setback which necessitates abandoning my current approach and all but starting over.

Read the rest of this entry »

Hackable Christmas Lights at Costco?

Thursday, September 1, 2011 by darco

I've heard that the hackable RGB christmas lights I blogged about are once again available at Costco. I haven't had a chance to run by Costco in the past few days, but when I head over to pick that up I'll be sure to grab a string and see if it uses the same protocol. Who knows what other sorts of hackable holiday cheer they might have.

I've run out of Tazo Chai Latté mix, so a Costco run is imminent. *twitch*

Capacitance Sensing

Thursday, August 4, 2011 by darco

Update: After building out a few more boards and doing some additional testing, it seems as though things aren't quite as bad as I originally portrayed them in this post—the boards I made may still be usable as designed, albeit with a few quirks. However, I will be incorporating the design changes outlined below into the project for future devices to improve the consistency and performance.

After building out a few of the soil moisture sensor boards, I'm starting to think I may have been a bit hasty in ordering forty of them. The biggest problem I'm running into is noise. Lots of noise. Practically unfilterable noise, the nature of which is entirely dependent on material the sensor is embedded in. It is as if the sensing plane is acting like a large antenna, picking up all sorts of crap.

Some noise is actually a good thing, because it acts as a dither. allows me to super sample the capacitance and get a filtered result that is of a higher resolution than that of a single sample. Without any noise supersampling would not yield any better results.

But this kind of noise is on a whole different level. About the only thing these sensors (as currently designed) are good for at the moment is as a touch sensor... Which happens to be exactly what the capacitive circuit I borrowed from the QTouch guidelines was originally intended for.


QTouch capacitive sensing channel schematic from the Atmel QTouch Library User Guide.

I am not an electrical engineer, so when the QTouch sensor design guide said on page 2-1 that the measurement circuit was capable of measuring capacitance down to a few femto-farads, I believed it—even though the circuit made no sense to me (See figure above). Initial testing seemed to indicate that the method did work to some degree, so I went with it. I now see that was a mistake; I should have trusted my instincts more.

This is not to say that my original capacitance sensing circuit (which simply discharged a capacitor thru a known resistance) was any better. Looking back at it, I think that it would likely be just as susceptible to noise as the QTouch design.

In order to keep moving forward with this project, I've come up with an entirely different circuit that should hopefully prove to be far less noisy than the previous methods:


New low-noise capacitive sensing circuit.

The circuit actually works in the way that I originally imagined how the QTouch sensing circuit would work. What we do is charge up the capacitor we want to measure using a pulse, and then wait a little bit for this charge to distribute to the holding capacitor. We calculate the capacitance of the target by counting the number of pulses it takes before the sensing pin goes high.

While we end up operating this circuit in close to the same way as the QTouch method, the results are interpreted a bit differently. For example with the previous capacitance measurement fewer pulses meant less capacitance and more pulses meant more capacitance. In this circuit however the opposite is true: fewer pulses means more capacitance, and more pulses means less.

There are three things I really like about this circuit:

  1. It effectively has a built-in low-pass filter, so it should be less prone to noise.
  2. It doesn't increase the part count.
  3. There are upper and lower bounds on the capacitance reading, whereas with the previous method there was no upper bound on the number of pulses required to measure a capacitance.

Unfortunately the resulting pulse count does not have a linear relationship with the actual capacitance. This means that some sort of compensation (via a look-up table or other methods) will have to be performed to get a linear output.

New sensor orientation

Since I'm going to be re-designing the board yet again, I might as well make a few more radical changes, right?

One of the problems with this sensor is the fact that the electrodes are not only parallel, but they are also co-linear to each other. Ideally a capacitor is made like a sandwich: two electrodes with a dielectric between them.

While the "ideal" case might not be such a good idea in this case, I think I may have come up with a compromise: have two circuit boards that slide together so that the electrodes are oriented 90° from each other. I took a Dremel to two of the boards to start to put together a prototype:


Dual-board moisture sensor prototype. Work in progress.

As an added bonus, this sensor should be significantly more sturdy than the previous single-board design, while being more sensitive. Of course, it could just not work at all. We'll see.

Read the rest of this entry »

Moisture Sensors Arrive

Wednesday, July 20, 2011 by darco

The circuit boards for my soil moisture sensors arrived yesterday. I ordered four panels with ten sensors each, for a total of forty sensors. I ended up receiving five panels—25% more than I ordered—at no additional cost.


I populated one sensor last night and put it thru a quick smoke test this morning. No smoke, and it seems to be working fine. Unfortunately I won't have time to populate any more until next week.

The carefully observant will notice that despite my previous claim that I had created the "final" layout weeks ago, the layout has indeed changed once again. It turned out the edge connector wasn't the best idea, so I've settled on a shrouded locking 3x2 right-angle header for the connector.

Previous Articles »
« Recent Articles