The problem is that you are using a MEMS digital accelerometer, and what you are reading is the SCK (serial clock) pin of the serial interface. In order to function, that sensor needs to be interfaced with a microcontroller, that sets it for the sampling frequency, the range and so forth.
So you don't have to expect a square wave with 100Hz frequency, but a fast (depending on the bus bitrate) spike, corresponding to a transmission. Expanding the spike, if the scope is fast enough, you should then see the clock square wave inside the spike.
Moreover, if you don't set the SPI interface correctly, the uC will not generate the clock (the sensor operates in slave mode), and you won't read any value.
If you want to see a 100Hz signal, you could probe the Int pin, which sends an interrupt to the microcontroller every time a measure is available. Then, if you handle the interrupt from the microcontroller properly, you wil see the pulse corresponding to the transmission every 10 ms (100Hz).
But make sure that you're not using motion detection; in that case, only when an acceleration is measured, it will generate the interrupt.
To read the data at the SPI port, the simplest thing is to configure the communication with the sensor; otherwise, it won't send data at all. Then, check if the microcontroller is getting the interrupts and if it's reading the data the sensor gives; you can use a timer to add a timestamp to values and check the frequency they come.
(still WIP)
The real problem is always the simplest. Generally you have a lot of noise on these sensors and you just need to make sure you know what you need to filter. A quick noisy pulse on the sensor can lead to an extremely high-g reading since there is not a lot of mass attached. If the board is susceptible to noise in one area you may be receiving a constant pulse to one side. Though it looks like you are doing some filtering I would suggest running a median filter before getting the angle to insure these high-g impulses are taken care of.
In addition, I would like to point out the sampling rate of your sensor. Look at the ODR of the sensor. Though the accelerometer has an ODR of over 1kHz, the magnetometer is limited down at 220Hz. If you want to do anything past this angle detection, I would suggest getting a low-g/gyro sensor. This will allow you do do fun rotation projects. The magnetometer can be used for this but comes with a ton of shielding problems and far to slow an update rate with given ODR.
Best Answer
The device containing the accelerometer is experiencing a force (of
x G) momentarily, against the direction of acceleration, when the motion starts. Then it will experience0 Geesas acceleration stops, i.e. once the target speed has been achieved.Similarly, when bringing the device to a standstill from constant velocity, it will experience a momentary force opposing the deceleration, then zero force again once it comes to a standstill.
That is what your experiment reports - the LEDs flash when the acceleration is experienced, once in each direction. In other words, the behavior is as designed.
For keeping an indication on as long as motion continues, an accelerometer is not the ideal device. It is not a motion detector, it is an acceleration detector, as the name implies.
While some simple software trickery (integrating the acceleration over time) could be used to track when acceleration is felt in one direction or the other, such a mechanism would fail if the deceleration (or acceleration) force is very low compared to the sensitivity and sense signal noise floor, such as if one were to accelerate the device very sloooooowly, but bring it to a halt rapidly, or vice versa.