Clock drift

29.02.2012 19:58

When I was processing the raw measurement results from Munich experiment I noticed that absolute timestamps on spectrograms recorded by two VESNA nodes were differing randomly from zero to three seconds and required manual alignment.

The experimental setup was not expected to give very precise time reference: each VESNA has its own free running real-time clock stabilized by a 32.768 kHz quartz which was providing time relative to the start of the measurement. Absolute time on the other hand was provided by two Linux running laptops to which the sensor nodes were sending the data. So all in all the accuracy of our timestamps depended on four quartz clocks.

Nevertheless this result was surprising to me. I expected these four clocks to drift apart in the three hours of measurements, but this drift should be uniform. I can't explain what could cause the difference between clocks to randomly change between experiments.

To rule out any problems on VESNA I rigged up a simple test where I compared the difference between VESNA's real-time clock and the clock provided by the Linux kernel with a running NTP daemon. This is the result of four test runs with two nodes that we were using in Munich:

Results of a clock drift test for two VESNA nodes.

As you can see, the clocks do drift apart and do so more or less linearly (nodes were turned off for the night before each test to also see if warm-up affected the drift). Node 117 drifts at around 3 ppm and node 113 at 9 ppm. This is actually quite bad, as node 117 would gain a second each four days, even considering that the reference here was a laptop that probably isn't a shining example of accuracy either.

The only weird thing is the strange bump on the graph for node 113, where drift was positive for around 15 minutes and then turned back to negative. I could not reproduce it in any of the later runs and it might be due to NTP adjusting the laptops clock. But even that can't explain the observed deviations that are more than ten times what we see here.

While this is of course not conclusive, it does give me some confidence that it might be the PC software that was causing these problems.

Posted by Tomaž | Categories: Digital | Comments »

Organic display

27.02.2012 18:55

Recently I got another gadget to play with from Farnell as part of their road testing program. If you remember last year I picked a pair of 433 MHz RF modules, which I put into some good use.

This time I choose something a bit more colorful: a small, passive matrix OLED display, not unlike the screens you find on small solid-state music players.

Densitron DD-160128FC-2 OLED display with a matching connector.

