login
Search
12 minutes without AGPS and 4-8min with AGPS?? I hope there was a thunderstorm inside the basement where you tested this... :) Seriously, these just don't seem realistic. Compare them for example with some other devices from 2003: http://www.pocketgpsworld.com/ttffcomparisons.php. Or from ublox: http://www.u-blox.com/technology/assistnow/ (table at the bottom of the page) Surely there must be something wrong with your software/settings/hardware/environment... (or maybe they still have a lot of work to do on the GPS :)) y _________________________________________________________________ Download Messenger op je mobiel! http://www.windowslivemobile.msn.com/nl/ _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I can confirm Marcus' findings, although often mine were even slower. The difference compared to the GTA01 is enormous. Unless TTFF improves a great deal I can see A-GPS being necessary for all users of the phone. I imagine a run once app that asks you to select what world city you are closest to and populates all the required A-GPS data from an included list of lat/long locations. I've discussed this with Marcus before; one thing we wondered is whether or not anyone else has tried it? Joseph _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
This is a multi-part message in MIME format.
--------------010208010009050009030009
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
This timings are insane unless you don't even have a valid almanac,
which is rare. This doesn't look right.
--------------010208010009050009030009
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
This timings are insane unless you don't even have a valid almanac,
which is rare. This doesn't look right.<br>
<br>
Yorick Matthys pravi:
<blockquote cite="mid:BAY140-W30E8C58A2CDC008B6CE3C6FBA60@phx.gbl"
type="cite">
<pre wrap="">Marcus Bauer said:
</pre>
<blockquote type="cite">
<pre wrap="">My experience with the Freerunner is ~12 minutes TTFF (time to first
fix) without use of agps and ~4-8 minutes TTFF with agps from
agps.u-blox.com using the software from openmoko.
The Neo1973 (GTA01) had a TTFF without agps assistance of ~2 min.
</pre>
</blockquote>
<pre wrap=""><!---->
12 minutes without AGPS and 4-8min with AGPS??
I hope there was a thunderstorm inside the basement where you tested this... :)
Seriously, these just don't seem realistic.
Compare them for example with some other devices from 2003: <a class="moz-txt-link-freetext" href="http://www.pocketgpsworld.com/ttffcomparisons.php">http://www.pocketgpsworld.com/ttffcomparisons.php</a>.
Or from ublox: <a class="moz-txt-link-freetext" href="http://www.u-blox.com/technology/assistnow/">http://www.u-blox.com/technology/assistnow/</a> (table at the bottom of the page)
Surely there must be something wrong with your software/settings/hardware/environment...
(or maybe they still have a lot of work to do on the GPS ...I can affirm this for 6 opemoko devices. i guess its an internal antenna issue. as soon as you connect a external antenna to it works like a charm. but fur me thats no solution. TTFF with external antenna (perfect condition): 40 to 60 seconds TTFF with internal antenna AGPS (perfect condition): more than 1:20 minute but not always. its like gambling. I guess a miss design of the internal antenna. CU Kai _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
From what I've seen on the wiki the version of the Antares4 on the GTA02 doesn't have the memory needed to store almanac and ephemeris, last known position or time. This means that every start is a true cold start, unlike every other reasonably modern GPS we're comparing it to. It starts up thinking the time is midnight on 30th November 1999 and seems to need a fair bit of decent signal to convince it otherwise, contributing to the long startup time. It looks like there is a way around this if you look at the documentation for the assist. The AID-INI message needn't be supplied by a remote server; we can generate it locally to provide the sort of data that's stored internally most of the time. At the very least we have a fair idea of the current time and date. We should also be able to store location, almanac and ephemeris when we shut down the GPS, and provide it at the next startup. We can also have a stab at current location, based perhaps on cell ID or wifi data as discussed by some of the other threads, or on user input. I'll try to patch together something to do this based on the example perl client and server code, and see how much difference it makes. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi Al, Sounds really convincing, but how do you explain the constantly fast fix via external antenna then. I really think its an antenna issue. Also the difference of the GPGSV values support this idea. Tomorrow evening i will ask a specialist to check the antenna signal qualities. Maybe a cable is broken or there is a short circuit on the main board. I ll report about the results. CU Kai _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi, I did some tests yesterday and here are my experiences with Freerunner's GPS: First I put the Freerunner on a window sill in a penthouse, no high-rise around. I got a fix after ~20 minutes. Disappointing. Later on I walked along in a big city between a lot of high-rises. After 15 minutes, the neo found the first satellite, but nothing more, no fix, only a gps-time. After 30 minutes I activated the power management (first dim, than lock) so the neo could be sleeping again, I gave up. Very Disappointing. A few hours later I sat down on a canvas chair at a bank of a more than 510 meters wide river in the same city, the last high rises are more than 100 meters behind me. I woke up my neo, unlocked it, started tango gps, looked at it. Nothing. I looked to the left and to the right, looked again at my neo. Stop. looked again at my neo and couldn't believe my eyes. There are 5 satellites in the display, the gps chip is using 3 of them. I GOT A FIX in less than 20 seconds! Very amazing! After one more minute, the neo was using 8 of 11 satellites. That was a really great experience. After the neo got the fix, I nearly could do everything I want, it won't loose it. I walked back in the city, worn the neo inside the pouch in my trouser pocket, around me all this big high rises. It was still tracking me and drawing this very interesting red line in my tango gps map. I couldn't believe it. I went to the home of a friend, gone up the staircase and took the neo out of my pocket in the apartment. I couldn't believe my eyes again. Tango gps was still drawing the red line, even in the staircase. It looked like: ___________ | _________| | |_ | Unfortunately I missed the chance to take a screenshot, but it was really amazing. My conclusion is that the chipset can't be so bad :) But the question is: Why is it so hard to get a fix, when there is something around? Is there any space for software improvements? Maybe different search algorithm or is it all in the hardware or driver-side? (All without an external gps ...
I've seen the same sort of thing. If the signal is at all poor getting the initial fix will be very slow if i happens at all. Once it has the fix it manages to keep it in locations my Garmin won't, and when it drops the fix it will reacquire quickly so long as it is kept powered. This is why I think feeding it good initialisation data could help with the poor startup time. My first step is to feed it time and location, but I have an error in my conversion from lat & lon to ECES x,y,z which is throwing things at the moment. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hmm, my results so far: First run with external antenna on the roof: GPS time after about 15 Minutes, TTFF 1599 seconds. Still, the position tangogps showed me was about 1 km off from my real position, and kept changing (with 4 visible satellites). Trying again now, after restarting agpsui, TTFF is only 55 secs, and now I see 6 satellites. Weird... Regards, Konstantin _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I'm having some trouble getting GPS to work on my Freerunner Having installed gpsd and tangogps, I tried starting gpsd and got: Starting gpsd: No /dev/ttyS3 GPS device, aborting gpsd startup. Check /etc/default/gpsd and tangogps couldn't find the gps receiver I saw this irc log: http://www.hentges.net/tmp/logs/irc/%23openmoko/2008/February/20080203_openmoko.log So I tried this: gpsd -n /tmp/nmeaNP and tangogps could at least find the receiver, but didn't find any satellites. Is "gpsd -n /tmp/nmeaNP" necessary on the Freerunner? Is there another way? Why doesn't the init script work? Regards Jeff _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
The Freerunner has another GPS than the Neo1973. The device with the NMEA-output is /dev/ttySAC1 (only works after powering the GPS on). With 3 minutes investigating in google, the openmoko wiki, or this mailinglist, you could find the information by yourself... _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi, I have the same problem that my Freerunner can't acquire a fix without a external GPS antenna. Just today I stumbled upon a page on the openmoko wiki: http://wiki.openmoko.org/wiki/FreeRunner_GPS_antenna_repair_SOP Anybody tried this fix and can report whether this realy fixes the issue? Greetings Alexander _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
These look like warranty-destroying repairs if you do them yourself. Jeff _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
On Fri, 11 Jul 2008 13:50:40 +0200, Jeffrey Ratcliffe That is, if there was a warranty to destroy in the first place. -- Alexey Feldgendler <alexey@feldgendler.ru> [ICQ: 115226275] http://feldgendler.livejournal.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hello, FWIW, I took apart my FreeRunner and checked the GPS connector on the cable and the mainboard. It looked good to me. I didn't disassemble the GP board itself. -- Regards, Torfinn Ingolfsen _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I suppose so. My external GPS antenna with built-in amplifier (requires power on antenna connector) works just fine with my Freerunnner (but doesn't work with my Medion PNA, which apparently does not supply power to the antenna connector). HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--4jXrM3lyYWu4nBt5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Yesterday I tried GPS for the first time. With gpssight and tangogps I got a fix within minutes when holding the FR out of the window. The fix remained when moving around my home. Then I installed gpsdrive and did some other things I don't remember anymore. When trying with gpsdrive I could not get a fix. With gpssight and tangogps it wasn't working either. Today I tried outside with no result. I reflashed rootfs to rollback software and only installed gpssight and tango again. No fix. It never worked again so far. So the idea of a loose contact at the antenna sounds somewhat plausible. But I don't want to open the FR right now. The connector is visible right under the battery. I can move it with my fingernail a little, really not much. Don't know if it is loose... --4jXrM3lyYWu4nBt5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh3nwkACgkQS1FjE303ERz9igCfUKTfZmATChLfaL22yUYJakMc QRUAoIC0SIpph6x0mDiIPc9fzEu2B1Eg =2Cjy -----END PGP SIGNATURE----- --4jXrM3lyYWu4nBt5--
I'm not saying there isn't an antenna issue, but that we may be able to mitigate the effects on startup time. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi Al, If you need testers, please contact me. I have several gta02v5 available and can do tests in Germany Munich. thanks Kai _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
An interesting idea would be to acquire a fix, then bring the phone under cover, so it loses the fix, then bring it back in the open and see how long it will take to reacquire the fix. -- Sent from Gmail for mobile | mobile.google.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
=46irst stab uses the example perl functions from ublox for generating the= =20 aid-ini data, replacing their hardcoded x,y,z with values for my location.= =20 The copyright notice on the example code says you can't do anything with it= =20 without permission so I can't give you the script, but I can tell you how t= o=20 reproduce it ;-) Get the AssistNow online client application note from: http://people.openmoko.org/matt_hsu/ImplementationAssistNowServerAndClient(= GPS.G4-SW-05017-C).pdf Create a new script aid-ini.pl and start with: #!/usr/bin/perl print(clientdata_prepare()); Go to section B - Sample Server implementation and append subroutines=20 clientdata_prepare and ubx_checksum to aid-ini.pl You need to replace the $posx, $posy and $posz values in clientdata_prepare= =20 with some that match your location. These are ECEF coordinated in m. There'= s=20 an explanation of the calculation method in: http://www.u-blox.com/customersupport/docs/GPS.G1-X-00006.pdf Alternatively you can use the attached spreadsheet if it survives the list.= =20 Just replace the lat and lon with values for your location. You probably want to change the time accuracy to reflect the accuracy of th= e=20 =46reerunner clock, and possibly the accuracy of your location estimate. Now copy the script to somewhere suitable on the Freerunner and make it=20 executable. I'm using /usr/local/bin. You need to install perl if you don't= =20 have it already: opkg install perl Switch on the GPS then run the script: /usr/local/bin/aid-ini.pl > /dev/ttySAC1 If you cat /dev/ttySAC1 you should be able to see it using the current time= =20 according to your Freerunner. TangoGPS makes it easier to see what it's=20 doing. In the only test I've managed so far it got a fix with a poor view o= f=20 the sky, while my Garmin Geko was still struggling to see 3 sats. It wasn't= =20 quick, but it was better than the Garmin. It would be interesting if you=20 could try 2 units side by side, one ...
hi all, today i tried to get the gps running, but i didn't get a gps fix i tested it with tangogps (nice tool!) and openmoko-agpsui the only output i got was: $GPVTG,,,,,,,,,N*30 $GPGGA,,,,,,0,00,99.99,,,,,,*48 $GPGSA,A,1,,,,,,,,,,,,,99.99,99.99,99.99*30 $GPGSV,1,1,00*79 $GPGLL,,,,,,V,N*64 $GPZDA,,,,,00,00*48 $GPRMC,,V,,,,,,,,,,N*53 $GPVTG,,,,,,,,,N*30 $GPGGA,,,,,,0,00,99.99,,,,,,*48 $GPGSA,A, http://scap.linuxtogo.org/files/6d11990f0c82d92f0252742d7ef44950.png what do i do wrong? mathias -- Psssst! Schon das coole Video vom GMX MultiMessenger gesehen? Der Eine für Alle: http://www.gmx.net/de/go/messenger03 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
It seems nobody gets a quick fix. Times range from 10 to 60 minutes if any fix at all. There is a similar thread running on the developer list but no answers from Openmoko. Normal for a cold start would be 45secs-2min and with agps ~15secs. This is industry standard and stated on the specs page of u-blox. The GTA01 (Neo 1973) gets a fix in one minute after a cold start. All modern chips (and the u-blox is a modern chip) can get a fix without downloading the full almanac (which takes 12.5 minutes). The ephemeris is sufficient and comes in 30secs. I think this is an important issue and hope that Sean or Wolfgang can give answers. I CC'd Steve too, because this equally effects the VAR markets. If they don't answer it is probably the best to send your FR back before the warrenty expires and buy a new FR once this issue is resolved. Marcus _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Well, Sean is sick in bed from taking Malaria shots since he is traveling to Ghana to speak. I have been Busy at the wharehouse and Wolfgang is aware of your issue and we have folks on it trying to duplicate the issue and figure it out. Sean, for example, has had no issues in TPE, west coast USA, east coast USA, and columbia with his phone. So, after we duplicate the problem then we can figure the cause. Software, component failure, test leakage. On the inside of your phone there is a datecode, serial number etc. Email that to wolfgang Steve -----Original Message----- From: Marcus Bauer [mailto:marcus.bauer@gmail.com] Sent: Monday, July 07, 2008 10:05 AM To: List for Openmoko community discussion Cc: Sean Moss-Pultz; Wolfgang Spraul; steve Subject: Re: GPS It seems nobody gets a quick fix. Times range from 10 to 60 minutes if any fix at all. There is a similar thread running on the developer list but no answers from Openmoko. Normal for a cold start would be 45secs-2min and with agps ~15secs. This is industry standard and stated on the specs page of u-blox. The GTA01 (Neo 1973) gets a fix in one minute after a cold start. All modern chips (and the u-blox is a modern chip) can get a fix without downloading the full almanac (which takes 12.5 minutes). The ephemeris is sufficient and comes in 30secs. I think this is an important issue and hope that Sean or Wolfgang can give answers. I CC'd Steve too, because this equally effects the VAR markets. If they don't answer it is probably the best to send your FR back before the warrenty expires and buy a new FR once this issue is resolved. Marcus _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I'm in the san francisco bay area, and am seeing very slow GPS fixes. It took 5 minutes to get the time code from the satellite this morning (didn't get a fix in 12 minutes...), and I've only gotten a fix once so far (after > 10 minutes...), and it's failed to get a fix during a few ~10 minutes walks outdoors. I've been carrying the phone screen up, away from my body, away from buildings taller than a story or two... Anyway, if you still haven't duplicated the problem, let me know. Also, I'm getting a bit of GSM data noise on my speaker during phone calls. Is that normal, or is it unexpected signal leakage? I plan to retest GPS with the GSM (and all other radios) disabled. -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Be happy I have never got a fix up to now although trying on different locations for >45min each. I'll consider to use my waranty. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--=-g9c44D6shsPo4uVgfhyS Content-Type: multipart/alternative; boundary="=-/d71ceAb8P+O7P51GrqC" --=-/d71ceAb8P+O7P51GrqC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable probably this is related http://wiki.openmoko.org/wiki/FreeRunner_GPS_antenna_repair_SOP --=-/d71ceAb8P+O7P51GrqC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8"> <META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.18.2"> </HEAD> <BODY> On Fri, 2008-07-11 at 23:57 +0200, Bumbl wrote: <BLOCKQUOTE TYPE=3DCITE> <PRE> Be happy I have never got a fix up to now although trying on different locations=20 for &gt;45min each. I'll consider to use my waranty. </PRE> </BLOCKQUOTE> probably this is related<BR> <BR> <BR> </BODY> </HTML> --=-/d71ceAb8P+O7P51GrqC-- --=-g9c44D6shsPo4uVgfhyS Content-Type: application/x-pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: ...
This might help too (I should add myself to it...): http://wiki.openmoko.org/wiki/GPS_Problems I've only gotten a fix using the agps diagnostic tool gui. I did it in the middle of a clear night with nothing near by, by going to the signal strength screen, and slowly rotating the phone until the bars started turning from light blue to dark blue, and going with an orientation that seemed to work, kind of like with an old analog TV set... I don't know if doing it actually helped, but while playing this game, I got a fix in ~ 2-3 minutes, vs the tens of minutes I'd waited before that. Bumble, after 10-15 minutes of waiting, do you see any satellites in the "ss" tab of the agps diagnostic tool? Does it display a time in UTC after a few minutes? If so, we're probably in the same boat. Is there a document explaining the exact handshaking procedure the chipset in the freerunner uses to lock onto the satellites? -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I played with it a bit more and think i figured out why i wasn't getting locks quickly. It looks like my Freerunner's GPS is working after all! :) I've updated the wiki GPS_Problems page with some basic information about how GPS devices obtain initial locks, and added more troubleshooting information... It would have saved me a few hours; hopefully someone else will find it useful. Someone familiar with GPS should probably check it for errors. Most of what I wrote is based on things I learned today by word-of-mouth and skimming wikipedia articles. -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I've been playing with my GPS and finally got a fix using agps diag tool. I stood the gta02 up on my garden table using a pop bottle :-) I think bottom line the gta02 has a poor antenna.... in fact the first time I got a fix I did so at the point I rested my free stylus on top of the gta02! Once I had a fix I used the signal strength screen in the agps diag tool and its then plain to see the signal is precarious at best with an average strength of around 28 which is greatly affected by orientation and nearby objects from hands, stylus, people etc pretty much what you'd expect in a device thats receiving a very weak signal.... except we know the say system is working so that only leaves the gta02 internal antenna as the problem. Thoughts? Jon _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Does it make any difference to leave the gps running 15 minutes plus (probably a few multiples of 15 minutes is best) then power off for a few minutes and then back on? My freerunner isnt here yet, but my experience on a cheap bluetooth gps that I though just had occasional conniptions was actually operating according to design On the first fix (or a fix after a few weeks on the shelf powered off), it would take some time (once being over a day with poor signal) to get a fix, after which it would be fine getting a nearly instant fix on startup. Turns out the device needs information downloaded from a satellite and can take ~13 minutes to do so. And at least one article mentioned that any problem/lost/corrupted data caused it to start again at the next start point. So if you have a poor signal, something blocks it at a critical point, you can scratch that 15 minutes. As the freerunner has come straight from the factory, probably with none of this data, it will need at least 15 minutes with a good signal to get its data up to date. This data is also valid for 6 weeks which explains the erratic operation after extended periods of non-use of my bluetooth unit. Learnt a lot reading up on this :) A good thread! BillK -- William Kenworthy <billk@iinet.net.au> Home in Perth! _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Funny... my experience has been completely contrary to this. When I first tried GPS, it got a fix within minutes at the open window. I then installed gpsdrive and did some other stuff. I did not get a fix anymore. I undid the software changes by starting from a fresh reflash. But i never got a fix again. Today I tried outside 15min with antenna faced skywards. agpsui signal strength display did not show any activity. Don't know it made it work the very first time.=20 --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh4vzgACgkQS1FjE303ERxf9QCffczG81BU+dWIvTV9Pdo1XMqX gFEAnRDdTmBFc1VTWmulHsX5uDBK54se =7Njb -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU--
No. Every time you power off the GPS it loses the data from the sats. At present every start is a cold start. It is possible to save the data before shutdown and send it back after a restart, but AFAIK here is no app to do this on the Freerunner yet. I'm working on this, as an excuse to learn _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I found exactly the same thing, the unit has to be stationary for a while, you need to swizzle it around its vertical axis until you get the maximum signal strength, and then leave it for 10 mins to get a fix. It must not be touched or moved during that time. It is pretty impractical for a mobile device though to do that. Lets hope some of the techniques to preload data will help this. -- Jim Morris, http://blog.wolfman.com _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_34069_12073796.1215942625447 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there still hope this is not a hardware bug? ------=_Part_34069_12073796.1215942625447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there still hope this is not a hardware bug?<br><br><br><div class="gmail_quote">On Sat, Jul 12, 2008 at 10:59 PM, Jim Morris &lt;<a href="mailto:ml@e4net.com">ml@e4net.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">Jonathan Spooner wrote:<br> &gt; I&#39;ve been playing with my GPS and finally got a fix using agps diag<br> &gt; tool. I stood the gta02 up on my garden table using a pop bottle :-) &nbsp;I<br> &gt; think bottom line the gta02 has a poor antenna.... in fact the first<br> &gt; time I got a fix I did so at the point I rested my free stylus on top of<br> &gt; the gta02!<br> &gt;<br> &gt; Once I had a fix I used the signal strength screen in the agps diag tool<br> &gt; and its then plain to see the signal is precarious at best with an<br> &gt; average strength of around 28 which is greatly affected by orientation<br> &gt; and nearby objects from hands, stylus, people etc pretty much what you&#39;d<br> &gt; expect in a device thats receiving a very weak signal.... except we know<br> &gt; the say system is working so that only leaves the gta02 internal antenna<br> &gt; as the problem.<br> &gt;<br> &gt; Thoughts?<br> &gt;<br> &gt; Jon<br> &gt;<br> <br> </div>I found exactly the same thing, the unit has to be stationary for a while, you need to swizzle it<br> around its vertical axis until you get the maximum signal strength, and then leave it for 10 mins to<br> get a fix. It must not be touched or moved during that time.<br> <br> It is pretty impractical for a mobile device though to do ...
Yes, there is still hope. The current software drivers do not save any state between GPS locks, so the GPS device is needlessly re-downloading information from the satellites each time it turns on. Downloading the data seems to require a much better/more consistent signal than calculating the phone's current position. It sounds like a (partial?) fix is in the works. There were some links to scripts posted to this mailing list a few days ago, but they came with copyright restrictions that prevent redistribution... My phone sometimes takes 10 minutes to get a fix, but can track its current position from a car seat (not just near the window), and indoors in my pocket. It's good enough for in-car navigation, and for use as a speedometer, though with a couple of seconds delay added in. Also, I see a few meters of jitter when the device is not moving. After losing signal in a tunnel for 15-30 seconds, it restored its fix immediately after I left the tunnel. Not counting the time to get the initial lock, this behavior is better than what I've seen from some inexpensive name brand gps devices, suggesting the antenna is "good enough", assuming saving and restoring the chip's state works. -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Doesn't just seem to, it does need a better signal. And yeah, being able to restore that data and/or get it from the network should provide much quicker first fixes. From #openmoko: <DocCod> cold start: like 10 minutes for a fix <DocCod> agps data feeded immediately after start: fix in 1 minute or less <DocCod> between 2 tall buildings, btw Anyway, as for the GPS problems some are having, I got a fix relatively quickly on a phone another guy had problems with from the first Finnish group batch. The difference mostly that he used some of the frontends and I grepped the device node directly. So there might've been some software glitches at work with eg. gsmd getting confused at the chip output (which includes large amounts of those spurious error messages and stuff). (Of course, it _might_ have been a flaky but not consistently faulty connection too; we'll keep an eye on the device if it starts acting up again.) So anyone who's having GPS problems should probably make sure it's hardware by checking out the GPS chip output at the lowest level by doing something like: echo 1 > /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron grep GPGGA /dev/ttySAC1 And seeing if there'll be fix-looking data within, say, 10 minutes to be sure, on a decent exposure of the sky. (You can do that remotely in a screen session and then attach to it with "screen -dr" from the OpenMoko terminal to make it easier to type it in but still get the output from the Neo.) See http://wiki.openmoko.org/wiki/GPS on what a fix looks like. Hope this helps someone. -- Mikko Rauhala - mjr@iki.fi - <URL:http://www.iki.fi/mjr/> Transhumanist - WTA member - <URL:http://www.transhumanism.org/> Singularitarian - SIAI supporter - <URL:http://www.singinst.org/> _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I read about this idea in the wiki and posted a comment there. Here's what I wrote. I tested the FR outside with internal antenna and did not see a single sat for 15min. With external antenna I have a TTFS of 33s. If I plug out the external after the fix is stable, it almost instantly gets lost. I still see one to three sats but get no fix. =20 So apparently the information obtain through the external antenna is not enough to assist the internal antenna in getting a fix. Orbit and positon data should be known to the device by then? If you download this data from the internet or recalculate it locally, in what way would this be superior to what I tested? --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh5/GcACgkQS1FjE303ERzXngCfec8I3BxYdBYebVrT+HxyNYim Fn8An19qLKNluA4RUVSSYQgp9Ue3mI21 =cFxN -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--
there seems to be no use of the workarounds/fixes discussed earlier -- does anybody use the ubx-tool or whatever was discussed to feed informations to the u-blox on startup, thus significantly decreasing ttff? http://docs.openmoko.org/trac/browser/developers/alphaone/u-blox there were some pretty promising reports for those attempts (can't find them right now) -- and standing hours on a meadow in the faint hope of a fix does not really sound appealing to me ... _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3B22452A1FCEA8A3E405B137 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Feeding assist data to compensate bad hardware based reception is no=20 real solution, since there are some FRs, which seem not to have any=20 problems to get a fast fix at all. The basic reception has to be better=20 and I cannot rely on fresh assist data at any time I need a fix! It's a point of qualitiy management on the hardware producers side which = has to get solved. I'm not willing to disassemble the new hardware at my = own risk (warranty pp.). I know that I have bought an 'incomplete'=20 smarty regarding the OS and software. That was fine with me, but FIC=20 (as experienced hardware manufacturer) should do basic soldering jobs=20 successful on their products (If this gets verified to be the real=20 problem of this issue, of course). My only question is: Which time I have left to engage a warranty=20 procedure? I'll ask Trisoft this week. Greets --=20 BlueStar88 ________________________________________________________ PGPID: 0x36150C86 PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86 --------------enig3B22452A1FCEA8A3E405B137 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIejfh/GOJMzYVDIYRA68qAJoD5wai2qAWlLzfXECeKrVF1RGPsgCgwJl5 PH6Pxz71aQVWF5WT+9aQF6M= =2+8L -----END PGP SIGNATURE----- --------------enig3B22452A1FCEA8A3E405B137--
My personal current belief is that those FRs are generally no better than eg. yours or mine. It's simply a matter of software used and especially the place used (some countries have also better GPS coverage than others), plus whether one really has a table or so where the device can easily be mounted firmly. If you hold it in your hand, still otherwise, it might not be steady enough to get the fix (or does someone know otherwise, eg. what kind of movement might corrupt the received bits?). Or are there some people who get a fix while moving Neo around? Since the software has zero GPS data saving features etc., it's no wonder people easily think "it's broken". Especially, like in my case, if people don't have previous GPS usage experience or don't know how hard it's actually to "start from scratch" (scanning the whole sky) without any eg. estimate on current whereabouts or any other help. And also it doesn't help that if eg. people use AGPS UI which clears any received data every time it's started. One reason I believe it's not bad hardware reception is that when the fix is gotten, the fix stays better than on many "real" GPS hardware. Still, I've yet to experiment more on what would be best ways to get the initial fix. Even if feeded initial data, it seems relatively impossible to get the fix around my place. I'm not sure what could be improved still for the first fix, since after the fix is gotten it stays so well one would imagine the fix should also be possible to get in an (relatively) open area with a clear sky. -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_41736_4216111.1216024440276 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline This all are no arguments. With my TomTom device I can do a full reset so that no GPS data is available at all (also no time and so on) and still get a fix in < 3 minutes at 100 km/h. Well, I know the freerunner is no specialized gps navigation device, but the fact that the signals are so weak that it's barely possible to get a fix under optimal condition (clear view to the sky, antenna on top, without moving 1 mm) shows, that this is no simple software problem and has to be fixed. ------=_Part_41736_4216111.1216024440276 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div><span class="gmail_quote">On 7/14/08, <b class="gmail_sendername">Timo Jyrinki</b> &lt;<a href="mailto:timo.jyrinki@gmail.com">timo.jyrinki@gmail.com</a>&gt; wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">2008/7/13 BlueStar88 &lt;BlueStar88@xenobite.eu&gt;:<br>&gt; Feeding assist data to compensate bad hardware based reception is no real<br> &gt; solution, since there are some FRs, which seem not to have any problems to<br>&gt; get a fast fix at all.<br><br>My personal current belief is that those FRs are generally no better<br>than eg. yours or mine. It&#39;s simply a matter of software used and<br> especially the place used (some countries have also better GPS<br>coverage than others), plus whether one really has a table or so where<br>the device can easily be mounted firmly. If you hold it in your hand,<br>still otherwise, it might not be steady enough to get the fix (or does<br> someone know otherwise, eg. what kind of movement might corrupt the<br>received bits?). Or are there some people who get a fix while moving<br>Neo around?<br><br>Since the software has zero GPS data saving features etc., it&#39;s no<br> wonder people ...
In my past life I developed a fleet management device that had GPS and GSM in it, able to send the fix data to server in intervals. we even implemented some location alerts (around the vicinity of, or near customer..). Based on that experience, we used on of falcoms devices for it, it most probably did not have much of a cache for gps data (black box, tough to tell), but it needed a strong antenna for gps. For a GSM antenna you could use a hairpin, anything that had 10-15 cm of length was totally enough for good quality gsm connection. GPS required much more, in our case we supplied all the devices with external antennas. My knowledge is based solely on this work experience, I'm no radio-geek so I cant really tell much about antennas and signal catching. What kind of GPS-antenna is there in FR? Embedded for sure, but could that be the problem? I guess your TomTom comes with an external windshield antenna? -- Kalle. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_42782_23532206.1216040756393 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, Jul 14, 2008 at 10:45 AM, Kalle K=E4rkk=E4inen < No, it has no external antenna, only a window-mount with antenna connector but without one connected. That GSM works better is sure, because mobile GSM devices can receive at -110 dBm (usually ~ -70 to -90) while GPS chips receive at up to -160 dBm (usually between -130 and -150 at the antenna). I think the antenna in the freerunner is not that bad, it even has a preamp= . Ublox can receive at -158 dBm (according to the datasheet), what is pretty good (and definitely not worse than every good navigation device), and should get at least -130 dB (good enough for a cold boot fix) _after_ the antenna (preamplified) I guess. It even has it's own additional amp on chip= . So the problem is imho only bad build quality (QA) at least in some of the devices (might be a defect connector by 3rd party, don't know). Short version: antenna good (I bet it's better than the antennas in most other smartphones with GPS), chip very good -> bug. And btw. - SIRF Star III are damn good chips and used in many navigation devices and bluetooth gps devices, but the antaris is almost at the same level. It surely is no software issue, theoretically it could be a firmware issue of the u-blox, but I don't think it is. ------=_Part_42782_23532206.1216040756393 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Mon, Jul 14, 2008 at 10:45 AM, Kalle K=E4rkk=E4inen &lt;<a href=3D"mailt= o:kalle.karkkainen@intstream.fi">kalle.karkkainen@intstream.fi</a>&gt; wrot= e:&nbsp;<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style= =3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; p= adding-left: 1ex;"> In my past life I developed a fleet management device that had GPS and<br> GSM in it, ...
two small questions: 1) is there ANYBODY who has a freerunner with a "normal" functioning GPS? 2) We must presume openmoko tested the GPS before starting the mass production. The GPS of those devices must have worked, no? _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Ok, I don't claim my guess would be truth, I'm just guessing. Is it so that when the fix has been gotten, it stays and works properly even with (supposedly) very poor antenna like Neo's, even in places where zero signal was seemingly being got before the fix was had (elsewhere)? The main interesting thing for me was that the map updated completely fine inside a car and between tall buildings, after the fix was finally gotten. Is this really possible if the problem is broken / very poor antenna that cannot receive almost any signals? If such finely working GPS function is not possible in the case antenna is so poor that these fixes are so hard to get as it seems most of the time, then it would more likely be this is the case of this (random) internal/external switch problem instead of broken antenna otherwise. Or if not that, then some other possibly software based problem related to getting the fixes - again something in which I don't know enough about GPS since I don't know if the software is supposed to do something else besides telling the GPS chip to "get the fix, please". -Timo _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
again: its not a software issue. This chip should work out of the box. 39 s to fix with good antenna is possible on my dev board, without any agps or anything. A good GPS reciever like some properly build SIRF3 systems and others get a fix within 1 minute under "good conditions" (clear view to sky) cold boot no matter how you hold your device. (proved here several times) The openmoko does not get a fix in reliable time (<3 minutes). If you plug in a external antenna and keep it away from the device it works like with a good SIFR3 chip. So lets face it: IT IS NOT A As you can see if you search for the thread "GPS External antenna detect issue" it is a hardware issue. And there are a lot of people on this list having experienced with gps systems like me. Reading the manual of the chip you can see, that it should work out of the box without "software" support. 39 s is what this chip is able to. But of course not if the antenna system is broken. Some people expect it to be a combination of: * broken antenna switch * bad antenna _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
That sounds like a different problem than I have. People have reported many different failure modes: - Everything "works". The phone gets a reliable fix in ~5-15 minutes if you baby it enough. (This might be improved w/ better drivers...) - The software is somehow messed up, and there are never any fixes. (People report GPS breakage after installing some combination of the GPS packages...) Reflashing the phone does not seem to help(!) - Actual antenna troubles. (See message "GPS issue related to GPS antenna selector ?") TangoGPS problems: - TangoGPS says "no gps found". Run "opkg install gpsd". - The GPS device usually works, but sometimes tangoGPS sees zero satellites after > 5 minutes. If you to power down the GPS device, then power it back up, it starts seeing satellites. -Rusty _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE0B13CD6308ABCCE048684B4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The GPS-module talks NMEA to the serial. I'm no GPS-expert, but where=20 exactly should a 'driver' step in, to assist in basic technical procedure= Ignore the software, just look at the NMEA output! If you get a communication to the module established, all depends on the = facts coming from the NMEA output. There should be no=20 'misunderstandings' from any software involved. This poor (?) signal is just not enough, to get any fix: GPS UI 0.20 is used by me to do the diagnostics. Is there a cause not to = trust it, even by looking at the pure NMEA output of it? --=20 BlueStar88 ________________________________________________________ PGPID: 0x36150C86 PGPFP: E9AE 667C 4A2E 3F46 9B69 9BB2 FC63 8933 3615 0C86 --------------enigE0B13CD6308ABCCE048684B4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIezcB/GOJMzYVDIYRA94KAJ9lmpTDrIQYA8VhiSDaw0a/swA0yACfa8qT CPpfNvW5WSXeu0sQS5AFNGY= =W+kK -----END PGP SIGNATURE----- --------------enigE0B13CD6308ABCCE048684B4--
The module talks NMEA but also a ublox binary format. Among other things this allows time and location estimates, ephemeris and almanac data to be fed to the module to give it an initial state, and should reduce time to first fix. Likewise it can be used to request this data from the module so it can be _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
So we just need to wrap 'save' and 'restore' scripts around the gpsd script? ; -- Jay Vaughan _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_45635_4044216.1216052435010 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Basically yes, but this won't fix the problem. It's for later when the problem is fixed, so you wouldn't have to wait a minute for the fix but 10 seconds. ------=_Part_45635_4044216.1216052435010 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 4:23 PM, Jay Vaughan &lt;<a href="mailto:jayv@synth.net">jayv@synth.net</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">&gt; The module talks NMEA but also a ublox binary format. Among other<br> &gt; things this<br> &gt; allows time and location estimates, ephemeris and almanac data to be<br> &gt; fed to<br> &gt; the module to give it an initial state, and should reduce time to<br> &gt; first fix.<br> &gt; Likewise it can be used to request this data from the module so it<br> &gt; can be<br> &gt; saved before shutdown. &#39;Driver&#39; probably isn&#39;t the right word.<br> <br> <br> </div>So we just need to wrap &#39;save&#39; and &#39;restore&#39; scripts around the gpsd<br> script?</blockquote><div><br>Basically yes, but this won&#39;t fix the problem. It&#39;s for later when the problem is fixed, so you wouldn&#39;t have to wait a minute for the fix but 10 seconds. <br></div></div><br> ------=_Part_45635_4044216.1216052435010--
what exactly is the gpsd for, anyway? looking at my fr yesterday i noticed it is not installed anymore, if it ever was, that is, (and not available in the official feeds i got in my opkg-config). with agpsui i got one fix once, putting the fr in my bag and cycling home -- after 2/3 in a park i looked and it got a fix and ttff 1400. it was the only time i got one, so i wonder if the gpsd may somehow be involved ... _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
gpsd is there so that more than one program can access the GPS device at the same time, making it available over a network interface. Some apps can access GPS data via gpsd but not directly from the device. I think tangogps is among them. Gypsy does something similar but shares it using dbus, and claims to be more efficient. FSO will apparently be using gypsy instead of gpsd, but currently more apps can connect to gpsd than gypsy. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_46331_10683066.1216055197451 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Afaik gpsd is only used to make the NMEA data more accessible without having every app to parse it and some other minor things that makes handling easier. ------=_Part_46331_10683066.1216055197451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <br><br><div class="gmail_quote">On Mon, Jul 14, 2008 at 6:42 PM, arne anka &lt;<a href="mailto:openmoko@ginguppin.de">openmoko@ginguppin.de</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">&gt;&gt; So we just need to wrap &#39;save&#39; and &#39;restore&#39; scripts around the gpsd<br> &gt;&gt; script?<br> &gt;<br> &gt;<br> &gt; Basically yes, but this won&#39;t fix the problem. It&#39;s for later when the<br> <br> </div>what exactly is the gpsd for, anyway?<br> looking at my fr yesterday i noticed it is not installed anymore, if it<br> ever was, that is, (and not available in the official feeds i got in my<br> opkg-config).<br> <br> with agpsui i got one fix once, putting the fr in my bag and cycling home<br> -- after 2/3 in a park i looked and it got a fix and ttff 1400.<br> it was the only time i got one, so i wonder if the gpsd may somehow be<br> involved ...</blockquote><div><br>Afaik gpsd is only used to make the NMEA data more accessible without having every app to parse it and some other minor things that makes handling easier.<br></div></div><br> ------=_Part_46331_10683066.1216055197451--
This will be my 3rd GPS device in ~5 years. The first two - a NAVMAN from New Zealand and a Garmin - always had exceedingly long cold starts (i.e. turn the device off, fly >1500 km, turn device on), on the order of 10 minutes. I still have the Garmin in working condition, it is the Garmin 10, a bluetooth model. If some one could help me with the FR bluetooth, and the GSP applications, I could connect to FR "gps" stack to the Garmin to isolate them from the on board chip. This would, of course. assume that the bluetooth stack didn't cloud any issue. Thoughts, how-tos? Chris _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
A refinement on the thought below - how to pipe the NMEA data to a bluetooth serial port so I can connect my Palm TX and run its mapping off the FR GPS chip data. If anyone could provide pointers on setting up bluetooth serial connections to/from the FR I'd appreciate it. Thanks, Chris _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
http://wiki.openmoko.org/wiki/GPS#GTA02 _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Thanks for this, I also found how to go the other direction on the wiki. Right now I have the AGPS application reading data from the Garmin. Three minutes have passed and no fix yet. Will try Tango and then reverse the scenario for the Palm TX. L8r, Chris _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--nextPart8715365.kB4GG9RAoU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Antenna is pointing front longaxis. You have to hold device upright (lanyard hole to ground, AUX-key to sky)! /jOERG --nextPart8715365.kB4GG9RAoU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBIejl+7Xtwhpk1UgwRAvsYAJ9oOafjm4QMWnsMp73bzvPIqz48ngCeIZ47 mbfjQtsdLjn8I9fgErdpdqk= =R/MH -----END PGP SIGNATURE----- --nextPart8715365.kB4GG9RAoU--
On Mon, 7 Jul 2008 15:37:08 +0100 Al Johnson <openmoko@mazikeen.demon.co.uk> wrote: Thank you for the testing. Keep doing the good work. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Another thing that might help: If the FR is connected to any network one should also be able to use IP Locator services like http://whatismyipaddress.com/ to get another extimation of the location of FR. They are usually quite accurate. Would this help? _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How accurate does the AGPS prefix need to be to be useful? - the above locator is ~20-25km out for me (In Perth, Western Australia) using a public IP. BillK _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Another data point. I dont have my FR yet, but looking at this thread got me to fire up an external bluetooth BT74R GPS and connect it to my treo650 using cetus gps to display a satellite map. the GPS is on a SE facing windowsill with one floor above me so everything behind the building will be cut off. This system will usually, but not always get a fix within seconds. Today (and I have seen this before), it cant get a fix. All the strongest satellites in view are aligned east-west. From experience, once the satellites move so they are "spread" across the sky, a fix will happen - and once obtained will stay fixed. Just need to get that first lock! Does the freerunner have software that can show how the satellites position overhead? - satellite location will certainly cause a lot of variability - I would think the only worthwhile measurements on how the FR performs will be comparative (with another, known performer placed alongside) rather than absolute. Billk _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
You might could try following ipkg for GPS testing http://people.openmoko.org/tony_tu/GTA02/util/gps/openmoko-agpsui_0.1+svnr7-r0_armv4t.ipk just using opkg install to install program. And reference the http://wiki.openmoko.org/wiki/GTA02_GPS page for source code information. Thanks, Tony Tu _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Im actually having some trouble installing that, it says: / root@om-gta02:/usr/bin# opkg install http://people.openmoko.org/tony_tu/GTA02/util/gps/openmoko-agpsui_0.1+svnr7-r0_armv4t.ipk Downloading http://people.openmoko.org/tony_tu/GTA02/util/gps/openmoko-agpsui_0.1+svnr7-r0_armv4t.ipk Multiple packages (openmoko-agpsui and openmoko-agpsui) providing same name marked HOLD or PREFER. Using latest. Installing openmoko-agpsui (0.1+svnr7-r0) to root... Collected errors: * Package openmoko-agpsui md5sum mismatch. Either the opkg or the package index are corrupt. Try 'opkg update'. root@om-gta02:/usr/bin# Not entirely sure what to do as im no linux expert :) / _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi flexed- Could you scp this ipk into GTA02, and try install from GTA02? Tony Tu _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
simply do opkg install openmoko-agpsui as it seems to be in the repositories. And although being the same version it has a different md5sum, that's why opkg complains. Marcus _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
for me it was accurate within the 4 km range, but i live in Milan and this could easily make a big difference :) _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
It's just initialisation data. More accurate will probably be better, but 20km
of doesn't sound that bad. It sure is *way* better than not even knowing
which hemisphere you're in.
Actually it think just knowing which country your in will make a big
difference allready. We could consider devising a list of country/location
data, assuming we can get country information from the GSM network (or the
SIM card perhaps?). Just adding this to the GPS initialisation might allready
reduce the time needed to get a fix hugely.
AVee
--
AMAZING BUT TRUE ...
If all the salmon caught in Canada in one year were laid end to end
across the Sahara Desert, the smell would be absolutely awful.
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
I'm not sure what capacity there is to connect via VPNs, but they could make a device appear to be in a different hemisphere. mj _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Gets my location wrong by 100 miles or so. Other GeoIP services put me in other locations similar distances away. The BBC has had complaints from people reported as being in a different country because it blocks them from using the download service. Perhaps this only affects a minority, so it's another option to add to the list. If we have multiple sources we can see if they agree. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How accurate does this position information have to be? With my own telephone numer, i could at least find out in which country i am. Not so good for america, russia and brazil. But in smaller countries, you culd get a ±500km position. -- Drucken Sie diese Mail bitte nur auf Recyclingpapier aus. Please print this mail only on recycled paper. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
What i did with my phone (using the script stuff Al posted), i took my position from google maps, simply by finding my home, centering it, and making a link. In the link you can see the coordinates and use the spreadsheet attached to his mail to calculate the right x,y,z. This works very well, i've been able to get a fix easy now. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Could you do a step-by-step guide for how to do this, and put it on the web somewhere? I think it would be easy to go from your guide to an automatic web-page/script that makes it easier for people to do this optimization themselves .. ; -- Jay Vaughan _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Basically, follow this: http://www.mmenterprises.co.uk/blog/2007/07/how-to-find-gps-coodinates-from-google.htm That gives you the numbers you need to put into his spreadsheet :) _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
It would be very easy to take the formulae from the spreadsheet in javascript.
Alternatively you can use it directly in the script if you glue in the calcs
in perl to calculate $posx, $posy and $posz as below. Variable $posacc is the
estimated accuracy of the supplied location in m.
## WGS84 constants
my $a;
my $b;
my $lat; # latitude
my $lon; # longitude
my $h; # height above ellipsiod (m)
my $e; # first eccentricity
my $N; # Radius of curvature (m)
## set lat & lon in degrees
$lat = 47.3;
$lon = 8.5;
## convert to radians for sin / cos to work with
$lat = deg_to_rads($lat);
$lon = deg_to_rads($lon);
$h = 0.0;
$posacc = 150000.0;
# define WGS84 constants
$a = 6378137.0;
$b = 6356752.31424518;
# calc intermediate parameters
$e = sqrt(($a**2 - $b**2)/$a**2);
$N = $a / sqrt(1 - ($e**2 * (sin($lat))**2));
$posx = ($N + $h) * cos($lat) * cos($lon);
$posy = ($N + $h) * cos($lat) * sin($lon);
$posz = ((($b**2 / $a**2) * $N) + $h) * sin($lat);
The whole thing needs reimplementing in a redistributable form. I'll be using
it as an excuse to learn python :-) It may take a while since the beer
festival's on for the rest of the week. If anyone else wants to do something
with it I've added links to the various useful resources to the wiki
http://wiki.openmoko.org/wiki/GTA02_GPS
_______________________________________________
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Someone has already done this: http://www.oc.nps.edu/oc2902w/coord/llhxyz.htm _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
--Boundary-00=_tEGdIwD4SUAQA/r Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, we (until now 4 people) started at docs.google.com (where multiple people c= an=20 edit the same document) a german (until now quick & dirty) getting started= =20 document. This document is not meant to be a copy of =A0 http://quickstart.openmoko.org/ and does not want to compete with the offic= ial=20 Wiki. Far from it! It can be used to make remarks and notes while playing=20 around with the freerunner without to care about the sentence structure and= =20 100% accuracy. From time to time the content should get higher quality and = be=20 =A0 transeferred to the wiki (in german and english), this can be done by anybo= dy=20 (even without FR for example while waiting for it ;-) ), because the docume= nt=20 is public on =A0http://docs.google.com/View?docid=3Ddnjszzj_0dzkbrncr and w= ill be=20 updated automatically. If someone wants to =A0edit the document and help us just write me a short = mail simarillion@gmx.de and I'll invite you. I think this Dokument helps to speed up the wiki (new pages as well as=20 untranslated to german) and will become a good and printable getting starte= d=20 for new FR owners who perhaps can't speak english. All the best Michael --Boundary-00=_tEGdIwD4SUAQA/r Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: ...
If you've got the time, could you retest this using a location some 500km from your real location? It should be interesting to see whether that will still get you a fix reasonably fast. If it does having a very rough idea of where you are is good enough to get a fast fix and we could start thinking of a more generic solution. AVee -- I always finish what I... _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Hi, thanks for your work, but it didn't work for me. I used your spreadsheet to calculate the values. Is there something I can do wrong? It sets the time, but I still don't get a fix. $posx = 3784209.3; $posy = 901525.8; $posz = 5037577.6; Are my values for Berlin/Germany (52.516667, 13.416667, h left 0) Strange thing is, it works great with an external antenna. I usually get a fix in less than 40 seconds, the freerunner even stays connected to those satellites when I unplug the antenna and holds the fix as long as it sees some sky. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Looks about right. You should see the current time appearing in GPRMC and GPZDA messages immediately after sending the data to the GPS if it has accepted it. I don't know whether it makes any difference or not. I was lucky the first time I tested it; subsequent tests have been slower, but I don't think it's taken longer than 10 minutes to get a fix. I don't have 2 to test side by side so I can't really judge whether it's improving things or not. At least it shouldn't make things any worse! I've found alphaone's ruby scripts for saving and setting the almanac and ephemeris data, and added a link to the wiki. I've installed ruby via opkg, but can't find rubygems which it seems to need. First time I've looked at Once I get a fix it keeps it very well, certainly better than my Garmin. Given the variation I'm guessing it needs a more reliable signal at startup than subsequently, and that it's borderline with the built in antenna. I guess sample to sample variation may mean some people will get a fix reasonably _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
------=_Part_22013_24995331.1215467247293 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also did some testing with all the pieces of hardware the freerunner has. The GPS is very disappointing. I could get a fix in about 2 minutes with my Neo1973 with a cold start. This works inside my car (maybe a bit slower), at my room's window (bit slower), and everywhere outside. I still didn't manage to get a FIX with my Freerunner. I tried it at my window (nothing at all), in my car (nothing at all), outside my window (first coordinates after 15 minutes, no FIX at all), and on top of a hill with sunshine and no clouds (first coordinates after 5 minutes, no FIX at all). After that tests I don't think that my Neo will be able to get a FIX ever. At least it's totally unusable as any kind of GPS- or Navigation-device. Getting coordinates from my CellID-database is barely less accurate, but it goes in no time and everywhere. Btw. - I took a picture of my GPS_antenna, and I just can't imagine, that this will be able to get a GPS signal without siginficant loss to the reciever (that has only a sensitivity of -155 dBm in the best case). http://c.imagehost.org/0230/gps_antenna.jpg ------=_Part_22013_24995331.1215467247293 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I also did some testing with all the pieces of hardware the freerunner has.<br>The GPS is very disappointing. I could get a fix in about 2 minutes with my Neo1973 with a cold start.<br>This works inside my car (maybe a bit slower), at my room&#39;s window (bit slower), and everywhere outside.<br> <br>I still didn&#39;t manage to get a FIX with my Freerunner. I tried it at my window (nothing at all), in my car (nothing at all), outside my window (first coordinates after 15 minutes, no FIX at all), and on top of a hill with sunshine and no clouds (first coordinates after 5 minutes, no FIX at all).<br> <br>After ...
--nextPart3387530.66MXpu37MB Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Please can you elaborate on this? What's wrong with the backside/amplifier of the antenna? Do you have any examples an antenna should look like? please see: http://lists.openmoko.org/pipermail/hardware/attachments/20080507/9a64aa3c/GPSPhonePer... cheers jOERG --nextPart3387530.66MXpu37MB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQBIcqgv7Xtwhpk1UgwRAjXJAJ9SP/3PFpJBDjHc1Wez2scmAN5dfACfYBd/ S4yAbVLmjUQWWemGoqd3TSI= =iQce -----END PGP SIGNATURE----- --nextPart3387530.66MXpu37MB--
