Review of project workflow

Reach RS3 RTK / PPK configuration
1

I have been given the task of carrying out a project of recording motions of large ships. This is quite a way outside of my comfort zone so I would appreciate if someone could review my workflow and let me know if there are any flaws.

  • A single Reach RS3 will be set up as a base station to provide correction over LoRa. The position will initially be estimated by the receiver, and in subsequent surveys this position will be input manually as absolute accurcay is not important. Relative accuracy is important and should be accurate within a few cm. The base station may not have access to wifi.
  • 3 additional Reach RS3’s will be set up as rovers and use the base stations corrections over LoRa as input. They will be set up within a couple hundred metres of eachother and within a km of the base station. The rovers will not have access to wifi.
  • The 3 rovers will be set to being logging data. The data will need to include position (lon/lat or x/y position in local coordinates) and elevation, all with a few cm accuracy and a frequency of 1Hz or greater. The logging will need to be continous for multiple hours at a time
  • The data will then be extracted to a laptop as some sort of ASCII file.

Questions:

  • How is the data stored/exported on the Reach RS3? Can data logs be stored to external memory devices such as SD cards/USB’s?
  • How large is the internal memory of the Reach RS3, how long could you continuously log data for before the memory ran out.
  • I have seen that before you begin logging data you need to enter the height to the bottom of the receiver. What is the reason for this? Is the receiver not able to tell its own altitude?

I appreciate anyone who takes the time to have a look through this and can provide any advice or suggestions

1 Like
2

Hi Jarrod

Sounds like an interesting project.

Could you give a bit more detail as to what your expected output would be? What are you trying to work out for the vessels? Is it plotting position over time or more in depth real time data analysis? Is the PPK workflow preferred and how often will you retrieve the data?

The reach units can log for hours without much hassle. For detail, a recent job with about 8 hours of logging 1hz gives a file around 150mb for final rinex 24O file. The battery should last about 20 hours but I’ve never let it run continuously for that length, I’ve had a few longer sessions on the same charge so they do last well. Testing is key, know what the unit does and what you can expect. You can run external power to them. The logs will split after 24hours, but you can split them in shorter files if you need. The 24 hours limit is mainly for uploading to post processing as the mix of GPS days is an issue there.

The RS2+ (3 likely the same) has an internal drive of 12gb. You can set it to delete older files so it doesn’t clog up. I’ve not seen a way to log externally so that might not be an option without setting up a direct feed out.

The antenna height is entered as you would normally setup on a tripod or a pole with an offset to the ground point. The emlid pole is 1.8m for example, so the points are reduced to 1.8m below the reference point of the reach. The reach has no way of knowing what you’ve attached it to. The logs are to the phase centre and then height reduced as per the offset.

You will need a higher rate logging for the distance and motion of the vessels, probably 5hz or more depending on how much motion there is. Also LoRa may be a bit weak for the 1km baseline you are planning. I would test that first to see how it goes, setup the base and take the rover for an ice cream. The caster service with a Sim in each rover would work or plug in an external radio for broadcast over a wider network. There is a guy in Australia (mangoesmapping) who was selling a radio pack so that setup will be available where you are but others will know more about that than me.

For outputs the log files will be rinex and UBX backup as a raw log. If you want corrections applied that will be a different setup altogether. Are you looking to have the fix position exported in a grid system or through as lat long? How much offline processing do you want (and prepared) to do? The reachs will only log raw rinex, any corrected and local grid position are applied in the flow app or similar. PPK workflows allow for the corrected positions to be calculated and depending on software the grids can be done then or after. With high rate data you will need to be careful with the conversations or imports to software. I tried importing high rate data for a vessel motion survey into flow and it didn’t upload to flow 360 very well.

It depends what your end goal is as to how you setup the array of reach units. Let us know a bit more detail and there will be good advice from everyone here.

From my side we work with vessels etc and online survey work offshore so there are always ways to get to the final answer you want.

