Spikes in data collected with rpi3

I have two different raspi3s in different locations, 100m appart in different buildings. Ruuvi Collector on both and they are collecting to my “own cloud” where I have InfluxDB and grafana.

To the problem, I have spikes in data from one of my two raspis. I have 5 tags in one location and one tag in the other location. I never have any type of spikes in data at my home location (5 tags) but on the other location (1 tag) I always have spikes in data. If I take one tag from my home location and put it in the other location both get spikes, so the tag itself is not the problem its the raspi and collector.

In this picture I changed the location on garaget tag to the other location at the black line and as you see, after an hour I have spikes in both.

There are one difference in the RPI setups, the one at home has the ruuvi image, the other pi (problem pi) is made according to this guide: https://github.com/bostrom/ruuvi-on-aws/ @bostrom

Anyone having similar problems? Any ideas how to fix this issue?

/Andre’

I have the same issue with a ruuviberry image updated to “Raspbian GNU/Linux 9.9 (stretch)”.
But the one at “Raspbian GNU/Linux 9.3 (stretch)” does not show those “spikes”.
For example battery voltage values can be as large as 64.438 volts, which is impossible considering that the nominal battery voltage of CR2477 is three (3) volts.
IMHO newer the Raspbian, more there are errors in the readings.

From another post where similar problems where found.

in english, otso believes that there could be several programs running that trying to use BT on the RPI and that could in some way create the bad data.

how can I be sure I don’t have several apps using BT, so I could eliminate that possibility for error? I’m no linux guru, in other words no ide how to check that from the console.

/Andre’

Do you have the most recent version of ruuvi collector?


v0.2.5

@Scrin Scrin released this on Jun 26

  • Improved error tolerance while parsing for raw data

Closed Issue#23 # Provide better logging on unexpected behavior

++++++++
Although I frequently run multiple hcidump commands I have not seen this problem.

ps -el|grep hci # display any processes running Blue Tooth stuff (hopefully)

Can you find any errors in /var/log ?

grep ' RuuviCollector' /var/log/*log |tail -100

++++++
What is you skill level? linux, influx
++++++
Perhaps displaying the exact data stored in the influx database might provide some clues:
influx -precision rfc3339 -database ruuvi -execute "select mac,temperature from ruuvi_measurements where temperature < 20 group by mac limit 50"

I did some digging around and found and ended up here. I dropped the bluetooth uart speed to half, and it worked for me, e.g. no bluetooth errors in dmesg output in the last eight hours, and the spikes have gone from Grafana.

$ sudo -i
# cp -pi /usr/bin/btuart /usr/bin/btuart.orig
# sed -e 's/921600/460800/g' < /usr/bin/btuart.orig > /usr/bin/btuart
# diff -u /usr/bin/btuart.orig /usr/bin/btuart
--- /usr/bin/btuart.orig        2018-10-29 14:02:08.000000000 +0200
+++ /usr/bin/btuart     2019-08-09 22:12:36.026493166 +0300
@@ -15,7 +15,7 @@
        if [ "$uart0_pins" = "16" ] ; then
                $HCIATTACH /dev/serial1 bcm43xx 3000000 flow - $BDADDR
        else
-               $HCIATTACH /dev/serial1 bcm43xx 921600 noflow - $BDADDR
+               $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
        fi
 else
        $HCIATTACH /dev/serial1 bcm43xx 460800 noflow - $BDADDR
# shutdown -r now
1 Like

great, I made these changes this morning, let’s see how it works out. I’ll let you know.

no spikes since the change. Thanks!

1 Like