Go Down

Topic: IMU 6DOF + GPS TTL communucation problems (Read 2997 times) previous topic - next topic

mikalhart


David82

right. i did more testing and sending an 007 byte works in telling it to start streaming data. i also found that it only works at 57600bps so now i know i'm at the correct baud rate and i am receiving a steady stream of data. the problem is still that it's illegible ascii characters. what else can be done?

mikalhart

Hmm... in my NSS testing, RX at 57.6K is 99.9% accurate (although not 100%).  I guess it's possible that slight differences in your Arduino clock cause this, but it's hard to see how it would be this bad.  I have heard several reports of people successfully using NSS at 57.6K.  Is anyone else having trouble at that speed?

Mikal

David82

i got it to work but i don't know why it works this way and not the other. here's the code.
Code: [Select]

void setup()
{
 Serial.begin(57600);
}

void loop()
{
 if(Serial.available())
 {
 Serial.print(Serial.read(), BYTE);}
}


now wtf is up with that? is there something wrong with the NewSoftSerial library? i don't get why this works and the previous code doesn't.

David82

here's some more weirdness. to set the scene, i've got the IMU TX -> Arduino RX and the IMU RX going to nothing. it's sticking in the air. if i touch the end of the wire with my finger it sends the menu screen. if i have it plugged in to the TX of the ardiono like it's supposed to be i get that ascii crap again.

mikalhart

#20
Apr 08, 2009, 10:53 pm Last Edit: Apr 08, 2009, 10:54 pm by mikalhart Reason: 1
David,

Because NewSoftSerial is a software-based serial port, it is sensitive to variations in clock speed, especially at higher baud rates, that the HW serial port is immune to.  NSS's 57.6K RX mode is optimized for the 16MHz Arduino's I have, but it may be that your Arduino's clock varies enough to break this.

If you'd care to try and tune NewSoftSerial for your device, delete the NewSoftSerial.o file and modify _bitDelay (currently 31) in the begin() function, case 57600.  Try 32 or 30 or 33 or 29 and see if this improves the situation.

On this subject, I have been toying with building an "auto-tune" test mode that would allow people in this situation to automatically customize NSS to their specific board's quirks.  You would run a simple program on the host that blasts a repeating pattern to the Arduino.  A sketch on the Arduino automatically varies _bitDelay until the recognized pattern is seen.  Does this seem interesting?

Mikal

David82

Now i can't even reproduce what little progress i made earlier. i've come to the conclusion that the IMU is to blame since all other TTL devices i try work just fine. they don't make that particular IMU anymore anyway. i'll just buy a different one in the future. I appreciate your efforts.

jes1510

It sounds like the unit is sending the raw data to you.  You can convert it to human readable ascii by taking the data byte and adding '0' like so:

byte = byte + '0'

The itoa function may be helpful as well:
http://en.wikipedia.org/wiki/Itoa

David82

yea, but i did get it to work (in a really bizarre way) as i described earlier so i think it was trying to send ascii but was not working right. there was one point where i was getting the menu screen and also the correct streaming data. the way i got it to do that was really bizarre and later i couldn't reproduce the results.

nico765

Hey guys,

I seem to have a very similar problem;
I am trying to combine a Razor9dof, a GPS (ls20031) to an arduino (duemi).
I have configured the Razor with the ftdi cable. Works fine. Also connected to the arduino, on pin0, works fine.
Here is the code:
void setup() {
 Serial.begin(57600);  
}

void loop() {
 if (Serial.available()) {
   Serial.print(Serial.read(), BYTE);
 }
}


However, using NewSoftSerial library doesnot work. I get lots of giberish as output.

My code is:
#include <NewSoftSerial.h>
NewSoftSerial nss (4,5);

void setup() {
 Serial.begin(115200);
 nss.begin(57600);
}

void loop() {
 if(nss.available()) {
   Serial.print(nss.read(),BYTE);
 }
}


I have the gps connected on pin2 and the razor on pin4. Using the above code (and changing pin 4,5 to 2,3); I get the nmea sentences alright.

Any ideas on why serial on pin0 works fine, but NewSoftSerial does not?

Would it useful to change the baud rate of the razor? something lower?

Regards,
Nicolas

Go Up