The mission of the rocket was to experiment with materials physics under conditions of weightlessness. The Freerunner had nothing to do with this experiments and was only on board to verify that it survives the launch, travel and landing. Battery, GSM and GPS antenna has been removed before launch. Everything survived. During the flight the accelerometers have been used to collect measurements.

In May this year it will enjoy its second trip into space. The case was designed and build to offer space for the Freerunner as well as an extension board connected to it. The board is connected to the debug board connector of the Freerunner which offers a SPI and an I2C bus. It was designed to hold different sensors the Freerunner does not offer and is equipped with a BMP085 pressure sensor and two gyroscopes. The Melexis MLX90609 and the Sensonor SAR100.

Over the next month I'll working on drivers for these two gyroscopes and after the flight we will see if the chips survived and if the data they had produced will show that they are good enough for further testing.

All in all this shows pretty nicely how an open device with available schematics, CAD files and hardware interfaces can serve together with an open software stack for vertical markets. Be it for research purpose like in this case or a crazy business idea on the other side. The fact that you have all resources to understand the electrical design as well as being able to make changes over the complete software stack brings you into the position to easily adapt it for your needs.

Some more picture with a higher resolution can be found here.

UPDATE: Fix typos and rewrite some parts so people have a chance to understand it.

Both of my talks went ok I think, but its always hard to judge on your own talks. People were asking questions directly after and also over the next days. This kind of interest is all you can ask for as a speaker. :)

It was not only my first FOSS.IN but also my first visit in India at all. A new country, a new culture and a lot of things I need to think about is all I can say about it right now. I like it thats sure.

The format of not only advocating on FOSS, but understanding and embracing it as well as the technology around it is something I could not agree more with. It is this kind of understanding which makes innovation possible. Think about technology and products not only the way the company selling it likes you to. Open up your mind and think how else it can be used for something better.

Let me finish with a big thank you for the complete FOSS.IN team. They did a great job in getting a high-class conference going and bringing people together to collaborate and inspire. Their hospitality and energy needs to be seen somewhere else.

I like a lot what I read there. Linux Kernel, OpenEmbedded, dbus based IPC, OMAP SoC, root on SD and more. I would design it mostly the same way. Wait, I'm missing 300 develoeprs and 300 Millions vanture capital here. To bad.

Really waiting for the kernel sources. It is using a MSM6xxx based modem for CDMA and I would bet just the brother, perhaps MSM6281 like the Samsung Omnia, for the GSM variant. As I'm hacking on the Omnia right know I would of cours be interested in a kernel driver to drive the modem. On the Omnia it is connected via a dual port ram chip that interfaces to the PXA312 on the other side.

This also is kinda similar to the MSM7k SoC's that are used in the available Android phones. Just that AP, ram and BP are in the same chip here.

And the driver for the CDMA modem should also be pretty similar to the GSM variant. That gives me a little hope that maybe a driver for such a dual port ram setup will be in the Palm Pre kernel sources. Let me know if you have details here.

I really hoped for modem communication during the weekend. That did not happen, but we start to get a real good understanding how the system works. We documented all the dirty details in the wiki.

Wish us look, or better help us, to get get the modem working soon. Then it is finally time to poke the rest of the FSO team to support it as a target device.

The main focus is to get the modem communication working. We are pretty sure that we understand how the modem is connected and how it is supposed to get driven. Even better Harald already wrote a driver for it. SPI slave part, linux tty layer integration, state machine it is all there. Still after nights and days debugging it we still not have it working.

This turns out into a major blocker now. Without the modem communication we can't start serious FSO integration and if the progress on this stalls to long it will be doomed as yet another project that may still make fun, but would not get the momentum it deserves, hardware is no longer available and so forth.

So we hope to get some progress with a high motivated face-to-face meeting over the weekend. We will send out a status afterwards. Stay tuned.

It's the user in me screaming for one of this fancy new smartphones. Get one and be happy. It's the 'I want to believe' [1] factor that let me think that Apple's iPhone or Google's G1 are exactly the phone I need.

Starting to get into a rush buying this new toy my other alter ego shows up. The tinkerer. These guy that ask inconvenient questions like what to do when I reach the end of the supported features? Neither the iPhone nor the G1 seem to support dial up or network connection via bluetooth. Damn tinkerer, life could be that easy. Still he has a valid point. Not having such a thing on the product spec is fine with me. There is always something that you have to scratch for a polished product.

But things like this are showing me the trouble I always get when trying to use these non-open devices. I step back then and think that my Freerunner, main phone since FSO MS4, may not be my taste in ID and needs a lot more work from the software side, but it gives me the freedom I want.

The Android dev phone 1 (aka unlocked G1) could be an option to work with FSO on it as it allows to flash unsigned images unlike the G1 from t-mobile. But a quick research turns up 600USD as cost for it. (400 the device, 180 shipping to germany and 25 developer registration fee. lol). Not an amount I'm willing to pay and then also invest time in working on it.

[1] Book recommendation: Neal Stephenson, In the beginning was the commandline http://nealstephenson.com/command/

For now we are using the SiRF III chip in NMEA mode. In opposite to the sirf binary mode we are not able to upload allmanac or other fancy things. Still we get a fast TTFF whcih lets me hope that the chip saves this useful data on its own.

One intereresting bit was that we need to drive the UART with a 57600 baudrate to get it working (For ublox we used 9600 so far). Once you figured this out it also tells you about it in a NMEA banner. A bit late. :)

$PSRFTXT,Version GSWLT3.0.0HT_3.1.01.00-SDKLT001P1.00b *4A
$PSRFTXT,ETEN-20070119-NMEA57600_S_EE-LX*2C

After this bad joke we can come to some real infos. Harald is working on the kernel full steam ahead. Good progress so far. Sometimes faster sometimes slower.

From my side I concentraded on the OE side so far. Booting into a fso-image is working now. With every new hardware feature the kernel gets support for we can start to integrate it into FSO. GPS and BT are good candidates as they are just attached to UARTs and the enabling/disabling via GPIOs is already in the kernel.

A 'cat /dev/ttySAC2' already gives out some NMEA stancas. SiRF III binary protocol has to wait a bit longer. Next week I'll have some fun with making use of the GPS in frameword. Stay tuned.

If you do software development for profit it is very likely that you work on software you never really use. Isn't this a scary thing? I man how should you know what works and what not? Are you finished when you completed 100% of the spec?

In the free software world on the other hand developers are often driven by scratching own itches. Fixing things they found bad or broken by using the software.

Looking at my desk I can see 7 linux based mobile phones around. Most of the time I used non-Neos as my phone for the daily use. This does not make me better then others devs not using the code they produce. Holger does it, Daniel does it and many colleagues in Taiwan does it. It was time to feel the pain yourself.

Over a week now I'm using my Freerunner as primary phone. Loaded with the latest and hottest on our way to FSO milestone 4. It is an interesting journey. Showing me how much I already miss compared to other phones. Also showing me how much we need to care about stabilize better for our milestones. MS3 was bad in this regard. We hope to do better with MS4.

During this journey I started to write down what annoys me. Annoyes me as a user. Besides all kind of smaller and bigger issues I had to learn that ZenPhone is really not a UI for the daily use. It is a testing apps to expose our interfaces, not more. Really looking forward to the UIs the SHR guys and raster are working on. Perhaps even a nice paroli. We will see.

Still I'm looking forward to it. This time I hopefully have some time to attend the technically talks. I look at you kernel track. And let Harald de-mystify the security of the micro waves around us.