info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Dual-frequency GNSS mouse on the market?
38 views
Skip to first unread message
Reinhard Zwirner
Jun 21, 2021, 8:38:39 PM6/21/21
to
Dear experts,
I own a GNSS mouse which is based upon an M8 GNSS receiver module
made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
module F9P. Is there any consumer device with this (or a similar) module?
Many thanks in advance for any information.
Regards
Reinhard
I own a GNSS mouse which is based upon an M8 GNSS receiver module
made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
module F9P. Is there any consumer device with this (or a similar) module?
Many thanks in advance for any information.
Regards
Reinhard
Alan Browne
Jun 27, 2021, 11:52:22 AM6/27/21
to
I've bought some modules from Sparkfun - you'd need to build a bit of
h/w around the module. No biggie depending on your abilities and
SparkFun sell a lot of interfacing and support modules as well as
antennas and so on.
ZED-F9P is dual f, but is intended as an RTK oriented design. You would
need 2, obviously, for that mode and a data link to operate that way.
Very high accuracy. No idea how well it does as a standalong dual f
receiver.
https://www.sparkfun.com/products/15136
I have a couple ublox receivers here. Good receivers. The binary
interface is a bear to get right - the documentation is clear, but not
well ordered and the narrative on design application is thin. If you go
with NMEA it's much easier of course.
--
"...there are many humorous things in this world; among them the white
man's notion that he is less savage than the other savages."
-Samuel Clemens
Reinhard Zwirner
Jun 30, 2021, 7:15:46 PM6/30/21
to
Alan Browne schrieb:
[...]
Well, at least it seems so. Many thanks for your information :-)!
> I've bought some modules from Sparkfun - you'd need to build a bit of
> h/w around the module. No biggie depending on your abilities and
> SparkFun sell a lot of interfacing and support modules as well as
> antennas and so on.
I think that the h/w wouldn't be a big problem, but the s/w would.
> ZED-F9P is dual f, but is intended as an RTK oriented design. You
> would need 2, obviously, for that mode and a data link to operate
> that way. Very high accuracy. No idea how well it does as a
> standalong dual f receiver.
> https://www.sparkfun.com/products/15136
I'm searching for a standalone dual frequency receiver. In the
"wilderness" there will be areas without any mobile phone reception.
Additionally, you'll need extra power operating several devices at
the same time.
> I have a couple ublox receivers here. Good receivers. The binary
> interface is a bear to get right - the documentation is clear, but
> not well ordered and the narrative on design application is thin. If
> you go with NMEA it's much easier of course.
A friendly person wrote a Python program for extracting NMEA
sentences out of the data stream provided by the ublox mouse.
GpsBabel converts this data into GPX format: works fine. So I long
for such a dual frequency GNSS mouse ...
Regards
Reinhard
[...]
> This group died a long time ago, alas.
Hi Alan,
Well, at least it seems so. Many thanks for your information :-)!
> I've bought some modules from Sparkfun - you'd need to build a bit of
> h/w around the module. No biggie depending on your abilities and
> SparkFun sell a lot of interfacing and support modules as well as
> antennas and so on.
> ZED-F9P is dual f, but is intended as an RTK oriented design. You
> would need 2, obviously, for that mode and a data link to operate
> that way. Very high accuracy. No idea how well it does as a
> standalong dual f receiver.
> https://www.sparkfun.com/products/15136
"wilderness" there will be areas without any mobile phone reception.
Additionally, you'll need extra power operating several devices at
the same time.
> I have a couple ublox receivers here. Good receivers. The binary
> interface is a bear to get right - the documentation is clear, but
> not well ordered and the narrative on design application is thin. If
> you go with NMEA it's much easier of course.
sentences out of the data stream provided by the ublox mouse.
GpsBabel converts this data into GPX format: works fine. So I long
for such a dual frequency GNSS mouse ...
Regards
Reinhard
Alan Browne
Jul 1, 2021, 10:53:20 AM7/1/21
to
On 2021-06-30 19:15, Reinhard Zwirner wrote:
> Alan Browne schrieb:
>
> [...]
>> This group died a long time ago, alas.
>
> Hi Alan,
>
> Well, at least it seems so. Many thanks for your information :-)!
>
>> I've bought some modules from Sparkfun - you'd need to build a bit of
>> h/w around the module. No biggie depending on your abilities and
>> SparkFun sell a lot of interfacing and support modules as well as
>> antennas and so on.
>
> I think that the h/w wouldn't be a big problem, but the s/w would.
S/w (for me) is quite easy and hardware is not that hard.
> Alan Browne schrieb:
>
> [...]
>> This group died a long time ago, alas.
>
> Hi Alan,
>
> Well, at least it seems so. Many thanks for your information :-)!
>
>> I've bought some modules from Sparkfun - you'd need to build a bit of
>> h/w around the module. No biggie depending on your abilities and
>> SparkFun sell a lot of interfacing and support modules as well as
>> antennas and so on.
>
> I think that the h/w wouldn't be a big problem, but the s/w would.
>
>> ZED-F9P is dual f, but is intended as an RTK oriented design. You
>> would need 2, obviously, for that mode and a data link to operate
>> that way. Very high accuracy. No idea how well it does as a
>> standalong dual f receiver.
>> https://www.sparkfun.com/products/15136
>
> I'm searching for a standalone dual frequency receiver. In the
> "wilderness" there will be areas without any mobile phone reception.
> Additionally, you'll need extra power operating several devices at
> the same time.
wilderness" is not the best use of RTK. Also note that RTK is relative
positioning, not absolute.
>> I have a couple ublox receivers here. Good receivers. The binary
>> interface is a bear to get right - the documentation is clear, but
>> not well ordered and the narrative on design application is thin. If
>> you go with NMEA it's much easier of course.
>
> A friendly person wrote a Python program for extracting NMEA
> sentences out of the data stream provided by the ublox mouse.
> GpsBabel converts this data into GPX format: works fine. So I long
> for such a dual frequency GNSS mouse ...
consumer level goods.
Why do you want a dual f receiver to begin with?
Reinhard Zwirner
Jul 1, 2021, 11:45:18 AM7/1/21
to
Alan Browne schrieb:
[...]
position be better with dual f than with single f, even when using
several GNSS systems simultaneously? As an OSM mapper I'd like to map
"new" (= not yet mapped) paths, ways, POIs etc. as precise as
possible. And with this claim, the hardware does not necessarily have
to be dirt cheap ...
Regards
Reinhard
[...]
> Why do you want a dual f receiver to begin with?
I admit: Just for fun ;-)! Shouldn't the precision of the measured
position be better with dual f than with single f, even when using
several GNSS systems simultaneously? As an OSM mapper I'd like to map
"new" (= not yet mapped) paths, ways, POIs etc. as precise as
possible. And with this claim, the hardware does not necessarily have
to be dirt cheap ...
Regards
Reinhard
Alan Browne
Jul 1, 2021, 3:05:27 PM7/1/21
to
codeless use of L2 less available in the coming years. There is a
civilian L2 f, but it's not all satellites yet so not sure of the
coverage at any given time - only 4 operational on orbit.
There's also Galileo E5 (E1/E5 receiver) and I'm pretty ignorant about
that - a hole I should fill some day...
If you're in North America or Europe then most single f receivers get
the SBAS signal (WAAS / EGNOS) most of the time, so accuracies are
generally < 10m horizontally (typically less than 5 and often better
than 2m.
This does not work well in the woods however, esp. if you're at higher
latitudes. (Satellites are geostationary, so as you go up in latitude,
the satellite gets lower in the sky. So more north + woods does not do
well.
(Other SBAS systems in Russia, Japan and India too).
Terje Mathisen
Jul 1, 2021, 3:18:51 PM7/1/21
to
Alan Browne wrote:
> On 2021-07-01 11:45, Reinhard Zwirner wrote:
>> Alan Browne schrieb:
>>
>> [...]
>>> Why do you want a dual f receiver to begin with?
>>
>> I admit: Just for fun ;-)! Shouldn't the precision of the measured
>> position be better with dual f than with single f, even when using
>> several GNSS systems simultaneously? As an OSM mapper I'd like to map
>> "new" (= not yet mapped) paths, ways, POIs etc. as precise as
>> possible. And with this claim, the hardware does not necessarily have
>> to be dirt cheap ...
>
> Yes L1/L2 should be better, but the US at least are going to make
> codeless use of L2 less available in the coming years. There is a
> civilian L2 f, but it's not all satellites yet so not sure of the
> coverage at any given time - only 4 operational on orbit.
Here in Norway I want multi-system/multi-frequency GNSS in a bad way.
> On 2021-07-01 11:45, Reinhard Zwirner wrote:
>> Alan Browne schrieb:
>>
>> [...]
>>> Why do you want a dual f receiver to begin with?
>>
>> I admit: Just for fun ;-)! Shouldn't the precision of the measured
>> position be better with dual f than with single f, even when using
>> several GNSS systems simultaneously? As an OSM mapper I'd like to map
>> "new" (= not yet mapped) paths, ways, POIs etc. as precise as
>> possible. And with this claim, the hardware does not necessarily have
>> to be dirt cheap ...
>
> Yes L1/L2 should be better, but the US at least are going to make
> codeless use of L2 less available in the coming years. There is a
> civilian L2 f, but it's not all satellites yet so not sure of the
> coverage at any given time - only 4 operational on orbit.
Pretty much all my GPS tracking & mapping are in the forests, so getting
EGNOS support is not a given.
Anyway, year-old Pixel 4a 5G phone supports pretty much all GNSS
systems, so the actual chipset to do so is effectively free now, we just
need it in a form factor with a much better antenna, and optimized for
precision, not low power.
>
> There's also Galileo E5 (E1/E5 receiver) and I'm pretty ignorant about
> that - a hole I should fill some day...
>
> If you're in North America or Europe then most single f receivers get
> the SBAS signal (WAAS / EGNOS) most of the time, so accuracies are
> generally < 10m horizontally (typically less than 5 and often better
> than 2m.
>
> This does not work well in the woods however, esp. if you're at higher
> latitudes. (Satellites are geostationary, so as you go up in latitude,
> the satellite gets lower in the sky. So more north + woods does not do
> well.
Yeah. Seaside coverage has been excellent here (59-61N) since the end of
> There's also Galileo E5 (E1/E5 receiver) and I'm pretty ignorant about
> that - a hole I should fill some day...
>
> If you're in North America or Europe then most single f receivers get
> the SBAS signal (WAAS / EGNOS) most of the time, so accuracies are
> generally < 10m horizontally (typically less than 5 and often better
> than 2m.
>
> This does not work well in the woods however, esp. if you're at higher
> latitudes. (Satellites are geostationary, so as you go up in latitude,
> the satellite gets lower in the sky. So more north + woods does not do
> well.
Selective Availability (2001), at that time I measured 65 cm (1 sigma),
about 2m for 3 sigma/99% of all samples, and a single 30m excursion that
lasted for 30 sec, all taken over a two-week period with a roof-mounted
antenna on a metal roof, so very nice ground plane.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Alan Browne
Jul 4, 2021, 11:10:03 AM7/4/21
to
On 2021-07-01 15:18, Terje Mathisen wrote:
> Alan Browne wrote:
>>
>> This does not work well in the woods however, esp. if you're at higher
>> latitudes. (Satellites are geostationary, so as you go up in
>> latitude, the satellite gets lower in the sky. So more north + woods
>> does not do well.
>
> Yeah. Seaside coverage has been excellent here (59-61N) since the end of
> Selective Availability (2001), at that time I measured 65 cm (1 sigma),
> about 2m for 3 sigma/99% of all samples, and a single 30m excursion that
> lasted for 30 sec, all taken over a two-week period with a roof-mounted
> antenna on a metal roof, so very nice ground plane.
Metal roofs are prone to give you multipath depending on your setup.
>>
>> This does not work well in the woods however, esp. if you're at higher
>> latitudes. (Satellites are geostationary, so as you go up in
>> latitude, the satellite gets lower in the sky. So more north + woods
>> does not do well.
>
> Yeah. Seaside coverage has been excellent here (59-61N) since the end of
> Selective Availability (2001), at that time I measured 65 cm (1 sigma),
> about 2m for 3 sigma/99% of all samples, and a single 30m excursion that
> lasted for 30 sec, all taken over a two-week period with a roof-mounted
> antenna on a metal roof, so very nice ground plane.
Reinhard Zwirner
Jul 5, 2021, 6:55:57 AM7/5/21
to
Terje Mathisen schrieb:
[...]
> Here in Norway I want multi-system/multi-frequency GNSS in a bad way. ...
Though I live in Germany at not that high a latidude: me too!
When I currently map, I use four to five devices for to optimize
precision of position:
One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
the mentioned Navilock/ublox8 mouse together with a small DELL tablet
and sometimes my mobile phone (OSMAND+). It's my hope that a
dual-frequency GNSS receiver would yield at least the same precision ...
Hope dies last!
Regards
Reinhard
[...]
> Here in Norway I want multi-system/multi-frequency GNSS in a bad way. ...
Though I live in Germany at not that high a latidude: me too!
When I currently map, I use four to five devices for to optimize
precision of position:
One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
the mentioned Navilock/ublox8 mouse together with a small DELL tablet
and sometimes my mobile phone (OSMAND+). It's my hope that a
dual-frequency GNSS receiver would yield at least the same precision ...
Hope dies last!
Regards
Reinhard
Alan Browne
Jul 9, 2021, 10:21:36 AM7/9/21
to
to the same propagation errors in the atmosphere that you're hoping to
reduce with a dual f receiver.
Terje Mathisen
Jul 9, 2021, 4:53:33 PM7/9/21
to
Alan Browne wrote:
> On 2021-07-05 06:55, Reinhard Zwirner wrote:
>> Terje Mathisen schrieb:
>>
>> [...]
>>> Here in Norway I want multi-system/multi-frequency GNSS in a bad way.
>>> ...
>>
>> Though I live in Germany at not that high a latidude: me too!
>>
>> When I currently map, I use four to five devices for to optimize
>> precision of position:
>>
>> One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
>> the mentioned Navilock/ublox8 mouse together with a small DELL tablet
>> and sometimes my mobile phone (OSMAND+). It's my hope that a
>> dual-frequency GNSS receiver would yield at least the same precision ...
>
> Multiple receivers don't give you more precision - they're all subject
> to the same propagation errors in the atmosphere that you're hoping to
> reduce with a dual f receiver.
>
>
In reality this does help, even if not as much as he probably hopes: The
> On 2021-07-05 06:55, Reinhard Zwirner wrote:
>> Terje Mathisen schrieb:
>>
>> [...]
>>> Here in Norway I want multi-system/multi-frequency GNSS in a bad way.
>>> ...
>>
>> Though I live in Germany at not that high a latidude: me too!
>>
>> When I currently map, I use four to five devices for to optimize
>> precision of position:
>>
>> One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
>> the mentioned Navilock/ublox8 mouse together with a small DELL tablet
>> and sometimes my mobile phone (OSMAND+). It's my hope that a
>> dual-frequency GNSS receiver would yield at least the same precision ...
>
> Multiple receivers don't give you more precision - they're all subject
> to the same propagation errors in the atmosphere that you're hoping to
> reduce with a dual f receiver.
>
>
multiple antennas will have slightly different view angles, sometimes
wildly different multipath (due to branches/leaves/tree trunks) so the
ensemble will often show where they all agree and where local conditions
caused more variability.
As you note, it still does not help with atmospheric issues where only
doing multiple traversals with significantly different sat geometry will
make a notable difference. Strava Heat map is very nice but it also
shows the limitations of single-freq civilian receivers.
Alan Browne
Jul 10, 2021, 11:47:49 AM7/10/21
to
On 2021-07-09 16:53, Terje Mathisen wrote:
> Alan Browne wrote:
>> On 2021-07-05 06:55, Reinhard Zwirner wrote:
>>> Terje Mathisen schrieb:
>>>
>>> [...]
>>>> Here in Norway I want multi-system/multi-frequency GNSS in a bad
>>>> way. ...
>>>
>>> Though I live in Germany at not that high a latidude: me too!
>>>
>>> When I currently map, I use four to five devices for to optimize
>>> precision of position:
>>>
>>> One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
>>> the mentioned Navilock/ublox8 mouse together with a small DELL tablet
>>> and sometimes my mobile phone (OSMAND+). It's my hope that a
>>> dual-frequency GNSS receiver would yield at least the same precision ...
>>
>> Multiple receivers don't give you more precision - they're all subject
>> to the same propagation errors in the atmosphere that you're hoping to
>> reduce with a dual f receiver.
>>
>>
> In reality this does help, even if not as much as he probably hopes: The
> multiple antennas will have slightly different view angles, sometimes
> wildly different multipath (due to branches/leaves/tree trunks) so the
> ensemble will often show where they all agree and where local conditions
> caused more variability.
That would only work if the PR's from each receiver were handed over to
> Alan Browne wrote:
>> On 2021-07-05 06:55, Reinhard Zwirner wrote:
>>> Terje Mathisen schrieb:
>>>
>>> [...]
>>>> Here in Norway I want multi-system/multi-frequency GNSS in a bad
>>>> way. ...
>>>
>>> Though I live in Germany at not that high a latidude: me too!
>>>
>>> When I currently map, I use four to five devices for to optimize
>>> precision of position:
>>>
>>> One Garmin (GPS+GLONASS+EGNOS), another Garmin (GPS+GALILEO+EGNOS),
>>> the mentioned Navilock/ublox8 mouse together with a small DELL tablet
>>> and sometimes my mobile phone (OSMAND+). It's my hope that a
>>> dual-frequency GNSS receiver would yield at least the same precision ...
>>
>> Multiple receivers don't give you more precision - they're all subject
>> to the same propagation errors in the atmosphere that you're hoping to
>> reduce with a dual f receiver.
>>
>>
> In reality this does help, even if not as much as he probably hopes: The
> multiple antennas will have slightly different view angles, sometimes
> wildly different multipath (due to branches/leaves/tree trunks) so the
> ensemble will often show where they all agree and where local conditions
> caused more variability.
a single processor to compute the estimated position - and the gain
would be marginal at best. What he ends up with is a Chinese watch
dilemma. He could average them, but the accuracy wouldn't really be
better - just different.
>
> As you note, it still does not help with atmospheric issues where only
> doing multiple traversals with significantly different sat geometry will
> make a notable difference. Strava Heat map is very nice but it also
> shows the limitations of single-freq civilian receivers.
winter many times and then taking the 'average' ish position of the
trails. I haven't managed a good numerical model because for any
position along a trail, I don't know the "along track" position (or
error) any better than I know the cross track error.
Bernd Rose
Oct 3, 2021, 6:39:34 AM10/3/21
to
On Tue, 22nd Jun 2021 02:38:39 +0200, Reinhard Zwirner wrote:
> I own a GNSS mouse which is based upon an M8 GNSS receiver module
> made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
> module F9P. Is there any consumer device with this (or a similar) module?
Stonex S580 receiver:
> I own a GNSS mouse which is based upon an M8 GNSS receiver module
> made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
> module F9P. Is there any consumer device with this (or a similar) module?
https://www.stonex.it/project/s580-gnss-receiver
It is in the 3.000 Euro price range, though, and still (by far) the cheapest
GIS survey class dual-frequency receiver, that I know of. The only other
GNSS-device I'm aware of, that uses the u-blox F9P chip is the South-Korean
MRP-2000 from MBC:
http://rtk.mbc.co.kr/en/product/product.jsp?name=MRP-2000
I wasn't able to test the S580, yet. But from the general performance of
Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
tinker solutions published on the Internet, which were done with the u-blox
evaluation kit):
https://www.u-blox.com/en/product/c099-f9p-application-board
I expect very good positioning results.
Bernd
Bernd Rose
Oct 3, 2021, 6:49:43 AM10/3/21
to
On Sun, 27th Jun 2021 11:52:19 -0400, Alan Browne wrote:
> ZED-F9P is dual f, but is intended as an RTK oriented design. You would
> need 2, obviously, for that mode and a data link to operate that way.
Or a Network RTK solution. Here in Germany, more and more National survey
> ZED-F9P is dual f, but is intended as an RTK oriented design. You would
> need 2, obviously, for that mode and a data link to operate that way.
bureaus offer SAPOS RTCM NTRIP correction data via mobile communication for
free (Open Data initiative).
Bernd
Reinhard Zwirner
Oct 3, 2021, 8:02:42 AM10/3/21
to
Bernd Rose schrieb:
Hello Bernd,
Many thanks for all your really helpful comments.
Am I right understanding that this device ensures 1-m accuracy
without RTK processing?
> It is in the 3.000 Euro price range, though, and still (by far) the cheapest
> GIS survey class dual-frequency receiver, that I know of. ...
Umm. What about costs for additional necessary software?
> ... The only other
> I wasn't able to test the S580, yet. But from the general performance of
> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
> tinker solutions published on the Internet, which were done with the u-blox
> evaluation kit):
>
> https://www.u-blox.com/en/product/c099-f9p-application-board
>
> I expect very good positioning results.
Far too much tinkering with the application board, though.
Best regards
Reinhard
Hello Bernd,
Many thanks for all your really helpful comments.
Am I right understanding that this device ensures 1-m accuracy
without RTK processing?
> It is in the 3.000 Euro price range, though, and still (by far) the cheapest
Umm. What about costs for additional necessary software?
> ... The only other
> GNSS-device I'm aware of, that uses the u-blox F9P chip is the South-Korean
> MRP-2000 from MBC:
>
> http://rtk.mbc.co.kr/en/product/product.jsp?name=MRP-2000
Unfortunately, its product manual is totally in Korean language.
> MRP-2000 from MBC:
>
> http://rtk.mbc.co.kr/en/product/product.jsp?name=MRP-2000
> I wasn't able to test the S580, yet. But from the general performance of
> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
> tinker solutions published on the Internet, which were done with the u-blox
> evaluation kit):
>
> https://www.u-blox.com/en/product/c099-f9p-application-board
>
> I expect very good positioning results.
Best regards
Reinhard
Bernd Rose
Oct 3, 2021, 3:00:40 PM10/3/21
to
On Sun, 3rd Oct 2021 14:02:38 +0200, Reinhard Zwirner wrote:
>> Stonex S580 receiver:
>> https://www.stonex.it/project/s580-gnss-receiver
>
> Am I right understanding that this device ensures 1-m accuracy
> without RTK processing?
"Ensures" is not a word to be used wrt. GNSS accuracy. In non-differential
>> Stonex S580 receiver:
>> https://www.stonex.it/project/s580-gnss-receiver
>
> Am I right understanding that this device ensures 1-m accuracy
> without RTK processing?
mode and flat open land (= no tree coverage, buildings, etc.) this device
will have a very high probability of sub-meter accuracy. Not only because
of the large number of supported GNSS systems, but also because multiple
frequencies permit in-device corrections of atmospheric signal distortion.
With extensive tree coverage or similar sources of shadowing and multipath
reflections, I'd expect typical accuracy around 1 to 5 meters in 95 % of
the measurement cases. Very bad geometric constellation of the visible
satellites (deep narrow ravines and the like) will usually produce even
worse positions on average. - But, as I already wrote: I hadn't the chance
to test this device, yet...
Buying such a device is usually only sensible, when suitable differential
corrections will be used, though. Working in RTK base/rover mode would
require 2 (not necessarily the same) devices, as Alan already pointed out.
This is an option for professional usage scenarios, but usually not with
recreational utilization. Network RTK is the better option in such cases,
if such correction data is available for free or for a small enough fee.
As I already wrote elsewhere in this thread, SAPOS HEPS (NTRIP RTCM) data
(which was /very/ expensive) becomes freely available in more and more
counties of Germany. (Where we both happen to live.)
With such correction data (and sufficient time to wait for "fixed" position
status), this device should achieve centimeter-level accuracy in 95 % of
usage cases for flat open countryside and sub-meter accuracy in medium-level
shadowing/multipath situations. In extreme measurement situations, you are
likely to get no "fixed" solution and therefore be left with worse positions
on average.
You need to keep in mind, that the gain in GNSS position accuracy tends
to decay exponentially to the increasing price tag of more sophisticated
GNSS devices. Compared to any current consumer GNSS device, you'll most
likely find the additional 2,5 T€ /not/ well spent.
>> It is in the 3.000 Euro price range, though, and still (by far) the cheapest
>> GIS survey class dual-frequency receiver, that I know of. ...
>
> Umm. What about costs for additional necessary software?
since the device outputs standard NMEA data stream, any program that can
deal with such data will work. Including free GIS programs, like QGIS with
GPS plugin on Windows devices or QField on smartphones with Android.
On Windows, you should be able to connect the device with either USB or
Bluetooth. On Android, you may need additional software which translates
the data stream to the "mock location" port. These 2 apps work well in my
experience:
https://github.com/freshollie/UsbGps4Droid
https://play.google.com/store/apps/details?id=googoo.android.btgps
>> MRP-2000 from MBC:
>>
>> http://rtk.mbc.co.kr/en/product/product.jsp?name=MRP-2000
>
> Unfortunately, its product manual is totally in Korean language.
mobile phone chip and contract (for access to differential correction
data) from a South-Korean provider. Here in Europe, you'd not be able
to use a major part of the bought functionality as a result.
>> u-blox evaluation kit:
>>
>> https://www.u-blox.com/en/product/c099-f9p-application-board
[...]
> Far too much tinkering with the application board, though.
But *much* cheaper than the Stonex S580. For a home enthusiast, this
kit would, IMHO, be the best way to go. But - of course - this would
require much time for assembling, configuring, testing, and so on...
Bernd
Message has been deleted
Gavin Scott
Jun 7, 2022, 6:15:32 PM6/7/22
to
(Bleh, sorry about the previous content-free reply. Stupid Google Groups interface is stupid.)
I have a Garmin GPSMAP 65 handheld coming this week to play with which has L5 support and multi GNSS and will do a little write up after I have a chance to try it out.
G.
P.S. Hey dead USENET group, log time no post lol.
I have a Garmin GPSMAP 65 handheld coming this week to play with which has L5 support and multi GNSS and will do a little write up after I have a chance to try it out.
G.
P.S. Hey dead USENET group, log time no post lol.
Alan Browne
Jun 9, 2022, 2:18:57 PM6/9/22
to
On 2022-06-07 18:15, Gavin Scott wrote:
> I have a Garmin GPSMAP 65 handheld coming this week to play with which has L5 support and multi GNSS and will do a little write up after I have a chance to try it out.
Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
> I have a Garmin GPSMAP 65 handheld coming this week to play with which has L5 support and multi GNSS and will do a little write up after I have a chance to try it out.
Tracks all 4 constellations concurrently with 92 channels (GPS, GLONASS,
Galileo, Beidou).
Does not do L-5.
SMA antenna connector. Battery backup (Ni-MH) for ephemeris/almanac.
USB-3 power (data too? Not sure).
25 Hz update rate.
This I'll integrate to a Raspberry 4B+ running an embedded runtime.
--
"Mr Speaker, I withdraw my statement that half the cabinet are asses -
half the cabinet are not asses."
-Benjamin Disraeli
ga...@learn.bio
Jun 10, 2022, 10:34:05 PM6/10/22
to
On Thursday, June 9, 2022 at 1:18:57 PM UTC-5, Alan Browne wrote:
> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
If you mean the NEO-M9N then I have one of those and it works great! Something that I didn't find clear from the product page at Sparkfun was whether or not it would talk data over the USB-C, but indeed it works fine with just the USB connection and talks to uCenter no problem. Very nice chip/module.
> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
I've been playing with the Garmin GPSMAP 65 for a couple days now and it's working very well. Simultaneously tracks GPS and Galileo on both L1 and L5, and GLONASS on its usual single frequency. Pretty much stays locked on 6ft displayed accuracy and shows very little movement over the ground over time. Altitude still wanders +/- 20ft or so, but that seems so far to be better than my prior single-frequency GPS experience. I usually get 3-4 GPS L5 signals (which are oddly showing lower signal levels than the corresponding L1 signal much of the time, even though the L5 signal has a 3dB advantage) out of 8 or more GPS sats tracked, and usually all the Galileo sats are showing both E1 and E5a with good strength.
Apart from the new receiver, it's pretty much the bog-standard Garmin experience you would get from any halfway modern eTrex or similar GPSMAP model etc.
Alan Browne
Jun 11, 2022, 11:14:13 AM6/11/22
to
On 2022-06-10 22:34, ga...@learn.bio wrote:
> On Thursday, June 9, 2022 at 1:18:57 PM UTC-5, Alan Browne wrote:
>> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
>
> If you mean the NEO-M9N
Yes. Shoot me!
> On Thursday, June 9, 2022 at 1:18:57 PM UTC-5, Alan Browne wrote:
>> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
>
> If you mean the NEO-M9N
> then I have one of those and it works great! Something that I didn't find clear from the product page at Sparkfun was whether or not
> it would talk data over the USB-C, but indeed it works fine with just the USB connection and talks to uCenter no problem. Very nice
> chip/module.
will only need to set the higher update rate and add in the extra
constellations.)
>
> I've been playing with the Garmin GPSMAP 65 for a couple days now and it's working very well. Simultaneously tracks GPS and Galileo on both L1 and L5, and GLONASS on its usual single frequency. Pretty much stays locked on 6ft displayed accuracy and shows very little movement over the ground over time. Altitude still wanders +/- 20ft or so, but that seems so far to be better than my prior single-frequency GPS experience. I usually get 3-4 GPS L5 signals (which are oddly showing lower signal levels than the corresponding L1 signal much of the time, even though the L5 signal has a 3dB advantage) out of 8 or more GPS sats tracked, and usually all the Galileo sats are showing both E1 and E5a with good strength.
>
> Apart from the new receiver, it's pretty much the bog-standard Garmin experience you would get from any halfway modern eTrex or similar GPSMAP model etc.
receivers personally and I bought a couple eTrex Legends for work at
some point back in the early oughts.
The 65 is a bit pricey too - and sort of locked into their "eco sphere".
Sparkfun do offer various ZED-x9x boards - maybe I should go that way.
I'll have to DL the interface manual to see what I'd be getting into -
but it looks pretty good - if pricey (US$275 ... $300 / board).
... after a superficial glance, none of ZED boards from Sparkfun have
L5... need to dig a little more.
Reinhard Zwirner
Jun 12, 2022, 10:42:47 AM6/12/22
to
ga...@learn.bio schrieb:
I own
this <https://www.u-blox.com/en/product/c099-f9p-application-board>
board. (Unfortunately I had to wait nearly half a year for it instead
of the announced eight weeks :-( ...).
It works great though I cannot use it for the intended purpose of
postprocessing yet. Here in Lower Saxony, a northern state of
Germany, SAPOS data are provided for free but the data to be
corrected must be referenced to ETRS89 datum. Unfortunately, I have
not found a way to set this via the u-center, not even in the
settings area provided for the F9P boards.
Additionally, I am still searching a way to transform ubx data into
the RINEX format which is also needed for postprocessing <sigh> ...
As the saying goes: hope dies last!
Bye,
Reinhard
> On Thursday, June 9, 2022 at 1:18:57 PM UTC-5, Alan Browne wrote:
>> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
>
> If you mean the NEO-M9N then I have one of those and it works great! Something that I didn't find clear from the product page at Sparkfun was whether or not it would talk data over the USB-C, but indeed it works fine with just the USB connection and talks to uCenter no problem. ...
>> Looking at getting a uBlox NEO-M9M on a Sparkfun breakout board.
>
I own
this <https://www.u-blox.com/en/product/c099-f9p-application-board>
board. (Unfortunately I had to wait nearly half a year for it instead
of the announced eight weeks :-( ...).
It works great though I cannot use it for the intended purpose of
postprocessing yet. Here in Lower Saxony, a northern state of
Germany, SAPOS data are provided for free but the data to be
corrected must be referenced to ETRS89 datum. Unfortunately, I have
not found a way to set this via the u-center, not even in the
settings area provided for the F9P boards.
Additionally, I am still searching a way to transform ubx data into
the RINEX format which is also needed for postprocessing <sigh> ...
As the saying goes: hope dies last!
Bye,
Reinhard
Bernd Rose
Jun 12, 2022, 12:07:16 PM6/12/22
to
On Sun, 12th Jun 2022 16:42:45 +0200, Reinhard Zwirner wrote:
> Here in Lower Saxony, a northern state of Germany, SAPOS data are provided
> for free but the data to be corrected must be referenced to ETRS89 datum.
SAPOS (both RTCM 2.x and 3.x NTRIP) correction strings reference WGS84.
> Here in Lower Saxony, a northern state of Germany, SAPOS data are provided
> for free but the data to be corrected must be referenced to ETRS89 datum.
Therefore, no transformation is necessary.
> Additionally, I am still searching a way to transform ubx data into
> the RINEX format which is also needed for postprocessing <sigh> ...
https://www.unavco.org/software/data-processing/teqc/teqc.html
HTH.
Bernd
Bernd Rose
Jul 24, 2022, 2:43:44 PM7/24/22
to
Following myself up:
> I wasn't able to test the S580, yet. But from the general performance of
> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
> tinker solutions published on the Internet, which were done with the u-blox
> evaluation kit):
>
> https://www.u-blox.com/en/product/c099-f9p-application-board
>
> I expect very good positioning results.
In December, I took this device on our forest test track, containing several
degrees of tree coverage from nearly open to three-story deciduous forest
and dense conifer forest thicket. The terrain is mostly level with a few
low hilly structures in between.
The Stonex S580 beat all (older) GNSS devices of the GIS class and performed
on par with RTK receivers having a price tag several times higher.
Today I did the summer test with full leave coverage. The S580 showed nearly
the same performance as in the winter. Average precision sub-meter with
maximum deviation from (with sub-centimeter precision) known positions
less than 3 m in summer and less than 2 m in winter.
I used GPS, GLONASS, and GALILEO with SAPOS RTCM3 NTRIP correction. BEIDOU
could be enabled, but will be disabled on each restart of the device. So I
concentrated on the out-of-box experience of the device and left BEIDOU
switched off.
Even on 2 points deliberately shadowing about 160 degrees horizontally and
nearly up to the zenith from GNSS reception (one north, one south) and
two-story deciduous forest in all directions, the device acquired more than
enough satellites for a good solution (deviation sub-meter to sub-2-meter).
In all "normal" test points, about 25 to 30 went usually into the solution.
HDOP was stable below 1.0 ("over-determined"), PDOP around 1.0.
It was usually possible to get a "fixed" solution within 1 to 10 minutes.
All other cases were left by "float", but with very low HRMS/VRMS values
of only few centimeters. All measurements were done averaging 100 positions.
But because of fine weather (dry and sparse wind) and low solar activity
both in winter and summer, an acquired position was very stable during
the whole measuring period on all test points on both test days.
The device seems to be eliminating multipath problems from reflections in
the canopy by evaluating several frequencies of the same satellite against
each other. Therefore, performance during very bad conditions is likely to
stay acceptable. Because our GNSS test drive contains lots of old growth
and many death trees, I'm not inclined to do tests over there in stormy
conditions. ;-)
Following a track east to west and back with old deciduous stands on both
sides while logging position every 1 m, the resulting line was smooth
without any outlier. Winter aerial shows correct location right on top
of the ruts. And walking one rut in each direction, the difference shows
correct, with stable distance and of course without any crossing between
both half-tracks.
IMHO, the Stonex S580 is an amazing device for forest inventories and the
like. Control software with ability to inject NTRIP corrections is only
available for Android, unfortunately. It /may/ be possible on Windows, to
use co0com/hub4com and u-blox u-center to get corrected NMEA streams to
GIS programs. I haven't been able (as of yet) to successfully set this up,
though...
HTH.
Bernd
> I wasn't able to test the S580, yet. But from the general performance of
> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
> tinker solutions published on the Internet, which were done with the u-blox
> evaluation kit):
>
> https://www.u-blox.com/en/product/c099-f9p-application-board
>
> I expect very good positioning results.
degrees of tree coverage from nearly open to three-story deciduous forest
and dense conifer forest thicket. The terrain is mostly level with a few
low hilly structures in between.
The Stonex S580 beat all (older) GNSS devices of the GIS class and performed
on par with RTK receivers having a price tag several times higher.
Today I did the summer test with full leave coverage. The S580 showed nearly
the same performance as in the winter. Average precision sub-meter with
maximum deviation from (with sub-centimeter precision) known positions
less than 3 m in summer and less than 2 m in winter.
I used GPS, GLONASS, and GALILEO with SAPOS RTCM3 NTRIP correction. BEIDOU
could be enabled, but will be disabled on each restart of the device. So I
concentrated on the out-of-box experience of the device and left BEIDOU
switched off.
Even on 2 points deliberately shadowing about 160 degrees horizontally and
nearly up to the zenith from GNSS reception (one north, one south) and
two-story deciduous forest in all directions, the device acquired more than
enough satellites for a good solution (deviation sub-meter to sub-2-meter).
In all "normal" test points, about 25 to 30 went usually into the solution.
HDOP was stable below 1.0 ("over-determined"), PDOP around 1.0.
It was usually possible to get a "fixed" solution within 1 to 10 minutes.
All other cases were left by "float", but with very low HRMS/VRMS values
of only few centimeters. All measurements were done averaging 100 positions.
But because of fine weather (dry and sparse wind) and low solar activity
both in winter and summer, an acquired position was very stable during
the whole measuring period on all test points on both test days.
The device seems to be eliminating multipath problems from reflections in
the canopy by evaluating several frequencies of the same satellite against
each other. Therefore, performance during very bad conditions is likely to
stay acceptable. Because our GNSS test drive contains lots of old growth
and many death trees, I'm not inclined to do tests over there in stormy
conditions. ;-)
Following a track east to west and back with old deciduous stands on both
sides while logging position every 1 m, the resulting line was smooth
without any outlier. Winter aerial shows correct location right on top
of the ruts. And walking one rut in each direction, the difference shows
correct, with stable distance and of course without any crossing between
both half-tracks.
IMHO, the Stonex S580 is an amazing device for forest inventories and the
like. Control software with ability to inject NTRIP corrections is only
available for Android, unfortunately. It /may/ be possible on Windows, to
use co0com/hub4com and u-blox u-center to get corrected NMEA streams to
GIS programs. I haven't been able (as of yet) to successfully set this up,
though...
HTH.
Bernd
Reinhard Zwirner
Jul 24, 2022, 8:50:28 PM7/24/22
to
Bernd Rose schrieb:
Aren't you comparing apples and oranges?
ublox c099-f9p eval board: 250 €
Stonex S580: 3800 €
Scratching his head
Reinhard
> Following myself up:
>
>> I wasn't able to test the S580, yet. But from the general performance of
>> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
>> tinker solutions published on the Internet, which were done with the u-blox
>> evaluation kit):
>>
>> https://www.u-blox.com/en/product/c099-f9p-application-board
>>
>> I expect very good positioning results.
> In December, I took this device on our forest test track, containing several
> degrees of tree coverage from nearly open to three-story deciduous forest
> and dense conifer forest thicket. The terrain is mostly level with a few
> low hilly structures in between.
>
> The Stonex S580 beat all (older) GNSS devices of the GIS class and performed
> on par with RTK receivers having a price tag several times higher. ...
>
>> I wasn't able to test the S580, yet. But from the general performance of
>> Stonex GNSS devices and reported accuracies of the u-blox F9P (from some
>> tinker solutions published on the Internet, which were done with the u-blox
>> evaluation kit):
>>
>> https://www.u-blox.com/en/product/c099-f9p-application-board
>>
>> I expect very good positioning results.
> In December, I took this device on our forest test track, containing several
> degrees of tree coverage from nearly open to three-story deciduous forest
> and dense conifer forest thicket. The terrain is mostly level with a few
> low hilly structures in between.
>
> The Stonex S580 beat all (older) GNSS devices of the GIS class and performed
Aren't you comparing apples and oranges?
ublox c099-f9p eval board: 250 €
Stonex S580: 3800 €
Scratching his head
Reinhard
Bernd Rose
Jul 25, 2022, 1:36:36 AM7/25/22
to
| I wasn't able to test the S580, yet.
a professional GNSS device against a developer board carrying the same GNSS
chip. I pointed out the price difference between the two, myself, last year.
(And suggested the S580 for professional use, only. While pointing consumers
to board-based solutions.)
As to the point:
| The Stonex S580 beat all (older) GNSS devices of the GIS class and performed
| on par with RTK receivers having a price tag several times higher. ...
The test field included no developer board, but only professionally sold and
| on par with RTK receivers having a price tag several times higher. ...
supported devices of the - mostly single-frequency - GIS GNSS-receiver class
(usually priced one-digit thousands €/$) and devices from the professional -
always multi-frequency - RTK GNSS-receiver class (price usually 5 digits).
Because of restriction from some manufacturers, I cannot provide detailed
test results, comparing the performances of the different devices against
each other. But let's say this: The test field contained a wide sampling of
professional GNSS receivers, that have been in use in German forestry for
about the last decade...
The Stonex S580 stands between GIS and RTK receiver class. (As do some other
devices.) Its technical capabilities (multi-constellation multi-frequency)
are leaning to RTK, while the range of possible settings is /much/ lower
than customary with professional RTK receivers, that usually permit to
change and control every little aspect of the measuring process. While the
latter usually require professional surveyors to make the best use of them,
can the former be used by about anybody, after a short introduction.
Bernd
Reinhard Zwirner
Jul 25, 2022, 6:58:01 AM7/25/22
to
Bernd Rose schrieb:
[...]
Sorry for having misunderstood the purpose of your post. But it's
nice to learn that the S580 is using the same GNSS chip as F9P receiver.
Best regards
Reinhard
[...]
Sorry for having misunderstood the purpose of your post. But it's
nice to learn that the S580 is using the same GNSS chip as F9P receiver.
Best regards
Reinhard
Reinhard Zwirner
Mar 16, 2023, 2:37:52 PM3/16/23
to
Reinhard Zwirner schrieb:
> Dear experts,
nowadays, there is one!
<https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
It comes with antenna and a short USB cable for data communication
or just for connecting a battery as power supply.
Position data are supplied via USB or Bluetooth. Using Bluetooth
together with the smartphone app Lefebure NTRIP Client the position
data can be real time corrected by SAPOS data which, here in Lower
Saxony (Germany), are provided for free :-)! It works :-).
HTH
Reinhard
> Dear experts,
>
> I own a GNSS mouse which is based upon an M8 GNSS receiver module
> made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
> module F9P. Is there any consumer device with this (or a similar) module?
Hi,
> I own a GNSS mouse which is based upon an M8 GNSS receiver module
> made by ublox. Meanwhile ublox is offering the dual-frequeny GNSS
> module F9P. Is there any consumer device with this (or a similar) module?
nowadays, there is one!
<https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
It comes with antenna and a short USB cable for data communication
or just for connecting a battery as power supply.
Position data are supplied via USB or Bluetooth. Using Bluetooth
together with the smartphone app Lefebure NTRIP Client the position
data can be real time corrected by SAPOS data which, here in Lower
Saxony (Germany), are provided for free :-)! It works :-).
HTH
Reinhard
Bernd Rose
Mar 16, 2023, 4:17:38 PM3/16/23
to
On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:
[consumer device with u-blox F9P or similar]
Bernd
[consumer device with u-blox F9P or similar]
> nowadays, there is one!
>
> <https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
Wrong link, I guess.
>
> <https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
Bernd
Reinhard Zwirner
Mar 16, 2023, 4:28:17 PM3/16/23
to
Bernd Rose schrieb:
Hi Bernd,
Of course <sigh>! How could this happen? How embarrassing ...
Here's the right one:
<https://www.ardusimple.de/product/simplertk2blite-bt-case-kit/>
Regards
Reinhard
Of course <sigh>! How could this happen? How embarrassing ...
Here's the right one:
<https://www.ardusimple.de/product/simplertk2blite-bt-case-kit/>
Regards
Reinhard
Alan Browne
Mar 16, 2023, 5:58:56 PM3/16/23
to
--
“Donald Trump and his allies and supporters are a clear and present
danger to American democracy.”
- J Michael Luttig - 2022-06-16
- Former US appellate court judge (R) testifying to the January 6
committee
Alan Browne
Mar 16, 2023, 6:00:09 PM3/16/23
to
(Or let Google Chrome translate). I can read some German, just not
enough to be sure ...
Reinhard Zwirner
Mar 16, 2023, 6:18:50 PM3/16/23
to
Alan Browne schrieb:
I'm really sorry!
You can find the description in English here:
<https://www.ardusimple.com/product/simplertk2blite-bt-case-kit/>
HTH
Reinhard
> On 2023-03-16 16:17, Bernd Rose wrote:
>> On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:
[...]
>> On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:
>>> <https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
>> Wrong link, I guess.
> I was puzzled too ...
Hi Alan,
>> Wrong link, I guess.
> I was puzzled too ...
I'm really sorry!
You can find the description in English here:
<https://www.ardusimple.com/product/simplertk2blite-bt-case-kit/>
HTH
Reinhard
Alan Browne
Mar 16, 2023, 7:31:06 PM3/16/23
to
On 2023-03-16 18:18, Reinhard Zwirner wrote:
> Alan Browne schrieb:
>> On 2023-03-16 16:17, Bernd Rose wrote:
>>> On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:
>
> [...]
>>>> <https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
>
>>> Wrong link, I guess.
>
>> I was puzzled too ...
>
> Hi Alan,
>
> I'm really sorry!
No worry.
> Alan Browne schrieb:
>> On 2023-03-16 16:17, Bernd Rose wrote:
>>> On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:
>
> [...]
>>>> <https://www.google.de/maps/@51.6312512,10.3664979,832m/data=!3m1!1e3!5m1!1e3?hl=de&ucbcb=1>
>
>>> Wrong link, I guess.
>
>> I was puzzled too ...
>
> Hi Alan,
>
> I'm really sorry!
>
> You can find the description in English here:
>
> <https://www.ardusimple.com/product/simplertk2blite-bt-case-kit/>
I'll be re-launching a particular project.
Cheers,
Bernd Rose
Mar 17, 2023, 2:43:37 PM3/17/23
to
On Thu, 16 Mar 2023 21:28:15 +0100, Reinhard Zwirner wrote:
>> [consumer device with u-blox F9P or similar]
>>> nowadays, there is one!
[...]
>> [consumer device with u-blox F9P or similar]
>>> nowadays, there is one!
> <https://www.ardusimple.de/product/simplertk2blite-bt-case-kit/>
Interesting site. Thank you very much for pointing it out!
I'll have to dig a bit deeper. But especially the triple band Septentrio
Mosaic-X5 receiver seems worth testing even from a semi-professional basis.
Bernd
Reinhard Zwirner
Mar 17, 2023, 6:08:21 PM3/17/23
to
Bernd Rose schrieb:
Do you know something about its price? Unfortunately, one has to
register to get more and detailed information ... :-(.
Am I right when understanding that the mentioned Septentrio receiver
is a raw module without confectioned periphery? And what do you mean
with "triple band"?
Ciao
Reinhard
register to get more and detailed information ... :-(.
Am I right when understanding that the mentioned Septentrio receiver
is a raw module without confectioned periphery? And what do you mean
with "triple band"?
Ciao
Reinhard
Bernd Rose
Mar 18, 2023, 4:16:59 AM3/18/23
to
On Fri, 17 Mar 2023 23:08:19 +0100, Reinhard Zwirner wrote:
[Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
a special configuration of the "RTK Base-Rover Calibrated Surveyor Kit":
English website:
https://www.ardusimple.com/product/rtk-base-rover-calibrated-surveyor-kit
German website:
https://www.ardusimple.de/product/rtk-base-rover-calibrated-surveyor-kit
Switch prices to EUR (needs cookies to stick) and select the following
options (I name only the English terms here; translation to German should
be obvious in all cases):
Receiver technology: "Triple band (millimeter precision)"
Radiolink options: "Medium range" [will be deactivated later]
Bluetooth options: "Base and rover"
Below the main selection area you'll see a list of components. Toggle any
entry "2" to "1" to get an impression, what the sum of all required
components will be for just one receiver. Deselect "Radio Module Medium
Range" completely, because this is only required to combine 2 receivers
in a base-rover setup.
End price will be 975 € (without any monopod/bipod/tripod, carry case,...).
This may seem much. Comparable devices usually /start/ around tenfold price
tags, though.
> Unfortunately, one has to register to get more and detailed information ... :-(.
No. Just dismiss the popup requesting your contact data.
> what do you mean with "triple band"?
GNSS satellites send their signals in a range of the spectrum of waves
of all frequencies called L-band. Inside this band there are certain
frequencies to transmit GNSS information. This following image shows
these frequencies. (The naming of the band sometimes differs between
GNSS systems [like L1 = E1]. But they mean essentially the same.)
https://gssc.esa.int/navipedia/images/c/cf/GNSS_All_Signals.png
As you can see, the information is sent as "peaks" with emanation to direct
neighboring frequencies. Think of an old analog radio, where you have to
tune in on a certain frequency to get a certain station. In background
you may hear a different station from further away. It is somewhat similar
with GNSS. Each system sends on up to 4 main frequencies. Although the
frequencies overlap for different GNSS systems, the information may be
split by the receiver, because one "radio station" sends only high tunes,
while another sends "bass". (So to speak.) Apart from the "sound of the
music", the "rhythm" sometimes carries information, as well.
A GNSS receiver needs to be able to get the information for a certain
frequency to evaluate this. For any frequency (= band), the antennae
/and/ the analog-digital converter needs to be adjusted and configured.
This complicates the electronics very much. So, the most simple receivers
just support L1 band and from this only a certain modulation type (C/A).
To get more, you need to pay (much) more.
The u-blox F9P is a modul containing different chips for 2 frequencies.
Therefore, it is a dual-band receiver modul. The Septentrio Mosaic-X5
is an integrated chip, supporting 3 frequencies from start. Therefore,
it is called a triple band receiver.
Each frequency has a different statistical probability of being disturbed
by obstructions, like ionospheric disturbances. Depending on the angle
of the satellite, the distance any GNSS signal needs to travel through
the atmosphere is sometimes longer or shorter. Any distance between
satellite and your receiver calculated will be an average value with
confidence interval. Think of it as a light spot shown from a flood
light onto a stage. Evaluating information from different bands for the
same satellite will give a different average value and confidence interval.
(Aka: A different spotlight.) Hopefully, the spotlights overlap. The
receiver will assume, that the real position will be just in the (smaller)
overlapping area. Information from a third band will narrow the position
even more. Evaluating the different modulations on each band helps further.
HTH.
Bernd
[Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
> Do you know something about its price?
Currently, this receiver is only available as assembly parts or as part of
a special configuration of the "RTK Base-Rover Calibrated Surveyor Kit":
English website:
https://www.ardusimple.com/product/rtk-base-rover-calibrated-surveyor-kit
German website:
https://www.ardusimple.de/product/rtk-base-rover-calibrated-surveyor-kit
Switch prices to EUR (needs cookies to stick) and select the following
options (I name only the English terms here; translation to German should
be obvious in all cases):
Receiver technology: "Triple band (millimeter precision)"
Radiolink options: "Medium range" [will be deactivated later]
Bluetooth options: "Base and rover"
Below the main selection area you'll see a list of components. Toggle any
entry "2" to "1" to get an impression, what the sum of all required
components will be for just one receiver. Deselect "Radio Module Medium
Range" completely, because this is only required to combine 2 receivers
in a base-rover setup.
End price will be 975 € (without any monopod/bipod/tripod, carry case,...).
This may seem much. Comparable devices usually /start/ around tenfold price
tags, though.
> Unfortunately, one has to register to get more and detailed information ... :-(.
> what do you mean with "triple band"?
of all frequencies called L-band. Inside this band there are certain
frequencies to transmit GNSS information. This following image shows
these frequencies. (The naming of the band sometimes differs between
GNSS systems [like L1 = E1]. But they mean essentially the same.)
https://gssc.esa.int/navipedia/images/c/cf/GNSS_All_Signals.png
As you can see, the information is sent as "peaks" with emanation to direct
neighboring frequencies. Think of an old analog radio, where you have to
tune in on a certain frequency to get a certain station. In background
you may hear a different station from further away. It is somewhat similar
with GNSS. Each system sends on up to 4 main frequencies. Although the
frequencies overlap for different GNSS systems, the information may be
split by the receiver, because one "radio station" sends only high tunes,
while another sends "bass". (So to speak.) Apart from the "sound of the
music", the "rhythm" sometimes carries information, as well.
A GNSS receiver needs to be able to get the information for a certain
frequency to evaluate this. For any frequency (= band), the antennae
/and/ the analog-digital converter needs to be adjusted and configured.
This complicates the electronics very much. So, the most simple receivers
just support L1 band and from this only a certain modulation type (C/A).
To get more, you need to pay (much) more.
The u-blox F9P is a modul containing different chips for 2 frequencies.
Therefore, it is a dual-band receiver modul. The Septentrio Mosaic-X5
is an integrated chip, supporting 3 frequencies from start. Therefore,
it is called a triple band receiver.
Each frequency has a different statistical probability of being disturbed
by obstructions, like ionospheric disturbances. Depending on the angle
of the satellite, the distance any GNSS signal needs to travel through
the atmosphere is sometimes longer or shorter. Any distance between
satellite and your receiver calculated will be an average value with
confidence interval. Think of it as a light spot shown from a flood
light onto a stage. Evaluating information from different bands for the
same satellite will give a different average value and confidence interval.
(Aka: A different spotlight.) Hopefully, the spotlights overlap. The
receiver will assume, that the real position will be just in the (smaller)
overlapping area. Information from a third band will narrow the position
even more. Evaluating the different modulations on each band helps further.
HTH.
Bernd
Reinhard Zwirner
Mar 18, 2023, 9:58:04 AM3/18/23
to
Bernd Rose schrieb:
misunderstandable. It referred to
<https://www.septentrio.com/en/products/gnss-receivers/receivers-module/mosaic>
(scroll down) -> Specifications (scroll down) -> Show more specifications
[...]
>> what do you mean with "triple band"?
>
> [comprehensive explanation]
Many thanks. All this is/was clear. My question just has been
generated by IMO inconsistent terminology. In this respect I would
have expected "triple frequency" instead of "triple band". For me,
the different GNSS systems work on different frequency bands and send
position data on different frequencies within those bands. Anyway, it
has helped :-).
Thanks again,
Reinhard
> On Fri, 17 Mar 2023 23:08:19 +0100, Reinhard Zwirner wrote:
>
> [Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
>> Do you know something about its price?
[...]
>
> [Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
>> Do you know something about its price?
>> Unfortunately, one has to register to get more and detailed information ... :-(.
>
> No. Just dismiss the popup requesting your contact data.
Sorry! Obviously, my question together with the above remark has been
>
> No. Just dismiss the popup requesting your contact data.
misunderstandable. It referred to
<https://www.septentrio.com/en/products/gnss-receivers/receivers-module/mosaic>
(scroll down) -> Specifications (scroll down) -> Show more specifications
[...]
>> what do you mean with "triple band"?
>
Many thanks. All this is/was clear. My question just has been
generated by IMO inconsistent terminology. In this respect I would
have expected "triple frequency" instead of "triple band". For me,
the different GNSS systems work on different frequency bands and send
position data on different frequencies within those bands. Anyway, it
has helped :-).
Thanks again,
Reinhard
Bernd Rose
Mar 18, 2023, 2:55:24 PM3/18/23
to
On Sat, 18 Mar 2023 14:58:01 +0100, Reinhard Zwirner wrote:
[Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
[Triple band Septentrio Mosaic-X5 receiver on ArduSimple]
>>> Unfortunately, one has to register to get more and detailed information ... :-(.
[...]
> <https://www.septentrio.com/en/products/gnss-receivers/receivers-module/mosaic>
>
> (scroll down) -> Specifications (scroll down) -> Show more specifications
They are not consistent in their website behavior. When you come from the
>
> (scroll down) -> Specifications (scroll down) -> Show more specifications
support area of the website with cookies enabled, you get to download any
document without requirement of a login. Apart from this, direct links to
the resources work as well. You may get them from search engines. The
main Mosaic manual should have all the information you need:
https://www.septentrio.com/system/files/support/mosaic_hardware_manual_v1.7.0.pdf
> I would have expected "triple frequency" instead of "triple band".
manufacturer tries to narrow down reception of a certain frequency as exact
as technically possible. With GNSS, the relevant information is not coded
on an exact frequency. If you look at the frequency image I linked to in
my former message, you'll sometimes see spikes at both sides of the bell
curve depicting the transmission field intensity. Those spikes carry
relevant information /different/ from the information found in the bell
curve maximum. Therefore, GNSS antennas and the analog-digital decoders
of GNSS modules are calibrated to frequency /bands/ and not to exact
frequencies.
Bernd
Reinhard Zwirner
Mar 18, 2023, 5:22:06 PM3/18/23
to
Bernd Rose schrieb:
Really?
> ... With GNSS, the relevant information is not coded
> on an exact frequency. ...
You're absolutely right! But let's have a look at radio in the FM
band. German stations transmit their signals on (center-)frequencies
in the range of 87.5 to 108.0 MHz. But when transmitting the desired
information the transmitted frequency is varying depending on the
contents of the transmitted information (frequency, amplitude)
according to the principles of frequency modulation. Because of this
locally adjacent stations must maintain a minimum distance with
regard to their transmission frequencies. (At least that's what I
learned at university some decades ago ;-) ...)
The same applies to GNSS signals though the modulation principle is
different. As can be seen in the linked frequency image a specific
frequency is specified for all signals whereas the bandwidth required
by the modulation principle is not mentioned at all.
Therefore my former confusion.
Best regards
Reinhard
> On Sat, 18 Mar 2023 14:58:01 +0100, Reinhard Zwirner wrote:
[...]
>> I would have expected "triple frequency" instead of "triple band".
> This is, where my analogy to analog radios goes astray. With a radio, the
> manufacturer tries to narrow down reception of a certain frequency as exact
> as technically possible. ...
> This is, where my analogy to analog radios goes astray. With a radio, the
> manufacturer tries to narrow down reception of a certain frequency as exact
Really?
> ... With GNSS, the relevant information is not coded
> on an exact frequency. ...
You're absolutely right! But let's have a look at radio in the FM
band. German stations transmit their signals on (center-)frequencies
in the range of 87.5 to 108.0 MHz. But when transmitting the desired
information the transmitted frequency is varying depending on the
contents of the transmitted information (frequency, amplitude)
according to the principles of frequency modulation. Because of this
locally adjacent stations must maintain a minimum distance with
regard to their transmission frequencies. (At least that's what I
learned at university some decades ago ;-) ...)
The same applies to GNSS signals though the modulation principle is
different. As can be seen in the linked frequency image a specific
frequency is specified for all signals whereas the bandwidth required
by the modulation principle is not mentioned at all.
Therefore my former confusion.
Best regards
Reinhard
Bernd Rose
Mar 19, 2023, 12:35:26 PM3/19/23
to
On Sat, 18 Mar 2023 22:22:03 +0100, Reinhard Zwirner wrote:
> Bernd Rose schrieb:
>> On Sat, 18 Mar 2023 14:58:01 +0100, Reinhard Zwirner wrote:
>
> [...]
>>> I would have expected "triple frequency" instead of "triple band".
>
>> This is, where my analogy to analog radios goes astray. With a radio, the
>> manufacturer tries to narrow down reception of a certain frequency as exact
>> as technically possible. ...
>
> Really?
>
>> ... With GNSS, the relevant information is not coded
>> on an exact frequency. ...
>
> You're absolutely right! But let's have a look at radio in the FM
> band. German stations transmit their signals on (center-)frequencies
> in the range of 87.5 to 108.0 MHz. But when transmitting the desired
> information the transmitted frequency is varying depending on the
> contents of the transmitted information (frequency, amplitude)
> according to the principles of frequency modulation. Because of this
> locally adjacent stations must maintain a minimum distance with
> regard to their transmission frequencies. (At least that's what I
> learned at university some decades ago ;-) ...)
That's what I wrote: Radio receivers are configured to filter out everything
> Bernd Rose schrieb:
>> On Sat, 18 Mar 2023 14:58:01 +0100, Reinhard Zwirner wrote:
>
> [...]
>>> I would have expected "triple frequency" instead of "triple band".
>
>> This is, where my analogy to analog radios goes astray. With a radio, the
>> manufacturer tries to narrow down reception of a certain frequency as exact
>> as technically possible. ...
>
> Really?
>
>> ... With GNSS, the relevant information is not coded
>> on an exact frequency. ...
>
> You're absolutely right! But let's have a look at radio in the FM
> band. German stations transmit their signals on (center-)frequencies
> in the range of 87.5 to 108.0 MHz. But when transmitting the desired
> information the transmitted frequency is varying depending on the
> contents of the transmitted information (frequency, amplitude)
> according to the principles of frequency modulation. Because of this
> locally adjacent stations must maintain a minimum distance with
> regard to their transmission frequencies. (At least that's what I
> learned at university some decades ago ;-) ...)
(as strict as technically possible - depending on the modulation method used
for the transmitted audio, of course) around the *one(!)* currently selected
reception frequency.
> The same applies to GNSS signals though the modulation principle is
> different. As can be seen in the linked frequency image a specific
> frequency is specified for all signals whereas the bandwidth required
> by the modulation principle is not mentioned at all.
for a broad frequency spectrum ("band") containing *several(!)* discrete
frequencies carrying /different/ relevant information.
With a radio, the user accounts for any frequency drift by fine-tuning to
the best reception.
With GNSS, the receiver chip extracts all relevant information by applying
mathematical/statistical and contentual analysis (concurrently) to a whole
frequency band. Any detection for noise, frequency drift and so on (for
/all/ relevant carrier frequencies inside the band!) has to be done by the
algorithms of the receiver chip firmware.
To come back to your original assessment:
>>> I would have expected "triple frequency" instead of "triple band".
A triple band receiver could therefore not be equally named as a triple
frequency receiver, but rather as a nona (= 9) frequency receiver. (Or
sth. around this number.) And that's /without/ accounting for the relevant
side-band frequencies... ;-)
Bernd
Terje Mathisen
Mar 20, 2023, 4:09:10 AM3/20/23
to
you are well versed in the technology:
It seems to me that both of you are over-complicating this as part of
trying to explain it in simpler terms:
All GNSS signals start with a fixed carrier frequency, then you apply a
very significant doppler shift to this baseline (which the receiver has
to estimate & correct for), before you smear the signal across a much
wider frequency band using a direct pseudo-random sequence, unique to
each sat.
This smearing code has 1023 +/- bits for the GPS civilian signal and
10230 (so 10x more) for the military version which is therefore a bit
harder to jam and impossible to spoof unless you have the encryption
keys they use.
Any receiver _must_ be able to tweak its own copy of each satellite's
spreading code, both in phase (i.e. where/when did it start) and doppler
frequency shift in order to lock on. Without doing this the signal is in
fact impossible to detect since it is well below the background noise
floor, but an N bit spreading code provides approximately sqrt(N) (so
about 30 x) signal amplification when all codes are maximally far apart
(the original "golden codes"), a bit less when we start to overload the
spectrum with many more codes.
Anyway, the key is that GNSS systems by design are trading spectrum for
power: By using a far wider frequency range than the payload signal
would require, they are able to function with an order of magnitude less
onboard transmission power, and as a side benefit, locking onto the
spreading code provides both sat identification and extremely good time
and doppler measurements. :-)
Using multiple, widely separated frequency bands provide the very
significant benefit that different frequencies will have different (but
consistent) behavior when passing through the atmosphere, making it
possible to estimate the actual transmission delay due to signal path
bending.
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
Reinhard Zwirner
Mar 20, 2023, 6:02:43 PM3/20/23
to
Only partial. That applies to long-term frequency stability. With FM,
for example, information is contained in short-term frequency variations.
> With GNSS, the receiver chip extracts all relevant information by applying
> mathematical/statistical and contentual analysis (concurrently) to a whole
> frequency band. Any detection for noise, frequency drift and so on (for
> /all/ relevant carrier frequencies inside the band!) has to be done by the
> algorithms of the receiver chip firmware.
radio signals at, say, 98.0 MHz it is necessary to transmit signals
from 97.925 to 98.075 MHz. If this bandwidth is reduced parts of the
original signal's contents will get lost. Of course bandwidth needed
for FM transmission is really narrow compared to bandwidth for
"Spread Spectrum Modulation".
> To come back to your original assessment:
>>>> I would have expected "triple frequency" instead of "triple band".
>
> A triple band receiver could therefore not be equally named as a triple
> frequency receiver, but rather as a nona (= 9) frequency receiver. (Or
> sth. around this number.) And that's /without/ accounting for the relevant
> side-band frequencies... ;-)
Garmin has succeeded in squaring the circle:
<https://www.garmin.com/en-CA/p/890109> (scroll down)
"MULTI-BAND GNSS SUPPORT
Access multiple global navigation satellite systems (GPS, Galileo and
QZSS). Get access to multiple [*] frequencies sent by navigation
satellites for improved position accuracy in areas where GNSS signals
are reflected, weak or typically don't penetrate."
[*]: nine ;-)?
Best regards and thanks again for your help
Reinhard
Bernd Rose
Mar 21, 2023, 2:16:44 AM3/21/23
to
On Mon, 20 Mar 2023 23:02:42 +0100, Reinhard Zwirner wrote:
> That's what I wrote: Radio receivers are configured to filter out everything
> (as strict as technically possible - depending on the modulation method used
> for the transmitted audio, of course) around the *one(!)* currently selected
> reception frequency.
[...]
> That's what I wrote: Radio receivers are configured to filter out everything
> (as strict as technically possible - depending on the modulation method used
> for the transmitted audio, of course) around the *one(!)* currently selected
> reception frequency.
>> With a radio, the user accounts for any frequency drift by fine-tuning to
>> the best reception.
[...]
>> the best reception.
> Only partial. That applies to long-term frequency stability. With FM,
> for example, information is contained in short-term frequency variations.
To cite myself from above:
> for example, information is contained in short-term frequency variations.
| as strict as technically possible - depending on the modulation method
> Okay, I admit that it's not easy to find a correct wording. Maybe
> Garmin has succeeded in squaring the circle:
>
> <https://www.garmin.com/en-CA/p/890109> (scroll down)
>
> "MULTI-BAND GNSS SUPPORT
>
> Access multiple global navigation satellite systems (GPS, Galileo and
> QZSS). Get access to multiple [*] frequencies sent by navigation
> satellites for improved position accuracy in areas where GNSS signals
> are reflected, weak or typically don't penetrate."
>
> [*]: nine ;-)?
Give or take, when considering the 3 mayor bands and ignoring side-band
> Garmin has succeeded in squaring the circle:
>
> <https://www.garmin.com/en-CA/p/890109> (scroll down)
>
> "MULTI-BAND GNSS SUPPORT
>
> Access multiple global navigation satellite systems (GPS, Galileo and
> QZSS). Get access to multiple [*] frequencies sent by navigation
> satellites for improved position accuracy in areas where GNSS signals
> are reflected, weak or typically don't penetrate."
>
> [*]: nine ;-)?
peaks (BOC - Binary Offset Carrier) that have a defined distance from
their related center frequency and therefore /could/ be considered
separate frequencies... ;-)
Bernd
Bernd Rose
Mar 21, 2023, 2:32:19 AM3/21/23
to
On Mon, 20 Mar 2023 09:09:07 +0100, Terje Mathisen wrote:
> the key is that GNSS systems by design are trading spectrum for
> power: By using a far wider frequency range than the payload signal
> would require, they are able to function with an order of magnitude less
> onboard transmission power, and as a side benefit, locking onto the
> spreading code provides both sat identification and extremely good time
> and doppler measurements. :-)
The spread range is only one aspect, why it is better to talk about
> the key is that GNSS systems by design are trading spectrum for
> power: By using a far wider frequency range than the payload signal
> would require, they are able to function with an order of magnitude less
> onboard transmission power, and as a side benefit, locking onto the
> spreading code provides both sat identification and extremely good time
> and doppler measurements. :-)
GNSS frequency bands instead of frequencies. (When talking about the
whole bands.) The other (and, IMHO, more relevant) is, that (inside
each band) different GNSS systems - sometimes - use different center
frequencies. This sometimes applies even inside the same GNSS system,
like GPS(CDMA) L3 and L5, which both reside inside the L5 band. ;-)
Bernd
Bernd Rose
Sep 20, 2023, 3:04:33 PM9/20/23
to
Following myself up:
>> <https://www.ardusimple.de/product/simplertk2blite-bt-case-kit/>
[...]
RTK2B receiver (GNSS chipset: ublox F9P) against the ArduSimple RTK3B
receiver (GNSS chipset: Septentrio Mosaic X5).
As is expected, connecting these receivers to an external survey grade
antenna provides significantly better reception than attaching a small
helical one (= average "sub 3 to 5 m" vs. "submeter" for the RTK2B under
typical forest conditions with moderate canopy). All following information
refers to a combination of the GNSS device with this antenna:
https://www.ardusimple.com/product/calibrated-survey-gnss-quadband-antenna-ip67
I tested the devices concurrently attached to the same antenna using a
GNSS antenna splitter and confirmed the results by connecting both
devices (independently) one after another without splitter.
NTRIP Correction data was applied from SAPOS Brandenburg VRS_3_4G_BB.
With optimal signal reception both devices reach status RTK fixed with
maximum deviation of the (known) real position of less than 10 cm in
seconds, when the devices were "warmed up" and had full almanach data.
In situations with only a small area of clear sky (about 90° horizontally
west and 20° to 60° degree vertically) and a complete block of GNSS
reception in all other directions, the RTK3B performed better. It was
able to reach RTK fixed after a couple of minutes and deviated less
than 2 m from known real position during RTK float state. The RTK2B
did not reach RTK fixed and deviated around 5 m on average from real
position. Because both devices used the same antenna signals, the
differences will result mostly from the higher number of GNSS signal
bands of the RTK3B. Chipset sensitivity and differences in firmware
algorithm may also play a role. Multipath signals from "invisible"
satellites have been +/- static in this setup. Therefore, both GNSS
chipsets should have been able to easily identify and filter them out.
Under heavy tree canopy the positioning quality of both receivers was
reversed. The RTK2B reached RTK fixed in few minutes. Starting from
DGNSS, followed by RTK float the position shown deviated only a few
meters from the (known) real position and fluctuated mostly in very
smalls steps. RTK fixed position was "submeter" in every single test.
(10 different forest points with different tree coverage, terrain,
and sometimes nearby bulky tree stems to block part of the reception
hemisphere. Repetitions on different days and weather conditions.)
Gusts of wind resulted in a bit higher position fluctuation during
RTK float state and sometimes loss of RTK fixed.
The RTK3B device failed to reach RTK fixed on several points with
moderate to heavy tree coverage, especially when wind was not fully
calm. RTK float was jumpy on the merest change of wind and showed
rapid positional changes around 5 to 10 meters on average and more
than 15 meters quite often. Wait time for RTK fixed was half an hour.
(If not acquired earlier.)
I contacted Septentrio to get configuration advice for using their
Mosaic X5 chipset in forest conditions. Unfortunately, they declined.
To eliminate unsuited NTRIP correction data for the frequencies not
supported by the ublox F9P I configured the Mosaic X5 to use only the
frequencies used by the F9P. This had no effect on the bad performance
of the RTK3B in forests. I also tried to enable "Smoothing". This did
not improve positioning, either. (I did hope, smoothing would result
in less extreme positioning jumps. But it did not.)
;--------------
To sum up:
The RTK2B receiver using the ublox F9P chipset showed excellent performance
under forest conditions, when connected to a good GNSS multiband antenna.
(As did other F9P based devices I tested during the last years.)
The RTK3B receiver using the Septentrio Mosaic X5 excels in clear sky
environments (construction sites and the like), especially when part of
the sky is completely blocked.
If I should guess, the differences result mostly from multipath handling.
The ublox F9P seems to have superior handling of very dynamic multipath
situations, like wind-moved leaves and branches under moderate to heavy
tree canopy. The Septentrio Mosaic X5 profits from the higher number of
supported GNSS frequency bands during bad (used) satellite geometries,
as long as any multipath is more or less static.
Maybe, this information is useful to other GNSS users.
Bernd
>> <https://www.ardusimple.de/product/simplertk2blite-bt-case-kit/>
[...]
> I'll have to dig a bit deeper. But especially the triple band Septentrio
> Mosaic-X5 receiver seems worth testing even from a semi-professional basis.
During the last couple of weeks I did some tests comparing the ArduSimple
> Mosaic-X5 receiver seems worth testing even from a semi-professional basis.
RTK2B receiver (GNSS chipset: ublox F9P) against the ArduSimple RTK3B
receiver (GNSS chipset: Septentrio Mosaic X5).
As is expected, connecting these receivers to an external survey grade
antenna provides significantly better reception than attaching a small
helical one (= average "sub 3 to 5 m" vs. "submeter" for the RTK2B under
typical forest conditions with moderate canopy). All following information
refers to a combination of the GNSS device with this antenna:
https://www.ardusimple.com/product/calibrated-survey-gnss-quadband-antenna-ip67
I tested the devices concurrently attached to the same antenna using a
GNSS antenna splitter and confirmed the results by connecting both
devices (independently) one after another without splitter.
NTRIP Correction data was applied from SAPOS Brandenburg VRS_3_4G_BB.
With optimal signal reception both devices reach status RTK fixed with
maximum deviation of the (known) real position of less than 10 cm in
seconds, when the devices were "warmed up" and had full almanach data.
In situations with only a small area of clear sky (about 90° horizontally
west and 20° to 60° degree vertically) and a complete block of GNSS
reception in all other directions, the RTK3B performed better. It was
able to reach RTK fixed after a couple of minutes and deviated less
than 2 m from known real position during RTK float state. The RTK2B
did not reach RTK fixed and deviated around 5 m on average from real
position. Because both devices used the same antenna signals, the
differences will result mostly from the higher number of GNSS signal
bands of the RTK3B. Chipset sensitivity and differences in firmware
algorithm may also play a role. Multipath signals from "invisible"
satellites have been +/- static in this setup. Therefore, both GNSS
chipsets should have been able to easily identify and filter them out.
Under heavy tree canopy the positioning quality of both receivers was
reversed. The RTK2B reached RTK fixed in few minutes. Starting from
DGNSS, followed by RTK float the position shown deviated only a few
meters from the (known) real position and fluctuated mostly in very
smalls steps. RTK fixed position was "submeter" in every single test.
(10 different forest points with different tree coverage, terrain,
and sometimes nearby bulky tree stems to block part of the reception
hemisphere. Repetitions on different days and weather conditions.)
Gusts of wind resulted in a bit higher position fluctuation during
RTK float state and sometimes loss of RTK fixed.
The RTK3B device failed to reach RTK fixed on several points with
moderate to heavy tree coverage, especially when wind was not fully
calm. RTK float was jumpy on the merest change of wind and showed
rapid positional changes around 5 to 10 meters on average and more
than 15 meters quite often. Wait time for RTK fixed was half an hour.
(If not acquired earlier.)
I contacted Septentrio to get configuration advice for using their
Mosaic X5 chipset in forest conditions. Unfortunately, they declined.
To eliminate unsuited NTRIP correction data for the frequencies not
supported by the ublox F9P I configured the Mosaic X5 to use only the
frequencies used by the F9P. This had no effect on the bad performance
of the RTK3B in forests. I also tried to enable "Smoothing". This did
not improve positioning, either. (I did hope, smoothing would result
in less extreme positioning jumps. But it did not.)
;--------------
To sum up:
The RTK2B receiver using the ublox F9P chipset showed excellent performance
under forest conditions, when connected to a good GNSS multiband antenna.
(As did other F9P based devices I tested during the last years.)
The RTK3B receiver using the Septentrio Mosaic X5 excels in clear sky
environments (construction sites and the like), especially when part of
the sky is completely blocked.
If I should guess, the differences result mostly from multipath handling.
The ublox F9P seems to have superior handling of very dynamic multipath
situations, like wind-moved leaves and branches under moderate to heavy
tree canopy. The Septentrio Mosaic X5 profits from the higher number of
supported GNSS frequency bands during bad (used) satellite geometries,
as long as any multipath is more or less static.
Maybe, this information is useful to other GNSS users.
Bernd
Alan Browne
Sep 20, 2023, 7:37:11 PM9/20/23
to
--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.
0 new messages