23.12.2011 9:02

I got a few questions about what I'm working on at my new job at Jožef Stefan Institute, so here's a short story about that.

Approximately a month and a half ago I joined the team working in the laboratory for wireless sensor networks, or SensorLab as people around here call it. They have been developing their own software and hardware for a year or so and have come up with a impressive collection of tools for gathering data from a large network of small sensor nodes.

VESNA core board, two radio boards and a debug/prototyping expansion.

At the core of their efforts was the VESNA platform, a wireless sensor network node with cute female name from Slavic mythology. It's a small, modular microcontroller system built around an ARM Cortex M3 chip from ST microelectronics. At the center is a core board with the CPU, non-volatile storage and power supply. Then there's a connector to the right that connects to one of a collection of radio modules that take care of different communication needs. Finally there's an Arduino-like general purpose shield connector on the top and bottom that can carry application-specific expansion modules, for instance with specialized hardware for sensors that cannot be served by the general purpose IO and instrumentation amplifiers on the core board.

When you are mounting hundreds of such boards in places that were never meant to carry any electronics, getting power to each sensor gets problematic very fast. So one of the main features of VESNA is power provisioning. In addition to requiring very little power to begin with, the core board carries a very versatile power supply that is capable of efficiently harvesting power from a solar cell or a range of external voltages. You can also connect a rechargeable battery to it and it will weather through nights or other power shortages.

Since you can't yet depend on having UTP cables at each and every place, communications are mostly based on radio (hence the wireless in wireless sensor networks). Radio boards are built around several multi-purpose chips that can use a number of regimes in the ISM bands, from proprietary schemes to IEEE 802.15.4, from star topology to mesh networks.

On the software side there's also a lot of interesting things happening. Guys and girls at SensorLab have been developing their own C library for VESNA peripherals, which you can use to compile and run bare-bones programs on the CPU. For simpler applications there's an Arduino compatibility in the works while heavier applications might use a port of the Contiki operating system, which allows you to access sensors through web-friendly REST interfaces on a 6LoWPAN network.

An the best part of it is, most of the things I described are going to be released under a free, open source license in the following year, since we are hoping to build a lively open hardware community around this project. The internet of things is the new buzzword you know and there are plenty of IPv6 addresses to go around. We think VESNA will help you make good use of at least a small part of them.

Posted by Tomaž | Categories: Digital | Comments »


19.12.2011 15:05

It's almost that time of the year already. You know, to chat with fellow hackers over a bottle of Club Mate, pile up a fresh amount of sleep deficit and draw a line under this year's happenings at talks and workshops.

28C3 - behind enemy lines

Yes, this means that in exactly one week I'll be flying to Berlin to attend the 28th congress together with the same group of guys from Kiberpipa as last year. This year I hope to bring a bunch of portable radio hardware with me to test and experiment with: the 433 MHz sniffer is certainly going into the bag, as well as the Funcube dongle and most likely also a handful of wireless sensor hardware I'm working on at my new job.

Perhaps I'll manage to schedule a lightning talk about some of that stuff. Anyway, if ISM band transmissions hacking sounds like fun to you, give me a call. In addition to all the usual means of communication I'll also be accessible via the 9-8087 extension on the Eventphone GSM network.

Posted by Tomaž | Categories: Life | Comments »

Open source hardware licenses

16.12.2011 9:52

Communities developing modern open source and free (as in freedom) software now have more than 30 years of experience behind them. During this time software licenses like the GNU General Public License, BSD license and a small handful of others have seen such wide use that they became de-facto standards when it comes to releasing code to the public. Although there are still some gray spots regarding legal issues, as a document from Free Software Foundation Europe nicely explains, the community has developed some stable views on what is acceptable and what isn't under those licenses.

Open source hardware logo

Logo by Mateo Zlatar

The situation is somewhat more complicated in the field of hardware. Hardware mostly falls outside of copyright law that makes software licenses possible. There is a fuzzy line between uploading a RTL design to a software-programmable circuit and etching a printed circuit board based on a schematic, but generally imposing restrictions on manufacturing and distribution of physical objects falls under the domain of patent and trademark law. While in most countries the author of a creative work is automatically granted copyright free of charge, patents and trademarks that would allow you to set any specific rules for use of your design documents are neither automatic nor cheap.

If you look around, practically all popular open hardware projects ignore this issue and simply apply either a software license like GPL or a Creative Commons license to their design documentation: for instance, RepRap decided on GPL, while Arduino uses Creative Commons Attribution Share-Alike for their board designs. This doesn't always have the desired effect though. For instance when someone sells products based on a modified design under GPL, he doesn't need to provide the modified documentation nor credit the original author, since he is not distributing their copyrighted works.

