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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-06-21 20:38, Reinhard Zwirner wrote:

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.

This group died a long time ago, alas.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

You don't need a mobile phone for the data link, OTOH "in the
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 ...

Good luck. Dual f is a special use case and not usually justifiable in consumer level goods.

Why do you want a dual f receiver to begin with?


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Regards

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

That's akin to how I've mapped some local trails by walking them in the
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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 bureaus offer SAPOS RTCM NTRIP correction data via mobile communication for free (Open Data initiative).

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

Hello Bernd,

Many thanks for all your really helpful comments.

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?

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Configuration is done via Web interface. So no costs involved, here. And
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.

Doesn't matter, anyway. AFAIK, this device is only sold bundled with a
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, October 3, 2021 at 2:00:40 PM UTC-5, Bernd Rose wrote:

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

Configuration is done via Web interface. So no costs involved, here. And 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.

Doesn't matter, anyway. AFAIK, this device is only sold bundled with a 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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!

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.

I'll be using the TX/RX lines. (My code is all written and tested -
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.

Yeah. Not a fan, alas. I've had and sold at least 2 Garmin map display 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.

--
"Mr Speaker, I withdraw my statement that half the cabinet are asses -
half the cabinet are not asses."
-Benjamin Disraeli

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ga...@learn.bio schrieb:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Have a look at Teqc:

https://www.unavco.org/software/data-processing/teqc/teqc.html

HTH.
Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

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

Aren't you comparing apples and oranges?

ublox c099-f9p eval board: 250 €
Stonex S580: 3800 €

Scratching his head

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

O Mon, 25 Jul 2022 02:50:26 +0200, Reinhard Zwirner wrote:

Bernd Rose schrieb:

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

Aren't you comparing apples and oranges?

ublox c099-f9p eval board: 250 �
Stonex S580: 3800 �

In this thread I wrote last year (and cited above, yesterday):

| I wasn't able to test the S580, yet.

The purpose of my post was delivering the missing information, not comparing
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 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Reinhard Zwirner schrieb:

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,

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:

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

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-16 16:28, Reinhard Zwirner wrote:

Bernd Rose schrieb:

On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:

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

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

Oddly enough my SO is learning German. I'll get her right on it!

(Or let Google Chrome translate). I can read some German, just not
enough to be sure ...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-16 16:17, Bernd Rose wrote:

On Thu, 16 Mar 2023 19:37:50 +0100, Reinhard Zwirner wrote:

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

I was puzzled too ...

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

HTH

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

You can find the description in English here:

<https://www.ardusimple.com/product/simplertk2blite-bt-case-kit/>

I did eventually find exactly that. I'll circle back in the fall when
I'll be re-launching a particular project.

Cheers,

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 16 Mar 2023 21:28:15 +0100, Reinhard Zwirner wrote:

[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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

On Thu, 16 Mar 2023 21:28:15 +0100, Reinhard Zwirner wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

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?

[...]

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 18 Mar 2023 14:58:01 +0100, Reinhard Zwirner wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

Each analog-digital converter for GNSS provides a statistical distribution
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose wrote:

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

Each analog-digital converter for GNSS provides a statistical distribution 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... ;-)

Please don't take this the wrong way, I know and understand that both of
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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bernd Rose schrieb:

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

Each analog-digital converter for GNSS provides a statistical distribution 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.

Hi Bernd,

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.

Maybe I'm misunderstanding you, but only for broadcasting mono FM
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... ;-)

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 ;-)?

Best regards and thanks again for your help

Reinhard

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

[...]

With a radio, the user accounts for any frequency drift by fine-tuning to
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:
| 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
peaks (BOC - Binary Offset Carrier) that have a defined distance from
their related center frequency and therefore /could/ be considered
separate frequencies... ;-)

Bernd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Following myself up:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-09-20 15:04, Bernd Rose wrote:

Following myself up:

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

Thanks - I will circle back and read this soon.

--
“Markets can remain irrational longer than your can remain solvent.”
- John Maynard Keynes.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)