apt-get install libtool libusb-dev fuse-utils libfuse-dev swig python2.6-dev tcl8.4-dev php5-dev

You don’t actually have to have Python, Tcl or php5 installed if you don’t want them they add to the interfaces you can use with OWFS – unless you specifically don’t want them you may as well include them. Once the installs above have completed you’ll need to get a copy of OWFS – be sure to download the latest version of it.

Update : I’ve rolled back to using 2.8p4 since 2.8p5 seems to have some problems with owserver (owfs still works fine).

Once you’ve downloaded you’ll see the file is called something like owfs-2.8p5.tar.gz – this file name is made up of owfs-[version of owfs].tar.gz In my case I have version 2.8p5. Your version may differ, don’t worry about that (unless it’s older!). Now extract the tarball with

tar -zxvf owfs-2.8p5.tar.gz

replacing the file name with whichever version you downloaded. This will extract a lot of files and place them in a directory with the same name as the file you downloaded, minus the ‘.tar.gz’. Move to that directory with

cd owfs-2.8p5

now we need to run the configure and make scripts. First configure, if this fails make sure you have all the dependencies required.

./configure

this will spit out reams of text which really only matters if something goes wrong. The last few lines should be something like this

Current configuration:

Now we build OWFS using make

make

After some churning, spewing output, cpu usage and warning messages (ignore them), which may all take 10 minutes or more depending on your cpu and memory, you should get your prompt back. Finally install owfs – do this as root.

make install

Since we need to mount the OWFS somewhere we create a directory

mkdir /var/lib/1wire

Ok, so now we come to the hardware side of things – I got my LinkUSBi from HomeChip – the ‘i’ variant has it’s own identity which may or may not be useful to you. If I’m honest I accidentally picked the ‘i’ version and could have easily saved 80 pence and gone for the non-‘i’ version without trouble – Quick Note, as I write this Quinten has had some issues that need investigation, he has the non-‘i’ variant – for now I’d stick with the ‘i’ variant that we know works. I’ll update once I get more information about the issue. Turns out that version 2.8p4 of OWFS worked with the LinkUSB for Quinten. The LinkUSB or LinkUSBi is the interface to 1-Wire devices, so now’s the time to plug it in. Be aware that if you have other FTDI devices you might want to set up some udev rules. This is what I have in a file called /etc/udev/rules.d/60-usb-serial.rules


# /etc/udev/rules.d/60-usb-serial.rules
# Determine XBEE, Current Cost and 1wire USB ports

Since I have 3 USB serial devices, a currentcost unit, some Xbee based wireless 1-wire devices I made and the LinkUSBi, two of which are FTDI I need to identify each so use the ATTRS{serial} to uniquely identify the LinkUSBi via its serial number. You can glean the serial number by using

lsusb -vv

and look at the output for the serial number of device you’re interested it. Once our LinkUSBi is connected and detected we can mount OWFS with

/opt/owfs/bin/owfs -d /dev/1wire -m /var/lib/1wire

Note that I use -d/dev/1wire because my udev rules create a symlink. If you don’t create the symlink then your device will be something like /dev/ttyUSBx – where x = a number. Now we can look at any attached devices with

# ls /var/lib/1wire/
01.BA0E0E140000 28.1842A1020000 alarm bus.0 settings simultaneous statistics structure system uncached

The 01.XXXXXX device is the LinkUSBi and the 20.XXXXX device is a DS18S20 temperature sensor. To read the output of the temperature sensor we simply do

cat /var/lib/1wire/28.1842A1020000/temperature
16.0625

As you can see the temperature is a rather chilly 16.0625 degrees Celsius. Stuart Poulton has some 1-Wire kits available to buy for creating some domestic environment friendly temperature sensors and Quinten has some good pictures of them. Kevin has also got some newer pictures up – thanks for the headsup Kevin.

Update 1: More pictures are available.