There are attempts to address this issue. First of all, there is now a draft of the Open Source Hardware Definition that aims to be what Debian Free Software Guidelines are for software, outlining the basic requirements that need to be satisfied before a design can be called open source. There are also several license texts that attempt to focus specifically on hardware projects. Ones that appear the most complete and widely used are the TAPR Open Hardware License from the Tuscan amateur packet radio group and the recently released CERN Open Hardware License from the European organization for nuclear research.

Both of these, however, contain some terms that might be surprising for anyone used to software licenses. For instance, both require you to make some reasonable effort to contact the original author or authors when distributing derived works or manufacturing products based on their designs. While a nice provision for one-man efforts, this puts an upper bound on how large a project using this license might become. Imagine trying to contact all the contributors to the Linux kernel today. TAPR has even more terms that limit its scalability. For instance, it specifically requires attribution on PCB artwork, which can waste costly PCB area. It also requires you to distribute "before" and "after" versions of all modified files, which can again become quite unwieldy when you have to distribute the whole history with every copy.

On the other hand, what I miss in these licenses is stronger terms for practical modifiability. While GPL clearly defines that source code must be in the preferred form of the work for making changes in it, TAPR merely says that you must also include open format versions (such as Gerber, ASCII, Postscript, or PDF) if your tools can create them. The openness of the format does not however make the design easily changeable. In fact, all of the listed formats can be compared to a compiled binary in software world. CERN license makes no such constraints at all, but then, neither do Creative Commons licenses, so all are more like the permissive BSD license than the GPL of the software world in that respect. Modifiability of the hardware design files is arguably less important than having source for a binary computer program, since even a PNG image of the schematic will enable you to understand the design, but if you want to have a lively community around your open hardware project, I think keeping designs easily modifiable is a must.

Given all of the above, I find that currently existing open hardware licenses still fall short of specifying good terms for redistribution of the documentation. While they do state the top most requirement for open hardware, that documentation for physical products must be shared, I think it's questionable whether that is actually enforceable in the way specified. From what I've seen, CERN license shows the most promise of addressing these issues and I will closely follow the happenings around it. In fact they already have a list of issues to be addressed with the next version that more or less covers all of my concerns, so I'm keeping my fingers crossed. In the mean time, I'll probably stick to GPL or Creative Commons for my projects involving hardware designs.

Posted by Tomaž | Categories: Life | Comments »

Funcube spectrum analyzer

10.12.2011 11:49

I've written before about the Funcube Dongle Pro. Apart from receiving satellite telemetry and amateur narrow-band FM, it can also be useful as a poor man's spectrum analyzer.

I'm not talking about doing a Fourier transform on the baseband data. At around 80 kHz that's not really useful if you want to see the big picture, for instance when measuring spectrum of a DVB-T transmitter with a channel width of around 6 MHz.

What you can do however is to emulate a swept-tuned spectrum analyzer. You sweep the Funcube's tuner through the range of frequencies using steps of several tens of kHz and pipe the baseband stream to a software power detector. Then you can plot the received signal strength against the frequency and get a fancy graph like this:

Spectrum of a DVB-T transmitter measured using FCD

Of course, there's a catch. Funcube Dongle uses an audio codec that is connected to the user space through the ALSA interface. This means that after you change the tuner frequency the sampled data needs to go through plenty of big buffers before it gets to the detector.

