Navigation
Neue Forenbeiträge
Newsfeeds
WAAS / EGNOS
Hi Mario,
With my BTQ1000, which works pretty well with your BT747 application on my macbook, I could normally benefit from satellite based augmentation signals with EGNOS satellites. Normally, 3 are now operational since October 2009, with IOR-W satellite lounched (PRN 126), which makes 3 satellites with ARTEMIS (PRN 124) and AOR-E (PRN 120).
If I choose 'WAAS' and 'utiliser SBAS en test', how do I know from my .csv recordings when it was actually used ? What is the difference between the 2 options ?
Is there an 'SBAS' indication in the 'VALID' field ? (that would be probably best)
Or shall I look whether there is a PRN 126 (n° 39), 124 or 120 (N°33) in the SID fields ?
Thanks for your answer and work.
=====================
Original answer by mdeweerd:
=====================
Hi "Foxecho"
The 'WAAS' option includes EGNOS.
The 'VALID' field will indicated DGPS in case WAAS or EGNOS was used. Since these systems are to my knowledge related to regions in the world, when you are in Europe, DGPS will indicate the use of EGNOS and in the US it will indicate the use of WAAS.
When 'Use SBAS in test' is active, then any SBAS data will be used. When the system was not officially active, the sats indicated that they were 'in test', indicating that the information they were providing was not "guaranteed".
I guess that satellites can still be in test in the future for maintenance reasons. Therefore a normal user should not activate that option.
It would be interesting of course that somebody checks the correlation between DGPS being indicated in the VALID field and the use of an SBAS satellite.
The SBAS satellite is possibly not present in the default satellite information. For that the DSTA field should be active. The DAGE field indicates how old the data is.
I hope this helps.
Mario
- Anmelden um Kommentare zu schreiben
OK, I'll check if I ever have
OK, I'll check if I ever have DGPS with proper satellites used.
Interesting link here
Interesting link here showing that SBAS (with all 3 EGNOS satellites) degrades accuracy (the article is not so recent, maybe sats settings have changed since then): http://www.gpspassion.com/fr/articles.asp?id=185
Unfortunately, the test was performed with SIRF 3 and Nemerix chipsets, not MTK like BT747, QSTARZ, BTQ1000...
Note that some GPS were not able at all to calculate DGPS position from EGNOS sats.
Has anyone noted that our MTK based GPS was capable of DGPS fix (not SPS) with any WAAS/EGNOS satellite ?
Hi The MTK chipset is capable
Hi
The MTK chipset is capable of DGPS. I've seen an MTK based logger do that.
I am not surprised that the DGPS positioning is considered not accurate. That corresponds to my personal observations.
I've recommended a few times here and there to not activate DGPS - but things can have changed since.
Mario
Mario, I test two iBlue-747
Mario,
I test two iBlue-747 at same time with/without SBA. I have not observed any difference between two track, when I see in Google Map.
Only in the CSV file, in the SBA set, show DGPS, but the accurate it is exacty the same.
Regards from Spain
Manuel
Thanks Manual for this
Thanks Manual for this feedback. I've noticed that one can have considerable position jumps when DGPS becomes active on a track.
The applied correction surely depends on when and where the GPS tracked.
! Hola Manuel ! That's
! Hola Manuel !
That's interesting, your test. Have you also checked in your Excel file if the altitudes (and VDOP) were also exactly the same ? Normally, SBAS is designed for aircraft final approach paths, and GPS worst accuracy is in vertical mode. Due to the relatively low elevation angle of the geostationnary satellite (it depends on which one(s) you received ?), there should be an improvement on vertical accuracy.
Besides, there should be an improvement on reliability and integrity of the SBAS data. But I have no clue of how to give any evidence for that with the iblue 747.
Hasta pronto ...
Hello Mario, I think I got it
Hello Mario,
I think I got it !
DGPS (and 'sometimes estimated mode') instead of SPS with my BTQ1000P, firmware Bcore 1.1, V1.38. Surprisingly, I don't find any of the satellites I expected (SID).
I'd like to make some averaging on a fix, to measure vertical dispersion in that mode (at first glance, a couple of meters, with a VDOP around 0,99.
But I think I have a trouble reading the proper values of SPEED, VDOP, HDOP, VDOP and distance in the csv file : from time to time, randomly, they indicate very high values, with no meaning at all.
Could you do something about that ? Please...
Besides, would it be possible to have commas (,) instead of points (.) for decimal separation : my openoffice can read the numbers as characters, and I've got trouble making averages.
Hi Foxecho 'Estimated Mode'
Hi Foxecho
'Estimated Mode' means that you did not have good reception, but the device does some kind of dead reckoning.
Very high values for VDOP, HDOP, PDOP mean that the position is inaccurate.
A high value for Distance will occur if a long way was done since that previously logged position or if the previously determined position was invalid.
I'll propagate a '.' or ',' setting for CSV only to the UI. It is surely manageable in openoffice at import time, but I agree that it is easier when configureable in BT747.
You can do something about these high values because BT747 allows you to do several things already:
Message out of topic.
Message out of topic.
Hi Foxecho Looking at the
Hi Foxecho
Looking at the table, I can understand the supection of a bug.
Can you send me your bin file so that I have a sample to look at what is going wrong (mail in the application in 'about').
First results : In DGPS
First results :
In DGPS indicated, with 4 to 5 sats used (HDOP = 3,1 / VDOP =1), with more than 600 points on a fixed point, we can calculate (thanks to Mario's modification of csv file)
- average speed of 2,0 km/h
- an average distance between each fix of ... 0,9 m
- an average vertical dispersion of 2,65 m.
Note that we never identified one of the expected EGNOS satellites, and that DAGE was stuck to zero, even when in 'estimated position'. This is maybe due to the way QSARTZ programs the GPS.
In SPS mode on the same point (but on a different day), with 5 to 6 sats (HDOP= 1,6 ; VDOP =2), we have
- average speed of 0,13 km/h
- an average distance of between each fix of ... 0,02 m
- an average vertical dispersion of 0,56 m.
This aims at giving a reference in both modes, with one good (SPS) constellation, and one medium (DGPS).
I wish I could do the same measurements with two identical GPSs co-located, at the same time, same warm-start, not to depend on sat constellation..
I have an iBlue 747, iBlue
I have an iBlue 747, iBlue 747 A+, Holux M241 and two Skytraq based GPS's (not recording sat information though).
I could do some parallel recording with all fields on - or we have to meet and check it out :-). The Qstarz is the same as one of the iBlue modules.
@mdeweerd, did you get to do
@mdeweerd, did you get to do the tests? It's interesting to know the results.
Hi I did not do that yet.
Hi
I did not do that yet.
I am using a Holux M1200-E
I am using a Holux M1200-E (MTK 3329 chipset) and I am located in Europe. I have observed that the fix method changes between SPS and DGPS from time to time. For my device, does that indicate if the device is actively receiving and using the EGNOS signal?
I would have anticipated that the HDOP and VDOP values decreased when in DGPS mode.
However, they seem to be largely unaffected by the mode (SPS/DGPS), see csv example here (positions modified slightly for privacy reasons)
INDEX,DATE,TIME,VALID,LATITUDE,N/S,LONGITUDE,E/W,HEIGHT(m),DSTA,DAGE,PDOP,HDOP,VDOP,NSAT (USED/VIEW)...
1408,2011/03/16,15:29:36.000,SPS,56.324068,N,10.334276,E,42.7,0,0,1.61,0.92,1.32,10(13),
1409,2011/03/16,15:29:37.000,SPS,56.324026,N,10.334135,E,42.6,0,0,1.61,0.92,1.32,10(13),
1410,2011/03/16,15:29:38.000,DGPS,56.323991,N,10.333984,E,42.6,0,0,1.61,0.92,1.32,10(13),
1411,2011/03/16,15:29:39.000,DGPS,56.323976,N,10.333818,E,42.5,0,0,1.61,0.92,1.32,10(13),
...
Is that normal?
Reflecting a bit on my own
Reflecting a bit on my own question. As I understand DOP is mostly depeding on the current position of the GPS satellites (a scale factor for the pseudo-range std deviation along various directions). And this one does not depend on EGNOS being available or not. So perhaps my data are not that surprising.
Instead I suppose it affects the pseudorange error, or the User Equivalent Range Error (UERE). Does anyone have good rules of thumb regarding what can be assumed about the size of UERE with SPS vs. DGPS in a non-urban environment.
Would 5 m/1 m be a resonable assumption?
When the fix method is
When the fix method is 'DGPS', that is when the device is using (in your case) eGNOS data which it can only use if it received the appropriate data from the satellite.
I am not surprised that the accuraccy values are not affected. I did not investigate in details, but IMHO, the *DOP values are based on the "correlation" with the signals received. Suppose that you and me are both satellites looking at a church. And we are one next to the other. If I say that the church is at 150 meters and you say it is at 140 meters, the distance to the church would be determined as 145 meters +/- 7 meters (I am not applying exact deviation mathematics, just illustrating).
Now if there would be a third person, physically at the same distance from the church but on the other side, saying that the church is at 100 meters. The new distance of us to the church would be at 130 +/- 15 meters given that it has to be in the center.
What DGPS is doing is that somewhere else, at another church another similar - more precise experiment is ongoing, still using us as satellites. For that church the exact locationis known and suppose that based on our signals, the location is found to be 3 meters too far north. So we say that there is an offset to do of 3 meters to the south.
We apply that on our church and supposing that the church is to the north of us, we now state that the church is at a distance of 130-3 = 127 meters.
Supposing that the 3 meters has 0 error, the end result still has an error margin of 15 meters unless we understand the correlation of the value of 3 with the value of 130.
[Maybe things are fuzzier now, but hopefully I hinted at what is happening].
I think that the *DOP values have more to do with the quality of reception (the experiment with our church) than with the error of a reference model (the fact that we suppose that a sattelite is at position XYZ while it really is at X1Y2Z2) which is what I think we get with DGPS.
Some people reported 5-10m
Some people reported 5-10m offsets besides the GE road with DGPS active while they were right on it with DPGS inactive.$
I am not sure that DGPS is 'valid' when not using it in a well controlled setup (excellent reception, fixed location (not moving),...).
Thanks for the explanation. I
Thanks for the explanation. I have read about EGNOS/WAAS and other SBAS methods and get the idea: pseudoranges are recorded in a network of accurately surveyed reference stations. Deviations due to propagation delays in the ionosphere, ephemeris, and other sources of systematic errors are accumulated to a central relay station, transmitted to geosynchronous satellites, which then broadcast the corrections at a specific frequency and format as dictated by the rules of ICAO.
I spoke with prof. Kai Borre earlier today regarding the precision, and he reports that the accuracy can be improved significantly by augmenting the SPS data with, e.g., EGNOS corrections. Typical error values are 1.0 m in the lateral plane and 1.5 m in the vertical direction for commercial SBAS enabled loggers. However, it depends on the implementation in the chipset used. Recent U-blox and Sirf chipsets should do this quite well. Wrt MTK I got not further info.