[omgps] important updates

[mqy]

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]:
50000, 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]: 50000, 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]: 50000, 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 <meng.qingyou at gmail.com> 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 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
> http://lists.openmoko.org/mailman/listinfo/community
> 
> 

-- 
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.