Avian’s Blog

On my recent trip to London I also visited HMS Belfast. I've seen her a few times before from the outside and I remember extensive coverage of this floating museum in one of our popular science magazines several years ago, but until now I never found the time to actually go on board.

The ship is well worth a visit, even if you're not particularly interested in military technology. Although in terms of electrical engineering there's not much to see. Most of the original electronics equipment is gone, supposedly because it was still secret when the ship was decommissioned and opened to public. You can see some racks with radios from afar (with added random sparks, for theatrical effect) and a workplace for a group of veteran HAM operators that still answer the original ship call sign. Original CRT radar displays have been replaced with a surprisingly authentic-looking mechanical simulations using rotating semi-transparent screens.

The engine rooms however more than make up for that. If you're into steam turbines, big brass gages, huge transmissions and other such things, of course. Compared to rooms housing electrical equipment where you have to stay behind fences and closed doors, here you can actually look at the control panels in detail. It's interesting to pause in the cramped spaces between various conduits and try to figure out what is the purpose of this or that instrument.

Above, by the way, is a mechanical analogue computer for calculating ballistic trajectories called Admiralty Fire Control Table.

One other interesting thing I noticed during my stroll around the ship was a distinct lack of chairs for the crew. Except for the rooms where the crew slept and ate, almost all work positions seemed to require standing, as also demonstrated by occasional mannequins in the exhibition. That rang a bell since it's a standing joke about Star Trek that it features futuristic space ships that lack chairs and seat belts. I wonder what the rationale behind their absence was in the case of this quite real battleship. After reading recollections of various battles that were on display in the museum I had the impression that being thrown into the nearest bulkhead was a quite real possibility.

I'm spending a few days in London and a this Sunday Jure and I visited Bletchley Park, the famous home of British code breakers during the second world war who cracked the German Enigma codes. It has been converted to a museum recently and is less than an hour of train ride north from London. I've heard some praise for the place and thought it might be worthwhile to check it out. We were not disappointed.

The place is quite large, quite a bit larger than I expected. Not all of the former military buildings have been renovated though. Those that have been now house a collection about the happenings in Bletchley Park during second world war and the National museum of computing. A few other organizations also have a place there (like the National Radio Centre), but we ran out of time to check them out.

The Bletchley Park collection includes probably just about every model of the Enigma machine ever made in Germany, plus a few that were modified during the decoding effort (one for instance has mechanical counters installed for statistical analysis). There's an impressive collection of other cyphering machines from all over the world as well, although I missed a bit more thorough description of their operation.

All of this fades though in comparison with the centerpiece of the collection - the replicas of code breaking machines that were originally designed and constructed in this place, and later destroyed after the war to conceal the progress British cryptographers have made from the rest of the world. It shows incredible effort made by retired engineers that dedicated years of their life to painstakingly rebuild old machines, often reinventing parts and procedures for which no documentation could be found.

The first replica, a Bombe, is an electromechanical device that basically did an exhaustive search for an Enigma key given a known plain text. It's a wonderful missing link between computers and steam engines. While long strands of wires on one side would fit perfectly well in a backside of a Cray, mechanical insides are made with the best practices of steam engine technology, full of sprockets, cam shafts threaded with thin copper tubes supplying lubricating oil, slowly dripping into pans below.

There is also a nice tribute to Alan Turing, his life and work, including the official apology from the British government for his wrongful prosecution that led to his suicide.

The other replicated machine, the first electronic computer called Colossus, was an even larger effort and supposedly included a public call for old equipment using vacuum tube to harvest for usable electronic components. It's housed in the same building that housed the original and has been tested by decoding a message encrypted using one of the preserved Lorenz encryption machines.

The Colossus is also where the Bletchley Park collection touches the Computer Museum one. That one focuses on the history of computing in Britain and goes from the WITCH computer (first time I heard of a Dekatron tube) to the modern age and is much too large to go into any detail here. It includes everything from big main frames to home microcomputers, with the BBC micro having a prominent place. As with the Bletchley Park collection, it's staffed by engineers that will gladly enter into a lengthy debate about this or that tiny detail of the machines they lovingly care for.

So in conclusion, Bletchley Park was definitely worth a visit and I wouldn't mind visiting it again on occasion, as one day just wasn't enough to go into any detail when examining all the exhibits.

A few days ago Jure brought me his 3rd generation Amazon Kindle. Someone sat on it and the results weren't encouraging. While the plastic frame and the display appeared undamaged from the outside, only a small portion of the screen in the lower left corner showed any signs of life when the device was turned on. The rest kept showing the screensaver image that was displayed when the Kindle was last turned off.

