RINEX for post-processing the position of a buoy in the ocean

[gauteh]

Hi,

I initially started out wondering how to set up RTK for a wave buoy close to the shore for measuring huge waves (accuracy preferably on 2-3 cm). But I think transmitting the RTK data from the base station is going to be a challenge. I don't really need the precise positioning at the time, so I started looking into post-processing the data. Would this project be useful in this? I also looked at RTKlib for post-processing, but I am pretty confused about all that is going on.

I am wondering whether I can put a GPS on the buoy, like the ZED-F9P (https://www.sparkfun.com/products/15136) and (if possible) capture the raw output from it (in RINEX?) and store it on a SD-card or transmit it home using the cellular network? It is a fair chance that the buoy may be lost in the ocean. Would that work? And would I need a base-station on land to also log the data? Could I use the same receiver to do that?

It depends a bit on the data-size as well. I suspect I won't be able to send everything home, but at least store it on SD-card for recovery.

The buoy is open-source: https://github.com/gauteh/sfy and has a cellular modem for transmitting data and position home.

Thank you,
Gaute

[gwbres]

Hello, great topic !

But I think transmitting the RTK data from the base station is going to be a challenge

It all depends on how close to the shore and what your RTCM transmitters are capable of (depends on the type of link you can use).
Personnaly, I am still unfamiliar with RTCM because I'm just about to get started with RTK. Once I finish conluding the ongoing topics, the next topic is to unlock a new rtkpost option for post processed RTK in rinex-cli. You only need RTCM for real time RTK

I don't really need the precise positioning at the time, so I started looking into post-processing the data.

Sounds good, and IMO is best to prototype your ideas and setup. But you need to be able to provide the required input. Post processing is made with RINEX and SP3 files (classical input)

Would this project be useful in this? I also looked at RTKlib for post-processing, but I am pretty confused about all that is going on.

First off, rtklib is a great software, and my toolkit originally did not cover positioning until 10 months ago.
I would say rtklib has the advantage of being stabilized and performant, while we are about to support true PPP, it is not completely accurate as of now. To be accurate, we have SPP and CPP tested in static surveying fashion, which exhibit similar results after 10+ hours of surveying. The disadvantage of RTKlib is the complexity of the toolkit: many tools to become familiar with, bugs exist and some operations may not be feasible or work properly. Configuration files are very complex while ours are and will remain simple. Finally, rtklib core is no longer maintained, the demo5 rtkexplorer fork maintains the topic alive, its maintainer tweaked and patched the original rtklib software, but the fundamental part has not evolved for about 10 years

I am wondering whether I can put a GPS on the buoy, like the ZED-F9P and (if possible) capture the raw output from it (in RINEX?)

Yes, especially considering that post processed positioning is most likely your only option to prototype the setup.
You have several solutions to achieve that. Our GNSS/Rust ecosystem does not have a solution to format Ublox to RINEX right now, it is a pending topic not made publicly available yet. I am working on it since I am about to start working on real time navigation and post processed rtk

I need a base-station on land to also log the data? Could I use the same receiver to do that?

This solely depends on your application and how robust you want it to be

and store it on a SD-card or transmit it home using the cellular network?

When sharing stuff over a network, especially replicated sensors, I would advice using MQTT mailboxes, which were designed for this very reason, allow server backups and information storage and have proved very powerful

The buoy is open-source: https://github.com/gauteh/sfy and has a cellular modem for transmitting data and position home.

Thank you for pointing that out, I will forward it to some friends of mine and will keep an eye on your project

[gauteh]

Thank you. So RTK post processing is not the same as PPP? The latter does not need a base station?

I am still pretty confused about all the different topics here.

[gauteh]

Great. So PPP would (together with atmospheric data and some other correction data provided a couple of weeks later) give good positioning down to a 1-3 cm? Would it support the frequency of the receiver (10-20 Hz)?

Do you have any idea how much data it requires to store on the receiver side for e.g 10 Hz per hour?

[gauteh]

By the way this buoy is continuously moving with the waves.

[gwbres]

Great. So PPP would (together with atmospheric data and some other correction data provided a couple of weeks later) give good positioning down to a 1-3 cm?

Yes. The accuracy you get in the PPP solution solely depends on the quality of your input.
Usually, for best PPP results (on par with RTK), we use so called "final" SP3 orbital files, that are only available 3 weeks after any point in time. That means you can only post process, and have to wait for that publication.

We currently do not have an example comparison of SP3 products, I simply always download the "final" products, but we should definitely have an example comparison in the future. See the reference examples that will soon be merged.

By the way this buoy is continuously moving with the waves.

Yeah of course.

All positioning techniques are compatible with moving targets, so called roaming applications.
Roaming simply involves a slight different configuration of the solver, compared to static positioning.
Your usecase falls in roaming application, with a profile close to pedestrian I would say.
We will propose several profile for easy setup in the future: we have only tested static positioning so far (see the example database).

It is normal to have poorer results in kinematic mode compared to static mode (let say 10cm limitation), but not in orders of magnitude that would prevail from detecting a new wave (about 1m).

Would it support the frequency of the receiver (10-20 Hz)?

not sure what you mean by that. Is that the production rate of the solutions ?
the solver production rate is dictated by the signal sampling rate

[gauteh]

Thanks a lot. This seems very interesting! I need to get a device that can produce the raw output.. it doesn't even seem to need to be an expensive one? I think the e.g. UBLOX MAX-M10S can produce these data (if this project can read them..?). As long as these data are not too big, I have to either store them on a SD-card or send them home with cellular (unlikely with the current solution), it should work.

10 cm accuracy is not enough for small waves, but then the buoy will move less. For the big ones that I hope to use this for, it's going to be more than enough! Is RTK better for moving objects?

[gwbres]

I need to get a device that can produce the raw output..

Any receiver for which you have that plugin will do. Ublox has the benefit to be widespread, work well and well documented.
I hope to make that function availlable soon (for ublox devices).

Is RTK better for moving objects?

yes, RTK always performs better and more easily (if you don't consider the "technical difficulties")

[gwbres]

Hello @gauteh,

FIY, I have initiated all of these major topics. Major but much simpler than our past objectives (like the PPP solver).
So I hope to obtain results very soon.

• This branch will introduce the RTK positioning technique to the navigation solver
• A new RTK mode is tied to it and adds the possibility to deploy the RTK solver from rinex-cli application. RINEX-Cli is dedicated to post processed navigation (as opposed to real time navigation). It basically works from files.
  It is 100% equivalent of the RTK post opmode of rtklib. You have to provide two sets of file as input
• I initiated a new RT-NAVI application, this one being dedicated to real time navigation.
  Therefore it requires hardware interfaces rather than text files. It will support Ublox receivers first, and we may have other options in the future. Exactly the same, it will have both ppp and rtk navigation options. For RTK, we will be agnostic of the medium and connection method

[gauteh]

We will try out offline methods first, I think offline-rtk works best close to shore, but ppp will be better offshore.

[gwbres]

Wow! Great! We are planning to do some experiments with this in august for measuring waves. We are still in holiday mode, but I think the activity will pick up soon. We will for sure keep you involved if you are interested.

awesome ! what kind of data will your experiments generate ? (File formats.. binary ?), I'd be interested if we could load some of it into one of our tools

I think offline-rtk works best close to shore, but ppp will be better offshore.

Indeed RTK is your best option when you're close to shore. I am not familiar enough with RTK to understand the limitation, it is said to work well bellow < 20km, and some conditions may increase that to < 100km (from reference station).
I'm not sure what you mean by offline rtk, because rtk requires information from the base station of very single solution.
Do you mean post processed RTK ? recording your data and post processing it afterwards

[gauteh]

Yes, exactly: post processing rtk. It will be maybe a few km for rtk. I was thinking of getting a ublox zoe from sparkfun, and using it as both base and rover for rtk. Would that be suitable data for this? Any recommendations?

[gwbres]

For sure! the Ublox F9P is a great device.
centipede.fr is an outstanding source of information for RTK navigation, they have tutorials to build both the reference and the rover, and they use the F9P receiver.
Unfortunately, it seems to only be redacted in french, you can probably use a language translator, or look at the schematics

[gauteh]

Great! Thanks. Maybe one of the cheaper ones also work if I dont need to do rtk processing onboard? I think maybe we'll test with the F9P first anyway.