We are currently running the basic version of Snip, and for the most part it is working well. We have 2 emlid base stations that we always have issues with however.
If for some reason the machine running snip has to restart or snip itself restarts, These 2 Emlid bas stations will not seem to connect back up and be an active stream.
I have them set up in 2 different ways, although they are both connecting via the public internet.
1 is set up via a pushed in stream, and the other is set up via a reserved mountpoint under the TCP/IP connections. For both of these, the only way to get them to connect again as an active stream is to physically restart the base station and that forces it to connect again.
I have 1 other Emlid set up to connect via a reserved mountpoint in TCP/IP that does not behave the same, however it is connecting via our local network, not the public internet.
I have the machine that is running Snip set up so it automatically starts, and runs Snip after any outage etc. It works perfectly for 3 out of 5 base stations, these 2 Emlids are an issue.
Is there an Emlid receiver in the other three bases?
To investigate this further, I’d like to check the Full System Report. Please send the Full system report both from the base that works and does not work, as well as the time information when the issue occurs and your time zone.
The Full System Report might consist of some sensitive data, so I suggest sending it to our email: support@emlid.com and mentioning this thread. Thank you!
As mentioned yes there is also 1 other emlid, however it does not connect via the public internet. It connects via our local network (TCP/IP) and it works perfectly.
I am downloading the logs from 1 of our problem Emlids now (its actually a RS2 but the RS3 behaves the same) What part of the log would you like? Rinex files, RTCM files?
Further update from today, It was suggested by Snip support that it is in fact the router restarting and renewing the IP address that could be causing these issues even though we have our router set up to update dyndns.org with the new IP. I have tested their theory and confirmed that it is in fact this sequence of events that causes the issue. I plan to do new logs capturing just this and email them in.
Hi, @andrew3, Thanks for the additional information! I received your email with the data. For now, all we need to check is the Full System Report and the log is not that necessary.
I am compiling the information and checking this with the team. Let’s continue the investigation through email to centralize the communication.
