I see RINEX automatic conversion! but I don’t see a raw log in base mode in ReachView v0.0.5
How do I get it back? Or am I doing this wrong? Must I use rover mode for both my base and my rover in order to obtain the raw .ubx logs?
Another problem I have is that I have not been entering proper coordinates of base in the fields for “Base latitude,” Base longitude," and “Base height.” It did not matter before because I used the raw files, but now I have a day’s worth of base logged in .rtcm3 using improper base coordinates. Rtkpost or rnx2rtkp will not use these RTCM3 corrections to get float or fix, so I’m stuck with single mode.
Is there a way I can decode the RTCM3 log file so that I can write a script to offset these corrections with the proper base coordinates? Or must I do the day’s surveying over again?
One more thing: I have not been able to download any ReachView log to my android phone. It says “Downloading,” but when I look at the downloads, it says “queued” and nothing is saved at all. Has anyone else been able to download the log to their android phone?
After the log is converted you get a zip package, that contains both Raw and RINEX logs.
In rnx2rtkp you can set base coordinates for post-processing with -l lat lon height or -r x y z flags.
In RTKPOST you can set them under Options->Positions->Base station
We have checked the download procedure on an Android phone. Seems to work fine on a Samsung Galaxy Note. Could you please provide more details about what happens?
Yes efedorov, when in rover mode, I get a zip package containing both Raw and RINEX logs, but when in base mode I do not. Either I get no log or I can get RTCM3 log and that is all.
Could the problem be is that there is no “advanced settings” button in base config tab, so therefore the setting for enabling raw log is not available? To enable raw log, I will have to ssh into reach and edit the base config file?
For my second issue which is unable to download raw logs, please disregard it. I discovered it must be a problem with the network setup on my phone.
I seem to have the same, or similar problem. The LOGS screen has frozen with “fetching available logs” on both units.
I will try to see if I can send more details.
Logs worked after loading upgrade, but are now “stuck”.
For what it may be worth, I am using a T-Mobile LG Leon 4GLTE with Mobile Hotspot. I also access the ReachView App through Windows7 Internet Browser and Linux Firefox Browser.
I did run into a problem some time ago with the cellphone (Android) browser getting too many TABS open. When switched to Bookmarks, everything seemed to work.
Next step is to trying upgrading again and/or another reflash.
This may be an issue with web page caching, could you try to open the page with caching disabled? In Chrome, you can do that by opening developer tools, going to tab Network, setting Disable cache tick and then refresh without closing dev tools.
Watching progress on GitHub Reachview. Appreciate all the work you and Emlid are doing on this project.
I am using ReachView 1.0.0 with Flash 1.2.0 .
It seems that the problem occurred when I went Version 1.0.0 in the last day. I will try what you suggest. I am not familiar with Chrome, but I guess it would be the default Android browser.
This may belong elsewhere, but sometimes the BASE SNR bars disappear on the ROVER display. It is not normally a problem in RTK Kenematic mode. I found that it mostly occurs in indoor testing during poor weather, but could happen with temporary signal loss like going through a tunnel. It appears that this is due to all BASE SNRs going below the minimum SNR set on the BASE device. I can eliminate this problem in testing by lowering the minimum SNR setting of the BASE Reach unit. However, I am not sure that it won’t happen when the signal is blocked in RTK operation.
When I have time, I will try your recommendation and send any additional observations to the forum.
If you are not using ReachView from the desktop, disregard what I just said about caching and Chrome. This will only work for a desktop version of the browser.
The thing is, that older versions required a page refresh to update the logs list. The new version does not. It sends a request to the device every time you open the logs tab. However, browsers cache web pages to save traffic, so you get the old page, that does not send that request and gets stuck.
What should help is refresh the page several times in a row. Please report your progress and issues any time here.
Regarding the minimum SNR levels, I need some more info.
How did you set up the correction link between Rover and Base? Base SNR going down may also occur if the correction link is broken, interrupted or the data is heavily delayed.
In general, you should know that RTK will not work properly indoors or in areas with low GPS signal availability, so lowering SNR minimum will not help you achieve better accuracy.
However, for the sake of testing, you can try the following:
Unit serving as Base does not have any limitations on what data to send, but the Rover, which handles all the processing will filter incoming corrections. Under advanced settings, you can change option pos1-snrmask from default 35 to a lower value and see what happens.
[quote=“egor.fedorov, post:5, topic:1727”]
If I understand correctly, you want to save a raw log to Reach for later download in Base mode?[/quote]
Yes, that is what I want to do.
That is precisely what I needed to know 2 days ago, but I did figure that out yesterday and was able to post-process my logs!
So to explain for others, I let myself be misdirected by the file suffix again. So, under the ReachView v0.0.5 config tab, in base mode set Output path for corrections to file
Then under the logs tab, the log file will appear as an “RTCM3” file and when clicked on, it will fail to convert to RINEX format, but then you can download the file named like so: bas_201507290014.rtcm3
I believe your recommendations were the right ones. I did find many webpages cached. I deleted them on the Android browser and I believe I configured the browser not to cache. the web pages. I think I may have been at the Wifi range limit also.
The logging seems OK, now. I need to remember that “fetching available logs” means that I have a setup problem and logs may not be recording. The ROVER logs give a progress report when recording, so this is fine with me.
SNR problem is not high priority as I think it may only show up in unusual situations as with moving baseline or with unusual test situations. I just mentioned it in case someone else might see it later on.
