I have had quite the troubles setting up these modules for the last little while, reflashing firmware until I figured out what I was doing wrong. Now that I have it configured correctly, I assume…
I have the base set up in the back yard, and rover in the front. From the ReachViewApp for the Rover, the mode is Kinematic, and the status alternates from ’ single ’ to ’ - ’ now on single quite reliably. The state will not move into float or fixed. I cannot see any reason for why this would be as I have followed the quickstart tutorial closely.
Rover lights: White, Blue, Blue, Green, Light Blue
Base lights: White, Blue, Pink/Purple, Green
It may be of help as well if there were a location where we could see what all the light sequences mean as well.
Thanks in advance,
It seems that the correction link between rover and base is misconfigured. Rover does not go into float or fixed mode because it does not receive base broadcast messages. When configured successfully, rover will show base satellite levels as grey bars in the background.
If you followed the quickstart guide, then you probably set your corrections up through the network. Please tell us more about the settings, addresses, ports you entered.
You will also need to enter base location manually, automatic base coordinates feature got a little bit delayed due to a bug.
Could you also elaborate what kind of trouble you went through at the beginning? We need the feedback to address these issues
I will have these settings for you later today, in what format would you like these? Text or screenshot?
I did get it configured correctly once… But that was before the Update was performed. As far as I can tell, They are configured the same.
About the base location, entering it manually, how would be the best way to get an accurate or correct base location, or does this really not matter?
In the beginning, I was unsure of how exactly to configure/set up the reach modules initially, it seems that loading the reach.local site while the Intel Edison is configuring (that 2.5 minute loading bar during initial setup) breaks the Edison. In addition to this, The update button on the ’ Logs ’ section of the ReachView interface did not seem seem to do anything, and so when one goes and tries to start up the module or adjust Base or Rover settings, the update is somehow canceled. I think visual update during this update process next to the update button would be nice, telling to let the module sit for a minute or two while the update is performed.
Also, if you could provide a release schedule for the ReachView updates/other updates to the Reach module so we are aware of what is and is not currently functional, would be greatly appreciated. I’m not sure if this is documented in the GitHub page, or if that is the current release only. Is your RTKLIB fork on GitHub the one which is used on the Reach module? One more question, do you plan to, or already have documentation for your API for interacting with RTKLIB, it is not identified here as far as I can tell, http://docs.emlid.com/reach/software-development/
Thanks, I’ll be back with the configuration later today.
Ok, here I have a screenshot of the configuration for both the base and rover which I have used, I saved a configuration file with the tcpcli enabled streaming out of port 9001, nothing else below there has been changed, although the different filname is not visible here.
Just wanted to chime in here. I’ve gotten both of my reach devices onto the same network now (had to reflash the firmware with the intel tool to get the AP to actually show up on one of them, terminal flashing didn’t work). But alas, I’m seeing the same thing as Weston. The Rover is getting satellites, but the base is not detecting any satellites (the base says 0,0,0 for lat,long,alt). I’ve configured the devices as recommended by the tutorial (same as Weston, with different IPs). Both devices say that they are started, but the base just doesn’t seem to be doing anything. I tried swapping the gps antennas, also did not help.
Hey there Nic,
Apparently this is known and will be released shortly as stated here, Wi-Fi connect stuck at scanning
Are your modules able to get a Fix in Kinematic mode?
Nope, it stayed in single in Kinematic mode.
I wish there was a serial connection into the device. The wifi comms are driving me crazy!
In what was is it driving you crazy, what do you want in a serial connection/what do you wish to use it for?
I can’t always get it to attach to my network reliably. Which means I can’t ssh and troubleshoot, nor access ReachView. Even after reboots. Which means the only solution is to reflash the entire firmware, and set up the whole device again.
I believe you can/could establish an SSH connection over the wired network it provides… I could be wrong though
Making progress. Grey base station sats are showing up in the rover status. 5 green sats, but hasn’t gotten a float or fix yet. Still staying in single. Added some massive aluminum plates under the antennas as large ground planes to boost the signals.
Looks better than I’ve been able to do… How do you have this set up? Maybe I’m doing something different that could hinder results… Although it is very cloudy here at the moment, so I cannot try anything now.
Here’s my config. I think it matches yours. I found that I had to be pretty close to the wifi hotspot for everything to talk. Going to try to connect some radios next for base comms so it doesn’t have to send through the wifi network.
Yeah… Looks the same. This may be a part of our problem (quoted below), awaiting a reply form efedorov to see if this is correct, it may help to get a Float or better, a Fix. I’m not entirely sure how to get accurate base locations which would be a problem if this is right:
Could you keep us updated on the status of this feature?
As I have mentioned in other threads - I have exactly the same problems - green sats, gray sats but still single. I manually entered lat,Lon,ht manually into the base but no difference. Something is missing.
Within a day we will roll out a new update with automatic base coordinates and GPS/Glonass support and numerous small improvements. If it does not help, we will start investigating further.
Ok, Thank you very much! And then about the API for controlling RTKLIB/Reach, is there a file I could be pointed to, or is this something that is being currently built?
You can refer to ReachView GitHub for now, there are plans to separate ReachView and python RTKLIB API, but it is not our priority.
Igor have you guys rolled out the update with the automatic base coordinates and gps/glonass support? According to your post which shows date posted on the 2nd of December you say that the update will be posted within a day which means the 3rd of December is that correct? I don’t see the update yet or is it not working still? What is the current version? What will be updated? The firmware or the reach app?
When you mean to enter the base LLH, how can we get that? We need help, remember that a lot of us on here are not experts and are trying to test and implement your product on to our UAV. Also, another thing that we also need is some kind of tutorial about how to use data to geotag.
As well as setting up reach without wifi in which we would log everything and post process.
Based on the timelineish (no dates still ) page, it looks as if automatic updates are complete, although no update has been supplied as far as I can tell.
The LLH, that is the Base Latitude - Longitude - Height, My best guess on how to get that is to set the Base as a rover and have it resolve it’s ’ best ’ coordinates. At least that is what I did. As well as that, I typed in the coordinates into Google Maps and adjusted the coordinates until they looked about the right spot.
For your last point, when you click the save button, it gives you the option to load upon startup, with this feature, you can plug it in and later extrapolate the log file…
Igor, how can I make the output .log files readable by Google Earth, or other such program. I was trying to the other day, but it didn’t read any coordinates but 0 latitude, 0 longitude.