Re: [openBmap] New cells visualisation interface on the website (beta)
Onen, glad to see openBmap gets better and better, congratulation :) best regards, mqy Onen wrote: > > Hi everyone, > > Nick did a very nice work about the visualisation interface of the cells > on the website [1]. > > You can now browse and zoom to an area, and see (depending on the level > of zoom), LACs and cells. > > When you select one item, you can click on it to see the coverage of the > item. > > This is still beta, as we encounter sometimes cells which does not > appear, or disappear after zoom in or out. But it is *very* much better > interface. > > Thanks must go to Nick! > > Onen > > [1] http://www.openBmap.org/with_osm4.php > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-openBmap--New-cells-visualisation-interface-on-the-website-%28beta%29-tp3325092p3326307.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: good bye google code
Yesterday I suffered almost same problem, also can't connect to apache.org. I asked friends for help, strange that they can connect. I suspect that it must be caused by some local problems. After adjust DNS settings restart notebook, problems disappeared. The notebook connects to internet through a TPLINK router (model:Tl-r402M) which connects to ADSL box. So, I'm really sorry, I apologize. At least it is my local problem, irrelevant to google or some firewalls. Anyway, I like google, and feel sorry and even angry whenever they suffer by some secret reasons I don't agree with. mqy, 20090723 > This is not due to Google... it's a china problem... Ask your government > to > not put many filtering equipments and routers, and latency will be better > :) -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3308717.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] omgps track disappearance
ok, hope this disaster can remind all of us: alway backup important data as early as possible:) jeremy jozwik wrote: > > On Mon, Jul 20, 2009 at 4:42 PM, mqy wrote: >> >> jeremy, >> >> You said .omgps directory is empty, do you mean only empty >> subdirectories? >> Let me explain how omgps works on directories: >> >> At start up, it check if .omgps/ exists. If not, it create .omgps/ and >> subdirectories, such as track/ screenshots/, etc. >> >> But if you link .omgps to another directory in SD card, the link file >> exists >> even if SD card fails to mount. >> Broken soft link file should trigger error dialog on omgps startup. >> >> If your partition is ext3, see this link >> http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html >> >> mqy > > on that part i was in error. i was running cd /.omgps instead of cd > ~/.omgps. > > the omgps folders exist as does the softlink to the sd card partition. > thanks for that link too. ill have to hope everything is there when i > get home and attempt a recover > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-shr-unstable--omgps-track-disappearance-tp3292182p3292703.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] omgps track disappearance
jeremy, You said .omgps directory is empty, do you mean only empty subdirectories? Let me explain how omgps works on directories: At start up, it check if .omgps/ exists. If not, it create .omgps/ and subdirectories, such as track/ screenshots/, etc. But if you link .omgps to another directory in SD card, the link file exists even if SD card fails to mount. Broken soft link file should trigger error dialog on omgps startup. If your partition is ext3, see this link http://www.xs4all.nl/~carlo17/howto/undelete_ext3.html mqy jeremy jozwik wrote: > > hello list. just saturday i went on a fairly long trip which i tracked > via omgps. just this morning i was reviewing the track. and now, only > a few minutes ago i was looking around in the track folder and > discovered there was no files of any size. > > along with that /.omgps seems to have disappeared as well. > > im pritty peeved off that my tracks are gone, is there any hope of > getting them back? > > [no rm commands were issued in the last 5 days. so im really confused] > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-shr-unstable--omgps-track-disappearance-tp3292182p3292601.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] omgps track disappearance
jerem, I mean omgps does not auto delete normal files such as track log. As of recovery, I know EXT3 is difficult to recover :( Read carefully including comments! mqy jeremy jozwik wrote: > > On Mon, Jul 20, 2009 at 4:00 PM, mqy wrote: >> >> Hi jeremy, >> >> I can confirm omgps does not issue any 'rm' commands. >> Do you link .omgps or other folds to some SD card partition? If so, that >> may >> be caused by hardware failure. >> I has similar bad experience, with SD card corruption. >> Check /media/ to see if your partitions are mounted. >> If you have a card reader, unplug SD card and try restore from a PC. >> >> May your dear data with you. >> >> best regards, >> mqy > > i did have a link from .omgps/track to mmcblk0p2. the partition was > mounted and i could move around the folder system. when i went into > the track folder and issued an LS command nothing came up. i tore out > the sd card right after i discovered the issue. > > is this a good source for an attempt at pc restoration? > http://www.linux.com/archive/articles/58142 > > also, is this a formatting issue or just a bug? > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-shr-unstable--omgps-track-disappearance-tp3292182p3292486.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
marterials from Xiangfu Liu: http://lists.qi-hardware.com/pipermail/developer/2009-July/03.html subscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer 2009/7/21 Rafael Campos (via Nabble) : > Nice geek gadget!! > (i also would like to have one) > > Do you have protypes and a working kernel? I could not stop my > internal engieering questions!! ;) > > My mainly question, rather that what is the target audience, what do > you have in mind when you design the NanoNote? Some Assistant? > > One important thing is that it has USB 2.0, and doesn't have the glamo:) > > Another important thing is MIPS!!! I only remember to develop some sw > in MIPS at University in one assembler simulator (a MIPSR2000/3000). > Other architecture to learn!! ;) > > Regards > > -- > ___ > Rafael Campos > o0 Methril 0o > http://openblog.methril.net/ > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > View message @ > http://n2.nabble.com/New-Open-Hardware-company-tp3289658p3292322.html > To unsubscribe from Re: New Open Hardware company, click here. > -- View this message in context: http://n2.nabble.com/New-Open-Hardware-company-tp3289658p3292386.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] omgps track disappearance
Hi jeremy, I can confirm omgps does not issue any 'rm' commands. Do you link .omgps or other folds to some SD card partition? If so, that may be caused by hardware failure. I has similar bad experience, with SD card corruption. Check /media/ to see if your partitions are mounted. If you have a card reader, unplug SD card and try restore from a PC. May your dear data with you. best regards, mqy jeremy jozwik wrote: > > hello list. just saturday i went on a fairly long trip which i tracked > via omgps. just this morning i was reviewing the track. and now, only > a few minutes ago i was looking around in the track folder and > discovered there was no files of any size. > > along with that /.omgps seems to have disappeared as well. > > im pritty peeved off that my tracks are gone, is there any hope of > getting them back? > > [no rm commands were issued in the last 5 days. so im really confused] > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-shr-unstable--omgps-track-disappearance-tp3292182p3292351.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
Last night the hairdresser told me he want to learn programming, even pay for training :) steven mosher wrote: > > That's cool. It's kinda funny every female I have showed the device to > wants one. And they alreadyown Iphones and blackberry's. "perfect for my > purse!" weird I didnt expect that. One's learning > PHP .. it would be her Personal Hack Pad. hehe. > > On Mon, Jul 20, 2009 at 12:51 PM, Sebastian Krzyszkowiak < > seba.d...@gmail.com> wrote: > >> On 7/20/09, David Ford wrote: >> > any general price range and is the usb port OTG for both client & host? >> >> Question++ >> >> I'm interested in programming *on* something like that, and my >> girlfriend is interested in learning programming when she see what I'm >> doing on my Freerunner ;) Keyboard seems to be ok for programming, so >> i'm generally interested. >> >> Cheers, >> dos >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/New-Open-Hardware-company-tp3289658p3291820.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: good bye google code
From launchpad web site: "Launchpad is a unique collaboration and Bazaar code hosting platform for software projects". Another VCS! Thanks for the tip, I prefer github for now :) I'm using eclipse, CVS and SVN are well supported, whereas git plugin does not fully function. With github.com, I can use git command, plus gitk program. BTW, it seems projects.openmoko.org runs a outdated program, at least needs further maintenance. It does not allow deleting a project by project admin, even if the project is empty. And sourceforge.net is dressed up like a young girl :D regards, mqy Patryk Benderz wrote: > >> Would you please avoid registering your new projects to google code? > You might want to try http://launchpad.net . it is free also and allow > you to delete your code if you do not like it or make a mistake. > Sourceforge doesn't allow to delete code :( > > -- > Kind Regards > > Patryk Benderz > IT Specialist > Linux Registered User #377521 > +48 22 538 6292 > > ERSTE Securities Polska S.A. > ul. Królewska 16 > Warszawa 00-103 > KRS 065121 > NIP 526-10-27-638 > REGON 011136053 > Kapitał akcyjny: 15.500.000 złotych (w pełni opłacony) > > This message and any attached files are confidential and intended solely > for the addressee(s). Any publication, transmission or other use of the > information by a person or entity other than the intended addressee is > prohibited. If you receive this in error please contact the sender and > delete the material. The sender does not accept liability for any errors > or omissions as a result of the transmission. > > > Email secured by Check Point > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3288381.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: good bye google code
>> I like google search, but google lives a bad life in my country. > > This is not due to Google... it's a china problem... Ask your government to > not put many filtering equipments and routers, and latency will be better > :) I don't think the abnormal cases were caused by just latency. Thanks for the tip, don't you think that your suggestion is a joke? Time to go to bed, should I enjoy the raining evening or try asking somebody in my dream? regards, mqy -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3285190.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: good bye google code
I registered to github, need some time to get used to it. My first impression is clean and efficient. Strange that can't be authorized by SVN of projects.openmoko.org. BTW, a new omgps installer ipk package was released, download from omgps.googlecode.com. regards, mqy Bumbl wrote: > > you might check out github > which really rocks and is free for opensource projects > > 2009/7/17 jeremy jozwik > >> search function is very bad as well. the only way to get to the intone >> page is to search google for c_c >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3281440.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: good bye google code
> you can't do the smalles things w/o having a google account -- not even > contact authors of google code projects, let alone reporting bugs. I like google search, but google lives a bad life in my country. I dislike the "feature" of google code: it increases SVN revision number whenever you edit a wiki page! -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3277649.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
good bye google code
Dear all: I feel very bad. It took me hours to submit 2 files to google code. This is the second bad day since omgps was registered to google code two months ago. Google search and gmail sucks too, at least from Beijing. I just registered omgps to projects.openmoko.org. Can't use sourceforge.net because it connects to google analytics. Would you please avoid registering your new projects to google code? thanks, mqy -- View this message in context: http://n2.nabble.com/good-bye-google-code-tp3277602p3277602.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR - Latest unstable] screenshot application
The value of Categories is strange. The icon is shown after I changed "Action" to "Applications" cheers, mqy 2009/7/15 Tony Berth (via Nabble) : > well 'gpe-scap.desktop' is already there! And reads: > > [Desktop Entry] > Name=Take Screenshot > Comment=Save a screenshot or upload it to http://handhelds.org/scap > Exec=gpe-scap > Terminal=0 > Type=Application > Icon=gpe-scap.png > Categories=Action > StartupNotify=False > > but don't get any icon on my Desktop. So something is wrong in that file? > > Thanks > > Tony > > On Tue, Jul 14, 2009 at 7:25 PM, mqy wrote: >> >> think about what will be captured if you issue that command from desktop >> :) >> >> One way: from Terminal (which is on desktop), issue this command: >> >> # sleep 5; gpe-scap >> >> then switch to the window you want, wait a while... >> >> Of course you can add your own gpe-scape.desktop which execute a shell >> script with content as above. >> >> >> Tony Berth wrote: >> > >> > in the latest SHR unstable, the screenshot application does run from >> > command >> > line but its icon doesn't appear on the Desktop! Should be something >> > minor >> > to fix it? >> > >> > Thanks >> > >> > Tony >> > >> > ___ >> > Openmoko community mailing list >> > commun...@... >> > http://lists.openmoko.org/mailman/listinfo/community >> > >> > >> >> -- >> View this message in context: >> http://n2.nabble.com/-SHR---Latest-unstable--screenshot-application-tp3257846p3258194.html >> Sent from the Openmoko Community mailing list archive at Nabble.com. >> >> ___ >> Openmoko community mailing list >> commun...@... >> http://lists.openmoko.org/mailman/listinfo/community > > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > View message @ > http://n2.nabble.com/-SHR---Latest-unstable--screenshot-application-tp3257846p3261725.html > To unsubscribe from Re: [SHR - Latest unstable] screenshot application, > click here. > -- View this message in context: http://n2.nabble.com/-SHR---Latest-unstable--screenshot-application-tp3257846p3264519.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR - Latest unstable] screenshot application
think about what will be captured if you issue that command from desktop :) One way: from Terminal (which is on desktop), issue this command: # sleep 5; gpe-scap then switch to the window you want, wait a while... Of course you can add your own gpe-scape.desktop which execute a shell script with content as above. Tony Berth wrote: > > in the latest SHR unstable, the screenshot application does run from > command > line but its icon doesn't appear on the Desktop! Should be something minor > to fix it? > > Thanks > > Tony > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-SHR---Latest-unstable--screenshot-application-tp3257846p3258194.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Record call.
I've had problems to record sound on SHR unstable for a couple of days. Thanks PaulFertser who helped a lot especially how to test compatibility. I just tried state files in dir /usr/share/shr/scenarii/, in stread of /usr/share/openmoko/scenarios/. # cd /usr/share/shr/scenarii # alsactl -f voip-handset.state restore # arecord -D hw -f cd -d 5 -t wav rec.wav # alsactl -f stereoout.state restore # aplay -t wav rec.wav It works like a charm (with a bit noise), with both built-in mic and Motorola A1200 headset :) -- mqy Ed Kapitein wrote: > > Hi all, > > I would like to automatically record each call i receive. > I did try to run arecord, but that doesn't record any sound (neo side or > other side) > I allready took a look at dictator, but that seems to be toying with the > state files, if i read the source code corectly ( probably not...) > > Is there a simple way to record an ongoing conversation? what would be > the input? can it be done with arecord (alsa)? > > Kind regards, > Ed > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/Record-call.-tp3239280p3255030.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hi Rask Ingemann Lambertsen, Thanks for your report, this is the first report from debian users. I haven't made a debian package yet, I'm sorry, the major problem is to setup a built environment. I've tried a bit without success, would you please give some help? These problems will be fixed as soon as possible when I can build .deb package for FRt. -- mqy 2009/7/13 Rask Ingemann Lambertsen-2 (via Nabble) : > On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: >> >> First, I must appreciate all omgps users, for your test and feed back. > > OK, a couple of problems running it on Debian: > > 1) At startup, a message "Unable to directory" in very > small print pops up. > > Suggestion: Use the default font size for error message dialogs. > > 2) Running it from a shell, messages such as this one are printed: > > 20090711 14:43:52 [WARN] load image failed: Failed to open file > '/home/rask/.omgps/maps/OSM/1/0/0.png': Permission denied > > $ ls -l ~/.omgps/maps/OSM/*/*/*.png > -- 1 rask rask 9091 Jul 11 14:43 > /home/rask/.omgps/maps/OSM/1/0/0.png > -- 1 rask rask 4436 Jul 11 14:44 > /home/rask/.omgps/maps/OSM/1/0/1.png > -- 1 rask rask 7730 Jul 11 14:43 > /home/rask/.omgps/maps/OSM/1/1/0.png > -- 1 rask rask 4226 Jul 11 14:43 > /home/rask/.omgps/maps/OSM/1/1/1.png > > Suggestion: Don't mess with the file permissions. > > 3) Running it again, at startup, a message "Unable to create pid file > ." in very small print pops up. > > $ ls -l ~/.omgps/omgps.pid > --x--- 1 rask rask 5 Jul 11 14:42 /home/rask/.omgps/omgps.pid > > Suggestion: Don't mess with the file permissions. Delete the pid file on > exit. > > 4) The GPS part only works if I have the GPS activated by some other means > such as running TangoGPS or using fsoraw. Otherwise, it just sits there with > "Initializing GPS" displayed at the bottom. > > -- > Rask Ingemann Lambertsen > Danish law requires addresses in e-mail to be logged and stored for a year > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > View message @ > http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3249932.html > To unsubscribe from [omgps] collect feature requests, click here. > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3251007.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: lowering gps sampling rate
Longer sampling rate does not save that much energy as expected. Also refer to this [1]. Omgps uses fixed 1Hz send rate for now, but ever tested a lot (even FIXNOW) before release. Incoming version will support configuring sampling rate which is implemented by sleep(). During my last trip (mountain climbing), we were told at hotel that the mountain is difficult to climb, almost no way. I did a quick hacking: To help find back way upon get lost, current position is displayed on track replay; To save a bit energy, sampling rate was increased to 5 seconds For next mountain climbing, I bought two Nokia BL-5C batteries yesterday :) [1] http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2541178.html jeremy jozwik wrote: > > omgps does it. and tracks well too > > On Fri, Jul 10, 2009 at 1:13 PM, Petr Vanek wrote: >> the wiki mentions ]1[ how to increase the sampling rate of gps, is >> there a way to lower it to save energy during gps tracking that >> doesn't require such precision? >> >> Petr >> >> >> ]1[ >> http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Configuration_for_a_higher_sampling_rate >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/lowering-gps-sampling-rate-tp3240723p3241085.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
> On GTA02 ogpsd uses UBX only (no NMEA) so the only overhead compared to > omgps would be that the parsing is implemented in python. I'm sorry that I said ogpsd uses NMEA :( omgps talks with ogpsd (gypsy service) through dbus APIs, so another overhead is delivering of dbus signals. As of my test, the approximate overhead is over 5% (CPU usage). > Do you think that your UBX parser code is ready to replace the python > parser? If yes, then there wouldn't be any problems anymore with using > ogpsd (currently performace/battery usage). No. The Gypsy service good for most users who want to get just data such as lat/lon. Fso-framework manages GPS device, it is not easy to write another working parser (data provider). UBX binary is preferred by omgps because I want full control. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3231221.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-unstable] screen flickering
hehe, I'm not alone :) My problem is similar to the second one you described -- whole screen image moves back and forth frequently. I saw colored vertical bars 5 months ago, it is triggered drawing part of pixmap to window. regards, mqy rhn-2 wrote: > > I saw two incarnations of that. > > The first one I encountered was the screen flickering, but not getting > blurred. It happened several times, each time (save one or two) the FR was > charging and feeling a bit hot. On powering off, the screen was black at > first, then, slowly, grey vertical bars appeared in various shades of > gray. > > The other one seemed more like a software failure - half of the screen was > blurred. It seemed like the image was being shifted a feww pixels in some > direction and then back to normall all the time. > > -- > Cheers, > rhn > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- View this message in context: http://n2.nabble.com/-SHR-unstable--screen-flickering-tp3214539p3214860.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-unstable] screen flickering
hi: SHR unstable version is 20090624. I've seen this problem for several times when omgps running. I often switch current page to "menu" which avoid refreshing views -- to save power. The whole screen gets blur. Fortunately in this case I can click the 'exit' button, but have to restart. Each time I saw the problem the only thing I'm sure that 1) the outdoor air temperature is high (>30 centi degrees) 2) the phone was put in a portable bag, I have to say the color is black :) I'm wondering it is caused by high temperature? Anybody has similar problem? -- View this message in context: http://n2.nabble.com/-SHR-unstable--screen-flickering-tp3214539p3214539.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Let me explain my build environment. HOST env: debian chroot on top of ubuntu 1. build with openmoko unstable toolchian (from openmoko download site) om-conf omgps && make clean && make && om-make-ipkg omgps With this approach, take care to run om-conf again once Makefile.am is modified. 2. build with bitbake (SHR), see omgps_svn.bb about comment #1: I have no idea how to test Python version installed in tool chain, so have to hard code the version as 2.6. What about try 2.4 or something else? about comment #2: which description? would you please clarify? 2009/7/5 Rask Ingemann Lambertsen (via Nabble) : > On Mon, Jun 29, 2009 at 05:29:22PM -0700, mqy wrote: > >> Please feel free to comment or add new feature requests here. > > Two comments on the package control file: > 1) The dependency on python2.6 is missing. > 2) The description is still the default one. > > -- > Rask Ingemann Lambertsen > Danish law requires addresses in e-mail to be logged and stored for a year > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > View message @ > http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3207160.html > To unsubscribe from [omgps] collect feature requests, click here. > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3208174.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Hi Bilk: Don't worry :) I've said that I'm afraid of the corruption. So this feature will be configurable if it can be integrated. 2009/7/2 William Kenworthy (via Nabble) : > I hope not - I have over 2 million tiles stored on SD card - if file > corruption or disaster occurs, it may affect only one tile if its being > accessed at the time - imagine the effect of file system corruption on > one large archive ... you will most likely lose the lot. > > Then there is the extra overhead needed - Ive gotta ask "why"? - if you > can justify the extra cpu needed for this, why not do vector maps? > > BillK > > > On Thu, 2009-07-02 at 00:42 -0700, mqy wrote: >> x and y are tile no in tile coordinate system within range of [0.. >> 2^zoom). >> just do it if you have time, since proof of concept is necessary :) keep >> in >> mind clear APIs. >> it's likely that, the final version to be integrated into omgps is >> rewritten >> in C. >> >> >> Laszlo KREKACS wrote: >> > >> > If I understand right the OSM tiles, they have the following directory >> > ... >> > >> > -- > William Kenworthy > Home in Perth! > > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > This email is a reply to your post @ > http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193977.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3205707.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
x and y are tile no in tile coordinate system within range of [0.. 2^zoom). just do it if you have time, since proof of concept is necessary :) keep in mind clear APIs. it's likely that, the final version to be integrated into omgps is rewritten in C. Laszlo KREKACS wrote: > > If I understand right the OSM tiles, they have the following directory > ... > -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193890.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] 20090624 suspend off not really off?
I assume that auto-suspending is disabled by some app while you try adjusting in SHR-settings :) Auto suspending is disabled by omgps, you can't adjust auto-suspending when omgps is running. vendion wrote: > > I have just noticed the opposite problem, I am unable to get shr- > unstable to auto suspend. Going to shr settings -> Power and using > the slider for the auto suspend to try an enable it does not work, > when I drag it, the slider just goes back to "disabled" no matter how > many times I try it or even how long I hold it there. > On Jul 1, 2009, at 8:23 PM, jeremy jozwik wrote: > ... > -- View this message in context: http://n2.nabble.com/-shr-unstable--20090624-suspend-off-not-really-off--tp3192622p3193723.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
XML is used as a database, elements can be easily added, modified, removed. xor tends to be overkilled as of map tile usage -- we don't need iterating, delete, and that much meta information. With my suggested design, we can even add newly downloaded tiles: insert record into meta database, and append tile content into "heap" file. Laszlo KREKACS wrote: > > ... > I have only one problem with xar: xml. > It complicates things unnecessary. > ... > Laszlo > -- View this message in context: http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193580.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New archive file format (was: [omgps] collect feature requests)
Thumb up for your effort:)
A simpler design choice would be:
1. int get_tile_meta(int zoom, int x, int y, TileMeta *tm) -- fill in
, ; return -1 if tile not found
-- implemented by collecting per map meta info into a sqlite database
2. int get_tile_bytes(char* buf, TileMeta *tm) -- read tile content into
of
-- implemented by collecting tiles into a big file.
Where TileMeta is defined as:
struct TileMeta
{
int offset;
int size;
U4 crc;
char *name; // optional
};
This kind of data source is abstracted as a tile provider, in addition to
the default standard file system based one.
I'd like to see if xar works well too.
regards,
mqy
Laszlo KREKACS wrote:
>
> Hi!
>
> I have studied all the available archive and compression options.
> ...
> Best regards,
> Laszlo
> ...
>
--
View this message in context:
http://n2.nabble.com/New-archive-file-format-%28was%3A--omgps--collect-feature-requests%29-tp3191899p3193471.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Laszlo, I understand your trouble, but I have to say that your problem is uncommon, because that is caused by unstable underlying infrastructure. Have you ever tested with other uSD cards, or have you upgraded kernel image and rootfs image to latest? Your request for "archived repository" was added into into requirement list, it will be implemented once I have evidence that it does not affect performance too much. Other than performance reason, I also worry about safety and memory usage. By safety I mean all eggs in one basket. Laszlo KREKACS wrote: > > > Ok, I lied a bit. I only tested with tangogps. > > But, it was reproducible. If the device freezed or I removed the battery, > many > tile maps got unreadable. I couldnt even list some directories or cd into > them! > (it rules out heavy CPU load, and not getting enough power) > > I already wrote about it about a month ago: > http://lists.openmoko.org/pipermail/community/2009-June/048997.html > > So the problem really comes about the insane 75000 files (118MB). > > I would really like to tar, ar, zip, etc the dirs containing the invidual > tiles. > It seems an easy job! Would be much more managable, speed up > a lot the file copying (copying many small files is several magnitude > slower!). > > Current directory structure: > OSM/11/1102/715.png > OSM/11/1102/716.png > OSM/11/1102/717.png > OSM/11/1102/718.png > > We could simply create an OSM/11/1102.tar file, containing those invidual > files. I bet it would be not slower. I could even imagine some speed > boost. > > Remember accessing invidual files on a sd card takes time. A lot. > You can try it for yourself, copy to a pendrive your ~/Maps directory. > Now tar the dir (Maps.tar) and copy that singly file to the pendrive. > > The result is something like 40sec compared to 6-7min. > > So please consider to implement this on-the-fly untaring capability. > > Thank you, > Laszlo > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3186272.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Onen, obm data can be abstracted as a kind of "POI" to display. obm can be integrated into omgps with loosely coupled interfaces. to support obm, omgps must: 1. get obm data within an lat/lon rectangle and display them as a layer (just like POIs) 2. show details of each node 3. optionally as a gps data provider for obm. Here are problems to be concerned by obm logger. 1. user may not able to connect to net or can't afford to be online for long time. so must be able to get obm data offline. 2. local data must be able to be updated, do this with open obm logger? 3. while obm logger running, it connects to ogpsd to get GPS data, this triggers omgps switching its data provider from UBX binary to ogpsd, which waste energy. Lets think about how to implement plugin interface. 1. Protocol version: avoid incompatibility. 2. Type is defined as: * type_id (string) * type_name (string) * image (file path string) 3. Type data is defined as * type_id * lat (double) * lon (double) * desc (string) Let's think about C wrapper functions for Python plugins: /* get version */ 1. char * get_version(void); /* returns types definition, format TBD */ 2. char * get_types(void): get type definitions. /* returns data list, empty or NULL type id means all types, format TBD */ 3. char * load_data(type_id, lat1, lon1, lat2, lon2) To avoid too much data returned, omgps can limit minimal zoom level to call load_data(). Upon get data, omgps renders those data into current view. What do you think? Onen wrote: > > > +1 to display cells on the map, like it is shown on the OSM map on the > openBmap website. This must be done through something "standard" (KML?), > because your app should stick to its purpose, and should not have > features specific to obm, or only under a plugin, don't you think? > > Onen > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3186131.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hi Laszlo, I've developed concurrent Java programs on sever, ever experienced problem of file descriptor out of per process limit. Haven't seen it crash file system on server or desktop boxes. By default the fd limit is 1024 (see it with ulimit -a), If that's the cause, you would fail even if with battery plugged. I don't think find or wc open that much file descriptors at all. My guess: to read dir entries in a directory, open the direcotory, then read inodes in this directory, then close the directory. Of course at least a pipe is created. My test with omgps running shows no failure, with 26954 image files. You can add a swap file /partition then test again, to see if limited memory causes this problem. I've watched with `vmstat 1`, seen limited memory usage. Here is my clues: #1: max current of usb power supply is 500mA, with heavy CPU load, uSD card may not get enough power then fails to work. #2: Many people experienced the "lose partition problem" including myself, I can remember somebody asked that "why GPS hurt uSD card?". Laszlo KREKACS wrote: > > Noone experienced whole filesystem crash because of *that* many open > file descriptors? > > It would be really strange. ITs really simple to test it: > While using tangogps/omgps remove the battery. > > Almost 90% percent and the whole filesystem crashes > (the tiles are no more availables) > > You can test it, with: find /home/root/Maps -name *.png |wc -l > > I bet it will hang. > > > So I request the following feature: > Instead of having 75000 file for 118MB, compress the > tiles into reasonable 1MB files. So 118 files in total in place of > 75000 files. > > Anyone agree? > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3185152.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
The summary is listed here: http://code.google.com/p/omgps/wiki/FeatureRequests?ts=1246375354&updated=FeatureRequests I will go traveling during 07-02 ~ 07-04. If your comment or suggestion may not list there, it is likely due to delay. -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3183248.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Hehe, I just googled "ciao", Ciao bella:) First of all I have to say that fso-framework is excellent, because we do need a top level abstraction and manger to control access to system resources (especially the hardwares). As of GPS related APIs in ogpsd, UBX binary protocol is used to issue control commands (such as initialize GPS receiver, upload/download AID messages), and NMEA protocol is used to accept messages passively. NMEA is good, because it is standard and easy to understand, easy to implement parser. but standard also means less flexibility comparing to UBX binary protocol which provides richer data and more controls. I've implemented three parsers (UBX binary, UBX NEMA, standard NEMA) and can switch on the fly. Finally I realized that it is unacceptable without supporting fso. I can choose use gpsd (or fso-gpsd) + ogpsd as data provider, but i's not battery-friendly -- fso-gpsd accepts data from ogpsd, converts them to NMEA messages, fso-gpsd users get data from it through sockets. To use ogpsd, it is obvious that omgps talks directly with ogpsd. I want better performance and free controls. UBX binary is efficient enough, so it is kept as default data provider. The common communication model of UBX binary is polling: send request, read response and optional ACK. On omgps start, it checks if ogpsd has users connected to it (for example fso-gpsd). If no existing users, omgps use UBX binary as data provider, then initialize GPS receiver (enable UBX binary protocol, disable NEMA protocol)... NOTE: the three protocols can be enabled at the same time, this means /dev/ttySAC1 can output binary + text. During omgps running, each response message is validated (header + checksum + ack). If another user of GPS receiver (say ogpsd) is started, it would re-initialize GPS, which may cause omgps read timeout, get bad data. Anyway, omgps can detect conflict and during that period other GPS receiver users may lose some data which are consumed by omgps. Upon conflict, omgps checks existing GPS receiver users via ogpsd dbus API, if the count > 0, omgps has to switch data provider to ogpsd. To get data from ogpsd you have to register signals (aysnc mode, ogpsd sends data per second) or poll in synchronous mode. So the finnaly conclusion: you can't manually switch to ogpsd. BTW, is the start time unacceptable? Ciao, mqy :) Fox Mulder wrote: > > My name is Rainer not Ciao but i forgive you. :) > > Ok so when i understand it right i can change between nativ UBX Format > and ogpsd (NMEA format?) usage. As i know ogpsd was introduced to solve > the problem of multiple programs accessing /dev/ttySAC1 and instead use > ogpsd which support multiple connections. > But what is not clear to me is how you connect to the gps with UBX > format. I thought this is only possible over /dev/ttySAC1, which would > block possible ogpsd readings, or does ogpsd support NMEA and UBX format? > So in the end i only have to switch somehow from UBX to ogpsd input in > omgps to disable the aided gps data function? > > mqy wrote: >> hi Ciao, >> >> omgps supports two data providers: (1) UBX binary and (2) fso ogpsd >> (through >> dbus). >> with #1, no way to utilize ogpsd, you know duplicate connection to >> /dev/ttySAC1 would cause unexpected result. >> >> >> Fox Mulder wrote: >>> The possibility to enable/disable aided gps start within the settings >>> would be nice since fso still does agps function by itself. So the aided >>> feed of data from omgps would do it the second time after gps start. And >>> disabling agps in omgps speeds up the start and exit time of omgps a >>> little bit. :) >>> >>> Ciao, >>> Rainer >>> >>> ___ >>> Openmoko community mailing list >>> community@lists.openmoko.org >>> http://lists.openmoko.org/mailman/listinfo/community >>> >>> >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3183105.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hi Ciao, omgps supports two data providers: (1) UBX binary and (2) fso ogpsd (through dbus). with #1, no way to utilize ogpsd, you know duplicate connection to /dev/ttySAC1 would cause unexpected result. Fox Mulder wrote: > > The possibility to enable/disable aided gps start within the settings > would be nice since fso still does agps function by itself. So the aided > feed of data from omgps would do it the second time after gps start. And > disabling agps in omgps speeds up the start and exit time of omgps a > little bit. :) > > Ciao, > Rainer > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3182489.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: NABBLE [was: Re: [omgps] collect feature requests]
it seems firefox plugin "cookieculler" prevents post displaying response. noscript is another trouble maker. I'm sorry for the duplicates. David Ford wrote: > > For those of you who post using nabble -- please reconsider. > > Nabble posts duplicates. The below was posted by nabble four times. > The headers clearly indicate nabble at fault with four different > originating message IDs. > > Additionally, many people report problems with nabble's javascript (no, > JS isn't evil Doc) in any browser other than firefox. So please don't > point people to nabble as a place to follow threads or research a message. > > TY > > 4x posted message: > > On 06/29/09 20:29, mqy wrote: >> First, I must appreciate all omgps users, for your test and feed back. >> >> Because ersion 0.1 gets stable for now, and it will be integrated into >> official openembeded repository, I'm planing start next major developing >> stage. Here is current plan: >> >> 1. better supports for track logging, nuk ask me to add altitude to track >> log, good point. I can remember complains about the lack of POI, and >> suggestion of voice recording to help post precess of track logging. >> >> 2. support dynamic layers, including POI, openbmap data, etc. my concerns >> are (1) performance (2) is it possible or necessary to support user >> defined >> layers as plugins? >> >> 3. and other big things related to routing. >> >> Requirement of version 0.2 will be frozen due 07-07, the core task is to >> make it track-friendly for OSM map and JOMS application. Please feel free >> to >> comment or add new feature requests here. >> >> regards, mqy >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/NABBLE--was%3A-Re%3A--omgps--collect-feature-requests--tp3178346p3178414.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
make sense, I can remember this request before. but that's not battery-friendly. think how to draw such a path after you get thousands of fixes on each redraw (per second)? what about add another menu item let you review history? what about start track automatically at start? currently, you have to stop track then view path with "track replay". jeremy jozwik wrote: > > and more sincerely. perhaps a setting for lenght of displayed track. > say your carting about with the track on, and you want to look at > omgps to see where you have been but the line only draws so many > minutes [?] into the past. i might be good to have a setting in the > app that could control this for times when you want to see the whole > shabang > > -jeremy > > On Mon, Jun 29, 2009 at 5:33 PM, jeremy jozwik > wrote: >> BIGGER BUTTONS!!! >> >> On Mon, Jun 29, 2009 at 5:30 PM, mqy wrote: >>> >>> First, I must appreciate all omgps users, for your test and feed back. >>> >>> Because ersion 0.1 gets stable for now, and it will be integrated into >>> official openembeded repository, I'm planing start next major developing >>> stage. Here is current plan: >>> >>> 1. better supports for track logging, nuk ask me to add altitude to >>> track >>> log, good point. I can remember complains about the lack of POI, and >>> suggestion of voice recording to help post precess of track logging. >>> >>> 2. support dynamic layers, including POI, openbmap data, etc. my >>> concerns >>> are (1) performance (2) is it possible or necessary to support user >>> defined >>> layers as plugins? >>> >>> 3. and other big things related to routing. >>> >>> Requirement of version 0.2 will be frozen due 07-07, the core task is to >>> make it track-friendly for OSM map and JOMS application. Please feel >>> free to >>> comment or add new feature requests here. >>> >>> regards, mqy >>> -- >>> View this message in context: >>> http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html >>> Sent from the Openmoko Community mailing list archive at Nabble.com. >>> >>> >>> ___ >>> Openmoko community mailing list >>> community@lists.openmoko.org >>> http://lists.openmoko.org/mailman/listinfo/community >>> >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178321.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
hehe, how big? double? jeremy jozwik wrote: > > BIGGER BUTTONS!!! > -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178300.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178265p3178265.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178260p3178260.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178254p3178254.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] collect feature requests
First, I must appreciate all omgps users, for your test and feed back. Because ersion 0.1 gets stable for now, and it will be integrated into official openembeded repository, I'm planing start next major developing stage. Here is current plan: 1. better supports for track logging, nuk ask me to add altitude to track log, good point. I can remember complains about the lack of POI, and suggestion of voice recording to help post precess of track logging. 2. support dynamic layers, including POI, openbmap data, etc. my concerns are (1) performance (2) is it possible or necessary to support user defined layers as plugins? 3. and other big things related to routing. Requirement of version 0.2 will be frozen due 07-07, the core task is to make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--collect-feature-requests-tp3178247p3178247.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] omgps wsod with full
hi jeremy, I encountered the WSOD two days ago with latest SHR-unstable, after a upgrade without restart xserver or FR. Haven't seen that problem again after reboot. I suggest you try other applications (eg. tangoGPS) with full/unfull buttons, and/or do a upgrade then test again. I will do a further check on omgps if this problem still exists after your upgrade, but don't know where to start from for now :) jeremy jozwik wrote: > > running shr-unstable 20090624 with the latest version of omgps on > opkg.org. when i hit the "full" button i get a white screen of death. > > no terminal errors to report. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-shr-unstable--omgps-wsod-with-full-tp3176059p3176211.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which gps app can do this?
hi lanzo, I have to say that your problem is interesting, but it's a bit too specific for a GPS application to do this. One quick and dirty solution is: You write a small application which: 1) calculate a polygon area which contains the allowed range. to do this you have to use web map or standalone map. The polygon nodes are lat/lon pairs. 2) get GPS fix from fso ogpsd through DBUS API. this is not difficult with python 3) periodically (say every five seconds) test if current position goes out of predefined area. if the test result is true, then warn with sound (aplay command). To see where you are, you can run a GPS application at the same time. I'm the writer of omgps, I'm planning to extend omgps to solve this kind of problem -- allow user register his/her python script as plugin, omgps periodically call each plugin, passing parameters of current lat/lon/altitude, etc. Periodically can be defined as: (1) on each fix (2) every N seconds. Welcome your feed back :) lanzo wrote: > > Hi! > I'd like to be using my FR on my little boat as marine GPS. I was curious > if, in your opinion, it could be possible to constantly show the distance > between me and the nearest point on the coast line. This would be > important because in my country (and i guess everywhere) there are rules > about the little boats distances from the coast and I cannot overcome 3 > nautical miles. > > I know it should be possible to show the distances between my present > position and any given point, but what about something always displaying > the distances between my position and the nearest point on the coast? > > is there maybe any more in-topic forum where i can ask this? > > Thank you very much for any answer! > bye! :) > -- View this message in context: http://n2.nabble.com/which-gps-app-can-do-this--tp3169715p3170060.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: input method : dasher
I'm thinking about a hand writing program, but it's not easy.
Really interested in this input method, will be a tester.
"Dasher can be used to write efficiently in any language.", great.
swap38 wrote:
>
> Hi,
>
> At the end of this article [1], there's a comment about Dasher [2].
> It's a strange but simple funny input method that can be very fast ("39
> words per minute").
>
> Dasher support numerous languages and the source code is open.
> A version for mobile device (ARMv4 / Windows Mobile) is in developed by
> Glen Femandes.
>
> Do you think Dasher can be useful for the Neo Freerunner ?
>
> [1] http://lwn.net/Articles/336787/
> [2] http://www.inference.phy.cam.ac.uk/dasher/
>
> --
> swap38
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
--
View this message in context:
http://n2.nabble.com/input-method-%3A-dasher-tp3136040p3136633.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Community Updates] # 4.3 Wishlist
Agree too. But no matter where the wish list being displayed, the core is to encourage feeding back. Also, release plans and votes help focusing on key problems. Risto H. Kurppa wrote: > > On Mon, Jun 22, 2009 at 1:06 PM, Patryk Benderz > wrote: >> Hi, >> Recently someone added point "4.3 Wishlist" of wiki. My opinion about >> this : >> I think it is not appropriate place to place "whish list" herein. >> "Community Updates" were designed to inform users and community of OM/FR >> about what is going on with OM/FR. This is not a discussion board to >> talk what would you like to have in your FR. According to above, >> "whishlist" should be transfered to another/new part of wiki, or to >> mailing list. Thus, if there will be no response for my consideration >> about this during next few days from author of this point, or from >> others, I intend to remove this point from wiki. LeadMan. >> >> Now i would like to know what do you think about that? Am i >> correct or >> wrong? > > I fully agree, the 'wishlist' is no informative to the community > (instead there can be a link in the Community Updates telling that > 'There's been a new general wishlist page created', if someone want's > that..) > > r > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-Community-Updates4.3-Wishlist-tp3132057p3132190.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] important updates
text color on center button is gray, when in "keep cursor in view" mode. it seems the button is inactive, but actually not :) ivvmm wrote: > > > Am I the only who has the 'center' button always inactive so cannot test > the new centering features? > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--important-updates--05-29--tp2977563p2997438.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [android] android on ubuntu
I've did this half a year ago, not very difficult, but plenty of modifications :) GNUtoo wrote: > > On Thu, 2009-05-28 at 11:29 +0200, arne anka wrote: >> might be interesting: >> some ubuntu guys compiled android against libc (not the android flavour) >> and hacked its ipc to make it run under ubuntu: >> >> > http://mjfrey.blogspot.com/2009/05/hacking-android-on-ubuntu.html > Is there a howto or sources? > or should we wait? > > Denis. > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-android--android-on-ubuntu-tp2986568p2991163.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] important updates
I double checked the UBLOX 5 document which is much detailed than ANTARIS's. You are right, suitable platform model results in more accurate position. As of the content listed below, platform model affects not only accuracy, but also maximum altitude/speed, 2D/3D output. I'm adding this feature, we can compare the results once it is added. wait for several hours :) About the CFG-NAV5 (a.k.a CFG-NAV2 for ANTARIS 4): --> u-blox 5 positioning technology supports different dynamic platform models to adjust the navigation engine to the expected environment. These platform settings can be changed dynamically without doing a power cycle or reset. It allows a better interpretation of the measurements and hence provides a more accurate position output. Setting the receiver to an unsuitable platform model for the application environment may reduce the receiver performance and position accuracy significantly. Platform Description Portable: --- (comment: ublox 5 only) Default setting. Applications with low accelerations, as any portable devices. Suitable for most situations. MAX Altitude [m]: 12000, MAX Velocity [m/s]: 310, MAX Vertical Velocity [m/s]: 50, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium Stationary: Used in timing applications (antenna must be stationary) or other stationary applications. Velocity is constrained to 0 m/s. Zero dynamics assumed. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 10, MAX Vertical Velocity [m/s]: 6, Sanity check type: Altitude and Velocity, Max Position Deviation: Small Pedestrian: Applications with low accelerations and low speed, as a pedestrian would move. Assuming low accelerations. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX Vertical Velocity [m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation: Small Automotive: Used for applications that can be compared with the dynamics of a passenger car. Assuming low vertical acceleration. MAX Altitude [m]: 5000, MAX Velocity [m/s]: 62, MAX Vertical Velocity [m/s]: 15, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium At sea: Recommended for applications at sea, with zero vertical velocity. Assuming zero vertical velocity. MAX Altitude [m]: 500, MAX Velocity [m/s]: 25, MAX Vertical Velocity [m/s]: 5, Sanity check type: Altitude and Velocity, Max Position Deviation: Medium Airborne <1g: Used for applications that have to handle a higher dynamic range than a car and higher vertical accelerations. No 2D position fixes supported. MAX Altitude [m]: 5, MAX Velocity [m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large Airborne <2g: Recommended for typical airborne environment. No 2D position fixes supported. MAX Altitude [m]: 5, MAX Velocity [m/s]: 250, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large Airborne <4g: Only recommended for an extreme dynamic environment. No 2D position fixes supported. MAX Altitude [m]: 5, MAX Velocity [m/s]: 500, MAX Vertical Velocity [m/s]: 100, Sanity check type: Altitude, Max Position Deviation: Large NOTE: Dynamic platforms designed for high acceleration systems (e.g. airborne <2g) may result in a greater standard deviation in the reported position. William Kenworthy wrote: > > Not sure - I saw a post saying automotive changed direction using a wide > smooth curve where pedestrian was much sharper - perhaps have it > selectable. Bikes would be closer to pedestrian? - for mapping > purposes, pedestrian might be better? > > Comment from anyone able to compare this? > > Bill > > > On Wed, 2009-05-27 at 07:31 -0700, mqy wrote: >> Yes, ease of use is also an important thing other than power-safe and >> stability. >> In fact I haven't ever used any GPS application other than TangoGPS. >> Before writing this application, I know nothing about GPS, GTK+ at all. >> >> Other commercial level applications must have excellent ideas that I can >> borrow from, >> unfortunately I don't have such devices, thus your suggestions are >> important. >> >> UBX 4/5 supports configuring navigation model via CFG-NAV2 or CFG-NAV5. >> Options are: >> * 1 Stationary >> * 2 Pedestrian >> * 3 Automotive >> * 4 Sea >> * 5 Airborne with <1g Acceleration >> * 6 Airborne with <2g Acceleration >> * 7 Airborne with <4g Acceleration >> Default is automotive. As of my understanding, the model determines how >> GPS >> receiver calculates fixes, >> automotive should be OK, right? >> >> >> William Kenworthy wrote: >> > >> > On Wed, 2009-05-27 at 08:37 +0300, Risto H. Kurppa wrote: >> >> On Wed, May 27, 2009 at 1:05 AM, mqy wrote: >> &g
Re: New release of Enscribi - version 0.2.0
I've tried 0.1, it does not recognize well. Need more work to enhance back-end engine. Anyway, good start point :) Olof Sjobergh wrote: > > Hi, > > Enscribi, the handwriting recognition input method for Japanese and > Chinese, has gotten bumped to version 0.2.0. > > What's new in this version? Not much, but at least there's now: > > * The Zinnia recognizer has been moved to its own process, so the GUI > doesn't lock up when doing the recognition. > > * Color coding of different alphabets, so it's easier to find the > character you're after (mostly useful for Japanese, where hiragana, > katakana and kanji sometimes are very similar and hard to separate). > > A precompiled package for current SHR unstable is hosted at > http://www.opkg.org/package_133.html. This should fix the problem with > the old package that didn't work with the new EFL version. > > For more details about installation and usage, please see > http://olofsj.github.com/enscribi/ > > Best regards, > > Olof Sjöbergh > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/New-release-of-Enscribi---version-0.2.0-tp2976910p2982860.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] important updates
Yes, ease of use is also an important thing other than power-safe and stability. In fact I haven't ever used any GPS application other than TangoGPS. Before writing this application, I know nothing about GPS, GTK+ at all. Other commercial level applications must have excellent ideas that I can borrow from, unfortunately I don't have such devices, thus your suggestions are important. UBX 4/5 supports configuring navigation model via CFG-NAV2 or CFG-NAV5. Options are: * 1 Stationary * 2 Pedestrian * 3 Automotive * 4 Sea * 5 Airborne with <1g Acceleration * 6 Airborne with <2g Acceleration * 7 Airborne with <4g Acceleration Default is automotive. As of my understanding, the model determines how GPS receiver calculates fixes, automotive should be OK, right? William Kenworthy wrote: > > On Wed, 2009-05-27 at 08:37 +0300, Risto H. Kurppa wrote: >> On Wed, May 27, 2009 at 1:05 AM, mqy wrote: >> > >> > Although there is a thread about omgps, I think I'd list the important >> things >> > here. >> > Those who have installed previous version(s) are recommend to do a >> update. >> > >> > download url: >> > http://omgps.googlecode.com/files/omgps_0.1_armv4t-20090527-1.ipk >> > >> > Important updates since first release on 2009-05-21: >> >> Wow, nice! Keep up the good work! >> >> BTw about the autocenter feature: could it update the position a bit >> earlier than when hitting the edge, let's say when there's 1/3 of the >> screen left before hitting the edge? Just to allow you to see more in >> the direction you're going to. >> >> THanks! >> >> >> r > > I would like to add my request for this as well - at the moment its not > usable when driving/or riding a bike as you cant see whats coming. Even > better than the 1/3, would be to offset the cursor so that 2/3 (or more) > of the screen is "ahead", and only a small amount is behind (none of the > FR gps apps I have tried do this - but TV adds for Nokias and the like > seem to show it as standard on those devices - very few people > riding/driving or usually even when walking are interested in where they > have been - its where they are going thats important. Sliding the map > under the cursor is a much better idea than redrawing the screen when > you get to the edge when moving for this reason. > > Even when walking, the current update method means you are always > manually centring so it never gets to the edge ... so any power savings > via reduced cpu are illusory as the user is always interacting with it > anyway. And thats something best not done when driving/riding :) > > There may be scope here for a mode setting in the config - walk, drive > etc - the antaris GPS chip does have settable parameters for these > modes. > > BillK > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--important-updates-tp2977563p2981457.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] important updates
Make sense, accepted as a defect. Consider there are other things to be fixed, I defer the next update to a couple of days later. 2009/5/27 Risto H. Kurppa (via Nabble) : > On Wed, May 27, 2009 at 1:05 AM, mqy wrote: >> >> Although there is a thread about omgps, I think I'd list the important >> things >> here. >> Those who have installed previous version(s) are recommend to do a update. >> >> download url: >> http://omgps.googlecode.com/files/omgps_0.1_armv4t-20090527-1.ipk >> >> Important updates since first release on 2009-05-21: > > Wow, nice! Keep up the good work! > > BTw about the autocenter feature: could it update the position a bit > earlier than when hitting the edge, let's say when there's 1/3 of the > screen left before hitting the edge? Just to allow you to see more in > the direction you're going to. > > THanks! > > > r > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > This email is a reply to your post @ > http://n2.nabble.com/-omgps--important-updates-tp2977563p2979241.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/-omgps--important-updates-tp2977563p2981243.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[omgps] important updates
Although there is a thread about omgps, I think I'd list the important things here. Those who have installed previous version(s) are recommend to do a update. download url: http://omgps.googlecode.com/files/omgps_0.1_armv4t-20090527-1.ipk Important updates since first release on 2009-05-21: --- 1. bugfix: "keep cursor in view" does not always behave as expected. 2. bugfix: SIGSEGV on stopping track. see http://code.google.com/p/omgps/issues/detail?id=2 3. bugfix: Full screen mode, popup message dialogs does not show on above -- deadlock screen. 4. defect: speed unit, add mph and km/h. see http://code.google.com/p/omgps/issues/detail?id=1 5. new feature: sky map to show satellite positions. Regards, mqy -- View this message in context: http://n2.nabble.com/-omgps--important-updates-tp2977563p2977563.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
Thanks for the report! I finally found the bug that when cursor moves out of left or top screen, the "keep location/cursor in view" mechanism fails. William Kenworthy, also pointed out this problem, here is my reply (I didn't notice this problem at that time): http://n2.nabble.com/forum/Permalink.jtp?root=2948257&post=2952181&page=y I'm adding a indicator for the "keep cursor in view" state. New package will be uploaded within 1 day. Regards 2009/5/22 William Kenworthy (via Nabble) : > Hi mgy, good little app. > > I tried it in the car yesterday and found that the cursor moved off the > map unless manually centred - is there a way to make the cursor fixed > and the map move under it as does tangogps? Its not possible to > continually hit centre whilst driving/biking. > > I do like the way the display is organised - better, cleaner and more > informative. > > BillK > > > On Wed, 2009-05-20 at 12:53 -0700, mqy wrote: >> Hi all: >> >> I got my gta02 freerunner on DEC 2008. >> After nearly 5 months development, I'm happy to announce the first alpha >> release of omgps. >> >> It is not as feature rich as other GPS applications, such as tangoGPS, >> anyway I think it should satisfy most of >> the daily needs. Please goto http://code.google.com/p/omgps/, download and >> give a try. >> >> After ten years of programming as a web developer for most of the time, >> now >> I join the community with my little gift :) Thanks you to open source >> community -- for your great works and spirits. >> > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > This email is a reply to your post @ > http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunneromgps-tp2948257p2956807.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunneromgps-tp2948257p2957926.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
First of all, Google map and Google sat are good, but there are distorts and offsets, at least in my region. I don't know whether that's due to technical reason or something else. That's why I the "FixMap" button in "Map Tile" menu. As of Google map, only offset found, but Google stat has distort + offset, that's non-linear thus can't be "fixed" at all. Without good maps, any GPS GUI application becomes nearly useless. As an author, I have to think about map licenses. The ideal way is to remove any commercial licensed map configurations from omgps. But to provide you and me a ease of use application, I finally decided to keep Google map and Yahoo sat in config file :D Here is the config for Google sat: def GoogleSat(): return "min-zoom=1; max-zoom=17; image-ext=jpg" def GoogleSat_url(zoom, x, y): return "http://khm.google.com/kh/v=37&hl=en&x="; + `x` + "&y=" + `y` + "&z=" + `zoom` + "&s=Gali" (1) You append these two functions to $HOME/.omgps/config_01./map.py, make sure replace leading blanks with a tab latter. (2) Then add "GoogleSat" to map_list() Please note: (1) about the parameters "v=" and "hl=", version may changes, you can set hl as your locale? (2) the downloads always fail, it may returns a HTML page which contains clear text redirected URL. I think that's a polite anti-spam way. - About tracking (or tracing), I accept your suggestion. I choose limited in-memory points due to performance reason, but that may be unnecessary at all or performance can be improved by better algorithm. About the slow response of zoom/pan: yes, it is slow especially when maps are layered. I've taken considerable time to improve the response time, in-memory tile cache is one of the solution, but I know there are chances to improve it. I'd like to provide you and me a new version with faster UI response. Thanks a lot! ivvmm wrote: > > mqy wrote: >> Hi all: >> >> I got my gta02 freerunner on DEC 2008. >> After nearly 5 months development, I'm happy to announce the first alpha >> release of omgps. >> >> It is not as feature rich as other GPS applications, such as tangoGPS, >> anyway I think it should satisfy most of >> the daily needs. Please goto http://code.google.com/p/omgps/, download >> and >> give a try. >> >> After ten years of programming as a web developer for most of the time, >> now >> I join the community with my little gift :) Thanks you to open source >> community -- for your great works and spirits. >> > > Your application is definitely good one and worth using it all the time. > But what prevents from using it for now is why is it *so* slow while > dragging the screen or zooming? Well. May be it is not. But in TangoGPS > it just moves the screen, when u drag with a finger and then loads PNG > so it looks like response(somehow). And in omgps I feel like it hangs > for certain amount of time. > > Another question. Why did you limit the number of GPX traces? Why just > not to go unlimited? > > There is also a repo in TangoGPS called googlesat, which is better than > YahooSat in quality. Can it be added? Or could instructions for adding > it to omgps be posted? > > Thank you for improved GPS handling in FreeRunner! Now we have something > to compete with TangoGPS. > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunneromgps-tp2948257p2955790.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
It's the two sides of a coin. It's not a good idea to suppose something that we are not sure, right? Let me explain. 1. Think about app A save it's maps to dir_a, app B save it's maps to dir_b, and c, d... What about when the "default" one changes it's directory? 2. soft link is the best choice. If you suddenly flashed a new image, and forgot to backup, the MicroSD partition saves you time and energy. If the Os can't boot, you can still read/backup data from MicroSD. I did not suppose user is root at all, even though we are all roots, that's why I soft link *.py to $HOME/.omgps/, because compiled python binary file is saved to the directory which contains the source *.py module. Risto H. Kurppa wrote: > > On Thu, May 21, 2009 at 11:54 AM, arne anka wrote: >>> Looks great but PLEASE use /home/root/Maps to store map tiles -> share >>> with Tangogps... right..? >> >> NO! >> please, use $HOME/... >> this "we're all root!" madness has to stop -- and hardcoding paths like >> that is really bad anyway. > > Oops, sorry, you're right :) But anyway I think it'd be great to use > the same folder that Tangogps uses ($HOME/Maps) -> I have some 300 000 > png tiles there, it's just waste of space, bandwith and time to > download separate files for both - and if/since everyone will symlink, > why not do it by default.. > > > r > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2952293.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
1. "Center" button is not "auto center" which waste power -- that's on each update, if the screen distance between new position and previous one greater than (say 5 pixels), the position is redrawn. As of "auto center", the whole map must be updated, that's really a waste. 2. Each time you press the "Center" button, it switch to "keep location in view" mode. In this mode, if you don't pan (drag) map, it keeps the location(position) in view, else the view back layers are not updated. About the foot: it means tracking. By default on each start the tracking is not enabled, so the image is a foot with "x" on means tracking is disabled now. If you start tracking, the image is updated to another foot without "x" sign on it. William Kenworthy wrote: > > On Thu, 2009-05-21 at 08:52 +0200, David Reyes Samblas Martinez wrote: >> Nice app :) >> I know it should be no easy, but a feature that I miss both in Tango >> and this is the ability to rotate the maps accordingly the direction > > I am still waiting for gps lock (actually just got it ... in the > office :), but it looks nice so far. symlinking the map directory to > the tangogps store works fine. > > One thing that all gps apps I see on the FR so far do is centre the > cursor/position. Thats fine when standing still, but I am not really > interested in where I have been, but where I am going so it would be > nice if the cursor/centre of the display was offset appropriately. > > Can someone tell me: > what the "foot" with a red cross through it means - doesnt seem to do > anything. > and similarly, the two diagonal opposing arrows next to it. > > BillK > > > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2952181.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LCD Displays?
What about protection film? Tim Schmidt wrote: > > On Thu, May 21, 2009 at 9:12 AM, zogg wrote: >> Looks like LCD for indoors are common, and for outdoors theres scarcity. >> So, do you know any manufacturers, or at least in what direction should >> i try and look at? > > The OLPC has an LCD which is very easy to read in daylight. When > backlit, it appears as a color LCD, but when frontlit (as from the > sun), it appears greyscale. This is a function of the OLPC's very > efficient backlight system (instead of using colored filters to block > out 66% of the light from the white backlight for each pixel, they use > a fresnel prism to split the backlight into it's component wavelengths > on pixel boundaries. Thereby allowing nearly 100% of the light > produced by the backlight through to your eyes, as opposed to less > than 33% for typical LCDs. Light from the front of the LCD passes > through the pixels, and is reflected by a silvered layer, back through > the pixels to your eyes, never passing through the prism, so what > would normally be colored sub-pixels appear as greyscale pixels. > > --tim > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/LCD-Displays--tp2950632p2950710.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
Wild! No easy sure. But... can be done with: (1) a bigger background pximap (2) iimage rotation (3) curve fitting to determine direction (4) semi transparency as you said Waste energy! However, to see clearly in sun light, you have to adjust backlight nearly 100%, thus energy is not a problem. Since most road segments are straight, I recommend you upgrade your "supporting frame" rotate-able :D I'm also a biker, but I'm doubting if it is safe to keep watching on the screen while moving. That's why I develop the sounding module. So, your requirement can be classified as "optional", agree? 2009/5/21 David Samblas Martinez (via Nabble) : > Nice app :) > I know it should be no easy, but a feature that I miss both in Tango > and this is the ability to rotate the maps accordingly the direction > you are moving on to have always up i the screen what you have in > front of you. Maybe a semi transparent Compass on the scree can help > to not get confused. offcourse it has to be an option you can > dissable/enable. > But when you move in bike for example it can be an awesome feature. > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2950687.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
Thanks, good suggestion. More works are needed for integrating with OSM better. Ease of recording is preferred anyway, which helps post-processing. I'm thinking about how to collect issues, what about http://code.google.com/p/omgps/issues/list ? 2009/5/21 Stefan Monnier (via Nabble) : >> After nearly 5 months development, I'm happy to announce the first alpha >> release of omgps. > > Looks like a great alternative to TangoGPS. I like the ability to write > on the map and save it as a screenshot. But I would even prefer a way > to take notes via the microphone and/or the keyboard, automatically > associated with the current GPS position. > > > Stefan -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2950308.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GPS] new GPS GUI application for OM freerunner
You can do it by soft link. Actually I soft link /home/root/.omgps to a sdcard partition. I haven't test the share yet :) Risto H. Kurppa wrote: > > Looks great but PLEASE use /home/root/Maps to store map tiles -> share > with Tangogps... right..? > > > r > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2948622.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[GPS] new GPS GUI application for OM freerunner
Hi all: I got my gta02 freerunner on DEC 2008. After nearly 5 months development, I'm happy to announce the first alpha release of omgps. It is not as feature rich as other GPS applications, such as tangoGPS, anyway I think it should satisfy most of the daily needs. Please goto http://code.google.com/p/omgps/, download and give a try. After ten years of programming as a web developer for most of the time, now I join the community with my little gift :) Thanks you to open source community -- for your great works and spirits. -- View this message in context: http://n2.nabble.com/-GPS--new-GPS-GUI-application-for-OM-freerunner-tp2948257p2948257.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Automatic screen lock
As of simple lock (which does not turn off display backlight power),
I think you don't need configure simple lock in frameworkd.
The AUX key binding is enough -- just a press to lock screen.
If you really need the way of auto + manual, you have to write a ROBUST
application,
which listens to DBUS signals (idle + input event). Here is the pseudo C
code:
int locking = 0;
pthread_mutex lk = ...;
void lock_screen()
{
pop up screen lock window which lay on top of other windows;
optionally turn off display backlight power;
locking = 1;
}
void unlock_screen()
{
close the screen lock window;
turn on display backlight power if it was turned off.
locking = 0;
}
void dbus_idle_signal_handler()
{
if (should lock screen) {
lock(lk);
if (! locking)
lock_screen();
unlock(lk);
}
}
void dbus_input_event_signal handler()
{
if (input event type == "pressed") {
lock(lk);
if (locking) {
if (button is "AUX" || button is "POWER")
unlock_screen();
} else {
if (button is "AUX")
lock screen();
}
unlock(lk);
}
}
Christian Rüb wrote:
>
> Hi,
>
> as I could not find another way to lock the screen I currently use this
> little script (illume + frameworkd):
>
> /usr/local/bin/simple_lock:
> #!/bin/sh
> export E_IPC_SOCKET=$(find /var/ -type s | grep enlightenment | cut -d\|
> -f1)
> enlightenment_remote -exec-action "simple_lock" ""
>
> in /etc/freesmartphone/oevents/rules.yaml:
> -
> trigger: IdleState()
> filters: HasAttr(status, "lock")
> actions: Command('/usr/local/bin/simple_lock')
>
> AUX button is also bound to desktop simple lock - otherwise it is
> impossible to unlock (withou sshing onto the phone)!
>
> Unfortunately it does not always lock the screen, as the "simple_lock"
> action seems to be a toggle. Thus when you manually turn the lock on (via
> AUX) the power state "lock" now reverts the manually acquired simple lock.
>
> Are there any plans to support a real locking in frameworkd - something
> like a touchscreen/keyboard resource? Or is there a way in enlightenment
> to force the lock and off?
>
> Cheers,
> Christian
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
--
View this message in context:
http://n2.nabble.com/Automatic-screen-lock-tp2913196p2913876.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
I tried again, it works as expected. KaZeR wrote: > > > Hello list, > > I also noticed last time i tried that i wasn't able to filter GPLL, GPGSA > and friends using the ubxgen script from the wiki. > Is it related? > > -- View this message in context: http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2889709.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
read this: http://www.nabble.com/GPS-at-4-Hz-td17096809.html
NOTE about "baud rate". If you can't change it, you can disable some NMEA
messages to make sure
the default baud rate (9600) is ok for 4hz rate.
On page 106, u-blox5_Protocol_Specifications(GPS.G5-X-07036).pdf says:
"... The calculation of the navigation solution will always be aligned to
the top of a second."
Vasco Névoa wrote:
>
>
> I've tried configuring (via frameworkd's om.py) the chip with a 3000ms
> period between samples, and sure enough gpspipe is outputting only one
> set of messages per every 3 seconds - so this proves my CFG-RATE
> message is correctly delivered.
>
> However, I also see that the gpspipe output is... chaotic. Although
> the NMEA timestamps are always correct (they skip 3 seconds),
> sometimes the messages are delayed and then delivered in batches. For
> example, there is nothing for 6 seconds, and both messages are
> delivered together.
>
> If I set the period to 5.25 seconds, I can see that all the timestamps
> coming out of gpspipe end with ".00", which is obviously wrong.
> Many of the sentences are repeated, like the SW couldn't wait for the
> next UBX data block and just repeated the last data block.
>
> Who is doing this sample mangling?
>
>
>
> Citando Vasco Névoa :
>
>>
>> Hi all.
>>
>> I'm used to putting the GTA02's ublox chip into 4Hz sample mode for my
>> research projects, but ever since I started using FSO and derivatives
>> I can't get it to spit out anything other than 1Hz samples - so I just
>> stop "fso-gpsd", configure the chip at my own will, and read directly
>> from /dev/ttySAC1.
>> However, this is the unfriendly way to do it, and I'd like to
>> integrate this option with FSO.
>>
>> So I found the initialization sequence inside
>> "/usr/lib/python2.6/site-packages/framework/subsystems/ogpsd/om.py"
>> and added this to the end of "def initializeDevice", just before the
>> "self.huiTimeout = gobject.timeout_add_seconds( 300,
>> self.requestHuiTimer )":
>> # increase sample data rate to 4Hz:
>> self.send("CFG-RATE", 6, {"Meas" : 0x00fa, "Nav" : 0x0001,
>> "Time" : 0x})
>> Unfortunately, it doesn't change anything. "gpspipe -r" will still put
>> out a single set of messages per second, even though the GPS chip is
>> (hopefuly) configured for 4 sets per second. When used with the
>> original gpsd in other older distros, this didn't happen; gpspipe -r
>> outputs whatever the the gpsd delivers. So the problem is most likely
>> in FSO's ogpsd implementation.
>> Sending a u-blox binary string into /dev/ttySAC1 with the same config
>> message while fso-gpsd is working also doesn't work out (I've tried
>> many times just in case I'm racing with the framework and messages get
>> mangled).
>>
>> I've combed the framework code in that folder trying to find any 1s
>> cycle hardcoded, but everything looks as it should: event-triggered by
>> available data.
>> So the 1M€ question is: where the heck is this 1s polling cycle
>> defined? How can I get the ogpsd framework to output 4 samples per
>> second instead of 1?
>>
>> Any hints will be appreciated.
>>
>> Thx,
>>
>> V.
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
--
View this message in context:
http://n2.nabble.com/-FSO-SHR--ogpsd-fso-gpsd%3A-can%27t-get-4Hz-sample-rate-tp2884445p2886833.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
On SHR with latest kernel of version 2.6.29-rc3, current is about 62.5 mA, 100% capacity. Here is link to the kernel: http://shr.bearstech.com/shr-unstable/images/om-gta02/uImage-2.6.28-oe1+gitr119778+9c4451ff31b937a478f3d3eabef30b71cbe12b12-r3.1-om-gta02.bin The name mismatches with actual kernel version, it shows 2.6.29-rc3 on boot. Rask Ingemann Lambertsen wrote: > On Sat, Mar 28, 2009 at 07:32:24PM +0100, Richard Kralovic wrote: >> It may be the case that the fixes for the current leak were introduced >> in devel branch (linux-openmoko-devel). On kernel 2.6.29-rc3, my tests >> show a drop from cca 80mA to cca 47mA. > >Do you know which git revision that kernel is? Alternatively, where did I am using gitr1e257a0e99817a338e3706708ebb5036518e46d8, I compiled it myself. Richard > you get that kernel from? > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2582277.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Hi,
Thanks a lot!
With "echo > /sys/bus/spi/devices/spi2.0/state sleep", the current drops
from 82.125 mA to 81.562 mA within 10 minutes. The battery is fully charged
before test.
My kernel:
# uname -a
Linux om-gta02 2.6.28-rc4 #1 PREEMPT Sun Feb 8 19:53:16 CET 2009 armv4tl unknown
Before read your reply, I get nothing by removing SD card, ifdown usb0, power
off backlight.
Here is the new script I used:
#!/bin/bash
# for exit SSH shell, unplug USB
sleep 5
# strange, 1 to power of backlight
echo > /sys/class/backlight/gta02-bl/bl_power 1
echo > /sys/bus/spi/devices/spi2.0/state sleep
for ((i=0; i<20; i++)); do
echo "i = $i:"
cat /sys/class/power_supply/battery/{current_now,capacity,voltage_now}
sleep 30
done
echo > /sys/class/backlight/gta02-bl/bl_power 0
echo > /sys/bus/spi/devices/spi2.0/state normal
But comparing to your ~50 mA, 82 mA is still too large :)
Could anybody who has latest SHR installation on GTA02, give a test to verify?
Before start this script, please make sure:
1. `/sys/bus/platform/devices/neo1973-pm-gps.0/pwron` output 0, else you can
echo 0 into it.
2. disable GSM/WIFI/Bluetooth in SHR settings
3. SSH to FR through USB if you haven't connect to it.
4. stop /etc/init.d/xserver-nodm, /etc/init.d/frameworkd
5. killall batget; killall wakerd;
6. start the above script, e.g. `power.sh > output_power.txt &` , exit SSH
shell, unplug USB
10 minutes later, you can plug USB and SSH into FR again. If you can't wait for
10 minutes,
modify "sleep 30" to "sleep 5" or something else.
I'd like to say "thank you" to Rask Ingemann Lambertsen again :)
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
> To set brightness: write (brightness_percent / 100 * 255) to file
> "/sys/class/backlight/gta02-bl/brightness"
I think that's why you get so high currents. This
# echo >/sys/class/backlight/gta02-bl/brightness 0
doesn't do what you hope it does. You should try
# echo
>/sys/class/i2c-adapter/i2c-0/0-0073/pcf50633-regltr.9/glamo3362.0/glamo-spi-gpio.0/spi2.0/state
sleep
also. A shorthand for that file is /sys/bus/spi/devices/spi2.0/state. When
the display isn't blanked, it reads 'normal'.
But, IMHO, consider using a higher-level interface (such as
freesmartphone.org) to turn off the display instead of trying to find all
the places to mess with under /sys yourself.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
View this message in context:
http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2549904.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: test result of battery current against display brightness and GPS power mode
Thanks for the tip.
My previous test program is written in C. I write a bash script and test again.
GPS, WIFI, bluetooth, GSM, xserve, fso-frameworkd, python, batget are
disabled/closed.
OS suspending is disabled in SHR settings.
With top command, I watch for a while to make sure no process other than top
and dropbear
using more than 0.1% CPU cycles. Then start the script and unplug USB.
#!/bin/bash
for ((i=0; i<120; i++)); do
sleep 30
echo "i = $i:"
cat /sys/class/power_supply/battery/{current_now,capacity,voltage_now}
done
The result is almost same with my previous test, on newly updated SHR:
Within 60 minutes, capacity drops from 100% to 91%, voltage drops from 4.16 V
to 4.06 V,
current increases from 103.5 mA to 104.5 mA,
On Fri, Mar 27, 2009 at 05:21:59AM +0800, Qingyou Meng wrote:
>To save power, we set display brightness to 0% by locking screen,
> but OS still consumes 95 mA, leaving at most ~10 hours battery life!
You must have done something wrong. I frequently test power comsumption
and I get 54 mA on a fully charged battery, dropping slowly as the battery
discharges[1] and nearly 20 hours battery life.
FWIW, I test with this command on a Debian installation:
sleep 120 && cat
/sys/class/power_supply/battery/{status,current_now,voltage_now,capacity}
[1] It's supposed to be the other way around - current increasing as the
battery discharges - but there's a current leak somewhere. It was down to 46
mA not too long ago with a kernel from the andy-tracking branch.
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
--
View this message in context:
http://n2.nabble.com/test-result-of-battery-current-against-display-brightness-and-GPS--power-mode-tp2541178p2544244.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Good news: FixNow mode can be wakenup through serial port
Hi,
Glad that power safe mode will be implemented into ogpsd.
Although serial port is enough, it's really good if somebody can point out
how to wakeup through EXTINT0.
I've seen UBX binary codes in ogpsd, so the basic implementation is simple.
My codes are written in C instead of Python, so I post pseudo codes here:
enum
{
FIXNOW_DISABLED,
FIXNOW_ENABLED,
};
static int fxn_mode = FIXNOW_DISABLED;
/* set CFG-RXM */
unsigned char packet[] = {
0xB5, 0x62, /* header */
0x06, 0x11, /* message type: CFG-RXM */
0x02, 0x00, /* length */
0x03, /* GPS sensitivity mode: auto */
0x01, /* low power mode: FixNow */
0x00, 0x00 /* check sum: to be set */
};
unsigned char wakeup[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
0xB5, 0x62, 0x02, 0x40, 0x00, 0x00, 0x42,0xC8 };
int write_ubx_packet (unsigned char *buf, int size)
{
if (fxn_mode = FIXNOW_ENABLED) {
// TBD: write wakeup[];
sleep(1); /* suitable? */
}
int success = 0;
// TBD: write buf and set success;
return success;
}
/* see U-BLOX document for more details */
int configure_fxn(unsigned char t_off_minutes)
{
/* suitable? */
unsigned char acq_minutes = 3;
unsigned char acq_off_minutes = 3;
unsigned char ms_acq = acq_minutes * 60 * 1000;
unsigned char ms_acq_off = acq_off_minutes * 60 * 1000;
unsigned char ms_t_on = 15 * 1000; /* 15 seconds, note: suitable? */
unsigned char ms_t_off = t_off_minutes * 60 * 1000;
unsigned char req[4], req_off[4], on[4], off[4];
int i, j;
for (i=0; i<4; i++) {
j = i << 3;
req[i] = (ms_acq >> j) & 0xFF;
req_off[i] = (ms_acq_off >> j) & 0xFF;
on[i] = (ms_t_on >> j) & 0xFF;
off[i] = (ms_t_off >> j) & 0xFF;
}
unsigned char packet[] = {
0xB5, 0x62,
0x06, 0x0E, /* CFG-FXN */
36, 0x00, /* length */
0x02 | 0x10, 0x00, 0x00, 0x00, /* flags */
req[0], req[1], req[2], req[3], /* t_reacq: default 20 minutes
*/
req[0], req[1], req[2], req[3], /* t_acq: default 20 minutes */
req_off[0], req_off[1], req_off[2], req_off[3], /* t_reacq_off:
default
100 minutes */
req_off[0], req_off[1], req_off[2], req_off[3], /* t_acq_off:
default 100
minutes*/
on[0], on[1], on[2], on[3], /* t_on */
off[0], off[1], off[2], off[3], /* t_off */
0x00, 0x00, 0x00, 0x00, /* res */
0x00, 0x00, 0x00, 0x00, /* base_tow */
0x00, 0x00 /* checksum */
};
int success = 0;
// TBD: checksum the packet and write to serial port, optionally read
ACK
return success;
}
#1 enable FXN mode (before suspend?)
if (! configure_fxn(30)) { /* offtime: suitable? */
// ignore
}
if (fxn_mode == FIXNOW_DISABLED) {
// 1. checksum packet[]
// 2. write this packet to serial port, and optionally read ACK
to check
success or not
if (success) {
fxn_mode == FIXNOW_DISABLED;
} else {
// ignore
}
}
#2 disable FXN mode (after resume?)
if (fxn_mode == FIXNOW_ENABLED) {
packet[7] = 0x00; /* continuous tracking mode */
// TBD: checksum packet[]
int success = 0;
int fail_counter = 0;
int max_fails = 5;
while (! success) {
// TBD: write this packet to serial port, and
optionally read ACK to
check success or not
success = ...;
if (! success) sleep (1);
if (++fail_counter == max_fails) {
// TBD: power off then power on
break;
}
}
fxn_mode == FIXNOW_DISABLED;
}
#3 poll navigation data (no matter in FixNow mode or not)
// TBD: prepare request packet
// TBD: call write_ubx_packet()
Regards,
mqy
In FixNow mode, NOTE:
1. to save power, the poll interval should not be small enough (e.g, less
than 15 seconds?)
2. occasionally, no fix available
3. my test result shows no NMEA output even the GPS chip is waken up. Need
verify.
Daniel Willmann wrote:
>
>
> This sounds quite promising. How was FixNow configured in that case?
>
> I think you misunderstood that post. In there Andy says that the GPS
> will have no way to wake us up if it has a fix. What is possible is to
> put the GPS into FixNow mode and wak
Good news: FixNow mode can be wakenup through serial port
U-BLOX GPS chip ANTRAIS 4 and above can run in several power modes:
0: Continuous Tracking Mode, about 3.5 mA
1: Fix Now -- sleep mode about 130 uA
Fix Now mode can be enabled by ubx binary message CFG-RXM. Detailed
parameters are configured by CFG-FXN.
One of the problem is how to activate (wake up) from sleep mode. I've read
several message lists discussing this issue, it seems no way to wake up
through serial port.
http://kerneltrap.org/mailarchive/openmoko-kernel/2009/1/22/4794494/thread
I've tried make GPS chip goes into sleep mode several days ago, but can't
wakeup it.
Last night I found good references through google:
1.
http://www.u-blox.com/customersupport/gps.g3/ANTARIS_EvalKit_User_Guide(GPS.G3-EK-02003).pdf
"When waking up TIM-Lx with RxD1, RxD2 from sleep- or backup state send a
number (at least 8) of
0xFF characters to wake up the serial communication module otherwise the
first bytes may get lost. To
request a position fix a position request message must be sent via serial
port after waking up the
ANTARIS GPS Receiver."
2.
http://www.mikrocontroller.net/attachment/36822/NL_60415_-_Datenblatt_u-blox_GPS_Module_24092007_481.pdf
5.3.3 Change operation mode
"Please add header with dummy data for any command when the GPS module is in
sleep mode. This is required for wake-up in sleep mode. The dummy data in
hexadecimal is “0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF”."
I've test this with ubx binary protocol:
1) enable FixNow (sleep mode) by CFG-RXM, configure CFG-FXN
2) periodically poll NAV-POSLLH, NAV-VELNED, NAV-SVINFO. Before writing each
poll request, write
unsigned char array {0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,
0xB5,0x62,0x02,0x40,0x00,0x00,0x42,0xC8};
/* note: first line: dummy data, second line: RXM-POSREQ */
then sleep 1 second;
3) toggle between "Continuous Tracking Mode" and "FixNow mode" by call
CFG-RXM (if in FixNow mode, first write dummy data and RXM-POSREQ)
With MON-SCHED, the average GPS CPU load in "Continuous Tracking Mode" is
about 35%, regardless of send_rate, max nav SVs, 2d/2d nav mode. No
performance test data for FixNow mode for now.
--
View this message in context:
http://n2.nabble.com/Good-news%3A-FixNow-mode-can-be-wakenup-through-serial-port-tp2476690p2476690.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
I'm not using ogpsd. The parser is written by I myself. My strategy is to filter out dumped ALM/EPH messages which contain zeros after SV id in payload. Need more tests to verify this can avoid chip crash :) 2009/3/9 Daniel Willmann (via Nabble) : > On Tue, 3 Mar 2009 06:47:26 -0800 (PST) > mqy wrote: > >> >> I've verified the issue on GPS receiver in GTA02: >> >> When dump ALM/EPH messages, in several messages, fields follow SV ID >> field in payload are filled with zeros. > > Okay, so what you're saying is that this commit > http://git.freesmartphone.org/?p=framework.git;a=commitdiff;h=ad2ec48cdb5ab9bdddc15adfc05cbd2e5b8a2cee > doesn't fix the situation for you? > If that is the case could you please send me the ALM/EPH messages that > you get when the chip crashes so I can take a look at it? > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > signature.asc (204 bytes) Download Attachment > > > This email is a reply to your post @ > http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2446510.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2447874.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GPS: CFG-PRT, port #3 is enabled by default, power consumption?
Here is the results of polling CFG PRT (0X06 0X00): (1) port #1 (id = 0x00)--> 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 (2) port #2 (id = 0x01)--> 0x01 0x00 0x00 0x00 0xd0 0x08 0x08 0x00 0x80 0x25 0x00 0x00 0x07 0x00 0x03 0x00 0x00 0x00 0x00 0x00 (3) port #3 (id = 0x02)--> 0x02 0x00 0x00 0x00 0xd0 0x08 0x08 0x00 0x00 0x96 0x00 0x00 0x07 0x00 0x03 0x00 0x00 0x00 0x00 0x00 (4) port #4 (id = 0x03)--> 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x03 0x00 0x03 0x00 0x00 0x00 0x00 0x00 Also, note that both NEMA and UBX binary are enabled on port #4 -- in and out protocols. GPS receiver continue sending messages to a port on which NEMA is enabled. Is this true when the port is not assigned a serial port device (say, /dev/ttySACx)? -- View this message in context: http://n2.nabble.com/GPS%3A-CFG-PRT%2C-port--3-is-enabled-by-default%2C-power-consumption--tp2418772p2418772.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
I've verified the issue on GPS receiver in GTA02: When dump ALM/EPH messages, in several messages, fields follow SV ID field in payload are filled with zeros. Daniel Willmann wrote: > > On Sun, 1 Mar 2009 14:25:14 -0800 (PST) > mqy wrote: > >> " >> UBX-AID-EPH and UBX-AID-ALM Messages for Satellite without valid >> Orbits When polling UBX-AID-EPH or UBX-AID-ALM messages, satellites >> without valid ephemeris or almanac data will >> return a complete UBX-AID-EPH or UBX-AID-ALM message with all data >> words set to zero. This doesn’t comply >> with the protocol specification. Furthermore, u-blox 5 receivers with >> firmware V5.00 and earlier can run into a >> floating-point exception when fed with such “empty” ephemeris. >> " >> >> Is that the cause :D > > Yeah, thought that at first as well, but almanac data was okay at that > point. The position was not, however. I guess the problem the chip > tripped over is similar in both cases though. > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2415564.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
From [ http://www.u-blox.cn/customersupport/gps.g5/ublox5_Fw5.00_Release_Notes(GPS.G5-SW-08019).pdf ]: " UBX-AID-EPH and UBX-AID-ALM Messages for Satellite without valid Orbits When polling UBX-AID-EPH or UBX-AID-ALM messages, satellites without valid ephemeris or almanac data will return a complete UBX-AID-EPH or UBX-AID-ALM message with all data words set to zero. This doesn’t comply with the protocol specification. Furthermore, u-blox 5 receivers with firmware V5.00 and earlier can run into a floating-point exception when fed with such “empty” ephemeris. " Is that the cause :D Daniel Willmann wrote: > > > Yes and that's what ogpsd does already. It has been saving/restoring > almanac for months, ephemeris was disabled up until recently because > there was a bug that prevented the GPS chip from doing anything useful > after they were restored to the chip. > > ... ... > > Regards, > Daniel Willmann > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2406454.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
U-blox receiver allows polling AID-EPH, AID-ALM data. For each type, we can poll 32 messages for 32 satellites. The precondition is: current fix is valid -- at least 3 SVs has valid EPH(or ALM?) data. These data get invalid 2~4 hours later, can be stored into files, and load into GPS receiver when needed and they are valid. I've tried this, not sure whether it works or not, need more tests:) AGPS-online works fine. Raphaël Jacquot wrote: > > On Sun, Mar 01, 2009 at 08:31:16PM +0100, Daniel Willmann wrote: >> Now that hot-/warmstart with ephemeris playback works with the framework >> we should try to get an open server with aiding data available ASAP. > > is there a way to get the ephemeris data from the gps receiver at some > point ? > it could be stored on the phone and used as a calculation aide... > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2406026.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Yes, ogpsd within frameworkd saves/loads u-blox AID HUI/ALM/EPH messages. u-blox A-GPS online messages are of AID message types. Let's read the html content dumped from ghex: > b5 62 0b 01 30 00 2d 26 29 f3 ba ca 13 1a ec b7 6b 18 20 a1 07 00 00 00 ee > 05 c4 7a 67 0e 00 00 > > 00 00 f4 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00 e8 ce b5 > 62 0b 31 68 00 03 00 > > 00 00 80 59 4d 00 00 91 7b 00 51 1b 68 00 06 8a 7e 00 cd 3c 55 00 f7 fb b4 > ff c4 3b 3c 00 2e 00 > > 00 00 3b 09 2e 00 d9 fc 3c 00 0e 2e 37 00 9c 27 f2 ff 05 3d fd ff bc 6c f6 > ff a1 db 1c 00 8f f7 > > 0d 00 7f c4 3b 00 0d c9 ff ff 33 17 41 00 25 59 00 00 22 32 c1 ff 24 44 0c > 00 e5 50 46 00 16 a4 > > ff ff 33 06 3c 00 e2 f7 b5 62 0b 31 68 00 06 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 f6 fb b4 ff c4 3b 20 00 82 ff 00 00 10 12 08 00 0b fe 20 > 00 75 5d 34 00 c2 12 > > ae ff 02 fb fd ff 4e 22 ec ff a1 0e 1d 00 79 ca 0d 00 7c c4 3b 00 0f 3c 00 > 00 d4 c1 f8 ff 26 f8 > > ff ff dc 30 0f 00 c4 df 0b 00 e7 c0 95 ff 0c a8 ff ff 3b 0b 20 00 2b 9d b5 > 62 0b 31 68 00 19 00 > > 00 00 80 59 4d 00 00 92 7b 00 51 1b 70 00 06 8a 7e 00 cd 3c 55 00 f0 fb b4 > ff c4 3b 6b 00 db 00 > > 00 00 1f a6 1e 00 ff 0c 6b 00 8a bb 31 00 cc bd ea ff 06 1a 0b 00 88 76 0a > 00 a1 9b 07 00 27 59 > > 0d 00 7f c4 3b 00 b8 39 00 00 22 17 98 ff 27 12 00 00 c8 d0 70 00 cd 13 27 > 00 b7 86 fa ff 77 a6 > > ff ff eb 11 6b 00 9e ee b5 62 0b 31 68 00 13 00 00 00 00 f1 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 e1 fb b4 ff c3 3b 0c 00 fb ff 00 00 46 46 04 00 57 00 0c > 00 29 41 2f 00 48 c4 > > d7 ff 02 49 00 00 75 0b a2 ff a1 b9 1c 00 3a 5d 0e 00 1c c3 3b 00 14 3d 00 > 00 cb 85 b9 ff 27 17 > > 00 00 68 fa 05 00 f0 fa 0d 00 07 56 28 00 c0 a9 ff ff 59 10 0c 00 30 ab b5 > 62 0b 31 68 00 0d 00 > > 00 00 80 59 4d 00 00 90 7b 00 51 1b 60 00 06 8a 7e 00 cd 3c 55 00 e8 fb b4 > ff c4 3b 29 00 0b 00 > > 00 00 c8 c3 25 00 b1 09 29 00 39 9f 24 00 00 9d 3e 00 01 0f 08 00 65 c0 ed > ff a1 85 1d 00 a4 18 > > 0e 00 7c c4 3b 00 94 e8 ff ff d3 5b 00 00 28 d7 ff ff 20 85 8f ff 3d 86 0f > 00 60 1c 5a 00 25 ae > > ff ff 94 01 29 00 0d b3 b5 62 0b 31 68 00 10 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 eb fb b4 ff c4 3b 1d 00 e7 ff 00 00 cd e8 09 00 9d f1 1d > 00 74 3a 31 00 84 6b > > 89 ff 02 a4 f3 ff 15 cc 98 ff a1 fa 0c 00 94 1a 0e 00 63 c4 3b 00 e7 d7 ff > ff 4a a6 fe ff 27 3a > > 00 00 19 e8 6d 00 f0 d2 20 00 cc 99 42 00 53 a6 ff ff 6f ee 1d 00 be a9 b5 > 62 0b 31 68 00 17 00 > > 00 00 80 59 4d 00 00 91 7b 00 51 1b 68 00 06 8a 7e 00 cd 3c 55 00 d5 fb b4 > ff c4 3b 66 00 06 00 > > 00 00 ec b1 32 00 a2 08 66 00 14 e9 2a 00 af 4b 56 00 02 2f 07 00 b4 41 f6 > ff a1 a1 1c 00 0f 39 > > 0d 00 7d c4 3b 00 91 31 00 00 68 58 fc ff 27 f3 ff ff e4 48 91 ff 75 ca 0e > 00 3b 50 5e 00 a1 aa > > ff ff 32 fe 66 00 28 bd b5 62 0b 31 68 00 07 00 00 00 80 59 4d 00 00 90 7b > 00 51 1b 60 00 06 8a > > 7e 00 cd 3c 55 00 e9 fb b4 ff c4 3b 1b 00 fd ff 00 00 ca fb 02 00 04 0a 1b > 00 d3 73 33 00 ad 74 > > 71 00 01 79 08 00 ac 04 2e 00 a1 5e 06 00 05 64 0d 00 45 c4 3b 00 bc df ff > ff 5a 61 74 00 27 c0 > > ff ff 7f 27 58 00 77 90 28 00 53 f6 32 00 7c a3 ff ff 10 10 1b 00 88 4b b5 > 62 0b 31 68 00 15 00 > > 00 00 80 59 4d 00 00 90 7b 00 51 1b 60 00 06 8a 7e 00 cd 3c 55 00 e7 fb b4 > ff c4 3b 5f 00 f0 ff > > 00 00 9a e3 03 00 51 06 5f 00 ad bd 3d 00 0f b8 df ff 07 f8 04 00 91 5c 7e > 00 a1 03 09 00 4a 19 > > 0d 00 7c c4 3b 00 3d 55 00 00 e3 4e 49 00 26 b8 ff ff 62 b9 0f 00 94 48 23 > 00 70 fd 28 00 9d a1 > > ff ff 27 18 5f 00 0c b6 b5 62 0b 30 28 00 19 00 00 00 ee 05 00 00 9f 60 59 > 00 b3 10 63 00 00 48 > > fd ff f7 0c a1 ff 64 8a b8 ff b0 01 ce ff 80 ec 45 00 e5 00 1f 00 ac f0 b5 > 62 0b 30 28 00 13 00 > > 00 00 ee 05 00 00 32 2a 53 00 f9 09 63 00 00 5c fd ff f1 0d a1 ff 4b ac 14 > 00 7d 23 f0 ff 37 ec > > . Each individual message format is: 1. head: b5 62; 2. the message class/id, e.g. 0b 01, 0b 30, 0b 31; 3. 2 bytes content length; 4. message content; 5. 2 bytes checksum. There is no message head in offline data file from u-blox (e.g, http://alp.u-blox.com/current_1d.alp), this prevents us from extracting (and/or calculate) AID data then load into u-blox GPS receiver. As of HUI/ALM/EPH, ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm says: See ICD-GPS-200 for a full description of the contents of... Sigh, If freerunner has flash memory, the offline data can be directly submitted to u-blox GPS receiver. Helge Hafting wrote: > > Cédric Berger wrote: >> On Wed, Feb 18, 2009 at 17:49, Al Johnson >> wrote: >>> I may be misunderstanding the suggestion, but I don't think it had >>> anything to >>> do with data from ublox. The suggestion was to use data sent by other >>> freerunner users instead of the data supplied by ublox. >> >> As I understood the suggestion was in reply to : >> It is not a problem that user account is required when download u-blox online aiding
Re: thoughts on A-GPS offline
It is not a problem that user account is required when download u-blox online aiding data. The download protocol is fairly simple, can be implemented within several hours in C. (1) appaly for a free account by sending a email to u-blox (2) format request package by filling in user/password/lat/lon and other optional data such as pacc, (3) submit request and get response data, (4) parse aiding data from the reply (it's a block of binary data after header lines), (5) write the binary data to GPS device. The binary data block contains about 50+ individual aiding messages The account is free. AFAIK, u-blox AsssistNow service should be one of the most open/free A-GPs services, and the up-to-14 days offline data is very attractive comparing to others. What I'm concern is: don't know how to eat the "big cake" without knowing the format -- unlike online data, there is no ubx binary message headers (0xB5, 0x62) inside offline file. I guess, each alp file (N days) should be contains the following data: time range(from, to): each file contains data of [1,2,3,5,7,10,14] days region IDs: the earth is divided into R regions each cover a (lat/lon?) area. satellite IDs: 24 satellites each has it's unique orbit. region visible satellites: at any time only several satellites visible to a user. differential almanac correction data: for each satellite (at the unit of hours). Nothing helps regardless where the data come from, if either don't know how to extract aiding data from offline data, or data format in-compatible. Rikard Nilsson wrote: > > would it be possible to get the satelite information that we get from > u-blox from somewhere else? > somewhere that dont require user account? > > /rikard > > On Tue, Feb 17, 2009 at 12:41 PM, Timo Juhani Lindfors > wrote: >> mqy writes: >>> I think get locations by cell id is especially useful in case of weak or >>> no >>> GPS signals. >>> I'll have a look at opencellid, thanks. >> >> Note also that ogpsd of frameworkd supports sending this off-line >> aiding data. >> >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2340696.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: thoughts on A-GPS offline
Should be. I think the major consideration of u-blox A-GPS is to speed up TTFF, decrease the TTFF from at 40 seconds or so to 10 seconds or so. A-GPS online needs network connection, if network connection is unavailable, AssistNow offline or something else are expected to provide initial aiding data such as almanach and/or ephemeris. Most of the time user know his/her location, but may unable to get GPS fix due to bad environment (e.g. buildings). If we have aiding data, we can submit them to GPS chip. What data to submit depends on your current location and time. Location can be specified by (1) picking up from map, (2) or last valid location recorded by GPS software (3) or from phone network (some service providers provide this kind of service with charge fee). I think get locations by cell id is especially useful in case of weak or no GPS signals. I'll have a look at opencellid, thanks. Rikard Nilsson wrote: > >> What about if we hack the data format of u-blox AGPS offline file, and >> extract data for current location and time? location can be specified by >> clicking map, time from local system time. If we could, we would be able >> to >> submit data to GPS chip as AGPS online message on demand. What do you >> think? > > Wouldnt it be possible to get the location from the gsm-network in some > way? > > /Rikard > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2340272.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
thoughts on A-GPS offline
[1] says AGPS offline is not possible because GTA02 lacks flash memory. It seems that's the only problem. but [2] does not contain any ALPSRV messages. My test failed on first step of enabling ALP messages (according to u-blox 5 spec), it returns NAK. So I think the chip firmware does not support ALP at all. [1] http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS#Assist_Offline [2] http://www.u-blox.com/customersupport/gps.g3/ANTARIS_Protocol_Specification(GPS.G3-X-03002).chm What about if we hack the data format of u-blox AGPS offline file, and extract data for current location and time? location can be specified by clicking map, time from local system time. If we could, we would be able to submit data to GPS chip as AGPS online message on demand. What do you think? I've implemented a GPS tool for freerunner, almost finished, with features such as: AGPS online, rulers, lat/lon grid, sync time, scratch on map, power on/off device, hot/warm/cold reset, adjust message rate, selective download tiles, track records... Hope it will be released to public in 10 days. The performance is good, 2~3% CPU usage on stand-by mode. -- View this message in context: http://n2.nabble.com/thoughts-on-A-GPS-offline-tp2338403p2338403.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Miscellanious minor issues
kimaidou,
Sorry, I have the same question as well :) I'm not expert at
enlightenment and illume.
I find that .cfg files in ~/.e/ is binary format, so can't give a hack :)
What about go IRC for answers?
host: chat.au.freenode.net
channel: #openmoko-cdevel
mqy
2009/2/2 kimaidou (via Nabble) :
> Thanks a lot MQY
> This works great with all the apps using the "grey" theme. But, for the apps
> using the "golden" theme, it does not. (eg Contacts). Could you please tell
> me how to change the scrollbar size for this them too ?
>
> Thanks a lot, it is improving SHR finger "friendlyness" a lot
>
> 2009/2/1 mqy
>>
>> A temp solution is:
>>
>> create file .gtkrc-2.0 in use home dir, and add the following contents:
>>
>> style "scroll"
>> {
>>GtkScrollbar::slider-width = 25
>> }
>> class "*" style "scroll"
>>
>
>
> ___
> Openmoko community mailing list
> commun...@...
> http://lists.openmoko.org/mailman/listinfo/community
>
>
>
> This email is a reply to your post @
> http://n2.nabble.com/-SHR--Miscellanious-minor-issues-tp2235786p2257910.html
> You can reply by email or by visting the link above.
>
>
--
View this message in context:
http://n2.nabble.com/-SHR--Miscellanious-minor-issues-tp2235786p2262049.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Miscellanious minor issues
A temp solution is:
create file .gtkrc-2.0 in use home dir, and add the following contents:
style "scroll"
{
GtkScrollbar::slider-width = 25
}
class "*" style "scroll"
kimaidou wrote:
>
> Hi
>
> About the scrollbar, it is much to thin to be reachable with the finger. I
> proposed an enhancement in the trac : make the right scrollbar twice (or 3
> times) bigger, so that all soft needing it become more finger friendly
>
> Kimaidou
>
> 2009/1/29 Johny Tenfinger
>
>> > 3) Today (29 Jan 2009) I did an opkg update and opkg upgrade and Mofi
>> > Wifi hangs when I run it, even before the menu comes up. Is this known?
>> > What could be a fix? Will wicd be ported to SHR?
>>
>> With new frameworkd you firstly have to set WiFi to "on" in shr-settings.
>>
>> > 4) Sometimes the scroll bar on the left is gold (see contacts) and
>> > sometimes it is black (see settings).
>>
>> Scrollbar from contacts is from etk theme; scrollbar from shr-settings
>> is from elementary theme.
>>
>> ___
>> Openmoko community mailing list
>> community@lists.openmoko.org
>> http://lists.openmoko.org/mailman/listinfo/community
>>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
>
--
View this message in context:
http://n2.nabble.com/-SHR--Miscellanious-minor-issues-tp2235786p2253824.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] LXDE?
I've switched from debian+LXDE to SHR for several weeks. ShR is not perfect though, it is not released yet. 2009/1/18 arne anka (via Nabble) : > ok, i just played around with lxde and i am going to purge it immediately. > my main points: > - almost every component needs a font setting on its own. the default is > 10pt and that's so big you can't read anything, not to speak of buttons > being out of reach > - while lxde is able to recognice the resolution of 640x480 it fails > miserably at resizing its dialogs. there are no scrollbars and mostly the > have a stupid with of >640 just becaus it seems to be hardcoded somewhere > and thus dropdownlist etc are stretched to match that min width ... > - configuration facilities are sparse. so far i found one for > "appearance", which does not match everything and one for openbox, the > window manager. how to remove the lot of applets jamming the panle and how > to add applets or another panel is impossible to say. the config files > used sem to be rather obscure -- obconf, the openbox configurator, creates > a rc.xml which obviously is not used; since the dialogs are too big i > started them via ssh -X at the host, but whatever i did -- the changes > never appeared on the fr; even manipulating manually the xml did not do > anything. > - it might be more resource friendly, but it requires hal to run and fam > or the like, the lxappearances tool requires gtk-themes and does not > install without > - alltogether seems lxde far less finder/stylus friendly than xfce -- i > started lxlauncher which offers a tabbed gui, like the eeepc has (had?), > since i considered it far superior to a popup menu -- but after all the > trouble with the fonts it started up with 10 or 12pt fonts; totally > unsusable and no obvious way to change that (one should think that setting > the font size with _two_ tools should be enough ...) > > ___ > Openmoko community mailing list > commun...@... > http://lists.openmoko.org/mailman/listinfo/community > > > > This email is a reply to your post @ > http://n2.nabble.com/-debian--LXDE--tp1690148p2174410.html > You can reply by email or by visting the link above. > > -- View this message in context: http://n2.nabble.com/-debian--LXDE--tp1690148p2176845.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] LXDE?
Better to add a swap partition, or swap file. Else you will get out of memory error when for example apt-get install something. Here is my /etc/fstab: The 3rd line is for swap, make sure to change the first column to your partition device. If you can not create new partition for swap, just add a swap file. Refer to: http://www.go2linux.org/Swap-memory-increase-with-swap-file http://lists.openmoko.org/pipermail/community/2008-September/031106.html Better to start openmoko-panel-plugin, else you will get frustrated by the matchbox keyboard (suppose you choose it): Add a new line to file /etc/xdg/lxsession/LXDE/autostart: @openmoko-panel-plugin With the panel plugin you can easily hide/open the keyboard. BTW, the openmoko frameworkd and panel plugin eats quite a bit memory :) Maybe it's a good idea to move the tray from bottom panel to (newly created) top panel. To do this, add a new file (named for example top-panel) in /root/.config/lxpanel/LXDE/panels/ with the content of Then (1) remove the tray from /usr/share/lxpanel/profile/LXDE/panels/panel (2) OR just copy this file to dir /root/.config/lxpanel/LXDE/panels/, rename it to "config" -- this overrides the default panel configuration. The biggest problem of LXDE on touch screen phone is UI. To do right click, install libgtkstylus and add it to ~/.xsession: export GTK_MODULES=libgtkstylus.so xsetroot -solid black # strange exec startlxde NOTE: do backups before modifications. Regards. jos-3 wrote: > > Hello, > > I also want to try LXDE but I don't no how to start it up. > Can you help me please? > > (I have been reading the wiki, but I don' t get it :-( ) > > Thanks > > Jos. > > Op maandag 22-12-2008 om 19:04 uur [tijdzone +0100], schreef Michele > Renda: >> Il 22/12/2008 15:06, arne anka ha scritto: >> > someone recently suggested using LXDE instead of XFCE -- are there any >> > experiences in regard to responsibility, memory requirements and >> > functionality compared to XFCE? >> > is it really more lightweight and faster? and does >> openmoko-panel-plugin >> > work (ie is there a standard systray)? >> > >> Hello, yes I was. >> >> I used on FR and according me run faster than XFCE (and use less >> memory). Yes, if I remember well it has systray support, and it contain >> panel and plugins like XFCE. >> You can find it on Debian repository (apt-get install lxde). All >> configurations can be done via gui. >> >> Please, if you try it, please report your impressions. >> >> > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-debian--LXDE--tp1690148p1694453.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
