User login

Brad Christensen's blog

22

Jun

2014

I wrote my interim report a couple of weeks ago (since the last time I wrote a blog entry) and this week I have been beginning to get back into the swing of things. I spent some time looking into 6LoWPAN/RPL gateway router solutions (to bridge the LoWPAN with Ethernet) and found that a common solution (6LBR) seems to be to run the router on a more powerful device such as a Raspberry Pi or BeagleBoard, using the radio of a USB-connected mote via a serial tunnel. An alternative to this would be to connect a radio directly to the board, but radios available are limited and generally not mass produced. To this end I went back to trying to get a serial tunnel working so that I could communicate between the host PC and a (remote) mote. I read into the code for the tunnel a little further and managed to work out that packets are being received and recognised between the host PC and tunnel mote, but not forwarded further to the remote mote. This is confusing since I had expected the problem to lie with the tunnel software (which I had such trouble initially compiling) and based on what I've read, it sounds like the motes should automatically establish a LoWPAN between themselves and communication should be no problem.

Following the plan I laid out in my interim report, I was aiming this week to nail down the hardware I would need for the coming weeks. Since Richard N has procured another STM32w RFCKit for me already and Richard S has a Raspberry Pi he doesn't need any more, I should be good to go.

03

Jun

2014

I've been flat out with other assignments for the past little while and haven't managed to get any honours work done, but I'm about to spend this week writing my interim report. As with my proposal I plan for it to consist mostly of background research, since my experiences with the STM32W RFCKIT have thus far yielded more questions than results.

20

May

2014

Have been trying to get communication working between devices this week, but nothing seems to just work in Contiki quite as you would expect it to. I read in several places (although each using fairly wishy washy methods) that it was possible to use a mote as an RPL border router, which the host PC could tunnel through via a serial connection to connect devices to the wider network/internet. I figured I would give this a go before I jumped into writing code to test that devices were networked and communicating properly. As it turned out, the RPL border router app for the mbxxx platform wouldn't compile out of the box due to missing files (in both release 2.7 and master branches). I worked out that after symlinking to what seemed to be the right files I could get the border router to compile properly, but connecting to it wasn't straightforward either and I eventually gave up in search of other methods.

Found what look to be excellent resources from Jacobs University, in the form of lab handout tutorials/walkthroughs. I followed through one on bridging an IPv6 network (using a different included app than the RPL border router), although the document was from 2009 and for a different platform. Some code in Contiki differs between the platforms: mbxxx seems to lack certain build functions, but I was able to substitute in the ones from the suggested platform. That being said, I finished the walkthrough, but I still don't seem to be able to reach a remote node through the tunnel mote, so I'm pretty confused now. If I continue down this track I may have to look back through past Contiki releases to see whether the code for each platform has changed -- I assume the bridge for mbxxx worked at some point.

Or I could just be completely doing it wrong. But either way, the lack of documentation is maddening...

11

May

2014

Have been busy with assignments the last couple of weeks, although one was a literature review on wireless sensor networks that I did together with Richard Sanger, which conveniently relates to my project. It gave me some really good further background knowledge (and a solid page of references) with regards to the technologies I'm working with, so I'm hoping that will be useful when it comes to writing later on.

This week I was able to sit down for a few hours and play with Contiki a bit more. I spent much longer than I should have trying to get a toolchain set up for cross compiling Contiki from my own Debian system, so that I don't have to rely on the Instant Contiki virtual machine any more. It turns out that the process of setting up the toolchain (at least for the platform I am working with) is actually really straightforward - there's just no documentation on it. I also worked out some interesting differences between the most recent stable release of Contiki and the master branch currently in Git - it seems there has been quite a lot of development since that release which brings about useful changes, but the mbxxx platform hasn't quite been brought up to date with the core changes and so it's not so usable. I've decided to go off the 2.7 release for application implementations (example CoAP/HTTP servers etc) but backported the improvements made to the stm32 tools so that it's possible to flash the devices from Debian without HAL.

So I've got to the stage where I've flashed a device with a CoAP server but I don't have a way of easily testing it since I don't have a gateway device. I'm thinking of putting a client on the second device with a shell that I can control it through, and I'll have to look into how the devices actually pair with each other etc. I ran into issues with overflowing RAM and ROM with newer versions of the apps from the master branch, but r2.7 versions seem fine. Once I've determined whether memory is going to be sufficient on this platform we might need to acquire a couple more devices to test RPL (or the simulator might also do the trick, but that's boring).

21

Apr

2014

I've been looking more deeply into Contiki this week in an attempt to become more familiar with the code. One issue I found was that Contiki only seems to support one of the five buttons on the MB950 (application board) out of the box, so I wanted to see if it were possible to fix this. It seems as though some effort has gone into writing the code such that it can be extended to support more buttons easily (for example, the button that is supported can be interchanged with any one of the other buttons), but it stops short of actually implementing multiple buttons, which is really strange. In any case, I should stop getting held up with this and move on to more relevant things. Over the next few days I will start playing with IPv6 communication and then revisit some of the initial research I did to determine which direction to take the project.

