I've been missing a good function generator for a while now. Over time I've accumulated an assortment of various ad-hoc 555 oscillators and microcontroller hacks I've cobbled together whenever I needed to generate some kind of a signal to test a circuit I worked on. For a while I've been considering joining all of these in one box and slap some kind of an interface on top. I even bought a nice back-lit LCD display and some buttons for the front panel.

Then at one point more or less by accident I stumbled upon this low-end line of function generators from GW Instek and they looked cheaper and more versatile than what I was building myself. From what opinions I could find on the web about it they mostly appeared positive. Last week when it came in stock in this corner of the world I bought one.

After a couple of hours of playing with it I can say it's a perfectly functional instrument that as far as I can see works as specified. However as you might expect, the fact that it costs around 150 € less than the next cheapest arbitrary waveform generator definitely shows itself.

Interestingly, my complaints mostly have to deal with the user interface. For instance, the first thing I noticed is that there is no visual indicator whether the display is set to show signal amplitude for a 50 Ω or high-impedance output termination. Since this means a factor of two in output voltage level a wrong setting can easily be fatal for some circuits. I guess resetting to high-Z setting before turning off the generator would be a prudent habit to keep.

One thing that sold this device for me is the USB connectivity. After being spoiled by the equipment I have at work, I missed being capable of running some automated tests for projects at home. While the manual doesn't mention the word USBTMC anywhere, the remote-control commands look suspiciously identical to the venerable industry-standard GPIB language.

When I connected AFG-2005 to my computer, first thing I noticed is that it doesn't actually use USBTMC protocol. Instead, it's behaves like a serial modem with USB ACM interface. As far as Linux user space is concerned, this doesn't seem to make a big difference - both kernel drivers expose a simple character device for interaction with the device. For USBTMC I know that when the write() syscall returns, the device has already accepted the command and you can expect it will be giving the signal you programmed. But I'm not sure whether this also holds in this case.

The implementation of the protocol is somewhat buggy though. First of all, commands require a terminating ASCII line feed (\n) character, which isn't the case with USBTMC devices. Invalid commands are simply ignored - there are no error or diagnostic messages at all.

My device identifies itself like this for the *IDN? command:

GW INSTEK,AFG-2005,SN:EN810021,V1.11

It's quite easy to crash the instrument's firmware by feeding it malformed commands. In that case the front panel stops working and the only way to restore it back to normal is by using the hardware power button.

The front panel display itself is somewhat sluggish and if you issue a lot of commands through the USB it might take a while to catch up with all the settings, even though if you watch the signal generator's output you can see they are applied much faster. The multi-purpose knob has similar issues and if you turn it too fast the values start jumping around instead of going in one direction (this seem to be a common issue though - I've seen a lot of different devices have a problem with that).

Arbitrary function generator works nicely and can be easily programmed from a PC using a DATA:DAC command. What I don't quite understand is the syntax there. In contrast to other instruments I worked with, the manual says that the first argument is the Start address of the arbitrary waveform. It gives an example where this address is 1000, but that doesn't seem to work at all with my instrument. The only address where the ARB output works as expected is 0. Using other addresses I either get garbage output with no correlation to what I wanted to do or crash the firmware.

Arbitrary function generator has a 20 MHz maximum sampling frequency and firmware allows you to fully exploit that, even when the frequency of the signal exceeds 5 MHz maximum for pre-programmed waveforms. The results in that case are less than perfect of course. The most obvious problem is the significant DAC jitter. Here is how a square wave looks like at 10 MHz:

In conclusion, this instrument gives you quite a lot of value for its price. But unsurprisingly, it's not on the level of instruments that have a few zeros more on the left of the Euro sign. I can't stop myself thinking though that a lot of these problems would take a simple firmware patch to fix. If only the manufacturer would provide source and simple means of reprogramming.

It sounds strange, but analog FM wireless microphones (the kind you find in studios, theaters and soon-to-be-restaurants) are one of the obstacles in the efficient re-use of the UHF band that has been freed with the digital switchover. They operate in the same frequency band as the now silenced analogue TV broadcasts, but on the other hand have never been well regulated. While locations and frequencies of TV transmitters are well known, microphones can appear on a lot of different channels and practically in any location.