Update 2: Pictures from day 3 are available now.

Update 3: Pictures from day 4 are available now. There are also some shots of Taipei

There are of course ways around this and I took the plunge with a Kalyway 10.5.2 iso. My laptop is an Acer Aspire 3692 WLMI which originally came with an 80GB hard drive which I have already upgraded to a 160GB drive. Since I was only going to be testing this out I wasn’t about to erase my current linux install. I dusted off the the old 80GB drive and swapped it out with the 160GB drive and kicked off the install. I actually did the install a couple of times to get used to how Mac people do stuff.

Some things just worked, my little Trust BT2400p bluetooth dongle, WiFi, Audio, Graphics all just worked. I was floored. Of course there were a few things that didn’t work but they don’t work under linux either, namely the Orbicam and the internal card reader – neither of which I really give a stuff about.

Actually this install boots slower than the original Kalyway 10.5.1 install I had a few hours earlier. Sorry about the dumb auto focus on the camera – or is it a Steve Jobs distortion field?

Obviously the multimedia buttons don’t work and rather annoyingly the scrolling button (between the left and right mouse buttons) doesn’t work either. Sleep mode seems to need a bit of work. Well, it’s not the sleeping, it’s the waking up – it just doesn’t. One other thing I did notice was how quick my laptop boots with OSX, it beats my SuSe 10.2 install into a cocked hat.

While most things worked fine I do still have one concern – compatability. Compatability not with Windows, but with linux. Everything I do now is done using linux and I need to be able to continue doing those things if I were to switch to a Mac. So far things are looking good. Right now I’m just off to create my own .mac service…

The next change is due to a request from Taki asking for tangogps to be preconfigured to use the sd card for map and track storage. So now, by default, maps on my builds are stored in:

/media/card/tangogps/Maps/OSM/


and track logs are stored in

/media/card/tangogps/logs/


This should be a little more useful and wont fill up your flash with tiles.

Next up we have a little script that starts on boot, checks to see if you have the gllin ipk ( gllin_1.0+r350-r0_fic-gta01.ipk ) in the root of your sd card. If it’s there it will automatically get installed for you – Very useful post-flash. The script will also replace the standard gllin script with the one from the tangogps site. Why? Well, because tangogps and gpsd are in the image too! Shortly, I’m hoping to provide a pre-downloaded series of tiles for download too. The good news is now you can have gps and a gps application ready for you immediately. Oh one last thing. If you create a directory on your sd card called local you can create bin and/or sbin directories and have applications run straight from there – all those little utils you need to install again after each flash now have a permanent home.

All of these are part of the image, you do not need to install anything extra, unless you want to

Update: The bluetooth keyboard script is much more wizzy now that I’ve added Zenity to the image and use that so you can now pick the keyboard you want to connect to from the list of devices. I’ve also added some notify calls so that you can see what is going on during the script.

312 ls
216 cd
108 vi
44 bitbake
24 ssh
23 cp
20 make
17 mv
17 mkdir
17 find

“First of all OpenEmbedded based systems are harder to build, due to the dependency of monotone and the properitary, OE-only, bitbake, and then even another MokoMakefile build wrapper.”

First of all any system that you know nothing about it hard to use. The use of monotone is not an issue, I use a version just for building my OE stuff. Calling bitbake propriatory is like suggesting that every kernel module is propriatory. Bitbake is used to ‘bake’ (make) the recipes (.bb files) and is “derived from Portage, which is the package management system used by the Gentoo Linux distribution.” The source is freely available at berlios – why is there an issue here? It also appears that this author doesn’t understand the role that the MokoMakefile plays. The MokoMakefile was developed by Rod Whitby to help people who are new to OE and OM build and setup it is not part of Openmoko or OpenEmbedded. Really, if they had even bothered to read the wiki entry for it they would have seen this. I guess it’s easier to spout bile than be accurate.

“OpenMoko also is glibc and sysvinit based…”