A final point is to think about position of the reach on the vessels (I’m assuming they will be on the vessels). There is a lot of masking, multi path going on there. Also where these are placed with relation to the vessel shape. How are you going to orientate the vessel relative to the reach?

Cheers
Scott

1 Like
3

Hi Scott, thanks for the response.

The idea for the project is to strategically place 3 of these receivers on a large vessel (200+ m long) as it is moored. The receivers will log the raw position/elevation while the vessel is moored. The raw data from these 3 logs will then be combined and processed to find the Vessels observed motions in 6 degrees of freedom. As such the relative accuracy for position and elevation is very important and should ideally be within a few cm.

I’ve found in the documentation that the RS3 has 16gb internal memory, so if I scaled up your example of 150 Mb for 8hrs @ 1Hz this should be able to log for about 170 hours at a rate of 5Hz before running out of memory, provided it is plugged in to power?

So to be sure I understand about the pole height question, if I wanted to gather data at the actual elevation of the RS3 itself, I should input a pole height of 0?

What kind of range would LoRa be ideal for if 1Km is too far?

Could you elaborate more on the caster service? Is this still a base station/rover set up?

Ideally the data being logged to the RS3’s would already be corrected, but if this has to happen as a post processing step that is fine. I’m not too sure on how this process works, it would be great if you could provide a bit of a rundown on how corrections are recorded/applied.

As stated, the end goal is to be able to correct and process raw position/elevation data from mutliple RS3 units positioned on a vessel to get that vessels motions in 6 DoF. The processing from corrected position/elevation data will be handled by me, so no need for this to be a part of the Reach workflow. The recordings could run for multiple days so these log files could become quite large.

We have done similar projects before, typically we try to set up 1 receiver at the front of the ship, and the other 2 on either bridge wing. With these projects in the past though we have used clients DGPS receivers, and they handled the correction of the raw data, so this is my main area on uncertainty.

Jarrod

4

Hi Jarrod

My hunch was correct, its a vessel calibration workflow you are working out. Its an interesting problem to tackle.

For the pole height, yeah keep at 0 and that will reslolve to the RS3 itself and no offset point below. There may be a reason to add in a pole height, and that’s if you are using fixed nodes on the vessel (within the vessel reference frame) but that’s a much deeper point to address. But to log for just the unit itself, keep at 0.

LoRa… It depends. The spec listing is for 8km I think, but you’ll never get that out of them. They are pretty low power and require good clear conditions. Things like masts, radar, quayside buildings, expanses of water will affect the range and probably not consistently either.

The caster service is emlids own NTRIP corrections portal. You can setup base nodes and connect using mount points with the rovers and base unit. Their documentation is very good to explain it. All four units will need wifi or cell coverage to access the NTRIP portal.

That being said I think you can forget the RTK element. The logs will be raw even if you are sending and recieving corrections so it doesn’t matter. To make use of the corrections you would likely need to have data controllers with timed logging active. That is an extra headache to acheive the level of data you are looking for. Using the PPK workflow would work fine for you.

For PPK you can use emlid studio. You would need the base logs and the rover logs. There is a kinematic tab in the software which essentially processes a track file. The docs for studio can guide you through it very well. The group on here and Emlid support have always been good in my experience too with any issues or guidance. You would need to upload the base files (with derived position, when you establish that), rover file and a nav file. You would cycle the rovers, so run one process with base and R1 (fwd CL), then base and R2 (Aft Stbd) and finally base and R3 (Aft Port).

The PPK will give you three .pos text files. You can then take those as your corrected file, prepare it for import to a transformation software to your local grid. This is a bit of a challenge for you, unless you already have access to software for that obviously. The size of these files and the number of data points will likely need to be split. That goes for processing as well, if you split the log files to chunks it will make the process easier. As I said I tried to take a similar set of data into flow 360 to convert and it crashed badly. That was 2hr of 1hz logging for one node of an identical workflow to yours. I ended up having to parse the PPK to 10secs or so to make the files small enough for that upload. There are converters out there to do the job. Eiva GeoCalc does a decent job but is limited with things. I have a spreadsheet butchered from the OS here in the UK. How much data do you need for the task? We usually conclude these types of surveys with a few hours of data. Mainly as clients get cold sweats at the thought of a surveyor getting money out of them. Ideally you would get a good solid log to see any trending behaviour in gyros and MRUs.

This type of job is the main thing we do, except using total stations from the quayside. The RTK approach is there but has always been expensive to use. But with the emlids that has changed a lot. Being able to throw 4 reaches out for less than one trimble or leica is great for this type of work. Also the software to process is free, and with a bit of python knowledge it could be streamlined a fair bit further.

To go deeper into things. Are you worried about the relative positions and misalignments of reach units on the vessel? Ie if you want to calculate heading you will need to apply the relative heading of the units within the vessel shape to offset that bias? Also the heights of the RS3 relative to each other can introduce issues. A GNSS heading system like seapaths can go wild if the GNSS antenna are placed at different heights. Any roll (port starboard movement) throws in a heading artifact into your data.

You will notice a huge difference between the local base rover PPK data and the DGPS you have used before. The corrections being used there are pretty basic so you will see much nicer trends with this setup. On that. If you are using the setup to compare position of the vessel itself, DGNSS health check then be aware of where your base position has been processed. The veripos and marinestar corrections, which are the most common for maritime are ITRF, so be careful if you process the base location to a local TRF such as NAD83 or ETRS89. That only works for health check, if you are only looking at motion then it doesn’t matter at all. You will only need the correct convergence to be applied for the heading calculations.

Out of curiosity, what will you do with the data and results? Will they be applied to the onboard systems, as mounting angles?

Thanks, apologies if it seems like a ramble. I’d be interested to see how you go, my tests for the same things have been very good so far.

Cheers
Scott

5

Hi Scott,

Understood, seems like PPK will be the way to go. Could you please explain what a nav file is and what I need to do to produce one? Should it come from the base or the rover or does it not matter?

I think there is a slight misunderstanding here. Once i have the corrected .pos files we will run the transformation ourselves with code that we have written to get the vessel motions. So we will be able to work around any issues with reading in large data files. By the sounds of things the clients may want data to be continously logging for days at a time.

I’m not sure what you mean about relative positions and misalignments of the reach units. I will be calculating the vessels yaw along with the other motions from the corrected position data. The absolute value of heading doesn’t matter, and the heading being recorded by individual reach units also does not matter. The only necessary information is the corrected position and elevation data.

Yes, I’m only interested in vessel motion and not absolute vessel position, do I need to worry about carrying out these health checks? Also, Does the location I give for my base station need to be incredibly accurate or can I get away with something within ~10m?

The results will be used for validation purposes. My company develops software that ports use which can predict vessel motions due to waves, wind, currents and tide, either while moored or while in transit. The weather predictions are also developed in house using our companies MetOcean forecasting tools. These recordings will be compared to our softwares results, giving ourselves data sets that we can calibrate off of if need be.

No need to apologise, I appreciate you taking the time to step me through this, happy to talk about it more :slight_smile:

Jarrod

6

Hi Jarrod

This project is getting even more interesting. Sounds like a pretty cool setup to use. Emlid may like to ask you some questions about the use case for their own benefit.

The nav file is auto generated. When you download the data it will be in a zip file. That will contain three files: a 24O, 24P and a 24B. 24 as that is the year. The O file is observation data and the P is your nav file. It doesn’t matter which you use (base or rover), I would suggest using the base, mainly as you will cycle the rover files which means one less file to change during processing, you can load the base and base nav and then cycle the rover 240 files for each batch.

If you have the software to do the import and calcs then great. Normally the transformation to grid is a step which stumps people.

I was meaning the reach positions within the vessel shape. If you have a bit of roll or pitch on the vessels through bunkering or ballast it will show up in the data gathered by the reach. Also knowing what zero is for those motions as a starting point. But that was for checking the vessel itself which is not your aim. Likewise for the GNSS health check. That is purely as a check on the vessel system which is not your aim at all.

The base location can be anywhere then. You could do a log session prior to things getting started and use the result as the fixed position from there. The 24O file can be uploaded to a PPP service and you get a pdf file back with the result. That is more than enough for what you require. At least then your starting point is the same as an averaged fix for the base would introduce elevation changes, no use for tide predictions. Do you have a way to reduce data to a tide guage at the site?

Having used predicted data offshore for years it is interesting to find out more about the process behind it all.

Cheers
Scott

7

Hi Scott,

Thanks for explaining that. So just to make sure, none of my reach units will need a sim card or wifi connection? All the corrections can be applied after the fact once I have exported the raw log files?

On that note, how do I actually go about getting the log files off of the reach units. Will I need to take them somewhere that DOES have an internet connection so I can download them?

Could you pleas explain what you mean when you say ‘transformation to the grid’. I’m not quite sure what the grid is that you are referering to. The raw position data will be transformed to vessle motions (roll, pitch, yaw etc)

I’m not sure I follow your statement ‘At least then your starting point is the same as an averaged fix for the base would introduce elevation changes, no use for tide predictions. Do you have a way to reduce data to a tide guage at the site?’ Could you please elaborate on this?

Jarrod

8

Hi Jarrod

No, I think you would be best served using the PPK workflow. There is no need to add in additional sims to get cell coverage for corrections if all the processing is being done in post. Emlid studio works very well for short baseline stuff.

As for getting data off the reach RS3. They all have their own wifi so you can connect to them and retrieve the data. I would think using a laptop and going through the IP address on a browser will be the best to take large sets of data off them. It does work on phones through the app and that can go direct to google drive, one drive etc. You would need to think about how frequently you can visit to get the data, if you will be checking on them during the logs and pulling batches off each time. That’s up to you, but I would get the RS3 logging data as a trial and get comfortable accessing the data, setting logs and making sure you are happy with using them. For short logs I would normally upload to google using my phone, which I use to set them up anyway. But for longer log sessions I’ll use the laptop for download. All of this is through the reach local wifi, its easy to use and this video shows the process..

Transformation. The output you will get is either lat long (decimal degree) with ellipsoidal heights (metres) or ECEF XYZ (earth centred cartesian in metres). Is that ok for you? They will not be in any state plane or UTM coordinate system. As long as your software is happy with one of those coordinate types then you are fine. Example .pos file (lat long el):

image
image2342×824 73.5 KB

The base location should be fixed from the start of your processing. If you use different base positions, for instance if you start processing the batch before uploading the base files for PPP position then the elevation can and will be different by a margin. I don’t know how you intend on running the processing and set up / trials but I would suggest logging the base location and deriving that as part of the prep work. This position is used as fixed from then on, everything is relative to one fixed location from start to finish.

Are you using the data for assessing the predicted tides? If so, would you need to resolve the difference between ellipsoidal height / ECEF and MSL or whatever tide benchmark you are using for the predicted tide data?

Cheers
Scott

1 Like
9

Hi Scott,

Understood, will definitely be getting my hands dirty and having a trial of everything before beginning the project. Do you have an idea of the download speed for getting data off the reach onto a laptop by any chance?

Yes any projection that the data comes in we should be able to handle just fine. Roger, physical location and the location entered into the software for the base station will be fixed after it has been determined initially.

No we won’t be assessing the predicted tides, only vessel motions in this project.

Thank you for all of your help Scott, I think the way forward seems clear enough now, happy to chat and field any more curiosities you may have about the project :slight_smile:

Cheers,
Jarrod

1 Like
11

Hi @jarrodh0110,

Welcome to our Community Forum.

I noticed that @scottmitchell63 added some valuable comments regarding your questions. I wanted to thank both of you for the insightful conversation and for sharing your knowledge.

Do you have an idea of the download speed for getting data off the reach onto a laptop by any chance?

For this cases you can access the Reach Panel of your RS3 via an internet browser and there downloading the logs directly to your laptop.

1 Like