Opening it up was a bit time consuming, but pretty straightforward. I used an old credit card to carefully pry open the plastic latches around the edge. There are many tear down descriptions and around the net, so I wont bore you with details here.

There appears to be a RFID chip taped to the back cover.

After removing the battery, circuit board and the central support frame it was quite apparent what is the cause of the malfunction. Since Amazon just released new Kindle models recently, replacing the display panel isn't really worth the hassle, even though supposedly you can get replacement panels.

So, this Kindle is now basically useless as a book reader, but it still contains a perfectly usable ARM-based embedded computer that is capable of running Linux. Since it consumes very little power it might be quite useful as a small always-on system to have at home. The motherboard alone doesn't seem to boot without the (smart) battery and the display connected to it, so that is a bit unfortunate. But even in the original frame it doesn't take much space and I might simply hang it on a wall somewhere.

Last Saturday was a Software Freedom Day in Kiberpipa, so went with the spirit and jailbroken it and installed a chrooted Debian system. Installing the jailbreak and usbnet took some trial and error since I was not sure which firmware version was last installed and it's hard to navigate the menus without the feedback from the display. In the end I resorted to doing the same procedure on my own kindle in parallel, so that I could see where in the menu the cursor was. Without that I'm not sure how I would be able to type in ";" and "~" characters using the on-screen keyboard. These are required when enabling the usbnet hack.

The built-in software from Amazon takes quite a big chunk of 256 MB of available RAM, so running a chrooted Debian is not really optimal. I'm looking into replacing the built-in firmware with Debian altogether, but for that I first have to find a RS232 adapter so that I can see the serial console from the Linux kernel. Otherwise I'm pretty sure I'll brick the device on the first try.

In December last year I wrote a post about VESNA and how it will be open sourced soon. However now, almost 8 months later, I can't say that promise has been fulfilled. Hardware design still isn't public and, apart from some of my isolated experiments, there isn't currently much to show on the software side either. Considering the amount of feedback I got about that blog post I feel I need to give a follow-up on the status of open sourcing VESNA.

During this whole endeavor I've learned a lot regarding the process of releasing to the public a non-trivial piece of work that has been developed behind closed doors for a significant amount of time in a large organization. On the web you constantly see discussions on how this or that company should release some piece of software under an open source license (famous Nvidia drivers come to mind). Once you actually attempt to do something like that, even on a much smaller scale, it becomes obvious just how naive such calls are.

First of all, there are strictly legal issues. For software that you develop for in-house use and only share with some partners you simply don't need to be that careful about what foreign code you incorporate into your product. This is especially problematic in embedded programming, where a lot of hardware manufacturers will give you documentation, libraries or examples to built upon that are attached to scary looking non-disclosure agreements, re-distribution licenses and so on. Even if in my opinion many of these are not actually enforceable, you can't ignore them without a through review and (expensive) legal help.

More specifically, almost all of existing software for VESNA is based on the proprietary STM32 firmware library that has a scary enough license to motivate people to make a free replacement for it. And no, I can't imagine moving everything to libopencm3 with limited resources we have. I'm personally guilty of committing code to the same repository that said "Under no circumstances is this software to be exposed to or placed under an Open Source License of any type" in the header. When you have project deadlines looming, clean room design isn't something that you want to mention at a meeting. While I took good care of adding warnings about it in appropriate places, I can't help myself wondering how many similar gems we have in the code that we don't even know about.

Hardware designs themselves can have similar issues. Chip manufacturers sometimes won't let you release a schematic of a circuit that uses their products, as silly as that sounds. Even though to my knowledge only one part of VESNA might potentially have that problem (my UHF spectrum sensing receiver of all things), these are even harder to track. The fact that Open hardware licenses themselves are in their infancy makes it even harder to make any solid decision regarding hardware designs without dedicating unreasonable amounts of time to it.

Then there are also cultural problems. Some of the projects here at the Institute have built upon open-source software, like Contiki. But that was done in isolation from the up-stream project. This means that after years of separate development the upstream has moved on and the private fork has accumulated a large number of changes. This is a nightmare if you want to contribute changes back to the community. While I may argue that it's reasonable to expect small drive-by contributions to be accepted upstream, I certainly can't recommend stopping by a mailing list and dropping a 50.000 line patch at the unsuspecting developers.

