I mentioned earlier on that I had been given an old NES, without any accessories (no power adapter, no controllers, just the box itself). Having grand plans to use it for various cool mods, I needed to get it to work first. As I am writing this, Brenda is playing Mario bros on my NES, so it actually works!

Does it even work?

Using a bunch of borrowed (original NES) hardware, I established that both the NES and the Mario/duckhunt cartridge I had with it, were working. I did need to bend out the pins on the cartridge slot on the NES, but now it seems to make contact properly.

Last week, I bought a second hand NES controller, so I could start experimenting with it. This weekend, while I was in Enschede with Brenda, I have been toying around with it. I borrowed a power supply from Bert, which had conveniently and only supplied AC voltage (which is exactly what the NES wants, though DC should work as well). I connected the NES to the composite input of my workstation's TV card.

After remembering exactly how to properly setup my TV card (haven't been using it in years), I got a properly coloured and sized image. Only, the image was distorted here and there and sometimes sprites would disappear all together. The cause of this was the power supply: When the NES was turned on, it supplied only 6V instead of the 9V the NES required. The solution was to turn up the power supply to 12V, so it supplies about 8V when loaded (yes, the supply is a bit overloaded).

The only problem left so far, is a nasty low buzz in the audio. This is probably related to the unstable power supply, but is nasty nevertheless. I have tried filtering the signal to get the buzz out, but that failed because using my microphone input as an ALSA input just didn't work for some reason.

Anyway, I can now play Mario! Next project: Building my own zapper gun to play duck hunt!

As you might have noticed, my blog is no longer layouted at a fixed width of 800 pixels, but stretches to fill the entire width of the page. I had meant to do this a long time ago, but I just could not get it to work with CSS alone, the only way to do it that I saw was using tables. Since I dislike tables for layouting, I made the width fixed.

Yesterday, somebody on IRC said it was perfectly possible using CSS and pointed out how. His suggestion did not work, though the idea behind it was good (Make the left bar a float, and to prevent the right bar from flowing below the left bar, give it a very wide margin, so the float will stay in the margin). I did some more digging in the CSS 2.1 spec and found a part about block formatting contexts.

From this section (and a number of others) I concluded that if the right bar (with the posts) would start a new block formatting context, it would be properly shortened to fit besides the left bar and I could use floats and the clear property inside the bar without interfering with the float(s) outside the bar.

So, I tricked Firefox into giving me a new block formatting context by setting overflow: none on the bar. This did not really work for IE, I needed to set float: left to make it work on IE. Of course, this breaks on Firefox for reasons I do not fully understand. So, I used the html>body part of the IE box model hack to make Firefox forget about the float part again...

Now my CSS is ugly, but it works!

For my Bachelor referaat, a third year course, I have to write a paper about scientific research performed by me. I started out with this course last year, but do to lack of time, I never actuall started the research.

I did however write my research proposal already. Instead of having to start all over with a new research topic this year, my teacher allowed me to finish my existing paper and present it on the next Bachelor referaat conference instead. So, I made a brand new planning and am now continuing my work.

Wireless Sensor Networks

In short, the goal of my research is to let nodes in a wireless sensor network improve their localization, in particular in the face of signal obstructions. These nodes are small electronic devices designed to perform all kinds of functions, communicating through radio signals. For most functions to be able to work, a node needs to know its physical position. To be able to determine this position, a small number of nodes needs to be told their position in advance. We call these nodes 'anchor nodes', since they are anchored on a know position.

There are a number of algorithms available to perform this localization, some of which work pretty effective. At least, in theory. In practice, these algorithms do not work as effective as we would hope. A significant part of the errors observerd is due to signal obstructions, such as walls, windows or cabinets. Take for example an anchor node and a normal node on opposite sides of a wall. Since the wall obstructs the signal, the normal node might not 'hear' the anchor node, even though they are well within transmitting range. If it performs localization, it will think it is much further away from the anchor node than it actually is (It should have heard the anchor node if it was close, right?). This is an example of the problem, obstacles pose for localization.

I have some ideas on how to improve this, but more on that later (or you should read my research proposal). To properly use my ideas for real research, I need some way of testing them. The obvious strategy would be to find myself a wireless sensor network and teach it my algorithms. Now, even though we have a WSN available at uni, I will not use it. Using real sensor nodes is a lot of work and it is hard to do ceteris paribus comparing. Also, the WSN is not just available all the time for me to play with. So, instead, I will be using a simulator called LocSim. It's implemented using Matlab and Simulink and was written by Stefan Dulman, who also helped me with my research subject initially.

Matlab

Up until now, I have been experimenting with Matlab a little, since I've never used it before. The locsim library is composed of a lot of building blocks, each modeling a small part, such as a block generating node positions, a block performing centroid localization or a block that shows the position of the nodes and the results of localisation. Each of these blocks is powered by pieces of Matlab code, a programming language that makes extensive use of matrices and other mathematical concepts, allowing one to write down these algorithms and other calculations pretty concise.

But, to properly be able to use this library, it needs simulate obstacles in the field, which it currently does not. So, my first goal is to make locsim support obstacles. Some initial toying around showed that obstacles are indeed a big problem: I created a block that inserts a big obstacle, splitting the room in two and that provides a signal obstruction of about half the transmission range. When running with this block inserted, average localization error doubled!

originally, I created a new block that inserts an obstacle into the 'connectivity matrix', ie the matrix that specifies which nodes can hear eachother. This idea was good, but it would not work with all localization algorithms. Some algorithms base their results completely on a given connectivity matrix, but some others need the actual node positions themselves and calculate their own connectivity matrix (or distance matrix).

Modifying loc_dm

To make this work, I would need to modify all the algorithms to work differently and everything would become real messy real soon. Currently I'm trying another route: Modify the distance matrix block (that turns node positions into a matrix with distance between each node). This still requires that I modify all algorithms to add an extra input: The list of obstacles. But, I only need to connect this input to the distance matrix module inside the localization block.

For this to work, I will need some way to describe obstacles to the distance matrix module. For this I have chosen something similar to how nodes are described: A matrix with 5 columns and n rows. Every row represents a single obstacle, in the form [x1, y1, x2, y2, d]. This represents an obstacle that starts at (x1, y1) and runs to (x2, y2). It has no thikness (only signals crossing this line will get obstructed, but it has a 'density' d, which is the length added to the distance (symbolizing the reduced signal strength).

Implementing this was fairly easy using the polyxpoly matlab function for checking intersection between the obstacle and all signal lines. For now, I've done this using a couple of nested for loops, but it should be possible to combine some of these to reduce the number of polyxpoly calls.

Next steps

Currently, my code supports generating obstacles, applying the effects of obstacles to the connectivity matrix and displaying obstacles. The only part that is still missing, is to make the localization algorithms support them too (which is mostly a trivial addition of an obstacle input port).

After this is done, I can start experimenting with the effects obstacles have on the localization effectiveness and try to improve the effectiveness of the various localiation algorithms in the face of obstacles.