NerdKits - electronics education for a digital generation

You are not logged in. [log in]

NEW: Learning electronics? Ask your questions on the new Electronics Questions & Answers site hosted by CircuitLab.

Support Forum » Strange Serial Question

July 01, 2010
by Keyster
Keyster's Avatar

i am trying to get my NerdKit to talk to a GPS via the USART. i am having strange results. i have been troubleshooting for a while and here is what i have found: Tools; -Nerdkit with code to grab from USART and display on screen. -Magellan GPS 315 set to send NMEA codes via Serial port 4800,N,8,1 no FlowCtr -Nertkit USB 2 Serial Adapter -"other" USB 2 Serial Adapter (PL2303 style) -Putty running in Serial Mode

ok, on to the fun stuff. A. if i hook up the NerdKit via the Nerdkit cable everything works great. i can type in Putty and it displays on the nerdkit LCD. the program looks for a specific NMEA code and clears the screen. i can type in that code and the LCD screen clears. all appears perfect.

B. if i hook up the GPS via the "other" usb cable and start Putty everything works great. i start receiving the NMEA codes exactly like i expect.

C. here is where the problems start. if i hook the GPS up to the Nerdkit i get nothing but garbage on the LCD screen. if i hook up the GPS via the Nerdkit cable to the PC i get garbage in Putty. if i hook up the Nerdkit via the "other" USB cable i get garbage (from Putty back to LCD Screen).

from my troubleshooting it appears that the Nerdkit only wants to work with the Nerdkit supplied cable for serial communication but i am pretty sure that is not the case. USART is USART right? -on the Nerdkit (ATmega168) i am forcing 4800,N,8,1. i have tried other Baud Rates with same results. GPS is hardcoded to N,8,1 per manual. -i have flashed my code on a "blank" (no bootloader) ATmega328 and get same results. -i have uninstalled and reloaded the PL3203 drivers (on PC of course).

Does anyone have any insight to what may be happening? is there something about USART that i am not understanding? shouldn't the ATmega168 be able to talk to any "standard" serial device?

Stumped in Huntsville AL

Bryan

July 01, 2010
by mongo
mongo's Avatar

Here is something to possibly try.

Instead of going from the GPS through the USB cabling, use the direct approach. Use the USB/RS232 adapter and let the adapter talk to the NK. (?)

I have a GPS wart on my truck that just transmits data through the USB cable to a PC and this sounds like an interesting adaptation. I'll see what I get and let you know how it goes.

July 02, 2010
by Rick_S
Rick_S's Avatar

You may be running into a problem in the difference between "standard" RS-232 protocal Vs. TTL level protocol. The main differences from what I understand is that besides the voltage levels being higher with standard RS-232, the signal is also inverted.

There are several ways around this. One of the solutions is using an inverter like the NK guys did on their serial adapter prior to the one they currently use. Another way and one I've used a few times is through a Maxim MAX232 IC. This single chip handles complete RS-232 to TTL conversion very reliably. Depending on the variety it may or may not need a few capacitors along side it to act as charge pumps to raise the RS-232 voltage levels.

If you search Google for RS-232 to TTL you'll find all kinds of examples to help out in the design.

Good luck and keep us updated!

Rick

July 02, 2010
by Keyster
Keyster's Avatar

Thank you for the quick reply Mongo and Rick. now that you mention it i remember reading on the forums (somewhere) about RS232 being slightly "different". i have googled and found a diagram for the RS232 to TTL converter. i just happen to have several MAX232 ICs and a handfull of 1uF Caps so i will throw something together tonight and see if that takes care of it. if it works (i think it will) i will post the diagram i used and the results here.

Thanks Again, Bryan

PS. i am working on an airplane that flies itself. if i can get all the individual pieces to work i will start a "project" in the projects forum. i know i am shooting for the stars here BUT what i have found in the past is that each hurdle i cross teaches me something new. whether the plane flies or not is irrelevant, the "smarts" is my goal!

July 02, 2010
by mongo
mongo's Avatar

Well, I hope it was of some help anyway...

I know the frustration when it comes to communications. I had been developing a wireless telemetry setup with one of my NK's, only to find that the transmitter/receivers I thought I bought turned out to be receivers only. They were switched at the factory and I have yet to get the situation with them resolved.

July 02, 2010
by Keyster
Keyster's Avatar

Mongo,

what Transmitters/Receivers are you using? i have purchased the 315Mhz ASK tran/Rec from Sparkfun. they seem to work "ok". i also wanted to do some telemetry from my airplane in a later project and was just wondering if you found something more reliable (but still light). Another thing i was going to use them for is to monitor my garage door while i am at work (or out of town). IE, send a signal to my computer if my garage door is opened and then send email to my blackberry from the computer. Maybe even make it so i can close the door remotely (from email or website).

the main problem i see with the Trans/Receivers is that as reliablity goes up, so does the price. ;)

July 02, 2010
by mongo
mongo's Avatar

The radio links I was supposed to get were a pair of Sure Electronics CY2196TR units. (Transmitter/Receiver).

What I got in the mail was a pair of CY2196R (receive only).

They are 433MHz FSK and operate at 19200 8 n 1 but since I can't transmit, they are useless.

July 03, 2010
by Keyster
Keyster's Avatar

Rick,

You were correct. i used the MAX232 and now it worked exactly as i expect. Thank you sir.

here is the site that i used to setup the MAX232 IC. MAX232 Diagram

for the most part i just used the diagrams near the bottom of the page. there are probably better pages out there but this is just the first one i found and it worked for me.

here are some pictures of the setup, sorry about the size but i was afraid if i reduced them it would make them "fuzzy".

