|
|
| 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...
| + | |
all documentation about my initiatives with the Neo1973 and the Freerunner are collected under http://pyneo.org/ .