Ok, I’ll let this slide since it’s true and just the author’s opinion on what is or is not suitable. I’ll come to the speed issue later.

“Forthermore OpenMoko comes with custom Gtk+ widgets and custom Moko libraries and applications, where Gtk+ PDA / phone applications are already available”

For a start “So what?”. Are you suggesting that no one develops anything that already exists? Should we have one email application, one word processor? What about one operating system? Clearly that gripe at Openmoko is just irrelavant. Furthermore you can actually build gpe applications for the Openmoko platform if you want. Take a quick look at what’s installed and you’ll even see that gpe-scap – what we use for screenshots is installed by default.

“yet another Gtk+ PDA / phone application stack equals reinventing the wheel.”

Actually, this is how progress is made. Take a look at the recent work on the moko underground stuff for an example. What’s more in the very next paragraph…

“We therefore started to create a saner, smaller, fully functional T2 based target”

So you decided to reinvent the wheel? Now to your bullet points

“T2 based, no bitbake…”

So you swapped one ‘propriatory’ build system for another?

“uClibC based, frees your phone’s…”

This, we agree on, but it does make building applications outside the tree a lot easier to not use uclibc.

“not sysvinit, bootup in less than 2 minutes…”

My Neo boots in less that 2 minutes all the time.

“GPE based GUI, to re-use existing applications…”

Did you actually write anything yourself then?

“focus on UI functionality early, no endless tinkering and rewriting, “

Wow, someone who writes perfect code and a perfect interface straight off! Oh, wait.. you’re actually using other people’s code so you’re not really doing anything yourself.

“includes just one embeded scripting language…”

Openmoko doesn’t include a scripting language by default, unless you count the shell, but you can install any number of them – including lua.

“just one… …webkit.”

Openmoko uses webkit.

Nothing you have said would inspire me to even take a look at your ‘T2 based’ project, least of all your attitude. Your main gripe seems to be that FIC didn’t use your T2 build system – that and a belief that everything not written by you is crap, as evidenced by your faq.

There’s an awful lot of work gone into this by emdete (irc nick) for which he should be congratulated. Not only is it a working prototype but he has been thinking outside the box – more of this is needed for new opensource devices to make it in the marketplace. I’ve chatted to emdete on irc and he is aware of some of the shortcomings of this first release. Primarily he was keen to get a working version to demonstrate at FOSDEM, which makes sense. In the future we can look forward to a more modular approach and of course, for those of us who don’t speak German, localization.

These new images also serve as a test-bed for Mickey Lauer’s gsm mux daemon which, wonderfully, has a dbus interface, something I really would like to see in all the daemons in Openmoko.

../../libkoto/libkoto.a(koto-task-view.o): In function `on_note_activated’:
/builder/newBuild/build/tmp/work/armv4t-angstrom-linux-gnueabi/
openmoko-tasks2-0.1.0+svnr379-r1/trunk/libkoto/koto-task-view.c:261:
undefined reference to `koto_platform_edit_task’

(just in case someone feels the need to fix it – hint hint )

but that has given me a chance to start poking about with other things. One of those things happened to be smstools3. SMS Server Tools 3 (smstools3) can take an ordinary phone or gsm modem and turn it into an SMS gateway that can send and receive SMS messages. Now, I don’t have a gsm modem but I do have a Neo 1973. Within 5 minutes I had SMS Tools compiled using the Openmoko toolchain. I’ve taken to using the toolchain quite a bit for testing before I create the .bb files so I can do proper building. Once I’d got a compiled smsd, I put together a simple /etc/smsd.conf file for the Neo (listed below).

devices = NEO
logfile = /var/log/smsd.log
loglevel = 6
outgoing = /var/spool/sms/outgoing
checked = /var/spool/sms/checked
failed = /var/spool/sms/failed
incoming = /var/spool/sms/incoming

