I am trying to get an ENU output from a stop and go type workflow, but hitting a wall to get the desired result.
What I am wanting to get is an ENU baseline from the base log to the rover, which gives me a true heading on the baseline. This is used for calibration surveys on gyroscopes for vessels and subsea vehicles during setup.
For single static points this is fine, no hassles, and for kinematic the ENU output is great for tracking the structure. If I use stop and go to put out multiple points (a network of points to use for total station adjustment), then the output is only lat long in the corrected csv. I have tried various options using the ENU output but the whole stop and go rinex file is listed in the .pos file and the events.pos is empty. I was hoping to log stop and go and have the output for each point to output as the ENU format. Essentially cutting out the process of conversion to grid and applying convergence to get true heading.
Is there a way to get that stop and go file csv to have the ENU values or run processing and the stops listed as events in the events.pos file?
Hi Scott,
Thanks for sharing the details! That makes a lot of sense for your setup. I think you’re referring to this option in the processing, right?
Could you send me your logs? I’d like to check why the .pos file is empty and see if there’s a way to get the ENU values.
If there’s any sensitive info, feel free to PM me or send it to support@emlid.com.
Hi Inkar, thanks for the response.
Yeah the E/N/U output is the one I’m interested in. My .pos files are fine, they do what the should do so I’m not struggling with studio not outputting correctly.
If it is possible I want to use the stop and go workflow but have the output include the E/N/U results. I can run a series of static logs and get multiple outputs for each one but I was hoping there would be a way to do so with the stop and go and streamline the activity. Hopefully that makes sense?
In my mind if I run a kinematic process or stop and go and I’ve recorded static occupation points then the sections of my rover rinex with each static portion would trigger an event which is logged in the _events.pos file. So I would get out a .pos file with a result every second of logging at 1hz, as happens now and then an event file with the static observations taken within the main file. Again I can take the file, and process multiple time snippets but the goal is to have a very simple workflow with as few steps as possible.
This might not be a workable idea, I’m just trying to figure out if the idea is achievable or not.
Thanks
Scott
Hi Scott,
Got it! If I understand correctly, you’d like Stop & Go to automatically detect static occupations and log them as events in an _events.pos file.
The _events.pos file is empty because the rover’s raw data log doesn’t include time marks unless triggered externally—like when a camera connected to Reach M2 takes a photo. Instead, Emlid Studio in Stop & Go mode relies on a CSV file from Emlid Flow to determine when points were collected.
Thus, there isn’t a way to automate this within Emlid Studio. But in firmware 29, we added the ability to record point markers directly into the raw RINEX log. This was designed for third-party software, so it might be worth looking into.
2 Likes
Thanks Inkar, that is exactly what I was hoping to achieve! I was trying various outputs to see if I could trigger it but no success. No worries though, there are other ways of getting to the desired output. The occupation segments written in there are handy in other software, however thinking was for getting a little workflow using studio (free and easy to use), which we can still do but with added little steps to mitigate grid convergence.
I don’t know if that would be a handy inclusion in the stop and go format for future development, to show the baseline values for each point. Probably a niche request… The base location is listed but maybe not as useful for certain outputs.
Thanks for answering the question, much appreciated.
1 Like
Glad to hear that, Scott!
I see you’ve already tried a few approaches. Adding baseline values for each point in the Stop & Go could be useful in some cases similar to yours. I’ve shared your feedback with the team, so they’re aware of these needs, too. If we make any changes in the future, I’ll let you know.
1 Like
