/13 May

/11 May

/4 May

/15 April

/12 April

/6 April

/26 March

/9 March

/4 March

/24 Feb

/NsluInstall

/AboutNumberOne

Commander's Log

Stardate 20100224

First experiences with the Sentilla Perk

I acquired a Sentilla Perk kit from Prof. Herman today. It contained, to my pleasant surprise, two motes, but one of them was missing a metal plate with a spring in the battery compartment. After getting that fixed and following the quick start guide, I started playing around with the sample applications.

The motes seemed to work fine and the development process is relatively painless, though quite slow (it takes about a minute to compile, install, and run a program on the mote).

I set up and got running the Charting example application from the Sentilla Labs site. This application uses a freeware Java library called Processing to graphically display sensor values from the mote. I was a little disappointed in the sampling rate and wanted to see if there was a bottleneck in wireless data transfer to the host computer, so I tried modifying the code to use a message buffer instead of just sending a reading every time it got one. I started with a buffer size of 128; this is what the code looks like:

public static class JCreateMessage implements Serializable

.... JCreateMessage jmsg[] = new JCreateMessage[128];

I was dismayed to find that this causes an OutOfMemoryError. That's right; the mote doesn't even have enough memory for 128 JCreateMessages. Using a buffer size of 4 gets rid of the error and has expected results, so I don't think there is anything wrong with my code. 16 is the largest power of two I can use without it crashing.

I am also a little disappointed in the transmission speed. The project I was working with serializes the JCreateMessage and sends it to the host application which can then use it as data. Unfortunately, the process is very slow. On the Sentilla user forums there is a thread about this where someone compares the time it takes to send 1000 one-byte packets via the default send() interface on a JCreate compared to the same JCreate running TinyOS. The factory mote takes over 200 seconds to send those packets; running TinyOS it takes less than 10 seconds.

Stardate 20100208

My new girlfriend:

http://en.academic.ru/pictures/enwiki/68/DeannaTroi.jpg

Yeah, that's right. After years of relentlessly hitting on the ship counsellor (by the way, seriously? We have a person on board solely devoted to therapy? And she sits next to the captain all day?), I finally nailed her. Now I'm getting hot Betazoid action, all from the comforts of my ship quarters. The only downside is that I can't lie to her, but on the other hand she never asks me how I feel or think about anything.

You know what the best part of all this is? Skin-tight one-pieces.

Stardate 20100203

Yesterday I, Geoff, and some others attempted to compile a working Linux kernel on one of the machines in the lab. I can't remember the name of the machine, but it was the one with the large screen farthest away from the door. We used "lj1" for the EXTRAVERSION. "lj" stands for "Little Jimmy" and 1 means the first version of the lj kernel. This is the notation I traditionally use when configuring my own kernels.

We never got the new kernel to boot. Our first problem was that we did not compile in ext3 support. This was surprising because our root filesystem was ext4. It turns out the /boot, or some elements in /boot, are always done in ext3.

After compiling in ext3 support, we managed to get the kernel to mount the root filesystem, but then we were face with another problem. On boot, the kernel would eventually complain about some bad ext2 blocks or something, recommending that we run fsck. We double checked that we had ext2 support in the kernel and even selected all the optional stuff on the ext* filesystems but continued to get the same error. It was about this time that I had to leave to go to a meeting.

A couple of notes are in order. First, I think that the purpose of this assignment is to practice building a minimal kernel where "minimal" refers to the runtime kernel, not the disk image. This means that merely changing options from built-in to module does not really address the assignment since modules end up getting loaded at runtime anyway. Second, if you can start X in your kernel or get networking, then you aren't addressing the assignment since neither of those abilities are required to mount a USB stick.


1MainPage (last edited 2014-05-25 18:15:48 by localhost)