New devices operating in the TV white-spaces can't be allowed to interfere with them, so they either can't use frequencies where microphones appear (leading to unused spectrum) or they must detect them using spectrum sensing. Reliable and energy-efficient detection of wireless microphones at low signal levels is an open research topic.

To test different ways of detecting microphones, IEEE has come up with simulation waveforms that can be easily reproduced on lab equipment and are reasonably similar to what microphones transmit in real-life usage. They simulate a silent microphone, microphone used with a soft voice and microphone used with a loud voice by frequency modulating a sine wave with different baseband frequencies and deviations (described in this Word document).

For example, here's how a soft voice simulation looks like on a spectrum analyzer when transmitted by a big and expensive Rohde&Schwarz vector signal generator. This is a 3.9 kHz tone modulated using a 15 kHz deviation:

And this is the same signal transmitted with an USRP N210:

As I mentioned before, VESNA also has some signal generation capabilities. This is how it looks like when the signal is simulated using a direct digital synthesis algorithm and a 4FSK modulator on the CC1101 transceiver:

The order-of-magnitude in price difference in hardware shows itself well enough here as transmission from VESNA obviously differs quite a bit from the desired. But still it's good enough for some detection experiments and of course, you can't have a USRP mounted on every light pole.

Although I haven't yet done detailed measurements, VESNA's transmission actually does seem to comply with FCC's requirement regarding spurious levels for wireless microphones (but not with more stringent European ETSI regulations).

The direction browsers and web technology are moving these days truly baffles me. As usual in the software world, it's all about piling one shiny feature on top of another. Now, I'm not against shiny per se, but it seems that a lot of these innovations are by people that haven't even took an hour to look at the already existing body of knowledge and standards that has accumulated over the years. With the frenzy of rolling releases and implementation-is-the-standard hotness, it's not even surprising that those are then implemented by browsers before someone with a long enough beard can stand up and shout Hey! We already thought of that in this here RFC.

Take for example all the buzz about finally solving the problem with authentication on the web. Finally, there's a way to securely sign into a website without all the mess with hundreds of hard-for-me-to-remember yet easy-to-guess-by-the-cracker user name and password combinations. Wonderful. Except that this exact thing existed on the web since people did cave paintings and used Netscape to browse the web. It's called SSL client side certificates and, amazingly, worked well enough for on-line banking and government sites even before the invention of pottery and cloud-based identity providers.

But that's just the most glaring case. Another front where this madness continues is pushing things from the old HTTP headers to the fancy new HTML5. Take for example a proposal to add a HTML attribute that defines whether a browser should display something or save it to disk by default. This functionality has existed for ages in the form of a HTTP header, yet this is somehow dismissed as a server-side solution (what does that even mean?).

