Class set of Accelerometers


I wish to purchase a class set of accelerometers (15 of them), does anyone know of an accelerometer that works easily with the Photon, minimal hookups and few include files?

I presently have two boards:

MPU6050 6 DOF Gyro Accelerometer IMU from RobotShop


SparkFun Triple Axis Accelerometer Breakout - ADXL362

but neither are working, possibly broken (yes, I may have trashed both of them. Don’t ask :unamused: ),

I normally purchase a product, get it working and then purchase a class set of them, but in this case, I think I will just take a Photon Community Member’s suggestion of what to purchase.


I’ve had good luck with the ADXL362.

There are a couple different drivers for it, but I wrote one that uses the chip’s FIFO and DMA to get large numbers of precisely timed samples into the Photon/Electron efficiently. That’s probably unnecessary for a classroom project, but I thought I’d mention it anyway.


Looking at your code, I found my mistake with the SPI connection:

// Connect the ADXL362 breakout:
// VIN: 3V3
// SCL: A3 (SCK)
// SDA: A5 (MOSI)
// SDO: A4 (MISO)
// CS: A2 (SS)
// INT1: no connection
// INT1: no connection

Not having ran into the CS (A2) connection with SPI I simply ignored it, and that is why nothing was working! Anyone have words of wisdom about the CS connection.

Thanks @rickkas7

P.S. Nice work using the Node.js server to talk to the Photon.


The Chip Select (CS) or Slave Select (SS) is an active-low output from the Photon/Electron (SPI master) that indicates which SPI slave device on the SPI bus is the one that is currently being used.

When there is only one SPI slave device on the SPI bus, some devices will allow you to ground the SPI slave device’s CS/SS/EN pin and it will always be the active device. This is useful if you are short on GPIO pins on your Photon/Electron. But not all SPI slave devices support this.

When the CS/SS pin is high, the SPI device goes into high-impedance (HI-Z) mode on MISO (master in, slave out) pin so another SPI slave device that is the active one can write to this pin to send data to the Photon/Electron.


I have had huge success with the BNO055. I have minifed, ported, and published the library on GitHub.

The BNO055 is a bit more expensive than the Accelerometers you have listed, but it provides 9 degrees of freedom and it works solidly over I2C.


That looks really powerful. Thanks for the suggestion


What the heck are the numbers. Even if I average 10 readings they don’t make much sense. I was expecting a still board to have low numbers for all x, y and z axis (except maybe an easy to spot acceleration due to the earth’s motion).

The values I am getting look more like board positional values. If I tilt the board upside down, z goes from 1200 to -1200. Meaning I can find a location that it gives a near zero value (board tilted vertically). I can then rotate the board horizontally to get a near zero value for the x axis while the z axis is still near zero, but I can’t then get a near zero value for the y axis without messing up the near zero x axis.

As far as acceleration goes. Moving the board in x, y or z directions does change the readings ± 1000 but it does not seem to be very predictable. Could someone please shed some light on this accelerometer board behavior.


To get all three readings near zero, you’d need to have a constantly dropping (hence eternally accelerating with earth’s gravity) sensor or move your classroom into space :wink:

Gravity will always pull down, so at least one of the coordinate readings will reflect the gravitational pull.
Every body on earth gets this (downwards) accelleration, but the hard surface you probably have your device rest on counteracts that acceleration be an invers upwards force.

You may want to turn down the sensitivity of the sensor in order for gentle movements to cause less noise in your readings.


Thanks @ScruffR that explains the weird z value. (Really should have caught that myself, so much for my years of teaching Physics). I will look into how to set the sensitivity settings for the

to make it more useful.

P.S. If I divide the values by 100 do I get acceleration in m/s^2 ? That would be very usefull.

P.S.S. What do I divide the temperature reading to get Fahrenheit or Celsius. Either one I can convert to the other.


So with the communities help I am doing better. This code seems to work and is useful.

// This #include statement was automatically added by the Particle IDE.
#include <adxl362.h>

//#include “adxl362.h”

