[omgps] important updates
meng.qingyou at gmail.com
Thu May 28 16:19:28 CEST 2009
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.
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
[m/s]: 50, Sanity check type: Altitude and Velocity, Max Position Deviation:
Used in timing applications (antenna must be stationary) or other stationary
Velocity is constrained to 0 m/s. Zero dynamics assumed. MAX Altitude [m]:
Velocity [m/s]: 10, MAX Vertical Velocity [m/s]: 6, Sanity check type:
Altitude and Velocity,
Max Position Deviation: Small
Applications with low accelerations and low speed, as a pedestrian would
low accelerations. MAX Altitude [m]: 9000, MAX Velocity [m/s]: 30, MAX
[m/s]: 20, Sanity check type: Altitude and Velocity, Max Position Deviation:
Used for applications that can be compared with the dynamics of a passenger
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
Recommended for applications at sea, with zero vertical velocity. Assuming
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
Used for applications that have to handle a higher dynamic range than a car
vertical accelerations. No 2D position fixes supported. MAX Altitude [m]:
Velocity [m/s]: 100, MAX Vertical Velocity [m/s]: 100, Sanity check type:
Position Deviation: Large
Recommended for typical airborne environment. No 2D position fixes
Altitude [m]: 50000, MAX Velocity [m/s]: 250, MAX Vertical Velocity [m/s]:
check type: Altitude, Max Position Deviation: Large
Only recommended for an extreme dynamic environment. No 2D position fixes
MAX Altitude [m]: 50000, MAX Velocity [m/s]: 500, MAX Vertical Velocity
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?
> 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
>> 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
>> 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
>> 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 <meng.qingyou at gmail.com> wrote:
>> >> >
>> >> > Although there is a thread about omgps, I think I'd list the
>> >> 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.
>> > better than the 1/3, would be to offset the cursor so that 2/3 (or
>> > of the screen is "ahead", and only a small amount is behind (none of
>> > 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
>> > 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 at lists.openmoko.org
>> > http://lists.openmoko.org/mailman/listinfo/community
> William Kenworthy <billk at iinet.net.au>
> Home in Perth!
> Openmoko community mailing list
> community at lists.openmoko.org
View this message in context: http://n2.nabble.com/-omgps--important-updates-tp2977563p2987919.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
More information about the community