So, while starting off an open-source project from zero might be relatively effortless, open-sourcing something requires a lot of dedication and time from everyone working on the project. Unfortunately these are hard to justify when you have ongoing projects with their own deadlines and demands for attention. You need a well thought-out strategy and at least some solid ideas on what benefits an open development process will actually bring. Unfortunately the latter is not as straightforward as it might seem in the case of VESNA and SensorLab's academic setting.

While all of the above doesn't mean that I have given up on a free and open source VESNA I hope it does explain why I have been overly optimistic in my initial writings. I still invite you to cautiously stop by SensorLab's GitHub account and web site every now and then in case we manage another step in that direction.

I like free and open source software and I use it almost exclusively in my day-to-day computing tasks. One of the reasons why I prefer it over proprietary applications is because I can go in and change things. Nothing is more frustrating than when one little bug in an otherwise perfectly fine piece of programming makes it unusable for a task at hand and you can do absolutely nothing about it. Or when you need one feature which you know must be a one-line change and you are left with pleading to some narrow communication channel with a disinterested customer support person on the other side.

Not surprisingly, such tinkering has led me to the current state where many of the programs I use every day are custom compiled with this or that little change I made. Over they years I got good at maintaining these changes in a somewhat painless way (in short, quilt and/or git). But software upgrades are still painful as each upgrade either means dropping my custom patches or wasting time to port them to the new version. This is why I prefer Debian and its slow release cycle for computers I use.

If it's not an one-off hack though, but some application I will use at least twice, I always take the time to roll-up the change in a presentable patch and send it to upstream developers along with a nice description. Having a patch accepted in upstream of course is always better than maintaining my own private version of the code. It means I no longer waste time each release cycle and other people can benefit from my work, which gives me a warm and fuzzy feeling.

The problem however is that very few of these patches actually get applied by the maintainers of the project. In my experience, the best chances are with active, small or one-man projects. Larger projects usually just let such contributions linger indefinitely in the mailing list archives or the ticket tracker. I'm not even talking about them rejecting the patch - in that case I usually take the time to correct any problems maintainers found as that is of course beneficial to me as well. In most cases there is simply no reply at all.

Jono Bacon calls this kind of participation in free software projects drive-by contributions and explains that they are expensive in term of maintainer effort and that communities should strive to convert such random contributors to active members. I can't argue with that logic. Obviously a patch from someone that has an established track record within the community requires less careful review before it is accepted into the official repository. Although the patches I'm talking about are always relatively small fixes and not some big architectural changes that would require some broad consensus from developers.

The problem is that I simply don't have time to be actively involved with every project developing each piece of the software that runs on my computers. I usually join the mailing list of a project I submit a patch to, at least for a while. But for more there is simply not enough hours in a day and I have enough of my own projects.

Another problem are dead projects. Is it better to leave a series of patches in an abandoned public tracker or accept all the overhead that comes with it and release my own version?

Sean Dague praises GitHub as a solution to such problems. In my experience GitHub is a double-edged sword. On one hand pull requests are easy to make and provide a standard and hassle-free way of accepting such contributions from random users. But on the other hand, if a project isn't already using GitHub this leads to confusing situation where you have a network of forks on GitHub in addition to a official repository that may or may not be completely ignored by the original developers. Often researching the fragmented fork tree takes more time than actually implementing the fix yourself and again, it doesn't help much with the fact that you have to maintain your own fork, even with all the magic of git-merge.

I know I'm talking in a very general way about many diverse projects, but that is the general pattern I seem to keep noticing. Each time I get involved in some job that uses open source software I preach how it's important to contribute back to the community and not keep a fork of the code in isolation. But recently I often ask myself if I'm doing something wrong or if it's actually not worth my time to keep trying to contribute quality patches when a quick hack I keep in private achieves much the same result.

I recently finished reading The windup girl, a science fiction novel by Paolo Bacigalupi. The story is set in a future where the world has all but ran out of fossil fuels and where the mechanical energy is provided mostly by either physical workers or draft animals. This makes the economy revolve around calories and joules, used to measure chemical energy bound in food versus work done by muscles and springs. It's all mixed up with copious amounts of biotechnology that tries to make the conversion from the former to latter as efficient as possible. This backstory itself makes the book fascinating to read and makes you think about the energy footprint of modern living.

I've browsed back in my records and compiled the sum of all my consumption of general-purpose energy sources I bought in the last year:

• 5.9 MWh, heat
• 3.3 MWh, fuel
• 2.4 MWh, electricity

Obviously, this includes only energy sources I bought directly to use as I please and doesn't include the energy needed to manufacture any products I consumed or the use of public transportation where I didn't directly buy the fuel. So at best this is at the very low end of the energy footprint estimate.

