View source for User:Emdete

From Openmoko

Jump to: navigation, search

You do not have permission to edit this page, for the following reasons:

  • The action you have requested is limited to users in the group: Administrators.
  • You must confirm your email address before editing pages. Please set and validate your email address through your user preferences.

You can view and copy the source of this page:

Return to User:Emdete.

Personal tools

I got my neo1973 gta01 some month ago now and want to share my expiriences with it. Because the gui at that point did not work at all and i was interested to develop an own gui anyway i deinstalled all gui stuff with

ipkg remove -recursive <all x11 libs>

(i don't remember which one and can't take a look because they are gone on my neo right now). Now i started to check all low-level functionality i thought i would need for my application with simple scripts to start them and python programs to test them (see the edits i made on the pages "manually using [GSM|GPRS|GPS|BT]" here in the wiki). With that basis i was able to do longrunning tests. here is the outcome:

* software in use expirience hints
GSM libgsmd did not work reliable. clients can't determine the state. i found no documentation when to issue which call (i.e. if you connect but don't get called for pin, when do you call to register into a network). is not able to decode special sms (like initiating sms for mms). sample client libgsmd-tool coredumps all the way. does not use (the glib recommended way) of using dbus. manually playing around shows something that looks like a kernel bug: linux freezes entirely. this is not a bug but a flow problem. switching on/off the modem toggles also a serial device where the kernel loggs. if there is flow control enabled the kernel waits for 'RTS' which never comes without debug board. issue the command `stty -F /dev/ttySAC0 -crtscts` before tampering around with "/sys/bus/ platform/devices/ gta01-pm-gsm.0/power_on".
GPRS pppd works well if chatscript take over everythink (like pin entry). same problems for auto-detect as mentioned with pan apply. using the options lcp-echo-interval allowed to keep a connection open over days without any problems.
GPS gllin for long running gllin some option must be changed (like named pipe and logfile output) but i never got a reliable fix for a ling time. gllin seems to have a memory leak or the like (after running for several hours cpu usage raised from about 2% to 20%). switching off logging (option -nmea) and writing to the named pipe (-np) allowed a long running gllin - otherwise the rootfs was filled up fast.
PM sys fs everything here is not documented very well. battemp show -6 (which should be in celsius), chgcur says 17213 (which would be 17A current!) while battvol is decreasing. i often encounter a neo that switches off even if it's connected to usb because the charing does not start.
BT PAN bluez-utils using internet over pan works fine while i did not figure out how to auto-detect the best way into the inter for the neo. i would prefere a fallback-rule like use usb, pan, gprs. libc makes some trouble when changing the nameserver, running processes will use a old one.
FS jffs2 if the filesystem runs full you are doomed. jffs2 is not able to delete files after that. you have to flash your neo again. i moved my logfiles, database and the like to (ext2) sd-card. i keep rootfs at around 50%.

conclusion: openmoko concentrates on nice gui stuff but the base is missing. i found not one longrunning testcase for one of the bases services of phone functionality. effect of this is the state these services are currently in.

this is the first impression on a graph from the stats i took today:

neo1973 stats

interpretation:

the top line (purple) shows the response time of a ntp request. this includes the name lookup. 2 seconds are quit okay. 10 seconds was the timeout. you can see that even after timeouts the gprs recovered. gprs works reliable fine.

the next line (blue) show the average signal of all seen satelites.

the line below () shows the count of satelites seen.

the next line (green) shows battery voltage. you see linear falling voltage until 5min before shutdown. fine.

the line "sat in use" (brown) shows how many sats are used for gps. 2 are not enough.

the last line (black) on bottom is not seen, its just zero. there is no fix all the time (quit reasonable with 2 satilites in use). i was outside all the time. about 10 satilites where seen. no fix - dont know why...