I wonder how many web developers today are even aware that there exists a mechanism for a client to tell the browser which language the user prefers (but we most certainly need the annoying language selection whole-screen pop-up-and-click-through!). Or that the client can tell the server whether it would rather have a PNG for downloading or a friendly HTML page for viewing in a browser (meh, we'll just fudge that with some magic on-click Javascript handlers).

Now I can see someone laughing and saying how ridiculous this idea is and if I have ever even tried to use one of those ancient features. No it's not, and I have. It's consistently painful. But it's only so because for some reason, browsers long ago decided to make the most horrible interface to such functionality imaginable to man and then forgot to ever fix it. Mostly it's hidden 10 levels down in some obscure dialog box and if banks wouldn't give you click-by-click instructions on how to import a certificate, 99% of people would give up after a few hours and continue chiseling clay tablets. Now imagine if a tenth of time spent in reinventing the wheel would be spent just improving the usability of existing features. Why can't I go to a web page and get a prompt: Hey! This web page wants you to login. Do you want me to use one of these existing certificates or generate a new, throw-away one?. World would be just a tiny bit better, believe me.

In the end, I think modern browsers have focused way too much on improving the situation for the remote web page they are displaying and neglected the local part around it. And I believe this direction is bad in the long run. Consider also the European cookie directive. I'm pretty sure this bizarre catch-22 situation where web pages are now required to manage cookie preferences for you would not be needed if browsers provided a sane interface for handling these preferences in the first place. My Firefox has three places (that I know of!) where I can set which websites are allowed to store persistent state on my computer. Plus it manages to regularly lose them, but that's a different story.

QEMU emulates a VESA-compliant VGA card that supports a static set of standard and a-bit-less-standard display resolutions. However, this set is far from universal and for example doesn't include the wide-screen 1600x900 resolution on my laptop. This means that running a virtualized OS full-screen would always stretch the display somewhat and give a blurry image.

Here's how I fixed that. Following instructions should pretty much work for adding an arbitrary resolution to QEMU's virtualized graphics card (but only when using -vga std). They are based on this patch.

Fetch QEMU source (I used 1.4.0) and edit roms/vgabios/vbetables-gen.c. For instance, to add 1600x900 I applied this patch:

--- qemu-1.4.0.orig/roms/vgabios/vbetables-gen.c	2013-02-16 00:09:22.000000000 +0100
+++ qemu-1.4.0/roms/vgabios/vbetables-gen.c	2013-05-04 11:46:55.000000000 +0200
@@ -76,6 +76,9 @@
 { 2560, 1600, 16                     , 0x18a},
 { 2560, 1600, 24                     , 0x18b},
 { 2560, 1600, 32                     , 0x18c},
+{ 1600,  900, 16                     , 0x18d},
+{ 1600,  900, 24                     , 0x18e},
+{ 1600,  900, 32                     , 0x18f},
 { 0, },
 };

Now re-build the VGA BIOS binary image (apt-get install bcc first):

$ cd roms/vgabios
$ make stdvga-bios

QEMU's make install will not install the image you just built. Instead, it will use an already built binary they ship with the source. Therefore you have to install it manually:

$ cp VGABIOS-lgpl-latest.stdvga.bin $PREFIX/share/qemu/vgabios-stdvga.bin

Of course, replace $PREFIX with the prefix you used when installing QEMU (/usr/local by default). Now when you start a virtualized OS you should see the resolution you added to vbetables-gen.c (for example as reported by xrandr or under Screen resolution in Windows).

I was wondering how much running a Kindle as an always-on, underpowered Debian box was costing me in terms of electricity. So I plugged it into one of the Energycount 3000 devices and monitored its power consumption over the last 4 days. This took into account the power consumption of the Kindle as well as the efficiency of a small Nokia cell phone charger I'm using to power it.

ec3k reported an average power of 1.0 W (and maximum 2.6 W). Dividing the watt-seconds count with time also yielded 1 W to three decimal places. This nice round number makes me suspect that it's due to limited precision of the measurement, but let's consider it accurate for the moment.

1 W is equal to 0.72 kWh per month. With the current prices I'm paying for electricity this costs me 0.083 € per month. For comparison, a cup of synthetic-tasting coffee from a machine at work costs around twice as much and running my desktop machine all the time would be around a hundred times as expensive.

Thanks to my previous posts about Amazon Kindle, I have another broken specimen on my desk now. This one seems to have experienced an interesting battery failure.

Kindle's battery has 4 terminals: ground, a positive terminal for power and SDA and SCL pins for I²C communication with the integrated battery management circuit. On a normal battery, the positive terminal is around 3.7 V above ground, depending on the charge level of the Li-ion cell and the I²C lines are on ground level, because they need external pull-ups.

This broken battery however has the positive terminal at 0 V compared to ground terminal while the I²C pins are at -2.5 V. I can't imagine what kind of failure mode could cause pins to go lower than ground, unless the polarity of the cell got reversed somehow. I don't see any way how a failure in the battery management circuit or a loose connection somewhere could cause such readings. I'm pretty sure it's not an artifact of my multimeter either, because the battery can draw some milliamps of current from the ground to one of the I²C pins. For the record, this looks like an original 1830 mAh battery. Date of manufacture is April 2011 and type is 170-1032-01 Rev. A.

The master I²C interface on the Kindle wasn't damaged though, because it boots and reads out battery state just fine when attached to a different battery. There does seem to be a problem with bad a connection somewhere on the motherboard, because it crashes if I lightly knock on the CPU package. Possibly a hairline crack in some solder joint. But that's a topic for some other time.

