Helpful ReplyHot!SPI with PIC16F18345

Page: < 12345.. > >> Showing page 5 of 6
Author
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 02:33:23 (permalink)
0
qɥb
I would have expected 0 to -255.
Are you saying it instantly change from 0 to -255 when you rotated past 180 degrees?

0- -255 from 270 to 360

and I would have expected -255 to 0 here, you are back to where it was measuring zero before you started.




Sorry qhb, I tested it again. Yes it is changing  as you are saying.
0-255        upto 90 degrees
255-0        from 90 to 180
0- -255     from 180 to 270
-255 - 0    from 270 to 360
but how to calculate the angle here i am very confused.

'//'A'lone Employee'
#81
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 02:39:05 (permalink)
0
You can't do it from a single sensor.
You have to use two, then it is simple trigonometry using an inverse tangent function.
https://en.wikipedia.org/wiki/Trigonometric_functions#Sine,_cosine,_and_tangent
 

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
#82
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 02:42:42 (permalink)
0
Is it? do i really need to use two sensors sad: sad then why so many people are saying that they are getting the values in the internet are they also using two sensors??????????????????. just asking.

'//'A'lone Employee'
#83
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 02:47:49 (permalink)
0
when i am moving anti clock wise
0- -255     
-255 - 0     
0 - 255      
255 - 0
 

'//'A'lone Employee'
#84
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 05:21:56 (permalink)
0
I think you misunderstood. You have three sensors: X, Y, and Z
You have to use two of them to work out angles in that plane.
There are three pairs, one for each of the three planes.

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
#85
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/03 05:28:54 (permalink)
0
got your point i will work on it.

'//'A'lone Employee'
#86
brownt
Super Member
  • Total Posts : 296
  • Reward points : 0
  • Joined: 2015/11/21 14:58:09
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 02:17:17 (permalink)
+1 (1)
Now that it seems to be working, you might be better of trying a forum that specialises in sensors.
 
Internet search for "arduino sensor forum"
 
You can use the X and Y axes to determine the angle, but at around 90 degrees things won't work that well.
If you use X, Y and Z you will get more accurate readings at extreme angles.
 
The acceleration figures read from the device need to be divided by a value relative to the G force settng on the ADXL345. For example the datasheet says if you set the ADXL for 2g, then it has 10 bits to represent 2G. 10 bits is 0 - 1023. So, a reading of 511 = 1g and a reading of 1023 = 2g. So, at the 2g setting you would divide by 512. 512/512 = 1g. 1024/512 = 2g.
 
At 1g (90 degrees) the combined low and high registers should be reading 512. If you are only getting 255 then I guess only the low register is being read. Even when it is flat, the Z axis should be reading 1g all the time. The force of gravity.
 
After you have the correct G force reading, some formulae are -
//using two axes
pitch = atan2(accele_x, accele_z) * 57.2958;
roll = atan2(accele_y, accele_z) * 57.2958;
 
//or using all three axes
pitch = atan(accele_x / sqrt(accele_y * accele_y + accele_z * accele_z)) * 57.2958;
roll = atan(accele_y / sqrt(accele_x * accele_x + accele_z * accele_z)) * 57.2958;
 
//atan2() returns an answer in radians, so multiply by 57.2958 to get degrees.
 
//FYI
totalAccelerationInAnyDirection = sqrt(accele_x * accele_x + accele_y * accele_y + accele_z * accele_z);
 
It would be great if you could read Yaw (heading) as well, but you need an e-compass as well for that. Or a gyroscope, but that gets out of sync pretty quick.
post edited by brownt - 2018/02/04 02:26:29
#87
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 02:50:25 (permalink)
0
Thank you brownt. You have given me a clear explanation.

'//'A'lone Employee'
#88
davekw7x
Entropy++
  • Total Posts : 1692
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 09:31:02 (permalink)
+1 (1)
brownt
....
The acceleration figures read from the device need to be divided by a value relative to the G force settng on the ADXL345. For example the datasheet says if you set the ADXL for 2g, then it has 10 bits to represent 2G. 10 bits is 0 - 1023. So, a reading of 511 = 1g and a reading of 1023 = 2g. So, at the 2g setting you would divide by 512. 512/512 = 1g. 1024/512 = 2g.
 

Well, I tried to stay out of it, but sometimes I just can't help myself...
 
The value that the OP wrote into the DATA_FORMAT register in his most recent post indicates he is operating in the "full resolution" mode, and the resolution is nominally 256 LSB/g for all ranges.  In other words, I would expect values in the neighborhood of 256 to indicate 1 g.  (If we wanted to print out the value in units of g we would divide the reading by 256.0, but I have never needed to display this; just used the readings and their ratios.)
 
