We use the rs232 NMEA correction output from the reach rs2 to our computer. But very often the datastream stops for 3 seconds till sometimes a minute. Always after the $GNZDA string. We cannot allow to have no position for such a long period. We have firmware version V2.24.0.
Who can help.
Hi @erwin,
Does the solution status change when the stream stops? What update rate have you set in the RTK settings?
The solution stays the same: fix. Update rate 5hz.
I have downloaded and installed the beta version v2.26.0 and that looks very promising. Ran for more than 1 hour with only 3 or 4 drop outs of 3 seconds. The fix stays.
What program are you using on your computer?
Some parsers are poorly written, they can only handle very specific messages. If extra NMEA messages are being transmitted it crashes the service. What does the manual for the software say?
What baud rate are you using?
Use 38400 minimum, you get all sentences whether you are using them or not. Sentence selection is finally now in Beta!
The Emlid just keeps dumping data, i have a feeling the problem is on the receiving end.
Hello PotatoFarmer,
We use a microcontroller (Teensy 3.5) and we have written the parser by ourselves.
This software is reliable written, we read out a lot of NMEA transmitters and they work all well.
We use 9600 baud and all data is read well, if it comes…
We disconnected our controller to exclude our faults. The result stays the same.
A connected oscilloscope (as the only receiver) sees the drop-outs also.
With this experiment we excluded a fault on our side.
We have installed the beta V2.26.0 version and that version is more stable for this situation.
We also asked our supplier who contacted emlid. As long as we do not get an answer from them or an explanation via this forum, we will use the beta version.
Of course the sentence selection is a very nice option to use.
Thanks for your reply and thinking along with us.
Set your Baud to 57600 and see what happens. The Emlid sends all the NMEA sentences, so at 9600 its over running your buffer and causing a timeout. 9600 cannot clear the input fast enough on the Teensy, or the output fast enough on the Emlid. The satellite in view reports totally swamp the output.
If you do not believe me record the output of the Emlid in a serial monitor at 57600, count the number of bits per second. The problem will reveal itself in easy math.
I discovered this issue trying to get the Emlid to talk to a Shipmodul. Now with the beta, with NMEA sentence selection if you only had vtg and gga you might get away with 9600. But why would you purposefully make a bottleneck running comms so slow?
If the emlid is attached to an oscilloscope and we see all the data coming out, it can not overrun any buffer on our side. It must overrun it’s own buffer then.
We use 9600 baud because the connected sonar is also 9600 baud and we can swap connectors. 9600 baud is a proven speed in a noisy ship environment.
Because we now have the beta version with sentence selection, we only receive gga and zda sentences.
I have a Teensy 4.0 default input buffer is only 16bytes, output is 64bytes, very easy to overrun and lock up especially if your parser does not flow and has blocking elements.
Use a serial monitor, all an oscilloscope tells you is a yes or a no, it cannot determine if the data is valid or if you are getting sent a garbled mess.
If you absolutely have to run 9600 due to electrical noise, I would invest in some properly shielded and grounded cabling and solve the noise issue completely in one step.
On the oscilloscope we see for more than 3 seconds or sometimes for more than a minute no signal. So it is impossible that it is a receiver problem. There is no data out of the emlid for that amount of time.
What message does it hang on?
Always after the $GNZDA string.
Hi @erwin,
We’ve received an email with the log from our dealers. I’ll check it and post the results.
I see you mentioned that you checked 26 Beta 1. Could you clarify whether you tested the latest stable v2.24.2?
We did not test v2.24.2 because we were unable to install it.
When we selected the update button, a strange script file appeared and no update starts. So we went for the beta version.
We encounter now also “502 Bad gateway” errors when we are connected through Wifi.
Hi @erwin,
We indeed had some issues with an updating process on v2.24.0. Sorry that you faced this inconvenience. Everything works fine since v2.24.2.
May I ask you to check if the issue persists on v2.24.2? If your device is on 26 Beta 1, you need to go through this guide from our docs to get back on the stable branch.
If v2.24.2 doesn’t help, please let me know.
We encounter now also “502 Bad gateway” errors when we are connected through Wifi.
Do you mean that you face this issue while updating?
Hi @svetlana.nikolenko,
We will go to v2.24.2 tomorrow, then the receiver will arrive.
“502 Bad gateway” we receive while the receiver was running normal and we were just looking into the receiver to see what was happening. So not during updating.
Yes, we work with Reachview 2 in a browser for changing settings and to see what the GPS does.
We use NMEA on RS232 to read out the corrected position.
Today we did a lot of tests after we went back to v2.24.2
With this version we encounter the same problems.
You asked me before what the solution does, we see now that the solution changes from single or float to a “-”. In those situations we see that sometimes also the signal to noise ratio bars go to zero. We also tested if this strange behavior is caused by the RS232 output. But that is not the case. We disabled the correction output and then we see the same strange behavior. I made a movie of it and put it on YouTube: Status of RS2
We do not reach a fix, because the receiver is hanging out of the window, so not a good view on the satellites.
Hi @erwin,
It seems that Reach doesn’t have enough data to calculate the solution. That’s why it falls to the No solution status sometimes and shows “-” on the Status tab.
At the moment, when Reach has No Solution status, it doesn’t output anything. However, we’ve changed this behavior in the 26 Beta 1. In this version, Reach outputs empty messages if there is No solution status.
So, if you need an uninterrupted data stream, I’d suggest using the 26 Beta 1 version. However, please note that Beta versions are mostly used for testing purposes.
“502 Bad gateway” error message is usually related to poor Wi-Fi signal. Our new ReachView 3 app should resolve such issues. Would you mind testing it and check if it works for you?
As you can read in the earlier messages, we just came back from the 26 Beta 1 firmware. And you suggested to go to the stable v2.24.2.
We have the same issue in the open field. So what is happening to the 25 and more satellites that they all disappear for more than a second? So when the Reach cannot calculate the solution it must be a Reach problem.
Hi,
Is there any chance you have logs recorded in the open field when the issue occured? It will help me to check the possible reasons for this.