So while the actual hardware might settle very quickly to the new frequency (I don't have data for the E4000 chip used in FCD, but other comparable tuners have channel change times in the order of milliseconds), software buffers limit the minimum sweep time.

For instance, this is what becomes of the picture above when you are not waiting enough time for the buffers to flush between (random, in this particular case) frequency hops.

Noisy spectrum of a DVB-T transmitter measured using FCD

It takes around 5 minutes to draw such a persistence plot with the bandwidth of 20 MHz, 50 kHz hops and 10 passes. So don't expect to get anywhere near the theoretical limit for sweep time versus resolution bandwidth.

You can get the Python source from the git repository below. It requires a recent GNU Radio installation, FCD source block and matplotlib.

$ git clone
$ python fcd_scanner/ --help
Usage: [options]

  -h, --help            show this help message and exit
  -d DEV, --device=DEV  Use Alsa DEVICE for FCD access
  -c FREQ, --center=FREQ
                        Center frequency in kHz
  -s SPAN, --span=SPAN  Scanning bandwidth in kHz
  -t ST, --sweep-time=ST
                        Time for one frequency sweep in s
  -g GAIN, --lna-gain=GAIN
                        LNA gain in dB (default 10)
  -p STEP, --step=STEP  Frequency step in kHz (default 25)
  -n N, --pass=N        Number of passes (default 1)
  -o FILE, --output=FILE
                        Write measurements to FILE
  -l, --line-plot       Draw a real-time line plot
  -e, --pers-plot       Draw a real-time persistence plot
Posted by Tomaž | Categories: Code | Comments »

HP EliteBook 8460p

03.12.2011 23:14

With a new job comes a new work laptop. Last week a shiny new Hewlett Packard EliteBook 8460p was waiting for me on my desk at Institute Jožef Stefan.

Plush penguin on a HP EliteBook 8460p

From the outside it's one of the prettier PC laptops and it's hard to say HP industrial designers haven't looked at Apple for inspiration. Aluminum case dotted with small white LEDs, chiclet keyboard, black bezel around the screen, a round HP logo on the back of the display. If you've seen a MacBook Pro you can probably see the similarity. However, good looks don't necessarily mean good design and HP made some weird decisions that I find hard to believe for a machine that costs more than 1600 €.

First of all, I might say quality control seems a bit lacking. Left and right mouse buttons were out of level just enough to look sloppy. The "a" key keeps falling out. There's something wrong with the latches on the docking station since the cracking noise they make when I take the laptop off always makes me cringe. There are also some unfortunate design decisions: each time you pick up the laptop from the table you basically lift it up by the DVD drive door, which I fear is not good for its longevity. The Apple-like LEDs that shine through (laser-drilled?) holes in the aluminum are quite hard to see unless you bend down to the table and look directly at them.

What about the software side? Linux Laptop Wiki has some general information that gives a good overview of Linux support for this laptop's hardware.

Out of the box the disk had all 4 primary partitions already used. Sadly I had to retain the Windows installation, so I only deleted two partitions at the end of the drive that looked like they contained some HP restore and diagnostics software. Debian Squeeze installer then shrunk the remaining NTFS filesystem without further problems and Windows seemed to have survived the operation without any noticeable damage.

Getting the installer to boot however did take some experimenting: the laptop has 4 USB ports and will happily boot off a USB key in any of them. However for some reason all except one on the right with a thunderbolt icon are turned off after the boot. So unless the installation USB key was in that drive, the installer couldn't find the installation media. Funny, since after installation all USB ports work without problems.

To get the Radeon HD 6470M running in xorg I had to install a newer kernel from Squeeze backports (linux-image-2.6.39-bpo.2-amd64) and a newer Radeon driver (xserver-xorg-video-ati 1:6.14.2-1). The card also requires non-free firmware, which is shipped separately in the firmware-linux-nonfree package. Without it you will only get military-grade noise on the LCD panel. For 3D acceleration you also need libdrm-radeon1. With this setup everything seems to work fine except setting the display brightness (there's a kernel bug already reported): manual setup through the sysfs is ignored although the interface is there and I don't even know how to approach the ambient light sensor.

By the way, I've heard complaints about the low quality of the LCD. Mine looks great and makes my EeePC 901 look pretty dim in comparison.

Regarding other periphery, there is not much to say. Wi-Fi works with Intel drivers and requires firmware-iwlwifi. Compared to the Thinkpad monstrosity the dock is only a bunch of hot-pluggable USB devices, which means no additional headaches there. Web-cam for some reason isn't detected automatically and you need to insert uvcvideo kernel module manually for it to work.

The power consumption hovers around 25 watts at idle, which is 10 watts more than when booted up in Windows. With that battery lasts a little bit more than 2 hours. This might have something to do with that kernel PCI Express power consumption bug. Setting power saving profiles on Radeon doesn't affect the battery drain which makes me suspect that power management doesn't work there either. Also, GNOME power manager crashes because of an empty second battery bay. I've written a patch against the version shipped in Debian Squeeze, but I'm not that optimistic it will get applied, since it's now sitting in the bug tracker right next to another patch I've made 3 years ago.

I should also mention the weird phenomenon where the computer freezes for several tens of seconds sometime after boot. There are no kernel messages logged about that and it doesn't seem to affect the running processes. I've seen such freezes on my old Thinkpad and on the EeePC, but they were always connected to IO contention. These freezes occur on an otherwise idle machine and the HDD light remains off, which makes me think they have some other cause. Also, a colleague with the exact same hardware and the latest Ubuntu version isn't seeing this, so I'm guessing it has something to do with my setup.

As you can see, after a week with this machine I have very mixed feelings about it. On one hand the aluminum case gives you a solid feeling. I love the dead simple screwdriver-less access to all the components inside, Linux support is pretty good and of course I don't have any complaints about the performance either. But seriously, shipping a laptop in this price range with a broken keyboard, dock and cheap-looking track pad?

Posted by Tomaž | Categories: Code | Comments »