Replies to This Discussion

Permalink Reply by Andrew Brygin on September 3, 2010 at 12:40am

Hi Matthew,

I am very interested in your investigation, because I also have LS20031 module and I am going to use it
with ArduIMU board.

Is it possible that 2.5v is too low voltage? The LS20031 spec says that minimum input voltage is 3v.
You could verify this by connecting the FTDI cable directly to the GPS module (in parallel with ArduIMU).
If you see normal NMEA output form it, then 2.5v input voltage is fine, and problem roots are somewhere
in GPS_NMEA parser.

Thanks,
Andrew

• ▶ Reply

Permalink Reply by Matthew Lai on September 3, 2010 at 8:43am

The VIH (minimum voltage recognized as logic high) in the datasheet is 2V, so while not the best practice, it should most certainly work. Just to clarify, I am powering it with 3.3V.

And I just realized there could be a baud rate mismatch. Will check it tonight.

• ▶ Reply

Permalink Reply by Matthew Lai on September 3, 2010 at 9:29pm

I corrected the baud rate mismatch (changing the first Serial.begin(9600) to Serial.begin(57600)), and was able to get SOME corrupted data. The numbers just don't look right at all, and jump around a lot.

I also had to change a few things for it to compile.

To be terribly honest, the code is quite a big mess :P. Maybe I will try to refactor it a bit if I have the chance, but I just want to get it to work for now.

I think I will just skip the NMEA parser (since the current one is big and unreadable) and just write a dummy one that passes the string to my main computer, and do the parsing there instead.

• ▶ Reply

Permalink Reply by Andrew Brygin on September 3, 2010 at 9:57pm

The IMU's nmea parser seems to be based on the parser from ArduPilot sources, which now works fine (at least in the case of LS20031 module). So, you may want to adopt current version of AP's nmea parser for IMU needs...

• ▶ Reply

Permalink Reply by Matthew Lai on September 4, 2010 at 12:48am

I think I will just pass the unparsed string around, since my main computer runs Linux (gumstix), so parsing the NMEA sentences will be trivial (because sscanf supports floating point).

If anyone is interested, here's what I'm using.

void decode_gps(void)
{
gps_buffer[0] = '\0';

int gps_str_len = 0;

byte b;

// discard until '$'
while (Serial.available() > 0 && Serial.read() != '$');

while (Serial.available() > 0 && (b = Serial.read()) != '\n')
{
gps_buffer[gps_str_len++] = b;
}

gps_buffer[gps_str_len] = '\0';

if (gps_str_len > 0)
{
Serial.print(gps_buffer);
Serial.print('\n');
}
}

• ▶ Reply

Permalink Reply by Matthew Lai on September 6, 2010 at 1:49pm

I think the biggest problem here is serial buffer overflow, and maybe that's why I'm getting data corruption.

The Arduino serial buffer is 128 bytes long, and 2 NMEA sentences can easily exceed that, especially when you have a fix (lines get quite a bit longer).

I'm not sure how to get around that yet, short of doing external buffering.

The baudrate doesn't matter because we are asking for 2 sentences, and they always arrive at the same time, most likely when the MCU is doing something else.

Any suggestions?

• ▶ Reply

Permalink Reply by Matthew Lai on September 6, 2010 at 2:55pm

I worked around it by making my own 512 bytes buffer "wrapper", and a function that copies everything from serial buffer to my buffer. Then I call the function on each iteration of the main loop.

512 bytes buffer can hold about 6-7 sentences, so that should be fine, if the decode_gps function is called at least every 5 GPS updates (at 5Hz that's once per second - but what's the point of getting 5Hz updates if you are only going to use it once per second? 4 readings would be outdated anyways). I optimized the ArduIMU code heavily (mostly taking out things I don't need), and am able to take GPS readings a few times a second.

Very ugly, but seems to work. I've been running it for a few minutes, and didn't see any data corruption (they were very obvious and frequent).

I suspect it can help with the official parser, too, since it should have the same trouble (data corruption), but I'm not working with that code anymore.

By the way, the NMEA_OUTPUT_5HZ - NMEA_OUTPUT_1HZ strings are wrong. That's not what the PMTK command does.

A value of 1 means it will output that type of sentence every update, 2 means every other update, 3 means every third update, etc.

So to get 5Hz updates of both sentence types, you'll need to set overall update rate to 5Hz, and "NMEA_OUTPUT_1HZ".

• ▶ Reply

3D RoboticsPermalink Reply by Chris Anderson on September 6, 2010 at 4:19pm

Mathew,

Thanks for the detective work. None of us on the dev team use NMEA GPS modules, which is why that wasn't supported and is probably buggy. It sounds like you've come up with some good fixes. If you can PM me an email address I can give you commit access to the repository so you can add your changes to the current code and we can test and possibly release them as the official version.

Best,

Chris

• ▶ Reply

Permalink Reply by Matthew Lai on September 11, 2010 at 1:12am

I ported my fix to the official source, but I'm still getting garbage data.

I can confirm that it's getting the whole NMEA sentences, though.

Probably something wrong with the parser. I'm trying to rewrite it and make it more readable also.

• ▶ Reply