I roughly followed the guide on the wiki page, but here’s explicitely what I done.

Open two terminals (for example through USB-networking and SSH to the phone).

In the first terminal execute these commands:

/etc/init.d/gsmd stop
echo "1" > /sys/bus/platform/devices/gta01-pm-gsm.0/power_on
chown uucp.uucp /dev/ttySAC0
cu -l /dev/ttySAC0

And in the second terminal execute these commands:

mkdir -p /usr/spool/uucp
chown uucp.uucp /usr/spool/uucp
stty -F /dev/ttySAC0 crtscts

Now go back to the first terminal and play with AT-commands; I made an outgoing call as follows (responses are included):

ATE1
OK
AT+CFUN=1
ERROR
AT+CPIN="x"
OK
AT+COPS
OK
ATDy

where x is the PIN and y is the phone number (for Danes: I only used the eight digits – no leading zero or anything fancy). Please notice that there is no space whatsoever between ATD and the actual number.

I build a new kernel and rootf by issuing a

make update-makefile && make setup update openmoko-devel-image

Afterwards I went to
~/moko/build/tmp/deploy/glibc/images/neo1973

and flashed my device with

sudo ./dfu-util -a kernel -d 0x1457:0x5119 -R -D uImage-neo1973-latest.bin
 
sudo ./dfu-util -a rootfs -d 0x1457:0x5119 -R -D openmoko-devel-image-fic-gta01.jffs2

The boot time was rather long compared to earlier, I guess. Not that it actually matters for me, but I noticed it, and thought that quite a lot of changes might had been made. And apparently changes had been made. At this time I’ve actually just booted the device, hence I’ve not actually found that much, but I’ve noticed these things:

• The “Today”-label has changed to “Home” (in the upper left corner), reasonable I my opinion
• I’m now able to create my phone as a network-place through SSH in Gnome; that’s nice in order to make file-management smoothly
• To today now consists of a “huge” watch, well, I like it, but I can easily imaging not everybody does, but I suppose it’s things like this that should be made customizable later on

Here’s a couple of screenshots of the glories:

The image from qtopia.net i a bit older, but seemed to work the best, i.e. most stable, whereas the Scaredycat-version was newer. Well, I didn’t dive more into since I just wanted to try it.

Another thing is, that QPE only worked with my Telmore SIM-card (uses TDC) and not my BiBOB SIM-card (uses Sonofon). I didn’t know whether it was a general problem, so I flashed my Neo 1973 with the newest OpenMoko from http://buildhost.automated.it/OM2007.2/?M=D (21-Oct-2007 09:55). I’m currently building my own image, but I really have to go to bed, so I’ll try that one tomorrow instead and settle with the Scaredycat-version for now.

Before continuing, I’d like to say that until now I’ve never been able to make a call from OpenMoko, not even registering the SIM-card. So I’m actually really exiting. I’ll of course try both SIM-cards.

I’m currently booting OpenMoko with my Telmore SIM-card. It’s actually quite slow – and it’s not feeling any shorter by staring at it. Finally done. The Matchbox panel is again not starting, so the usual

/etc/matchbox/session

is executed, and the panel appears. Well, OpenMoko isn’t working with the Telmore SIM-card. I’ll give it a reboot and see. I’m so excited about being able to call from this, and it doesn’t work – it beginning to be a bit frustrating (although it’s a really bad skill for a developer to exhibit). After the reboot several things are working: the panel appears immediately and the screen light fades when the screen is not pressed. Despite these promising signs, I’m still not able to register the SIM.

Well, I guess I’m not going to try the BiBOB SIM-card anyway right now. The next step is to attempt some of the hacks mentioned on:

• http://wiki.openmoko.org/wiki/Kernel,
• http://wiki.openmoko.org/wiki/Manually_using_GSM, and
• http://wiki.openmoko.org/wiki/Manually_using_SMS

Goodnight!

