ReachView 2 beta v2.1.1

Solved:

1 Like

Hey!

Could you share any details of your setup? In this version serial must work.

Correction input tab has a status line. What does it say? Is it clickable? If it opens a more detailed status post it here as well.

We definitely have plans to introduce in-app update notifications and changelogs. If the beta tests continue to be this productive, we will formalize it one way or another.

uart at 57600bauds rtcm3
status: connect at /dev/ttyMFD2

seelm to be clickable ( hand when hover) but not details appear

using latest firefox 50.0 on win8

Few items to check if these are bugs or not.

Firstly, seems there is no way to update from within ReachView v1.2 to 2.1.* or even 2.09 from what I could see?. Then the new download fw to flash with is still using 2.09 and then it doesn’t work to set the Wifi in many browsers very well so I got stuck there at first. (I wasted more than a whole day trying to get past this first step!.) Would also be nice to see which version its at and going to when at that "welcome to ReachView update screen.
I suggest to please have a link to the newest FW update files as you post them so people updating from v1.2 get the latest fw to flash with and one without the buggy 2.09 ?

When I change the coordinates format from LLH to XYZ it doesn’t hold and always reverts back to LLH after I switch pages.

When I changed over to use another wifi network, it lost most of the settings and I had to redo them all again. Is there anyway to save the settings or back them up?

I set the coordinates accumulation time to 15min but it seems to take much longer. Sometimes up to 30min to 1hr or more to get a Base coordinate fix. This is even when I have constant 6 to 8 sats well over 45

Sometimes in Rover it shows I have 8-9 sats over 45 but when i go to the Base screen it might only show 4-5 sats over 45. When this happens it sits often in Float mode mostly but can also be in fix mode. (inconsistent?)

I like to dedicate one browser wholly for Reach use to avoid cache issue etc. I tried Opera for this. When first loading ReachView in Opera it doesn’t get past the Emlid logo first page screen. Once I load it up in either IE or Firefox, after then it loads ok in Opera. Except the settings might be all different again. This also might happen when switching from IE to Firefox they settings seem different sometimes. I suppose this is again a cache issue?

Suggestion:
Presets for Base and Rover.
Ability to Save settings and save them as presets.

Updated documentation, which no doubt is in the queue. But a quick setup guide for now would have saved me quite a few hours.

Thats all for now, and many thanks for all the great work on this new update.

Could you attach a screenshot?

A couple of things to check at this point:

  1. The radios might be configured to work on a different baud rate. You try sending NMEA and checking the other end. NMEA is text based, so you will be able to see the data is coming through correctly just by looking at it.
  2. Is there any chance you have RX/TX wires mixed up on the radio connected to Reach?

Hi!

I’ll try to address some of the mentioned issues.

The new app and even the new image are rewritten from the ground up. Updating from 1.2 is borderline impossible, even if we thought it would be worth the effort. New image contains countless new features including Linux-level modifications which will help us enable support for accessories, such as USB modems and such.

Updating from 2.0.9 is possible by going to “192.168.1.XX/updater” url. There is also a link inside the settings tab(marked with a gear).

That’s a fair point. But during this phase, we also need to test and smooth out the update experience itself and just putting out new firmware with every update would be cheating :slight_smile:

Good idea. We’ll do something about it.

Settings are saved every time you hit apply. If they are lost, then it means something went wrong. Probably the file got corrupted. It should be connected to an unfortunate powerdown. Are there more details to this?

I don’t quite understand. What do you mean by Base fix? Does the procedure itself start?

By Rover and Base you mean two different Reaches? Check enabled GNSS in the settings. One probably has more systems enabled and therefore shows more satellites.

Most definitely. We are working on this problem.

We are currently trying to figure out a way to do this without cluttering the interface and experience.

Things still might change considerably, so it’s a little early for the docs.

Thanks for the feedback!

Bluetooth is working again. However, I’m concerned with the message “Read error” on the position output BT page. It gives this message when the BT device is paired but no app is actively “pulling” any data. My concern is that this is a misleading message.

Short feedback to v2.1.2:

