Try monitoring the CPU temp on the config page. I had problems with drop outs when my CPU got over 68 C. The high temps were caused by monitoring the trace through Stream at the default high refresh rate of 1 sec. When I throttle the refresh rate down to 10 sec the temps settle down. That’s the monitor function, not the helicorder display, which works OK temp wise.
Jeff
Hi Graham, from the logs it looks like you are having DNS issues, which are generally a router or ISP-specific issue. There are two ways around this: setting a manual IP and DNS in the http://rs.local web config, or adding a line to /etc/dhcpcd.conf in the Shake filesystem.
Each of these fixes is simple:
The first doesn’t require logging in to the Shake at all. Simply navigate to http://rs.local/, make note of the Shake’s IP address, then click on the Config gear to go to http://rs.local/config.
Click on NETWORK, then under ETHERNET SETTINGS, click on “Enable static IP”.
Fill out the Static IP field with the address you copied from the front page.
Fill out the DNS server field with a more reliable DNS service. I like to use OpenDNS, which is 208.67.222.222 but you can also use Cloudfare’s new DNS service by entering 1.1.1.1 or Google’s by entering 8.8.8.8.
The slightly more involved way, in which you can keep your Shake on a dynamic IP (assigned by your router):
It’s also possible that the problem is on the ISP (internet service provider) side of things, in which case the above fix will not have much effect.
In that case, you may need to call your ISP and tell them to stop disconnecting your router’s DNS every 12 hours. Let’s hope it doesn’t have to come to that! (but it’s a distinct possibility)
not sure i understand. the unit was rebooted a few hours ago, connected to the server, and has stayed connected just fine. it did happen, however, that there were a few hard resets on the time-stamping, which implies that your unit was unable to communicate with the NTP servers for some period of time.
you can see this in the odf_SL_plugin.info log file near the bottom:
...
2019 227 12:30:38>> Time adjustment M0: HARD RESET. This will result in a one-time time-tear.
2019 227 12:30:38>> 5.0: NTP Time (Init): NTP: 1565872237.761822939
2019 227 12:30:38>> 5.2: NTP Sync (HARD): VEL Before: 1565871767.750000000 After: 1565872237.500999928 Diff: 469.750999928
2019 227 12:30:38>> 5.2: NTP Sync (HARD): IS Before: 1565871767.750000000 After: 1565872237.500999928 Diff: 469.750999928
...
and i can confirm that your unit is currently connected and delivering data.
everything is looking fine: since your reboot a few days ago there have been no more hard time resets (indicating a connection loss to the NTP servers). there were, however, a couple of reconnections to the server, but this was a server-side issue that has been resolved.
you can verify no time-tears in your data using swarm and connecting to your local unit, and not to the data server itself; server reconnections issues will not be present on the local version of your data streams.
My shake will stay connected for a number of hours and then lose connection and cant access it by rs.local
Swarm stops recording but the uptime shows it has been up for days
I really dont know what is going on . I am using a static IP and a DNS server of 1.1.1.1
I have attached the logs
Kind Regards
Hi @Pumaman—Unfortunately, I think this warrants a call to your ISP. There’s nothing on the Shake side of things that indicates anything is going wrong on our end.