Experimental radio equipment on VESNA can be used for more than spectrum sensing. Radio boards based on Texas Instruments CC2500 and CC1101 transceivers can also be used for packet transmission and reception and, perhaps somewhat surprisingly, also as flexible signal generators. These can be used in experiments when you want for instance to introduce a controlled interference in some system or to check if your spectrum sensor is working correctly.

Usually when I'm talking with people about what our hardware is capable of the conversation often starts with amazement at how small the radio part is and then inevitably turns to the question whether VESNA has a software defined radio. I have to answer no, it doesn't, and then there's usually an awkward silence because that seems like a dead-end for any serious research work these days.

True, these transceivers don't provide software access to the undemodulated baseband samples (like for instance USRP does). However they are still amazingly flexible. They offer plenty of reconfigurability and, after you get to know some of their quirks, can be adapted for a lot of weird use cases without hardware changes. If you skip the various high-level digital parts of the chip for proprietary packet format handling there's a flexible front-end in there that allows you to choose between a handful of frequency, amplitude and phase modulators and several options for channel filters and such.

The closest you can come to software defined radio is a transparent continuous transmit mode where you can feed the transceiver arbitrary binary data from the microcontroller and it will simply get modulated and fed into the antenna. There is a catch though, since the chips offer at most 2-bit quantization of the baseband signal before modulation (they were designed for simple digital transmissions after all). This means that you have to get creative if you want to approximate an analog modulation and be ready for plenty of quantization noise.

This is how it looks like on a spectrum analyzer when you run a direct digital synthesis algorithm on the microcontroller that generates a baseband sawtooth frequency sweep and use the amplitude modulator to up-convert it to 2.4 GHz:

Using delta-sigma modulation you can approximate arbitrary waveforms in this way. For instance, you can make a passable simulation of an (analog) wireless microphone transmission using a 4-FSK modulator in CC1101 tuned into the UHF band.

Of course, setting this up takes more work than popping a few blocks into GNU Radio Companion and part of my job is to make it more accessible to people using VESNA and our VESNA-based testbeds. If you're interested in such signal generation using Texas Instruments CC series, some platform-independent code capable of doing this should start hitting the vesna-spectrum-sensor repository on GitHub in the next few weeks.

Multilib is a mechanism in GCC for handling multiple binary versions of a single library that have been compiled using different compiler options. This is useful for instance when compiler options affect the ABI and the linker has to choose the correct library version to link your program with. ARM architecture with its multitude of ABIs and floating point unit options is a prime example where this comes in handy.

Multilib works by mapping compiler command-line options to directories where libraries can be found. For instance, GCC compiled with my fork of summon-arm-toolchain says this about its multilib support:

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard

What this says is that binaries compiled with -mthumb will be linked with libraries that appear under thumb/ and binaries with -mfloat-abi=hard will use libraries under fpu/ relative to the usual library search path.

However:

$ arm-none-eabi-gcc -print-multi-directory -mthumb
thumb
$ arm-none-eabi-gcc -print-multi-directory -mfloat-abi=hard
.

While thumb option seems to work as expected, the hardware-float libraries don't appear to be used. Why is that?

It turns out that multilib is somewhat smarter than what the documentation and -print-multi-lib would lead you to believe. It doesn't just check the options that you give GCC explicitly on the command line but also their default values.

It seems that -print-multi-lib assumes built-in default values for these options. It believes that fpu/ versions have been compiled using ARM, not thumb mode. But since -marm is default, it doesn't print it out explicitly.

However, this GCC has been compiled using --with-mode=thumb, which changes the default to -mthumb:

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/avian/local/libexec/gcc/arm-none-eabi/4.6.3/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.3/configure --target=arm-none-eabi
--prefix=/home/avian/local --enable-interwork --enable-multilib --with-newlib
--disable-shared --with-gnu-as --with-gnu-ld --disable-nls --disable-werror
--with-system-zlib --with-arch=armv7-m --with-mode=thumb --with-float=soft
Thread model: single
gcc version 4.6.3 (GCC)

Multilib is smart enough to know that libraries under fpu/ won't work with code compiled with -mthumb and falls back to the default directory and hopes for the best. So, to get the compiler to use libraries under fpu/, you have to explicitly set it to ARM mode:

