What is the problem you are experiencing?
I have 2 raspberry shake devices, each on separate networks on different floors of a building. When viewing the station on data view, there are huge gaps in the data - cutting in and out every few minutes. Very frustrating. There are no gaps in helios local view. On both of my devices - again each in different locations - the cut outs happen around the same time.
When did it first appear? (Was it after a power cut?)
Since turning on the unit.
Is your RS connected to a home or school/office network?
Commercial
Has your hardware (Shake board, power supply, Raspberry Pi, etc.) been supplied entirely by us?
Yes, this is an out of the box configuration by Raspberry Shake - everything is from you.
Thank you for reaching us about this intermittent data issue, and also for attaching the logs/screenshots. I understand the frustration caused by the situation, so let’s see what we can do.
Nothing peculiar appears from the logs themselves, so could I ask you to reboot both Shakes and check if all the LEDs behave as described here?
Particularly, if the LEDs on the Ethernet port (point 3) on that list remain constant in their behavior, or if they start acting out of pattern during the gaps you see on DataView.
After checking the LEDs, can you try the following procedure on both Shakes?
turn off your Shake
disconnect all cables from it
restart your router (if possible) and wait for it to regain internet connection
now reconnect LAN and power cable to the Shake in this order
turn on the Shake again
Then, wait for about 30-60 minutes and, when you can, download the new logs from both instruments and send them to me. I would like to see if there are any differences compared with the current log set, and also what the logs show after a full, fresh, restart.
In the meantime, I re-flashed the OS on both units with no improvement. I also adjusted firewall state timeouts, assigned static IPs, changed DNS servers, and even replaced the router—none of it made a difference. I also tried connecting the Shake directly to the main router for a public IP, but the same timeouts persist.
Both Raspberry Shake units respond to continuous pings with no dropouts, and I can SSH into each and ping external hosts without packet loss.
Thank you for the additional feedback and all the troubleshooting you’ve already done. I’ve passed your messages to our server team, and they will be investigating on our side to see if there is something amiss there.
Since you mentioned SSH (I was going to propose this test later on), could you log into the Shake again and execute:
Also, could you post the output of the following additional commands?
cat /etc/dhcpcd.conf
cat /etc/resolv.conf
Most of these commands are just procedure, and will probably report that connections are all right (particularly the ports one), but it would be good to have their output anyway.
Yes of course and thank you for your very fast replies.
If you see the attached screenshots - these are two different stations with the cut outs happening at precisely the same time(s), which is what makes me think this may be server-side. See attached images.
myshake@raspberryshake:/opt $ ping -c 5 raspberryshakedata.com
PING raspberryshakedata.com (178.162.236.229) 56(84) bytes of data.
64 bytes from 178.162.236.229 (178.162.236.229): icmp_seq=1 ttl=48 time=122 ms
64 bytes from 178.162.236.229 (178.162.236.229): icmp_seq=2 ttl=48 time=122 ms
64 bytes from 178.162.236.229 (178.162.236.229): icmp_seq=3 ttl=48 time=121 ms
64 bytes from 178.162.236.229 (178.162.236.229): icmp_seq=4 ttl=48 time=120 ms
64 bytes from 178.162.236.229 (178.162.236.229): icmp_seq=5 ttl=48 time=120 ms
--- raspberryshakedata.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 120.073/120.887/121.846/0.846 ms
myshake@raspberryshake:/opt $ traceroute raspberryshakedata.com
traceroute to raspberryshakedata.com (178.162.236.229), 30 hops max, 60 byte packets
1 unifi.localdomain (10.13.0.1) 0.459 ms 0.389 ms 0.341 ms
2 100.66.136.1 (100.66.136.1) 2.971 ms 2.924 ms 2.885 ms
3 100.64.253.23 (100.64.253.23) 4.824 ms 4.781 ms 4.738 ms
4 100.64.253.23 (100.64.253.23) 3.737 ms 3.690 ms 3.132 ms
5 100.64.253.14 (100.64.253.14) 5.801 ms 4.696 ms 5.689 ms
6 170.250.254.118.hwccustomers.com (170.250.254.118) 4.608 ms 4.506 ms 3.750 ms
7 170.250.254.9.hwccustomers.com (170.250.254.9) 6.166 ms 6.776 ms 6.318 ms
8 3-1-4.ear4.Miami2.Level3.net (4.15.158.169) 5.765 ms 5.385 ms 5.680 ms
9 * * *
10 be2258.ccr82.mia03.atlas.cogentco.com (154.54.168.86) 5.690 ms 5.431 ms be2085.ccr81.mia03.atlas.cogentco.com (154.54.167.186) 6.072 ms
11 be5576.ccr41.atl01.atlas.cogentco.com (154.54.47.49) 17.528 ms be5577.ccr42.atl01.atlas.cogentco.com (154.54.82.245) 17.255 ms be5576.ccr41.atl01.atlas.cogentco.com (154.54.47.49) 17.213 ms
12 port-channel3482.ccr91.dca04.atlas.cogentco.com (154.54.169.177) 32.958 ms port-channel3483.ccr92.dca04.atlas.cogentco.com (154.54.172.169) 33.203 ms port-channel3482.ccr91.dca04.atlas.cogentco.com (154.54.169.177) 33.949 ms
13 be2261.ccr41.par01.atlas.cogentco.com (154.54.47.166) 111.967 ms 111.921 ms 112.204 ms
14 be7946.ccr42.fra05.atlas.cogentco.com (154.54.72.118) 121.036 ms be4975.ccr41.fra05.atlas.cogentco.com (154.54.63.69) 121.362 ms be7946.ccr42.fra05.atlas.cogentco.com (154.54.72.118) 120.946 ms
15 be5970.agr31.fra05.atlas.cogentco.com (154.54.59.53) 120.754 ms be3763.agr31.fra05.atlas.cogentco.com (154.54.76.210) 121.709 ms 122.125 ms
16 149.11.182.202 (149.11.182.202) 121.115 ms 121.994 ms 121.792 ms
17 po-01.ce14.fra-01.de.leaseweb.net (212.95.37.53) 122.447 ms po-01.ce13.fra-01.de.leaseweb.net (212.95.37.51) 121.332 ms po-01.ce14.fra-01.de.leaseweb.net (212.95.37.53) 121.492 ms
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
myshake@raspberryshake:/opt $ nc -zvw5 raspberryshakedata.com 55555
Connection to raspberryshakedata.com 55555 port [tcp/*] succeeded!
myshake@raspberryshake:/opt $ nc -zvw5 raspberryshakedata.com 55556
Connection to raspberryshakedata.com 55556 port [tcp/*] succeeded!
myshake@raspberryshake:/opt $ cat /etc/dhcpcd.conf
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
#nohook loo
denyinterfaces wlan0
myshake@raspberryshake:/opt $ cat /etc/resolv.conf
# Generated by resolvconf
domain localdomain
nameserver 10.13.0.1
myshake@raspberryshake:/opt $
Thank you so much for all the prompt replies too, ajgnet.
I have passed everything to our server team so that they can cross-check with the information we have on our side.
I’ll update you as soon as they have a reply for me (probably on Monday).
As far as I can see on my side, both Shakes appear to operate without internal issues. My apologies for the data interruption problems, and thank you for your patience while we work to understand what is happening.
