Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

GPS NMEA-0183 serial comm

Status
Not open for further replies.

Oznog

Active Member
I'm trying to get my PIC to read the NMEA-0183 serial communication out of my Garmin III+ GPS.

This guy has a project done in a bare-bones format, very handy to understand what's going on without wading through a lot of unrelated crap:
http://www.oldvan.com/garage/leds5.htm

Now here's what's got me confused. He says you don't need to transmit anything to the GPS, in fact, he only implemented the Rx side. That sounds logical enough. But just firing up my GPS and putting the scope from Tx to GPS ground (and Rx to ground, just in case I'm mixing up from whose perspective those are labelled), there is no signal, both are a constant 0v. So there is obviously not going to be a signal for the PIC to read. Is there something I'm missing here? What makes the GPS send out data?
 
Debug with your PC

Sometimes it is hard to catch the transmissions on a scope. Try downloading realterm and veiwing data on your PC. It works like hyperterminal but with more debugging features. It's a free dl ..just search on google.

It may be that your GPS receiver is outputting RS232 levels (-10 and +10) that are used by a PC serial port instead of TTL/CMOS levels(0 and +5V) that the PIC requires. You can order a simple module from www.circuitblocks.com to convert the levels or just place a MAX232 chip in your circuit. They both do the same thing.
 
Re: Debug with your PC

BF9000 said:
Sometimes it is hard to catch the transmissions on a scope. Try downloading realterm and veiwing data on your PC. It works like hyperterminal but with more debugging features. It's a free dl ..just search on google.

It may be that your GPS receiver is outputting RS232 levels (-10 and +10) that are used by a PC serial port instead of TTL/CMOS levels(0 and +5V) that the PIC requires. You can order a simple module from www.circuitblocks.com to convert the levels or just place a MAX232 chip in your circuit. They both do the same thing.

Supposedly the Garmins use a 0 and +5v TTL. Anyways, I have a MAX3232 chip in there to support the bootloader (same as a MAX232, but with an automatic self-shutdown feature). I checked the spec sheet and it looks like it will still interpret 5v TTL logic properly, and the GPS is meant to take in RS232 levels on the Rx so it should be fine.

I'm using a digital scope, so I would expect I should be able to capture something going on here. Good point on reading the output with the PC... I'm going to have to try that.
 
Oh- duh! You have to go into the GPS Setup and set the Interface to NMEA, the default is Garmin (which I have no spec on at all).
Hyperterminal is now spitting out pages of NMEA sentences. Cool! Now at least I know the signals are there.
 
Realterm

Give Realterm a try. It's hyperterminal plus more. Just do a google search on it. I think you'll really be impressed and find it extremely useful. Did I mention it was a free download?
 
I may give Realterm a try later, but Hyperterm has already verified the GPS can put out a signal.
I've also used this hardware setup for bootloader successfully, so I know it's working. I have since overwritten the bootloader and went back to ICP for now so there is no confusion about what it's supposed to do with the serial port.

Now my problem is I still can't get the hardware to talk with the GPS. I had to change the gender of the DB-9 dongle coming off the board. An ohmmeter test showed the gnd went to "-" on the GPS, T1OUT went to the pin labelled "T" on the GPS and R1IN to "R", I suspect this was not correct and wired a connector the other way too.

Either way, I'm not getting RCIF getting set. The project has a large LCD which helps in the debugging. It's polling RCIF rather than enabling RCIE to keep it simple. Xtal is 10MHz with the 4x PLL enabled, so FOSC=40x10e6.

This is the setup:
initUSART(){
#define BAUD 4800
#define FOSC 40000000UL
#define DIVIDER ((int)(FOSC/(64UL * BAUD) -1))
#define HIGH_SPEED 0
TXSTA=0b00100000;
RCSTA=0b10010000;
SPBRG=DIVIDER;

RCIF=0;
RCIE=0;
}

And this is the code to poll the interrupt:
if(RCIF){
printChar(RCREG);
RCIF=0;
}

Is that the right way to get the Rx data? Is there anything I'm missing?
 
Oh hey I've got characters all of the sudden, and they are NMEA sentences, but only 50 or so, then there are no more RCIF flags getting set. Very promising but why does it stop??

I did find out I'm not supposed to clear RCIF like a normal interrupt flag, it is cleared when RCREG is read (wonder what's up with that solution?) I did remove the clear but it's still getting stuck after a limited number of chars.
 
Oh hey I think I got it- that crude system without interrupts was getting an Overrun or maybe Framing error, after adding code to clear them it's happily buzzing away NMEA sentences without limit.
 
Hello there !
If you have XP on a PC ,you will find Hyperterminal under Programs->Accessories->communications.... Connect the GPS to the PC com port ...select the same comport in hyperterminal ....and the sentences should come in ...

As you probably know ,nmea is quite old ,so 4800 baud was ,and is still standard.... But many uses 9600 anyway....
 
Status
Not open for further replies.

Latest threads

Back
Top