The theme is fairly basic, but removes most of the images which should help with resources and I think, make the Neo more responsive.

The theme itself is based on “Clearlooks-DarkCoffee” by Franco Gotusso (sorry no link). Essentially I’ve merged bits from the original Openmoko theme and the Clearlooks-DarkCoffee themes picking the parts I wanted from each, but with the primary goal of making thinks work faster.

update: I’ve been getting requests for the theme so I am making is available for download, although it is a work in progress so will change in the future. When you untar the archive it will create an openmoko-standard-2 folder, replace the existing one in /usr/share/themes/ on your Neo1973.

Mar

8

Ok, we all know that the Neo 1973 GTA01 power management isn’t quite there yet but we’ve had the recent good news that NXP have made the user manual available for the PCF50633;

“We have carefully reconsidered how to best serve the OpenMoko community in supporting our PCF50633 product, and our decision has been to allow you to publish the full User Manual on the OpenMoko website. This is more effective for the development community then having to reference to 2 documents, being the DS already sent to you and the addendum containing the register description. We therefore prefer that the full UM get’s published. The Company Confidential notice has been removed. We hope to see the successful application of our device and hope to see many OpenMoko products in the market, using our PCF50633.”

So really, we should have hundreds of pairs of eyes looking at this for the GTA02. Anyway, in the meantime I’ve been testing out a little battery pack, supplied by Portable Power Supplies in the UK, which is charged and charges via USB ports. Just the ticket for the Neo GTA01. The unit takes an initial, approximate 6 hours to charge and can be done from a standard USB port on a desktop or laptop. There is also a wall charger available but this obviously bumps up the price. Once charged the unit will happily sit there for months at a time doing nothing, which makes for a good emergency backup. Of course the battery pack will not indicate to the Neo that it can do fast charging but it is capable of doing so – indeed it can serve up a healthy 700ma – but that problem is solved by Bobby Martin (wurp2 irc nick) who has produced a python application to help out. This little application allows you to force the Neo to do fast charging (draw 500ma). Obviously by doing this you override the safety checks, but as I already know that the battery pack is capable of serving more than the Neo will take there’s really no risk here. So far my Neo has been running off it for more than 24 hours and I’d expect it to go on for a lot longer too. This is going to mean that I don’t have to turn off my Neo to save power, especially when I do those overnight trips to and from The Netherlands. I’ll update here when the battery eventually dies, I’m expecting at least 3 or 4 days but we’ll see.

update:at about 4am this morning the Neo had managed to suck the life out of the battery pack and its own battery. This is horrific, showing just how thirsty a Neo is. The total time ended up at about 30 hours, but I’m going to rerun the test to be sure.

update 2:I’ve repeated the test 2 more times now and the results are very similar, sadly.

Mar

2

I recently read quite a bit of FUD and really felt that it was worth comment even if only as a counter to the points made when someone Google’s the Neo 1973 / Openmoko. I’ll take on each of the points made and correct what is needed. Oh, and just for the record, this text represents my opinions – no-one else’s.

“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.

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.

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.

Mar

1

Mickey Lauer recently told us about some interesting developments presented at FOSDEM. More work has taken place and images can now be built – so as always that’s what I’m going to do. I’ll add this to my regular building regime – although the rate of change in this image will probably be a little slower than the main Openmoko and ScaredyCat images . The first one has already been uploaded to my buildhost so you can test it out for yourself right now. Please remember that although it works and you can make and receive calls this is experimental stuff. As long as you bear this in mind everyone will be happy.

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.

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).

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.