User:Emdete

From Openmoko

(Difference between revisions)
Jump to: navigation, search
(Replacing page with '== pyneo.org == all documentation about my initiatives with the Neo1973 and the Freerunner are collected under http://pyneo.org/ .')
 
Line 1: Line 1:
== Moko Underground ==
+
== pyneo.org ==
  
i started a project called zad months ago and developed a stack of daemons for it. see more at about it at http://neo1973-germany.de/wiki/Zad. i showed it at the fosdem and the developer community showed some interest in it.
+
all documentation about my initiatives with the Neo1973 and the Freerunner are collected under http://pyneo.org/ .
 
+
== GTA01 first impressions ==
+
 
+
I got my neo1973 gta01 some month ago now and want to share my experience 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:
+
 
+
{| align="center" style="margin:0em;" cellspacing="0" cellpadding="3" border="1"
+
! *
+
! software in use
+
! experience
+
! hints
+
|-
+
! [[Manually_using_GSM|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".
+
|-
+
! [[Manually_using_GPRS|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.
+
|-
+
! [[Manually_using_GPS|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.
+
|
+
|-
+
! [[Manually_using_Bluetooth|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.
+
 
+
== statistics ==
+
 
+
=== image by rrd ===
+
 
+
this is the first impression on a graph from the stats i took today:
+
 
+
[[Image:Drraw.png|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...
+

Latest revision as of 18:13, 17 February 2009

[edit] pyneo.org

all documentation about my initiatives with the Neo1973 and the Freerunner are collected under http://pyneo.org/ .

Personal tools

pyneo.org

all documentation about my initiatives with the Neo1973 and the Freerunner are collected under http://pyneo.org/ .