Further testing follows…

ps: what about my early suggestion to mark the base on the map?

Wittich I also am getting some great connections using TCP even from my balcony where I only have a half view of the sky. (screen shot is this example on a very clear night) Even last night when it became very heavily clouded and rain like crazy for over an hour, I still maintained a fix all that time. My immediate concern is however, is this really accurate, or is this again a cache issue? Just one other question a bit off topic. Does the base line improve the accuracy if its spread apart further? From my balcony I only have a 3m space between the Base Reach and the Rover Reach. Or doesn’t it make any difference?

Thanks for your time to reply with all the good info.
Re:
_"I set the coordinates accumulation time to 15min but it seems to take much longer. Sometimes up to 30min to 1hr or more to get a Base coordinate fix. This is even when I have constant 6 to 8 sats well over 45

I don’t quite understand. What do you mean by Base fix? Does the procedure itself start?"

In Base screen for my base Reach in the Base Coordinates settings is the "Coordinates accumulation time " slider , which I assume this is set to a time frame so that the base can collect coordinates data so it gets a best average fixed location with and then it uses that as the correction coordinates for the Rovers correction?. Is this assumption correct? If it then the issue I have is if I set the slider to 15min or over, it takes much longer than that before it finally sets a Base coordinate that gets set into the Rover field. I tried at 30min and even after 2hrs it never set a fixed base coordinate. Is this maybe a cache issue as well? I will try again after I have made a few changes to the settings and see if I get the same issue again.

RE:
“Settings are saved every time you hit apply. If they are lost, then it means something went wrong. Probably the file got corrupted. It should be connected to an unfortunate powerdown. Are there more details to this?”

Sometime when adjusting some of the settings there is no popup to click apply with right?. Which makes me wonder if the changes actually got sent and written to the board or not. Perhaps that’s deliberate and/or still in the works?
My guess what I think may happen is if I open ReachViewer in another browser that was used before and that had some old settings, when it connects to the board it updates and sends those older settings to board, rather than the board refreshes the ReachViewer with it settings? Obviously would be a cache issue again?

Thanks again for the great job on this release.

Do you get the “read error” message if you turn turn BT on but have no device app connected?

i have also posted an issue like this months ago. i got a fix with very bad conditions.

but with best conditions the fix is not stable @me.

Yeah, of course you are right. We’ll address this messages altogether.

Cache may have something to do with the page not loading correctly. The status data is always accurate.

Small baseline doesn’t make any difference.

I quess interference will, if units are placed to close…

yes, but as @egor.fedorov says they will do something about it :slight_smile:

@jcampen unfortunately you cut the screenshot in a way that we can’t see the baseline. Is the baseline distance correct between the two units?

@Andreas_Ortner I had the feeling that the fix was not good here. Also as my position stills moved though the to units where mounted on a tripod. And by the way my baseline of 10m (as you saw it in the screenshot) was definntly wrong the units where in a distance of 1-2 m. :wink:

@egor.fedorov nice feature that the settings are saved, even when there where disabled for a while (for example when I switch between radio and tcp correction or between average and manual coordinates of the base)! :+1:

My radio correction also working!!! (I think it’s time that I solder the connections) :wink: Also the the "age of differential is now max 1s with the radio! With the older image I had up to 90 seconds.

Conclusion: nice work emlid team!

ubx.cmd

@emlid

i did have a look in ubx.cmd in /usr/bin/RTKLIB/app/rtkrcv

you have again set UBX CFG-NAV5 1 8 = airborne

it like to set it to 1 for base and 3 for pedastrion for me. but after restart the value is again at 8.

andreas

Hy
updated new release BT works

thx

Francesco

1 Like

This setting does not affect raw data produced by the receiver, so unless you rely on the single solution calculated on the receiver(not RTKLIB), there’s no need to change it.

1 Like

Would you post a link to the image so I can download it and flash the Reach’s manually? I am on a slow connection and do not want to download the image multiple times to flash multiple Reach devices. Also, the Intel installation application refuses to install without an error on my laptop so I need to install the firmware using the Windows CLI approach.