I recorded this on my RSD4 Last night on my RS This looks like some odd RF Noise but the Raspberry Shake (RS) is in a Vault in the yard with no RF equipment/things near it. Whats even more odd is that the Noise appears and then disappears, maybe its a Digitizer issue? I am not sure though. Any thoughts? I will attach some images from swarm, but for some reason the “noise” is reordered and saved in swarm and on the ShakeNet app.
Southern CA Earthquakes
It definitely seems something strange, and I remember seeing a similar event when I was using my Shake when I had it connected via WiFi and not Ethernet.
Is this the first time that this event has happened?
EDIT: Now that I am thinking about it, I remember also something akin to this with children stomping outside or a neighbor door that was closed with too much force, but I’m not 100% sure.
I got these from time to time on my RPI3 system. My “neighbor” (50 km away) gets them too - again rarely. It usually looks like a single reading of an extremely large value that makes quite a colorful splash on the spectragram. I really don’t think it is anything external to the RS that is causing it…
My RS is connected using ethernet so that shouldn’t be an issue. This is the first time that something like this has happened. It was also 4:30 in the morning so I would assume that no children are outside and I have seen people stomping near the RS and it appears differently. Very odd. This also only appeared on the EHZ channel and then disappeared. Thanks both for all of your help.
Thank you both for writing out your own experiences.
As of now, searching through our post history, it seems that another user has reported a similar event:
I am sure you have already checked this out, but please verify that your WiFi module is turned of from the
rs.local interface. That module can produce this kind of high amplitude spikes.
Can you also check if the spikes repeat at regular intervals, or, in case of isolated ones, at the same times each day? This could prove (and maybe identify) a nearby source of RF interference.
Thanks again, i have verified that the Wi-Fi module is turned off. This is also the only large spike that I have ever seen. I have checked and will attach a helicorder from swarm as well. The mystery spike is the red spike in the middle right-hand side. There are lots of other smaller spikes but I am positive that it is someone in a pool nearby.
Thanks for all of your help.
Could you post the logs from your Shakes? With them, we can try to look for a cause for these spikes you are experiencing.
RSH.RCEA5.2020-09-25T20_15_12.logs.tar (2.9 MB)
There you go!
Thank you @SouthernCAEarthquake!
From your logs, in particular from the
system.log file, this appears:
Sep 24 12:10:16 raspberryshake kernel: [1174915.925323] ttyS ttyS0: 1 input overrun(s)
In this case, your spike is caused by a missed data packet off the serial port, which can result in either a gap (when the entire 1/4 second data packet is dropped), or, as you have seen, a spike when a single data point is either dropped or corrupted.
Then, this spike is an artefact of the system components and not actually recorded noise.
Our latest Shake OS image (which you can download from here: https://gitlab.com/raspberryShake-public/raspshake-sd-img) contains some recent modifications to handle these
tty overruns. If you are interested in reducing these (false) data artefacts to the greatest extent possible, then you should consider downloading and installing the updated version.
Thank You very much @Stormchaser ! I would of never known that without you!
-Southern CA Earthquakes
I am reminded of an experience I had many years ago with a piece of industrial control equipment. Every few weeks (usually in the middle of the night!) it would throw off a really large analog reading for one program scan. It turned out that the vendor of the ADC chip had changed the spec so that one more wait state was needed somewhere in reading the value - otherwise you would sometimes lose the sign bit. Since the analog readout was in two’s complement, if you took a value just below the zero midpoint and removed the sign bit, you got a number that was quite near full scale. But just for one reading. The vendor of the equipment eventually figured it out and made a firmware change, fixing the problem.