PDA

View Full Version : GPS NMEA data and PBASIC



Robert@HCC
01-04-2006, 08:25 PM
I am trying to capture the time from a LassenIQ GPS module transmitting in NMEA. the format of the message is : $GPZDA,hhmmss.ss,xx,xx,xxxx,*hh<CR><LF>.

I am only concerned with the hhmmss at the start, as I am only trying to capture and display the time. I have the Date and LAT/LONG down - no problem there. My problem is that the time is 6 digits in a row - to big to fit in a Word variable . So I tried this :




TimeData VAR Byte(6)

GOSUB GetDate
SEROUT TxD, Baud48, [MoveTo,0,19, "GPS",MoveTo,0,20,
REP"-"\3,MoveTo,0,4, "Date is: ", DEC NibData ,"/",
DEC ByteData1,"/",DEC WordData1,MoveTo,0,5,"Time Is: ",
TimeData(0), TimeData(1), ":",TimeData(2),TimeData(3),
":",TimeData(4),TimeData(5)," ", "UTC" ] ' Print MM/DD/YYYY and hh:mm:ss

...code continues on to get LAT/LONG

GetDate:
SERIN RxD, Baud48, [WAIT("GPZDA,"), STR TimeData\6 , ' Read the ZDA sentence from LassenIQ GPS -
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData1] ' $GPZDA,hhmmss.ss,xx,xx,xxxx,*hh<CR><LF>
RETURN ' - store day as NibData, month as ByteData,
' year as WordData1 and hhmmss as TimeData\6





So basically, I grabbed the time as a string in a 6 byte array. so far so good, and it displays perfectly. However, this time from the GPS is UTC, and I would like to convert it to local time ( -10 for Hawaii).
So I tried something like :

DEC TimeData (1), DEC TimeData (2),.....etc to change back to a number that I could minus 10 hours from somehow. But I dont get back the numbers I should be getting.
For instance , say the time is 12:30:00. TimeData (0) = 1, TimeData (1) =2 ......ect. Or so I thought... silly if me lol... but if I now go : DEC TimeData(0), I get 49 instead of 1, and DEC TimeData (1) , I get 50 instead fo 2....

sigh... I assume I am getting ASCII values or something because the data is a STR? Anyone got some pointers on how I can convert this six digits from UTC to local time, or perhaps show me a better way to grab the six digits without using STR and having it in a numerical value from the start ?

I would really like to use the time from the GPS to provide a "time stamp", and save the effort of using a RTC for that. But if converting UTC to local gets too complicated I may well do that....lol after trimming down the "luxuries" in my code to make EEPROM space for the RTC ( code now runs/displays data from : accelerometer, DS1620, LassenIQ GPS LAT/LONG,Date, Time (somewhat), 25LC640 EEPROM and a MPX4115 presssure sensor).
Hehe had to can my Sensirion Temp sensor and goto the DS1620 after I fried it by accidently reversing the polarity during a 300 am test session....http://forums.parallax.com/images/smilies/turn.gif

Thanks for any replies, and Alohas!
Robert

Post Edited (Robert@HCC) : 1/4/2006 1:33:07 PM GMT

PJ Allen
01-04-2006, 09:02 PM
Yes, NMEA, is 4800, 8N1, ASCII output.· It's not ASCII'ized because of the use of STR.
SERIN has a decimal formatter where using [DEC variablename] would interpret/convert the incoming ASCII characters as Decimal numbers for you.· Read all about it in PBASIC Help.
I've given some thought to converting UTC to local time in a project of my own, but not in depth.· You will also have to convert the date, too, depending.



Post Edited (PJ Allen) : 1/4/2006 2:09:15 PM GMT

Robert@HCC
01-04-2006, 09:16 PM
That part I understand - but how do I store the hhmmss ( which will be a 6 digit number once I dec it)? Thats what has me at a loss....

In other words, I cant go :
SERIN RxD, Baud48, [WAIT("GPZDA,"), DEC TimeData ,
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData]

Because now the variable TimeData is more than 16 bits.....

Robert said...
My problem is that the time is 6 digits in a row - to big to fit in a Word variable .


It works fine converting the ASCII date values that follow TimeData because that is only 2 digits (comma), 2 digits comma) ,then 4 digits (comma)whereas the Time values are six in a row....

Post Edited (Robert@HCC) : 1/4/2006 2:21:25 PM GMT

Bruce Bates
01-04-2006, 10:40 PM
Robert -

In lieu of doing this:

SERIN RxD, Baud48, [WAIT("GPZDA,"), DEC TimeData ,
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData]

Is there some reason you can't do this:

SERIN RxD, Baud48, [WAIT("GPZDA,"), DEC2 HH, DEC2 MM, DEC2 SS,
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData]

using one byte each for hours, minutes and seconds?

Regards,

Bruce Bates

PJ Allen
01-04-2006, 11:55 PM
I thought of a way to convert the Hours from UTC to Hawaii, but it doesn't change the date:

Z VAR Byte ' Z = UTC hh
IF Z < 10 THEN GoAdd
Z = Z - 10
'go somewhere else, Conversion Done

GoAdd:
Z = Z + 14
'go somewhere else, Conversion Done
[ Isn't there a variable in the $GPZDA sentence to offset UTC for local time? ]

To·offset the date·a look-up/calendar table would be needed (way too much memory) for obvious reasons.

Post Edited (PJ Allen) : 1/4/2006 8:26:41 PM GMT

Robert@HCC
01-05-2006, 04:01 AM
Hi Bruce,
LOL I have been chewing on this for three days, it cant be THAT simple....and yet it is! Works perfectly, and in addition, you saved me three bytes to boot - a very valuable commodity at this stage! I guess I was stuck on the idea that it was a solid string of 6 digits...thank you very much for that, Bruce!

PJ, that looks good to go :)
I worked out something with a couple If/ELSE statements , but your way is much better. There is an offset value, but it is to convert GPS time to UTC.

Thanks :)

Robert@HCC
01-05-2006, 10:18 AM
Actually, I was wrong ,Bruce - tried that out before I had my morning cuppa coffee and thought it worked.... I actually had to do a separate SERIN for each time value, like so:




GetTime: ' Get time values from NMEA msg in format
SERIN RxD, Baud48, [WAIT("GPZDA,"),DEC2 hh ] ' $GPZDA,hhmmss.ss,xx,xx,xxxx,*hh<CR><LF>
SERIN RxD, Baud48, [WAIT("GPZDA,"), SKIP 2, DEC2 mm]
SERIN Rxd, Baud48, [WAIT("GPZDA,"), SKIP 4, DEC2 ss]

SEROUT TxD, Baud48, [ MoveTo, 0,2,"Time Is: ", ' Display UTC time
DEC2 hh ,":",DEC2 mm, ":" ,DEC2 ss," ", "UTC" ]
RETURN




Lose a few seconds this way, but I dont need real accuracy - just a time stamp for my sensor data over a fifteen minutes period as our CanSat drifts to Earth.

PJ, that conversion works like a charm - like you said, doesnt fix the date - but I can fool with that later, I am just happy having local time!
Thanks to you both for all the help!
Aloha,
Robert

Post Edited (Robert@HCC) : 1/5/2006 3:33:18 AM GMT