Weird problem with ADXL345, Buzzer and Arduino

Question

I've set up a Serial port via a Bluetooth module (HC05). I'm using a JavaFX app that I wrote to read the serial port, plot the acceleration values (via ADXL345) and write back to the serial port an alarm bit (1 for ON and 0 for OFF) whenever a certain function of accelX reaches over a value.

The weird part is, whenever Arduino detects ON bit and turns on the buzzer, my acceleration values become quite noisy! I've checked my codes both in Arduino side and Java side and couldn't find a problem.

Then I put a LED instead of buzzer and to my surprise it turned on without interfering with accel. readings !!

I really don't know what is the problem with buzzer. Can anyone help?

Here is my suspicion:
I'm using a break out board for ADXL345. I'm not sure whether it can tolerate 5 volts. I connected Uno's 3.3 volt to it's Vcc and I'm using I2C for communications. (with two 4.7k pull-up resistors connected between it's SDA and SCL pins and Uno's 3.3v).
Could it be that the buzzer when turned on somehow draws so much current that interferes with those pull up resistors?

Here is the photo of my setup (the lower red line is 3.3v and upper red line is 5 vols both coming from Uno. All grounds are connected together):

And here is the readings of accels. in IDLE:

And I get these reading out of Serial Port:

But whenever I tilt the breadboard (limit for alert is 20 degrees), it correctly beeps, but due to noisy accelerations, buzzer starts, stops, starts in a random pattern:

Answer 1

To expand from my comment:

This could easily be due to the buzzer itself: either physical vibration or EM noise. The fact that replacing the buzzer with an LED supports this as the LED gives no physical movement, and draws a nice steady amount of current. As the buzzer is on the same bread board as the LED, it is mechanically rigid to the sensor, while also being electrically close, and so it is tricky to say which out of physical or EM noise is more likely (my hunch would be physical movement which is easier to cause and easier to cure).

To confirm that it is the buzzer that is causing the issue I would recommend connecting the buzzer via some flying leads. This will mechanically isolate the buzzer from the sensor. When the test is repeated, if the sensor does not give the "funny" reading you are seeing now, the mechanical movement of the buzzer is the cause. The cure for this is then simple: mechanically isolate the buzzer from the sensor (put one or other or both on flying leads). If that is not something you can do for your application, you can either dampen the buzzer signal (using rubber mountings) or you could change your software to filter out the noise (which is often done using over-sampling and taking the mean of the data).

You have replied to my comment saying that the flying leads fix the issue, so you now have various options: Mechanical: isolate the buzzer from the sensor in any way you like (flying leads, rubber mountings) Software: sample the data and filter out fast changing values (averaging over a set period of time is the easiest) Hardware: use a different sensor that samples at a slower rate (so can't pick up the motion from the buzzer). If you are using a different sensor with an analogue output, you could filter the output, with a simple capacitor.

As this appears to be mainly a software project, I would go for a basic software filter. The specifications of it will depend on your application; speed of response to change, fasted change you want etc. You can go a long way with filtering, depending on your application, using; averaging, rate of change, frequency matching, debouncing.