Well, the C-coding is slowly returning (I’ve done some C-coding, but not as much as C#), but I’m still having some trouble setting a proper development environment up. That being said, I really haven’t got a whole weekend dedicated for that, but the times I’ve tried to use MokoMakefil and OE’s HelloWorld tutorial wasn’t successfully. But that’ll come later on, I assure you!

But for now, I’m just developing on my desktop, and then I’ll try to get a decen (or just running) environment up and running when the time comes.

What an excellent timing receiving such a sweetheart on a Friday!

Some optimal data structure might be quite a mess to make persistent, which lead to the selection of another data structure.

Still, I haven’t read much about this subject in regards to OpenMoko, but I think remembering something about it uses a Evolution Data Server. Well, it’s certainly a subject to investigate further – in particular to location-based reminding which I think is very exciting.

Oh, my Neo 1973 should arrive tomorrow! Yeah!

Until now GPS has primary been used for navigation (please don’t take this to literal – I know it’s been used for a lot of other stuff, too, but this is merely a statement used to widen the mind and open it for new/other approaches), but as several different kinds of products with GPS appear, one has to rethink the whole idea in order to take proper advantage of the fact of GPS (as one might call it).

(As an aside, I would like to refer to OpenMoko to justice the generalization of location-based software: it would be stupid not to have a common location-library – pick an arbitrary name for it of your own choice – instead of every little application should implement general location events on their own.)

Personally I have a couple ideas to location-based software: location-based profiling (mute, non-vibrating among others) and location-based reminders. The first is probably more self-explained than the latter, which is thought of as a when you should be reminded of something on behalf of location instead of time. These ideas has forced me to try to think of location-based software in a generic way.

The first realization is that a generic type of usage is event-driven/-based. Others probably exist, but in this post I’ll stay with the event-driven-types.

This would probably be an appropriate time to excuse for my English, and for you to accept my apology and get a cop of black power aka. coffee, tea, or whatever you fancy the most at this particular time.

As earlier mentioned, GPS has primarily been used for navigation. Here the events are whenever the driver should do anything else than just driving straight ahead, e.g. taking a turn, exiting the highway or whatever. Several software products come with ability to make favourite positions, too, and in that way creating a quick route from a favourite location. In the case of navigation, GPS is used intensely every time – assuming that it’s mostly used at new routes. The case with position-base software is slightly different – at least in some situations. In particular, I’m thinking of the two examples given earlier with location-base profiles and reminders. Here whole areas has to be saved (“Home”, “Work”, “School”, …) in such a way that it can be identified and acted upon, i.e. execution of a (system)event.

Two key observations, with a basis in the two examples given, are that it is required – or desired - to identify whenever entering or leaving an area. The solution to this problem depends highly on in which way an area is created. First the term “area” should be defined: a area is a named collection of positions. Then areas can be created in at least the following different ways:

1. a radius of the current position making the area circular; all positions are interconnected
2. a set of positions not necessarily interconnected (if some positions of the intended area are unavailable, e.g. due to access limitation)

Data-wise it is often less demanding to use the first option, but it requires more computations (it is really enough to save one location and a radius – from that it would be easy to calculate when the current position is inside that area or not). Reversely, the locations in the second option should just be saved in an appropriate data structure and then searched with a good search algorithm (depends of course on the chosen data structure). Both methods (and more?) could be offered, but the crucial question probably is, how big cells/positions are? Maybe several introductory experiments should be made. In addition, distinct users may have distinct needs, so maybe it’s best to make the location software so generic, that these and more can all be used. It’s certainly a point of interest and one requiring further focus.

Lastly I would, too, like to add another important application: the interface and cooperation with other triggers (such as time). Maybe a user would like to have a reminder when leaving an area, or at least at 3 p.m. This should be made in a natural way, and that requires a significant amount of thoughts leading to a sound architecture.

Well, still looking forward to receive my Neo 1973 so I really can address these issues. In the meanwhile I’ll start addressing these problems in an abstract level as done hitherto.

ABI Research published for some time ago an article regarding mobile marketing and Google recently published a plan of mobile advertising. With these articles in mind, I started to wonder whether some kind of cooperation with OpenMoko and Google was possible.

Of course not to force someone to receive commercials if they don’t want, but instead of using alternative channels with another purpose originally, it could be interesting to make some kind of optimal channel for commercials on mobiles. Clearly it’s something trendy right now, and why not try to take advantage of that?

I’m really looking forward to receive it so I can start to play with it I’ll of course try to write something about it in this blog.