CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Gyro XV 3500CB angular rate sensor , i really need some help
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

Gyro XV 3500CB angular rate sensor , i really need some help
PostPosted: Tue Jan 31, 2012 7:20 am     Reply with quote

Hello ccs community,

Anyone here already used gyroscope XV 3500CB ?? I'm looking for some support with this component.

Battery David



Joined: 01 Feb 2010
Posts: 25

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 8:14 am     Reply with quote

Did you know there's a web forum for the manufacturer of the module?

http://www.sureelectronics.net/forum/index.php
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 8:56 am     Reply with quote

EDIT: needed to cut this thread

Last edited by Chaud on Wed Mar 21, 2012 10:21 am; edited 1 time in total
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 10:29 am     Reply with quote

This module is a rotation *rate* gyro detector. Its output is proportional to the rate of change of angle, not the angle itself. So, you get an output as you twist it, +ve for one way, -ve for the other. As soon as you stop twisting the output returns to the 1.35V quiescent state. To get the angle you would have to integrate the output of this sensor.

To get it to work well you probably need to do some analogue signal conditioning: amplifying and possibly filtering. What is the maximum rate of change of angle you are expecting? say its 90degrees/second, if so you amplify and offset the output of the sensor to make +/-90deg/sec equivalent to your ADC range, say 0-5V. The sensor gives you 0.67mV/degree/second with a 1350mV nominal offset. So 90deg/sec is 60.3mV. +/-90deg/sec is 120.6mV and you probably want that to be 5V, so you need gain of 41.46, and you'll have to offset it from 1.35V to 2.5V. All straightforward analogue stuff. I'm not saying these are the numbers you need, you'll have to decide what you really need for yourself and design your circuit to give it to you.

RF Developer
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 11:05 am     Reply with quote

RF_Developer wrote:
This module is a rotation *rate* gyro detector. Its output is proportional to the rate of change of angle, not the angle itself. So, you get an output as you twist it, +ve for one way, -ve for the other. As soon as you stop twisting the output returns to the 1.35V quiescent state. To get the angle you would have to integrate the output of this sensor.

To get it to work well you probably need to do some analogue signal conditioning: amplifying and possibly filtering. What is the maximum rate of change of angle you are expecting? say its 90degrees/second, if so you amplify and offset the output of the sensor to make +/-90deg/sec equivalent to your ADC range, say 0-5V. The sensor gives you 0.67mV/degree/second with a 1350mV nominal offset. So 90deg/sec is 60.3mV. +/-90deg/sec is 120.6mV and you probably want that to be 5V, so you need gain of 41.46, and you'll have to offset it from 1.35V to 2.5V. All straightforward analogue stuff. I'm not saying these are the numbers you need, you'll have to decide what you really need for yourself and design your circuit to give it to you.

RF Developer


Hey RF Developer, thanks for reply, the first part you are right and i get it already, how to integrate and get the angle.

I am expecting like 1~3 degrees variation detection.

About second part i heard i can use I2C interface to obtain a much bigger resolution than ANA0(analog output).

The I2C interface pins are pin1 (IICCLK) and pin 2 (IICDAT) , to be honest i never used I2C interface before, do you know how i use it with PIC 18F2550? i saw this CCS example:

Code:
/*
This configures two I2C ports, each has a different stream name.
*/
#use i2c(sda=PIN_C4, scl=PIN_C3, stream=I2C_HW)
#use i2c(sda=PIN_B1, scl=PIN_B2, stream=I2C_SW)

/*
The following function reads a data byte from a Microchip 24LC16 I2C EEPROM, using the I2C_HW stream
*/
int Read2416(int address)
{
   i2c_start(I2C_HW, 1); //perform a start
   i2c_write(I2C_HW, 0xA0);
   i2c_write(I2C_HW, address);
   i2c_start(I2C_HW, 2); //perform a restart
   i2c_write(I2C_HW, 0xA1);
   data=i2c_read(IC2_HW, 0);
   i2c_stop(I2C_HW);
   return(data);
}


So i need to connect sda C4 and scl to B3 ( using first I2C port) , and with int Read2416 i simple obtain the data i want? And what adress i must give on method? any1 can giveme some lights about how to use I2C interface?

Thanks
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Tue Jan 31, 2012 1:12 pm     Reply with quote

Quote:
Gyro_output stable is always 1,34V ~ 1,35V , with AD conversion the values are 68~72. If I get a value higher than 72 its because i rotate gyro to right. If I get lower than 68 is because i rotate gyro to left.


i suspect that better AND simpler approach is really as RF_devel has indicated.

this is a pretty simple task for a solid 1.35v ref - or it there is an assured return-to-zero condition , an integrator of suitably long TC --
coupled with a gain adjustable Dif/ instrumentation -amp --and THAT will get you a very easily processed analog input to your pic .
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 1:58 pm     Reply with quote

I discovered that using I2C is better because it gives 16-bit resolution, with I2C I don't need to amplify signals.

So I need to read a 16-bit integer, I coded this:
Code:

i2c_start(I2C_HW, 1);
value = i2c_read(I2C_HW, 0);
value |= i2c_read(I2C_HW,0) << 8;
lcd_gotoxy(1,1);
printf(lcd_putc,"%d",value);