The numbers above add up to 11.6 MWh per year or an average of 31.8 kWh per day or 1.3 kW of continuous power. To put this into perspective with some back-of-the-envelope calculations:

• Two draft horses would need to be working around the clock to cover this consumption.
• If perfect conversion from food energy to work would be possible, this would require 6.7 kg of carbohydrates per day.
• Or, it would require around 100 m² of photovoltaic cells (a technology curiously absent in the novel).
• Or, 70 s of exclusive use of our national nuclear power plant's output per year.

Energy consumption is often considered one of the indicators of progress and I don't subscribe to any movements that we should return to pre-industrial age energy footprints. I am all for using resources responsibly and as efficiently as possible though. And such little calculations do show a bit what kind of power is available from your wall socket compared to what was available merely a century or two ago.

Last week the National museum of contemporary history opened the doors to a new temporary exhibition dedicated to the history of computing. While quite a few groups and sponsors were involved in the preparation of this exhibition, GOTO 1982 is also the culmination of efforts of Kiberpipa's computer museum to regroup, reorganize and give one more try at making a community that would do its best to preserve the history of computing in our country.

Two years ago, things looked quite bleak. The old team pretty much went their separate ways for complicated reasons. Exhibits got scattered around Ljubljana as Kiberpipa and it's mothership organization was struggling with the large pile of old stuff that was taking precious storage space. The permanent exhibition in Kiberpipa's cellar went into an increasing state of disarray.

Last spring however at least some of the old disputes were settled and we got a new team together. We also got a sponsor for a proper storage space and spent the rest of the summer tracking where the old collection went and moving it all to the new location - involving lots of manual work, rented vans and forklifts in the process. We cleaned up the small exhibition in Kiberpipa and made it presentable again to the occasional visits from schools and reporters. I gave up on my former role of computer repair man and took care of cataloging our complete collection. We now have a web-based inventory tracking system and fancy QR-code stickers on each piece, with 312 pieces of inventory and 234 unique exhibits in the database. Being able to show a spreadsheet of possible display items goes a long way in presenting a credible case for an exhibition like GOTO 1982.

I can't say how happy I am that GOTO 1982 turned out as well as it has. It was in no way a small feat and all of us have donated a lot of our time to make it possible. It also gives a spark of hope that one day there will be a permanent place somewhere in Slovenia where you can try out typing on Spectrum's rubber keyboard or listen to the original Prince of Persia theme beep out of the PC speaker.

Remember back in February when I was writing about an PM-OLED display I got from Farnell? I recently learned about Seeed, a cheap PCB manufacturing service in China, through Dangerous Prototypes. Since I was not optimistic that I can make a usable footprint for the display with a home-made board I decided to order the design at Seeed and test the display as well as this new manufacturing service.

Ordering a PCB through Seeed Fusion PCB service is quite simple and worked without a hitch for me. You order a correct manufacturing option in the web shop and send the design files (Gerber for artwork and Excellon for drills) in a zip file to their e-mail address. The basic offering is 10 pieces of a two-sided board with silk, solder mask and copper layers on both sides, green finish and a 50% electrical test. You can also add a few options that cost extra, like different solder mask color or RoHS-compliant finish. Price increases in steps in relation to the board dimensions, with the minimum at 5 x 5 cm.

They have a few special requirements that you need to watch for when making design files though. You have to have a board outline on one of the layers and you have to include the order number they send you on the design somewhere. Other than that, the design rules are pretty standard. Minimum trace width is 6 mil. There's also an excellent guide to using the service which goes step by step using CadSoft Eagle.

I used gEDA PCB to make the artwork for this particular board and I didn't have any special problems. Seeed expects the files to be named in the same way Eagle does (foo.GTL versus foo.front.gbr), so you need to do some renaming after exporting the design to Gerber in PCB.

So how did it work in practice?

The cartoon box I received by mail contained 11 boards, one extra over my order of 10 pieces. Perhaps because my Arduino shield design was just a little bit too large for the 5 x 10 cm and I had to pay for 10 x 10 cm. It also appears that all of my boards have been electrically tested, not just 50%, since all of them have markings on the side. Nice surprise there.

I have no complaints over the manufacturing quality. I inspected all eleven boards and I can see no apparent defects (compared to some other cheap PCB manufacturer that managed to botch one board out of four) and drills are perfectly aligned.

