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.qing...@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@lists.openmoko.org >> > http://lists.openmoko.org/mailman/listinfo/community >> > >> > >> > -- > William Kenworthy <bi...@iinet.net.au> > Home in Perth! > > > _______________________________________________ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/-omgps--important-updates-tp2977563p2987919.html Sent from the Openmoko Community mailing list archive at Nabble.com. _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community