This is Densitron DD-160128FC-2B (original manufacturer's site). It's an 1.69 inch color dot-matrix display using organic LEDs on a glass substrate driven by a passive matrix. This means that you get 160 x 128 pixels with 18 bits of color resolution in a viewable area of around 36 x 29 mm (making for 110 DPI).

SEPS525 driver IC bonded to a flexible PCB on a Densitron OLED display.

On the electronic side it's controlled by a Syncoam SEPS525 driver IC. By the way, that's the elongated bar on the front side of the display bonded to the flexible PCB tail - you can actually see the structure on the silicon through the transparent substrate. This chip supports quite a few possibilities of interconnect, although not all are usable with this particular display since some pins of the chip aren't available on the connector.

Probably the most interesting one is the single channel serial 10 MHz SPI bus which requires only 4 pins. You also get the possibility of using an 8- or 9-bit parallel bus in an either a Motorola 6800 or Intel 8080 flavor, which is somewhat surprising since I haven't seen a bare CPU bus exposed on highly integrated devices that would use a display like this. More likely these modes can be used through some kind of emulation of these CPU buses as they allow faster writes to the frame buffer compared to SPI. The fourth possibility is a direct RGB interface that uses a dot clock and h- and v-sync signals to transfer subpixel values through a 6-bit parallel bus. The chip also supports parallel buses wider than 9 bits, but as I mentioned above, they appear to be unusable, as data lines D9 through D0 aren't connected.

My plan is to put this display on a shield for an Arduino Duemilanove, as it is just about the right size to fit nicely. And here's the catch that is the reason why so far I'm writing all of this from theory and I haven't yet actually turned the display on.

First, the OLED display requires a 14 V, 40 mA power supply. This is not something you will usually find on microcontroller boards which means using a micropower step-up converter. Thankfully, these requirements are quite similar to those of LCD panels, which means that you can get cheap DC/DC converter chips in this power and voltage range (I'm currently looking into National Semiconductor LM 2703). To complicate things just a little bit more though, you apparently need to be able to turn this voltage on and off from software, since the datasheet specifies a turn-on sequence that involves turning on the driver voltage some time after the digital part gets its supply.

The said digital part however, only works with supply voltages between 2.8 and 3.3 V (with I/O pins capable of also using 1.6 V digital levels). This presents another inconvenience on a 5 V board like the Arduino, since you have to do level shifting for digital lines. Thankfully, there's a 3.3 V supply already available on the Duemilanove shield connector that should be capable of powering SEPS525.

Lastly, the display sports a flat flexible cable with a 0.5 mm pitch. Even with a matching SMD connector this is quite impossible to manually solder without a PCB break-out board that puts somewhat more space between the pins. 0.5 mm pitch (I'm guessing requiring minimum feature length around 6 mil) is also somewhat stretching the limit of what I can do with my home-brew PCB process. I have yet to try it, but it's not unlikely I will have to get this board professionally made.

In conclusion, none of the problems I mentioned above are show stoppers if you want to use this display. However they make it quite inconvenient to use in a home workshop or with the cheaper microcontroller development boards and I haven't even started looking into the software side of the things. Guessing from the datasheet talking with SEPS525 won't be trivial either and from some initial searching I haven't been able to find any free libraries that support it. So, unless you are looking for the flexibility that only a bare display can offer, I would suggest trying some of the display modules that already come with all the tidbits required for mating them with a microcontroller development board.

Posted by Tomaž | Categories: Digital | Comments »

Too much NoScript

22.02.2012 22:57

I am a long time user of NoScript Firefox extension. I find it's an effective cure for obtrusive advertisements and weird page features, plus it gives me the feeling that I can still control who can execute code on my computers. I also hate being tracked by various bugs embedded in pages and NoScript allows me to block those iframes and scripts that send information about my visit to third parties.

It's not perfect (what is on the web today?) but in my experience the domain based blocking of Javascript seems to be an effective heuristic against unwanted content. Plus in contrast to various other ad- and tracking-blocking extensions it's very simple to temporarily or partially disable the block should I stumble upon a page that absolutely requires some piece of Javascript.

Unfortunately NoScript took a path all to many software projects take. From doing a simple task of blocking script execution it grew into a giant that wants to solve all of the browser-related security problems. That by itself isn't such a bad thing, but such complexity invariably leads to problems and it's those that are starting to annoy me.

For instance, NoScript nowadays comes with some heuristical algorithms for preventing XSS. As far as I know, they have yet to save me from malicious content, but are constantly breaking legitimate scripts like Instapaper, even when I put it on all white lists I can find. Same goes for something called ABE, which constantly prevents me from following links to servers on my local network. Again, it might prevent attacks against my local routers, but security that constantly gets in your way is worthless.

These two annoyances however at least identify themselves by descriptive error messages. Lately, some web applications started to repeatably break when NoScript is enabled without as much as a warning. One thing I found for instance is that NoScript will silently block Javascript that is served as MIME type text/plain. How that could be a security risk, I don't know. But it appears a few legitimate sites have misconfigured servers that do that.

As I've been looking a bit more closely at this project, I discovered another surprising thing: while the code is indeed released under a free license, the development process is all but open. There is no public source repository. There is no bug tracker. There is even no mailing list. All you get is a web forum and a bunch of XPI files that you can decompress to get to thousands of lines of dense Javascript code. You don't get any scripts for instance that are surely used in the release process to generate some files and pack all the parts into the XPI file itself. For a security oriented project, that is quite unusual to say the least.


Now I hate to only give criticism and not offer any solutions. Unfortunately my experience with Firefox extensions is limited to some prehistoric version and I have neither the time nor will to refresh it enough to be able to look into any of the bugs I described above. I know there are many talented Javascript developers out there that are more than capable of making a better NoScript, but the closed nature of this extension makes it hard to make a fork.

So I decided to rather donate some of my time to help with that last problem. I downloaded the complete history of stable and development NoScript releases from addons.mozilla.org and committed them to a GitHub repository. Using their API I also set in place a mechanism that will automatically update the repository with new releases, hopefully with minimal maintenance from my side. I also added a simple script that can be used to create an XPI file from code in the repository that should be nearly identical to official releases (except for author's cryptographic signature, of course).

As usual, you can check it out with a command like this:

$ git clone https://github.com/avian2/noscript.git

This also has a useful side effect in that it makes the original upstream development somewhat more transparent. With a diff between two releases one click away on GitHub, you can check the changes between two releases yourself. With a tool like that undesirable changes like NoScript messing with Adblock Plus back in 2009 might have been discovered earlier.

And finally, having all of NoScript history in git means you can easily create nice graphs in a few key strokes (courtesy of gitstats). Enjoy.

Number of releases of NoScript per month

Number of releases of NoScript per month (note that for releases earlier than 2007 I don't have information of their exact date hence the spike on the graph)

Number of files in NoScript XPI through time

Number of files in NoScript XPI through time

Lines of code in NoScript through time

Lines of code in NoScript through time

Posted by Tomaž | Categories: Code | Comments »

Munich experiments

17.02.2012 21:57

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.

Ottobrunn EADS site.

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.

Aircraft meal cart full of spectrum sensing equipment.

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.

Two spectrograms recorded at the CREW Munich experiment

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.

Posted by Tomaž | Categories: Life | Comments »