GPS Serial relay to PC by LPC-2138

Development Boards MicroMod
1

So I’ve never used GPS chips and have limited experience with serial/UART, and am having limited success. It’s an interesting setup some of you may enjoy tring to help me problem-solve… Thanks in advance.

So eventually the LPS-2138 will read the GPS via UART1, and parse the data. Parsed data will then be used by the LPC-2138. In addition the LPC-2138 will have a serial link to a PC on UART0.

The PC ↔ LPC serial link works great, and I can change baud-rates, etc on both PC and LPC. With mix-matched baud-rates you get a repeatable gibberish.

Now I have a software relay on the LPC-2138 for sending the GPS output to the PC’s serial port… to learn to interact with the GPS via serial before programming the LPC to do the same. This software relay / character encoding must be my problem, as no matter what baud rate I tell the LPC to talk to the GPS with, I get gibberish. Repeatable gibberish at a baud-rate of 4800 as the GPS puts out by default.

EM-408 GPS module connected to LPC-2138 on UART1 at 4800.

I’m using the UART headers from the Winarm examples. If you have them, my code is based on their LPC2138 uart example.

This works to send test from LPC to PC:

uart0Puts(“\r\nHello World! (UART0)\r\n”);

I feel like this should, but doesn’t work to relay GPS characters to the PC:

int ch;
while(1){
if ((ch = uart1Getch()) >= 0) {

  • uart0Putch(ch);*
    }
    }

//it relays a bunch of characters in what seems to be bursts of ~50 but it’s all gibberish with generally a lot of braces and N’s, as well as a filled oval with a cutout “?” in the center.

further investigation shows that uart0Putch(“h”) and uart0Puts(“h”) both display the wrong character on the PC… hmm… I feel so close, but can’t figure out the (character encoding?) problem.

Thanks for any help or suggestions on how to track this problem down!

2

Have you got this running yet?

I checked out the Garmin module that you are using

The GPS is a SiRF processor and may be putting out a data stream in binary. NMEA is a common character based output, but some units send binary packets and you will have to get the SiRF documentation to parse it. Binary output would explain the garbled output.

Also, the voltage level for that GPS is TTL. Your serial port is probably expecting RS232. They don’t mix well. In TTL, a “1” may be 3V to 5v and the “0” is ground. In RS232, a “1” is a negative voltage and the “0” is a positive voltage. It doesn’t even pay attention to ground levels.

If I were you and needed to play with GPS through a RS232 serial port, get an eval kit from the manufacturers.

Then your problem will be the same as mine … how to deal with the USB interface that eval kits use for output :smiley:

D

3

You need to use a ring buffer. Take a look on this page: http://www.fourwalledcubicle.com/LUFA.php

Download the code, and navigate to: LUFA 090810/Demos/Device/ClassDriver/USBtoSerial

In there you will see an example of using his ring buffer. The code is made for AVR so you might have to do some work to get it working on an ARM, but the idea is the same. I am using his code with an AVR and it works great. Good luck.

4

Also, when using putch, you generally need to use single quotes (‘h’) not double quotes (“h”) … but then again, that could have been a typo.

5

The statement about binary-data stream instead of NMEA ASCII encoded strings is very plausible, but I will go out on a limb and ask - are you sure that your UART settings (divisor, etc.) are correct for 4800 bps ? Can you use the same settings on the other serial port and communicate successfully with the PC at 4800 bps?