Well I have taken what is for me an unusual step of burying a raspberry pi.
However, now I have it in a physically quiet location I can see a great deal of electrical noise.
Before I pull the Shake apart an try and track it down, could somebody look at AM.R0099.00.EHZ
and confirm or allay what looks a real mess. The pi is a 3A+ with the wifi and BT turned off. the wifi is provided by a USB dongle located about a meter away from the pi.
Is there an example waveform that I could look at so that I can see what I’m aiming for?
oh my, you are correct, that is a messy signal, even though it’s well-organized.
the spikes you see every two minutes is the WiFi scanning the airwaves looking for any new networks that might be available. this makes a lot of sense when you’re on a phone and moving around, absolutely zero sense when the unit is stationary and every going to connect to a single network. unfortunately this is built into the driver and the maker did not provide an option to turn this “feature” off. are you absolutely certain your unit is using the WiFi dongle instead of the on-board WiFi?
the spikes you see every three seconds, i do not know about, but seemed to have stopped for the moment.
can you send your log files along so i can have a better look at what might be going on?
RSH.R0099.2022-12-28T12 06 17.logs.tar (493.5 KB)
please find the log tar attached. When I went to the shake to get the log the webserver element seemed to be hosed, but data was still flowing.
I rebooted by power clearing, and courtesy of the juice4halt it will have been shutdown gracefully.
Now that its running again the 3 second and the 3miute spikes are back with a vengance, when the rain stops I’ll recover the pi and fire it up on the bench and also get some ferite slugs for the usb and power leads. Although I cant see spikes getting through the buck boost section of the juice4halt.
I have checked at the os level to make sure that the onboard wifi and onboard bt is disabled:
txpower 31.00 dBm
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 31.00 dBm
It look to me that it is ??
i’m not sure what generated that output so i can’t really say what it “means”.
did you happen to see the manual page describing how to ensure that the internal WiFi is disabled? have a look here and confirm that everything is configured such that the internal WiFi is explicitly disabled.
after that’s done, if there’s still no change in the signal, please provide the output of the
iwconfig command and please attach again your log files.
Richard - iw is the Linux wireless device management tool (yes - there is a new one every 20 minutes!)
Strebor - This is what the same command gives on my device:
root@raspberryshake:/opt# iw dev
Nothing at all - looks like yours is configured/active - but you did say that you are using an external USB WiFi device … so this could be that. – I am using a WiFi device connected to the ethernet port.
As Richard said, check that the internal device is disabled, then maybe try a longer cable to move your WiFi device a bit further away?
Thanks for your replies,
I did read the wiki but just did what I have always done and disabled the onboard wifi by adding dtoverlay=disable-wifi
to the config.txt file. The man pages in overlays concur so I don’t think the leading pi3 is required in Buster.
I can see the link is week at at -77dbm so I will have to address that as well as stop the sprogs getting into the digitiser. The pi is a 3A+ so only has one USB port and no Ethernet, not that there is any at the slightly remote location. I may have to go down a different route for network.
Is there a way of me seeing the waveform from the digitiser locally, without sending it up to the cloud?
I found rsudp and think that will be my debug tool /…Strebor
rsudp will indeed work to display data coming directly from the Shake, but it doesn’t get you much more than display-only.
SWARM, downloadable from the
rs.local config app, will also display data directly off the shake, but has more ways to “investigate” the data, zooming, spectra, filtering, etc.
Thanks Richard, I’ll look at SWARM.
If you get a wifi bridge that has an ethernet input, you can connect that to the Pi’s ethernet port, which will disable wifi and help you diagnose if that is the issue.