//#include <adxl362/adxl362.h>

//#include “adxl362/adxl362.h”

ADXL362 xl;

int16_t temp;
int16_t XValue, YValue, ZValue, Temperature;
float XValueF, YValueF, ZValueF;

void setup(){

xl.begin(SS); // Setup SPI protocol, issue device soft reset
xl.beginMeasure(); // Switch ADXL362 to measure mode


void loop(){

// read all three axis in burst to ensure all measurements correspond to same sample time
xl.readXYZTData(XValue, YValue, ZValue, Temperature);

// Convert to m/^s

XValueF = XValue/100.1;
YValueF = YValue/100.1;
ZValueF = ZValue/100.1;

Temperature = Temperature / 14.5;

Particle.publish(“Temp=”+String(Temperature, DEC)+" °C", String(“x=” + String(XValueF, DEC)+", y=" + String(YValueF, DEC)+", z=" + String(ZValueF, DEC)), 60, PRIVATE);


I get these results which seem good, x and y respond to motion and z stays constant at about -9 m/s^2

Two strange things:

  1. If I change my code to integer division

XValueF = XValue/100;
YValueF = YValue/100;
ZValueF = ZValue/100;

I get this strange result

Is that a particle bug or expected behavior for integer division to a float?


#2. The other issue is that printing values to 2 decimal places seems very old fashion and confusing. Could the Particle team just make some easier method such as

String myString = String(myFloat, DEC, 2); // for printing 2 decimal places

Just a suggestion, I am sure I can figure out the whole (snprintf, sprintf, Serial.println(longVal, 2), String(f).toCharArray(buf,10) ) standard ways of printing 2 decimal places.

V2 Libraries not auto loading

What do you expect?
Integer divisions don’t round they just use the integral values (without the decimal places) and divide that and the result will also not contain any information about the decimal places, so no rounding can happen.

What is old fashion?
If you have a reliable, flexible and safe tool (like sprintf()) replacing it with an (arguably) easier tool of limited use and more unwanted side effects might be modern, but maybe not better IMHO.

You couldn just write

sprintf(data, "x=%.2f, y=%.2f, z=%.f", x, y, z);

how would the same thing look with a “more modern” function?


Each year, only about 2 out of my 30 students are natural programmers. I will do anything to make the coding easier to understand so that my class becomes a problem solving class instead of a typing class. I am fairly fast at finding the things that the students will have problems with.

Most of the Particle community members will be natural programmers (or really hard workers) so I would expect little interest in these issues.

I have to teach String(x, DEC); as different from String(x, HEX) so why not teach String(X, DEC, 2); as formatting to 2 decimal places.

You and I have no problem with

sprintf(data, “x=%.2f”, x);

but 28 or my 30 kids will have a problem with it. I agree that any changes to the Particle code base will have growing pains. If Particle does not think it is worth the developmental costs, then that is fine with me.

Here is the Particle code

void setup() {

float y = 0.000;
int x = 3456;
y = x/100;
Particle.publish("y =",String(y), 60, PRIVATE);


Output: y = 34.000000

Here is PHP code


$y = 0.00;
$x = 3456;
$y = $x/100;

echo "y= $y ";


Output: y= 34.56

And here is a javascript version:

<input type=button value=divide onclick="{
y = 0.00
x = 3456

y = x/100


Alert box output: 34.56

I can live with this issue as just something the students need to know about C++, but it does seem a bit strange. The fix is fairly easy.

void setup() {

float y = 0.000;
int x = 3456;
y = x/100.0;
Particle.publish("y =",String(y), 60, PRIVATE);


Output: y =34.560001

Got to love the sneaky “1” at the 6th decimal place :kissing:


JS & PHP are really high level languages that hide away most of the bits and bytes that make a computer work.
C/C++ is a lot more low level, but hence way faster and powerful.

It might “seem” strange, but think back to your primary school time before you even heard of decimals. What did the teacher say was 10 / 3?
At least first we were told: "This doesn’t divide"
Later we got told: "It’s 3 with 1 remaining"
Only a while later we learnt what to do with that extra left over.

One integer variable has no way to say it’s 3 with 1 remaiming or 3.3333333333333333333333333333...
And the “sneaky 1” is something easily explained t(w)oo :wink:


If you ever get tired of tech, I am sure a few elementary schools would love to give you a job. :grinning:

As always, thanks for your help @ScruffR


I really should let this go as @ScruffR has summed it up really well, but (I am trying to teach my students to be persistent :wink: ) while looking for the opensource definitions of the String object, I found this entry last edited by @mdma

So it looks like the high level String object already has some sprintf style conversion abilities

I still like my suggestion for beging able to do something like

String(3.23567, DEC, 2) to make the number into the 2 decimal place string “3.24”

float myFloat = 3.23567;
String myFloatString = String(myFloat, DEC, 2); // for converting a float to a 2 decimal place string

Does anyone know where the opensource definitions for the String object are hiding, I would like to have a look at them.

I think it is actually here defaulted to 6 decimal places but I am not sure

This looks like I should be able to change the defaultPlaces somehow. I think I need to do some testing. Anyone have any ideas?

It kind of looks like String(3.23567,2); is already set to convert a float to a 2 decimal place string…

a few minutes later

void setup() {

float y = 0.000;
int x = 3456;
y = x/100.0;
Particle.publish("y =",String(y, 2), 60, PRIVATE);


prints out

Darn you Particle. The function was there all along. I have no idea how to put that in the DOCS, but it would be a good addition.


As per the conversation at

My Accelerometer code would now look like:

//connecting the ADXL362 breakout board

//**************************** Start Important Photon Information *********************************

// Connect the ADXL362 breakout SPI connections:
// VIN: 3V3
// SCL: A3 (SCK)
// SDA: A5 (MOSI)
// SDO: A4 (MISO)
// CS: A2 (SS)   If only one SPI board this can be grounded
// INT1: no connection
// INT1: no connection

// Must include the ADXL362 library from libraries.
// Search for ADXL362 and include it in this Application
// It will auto setup all dependcies and
// include a statment like the following at the top of the page. Only allow one of these statements.

// This #include statement was automatically added by the Particle IDE.
#include <adxl362.h>

//**************************** End Important Photon Information *********************************

ADXL362 xl;

int16_t temp;
int16_t XValue, YValue, ZValue, Temperature;
float XValueF, YValueF, ZValueF;

void setup(){

   xl.begin(SS); // Setup SPI protocol, issue device soft reset
   xl.beginMeasure(); // Switch ADXL362 to measure mode


void loop(){

   // read all three axis in burst to ensure all measurements correspond to same sample time
   xl.readXYZTData(XValue, YValue, ZValue, Temperature);

   // Convert to m/^s
   XValueF = XValue/100.0;
   YValueF = YValue/100.0;
   ZValueF = ZValue/100.0;

   // convert to degreees Celcius
   Temperature = Temperature / 14.5; 

   Particle.publish("Temp="+String(Temperature)+" °C", String("x=" + String(XValueF, 2)+", y=" + String(YValueF, 2)+", z=" + String(ZValueF, 2)), 60, PRIVATE);


Go to this page:
Click the Edit button at the top right :slight_smile:
You’ll need a github account and then you can click the pen button at the top right of the src in that page (by the delete icon).
Then submit a merge request back to Particle.

Also you found the headers. You need the src at:



Thanks for the steps @lbt . Finding the correct location to edit in the large file was a bit of a challenge, but I did submit a pull request at:


Just wanted to chime in to say that, although your valuable inputs are appreciated, inappropriate language is not. Do take note of our forum etiquette. :slight_smile:

Thanks @lbt!


@kennethlimcp, I’m pretty sure @rocksetta actually meant that “Darn you” more “ironic” with a :wink: wink rather than offensive.

But, I agree, if it wasn’t we’d oppose to this kind of language.
And to remove all doubt, we can encourage people to explicitly mark possibly misunderstandable expressions with fitting emojis or put them in quotes :sunglasses: