Hello everybody. I’m loving my RS2 set, great work using RTK, CORS, etc. But still losing somethings like network adjustment and other project manipulations. Is there any way to get the ROVER UBX or RINEX and split it in the static occupations as well the cinematic sections, that I made using the rover? Any idea or suggestion? thanks in advance
1 Like
Thank you for your kind words🙂
RINEX and UBX are simply the file in which satellite data is recorded. They don’t depend on the mode in which you do your survey, static or kinematic. Could you share why you would like to split logs?
You can also tell us in more detail about the issue with the network or project manipulations. I’d suggest you send an email to support@emlid.com if it includes sensitive information.
2 Likes
Basically I’m doing stop and go. Using Emlid Studio its a breeze but I’m a Leica infinity user as well other gnss post processing tools. When I use them I cannot enter with the converted Rinex that has mixed cinematic and static. So I need to export the time lapse of the occupation one using the occupation period from the reachview. Here Ill enumerate some issues doing this:
1 - Time consuming even with few ocupations
2 - The Rinex has the header position the same for all, not a big issu but need to preprocess to preview the aproximate position of the occupation.
3 - Reach view max ocupation time is so short, and Z precision demands higher times than the 5min.
These are the most significant ones. Also still existing another issues with Emlid Studio that is a great tool ( well rtklib adaptation basically).
Making test in a well known area and also comparing with a traditional survey, total station, I noticed very remarkable difference in Studio vs Leica results giving a significant advantage ( precision to leica tool). Im short words in my test having 6 stop and go points collected using reachview 5 min occupation I only got fix of 5. Using leica all where fix, and the results slightly different but for my use significant, verified by my traditional survey. The same data processed by leica matched ( with the respective tolerances) the total station survey and the results from studio had significant error.
After that I made other survey to test that precision using geodesic marks and longer ocuppations where I created separated logs leica post processed and results where impressive.
So basically Im completely amazed with RS2 quality but the post processing still an issue, I understand that develop a full postprocessing tool is a big investment and long development road but make small tools to make RS2 data more easy compatible with processing packages helps. Believe me I have Leica units and feel very confortable with the RS2 by it simplicity. So a good set of tools to convert its raw data to more compatible formats until a post-processing software matures or even if not because it can be part of emlid strategy will made RS2 bright as its deserves. Sorry for any errors in my writing, im doing it while driving (not me) to a survey job with my RS2 and traditional survey tools. I’m willing to share all my data and experience with anyone in the community to we achieve this very simple needs. Bests regards G. Osinaldi
3 Likes
Remember that you can tweak the parameters of the underlying RTKLib processor that Emlid Studio utilizes. That might yield better results in some situations (or worse, if you overdo it, but that’s true for most applications anyhow).
May I suggest you also look into OnPoz EzSurv?
It has a small utility that combines the csv file from either ReachView 2 or 3 with the obs-file, and does the necessary processing quickly.
It also supports network adjustments if you have multiple observations per point or multiple bases.
2 Likes
Hi Guillermo,
If you mean the Averaging function in Survey mode, it is usually used to collect points in RTK. If the receiver has calculated a Fixed solution, it means that it has reached the centimeter-level accuracy. In this case, we recommend setting the Averaging time to about 40 seconds.
Since you use Stop&Go mode to post-process points, you know that you need to record raw data logs without separating them into static or kinematic and a CSV file with points in a single mode. It should work fine for Emlid Studio. I just add that 5 min to collect a point is usually more than enough to get centimeter accuracy after post-processing the data. You can also use a shorter point collection time. It usually depends on the conditions in which you work.
Working with a total station can indeed give you better results, especially if you mean working indoors. The receiver needs to obtain satellite signals to calculate centimeter-level coordinates. Tall buildings and foliage might block signals from satellites.
I got your point that such a separation would be convenient for processing in Leica Infinity. We are improving our products and add new features for our users. However, there’re also many other programs for post-processing that have their own requirements. That’s why creating conditions in which this would work for any software is quite a long and complex process. But I’ll definitely pass on your request to the team.
2 Likes
Thanks for your answer, we work outside we project roads. Even with the instrument precision being lower in the GPS case several human and environmental factors affect total station work, such as human handling, distances over high temperatures, yes even the most precise optic on a hot road suffers an amazing visual interference by the hot air masses over the surface and many other factors, so GPS when well utilized don’t go so far out in precision and a vital tool to support our work. Because this we are always experimenting and openminded to more options and combinations. Well, speaking about software and option to log separately occupations and or between kinematics is basic requirement in most of the post processing softwares, this feature will be largely appreciated if implemented to save time, in the meantime we are doing this by hand. Thanks again to everybody that is answering and bringing more ideas.
Are you sure that UBX and RINEX are not processed because the log is recorded during both static and kinematics? Probably this problem is not related to the mode in which you work but to something else. Have you run any other tests?
Yes, but all in the same RINEX. As well all occupations. To avoid this, I need to stop and start logging manually.
1 Like
You’ll likely get a more solid fix from running one long kinematic log, than many small static. Especially if conditions aren’t ideal.
As far as I know, that’s how it works. If you work in static, it’s your responsibility to enable logging when you start to measure a point and turn it off when you are finished. I haven’t met receivers that can recognize when you are moving or work in static and split raw data log in real-time.
I guess that’s what Stop&Go was invented for. You write all the data in the kinematic and CSV file with your points. Then, if post-processing software has Stop&Go mode, it can calculate solutions by the time in the CSV file when you measured the point (“static”). So, if the Leica Infinity software doesn’t allow you to process data in this mode, I’d ask them to do something like that 
.
As far as I know in 25 years working with gnss, I can give the name for the occupation and not been using a notebook or a note in my phone with the name and time of the occupation, My first novatel that was controlled by terminal using a data collector, my first magellan and we can go so far naming. I stopped by gave the location a name used a timer of HOURS or MINUTES and lets go to the other. No been taking time notes been watching . Lets be honest the RS2 is a great GPS but the main focus is RTK and PPK. And no GPS actually in these modes has a really high precision. So a better interface mode like the one used in reach 3 for static will be a must. And believe me I love this equipment and achieve really high precision with it, but as all existent GPS altitude precision using RTK still far from some engineering needs.
I can give you some suggestions to observe as interfaces like the old spectras 220, the magellans 3 and many others. Please need also to understand thst not all is RTK and PPK and CORS. Obviously if I can work in civilizated places only the tools thats emlid offers me are more than enough. But Emlid has a exelent hardware and we obtain exellet results in adverse conditions, where no GPRS, no line of sight, place where we go on a first survey fo static very long occupations to have our references, 2 to 3 per kilometer ( no I cannot do one every 4 km and play with rtk because are height markers and precision required together legislation in road projects doesn’t allow me to do) . After that I can do RTK to do sll the project trace etc. But can you inaginate doing 60 occupations of 1hr and been downloading renaming with my notebook help or export just the occupation times but the rinex header has the coordinates of the first position for all the exported occupations(or last I don’t remember but don’t give me a approximate coordinate for the occupation in that time frame) . So I inititiate TBC or Leica infinity visual with one point for my base and 60 piled points (occupations in the same place) , enter by hand with the aproxímate occupation coordinates to have a preview od my project or run a pre process to have all adjusted . Its really time consuming.
I have some other equipments here and will perform the same operation in all to the colleagues that never used this kind of function. And this is before post processing is on collection. Remember also that Emlid doesn’t can be controlled by a collection software like Carlson, Fieldworks. Reachs are compatible sending the coordinates as an NMEA device but no logging control. Thats the point, spectras 220 are awful units but controlable with Carlson so static, rtk logging have all the function that I have posts and posts trying to explain. I use Carson and Fieldworks but as im limited to a nmea device I don’t have the options to manage and control logs that are really necessary to some professionals, because this these softwares still existing. I suggest to the team have a look on these softwares ( visually awful) but really well designed in functions to engineers survey needs.
Also in this research I found a software in Brazil that has most of the finctions Im suggesting to an external soft help in this tedious process with emlid, its made for EMLID units so people is having the same needs as me as I see. Check it out, ill request a demo.
Hi Guillermo,
From your comments, I see that it could be made more convenient.
I guess we may improve this process the following way: the receiver records info about the point name, its number, and time interval directly in a raw data log (RINEX or UBX). Probably, this is similar to how Stop&Go usually works. I suppose this could make it more accessible from the interface side and improve compatibility with post-processing software.
We’re always ready for discussion to make our product better if we see that something isn’t convenient enough. If you think that some other information should be recorded to RINEX or UBX, please share that. We’ll consider your request and think about how this feature can be added.
Yes, basically you got the point, Reachview usability is great to do RTK but forgets completely static collection. This week I went to a new area to survey, it’s a road project, no GPRS signal, maximum Lora range due topography ranges from 2km to 4k varying by segment. So, using my own RS2 base I tested the lora range along the project and defined 4 bases to full cover the area using RTK. After that I did:
1 - Stablished a general reference point, single collected and post processes against Cors network using RINEX
2 - Using this base point, returned placed the base on this point and collected in single during one hour the points and the base.
3- Post processed the other points against the base that has the fixed coordinate obtained from the against Cors postprocessing.
Now I have the other bases propagated from the first. During this process collected the data recording times with my notebook and my phone and took a reference estimated position of each new base point using reach in float very quick (just reference). As you see reach has nothing to help in this process as no static tools has. Some observation before someone asks why not PPK?I tested and this happened running PPK Kinematic postprocessing:
1 - One of the points I captured using RTK capability during 5 minutes. This same point using PPK went to float.
2 - One interval containing one of the 1hr collections went to float. Also played to just postprocess a 5 min interval artificially creating a 5 min occupation, the point was observed as float.
An observation, I have traditional survey using the same base coordinates that I collected in parallel so I have how to verify the precision very well. So, I changed the setup to PPK static and post processed the time interval of each point collection (getting from the old and good paper notebook) and got a fixed solution for all the occupations also for the 5 min RTK. Observations using this process of PPK static:
1 - Need to process each interval by hand taken time, so if reach view were capable of make static parameter recording from observations to process it at static during the defined time this will be great.
2 - RTK and PPK Kinematic solution were too much different (too much for me is ±1cm horizontal, 10cm vertical), the PPK Kinematic solution went to FLOAT. Using the PPK kinematic the result was almost the same than the RTK but precision against traditional survey with total station went more precise. So PPK static solution was really good and RTK acceptable. I knew previously that will happen and because this I had this point to be a new “base” because lora fluctuates too much at this point. And here goes an empirical observation, as base correction still fixed 60 seconds after signal lost from the base, the corrections deviations jump values and start to try to reach initial values or smaller as the signal is reestablished. So, this so pseudo corrected in RTK points (because corrections from base never aged more than 59 seconds) are very problematic. I noted this during several surveys just looking a very crazy behavior in deviations in some points but points never went float always fixed. Checking the points against total station survey big errors emerged. Taking them again from another base, increasing antenna height and having and eye on the base status and having a good signal timing (even and not going over 6 seconds usually) the values were also FIX but values remarkable different and checking against total station error so small that could be considered an observation difference. SO NOT ALL FIX COLECTED POINTS ARE GOOD FIXES. So small deviations variations in a static place most of the time indicate a FIX AGING correction degradation. This empirical observation is backed when after PPK static post processing you check the AR value, the points that RTK FIX low quality observations (generally these go FLOAT after PPK Kinematic) they get FIX solution but AR barely goes over 3 (minimum to fix is 3).
This false low quality fix point observation using RTK went to my eye doing a very different kind of survey procedure, stacking. I was staking a 4 meters square grid (2 hectares area) for an archeological survey and with never losing the fix status in a sudden point in some areas started to run out of me and returning, but “running” far as 20 cm after being over the point by 3mm horizontal and vertical. So, when these strange behavior points when started to occur I started to place a bipod and park over and appreciated the point that in minutes can come back or move around the same position without loss of FRIX solution in RTK. Observating I started that they were in places were GPRS signal was so weak, and started to observe the base status in Reachview. Increasing GPRS quality elevating antenna and getting more consistent and short timing from base made this problem disappear, so here I leave a good consideration to be done or an option to we choose the base time out, because one minute can cause very crazy results when precision is needed, and we can wrongly blame the hardware when was a software consideration over an external condition is governing the result.
1 Like
Hi Guillermo,
In your case, PPK Static indeed can give a better result, as it considers that all the data is related to one point. As for PPK Kinematic, the software assumes that your receiver is constantly moving and calculates a solution for a set of points.
Thanks for explaining your point! We’ll look into how we can improve our software to make your work with static observations easier.
Reach uses the Fix-and-Hold mode, so it holds Fix for a while even if it stops receiving the corrections. It helps Reach achieve a more stable Fix if there are slight delays. However, 60 seconds is a big age of differential which can result in lower accuracy. So, the root of this issue lies in the correction transmission.
If you are using LoRa and there are obstacles like trees or buildings, raising the antenna higher can help improve signal stability. So, this should lead to better survey results.
LoRa is a low-powered radio and needs a line of sight between receiver and transmitter to hold the link. If you often have to work in complicated environments, I’d suggest using a pair of more powerful 3rd-party radios. Alternatively, you can set the NTRIP link between your devices using, for example, our free Emlid caster. This should improve your survey in RTK and when staking out.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.