But the print value is always "-1", is the syntax correct ? How you guys do things like this on CCS compiler?
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Tue Jan 31, 2012 2:37 pm     Reply with quote

Look at the CCS documentation for
Code:

MAKE16(varhi,varlow);

the rest is EZ.

Remember to declare your INT16 that you pass the result of make16 TOO - as being signed or unsigned as you may require.
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 4:19 pm     Reply with quote

Check if i did right
Code:


 int value1;
 int value2;
unsigned int16 gyro;

loop:
value1 = i2c_read();
value2 |= i2c_read() << 8;
gyro = make16(value2,value1);
lcd_gotoxy(1,1);
printf(lcd_putc,"%ld",gyro);

end loop:


When i send the hex file it prints "255", but if i power off circuit and re power on it prints "25855" , something is wrong, it is suposed to get a variation not always 25855 :x
temtronic



Joined: 01 Jul 2010
Posts: 9128
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 4:45 pm     Reply with quote

Have you the correct pullup resistors on the I2C bus lines?

When doing 'math' functions, you should always test with known data.
Instead of
Code:

value1 = i2c_read();
value2 |= i2c_read() << 8;

try
Code:

value1= 0x21;
value2= 0x43;

then see what happens...

You should try a few keystone values like 0000, ffff, 1234, etc. to be _sure_ the math is correct! Nothing is worse than finding out the bytes are swapped (2143 when 4321 is right...) !
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 5:02 pm     Reply with quote

temtronic wrote:
Have you the correct pullup resistors on the I2C bus lines?

When doing 'math' functions, you should always test with known data.
Instead of

value1 = i2c_read();
value2 |= i2c_read() << 8;

try

value1= 0x21;
value2= 0x43;

then see what happens...

You should try a few keystone values like 0000, ffff, 1234, etc. to be _sure_ the math is correct! Nothing is worse than finding out the bytes are swapped (2143 when 4321 is right...) !


Hey the math is correct, but I think I found the problem, look:

If
Code:

value1= 0x21;
value2= 0x43;

result = 17697 -> CORRECT

if
Code:

value1= 255;
value2= 120;

result= 30975 -> CORRECT

if
Code:

value1=255;
value2=255;

result= -1 -> is this what I am getting when I read values from i2c_read(). The first value being 255 is normal, because gyro normal output is something higher than 255 if resolution is 16-bit, but second value2 being 255 is not normal :O

About pull-ups I am using 1k resistors. How can I know which resistors I should use?

EDIT: now it prints 255 from:
Code:

value1 = i2c_read();
value2 |= i2c_read() << 8;
gyro = make16(value2,value1);
lcd_gotoxy(1,1);
printf(lcd_putc,"%ld",gyro);


If I print value1 it is 255 and if value2 it is 0, so it is correct, the thing is why value 2 |= i2c_read() << 8 ; is zero?
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Tue Jan 31, 2012 5:15 pm     Reply with quote

BTW: a struct of two 8 bit vars - defined as a 16 bit combined INT can do the same thing as the make() function - but first you will have to sort out the transfer / level shift problems with the i2c connection.

a confession - i endorsed the analog approach because
of my DEEP prejudice:

1- analog is my strong suit , by quite a large margin
2- i much prefer SPI having had nothing but misery/debug when
STUCK implementing i2c parts

(IMHO: I2C a concept that only Philips could love or invent )
Razz Arrow
temtronic



Joined: 01 Jul 2010
Posts: 9128
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 5:43 pm     Reply with quote

hmm....

value1= 0x21;
value2= 0x43;
result = 17697 -> CORRECT

for 0x4321(value2,value1) I get 17185 using 2 different 'calculators' !

Anyone else confirm,deny ????
Chaud



Joined: 11 Jan 2012
Posts: 39

View user's profile Send private message

PostPosted: Tue Jan 31, 2012 5:45 pm     Reply with quote

temtronic wrote:
hmm....

value1= 0x21;
value2= 0x43;
result = 17697 -> CORRECT

for 0x4321(value2,value1) I get 17185 using 2 different 'calculators' !

Anyone else confirm,deny ????


it was 17185, my mistake !

I think the problem is here:
Code:
value2 |= i2c_read() << 8;


What I want on this line is the most significant 8 bits, and I think that line isn't doing what I want.
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Tue Jan 31, 2012 6:33 pm     Reply with quote

Well lucky you -

0x4321 is decimal 17185 && is
the same whether you are signed or UNSigned INT16

Assuming 0x43 is the MSB that is.

If would be more tricky if the unsigned i2c ret value was > 0x7FFF.

BUT more to the point - while you are figuring out how to organize bytes into 16 bit quantities - I might add - that if the i2c Byte return values are actually always 255 decimal - then you have HARDWARE interface trouble at a MINIMUM!!!
So I need to ask:

Have you evaluated IF you are having level translation / pull up issues with the circuit?? How do you know you DON'T ?? \methinks you focus too much on the code right now - and not enough on the circuitry -

The code will never be right if the circuity is a mess.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group