As I indicated in my previous post, I expected and I observed values in the neighborhood of +-256 as maximum and readings as I rotated the device, and here's why I said "in the neighborhood."  This is still the case with the OP's settings.  (Tested.)
 
First of all, it's a mechanical device, and even though they are supplied with factory calibration, there may be some offsets in the readings, slightly above or below the nominal values.  That is 256 might not mean exactly 1g.
 
Also, and this might be more important:
As indicated in the data sheet, the device is factory calibrated at an operating voltage of 2.5V.  If we are operating at 3.3V, there are offset values in the X-Axis and Y-Axis that result in values typically 25 mg higher than the offsets at 2.5V, and the Z-axis offset is typically 20 mg lower.  Without compensating for offset values, the readings might be "a little" off.  The Offset Registers allow calibration information to be stored.  This is described pretty carefully in the Data Sheet.
 
Bottom line: In addition to the Data Sheet, which contains all of this information, there are some relevant App Notes from Analog Devices, as suggested by qɥb some few posts ago (+1).  I could give links, but maybe the OP will want to poke around and find some others that also might be helpful.
[Edit]
But, for initial testing, maybe ignore the offsets and see if the math gives reasonable inclination values about X-Axis and/or Y-Axis and refine the readings with Offset Calibration later if it is perceived to be useful.  (Assuming x-values and y-values go from "about" -256 to "about "+256")
[/Edit]
 
I would start with:
    ADXL345 Data Sheet Rev E.
    AN-1077 ADXL345 Quick Start Guide
    AN-1057 Using an Accelerometer for Inclination Sensing
 
Both of these App Notes are listed under the "Documention" heading near the beginning of the Data Sheet
 
Regards,
 
Dave
post edited by davekw7x - 2018/02/04 10:43:57

Sometimes I just can't help myself...
#89
brownt
Super Member
  • Total Posts : 296
  • Reward points : 0
  • Joined: 2015/11/21 14:58:09
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 14:35:48 (permalink)
0
256 per g, fair enough. What happens to the other bits when in say 2g 10 bit full resolution mode?
 
(If we wanted to print out the value in units of g we would divide the reading by 256.0, but I have never needed to display this; just used the readings and their ratios.)
 
The reason of have converted to g's previously before calculating the angle is because either atan2(), atan() or sqrt() was not able to handle the size of the numbers, though that was with a 16 bit device accelerometer, perhaps 13 bit would be ok.
#90
davekw7x
Entropy++
  • Total Posts : 1692
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 17:05:41 (permalink)
0
brownt
256 per g, fair enough. What happens to the other bits when in say 2g 10 bit full resolution mode?
 

All ranges full resolution: 256LSB/g (nominal)
2g 10-bit resolution same as 2g full resolution: 256LSB/g (nominal)  valid values, +-2g, will be -512 to 512,
which is 16-bit twos complement 0xFE00 - 0x0200.  Remember, with offset errors, the values might be "a little" beyond the nominal range.  I note that since I assume the application is for devices operating at 1g, using the higher ranges make no sense.
 
If you are going to use the arcsin formula, obviously the domain must be normalized to [-1,1].  The simplest way to get started with the inclination problem is just to peg the readings at +-256.  Since the precision is not very good near +-90 degrees, where the largest amplitude readings occur, you aren't increasing the error much by using factory calibrated units and imposing hard limits of +-256 on the readings.  If more accuracy is required, the Data Sheet and App Notes talk about calibration.
 
My point here is not to go into how the readings are going to be used (the OP didn't mention this, and this is probably the most important part of the Marketing Specification Document).  The idea (at least my idea) is to try to help the OP (and others) to get to the point of reading x,y,z values as needed from the ADXL325.
 
Do the readings one at a time for now and try one of the formulas in App Note AN-1057 to see how it goes.  Then refine the measurements and/or calculations to get it to meet your needs.
brownt
The reason of have converted to g's previously before calculating the angle is because either atan2(), atan() or sqrt() was not able to handle the size of the numbers.




For test purposes, I use floating point calculations and standard <math.h> library functions.  I can squeeze the stuff for reading and calculating and even printing floating point into a PIC16F18345, but I would use a '346 for my own development.  (Actually, as I mentioned, my project was on a PIC24.)  I would begin testing with something like the following using 256LSB/g resolution.
        // xyz_values[] is an array of three 16-bit signed ints.
        // The function read_adxl_xyz() reads the six data bytes into the three ints
        // using the multiple-byte scheme to get all of them in a single
        // transaction.
        //
        // For this test I am using 24-bit doubles
        //
        // I use rtiltx to hold the value of inclination (tilt) angle in radians.
        // I use dtiltx to hold the value of tilt angle in degrees.
        read_adxl_xyz(xyz_values);
        x = xyz_values[0];
        y = xyz_values[1];
        z = xyz_values[2];
        printf("(x,y,z) = (%4d,%4d,%4d)\n", x, y, z);
        if (x > 256) {
            x = 256;
        }
        else if (x < -256) {
            x = -256;
        }
        if (z > 256) {
            z = 256;
        }
        else if (z < -256) {
            z = -256;
        }
        // Single axis formula is simplest, but not very sensitive to
        // changes near 90 degrees or -90 degrees.
        // Starting with z-axis straight up, as the front is tilted up,
        // the result goes from 0 to 90 degrees.  As it is tilted more,
        // i.e. greater than 90 degrees, it starts back down again.
        // So, for example, 135 degrees reads 45 degrees.
        // Tilting the front down makes the readings go negative.
        //rtiltx = asin((double)x/256.0);

        // This 2-axis formula is also good for -90 to +90 degrees.  Now
        // if it is tilted greater than 90 degrees, the result becomes negative.
        // For example, 135 degrees reads -45 degrees.
        //
        rtiltx = atan((double)x / (double)z); // Radians
 
        // For either calculation, print the value in degrees
        dtiltx = rtiltx * 180.0 / M_PI;       // Degrees (M_PI is #defined in <math.h>)
        printf("X-axis is tilted %f degrees\n", dtiltx);

 
It ain't necessarily pretty, and is definitely not for production (I didn't test for zero before dividing in the two-axis formula, for example), but maybe it's a start, once the thing about reading x, y, z values is implemented correctly (and, of course, tested).
 
[Edit]
With the two-axis formula, just holding the ADXL345 breakout board in my hand and tilting it slowly I see the following.  My test program takes readings every second.
(x,y,z) = (   5,   9, 216)
X-axis is tilted 1.326048 degrees
(x,y,z) = (   4,  26, 215)
X-axis is tilted 1.065826 degrees
(x,y,z) = (  21,  19, 214)
X-axis is tilted 5.604256 degrees
(x,y,z) = (  56,  17, 208)
X-axis is tilted 15.068360 degrees
(x,y,z) = (  84,  27, 204)
X-axis is tilted 22.379880 degrees
(x,y,z) = ( 103,  28, 194)
X-axis is tilted 27.965328 degrees
(x,y,z) = ( 126,  38, 181)
X-axis is tilted 34.843744 degrees
(x,y,z) = ( 156,  35, 164)
X-axis is tilted 43.567376 degrees
(x,y,z) = ( 178,  33, 128)
X-axis is tilted 54.280272 degrees
(x,y,z) = ( 191,  37, 125)
X-axis is tilted 56.796880 degrees
If you are checking these with some external program...
Note that my 24-bit doubles are only good for three or four significant decimal digits even though I printed out with the default six decimal digits after the decimal point.  (There is a difference between significant digits and correct decimal digits.)  This with XC8 version 1.44 (Free mode)
[/Edit]
 
Regards,

Dave
 
post edited by davekw7x - 2018/02/04 17:20:28

Sometimes I just can't help myself...
#91
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/04 23:12:26 (permalink)
0
davekw7x
brownt
....
The acceleration figures read from the device need to be divided by a value relative to the G force settng on the ADXL345. For example the datasheet says if you set the ADXL for 2g, then it has 10 bits to represent 2G. 10 bits is 0 - 1023. So, a reading of 511 = 1g and a reading of 1023 = 2g. So, at the 2g setting you would divide by 512. 512/512 = 1g. 1024/512 = 2g.
 

Well, I tried to stay out of it, but sometimes I just can't help myself...
 
The value that the OP wrote into the DATA_FORMAT register in his most recent post indicates he is operating in the "full resolution" mode, and the resolution is nominally 256 LSB/g for all ranges.  In other words, I would expect values in the neighborhood of 256 to indicate 1 g.  (If we wanted to print out the value in units of g we would divide the reading by 256.0, but I have never needed to display this; just used the readings and their ratios.)
 
As I indicated in my previous post, I expected and I observed values in the neighborhood of +-256 as maximum and readings as I rotated the device, and here's why I said "in the neighborhood."  This is still the case with the OP's settings.  (Tested.)
 
First of all, it's a mechanical device, and even though they are supplied with factory calibration, there may be some offsets in the readings, slightly above or below the nominal values.  That is 256 might not mean exactly 1g.
 
Also, and this might be more important:
As indicated in the data sheet, the device is factory calibrated at an operating voltage of 2.5V.  If we are operating at 3.3V, there are offset values in the X-Axis and Y-Axis that result in values typically 25 mg higher than the offsets at 2.5V, and the Z-axis offset is typically 20 mg lower.  Without compensating for offset values, the readings might be "a little" off.  The Offset Registers allow calibration information to be stored.  This is described pretty carefully in the Data Sheet.
 
Bottom line: In addition to the Data Sheet, which contains all of this information, there are some relevant App Notes from Analog Devices, as suggested by qɥb some few posts ago (+1).  I could give links, but maybe the OP will want to poke around and find some others that also might be helpful.
[Edit]
But, for initial testing, maybe ignore the offsets and see if the math gives reasonable inclination values about X-Axis and/or Y-Axis and refine the readings with Offset Calibration later if it is perceived to be useful.  (Assuming x-values and y-values go from "about" -256 to "about "+256")
[/Edit]
 
I would start with:
    ADXL345 Data Sheet Rev E.
    AN-1077 ADXL345 Quick Start Guide
    AN-1057 Using an Accelerometer for Inclination Sensing
 
Both of these App Notes are listed under the "Documention" heading near the beginning of the Data Sheet
 
Regards,
 
Dave


Yes, by using 2 axis also we can get the values by using its sign values according to the quadrants. i have studies the app note which you have given. I clearly understood now what is happening in the accelerometer.

'//'A'lone Employee'
#92
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/06 00:30:28 (permalink)
0
brownt
 
//using two axes
pitch = atan2(accele_x, accele_z) * 57.2958;
roll = atan2(accele_y, accele_z) * 57.2958;
 
//or using all three axes
pitch = atan(accele_x / sqrt(accele_y * accele_y + accele_z * accele_z)) * 57.2958;
roll = atan(accele_y / sqrt(accele_x * accele_x + accele_z * accele_z)) * 57.2958;
 
 


Getting 0 - 180 and -180 - 0 when i am using two axis 
Getting only +- 90 degrees when i am using all three axis. 
 
brownt
 
The reason of have converted to g's previously before calculating the angle is because either atan2(), atan() or sqrt() was not able to handle the size of the numbers, though that was with a 16 bit device accelerometer, perhaps 13 bit would be ok.


Yes, I got '0' from o to 45 degrees in any axis.

'//'A'lone Employee'
#93
brownt
Super Member
  • Total Posts : 296
  • Reward points : 0
  • Joined: 2015/11/21 14:58:09
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/06 16:08:39 (permalink)
0
Yes, i believe that is the way it is supposed to be. I guess there is some advantage with three axes in regards to accuracy at extreme angles, though I am not sure about that.
#94
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 04:14:38 (permalink)
0
Everything is okay, why my "printf" is very slow. When i am printing a string it is working like a charm. But when i used "ftoa " and sending through "printf" , it becomes slow why?
 
pink: pink
 
i am using 1Mhz 

'//'A'lone Employee'
#95
qɥb
Monolothic Member
  • Total Posts : 3332
  • Reward points : 0
  • Joined: 2017/09/09 05:07:30
  • Location: Jupiter
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 04:19:53 (permalink)
0
All floating point is relatively slow on an 8 bit processor.
 

This forum is mis-configured so it only works correctly if you access it via https protocol.
The Microchip website links to it using http protocol. Will they ever catch on?
PicForum "it just works"
#96
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 04:36:33 (permalink)
0
Okay, but i am printing a string here.

'//'A'lone Employee'
#97
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 06:02:13 (permalink)
0
i am just printing a string here. why it is taking time. If i print a string in a loop it is fine. while printing after taking the readings it is taking time.?????????

'//'A'lone Employee'
#98
jack@kksound
code tags!
  • Total Posts : 3154
  • Reward points : 0
  • Joined: 2014/05/14 10:03:19
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 08:31:09 (permalink)
0
Which part is "taking time"? The ftoa() function or the printf() function? ftoa() IS a floating point function, floating point functions ARE SLOW on 8 bit processors.
#99
ram1723
Starting Member
  • Total Posts : 78
  • Reward points : 0
  • Joined: 2018/01/16 22:27:23
  • Location: 0
  • Status: offline
Re: SPI with PIC16F18345 2018/02/07 09:44:22 (permalink)
0
jack@kksound
Which part is "taking time"? The ftoa() function or the printf() function? ftoa() IS a floating point function, floating point functions ARE SLOW on 8 bit processors.

Okay how to overcome this. I used my own function to change float value into string. Still it is taking time to print.
What to do now?

'//'A'lone Employee'
Page: < 12345.. > >> Showing page 5 of 6
Jump to:
© 2019 APG vNext Commercial Version 4.5