$ arm-none-eabi-gcc -print-multi-directory -marm -mfloat-abi=hard
fpu

By the way, the combinations of options and directory names printed out by -print-multi-lib are set using MULTILIB_OPTIONS and friends in gcc/config/arm/t-arm-elf in the GCC source tree.

Here's a small addendum to my previous list of lessons regarding easy debugability of microcontroller boards.

It's not a bad idea to pay a bit of extra attention to the connectors that will be used when developing and debugging software. It's likely these will see much more use than any other connector on the board, especially if the board is also meant for teaching or research like VESNA.

The first concern is that it should be hard to connect it in a wrong way. IDC and similar pin header connectors are popular for JTAG. Use a male part that has a shroud so that it's impossible to connect it when displaced by a pin or turned 180 degrees. That might sound obvious, but when you're debugging that tricky race condition and switching the debugger between three systems on your table late in the evening, the last thing you need is a burned out board because of a misplaced connector.

The other thing that is also worth considering is the life time of the connector itself. While the life time of the part on the board might not be problematic, the part that stays with the developer can be. For VESNA one of the most common reasons to make a trip to the soldering station is a torn wire in the connector for the serial debug console. We use something similar to the Berg connector and that one doesn't really take many connect-disconnect cycles before either wires get torn out or little springs break and the metal part falls out of the plastic housing. It's not always obvious that has happened and again it's a pain to realize after a long debugging session that the reason a board is talking garbage is not due to a bug you're trying to catch but rather due to a broken ground line in your debug console.

Last November I was writing about an issue with 2.4 GHz transceivers that were deployed on street lights as part of Jožef Stefan Institute's testbed for radio communications. Some radios based on Texas Instruments CC2500 integrated circuit seemed to degrade after they were mounted out doors. In the most extreme case, there was almost an -30 dB drop in receiver sensitivity and maximum transmit power dropped to insignificant levels.

The leading theory at the time was that some component has deteriorated over time due to environmental effects. After some initial testing it appeared that the coaxial cable between the radio PCB and the connector is to blame. However having more boards with this issue in the lab showed that in most cases it's not possible to restore original characteristics only by changing the coaxial cable.

I then fired up the soldering iron and did a brute-force approach: on three bad radio boards I manually replaced components one by one, preforming automated tests of the board after each replacement. While replacing the coaxial cable did have a small effect (0.3 dB in the best case), only replacing the CC2500 integrated circuit itself seemed to restore the correct performance. So the suspicion immediately fell on the transceiver chip itself.

Since I did not exhaustively test all radios for sensitivity and transmit power before deployment, I couldn't be sure whether the radios have been bad from the start or whether they degraded due to environment. The fact that only radios that have been deployed out-doors have had this issue pointed to the second explanation, but since more radios were deployed out-doors than in-doors that could have been a coincidence as well.

As a test, I also brutally heated up one of the newly replaced CC2500 chips with a hot air gun. After such test, the radio board had similar symptoms as the boards that were unmounted from the testbed as defective: the digital part of the IC still functioned correctly, but receiver's sensitivity dropped permanently by 33 dB. Unfortunately I did not record the temperature to see how much heating is actually required.

To test the other theory, I set up a long-running experiment on the testbed that recorded received signal strength between neighboring pairs of newly replaced radios 4 times a day between December 2012 and March 2013. If radios were deteriorating over time, I should be able to see the signal strength drop during these three months.

Here are two typical plots of these measurements over time:

As you can see, while there is a lot of variation in the signal strength, there is no obvious downward trend. Variation is probably due to weather and or large things moving around the radios (these are mounted in an industrial zone, so moving trucks and other such things are not an uncommon occurrence).

So, it currently looks like we either mounted already defective radios or they were damaged by a one-time event after deployment (which is hard to imagine). The fact that over-heating damages radios in a similar way may point to an error in manufacturing, although that's not a popular opinion, since these boards were soldered using a lead solder and radio ICs are supposed to support a RoHS process that involves higher temperatures. It's also a theoretical possibility that the radios were damaged during summer (the test above was obviously done over winter months), although again it's very unlikely that sun would overheat the radios.