Re: [Freerunner] Access GPS chip's parameters and navigational models?
Olivier Migeot wrote: Hi ev'ryone, I'm currently experimenting things with the Antaris chip, and I'm starting to like it - at least through FSO and it's gpsd compatibility layer. I've been browsing through the UBX protocol specification, and I stumbled upon one interesting parameter : the dynamic platform model of the navigational unit. Simply put : using this, we should be able to explain our chip that we are either by car or by foot, and get more serious tracklogs (providing this is doable, 'cause the doc states (SW Versions 3.04 and higher), so I'm not sure whether or not we qualify). I did some quick tests, using my work phone as a reference (an HTC Trinity with a Sirf chip) : when logging car trips, both tracks are pretty close. Like a few meters. Far better than what I expected, at least. But when logging pedestrian trips (and I do quite a few), the Antaris starts to behave like ... a car. Every steep turn I took is throughly rounded on the Neo-based log. So I guess the current setting of our chip is car. So I wonder : does anyone here know whether we got version 3.04 or higher of the software? I see the opposite. My SiRF unit rounds a lot, and may decide to cut out a walk around the house completely. But I can walk the Antaris around a 4mx4m square and record a square with nice sharp corners. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
Am Mittwoch, 14. Januar 2009 18:18:26 schrieb Olivier Migeot: Hi ev'ryone, I'm currently experimenting things with the Antaris chip, and I'm starting to like it - at least through FSO and it's gpsd compatibility layer. I've been browsing through the UBX protocol specification, and I stumbled upon one interesting parameter : the dynamic platform model of the navigational unit. Simply put : using this, we should be able to explain our chip that we are either by car or by foot, and get more serious tracklogs (providing this is doable, 'cause the doc states (SW Versions 3.04 and higher), so I'm not sure whether or not we qualify). I did some quick tests, using my work phone as a reference (an HTC Trinity with a Sirf chip) : when logging car trips, both tracks are pretty close. Like a few meters. Far better than what I expected, at least. But when logging pedestrian trips (and I do quite a few), the Antaris starts to behave like ... a car. Every steep turn I took is throughly rounded on the Neo-based log. So I guess the current setting of our chip is car. So I wonder : does anyone here know whether we got version 3.04 or higher of the software? Hoping that we do (well, ignoring that maybe we don't, actually), I tried to feed the setting to the chip. The CFG-NAV2 UBX message that does that is 40 bytes long, and contains lt of more or less related information, which I certainly don't know how to feed. So I tried to first _get_ the setting, and re-set it verbatim (give or take the said parameter). But though there is a tool to generate UBX messages (ubxgen.py, on http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS ), I can't find a (successful) way to get the result from the chip. From my view, I should cat the commands to ttySAC1 and then read it. But I get nothing exciting that way... Hi, I looked up the 40 bytes long code with the u-center 5.06 tool with all default values except the dynamic platform model (it's the 5th byte). 01 stationary 02 pedestrian 03 automotive 04 sea 05 - 07 airborne And then generated a binary code: FR$ ubxgen.py 06 1A 28 00 03 00 00 00 03 04 10 02 50 C3 00 00 18 14 05 3C 00 03 00 00 FA 00 FA 00 64 00 2C 01 00 00 00 00 00 00 00 00 00 00 00 00 6B 6D CFG-NAV2-SET-AUTOMOTIVE.ubx and FR$ ubxgen.py 06 1A 28 00 02 00 00 00 03 04 10 02 50 C3 00 00 18 14 05 3C 00 03 00 00 FA 00 FA 00 64 00 2C 01 00 00 00 00 00 00 00 00 00 00 00 00 6B 6D CFG-NAV2-SET-PEDESTRIAN.ubx then set it with cat CFG-NAV2-SET-PEDESTRIAN.ubx /dev/ttySAC1 I've got also the problem that there is no feedback it's set on the chip. Now I will test if there is a difference in gps tracks between this to options. I guess I should shut down FSO's GPS handling first, but how? Is stopping fso-gpsd enough? (I tried, but it didn't seem better) Any insights, somebody? Thanks. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
If you're already working on FSO, you might consider enhancing our dbus interface to support different navigational models. You'll find that extending our UBX parser helps us more than using ubxgen ;) Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Freerunner] Access GPS chip's parameters and navigational models?
Hi ev'ryone, I'm currently experimenting things with the Antaris chip, and I'm starting to like it - at least through FSO and it's gpsd compatibility layer. I've been browsing through the UBX protocol specification, and I stumbled upon one interesting parameter : the dynamic platform model of the navigational unit. Simply put : using this, we should be able to explain our chip that we are either by car or by foot, and get more serious tracklogs (providing this is doable, 'cause the doc states (SW Versions 3.04 and higher), so I'm not sure whether or not we qualify). I did some quick tests, using my work phone as a reference (an HTC Trinity with a Sirf chip) : when logging car trips, both tracks are pretty close. Like a few meters. Far better than what I expected, at least. But when logging pedestrian trips (and I do quite a few), the Antaris starts to behave like ... a car. Every steep turn I took is throughly rounded on the Neo-based log. So I guess the current setting of our chip is car. So I wonder : does anyone here know whether we got version 3.04 or higher of the software? Hoping that we do (well, ignoring that maybe we don't, actually), I tried to feed the setting to the chip. The CFG-NAV2 UBX message that does that is 40 bytes long, and contains lt of more or less related information, which I certainly don't know how to feed. So I tried to first _get_ the setting, and re-set it verbatim (give or take the said parameter). But though there is a tool to generate UBX messages (ubxgen.py, on http://wiki.openmoko.org/wiki/Neo_FreeRunner_GPS ), I can't find a (successful) way to get the result from the chip. From my view, I should cat the commands to ttySAC1 and then read it. But I get nothing exciting that way... I guess I should shut down FSO's GPS handling first, but how? Is stopping fso-gpsd enough? (I tried, but it didn't seem better) Any insights, somebody? Thanks. -- Olivier ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
On Wednesday 14 January 2009, Olivier Migeot wrote: I guess I should shut down FSO's GPS handling first, but how? Is stopping fso-gpsd enough? (I tried, but it didn't seem better) Any insights, somebody? Thanks. Disable ogpsd in /etc/frameworkd.conf by adding 'disable = 1' to the [ogpsd] section, then restart frameworkd nicely: /etc/init.d/xserver-nodm stop /etc/init.s/fso-gpsd stop /etc/init.d/frameworkd restart /etc/init.d/xserver-nodm start You might like to take the fso-gpsd startup link out of /etc/rc5.d too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
On Wed, Jan 14, 2009 at 7:08 PM, Al Johnson openm...@mazikeen.demon.co.uk wrote: Disable ogpsd in /etc/frameworkd.conf by adding 'disable = 1' to the [ogpsd] section, then restart frameworkd nicely: Whoa, that was quick, thank you. That'll be ok for some testing, but I sure wouldn't want to do that everytime I need to switch navigational models ;) -- Olivier ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
On Wednesday 14 January 2009, Olivier Migeot wrote: On Wed, Jan 14, 2009 at 7:08 PM, Al Johnson openm...@mazikeen.demon.co.uk wrote: Disable ogpsd in /etc/frameworkd.conf by adding 'disable = 1' to the [ogpsd] section, then restart frameworkd nicely: Whoa, that was quick, thank you. That'll be ok for some testing, but I sure wouldn't want to do that everytime I need to switch navigational models ;) You could always patch ogpsd to accept a dbus command for changing navigational models ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
Al Johnson openm...@mazikeen.demon.co.uk writes: /etc/init.d/xserver-nodm stop Hmm, why is stopping X server necessary? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
On Wednesday 14 January 2009, Timo Juhani Lindfors wrote: Al Johnson openm...@mazikeen.demon.co.uk writes: /etc/init.d/xserver-nodm stop Hmm, why is stopping X server necessary? Apps using frameworkd can get upset if you restart frameworkd while they are running. This would include zhone, and possibly some illume bits (battery monitor maybe?) This is a relatively clean and easy way to get frameworkd restarted without problems, but isn't strictly necessary. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Freerunner] Access GPS chip's parameters and navigational models?
because the qtopia indexing stops with it ... Its probably possible to just stop the app doing the indexing (mediaserver I think), but I am not sure if it would create problems to knock out a low level part of qtopia or not. An alternative is to change the config so on the next boot, it wont index the SD card at all (best fix in fact) Billk On Wed, 2009-01-14 at 21:46 +0200, Timo Juhani Lindfors wrote: Al Johnson openm...@mazikeen.demon.co.uk writes: /etc/init.d/xserver-nodm stop Hmm, why is stopping X server necessary? ___ 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
