LS20031: Can receive data fine, cannot send commands

GPS/GNSS Development Boards
1

Hello everyone,

I am using a LS20031 GPS unit from Sparkfun with a PIC18 procesor. So far I’ve been able to lots of data off the GPS unit, but I’m unable to get it to accept my commands.

I am trying to decrease the frequency of the NMEA sentences. I sent the GPS:

$PMTK314,5,0,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0*28\r\n

(where \r\n = )

but I do not get any kind of ACK packet; all I get is the standard barrage of NMEA sentences. (Since TX and RX are being handled by the same UART module on the PIC, I’m pretty sure the TX baud rate is correct since I can receive uncorrupted data).

After that, I tried to send a frequency query:

$PMTK414*33\r\n

and still I don’t get any kind of ACK packet or anything that looks like a response to my query; just more GPS output.

Also I noticed that the document posted on the sparkfun page ( http://www.sparkfun.com/datasheets/GPS/ … K_Protocol ) says there should be 17 fields in a 314 packet (and the example shows 17 values), but the more detailed document that someone posted in the comments (

http://www.rigacci.org/wiki/lib/exe/fet … system.pdf ) refers to 19 fields in a 314 packet. Does anyone know which is right for the LS20031? Also, the 514 command looks like exactly the same command as the 314 … anyone know what the difference is?

Can anyone see anything that looks blatantly wrong or have any insights? I may try to hook the TX pin up to a DLA to confirm that I’m getting output on that pin, but I’m not sure what else I should check.

Thanks in advance.

2

I had a thought, are the RX and TX baud rates the same on the GPS? I don’t have to send commands at a different rate than I receive data, do I?

3

As a refernce these are the commands I sent to my module every startup. It’s in arduino-language, but I’m sure you get the gist of it. I was sending this at 4800bps 8N1

  Serial.println("$PMTK251,4800*14");  // Use 4800 bps
  delay(500);
  Serial.println("$PMTK300,1000,0,0,0,0*1C");   // 1Hz update rate
  delay(500);
  Serial.println("$PMTK314,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29"); // report GGA every update
  delay(500);

i think it has some sort of autobauding feature, because I was doing some failure mode testing, and even when the module was completely reset, which defaulted to 57600bps, it would accept these commands. Maybe I got lucky or something though. Otherwise, you could try sending the baud rate command at 57600, then switch to whatever you set it to.

4

Thanks trialex – I tried transmitting those 2 commands at 4800 baud and 9600 baud (adjusting the baud rate command accordingly, of course), but still no luck.

If I leave the baud rate at 4800 after issuing the baud rate command, I get garbage on the output. If, however I transmit the command at 4800 and then switch the baud rate over to 57600, the GPS comes through fine (no ACK packets in sight, though).

I resoldered the TX wire to the pad and checked the continuity from the pin to the pad, that looks OK. And I know the TX signal is getting to that pin because if I jumper the PIC’s RX to its TX, it can receive all the bytes it sends out.

I even tried to send the GPS unit a break sequence to see if it would respond to that – but again no luck. At this point I think I am just going to write some code that will filter out all the sentences that I don’t need and throw them away because I’m filling up the SD card way too quickly with useless data.

I found some kind of final report for some class project where the team mentions that their LS20031 failed to accept any init commands as well. I guess maybe it’s just unreliable – but I am happy to at least be getting data out of it

5

Bummer.

As you say you are getting the important stuff, but it’s frustrating to not have it working exactly the way you want it. What baud is the module sending NMEA strings at?

Have you tried the “factory reset” commands? Maybe somehow a “lock preferences” option got selected.

$PMTK104*37<CR><LF>

Also I wouldn’t recommend this, but I accidentally reversed +ve and -ve - that was very effective in reseting everything to factory defualts.

6

The GPS module always sends data at 57600.

I’m thinking that a factory reset via serial won’t work because it seems like it cannot understand anything I tell it. The reason I say that is because I’m supposed to get an ACK packet back from the GPS (I presume if it was preference locked, I’d just get an ACK that reports “action valid but failed”, which is one of the responses).

I’m almost done writing the code to filter all that stuff out – the PIC runs at such a high frequency compared to the GPS that it is pretty much no big deal. Better too much data than not enough data, right ? :slight_smile: