Date/Time from export files

Reach Module / M+ / M2 RTK / PPK configuration
1

Hello ReachRS people.

Just wondering if there is anyone out there who thinks having date/time exported as attribute of shapefile would be a might fine thing. May be that data is there in the DXF, but I cant see/find it. Its not in the GeoJSON file.
will request if others think useful (may be Im kind of requesting it right now???)
Apologies if this has come up before.

Cheers

2 Likes
2

Perhaps I put this in the wrong place or tagged incorrectly or used the incorrect key words.
Surely time stamp on each point taken would be useful?

3

This is a good idea and we will add time of collection as one of the point attributes.

4

Hi Igor,

Thats great! Wish I had that capability right now!
I’m trying to ppk my data (mostly unsuccessfully; collected in the filed with base over an unknown point) then figure out which “raw” data relates to the Point collected at a particular location.
When I get a chance I will post some info about how we have been putting the Emlid Reach to use in bathymetric surveys!

Cheers

5

Sounds amazing, please do!

6

Sure! need to learn how to ppk properly first so the data makes sense!

7

Small tip is to survey (reachview survey mode) as usual even if you only get float/singel and save log.
And overlay survey points on PPK track. And use extra time over each point to make it clear that this is where you surveyd.

8

Thanks TB. I will have a crack at that once I get PPK work down. I keep going round in circles trying to get fixes, but most importantly heights that make sense - even when I have a fix (Q==1) the ellipsoidal heights are ~10 m out from what they should be on control points. This may need a new thread, please advise, but have uploaded some beach profile data here: Dropbox - File Deleted

The settings/process I’m using, which is from this forum or other Emlid sources of info, is giving heights of ~29 m, should be 19 or 20 (have disposed of decimal accuracy for the time being!!!). I do a lot of surveying, nearly always with base over known, well established geodetic mark, and run in real time (UHF etc.). Thought I would give this method a crack :face_with_raised_eyebrow:

9

Have you applied offset value to base? and known coordinated for base as well? and what are the coordintes for the known base?
When i run average base i get 12.2m ish and with rinex header i get 26m (ellipsoide height).

10

Hi TB,

  • No offset applied.
  • No known coordinates this time round - my understanding was that with sufficient data (>1 hour) a fix on the base is good enough for PPK. I let the base collect data for about 4 minutes to get a single solution to run from.

The base was on a 3 storey building (9-10m), the ellipsoidal height of the ground outside the building would have an ellipsoidal height close to 17 m, so that adds up for the base ellipsoidal height, but I don’t see why the rover positions would be so high when I was walking around at ground level…

Thanks for your help! May be I will stick to real time solutions from now on!

11

Ok, no absolute coordinates involved here. When i process base with average and use 9m offset for base and set 2m offset at rover (i assume you used a pole and not placing the device on the ground?)
I get an average ellipsode height on the ground of 19,22m.
But that is average. I assume the bottom measure done in the plot is the bottom surface, and by subtracting given value of about 1,8m i end up at 17,42m (ellipsoid height). Does that sound right?
Bare in mind, this is all based on give values and a average of base.

atk1
atk1.png1117Ă—551 39.9 KB

12

Hi TB,

I have Post processed the base data first with the NZ equivalent of a cors station. Got a proper lock for the base, then PPK’d the rover data. Heights and positions are good for 77% of data.
Just working on the rest now trying different elevation masks etc, just posted another questiosn though:

Wonder if it will get me the last 23% of pints to fix!

13

We also in need of matching collected points with PPK too. So time stamps on each survey point will be very useful. Will this improvement be seen in next release?

14

@l3technologycambodia We are working on improving the survey features. It will not be the next release, but soon new surveying features will start to surface.

1 Like
15

Thank you for your response. I can’t wait to see improved survey tool.

  • From your programming perspective, is it complicated to include one more column in the expoeted shapefile with the time stamp?
  • People have talked about cycle slip and re-initialization to ensure cm accuracy for collected point. Tool such as ezfield from onpoz was developed for L1-only data collection. Is this feature needed from ReachView? If yes, will we see this feature in ReachView app anytime soon?

Thank you.

16

Nope, but only doing this isn’t much of an improvement.

If I understood your question correctly, this has long been incorporated in the RTK engine.

17

That’s great to hear that cycle slip was incorporated in existing RTK engine. We strongly hope to see the following capabilities in the improved survey feature:

  • The ability to collect points, lines (including tracking), and polygons objects in UTM XYZ coordinates.
  • The ability to design attribute columns for points, lines, and polygons to be collected.
  • The ability to match the collected points with PPK processing for better Fix changes.
    So far, your team has done very well with Reach RS and we hope to see you design ready-for-field L1/L2 affordable devices.

Thank you

1 Like
18

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.