Post Go back to editing

ADIS16365 interface with dsPIC

Hi everyone , it's the first time to me here.. i have a strange problem ..

i am working on ADIS16365 interface with dsPIC , I wrote a code to extract all these data :

1- Power supply measurement

2- x,y,z gyroscope output

3-  x,y,z accelerometer output

4 - x,y,z gyroscope temperature output

i read all these data correctly except accelerometer y output , it gave a strange output

i used the same methods and calculations with accelerometer x and z and there wasn't any problem , i didn't use burst mode to extract these data ,  i send a command every time

for example , i used  this part of code to read accelerometer x :

         SPI2_Write(0x0A00);                        // Send data via SPI

          delay_us(25);

          XGValue = SPI2_Read(buffer);              // Read the MSByte

          info[4] = (XGValue & 0b0011111111111111); //Strip off the ND and EA flags

so, any help ?

Parents
  • Thank you for sharing this! To be honest, I am stumped.  Pins 22, 23 and 24 offer access to the analog portion of each accelerometer's signal chain.  This had utility in an early application, but when we discovered that it was so easy to introduce undesirable influence, we decided to make these pins into "no connect" lines. Since you have two units, which are doing the exactly the same thing, on the same axis, while the rest of the device continues to work well, it is hard to imagine this as some sort of random failure event.  Is there any chance the units were subjected to any handling or application shock that is beyond the rated levels in the datasheet?  I am not sure what else to look at, but if you are convinced that you are doing everything correctly in the digital signal processing portion of your system, we do have a failure analysis service, which you can request, through your original point of sale.  Since that group does not use this forum for their inputs, you will want to provided a clear summary of your observations, methods and data (with annotations to make highlights easy to find).  When our F/A team has little or no description of the behavior, they are very limited in what they can do.  You can reference this discussion, but it would help to make sure that a link to this discussion is included in the F/A request form.   

Reply
  • Thank you for sharing this! To be honest, I am stumped.  Pins 22, 23 and 24 offer access to the analog portion of each accelerometer's signal chain.  This had utility in an early application, but when we discovered that it was so easy to introduce undesirable influence, we decided to make these pins into "no connect" lines. Since you have two units, which are doing the exactly the same thing, on the same axis, while the rest of the device continues to work well, it is hard to imagine this as some sort of random failure event.  Is there any chance the units were subjected to any handling or application shock that is beyond the rated levels in the datasheet?  I am not sure what else to look at, but if you are convinced that you are doing everything correctly in the digital signal processing portion of your system, we do have a failure analysis service, which you can request, through your original point of sale.  Since that group does not use this forum for their inputs, you will want to provided a clear summary of your observations, methods and data (with annotations to make highlights easy to find).  When our F/A team has little or no description of the behavior, they are very limited in what they can do.  You can reference this discussion, but it would help to make sure that a link to this discussion is included in the F/A request form.   

Children
No Data