GPS NMEA data and PBASIC
Robert@HCC
Posts: 80
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 :
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....
Thanks for any replies, and Alohas!
Robert
Post Edited (Robert@HCC) : 1/4/2006 1:33:07 PM GMT
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, [noparse][[/noparse]MoveTo,0,19, "GPS",MoveTo,0,20, REP"-"\3,MoveTo,0,4, "Date is: ", DEC NibData ,"/", DEC ByteData1,"/",DEC WordData1,[b]MoveTo,0,5,"Time Is: ", TimeData(0), TimeData(1), ":",TimeData(2),TimeData(3), ":",TimeData(4),TimeData(5)," ", "UTC" [/b] ] ' Print MM/DD/YYYY and hh:mm:ss ...code continues on to get LAT/LONG GetDate: SERIN RxD, Baud48, [noparse][[/noparse]WAIT("GPZDA,"), [b] STR TimeData\6 [/b] , ' 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....
Thanks for any replies, and Alohas!
Robert
Post Edited (Robert@HCC) : 1/4/2006 1:33:07 PM GMT
Comments
SERIN has a decimal formatter where using [noparse][[/noparse]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
In other words, I cant go :
SERIN RxD, Baud48, [noparse][[/noparse]WAIT("GPZDA,"), DEC TimeData ,
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData]
Because now the variable TimeData is more than 16 bits.....
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
In lieu of doing this:
SERIN RxD, Baud48, [noparse][[/noparse]WAIT("GPZDA,"), DEC TimeData ,
SKIP 3,DEC ByteData1, DEC NibData ,DEC WordData]
Is there some reason you can't do this:
SERIN RxD, Baud48, [noparse][[/noparse]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
[noparse][[/noparse] 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
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 [noparse]:)[/noparse]
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 [noparse]:)[/noparse]
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