Noise on BOOM

[orez]

When I started using the BOOM in 2021, as R571C_HDF, the helicord just looked like noise 24/7. Most probably I didn’t report this as I assumed this was what it looked like (the Shake was good).

More recently, operating as R877D_HDF, the BOOM started to show long periods of low noise (flat lines on the helicord), but had periods of noise and random drifts on the helicord. These tended to occur in blocks of a few hours and typically at similar times.

A couple of days ago there was a fireball that was recorded on a couple of BOOMs at greater distance from the event than mine, but my trace was swamped by one of these periods of noise. By this time, the periods of flat lining on the helicord had shown me there was an issue, but I never got around to requesting any assistance as to the issue. If it is a source external to the unit, it is nothing associated with activity on my property.

Attached are the current logfiles, some old logfiles from a time when the helicord was all noise, and a few recent helicords.

RSH.R877D.2025-04-22T22_18_25.logs.tar (3.6 MB)

RSH.R571C.2021-10-14T12 32 18.logs.tar (3.5 MB)

[Stormchaser]

Hello orez,

Thank you for providing the detailed feedback, the logs, and the screenshots from the infrasound sensor.

Indeed, there are some periods in which everything is working perfectly fine

And then the output translates to nothing, as shown below:

From your logs (in both sets), these lines indicate the possible cause of the issue:

2025 112 18:48:50>>	No Data has been received from the MCU in 12 read attempts.It appears the MCU is not transmitting data.  This is a fatal condition and should be investigated if this condition persists!
2025 112 18:48:50>>	Data has been successfully received, fatal condition resolved.
2025 112 18:48:50>>	internal error: buffer overflow!  cannot process read data...
2025 112 18:48:50>>	buf: {zBDL2D#FTf;
2025 112 18:48:50>>		16346	304

In such cases, we recommend our standard troubleshooting path, which I have attached below.

My first thought (and the probable cause of the issue) would be to check and see if the current power supply you are using is continuing to deliver a stable voltage between 5.0 and 5.2V and a current of at least 2.5A at all times (3.0A if the Raspberry Pi board that is being used is a RPi4), as a decrease in power could lead to data services interruption. If possible, connect the Shake to a single wall socket (or try different ones to see if there is a difference). And, if you have another Pi power supply that you know is in working condition, please try exchanging the current one with that and see if the Shake now works correctly for extended periods.

A second check that you can do is to see if all the connections between the sensor, the blue Shake board, and the Pi board are still solid and free from dirt or any other element that could compromise transmission. If you decide to disassemble the Shake during this process, please ensure you are using proper ESD (ElectroStatic Discharge) protection, such as gloves, to prevent damage from static electricity, as electronics are sensitive to this type of energy.

As a last resort, and if all these checks come out as positive, then I would recommend re-burning the microSD card again (or using a different microSD) after formatting and erasing all its data/partitions first (you can use DISKPART for this as it is very efficient), and see how the Shake behaves with the newly installed system, removing potential issues derived from corrupted files. I will leave the burning instructions link here for your convenience: microSD card topics.

Thank you for your collaboration.