[NEO]
device = /dev/ttySAC0
baudrate=115200
incoming = yes
regular_run_interval=3600
regular_run_cmd=AT+CFUN=1
regular_run_cmd=AT+COPS
pin = 1234

Obviously the /var/spool/sms directories needed to be created too. Before you start up smsd though you need to kill off gsmd by simply issuing the command

/etc/init.d/gsmd stop

gsmd will then stop and, from what I gather, power off the gsm chip. This bit is fairly important to know, since you actually need the chip to be powered up. We can do this simply by using the command

echo 1 > /sys/devices/platform/neo1973-pm-gsm.0/power_on

smsd can then be started, if you want to stop it forking use the -t switch on the command line. Incidentally, if you want to use the regular_run_xxx commands in your configuration you need to use the latest beta of smstools3. I needed to use them to get the Neo to register with the network, particularly as I’m actually roaming while doing this. To send an sms you simply copy a text file into the /var/spool/sms/outgoing directory – The format of the file in its simplest form is

To: destination-number

message-text

That’s its most basic form, you can get much more complex. There are some very nice features in smstools particularly that you can trigger actions on the receipt of SMS messages.

design, I’d just need to tap into the LEDs and disconnect the chip they used. Before any of this was going to happen I needed to build some sort of prototype to at least be sure that the concept was going to work. Since I didn’t have any RGB LEDs or even one of each red, green and blue I had to settle for a small LED board that had come from an old piece of equipment that I’d bought, literally, just for the parts. There was a slight problem. The led board was red, green and errm… orange. It didn’t really matter at this stage, I was only proving the code and making sure that I could get the whole idea to work before destroying the perfectly useless light globes.

The software side was also fairly straight forward too. In the end I used the SimpleMessageSystem library to handle the serial data since I kept running into issues with the standard serial I/O routines. The SimpleMessageSystem routines basically use white space as variable separators and a <CR> to signify the end of input.

Each of the colour channels can have a value between 0 (zero) and 255 which gives a lot of variation. There’s also the option to pulse the mixed colours.

Initially I was just going to have the 3 LEDs change to their relative brightness but then I hit on the idea of having them fade up and down to the correct value. I have to say it looks much better with the gradual change, although I might just add the option of selecting either gradual or instant to the parameter list.

Now, with a simple command, I can set the RGB value of my light globe.

./rgb-globe -l -b 9600 -p/dev/ttyUSB0 -s “1 255 50 0”

The original code for the command line application came from Tod Kurt and was written to be able to send serial data to the Arduino. I did make some modifications, including a couple of virtual slappings of Tod for using strcpy – I still don’t understand why people don’t pretend that function just does not exist.

I’m considering writing a small GTK application that just has a colour picker to select colours, but that would be in addition to the command line application since this is designed to be used from things like scripts or mail and IM notifications or, as I suspect mine will, build status information for my Openmoko buildhost. The only real issue at the moment is that it’s really not bright enough, I think I need to rethink the orb – maybe it’ll be better at night…

I look forward to finding an Openmoko channel there soon.

update I’ve just snagged myself one of these from a local shop. My SuSe 10.2 install saw it immediately and kbluetooth reported it as Bluetooth 2.0 + EDR which, in theory, should give 3Mbit /sec.

Update 2 This device uses hci_usb as the driver. It’s based on the Cambridge Silicon chipset.

Itunes sucks as it is, but since I don’t use Macs or Windows it means I can’t use that for my music. It’s a bit of a blessing in reality. There are a number of applications for Linux which allow you to manage your iPod, in the end I went with the simple to use, opensource gnupod Perl scripts. The best part of these scripts is the ability to use regex for generating the playlists, something that’s very important with the IMIV.

The IMIV will only work with MELBUS (Mitsubishi Electronics Bus) based Volvo systems, newer Volvos (XC90, new model S40/V50/C70 and S80) use MOST which is apparently fiber optic based.