If you look closely, straight lines on the silk screen layer have a somewhat jagged, pixelated appearance, which might be because of some calibration procedure (the effect looks similar to what you get on a projector where you correct the perspective in software). But this is just a very minor cosmetic problem and copper layers do not have any such effect. Seeed also inserted some kind of a batch number in small print on the bottom side stop mask layer. In my case it's over the ground fill so I guess they position it in a way that does not affect any artwork.

From the day I sent the email with the order it took 22 days before the package turned up at my local post office. The total cost for the PCB which is the size of a typical shield for Arduino Duemilanove was 26.05 €. I think this is an excellent value for the price. The long turn around time still makes it more practical to make simpler one-off boards at home, but for multiple pieces or smaller dimensions I will definitely use this service again.

And I guess another good thing about dealing with Chinese is that they do know their Unicode and don't mangle my non-ASCII name in their correspondence.

Last week I attended a three day course at Aalborg university on cognitive radio. Cognitive radio research is the reason behind the development of spectrum sensing hardware for VESNA. Since I haven't encountered this field before joining the Jožef Stefan Institute I decided to go to this course to get some background and to better understand what is the state of the art in radio communications.

It turns out cognitive radio means many things to many people. In the most broad sense it's an autonomous device that can optimally use the electromagnetic spectrum for communication by being aware and capable of adapting to its environment. This idea is then developed by some to an extreme, where the radio contains strong artificial intelligence that has perfect knowledge of its surroundings and is capable of predicting future events and the wishes of the user. For instance a mobile phone that learns your daily commute and plans ahead in cooperation with base stations on how to optimally use the cells on your way to the office. The personal digital assistant idea is strongly coupled with this and sometimes cognitive radio device is even described as being capable of communicating with the user through speech and natural language.

But such visions I only see as a thought experiment, as I can see no indications that such machines will be possible anytime soon. On the other hand however there is a more pragmatic approach to cognitive radio that concerns itself mostly with how to more efficiently use the limited amount of usable frequencies and overcome the spectrum crunch. This research covers for instance new ways to dynamically allocate frequency bands beyond very static licensing regulation that is in use now, how to enable secondary use of frequencies that are unused by people that initially licensed it for exclusive use and how to decentralize frequency allocation. It is also tightly connected to software defined radio technology that enables this kind of quick reconfigurability of radio devices.

Besides lectures that covered information theory, networks, game theory, machine learning, software radio and economics we also had a practical demonstration of the ASGARD software radio platform. Guys from Aalborg university demonstrated three pairs of USRP devices that were dynamically and autonomously selecting radio channels in a shared 5 GHz ISM frequency band so that the interference between them was minimized.

The course concluded with a poster session where I also presented the spectrum sensing expansion for VESNA with the following poster (PDF version).

In a month or so, we will be deploying around 50 VESNAs to a wireless sensor network in one of Slovenian smaller cities. VESNA boards, sensors and other electronics will be mounted in white plastic boxes and fixed on top of light poles alongside public streets. It will look somewhat similar to this temporary mock-up we set up in the Jožef Stefan Institute courtyard the other day:

While these boxes are certified to be resistant to the elements and provide adequate shielding for sensitive electronics within, one question remains open. In the summer the air temperature can reach 40°C and with the boxes exposed to direct sunlight the inside could get uncomfortably warm. The ARM microprocessor on the VESNA core module only dissipates around 100 mW at worst, however my UHF spectrum sensing receiver, which is also going to be inside the box, has to shed close to 1.5 W of heat while not heating up over 120°C. If the air inside the box is at 80°C from the sun alone, this requirement might require some extra measures to meet.

Unfortunately, there are no exact specifications on how the boxes behave in this respect. To get a rough estimate of the situation I defined the following thermal resistance model of the box and performed some experiments in an attempt to determine some limiting values on the environment my electronics will have to endure.

Here, T_a is the environment air temperature, T_b is the temperature of the box itself and T_c is the temperature of the air inside the box.

First experiment was to determine the contribution of the sun (P_sun). I put a VESNA node running on batteries inside the box which was mounted in a sunny position on a south-facing balcony. VESNA was running a temperature logging application which recorded the ambient temperature every few minutes.

In the ten days the experiment was running we had 8 sunny days. If you look at the highest peak, the temperature inside the box was somewhere in the vicinity of 55°C, while the air temperature outside the box (not drawn on the graph) was around 25°C. So, in early May the sun already heated up this white object to 30 K above the ambient.

The second experiment was to determine the contribution of the UHF scanner's power dissipation on internal air temperature. I placed a ceramic resistor inside the box and set up a lab power supply so that 2 W were dissipated on the heater (P_c). This time I used two battery-powered VESNA nodes to log the air temperature inside and outside the box.