13

Apr

2014

Thanks to Richard I now have an STM32W RF Control Kit, which I had a chance to play around with a little bit this weekend. Spent some time looking through its documentation and eventually found Windows drivers for communicating with each component (the USB dongle and the application board) through a virtual COM interface. The boards run a simple "chat" application by default so you can see the RF communication between them by typing into one COM terminal and watching it appear at the other end. I tested flashing another couple of sample applications, in particular one that is mentioned in the documentation that contains a number of commands for testing functionality. (The LED commands didn't seem to actually control the LEDs, but otherwise it seemed to function as described in the docs so I assume I'm still on the right track...) All in all an interesting intro and next week I'll start looking into what it's going to take to get Contiki on to the boards.

23

Mar

2014

Wrote and handed in my honours proposal on Friday(/Saturday), in the process doing a lot more research into the 6LoWPAN/RPL/CoAP stack and compiling reading material for future reference. I wrote my proposal in LaTeX also, which is new to me -- I figured it would be useful to learn now in order to use efficiently later.

My project is fairly open ended right now (evaluating the state of the art of 802.15.4 CoAP security), as nailing down goals is still going to involve further research. I found one paper in particular titled "Security of CoAP-based End-to-End Scenarios for the Internet of Things" (a master's thesis) that I think could be very relevant and perhaps help narrow my focus, but the thesis doesn't appear to be available online anywhere. Now that I've finished my initial proposal I may look at contacting the author.

14

Mar

2014

Spent a few hours this week looking into 802.15.4, some implementations of it and common protocol stacks, which will be relevant to my honours project this year. Wrote a quick blurb outlining my objectives that will probably have changed significantly by the time I write my proposal next week.

The blurb: 802.15.4 is an IEEE standard for the physical and MAC layers of highly resource-constrained, low speed wireless personal area networks. Protocols at higher layers allow communication with other devices: 6LoWPAN, an implementation of IPv6 over 802.15.4, allows communication with any other IPv6 devices also bridged into the network. The security considerations of technologies such as these are increasingly scrutinised. Existing security standards are not viable on resource-constrained networks, and as yet, no solutions for this scenario have been standardised. This project therefore seeks to evaluate proposed solutions for achieving fully secure communication on an IP-based Internet of Things.

Perhaps instead of security, another aspect I would like to look into is the deployment of HTTP and UPnP on an 802.15.4 network, which would be useful in connecting IoT devices.

18

Feb

2014

Slow final week, mostly spent fixing lots of minor issues here and there. I also added tooltips to the smokeping graph and did some work on improving the usefulness of information in legend tooltips. I have some extra clean up to do as I still have a few open branches, so I'll address those over the next week or so.

Wrote a report to hand off to the faculty, created a slideshow and wrote some notes for the presentation on Monday (which went very well).

03

Feb

2014

I thought it would be a good idea to start off the week with more refactoring and reorganising the Cuz Javascript folder structure, since it would cause minimal disruption while everyone else is away. After this was done I started going through points from the todo list on the whiteboard:

  • Reimplemented History.js based tab switching - this time using AJAX to send a request for the appropriate view ID before switching to it (had previously not been doing this, which caused problems). Functionally this works well now, but could do with a loading spinner to indicate that the page is doing something while it is waiting to receive the view ID it needs to switch to.

  • Made page titles consistent. Removed redundant strings in titles such as "CUZ - Cuz - subtitle". Titles are now always prepended with "CUZ - " at the lowest level, so higher level titles should omit it.

  • Added a new library for detecting timezone + DST and matching with a string location representation (e.g. "Pacific/Auckland"). This should be a bit nicer than the hacky timezone function that depended largely on each browser's timezone representation.

  • Work on tooltips in modal dialogs. Started using popovers instead of tooltips for displaying descriptions of field headings (but still use tooltips for radio button descriptions etc).

I made some more UI changes, one of the more noticeable being that I have replaced the Source Sans Pro font with the Roboto family (Roboto, Roboto Condensed and Roboto Slab), which I think suit the project a bit more.

I modified the Flotr2 Hit plugin to use Bootstrap tooltips instead of its standard tooltips, and made these appear relative to the mouse cursor or part of the graph being hovered over. This should help to unify our aesthetic and also solves a problem we had with text in Flotr2 tooltips overflowing off the side of the page.

I did some more work on the traceroute map, updating it to work with recent changes to the way graphs load (no loading bars and made visible as soon as data is available). Once I'd figured out the new structure I was actually able to remove a lot of the code I already had in the traceroute map thanks to this, as it had already been doing something similar - attempting to process data as soon as it was available and subsequently displaying the graph if everything had finished loading. I started working on a fix for summary data being too highly aggregated to display anything useful, with the idea that (with some restrictions) the graph should load data for the summary graph at the same resolution as the detail graph. In order to accomplish this we must request data for the summary graph at the same interval as the current detail interval. This gets pretty crazy at super high resolution however, and the code is very rough so I need to refine this.