I would prefere taking a glympse at the screen now and then so i dont track the wrong way.
Something like this WebAudio Experiments - Simple Tone
Not sure how much work that would be to implement in your webcode?
I like this idea too. But my idea was to alert when “fix” was lost, for example. One of the commercial field surveying solutions I’ve used in the past did this.
Sound feedback seems like a popular feature, we’ll think about it. Added to the issue tracker(RCH-367).
2 Likes
Display “DGPS” on status page when appropriate. I’m assuming that Reach does give a DGPS correction if available (WAAS for example). Is this an accurate assumption or does Reach never give a DGPS corrected solution?
A Feature I am missing is, to set Bluetooth to discoverable, so that other devices can pair to it.
Another featuer I am missing is to set a WIFI Hostname without the MAC-Suffix and an IP address other then 192.168.42.1 for AP Mode.
Maybe it will also be good to remember the last state at boot (AP Mode oder Client Mode).
a feature i would like:
you have in base mode:
store average fix (single) position after x minutes…
could you also insert a checkbox to disconnect from ntrip server after fix is stored in reach.
i would like this feature when i move my base from one place to another.
after power on it uses ntrip server to get fix postion after that it disconnect from ntrip and saves data and internet flatrate .
…
second feature: show status of base station in rover… (float, average fix in x min, and fix)
best regards
This is now a part of 2.1.3 . Thank you for your feedback!
1 Like
Could you please elaborate more on this one? The pairing request is sent from Reach.
What could be the use cases for these?
Same question here. What is a real world scenario when this is needed?
Thank you for the feedback!
This sound interesting indeed, but ATM would be hard to implement.
Hi Igor,
I want to pair to reach from a Bluetooth device, so that i do not have to first connect via WIFI and then search for the device in the reach view ap.
I have already succeeded doing this by folowing the guid in the answer of this post:
http://stackoverflow.com/questions/34709583/bluetoothctl-set-passkey
The only thing i have to do after this procedure was to trust the connected device, so that it can reconnect.
The use case for the WIFI hostname and the ip Address is the APP:
This App needs a Hotspot with the Name SmartBox which sends the NMEA Messages on the IP 169.254.1.1 at Port 10001.
The Port can easily be set. Setting the Hostname is also not so tricky. It can be done by modifying hostapd.conf.
For setting the IP addres I modify the reach_setup file at the point after the hotsopt was set up. Last but not least the udhcpd have to be changed, so that the clients get the right IP Address from the router.
Remembering the last state would be good if I want to start reach near my normal WIFI and then go into the field, which will mean I lose my WIFI connection. With the “remember feature” it would be possible to avoid this Connection loss by conecctiong the Monitoring device to the reachs Hotspot. Without the need to first go to the ReachView APP and change the mode.
I hope my intentions are more clearly now.
1 Like
Hello Georg,
I don’t really see a problem here, as you only need to pair the devices once, and then it’s possible it initiate the connection from your client device.
That’s definitely possible, but that would mean allowing all connections and pairings at all times, which is not a nice practice. Maybe we will come up with as a passcode pairing process, but still, you don’t really need to do it that often.
Maybe it’s easier to set a static IP for Reach from the router itself? This is the general practice for things like that.
This makes sense, although we usually distinguish the settings like home-wifi-client and field-hotspot modes. We’ll think about adding this feature. You can also boot outside the network.
Hi Egor,
for the Bluetooth thing i definitly agree with you. But it would be comfortable to pair devices without doing anything on the reach. For the security issue a passcode will be good. Also a limited time to pair after boot, lets say 5 minutes, would raise the security.
For setting the Hotspot name and IP address my use case is may be to special. So I will do it by hand so that nobody gets confused by this option 
Starting outside the network is not always possible, since I wold not shut down my whole network at home, when I start at home. At the moment I use a special WIFI only for the reach which I can switch off if I do not need it. But using the usual network would be better and less effort.
A new thing, may be other people have mentiont it before, is that with the reachView Version 2 the possibility of multiple output pathes is lost. It would be nice if the output can be sent to multiple destinations in the future. At best to all destinations (TCP may be even multi port, BT, UART and USB) at the same time. Maybe selectable by checkboxes or something similar.
Best regards
Georg
Hi @emlid team @ivereninov @efedorov, If I may suggest something about solution button. It is a button on status page which function is like solution. For example button name is “start” when start button click, solution is written in a file solution, then the button name (in same button) change “stop”. When we finished, click stop, the file solution is paused. Then when the button click again, the solution file is written again in same file solution.
Actually the slide button in log file is enough, but maybe if we see a button in status page whuch we can know fix or not, then just click the button, file solution is written.
Thank you.
1 Like
Thanks for the offer. We are working on a more complete solution for the problem, developing a surveying tool inside ReachView.
2 Likes
Hi @emlid, you have come along way in your reach journey … congrats. I’m getting more and more excited to use your products. New Reach frontend is ‘fantastic’!
I’ve been searching for ages trying to figure out how to use two reach units on a rover with 2 gps units to get accurate heading data without the need for a compass (and then feed that output to ardupilot to use.
I think once moving base is implemented then this may become an option. Would like to put this feature on the request list please.
Thoughts are that for base rover rtk, 2 units are needed on the base running a ‘moving base’ between them and another base reach on the ground sending corrections to the rover unit (3 units in total). Have things just got too complicated …?
Regards
Jason
1 Like
Maybe could be added a method in ReachView an algorithm for switching between static and kinematic, the default method is kinematic, then when stop in a point we can choose what method for calculating the point, kinematic for default or static for other option. This need a button for collecting point with static method, we push ‘start’ button then static method working, then start button name change to ‘stop’ button. If we don’t push the button, kinematic (default) will work.
So the conclusion is we move with kinematic, when stop in a point, collecting point with kinematic(default) and static (with button).
1 Like
You’re talking about “stop & go” mode 
We’re working on surveying tool in ReachView now as @egor.fedorov said in his post and that mode will be a part of it.
2 Likes
That’s great… Awesome!!
Another map request. I zoomed out on the status page map and realized the base station is displayed. This is a nice feature. Make it more evident with “Zoom to base” or “Zoom to baseline”.
1 Like