We are getting ready to map an area of the Bahamas where CORS site is not available (either not operational or the ones that do, are far away).
The goal is to place high contrast mats and collect them for Ground Control.
Bringing (2) RS2 on-site, on the date of arrival, we figure we could do a static collection of a minimum of 2 hours and get an OPUS solution. From there, we can manually enter the known point and achieve the goal of collecting the GCPs establishing the known point send corrections through LoRAa.
The area of interest is fairly long. about 4 Km and there are hills and a challenging hardscape. I am worried that the signal from LoRa would not reach. If I set up a Base-Rover correction through LoRa with a known point, can I collect a point with the Rover to be used as a second Base station to extend the radio communication throughout the site? Would it collection would still be absolute?
The overall goal is to collect GCPs for Aerial Mapping. There’s no NTRIP, VRS, previously collected points, or local coordinate established.
If someone can give us some direction on how to properly get good absolute results without CORS, I would appreciate it. We have a subscription to EZSurv if that helps.
Does it have to be RTK-precise at collection time or could you do post-processing?
It seem that you would have 2 options:
Local, well-documented known points, that you can set up on
PPP collection.
I’d prefer the first option as that gives you a hard reference to whatever coordinate system is being used.
With PPP you can however still acheive some very good accuracy (2-3 cm vertical), if you log long enough (8+ hours using dual frequency) and wait long enough (12-14 days for Final Product to be available). But you’d likely have to transform etc afterwards.
Well at first we had issues trying to get an OPUS from a 2hour staic. One of them was an unknown error I have no knowledge of but my guess was the collection went from one day to other. Keep in mind we did this very late at night, almost midnight. The other error was the size of the obs. Rinex was 150ish mb and the ubx 200ish mb. We later find out we were not collecting in the OPUS setting in the log and we were collecting in all constellations. Today we did an 8-hour static with just the OPUS option in the loggins, and didn’t had any issues getting a result back.
However, we place the base in the middle of the area of interest, and when we went to collect the GCPs, with LoRa on that 8-hour OPUS point, it would not keep a fix.
So, as we collected the GCPs and we are moving the base to the farthest we could collect with a fix, and establish that as a base to extend our radio communication. I hope this keeps the consistency and quality of the OPUS as we move the base.
It’s strange too, we move away from the base, perhaps 500 meters, and could not get a fix again. That was one of my biggest concerns.
I there any explanation for losing a fix on these distances? The area is on the coast and there isn’t any challenging hardscape that could be considered an issue.
Sounds like the ver 28x problems previously discussed here and still not resolved 4 months later. Is the age of corrections rising and falling non stop?
Let’s try to figure out what’s going on. Are your base and rover located in the line of sight? What LoRa settings do you use: default ones from the Base and rover setup guide?
Sometimes allowed frequencies may be affected by some local factors. That’s why I’d suggest you check the LoRa range with different of them. Just set the highest available value and then go down with the 1-2 MHz step until you find the frequency that works best for your area.
If it doesn’t help, please record the logs where the issue persists and share them with us via support@emlid.com. We’ll need:
Raw data logs in UBX format from both units
Position log from the rover in LLH format
Correction log from the rover
These files will help us check the stability of the correction flow and how your rover uses it in calculations. So I’ll be able to share more thoughts on this issue.
I also want to agree with Christian @wizprod and Dave @dpitman suggestions about your initial post. I see 3 possible options for your work area as well:
RTK via LoRa, if you can place base and rover in line of sight
RTK via Emlid Caster, if you have an Internet connection on your worksite
To get the base position, OPUS is a good idea as well. But yeah, don’t forget to use our preset for it in the Logging tab. It makes the logs meet the OPUS requirements. The data you recorded without it can still be used in OPUS, but it needs some reworking to exclude all the satellites except GPS and make the seconds integer for observation epochs. Please let me know if you need my help with that.
Oh, and one more note from me. I just thought you could try the Base shift feature. It’s useful when you exceed the baseline and need to relocate your base. More details about it you can find in this article.
We recommend keeping all the devices on the latest stable firmware version. Currently, it’s 28.4. We don’t have confirmed issues with the LoRa range on it. If you face any difficulties, please let us know. We’ll research each case separately.
Jim, I remember your case, and we’re ready to investigate it. The issue may be related to your exact device, but we need to check the logs from the receiver to confirm it. So please share the data Andrew asked from you in this thread via support@emlid.com.
Julia,
Its not just my device. Three others I know of.
E38 has sent you many files on this. As I am on ver 27 now and working fine I have nothing to send. Please contact e38 and resolve this.
We’ve conducted multiple tests on 27 and 28.4 with E38 and in our office. We cannot catch the situation where the range drops down as you describe. Therefore, we cannot confirm that 28.4 has issues with LoRa performance.
We want to address your case thoroughly and find the cause of the described behavior. However, we cannot do that without analyzing the data from your surveys.
I suggest you update your units once again to 28.4 and conduct a survey. If you face any issues with this firmware again, please get in touch with me and share logs via support@emlid.com.
First of all, I should specify that each case with rising AoC should be addressed separately. We can make any conclusions only after a thorough analysis of the survey data and environmental conditions.
AoC delays up to 10 seconds can happen in LoRa radio transmission. There can be various sources of such delays. As I mentioned before, our tests showed that they are infrequent and inconsistent. AoC delays don’t affect positioning accuracy as long as the unit calculates Fix.
We believe that interference is the main source of longer delays if you have a line of sight between a base and a rover. We do not recommend using popular frequencies, such as 868 ±0.5 MHz. You can test other frequencies starting from the highest available value and going back with the 2-3 MHz steps in the Correction output settings.
The range of the LoRa radio is affected by the environmental conditions and applied settings.
Everything worked out well after that. I’ve been told by other users that have experienced the same symptoms that resetting their units, has worked well.
I hope this can help you as well.
As far as getting an OPUS solution, we are still having issues in knowing the right settings to upload and obtain a successful solution. We have tried the OPUS profile and let it log for an hour only to be unsuccessful. Here are some of the examples we have experienced so far in situations we needed bad:
Some of these issues are obvious, but we tried both options.
Can someone please share what settings and amount of time to get a favorable OPUS solution?
I know it could be different due to many factors, but I would really like to have tested any suggestions and dile down the approach for the next we need it and are able to achieve a good OPUS solution.
Additionally, is EMLID studio able to get the UBX files and converted into a Rinex for OPUS? If so, can you send a tutorial about it?
Hi avalez, are you able to share a few sample UBX files from observations where you have had difficulty obtaining OPUS solutions? It will help in understanding what the problem may be.
I’m glad to know that you’ve no issues with your units now!
We recommend logging the data for at least 4 hours or more, depending on the observational conditions. The OPUS can calculate the solution the next day after the day of logging. You can achieve the most accurate result with Final ephemerides, available after two weeks.
If you still have issues with acquiring solutions, please share your logs to support@emlid.com for the analysis.
