Prop to GPS
bboy8012
Posts: 153
On my prop education kit, I used the 5V regualtor and gave it one power distro bar. I am trying interface say the parallax gps to the propeller pin14. I used a 10Mohm resistor and it brought the voltage down to like 3.1 is that safe enough to connect to P14? Also I am wondering has anyone else connected say a parallax gps to there propeller this way, or is there another way that is way more safe? I am venturing in to electroincs, and dont know much so I'm looking to the pro's for help. Another question is even with that Voltage will the propeller be able to communicate on that pin with the gps? Final question anyone know of any good sites for beginners in electronics?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
Comments
10M would be a bit high..
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
http://forums.parallax.com/showthread.php?p=667581
Read the first post
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
Whatever resistor you use, you will ALWAYS measure something around 3.6V. This is due to internal diodes, protecting the CMOS input.
Such a high resistor as you use will however degrade the slope of the signals sent. It forms a "low pass filter" with the internal input capacity, around 5 to 10 pF.
As Oldbit already said: 4k7 to 47k is a more common value for 5V input..
It'll be Geocaching time when the weather warms a bit..
A Cookbook project entry will also be forthcoming...
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Getting started with the Protoboard? - Propeller Cookbook
Got an SD card? - PropDOS
A Living Propeller FAQ - The Propeller Wiki
(Got the Knowledge? Got a Moment? Add something today!)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
BTW: I utilize the RAW mode (just run the /RAW pin to ground) and parse the NMEA data myself. I was using the GPS spin code available on the object exchange but I couldn't get it to work and found it much more complicated then it needed to be (takes 2 cogs to run). I will post my code in a few days.
He uses a 1K resistor for the SIO pin and pulls the /RAW pin to ground.
The SIO resistor can be too high at 10M ohm as the signal you want is actually the low value and needs to sink the I/O pin below the propellers 1.42V threshold.
The code you see in the Object exchange is actually my code, modified by Paul Hubner to provide support for "eTrex proprietary barametric altitude" it was designed for the "On Screen Drone" http://forums.parallax.com/showthread.php?p=662310
micahp:
as to "complexity" the code was designed to make the application somewhat device independent and easy to use. The GPS_IO object continuously reads the serial data from the GPS and makes that data available to the higher level code without needing a lage serial buffer to keep the raw data available for the application
Perry
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
{{FileRead.spin }} CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 baud = 115200 serXmit = 30 serRec = 31 CR = 13 LF = 10 OBJ debug : "FullDuplexSerial" 'To print to hyperterm DAT GPS File "GPSData.txt" 'File that is being read VAR byte GPGGAb[noparse][[/noparse]80] 'Unused right now long GPGGAa[noparse][[/noparse]20] long dataIn[noparse][[/noparse]80], Index PUB readFile debug.start(serRec, serXmit, 0, baud) 'Start the debug to see if it is reading the data Index := 0 repeat repeat while dataIn <>= "$" 'To let us know that it is the beginning of the NMEA Sentence dataIn := byte[noparse][[/noparse]GPS][noparse][[/noparse]Index++] debug.str(dataIn) while dataIn <>= CR 'Start a new line when reach the CR debug.str(String(10, 13))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
Post Edited (bboy8012) : 12/18/2007 11:44:31 PM GMT
I started with that example and just commented out the "sdfat code" and the first button check.
This will display data from any 4800 baud GPS receiver out there.
For a more interesting example of decoding the data, take a look at my "GPS satellites" code http://forums.parallax.com/showthread.php?p=662232 it displays the positions of the GPS satellites overhead.
Perry
From the looks of your last post, you've been able to scrape some code for GPS NMEA from existing examples. To move forward with parsing, take a look at Martin's GPS to VGA stuff in the Object Exchange. This uses Perry's GPS IO code to parse:
obex.parallax.com/objects/225/
In Perry's GPS IO code when parsing different NMEA sentences, I seem to remember an issue. Below is a line I changed to get the thing working with a GPS receiver that outputs a lot of data between each comma in $GPRMC. Something to look out for perhaps:
From memory... Note some general general tips when parsing NMEA... Data between delimiting commas may vary in length and/or format between devices. In-addition certain messages, like $GPGSV may contain more than one sentence per message. $GPGSV contains up to 3 sentences per message, and not all sentences may appear at all times, and (if this isn't troublesome enough) the sentences may appear out-of-order. So $GPGSV may contain up to three sentences, four satellites per sentence, but the message includes fields for number of sentences per message and sentence number within the message for each meassage. Another consideration: There are primarily two versions of NMEA out there in the mainstream. I don't remember what the version change point is but an older version has less fields at the end of each sentance than the newer version. You may or may not have to take this into acount. Consider it when optimizing buffers and/or dealing with checksums. Also, don't try to bring too much data down in terms of NMEA messages, especiallly if you want once-per-second updates. Too many messages will overwhelm 4800 bps. In-fact older GPS receivers without configurable message content would only update once every 2 seconds at 4800 as a result (i.e., Garmin GPSIII-Plus). But there is also a trade-off if your GPS can send at higher rates; you're serial driver/parser on the Propeller may not be able to process all the data in-time. Lastly - remember your time displays after processing are delayed. Professional GPS displays take the current second's data and have precision calculations to move to the next second's valid date, time etc plus a precision (often programmable) delay to compensate and ouput the current second's corrected data at the epoch of the current second's new message (yes this sounds confusing but it makes sense). This requires a lot of calculations that will bring Propeller to its knees if done regorously. So don't expect anything more than, let's say, sub 10ms accuracy; typically not a problem for most human readable applications though.
Good Luck,
David
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Remove old set of EPROMS. Erase for 1/2 hour of so; eraser didn't hold whole batch, so had to do this several times.
With 'paper tapes' in hand, start up Teletype reader and connect to EPROM burner. Install first tape, read in first program to program EPROM
Repeat for each EPROM. Remember to verify writing EPROM # on label and put on proper EPROM.
Tomorrow. We can fire up the system with the new EPROMs and start debugging.
And, many iterations and days/weeks later maybe this card is working right! (Fade in to today's bright colors, please)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
PUB readGPS serial.start(gpsRec, GpsXmit, 1, gpsBaud) 'Start serial comms to get NMEA Sentences debug.start(serRec, serXmit, 0, baud) 'Start the debug to see if it is reading the data Rx:= serial.rx Index := 0 repeat repeat while Rx <>= "$" dataIn := byte[noparse][[/noparse]Rx][noparse][[/noparse]Index++] debug.str(dataIn) while Rx <>= CR 'Collect data until you get to Carriage Return debug.str(String(10, 13))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
{{FileRead.spin}}PUB readGPS serial.start(gpsRec, GpsXmit, 1, gpsBaud) debug.start(serRec, serXmit, 0, baud) Rx:= serial.rxIndex := 0 repeat repeat while Rx <>= "$" dataIn := byte[noparse][[/noparse]Rx][noparse][[/noparse]Index++] debug.str(dataIn) waitcnt(clkfreq/5 + cnt) while Rx <>= CR 'Collect data until you get to Carriage Return debug.str(String(10, 13))▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
So much to learn
Post Edited (bboy8012) : 12/20/2007 2:37:41 AM GMT
you are confusing strings with characters
Perry
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 OBJ dbg_ser : "FullDuplexSerial" gps_ser : "Simple_Serial" VAR byte rx, dbg_rx, bFoundStart, array[noparse][[/noparse]256] long idx pub main idx := 0 bFoundStart := 0 ' start up the debugger... dbg_ser.start(31, 30, 0, 19200) waitcnt (1_000_000 * 25 + cnt ) dbg_ser.str(string("GPS Device Started...")) dbg_ser.tx(13) dbg_ser.tx(10) ' start up gps serial communication... gps_ser.start(18, 17, 4800) waitcnt (1_000_000 * 25 + cnt ) repeat rx := gps_ser.rx if rx == 36 ' ascii $ which is the beginning of the NMEA string bFoundStart := 1 ' we can now start capturing a NMEA line... if bFoundStart == 1 'found the start of the string if rx == 10 ' ascii CR (end of NMEA string array[noparse][[/noparse]idx] := 0 ' null terminate as string... idx := 0 ' start over bFoundStart := 0 ' start over dbg_ser.str(@array[noparse][[/noparse]0]) dbg_ser.tx(13) dbg_ser.tx(10) else ' just copying the data array[noparse][[/noparse]idx] := rx idx++As I alluded to in a previous post in this thread... GPS sentences have variable data fiield lengths. If you don't take this into account when displaying your NMEA input data to a debug display, you will often end-up with "Gibberish" as one set of input data ovrelays and/or corrupts a previous set when even one data fileld changes in length. Different devices handle this differently, even among different NMEA sentences in a single device. The NMEA "standard" allows this. In addittion, any field can be any size across devices, fixed or variable in length. The NMEA spec makes sense in this respect, 'pack as much data as possible into what can be transmitted in one second (espeically at 4800 baud=4800 bps with RS-232)' and leave the format up to the manufacturer. Again, don't forget NMEA allows multi-sentence messages to arrive out-of-order as well.
Starting with fixed arrays will often lead you down the path of "gibberish" when NMEA data input varies in length.
I recommend the following debug procedure:
Don't start with arrays... simple top-down serial parse, and output, one field per line to a debug display...
1. Debug $GPRMC first, output to your debug device ONE field per line allowing multiple characters per line.
2. If that is working then debug $GPGSV, this is a (typically) a two or three line sentence (take it one line at a time) and do the same as with $GPRMC, one field per line of debug output. Watch the fields vary in length as often is the case with $GPGSV.
Now knit your variable length data into fixed length arrays (if necessary) - recognize however this WILL make your application very device specific; even single device firmware version specific! Something you don't want to do with production code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!
the GPS_IO starts a serial receive channel for the GPS module
it then receives GPS strings replacing commas with nulls
When the whole string is finished (CR detected) it copies that buffer to a permanent buffer, based on a few characters at the beginning for the captured message that identify which message was received. While it is doing that copy it builds an array if pointers to the begining of each field in the message.
that leaves nothing for the user functions (ie heading, date ,time, ....) to do but return the address of the string that contains the data requested.
the last valid data should always be available.
as some people have noted it does not work for all GPS receivers. I suppose I could add some more defensive code in it to make sure that writing to the pointer tables does not get out of bounds, as well as a checksum routine to discard bad messages ....
Perry
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Hunger hurts, starvation works!