Project Working

Closeup

July 03, 2010
by Ralphxyz
Ralphxyz's Avatar

Hey Keyster please post your code!!

Is the code on the LCD the raw NMEA data?

I suppose the data is scrolling on the LCD display.

I have ideas for a GPS project but have not pursued anything besides trying to find a NMEA cable for my Lawrence GPS.

Ralph

July 03, 2010
by mongo
mongo's Avatar

A plowed field in northern Alabama?

Project looks good. My hand-held GPS is a Garmin. I'll have to look up the protocols.

July 03, 2010
by Rick_S
Rick_S's Avatar

Good! Glad to hear you got it working. One day I'm going to interface the Pharos GPS500 SIRF III module that came with my streets and trips software. It's a raw GPS module that spits out NMEA data... One day... :D

Rick

July 03, 2010
by Keyster
Keyster's Avatar

Ralph,

Absolutely. just keep two things in mind... 1) i am only a programmer by hobby so code may seem bloated. 2) this is only a test app thrown together to verify i could capture the data. ;)

Yes, that is the raw NMEA data you see on the LCD. i have it displaying everything because i was having problems with the RS232. normally it just displays the $GPGGA string which is the string that contains the location, time, altitude, etc. i receive apx 1 string per second. the $GPGGA comes in about every two seconds. My GPS has several different NMEA Modes. i currently have it set to NMEA 2.1. now that i have it working i will also up the speed. i read that NMEA is "standard" at 4800 but my GPS will go up to 19200 that should help get the data to the ATMEL a little quicker and free up the processor to do other things (like fly an airplane i hope).

//
//  Test app by bryan key
//    Test serial communication from GPS
//

#define F_CPU 14745600
#include <stdio.h>

#include <avr/io.h>
#include <avr/interrupt.h>
#include <avr/pgmspace.h>
//#include <string.h>
#include <inttypes.h>

#include "../libnerdkits/delay.h"
#include "../libnerdkits/lcd.h"
#include "../libnerdkits/uart.h"

    uint8_t baudrateH, baudrateL;

//
// set the baud rate of the UART
//4800 = 191    0/191
//2400 = 383    1/127
//1200 = 
int8_t SetBaudRate(uint16_t baud)
{   uint16_t baudrate;

    baudrate = (float)F_CPU/16/baud-1;
    baudrateH = baudrate >> 8;
    baudrateL = baudrate & 0xff;
    UBRR0H = baudrateH; //(F_CPU/16/BAUD-1)>>8;
    UBRR0L = baudrateL; //(F_CPU/16/BAUD-1)&&0xff;
    UCSR0B = (1<<RXEN0)|(1<<TXEN0); // enable uart
    UCSR0C = (1<<UCSZ00) | (1<<UCSZ01); //8 bits
    return(1);
}

int main()
{   char x;

    sei();
    lcd_init();
    FILE lcd_stream = FDEV_SETUP_STREAM(lcd_putchar, 0, _FDEV_SETUP_WRITE);
    lcd_home();

    uart_init();
    FILE uart_stream = FDEV_SETUP_STREAM(uart_putchar, uart_getchar, _FDEV_SETUP_RW);
    SetBaudRate(4800);
    stdin = stdout = &uart_stream;

    //
    // Display baudrate numbers to verify they are correct
    fprintf_P(&lcd_stream,PSTR("Testing-%i-%i"),baudrateH,baudrateL);

    char holding[40];
    int8_t index = 0;

    while(1)
    {   if (uart_char_is_waiting())
        {   //lcd_home();
            x = uart_read();
            if (x == 0x0d)  // check for end of a NMEA string
            {   //
                // Check for "GGA" in NMEA code. this is the "location" string
                // when found, clear screen, display to LCD and set buffer to "empty"
                if ((holding[0] == '$') && (holding[3] == 'G') && (holding[4] == 'G') && (holding[5] == 'A'))
                {   lcd_clear_and_home();
                    fprintf_P(&lcd_stream, PSTR("[%s]"),holding);
                    printf_P(PSTR("[%s]\n"), holding);
                }
                // reset buffer to "empty"
                index = 0;
                holding[index] = 0x0;
            }
            else
            {   //
                // place new char in Buffer and bump index
                holding[index++] = x;
                holding[index] = 0x0;   //mark end of string
                //
                // output each single char read to verify it is not garbage. this is for testing only.
                fprintf_P(&lcd_stream, PSTR("%c"), x);
                if (index > 38) //max length of Buffer
                    index--;
            }
        }
    }

}
July 03, 2010
by Keyster
Keyster's Avatar

Mongo,

i also have a Garmin handheld GPS with turn-by-turn etc. this one is one that my wife bought for be YEARS ago so i dont mind it going down in flames. i am going to try to keep it from going down in flames but if it does it will not be the end of the world. Also i like the fact that this one has a simple serial connection on the back and should run fine off a 3.3 volt voltage regulator (if you have any comments of that please let me know, i dont want to "let the smoke out" as they say).

thanks bryan

July 03, 2010
by mongo
mongo's Avatar

Everything works on magic smoke. If you let it out, they stop working...

My Garmin unit is about 6 years old now. I use in when traveling and such but mostly on the bicycle. Keeps track of a lot of things like speed, direction, etc. Nothing fancy, no maps, no voice, just a neat little set of displays for different functions.

I have the cable for PC interface but it never worked. Something about the signal levels but I am not sure. (Haven't messed with that for years). If I can get it to talk to the NK, I would be miles ahead. Thanks for the idea.

Post a Reply

Please log in to post a reply.

Did you know that the printf format string "%.3f" will show three digits after the decimal point? Learn more...