While this experiment was performed inside and in the shade, the daylight still somewhat affected the ambient temperatures by heating up the room, so the thermometer outside the box recorded a slight increase during the day. During the day I also turned on the heater (I didn't want to leave it running over the night), which resulted in around 5 K increase in the internal air temperature.

If you look at the model I pictured above, these measurements are unfortunately still inadequate to determine both thermal resistances. From the second experiment you can calculate that R_ab + R_bc is around 2.5 K/W, but to get individual resistances you would need to know the thermal input from the sun, which depends on the unknown albedo of the box.

However, at this point this detail is irrelevant. From the first experiment in know that the sun will contribute around 30 K and from the second experiment I know that internal power dissipation with add another 5 K above the ambient. If I take the worst case air temperatures outside to be 40°C, this adds up to 75°C inside the box. From this I can now calculate the maximum allowed thermal resistance between the tuner IC's silicon and the inside ambient and from that choose the appropriate cooling solution.

Spectrum sensing is a phrase that is being used a lot at my current job. I have mentioned it before in relation to the experiments in Munich back in February. Let me explain what it means and why it is important.

One possible way of enhancing radio communications in the future is making the receivers and transmitters aware of their environment and capable of adjusting the radio link accordingly. For instance, they could intelligently avoid uncontrollable interference at a specific frequency, cooperatively share a limited part of the spectrum or use frequencies that experience the least fading in the current location. This idea usually falls under the somewhat awkward umbrella of cognitive radio (which sometimes also includes gratuitous applications of strong artificial intelligence and other things not directly related to radio communications).

So broadly speaking, spectrum sensing means measuring the properties of the radio-frequency part of the electromagnetic radiation propagating in an area of interest. In the current real-life usage scenarios you are usually interested in knowing whether there are other third-party transmitters operating in the same part of the spectrum as you. This might be because you don't want them to interfere with your connection. But equally important are cases where you don't want to interfere with them. For instance, recently frequencies where formerly only big, licensed TV operators were allowed to transmit are being opened to general public and consumer devices, with the added catch that these devices must make sure their transmissions will not interfere with licensed users.

The latter use case is especially problematic. If you are only interested in the effect of any third-party transmitters on your radio link, measuring their signal strength at your own antenna is sufficient as the location of the measurement is the same as the point of interest. However electromagnetic field theory says that in general case just by doing measurements at your antenna you can't infer how your transmissions will affect a link between two distant devices in your neighborhood. Empirical rules have been developed though that work in common circumstances with high enough reliability, but they are necessarily hard to satisfy in practice as they require very sensitive spectrum sensing receivers.

How do you detect a transmission? The most simple method is called energy detection - you are simply detecting the received signal level on the antenna and declare a transmission has been detected if the level is high enough above the noise level. Energy detectors work quite similar to classical swept-tuned spectrum analyzers except that they are much simpler and cheaper. Usually an integrated silicon tuner is used. For example Texas Instruments CC2500 is a popular choice for the 2.4 GHz ISM band.

Simple energy detection has one big problem though: you can only detect signals that are significantly above the noise level. For example, in TV band white-spaces FCC requires detection threshold of -114 dBm. At this levels of sensitivity even the unavoidable thermal noise presents major problems. This can be solved though with more advanced methods of detections. For instance, repeating patterns can be still detected when the signal to noise level falls well below unity. And most real-world transmissions include some repetition, so cyclostationary detection doesn't hurt generality much.

In conclusion, to add some practice to all of this theory, here is a spectrum sensing receiver I developed at the Jožef Stefan Institute during the past months. It fits on a VESNA node and is built around the TDA18219HN silicon tuner from NXP. This single chip includes most of the radio-frequency circuitry as well as the intermediate frequency part, a lot of which can be reconfigured through an I²C interface. It's also cheap enough that many such receivers can be used in a sensor network.

The receiver can do energy detection on the VHF and UHF bands with receive bandwidths from 1.7 MHz and 9 MHz and is specifically designed for research into TV white-spaces reuse. In theory it should also be capable of cyclostationary detection using VESNA's CPU, although that has yet to be tested in practice. Here you can see a spectrogram of the UHF TV band that was recorded with it. The central Slovenian DVB-T multiplex can be clearly seen at 562 MHz.

Making this hardware was a lot of fun and I might write a bit more about it in a separate post. There is some ambiguity about the amount of information I can disclose about it though as the documentation for the tuner chip and reference implementation came with some crazy restrictive fine print. However you can already dig through the source code of VESNA spectrum sensing application and my spectrum analyzer Python script (which has been recently updated to work with a properly equipped VESNA in addition to Fun Cube Dongle).

My dad is an avid model airplane builder and he is currently building a new electrically-propelled glider of his own design. This particular airplane will have styrofoam-core wings and two weekends ago he was trying out a new way of making them.

Such wing profiles are traditionally cut out from blocks of styrofoam with a hot-wire cutter that is pulled by hand over plywood templates. However the width of the cut depends on the speed of the wire as it travels through the material and since you can't manually pull the wire at a perfectly constant speed the wings end up full of little pits and grooves. Of course, nowadays you can get computer controlled cutters that control the hot wire with servos and can cut out any shape with perfect steadiness and without the need for templates.

My dad however went for another approach: he made a purely mechanical device that pulls the wire over the templates with constant speed. The interesting bit here is that the two ends of the wire usually have to travel different lengths through the styrofoam in the same amount of time, depending on the wing taper ratio. He achieved this with an adjustable system of levers, pulleys and ropes that would make for a nice high-school mechanics class demonstration.

The whole thing is powered by gravity and an occasional nudge by hand. In fact, for perfect straight cuts just the weight of the hot-wire cutter is sufficient without additional mechanisms.

As you can see from the (long) video below, it takes one to two minutes to make one cut (and you need several per wing, depending on the number of segments), so it's not the fastest thing around. But it makes up for it with perfectly smooth cuts and if you only make a few wings per year it's perfectly sufficient.

One of the more unusual sights at the 28C3 last year in Berlin was a circle of hackers of all ages and genders sitting on the floor around a large flat panel monitor. They were watching a cartoon show with colorful ponies, while behind the screen you could see the dark basement with flags of various groups and hackerspaces hanging from the ceiling and a disarray of electronic devices strewn on tables. Maybe not surprisingly, this gathering also happened to be almost immediately below the no photography sign, which means that I was unable to find any evidence of it.

I have heard about this show now and then in the usual background noise of the web even before the congress. However this encounter made me somewhat curious and, having never actually overgrown watching an occasional cartoon, I decided to see what all this is about. For scientific reasons, of course.

Image by Chromamancer

I am talking about the latest remake of My Little Pony. It's an animated TV series that was created to advertise a line of Hasbro toys for girls, but in a funny turn of events actually got a sizable following of the opposite gender and in another age group. I guess something that would be unlikely to happen without the internet and the pseudo-anonymous discussions it enables.

After watching some of the show, I can say that I can understand to some degree why it has attracted such a broad audience. They say that a sign of good content for children is that it is also worth watching for adults. And in this particular example the latter certainly appears to be true.

You can often read that the show is well drawn and animated. For sure that is one part of the attraction. Remember my thoughts about the Avatar movie? I guess modern artists have become increasingly good at triggering emotional responses in their audience. The combination of human and animal visual traits in a character allows you to trigger more image recognition circuits than what is possible with only a human face. There's actually a word for that: superstimulus and it's quite amusing to see the parallels between songbirds falling for a red stick with white bands and people looking at what would be pretty deformed body shapes in nature.

Another thing that is often mentioned is the lack of cynicism in the show. Not surprisingly for a show that also carries an educational mark, the characters always find out that it's better to work for the greater good than for only your personal benefit. I can certainly see the appeal in this. It's nice to loose yourself in such fantasy after spending day after day in society that is increasingly focused on grabbing as much of the pie for yourself as possible and there isn't much space for laughter, truth, generosity and loyalty.

However, if this is one of the causes for the popularity among grown-ups, it's somewhat ironic if you consider why the show has been created in the first place: to increase profits of a multinational company that turns around billions of dollars each year. And in fact Hasbro has controlled the show from the start, making sure that it features things they can sell as toys.

But if you put these arguments aside, the creators of the show managed to paint a pretty consistent picture of a world where things are operated with hooves and mouths instead of fingers and three races divide their work to cover for each others shortcomings. This has made it possible for fans of the show to build upon it with their own original stories and, not having to stick to the original constraints, some of them are just as, if not more amusing than the original itself. So it's not all in the visual appearance either.

To sum it up, once you survive through the first view of the pink sugary overkill of the brand logo, it's an enjoyable show with memorable songs and a surprising lack of elements that could be described as fitting for a stereotypical little girl. If it makes more people think about their actions from the perspective of broader society, so much better. And if marketing departments can miss their target audience that much, I guess that's also a sign to be optimistic and might mean we have some time left before they figure out how to control our every thought.

I've spent past week just outside Munich, Germany at the Ottobrunn EADS site. Among other things at the Jožef Stefan Institute I'm also involved in the CREW project. As it's usual for such multinational projects they organize regular meetings at one of the partners and this time the turn was on European Aeronautic Defence and Space Company.

The CREW project aims to build a number of instrumented test sites across Europe that would allow experiments with advanced radio technologies, like cognitive radio and dynamic spectrum access. I'm currently working on spectrum sensing hardware for VHF and UHF TV frequency bands and even though the happenings this week didn't directly concern that, I couldn't pass on a visit to the company that makes things like Airbus aircraft and Ariane launch vehicles (in addition to some less enlightened products). Not to mention that it's always nice to put faces behind names appearing in your inbox.

If you've been on a passenger airplane you probably know little panels above your seat that remind you to fasten your seat belt and have speakers for announcements from the crew. Behind the curtains these are currently connected to the airplane's network with cables, however airlines wish to do away with physical connections and use radio instead which would make the panels and seats below easier to rearrange. Of course, this brings problems since these panels are considered critical to passenger safety and must work even if some ignorant passenger turns on Wi-Fi on his iDevice or if a terrorist smuggles 10.000 EUR worth of signal generators on board.

This is where this group of experimenters came in. We were given a section of an Airbus 340 fuselage to work with. It happened to be furnished with first-class seating and plenty of power sockets in the floor panels, something that's sadly not part of the usual airplane equipment. After two days of setting up measuring equipment the place was so full of criss-crossed wires that it was somewhat hard to believe the objective of study was in fact wireless technology.

In a nutshell, we set up two programmable 2.4 GHz transmitters at opposing corners of the cabin and then measured received power at different locations across the cabin, including one mobile one on the meal cart, with different custom (for instance the IMEC sensing engine) and commercial receivers (USRP among others). The end result, at least on our end, was a bunch of spectrograms, like the one below that was recorded with two VESNA nodes equipped with our spectrum sensing receiver.

If you think this is something you might show the stewardess when she next asks you to turn off your favorite gadget I must disappoint you. You will have to wait for the peer-reviewed papers that will undoubtedly be published about the experiment and even then I'm not sure you will win that argument. In that regard I am not very optimistic about the usefulness of results myself. You might do some qualitative discussions of what the cabin radio environment looks like, but I think that's about it. For anything else there are just too many unknowns even in just the physical setup of the experiment. The conclusion that cognitive radio approach will be superior for such an application was somewhat unscientifically determined before the experiment took place anyway, so you can't say that it was an unbiased effort either.

The real value of this work however was in testing all of our tools. We found several problems with VESNA nodes that need to be fixed before we deploy them in our CREW test bed, from unknown sources of clock drift to buggy software, inconvenient procedures and unfavorable reactions to lengthy USB cables. We also found sources of interference on some devices that need to be looked into and so on. Suffice to say, my wish list grew a bit over the week.

The short tour of EADS offices was quite interesting too, of course. It's a huge facility with 3.000 employees and a correspondingly large amount of amazing stuff hanging on walls and laying around workshops and hallways. Sadly the strict security didn't allow me to take pictures outside of our experiment, so I'm not able to share them here but I can say that the shapes behind frosted glass and warning signs on closed doors do well to fire up your imagination.

Photo by lowk3y

Last Tuesday I gave a talk about my 433 MHz receiver project at Kiberpipa's Open Sessions. I presented what I learned about the radio communication between cheap, simple everyday devices, described the receiver hardware and software and did a live demo.

I think the talk was well received and although I didn't go much into the security consequences of some of my finds the Q & A session that followed made it clear that it wasn't really necessary.

A few minutes ago I also uploaded the version of the software that I was using during the demo. Compared to the 0.0.1 version which I put on-line during the 28C3 it contains some minor fixes for the software demodulator and a bootstrap script that (hopefully) compiles everything in one step.

If you missed the talk, the video recording of it is already on-line thanks to the efforts of the Viidea team. You can either download it or watch it in the web browser synced to high-res slides at Kiberpipa's shiny new video archive.

Update: in the talk I mentioned that the CM108 audio chip doesn't allow for longer than 24 hours of continuous recording and blamed either a bug in the chip or ALSA drivers. It turns out this was a bug in my own code (which is now fixed in the git repository). I guess I should count the bits in my own variables before speculating on the counter size of others.