problem with GPS api
Trapulo
on win mobile 5.
It seems working (it collects data every one second), but data are not
"fluid" or "regular": they change with a "zig-zag", and don't draw a line.
It seems that my application bad receives updated data. Is there someone
using GPS from .NET in this scenario with similar problem? Any idea?
Gps precision and diluition of measure are very well (from 1 to 3), and I
work with 6-9 satellites used in solutions.
If I use same receiver with a third-parts software that is not .NET, it
collects very good data (without post-process them, only recording points),
so I think there is some problem with .NET or gps api. I'm using the sample
provided with .NET mobile SDK.
thanks
Peter Foot [MVP]
navigation applications snap to the nearest road in their maps which can
help to smooth out a trace.
Peter
--
Peter Foot
Windows Embedded MVP
www.peterfoot.net | www.inthehand.com
"Trapulo" <tra...@noemail.noemail> wrote in message
news:OpTgq0TE...@TK2MSFTNGP11.phx.gbl...
DickGrier
receiver (depending on mode used thig might be +- 15 to 20 m).
Are you certain that the other product(s) is/are not doing some sort of
filtering -- perhaps simply reducing the precision that they use to display
any single point?
--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition, ISBN 1-890422-28-2, Mabry Publishing (391 pages, includes CD-ROM).
July 2004.
See www.hardandsoftware.net for details and contact information.
Trapulo
news:O3KNDHWE...@TK2MSFTNGP10.phx.gbl...
> How much deviation (zigzag) are you seeing? Is it within the norm for a
> GPS receiver (depending on mode used thig might be +- 15 to 20 m).
I think this isn't my problem. I have an error about 20-30 mt, but I can use
same receiver with other nmea parsers (not navigation programs: I am only
recording points and loading them in to google earth) and I have very good
results.
It seems that gps api report an update only in longitude or latitude, but
not both. So I read a good point (very good), but next point has, for
example, right latitude and the longitude of the previous. Then, I read an
other point that semms ok, and a next one that has rigth latitude and
longitude of the previous.
> Are you certain that the other product(s) is/are not doing some sort of
> filtering -- perhaps simply reducing the precision that they use to
> display any single point?
I'm recording data with 13 decimal digits, the other product 6. I thinked
also that this can "correct" the result, so I rounded my data to 6 decimals
also, but it is the same.
It seems that I cannot read in realtime position updates.
I'm trying to record data when the event occurs, and also I've tried to run
a tried that polls position every 1 second, but results are same. This is
strange, because I hope that GPS api has not some bug in parsing nmea data..
Thank you for your help
Trapulo
"Peter Foot [MVP]" <feed...@nospam-inthehand.com> wrote in message
news:%23JYZJHU...@TK2MSFTNGP09.phx.gbl...
> What is the third-party software you are comparing against. For example
> most navigation applications snap to the nearest road in their maps which
> can help to smooth out a trace.
Thank you for your suggestion (I have same doubt), but I'm using a program
(Phone 2G Earth)that doesn't have any map or streets data, but can only
track points and export them as klm file (to import in google earth). So the
problem is in detecting position (please check also my reply to DickGrier).
Thanks
DickGrier
Try it with DecodeGPS from my homepage and report back to me. I don't have
any CF 2 devices that have a serial port or built-in GPS, so I haven't use
the GPS API (also, I prefer my own methods).
Dick
Trapulo
I'm trying your library, but I have some problem deploying it on win 5. When
I solve it, I'll report.
However I'm working with a BT device: GPS API works with all gps devices.
They manage serial flow, and NMEA data to make position information
available to applications.
Thank you
DickGrier
chance to explore it.
John Spaith [MS]
as the positions that GPSID is returning at the same time. You can get at
the NMEA by just doing a CreateFile("Whatever mux port is",...);
ReadFile();" as laid out in the docs.
There was a bug in NMEA parsing where degrees/minutes <-> decimal logic was
incorrect. My understanding was that this had been fixed before any devices
actually shipped (though it may still impact the device emulator ??).
Thanks.
--
John Spaith
Software Design Engineer, Windows CE
Microsoft Corporation
Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2003 Microsoft Corporation. All rights
reserved.
"DickGrier" <dick_grierNOSPAM@.msn.com> wrote in message
news:%23Nfgs2k...@TK2MSFTNGP10.phx.gbl...
Trapulo
I answer to your post:
1 - I'm using a Dell Axim x51v with italian OS. The OS build is 14366.1.01.
I don't know if this can help you to know if I have a bug in OS.
2 - I cannot find useful sample to read from gps the nmea flow (and I'm
using vb.net). However, I've used the library provided from
www.geoframeworks.com that reads nmea data and parse it (and has a sample
that I can easy read raw data with), and I've this result:
position returned by gps api to my program:
lat 45,6933333333333
lon 9,77333333333333
raw data recorded by geoframework's at same time:
$GPGGA,171033.782,4541.6142,N,00946.4068,E,1,04,21.8,246.1,M,46.0,M,,*6E
$GPGSA,A,2,01,03,14,22,,,,,,,,,22.4,21.8,5.2*3C
$GPGSV,2,1,08,1,44,128,44,3,20,160,45,11,64,298,,14,41,071,44*78
$GPGSV,2,2,08,19,58,176,,20,30,310,,22,15,053,45,28,20,296,*71
$GPRMC,171033.782,A,4541.6142,N,00946.4068,E,0.00,128.66,070106,,,A*6B
$GPVTG,128.66,T,,,0.00,N,0.00,K,A*7B
$GPGGA,171034.782,4541.6142,N,00946.4069,E,1,04,21.8,246.1,M,46.0,M,,*68
$GPRMC,171034.782,A,4541.6142,N,00946.4069,E,0.00,128.66,070106,,,A*6D
$GPVTG,128.66,T,,,0.00,N,0.00,K,A*7B
$GPGGA,171114.773,4541.6176,N,00946.3919,E,1,05,03.2,246.1,M,46.0,M,,*60
$GPRMC,171114.773,A,4541.6176,N,00946.3919,E,0.00,286.59,070106,,,A*65
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
$GPGGA,171115.773,4541.6177,N,00946.3915,E,1,05,03.2,246.1,M,46.0,M,,*6C
$GPGSA,A,3,01,03,14,19,22,,,,,,,,4.0,3.2,2.3*39
$GPGSV,2,1,08,1,44,127,47,3,20,160,44,11,64,298,,14,41,071,44*75
$GPGSV,2,2,08,19,58,176,39,20,31,310,,22,15,053,44,28,20,296,*7B
$GPRMC,171115.773,A,4541.6177,N,00946.3915,E,0.00,286.59,070106,,,A*69
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
$GPGGA,171116.773,4541.6177,N,00946.3911,E,1,05,03.2,246.1,M,46.0,M,,*6B
$GPRMC,171116.773,A,4541.6177,N,00946.3911,E,0.00,286.59,070106,,,A*6E
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
$GPGGA,171117.772,4541.6178,N,00946.3911,E,1,05,03.2,246.1,M,46.0,M,,*64
$GPRMC,171117.772,A,4541.6178,N,00946.3911,E,0.00,286.59,070106,,,A*61
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
$GPGGA,171118.772,4541.6178,N,00946.3910,E,1,05,03.2,246.1,M,46.0,M,,*6A
$GPGSA,A,3,01,03,14,19,22,,,,,,,,4.0,3.2,2.3*39
$GPGSV,2,1,08,1,44,127,46,3,20,160,43,11,64,298,,14,41,071,44*73
$GPGSV,2,2,08,19,58,176,40,20,31,310,,22,15,053,44,28,20,296,*75
$GPRMC,171118.772,A,4541.6178,N,00946.3910,E,0.00,286.59,070106,,,A*6F
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
$GPGGA,171119.772,4541.6178,N,00946.3908,E,1,05,03.2,246.2,M,46.0,M,,*61
$GPRMC,171119.772,A,4541.6178,N,00946.3908,E,0.00,286.59,070106,,,A*67
$GPVTG,286.59,T,,,0.00,N,0.00,K,A*70
The library is reading data from the virtual serial port created by gps
intermediate driver (so either my software an geoframework's sample software
can access data at the same time).
Data has been recorded without moving.
However, I verified that if I use my software that I developed to track
position using GPS API (with zig-zag problem), and use geoframework's lib to
retrieve position instead of gps api, I have a very good record. So I think
that really there is some problem with gps api retriving right position.
thanks for your help
DickGrier
instead of the EU "," which is being generated because of localization.
Perhaps this is cause a problem. If you Replace "," with "." and try the
positioning you may see a different result (or, maybe not).
Just an idea.
John Spaith [MS]
having.
First of all, you're expecting the data returned to be in decimal (which it
is) and not some sort of degrees minutes seconds representation (which it
isn't), correct? It's possible that if the values were misinterpreted a
small movement could be interpreted differently.
Next, I wonder if this is some sort of rounding problem? Is your program or
the printf() format doing something strange to blast off the least
significant digits in the result GPSAPI is returning you? The values I got
when running your test file below were quite similar to yours -- within 30
meters, which obviously isn't good enough when the same data should be
identical.
If this doesn't help, the next thing we need to do is reduce the "noise"
possible here. Could you create a file that has a few hundred copies of
this line:
$GPGGA,171033.782,4541.6142,N,00946.4068,E,1,04,21.8,246.1,M,46.0,M,,*6E
And then setup GPSID to use a FILE driver with this data, rather than COMM
driver, as laid out in MSDN. This way we can get the same position each
time. When I ran GPSID in my office against this here's what I saw (in
parens I show calculation from degrees minutes sec -> decimal, which shows
GPSID is returning the right value).
Latitude = 45.693570 (// 4541.6142 --> 45 + fraction (416142 * 10/6) -->
45.693570)
Longitude = 9.773447 (// 00946.4068 --> 9 + fraction (464068 * 10 / 6) -->
9.773446666)
Obviously my office isn't your office which is why I'm asking if you could
look into this a little more.
I had mentioned a known parsing bug that was fixed before devices shipped
and based on your output your device does NOT have the bug in question, so
it's not that.
--
John Spaith
Software Design Engineer, Windows CE
Microsoft Corporation
Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2003 Microsoft Corporation. All rights
reserved.
"Trapulo" <tra...@noemail.noemail> wrote in message
news:OekdW56E...@TK2MSFTNGP09.phx.gbl...
Trapulo
news:%23yFfia9...@TK2MSFTNGP10.phx.gbl...
> My apologies for the delay in responding here and the problems you're
> having.
No, problem, and thank you for your assistance!
> First of all, you're expecting the data returned to be in decimal (which
> it is) and not some sort of degrees minutes seconds representation (which
> it isn't), correct? It's possible that if the values were misinterpreted
> a small movement could be interpreted differently.
Yes, I need data in decimal format.
> Next, I wonder if this is some sort of rounding problem? Is your program
> or the printf() format doing something strange to blast off the least
> significant digits in the result GPSAPI is returning you? The values I
> got when running your test file below were quite similar to yours --
> within 30 meters, which obviously isn't good enough when the same data
> should be identical.
This is an interesting suggestion. In fact, now I remember this: I builded
my application around the SDK sample (GPS Sample) to have a managed wrapper
for gps api. When I builded it, I found an error with the function
GpsPosition.ParseDegreesMinutesSeconds, that I correct (I think).
Here there is the original code:
double degrees = (val / 100.0);
double minutes = (Math.Abs(degrees) - Math.Abs((double)(int)(degrees))) *
100;
double seconds = (Math.Abs(val) - Math.Abs((double)(int)val)) * 60.0;
return new DegreesMinutesSeconds((int)degrees, (int)minutes, seconds);
This code doesn't work, because val is some as "45.693673333333336", and
(int) val/100 gets always 0 degree for latitude and longitude. This is a
strange "bug". Hoevere, I changed this routine with this one:
Int32 degrees = (int)(val);
Double originalMM = (Math.Abs(val) - Math.Abs(degrees)) * 60;
Int32 minutes = (int)(originalMM);
Int32 seconds = (int)((originalMM - minutes) * 60);
return new DegreesMinutesSeconds(degrees, minutes, seconds);
Maybe my conversion is not ok?
However I dont' understand why SDK sample load a coordinate that is in
decimal value as DD MM SS format, and then re-convert it in decimal format:
GpsPosition.Longitude makes "get { return
ParseDegreesMinutesSeconds(dblLongitude).ToDecimalDegrees();"
I think there is some reason for this, but I cannot understand it and maybe
this "trip" can create some round error. Now I'm tried to change the
function as a more simple:
get { return dblLongitude; }
I see that I read different decimal values, but same DD MM SS values as with
the original implementation. Now I may make some road test to see if this
is best o worse.
>
> If this doesn't help, the next thing we need to do is reduce the "noise"
> possible here. Could you create a file that has a few hundred copies of
> this line:
>
> $GPGGA,171033.782,4541.6142,N,00946.4068,E,1,04,21.8,246.1,M,46.0,M,,*6E
>
> And then setup GPSID to use a FILE driver with this data, rather than COMM
> driver, as laid out in MSDN. This way we can get the same position each
> time. When I ran GPSID in my office against this here's what I saw (in
> parens I show calculation from degrees minutes sec -> decimal, which shows
> GPSID is returning the right value).
>
> Latitude = 45.693570 (// 4541.6142 --> 45 + fraction (416142 * 10/6) -->
> 45.693570)
> Longitude = 9.773447 (// 00946.4068 --> 9 + fraction (464068 * 10 / 6) -->
> 9.773446666)
>
> Obviously my office isn't your office which is why I'm asking if you could
> look into this a little more.
>
I make a test with the update I described previuosly, and then will try this
suggestion.
> I had mentioned a known parsing bug that was fixed before devices shipped
> and based on your output your device does NOT have the bug in question, so
> it's not that.
that's good :)
thank you
Trapulo
It really was a round error!
I solved with two changes:
1 - changed how SDK's GpsPosition class works, that, as I said, it seems
very strange:
public double Latitude
{
get { return dblLatitude; }
// original SDK's code:
// get { return
ParseDegreesMinutesSeconds(dblLatitude).ToDecimalDegrees(); }
}
idem for Longitude
2 - I also found an error on my decimal-to-DDMMSS routine. I was using an
Int32 to define seconds, but in fact I may use a double because there is a
lot of precision in this field.
private DegreesMinutesSeconds ParseDegreesMinutesSeconds(double val)
{
Int32 degrees = (int)(val);
Double originalMM = (Math.Abs(val) - Math.Abs(degrees)) * 60;
Int32 minutes = (int)(originalMM);
Double seconds = ((originalMM - minutes) * 60); // here I used an Int32
// prev code can be written better :)
return new DegreesMinutesSeconds(degrees, minutes, seconds);
// original SDK's code:
// double degrees = (val / 100.0);
// double minutes = (Math.Abs(degrees) - Math.Abs((double)(int)(degrees))) *
100;
// double seconds = (Math.Abs(val) - Math.Abs((double)(int)val)) * 60.0;
// return new DegreesMinutesSeconds((int)degrees, (int)minutes, seconds);
}
So, my original problem was in some SDK's wrapper bug and not in GPS API
behavior. Thank you for your assistance, and your help to find where the
problem was! It really help me a lot!
John Spaith [MS]
The SDK issue is most certainly our fault and I apologize that you had to
deal with it. I'm working with the C# SDK folks to make sure it does the
right thing. Though in fairness this is my fault, not theirs, since they
were working around the old NMEA parsing bug I had mentioned earlier. I'm
following up with the owners.
--
John Spaith
Software Design Engineer, Windows CE
Microsoft Corporation
Check out the new CE Networking Team Blog at http://blogs.msdn.com/cenet/.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2003 Microsoft Corporation. All rights
reserved.
"Trapulo" <tra...@noemail.noemail> wrote in message
news:OROMu4RG...@tk2msftngp13.phx.gbl...
Trapulo
I hope I can notice if there will be a new SDK wrapper around gps api from
C# team ;-)
Thank you
"John Spaith [MS]" <jsp...@ONLINE.microsoft.com> wrote in message
news:OOMODTsG...@TK2MSFTNGP10.phx.gbl...