Extracting GPS time with PICAXE

I'm returning to my PICAXE projects after a couple of years of attempting to retire and failing ;-) I am iniitally constructing a digital clock with some unusual features, mainly using PICAXE modules. The time source is an Adafruit Chronodot RTC. All this ought to go smoothly - although I may come to regret writing that.

In a complete failure to keep things simple, I've now started thinking about how to use GPS time, when available, to update/set the RTC. I have read all the material I can find on this forum about NMEA parsing and getting PICAXEs to do 9600 baud (not helped by the search field refusing 'GPS' as a search term), so my questions right now are:

. Has anyone got experience of interfacing a PICAXE to a recent GPS breakout such as the one from Adafruit (<https://www.adafruit.com/product/746>)?

. Bearing in mind that one would have to write code in any case, is there any point in using something like the AXE210 for parsing/serial buffering?

. Does anyone have experience of using the AXE210 for this purpose (as opposed to using it for 433 MHz comms)?

I am finding the AXE210 material rather confusing, probably because the module is designed to do so many things.

Thank you all for your patience.
 

oracacle

Senior Member
search GPS* the added star take it above the minimum search length and has no effect on the results.
 

Flenser

Senior Member
A search for "NMEA parsing" comes up just one page of results that includes at least two threads that are about parsing out just the time.
 
Many thanks for the very useful replies. I'm not sure why I didn't find Pete's posting, but it looks as if he's provided me with an almost ready-made solution, not to mention a great coding example. I hope in time I can make useful contributions back to this forum.

I'd still be interested to know what happened to the 'AXE211', which sounds as if it might have been intended to be a dedicated GPS interface.
 

hippy

Technical Support
Staff member
I'd still be interested to know what happened to the 'AXE211', which sounds as if it might have been intended to be a dedicated GPS interface.
As answered in the other thread; I recall it was intended for serial GPS plus XBee but XRF were becoming favoured over XBee so it probably wasn't deemed necessary or useful and thus never materialised.

https://picaxeforum.co.uk/threads/gps010-with-axe211.26818

The 20X2 is a good balance in having background receive capability for lowest cost so I believe that's why it was intended on the AXE211. NMEA parsing can be done on any X2 PICAXE, and X2 board, so no real need for a specific board for that.
 

Pongo

Senior Member
I posted code for an X2 PICAXE here that uses the background serial data receive option. The code include a routine to validate the NMEA data packet against its checksum.
Nice code. I wondered how you could manage with the $GPGGA sentence that doesn't include the date, but I see you are in WA don't have to worry about that pesky Daylight Saving adjustment.
 

inglewoodpete

Senior Member
Nice code. I wondered how you could manage with the $GPGGA sentence that doesn't include the date, but I see you are in WA don't have to worry about that pesky Daylight Saving adjustment.
I had never given dates a thought. The application I wrote the code for only needed the time and GPGGA fitted the bill (and thankfully, Daylight Saving only occurs pretty rarely in this part of the world*). It would be pretty straight forward to adapt the sentence type to one that includes the date - something I'll be doing on my next GPS data project.

* Western Australia's time (AWST) is fixed to longitude 120 degrees east. Perth, the major population centre for WA is located around 115 east, so the sun lags AWST by about 20 minutes. This factor, plus our relatively hot and dry summers with the maximum often occurring between 4 and 5 PM make daylight saving unpopular. The state government has trialled daylight saving on four occasions over my adult lifetime and the following referenda have resulted a fairly convincing "no" vote. Personally, I don't see much value in it and one of my wall clocks fell off its hook and broke after I changed the time during the last DS trial, so it cost me a new clock too!
 

Pongo

Senior Member
We (California) voted 60/40 last year to move to year round daylight saving time, but whether it will actually happen is anyone's guess.
 

tommo_NZ

New Member
Daylight Saving may or may not be an issue. I am building (another) garden and universal timer. Some things need to to be activated at sunrise, so daylight saving is an issue if it is time based. Some things just need to be activated a certain number of times a day, so Daylight Saving is not an issue. Using another language, I developed an algorithm and formula that approximated sunrise and sunset all throughout the year, but I can't translate that into picaxe code just yet. But by storing values in the EEPROM I think I can get close.
 

AllyCat

Senior Member
Hi,
Some things need to to be activated at sunrise, so daylight saving is an issue
Surely you just run your "timer" (I2C chip ?) permanently in GMT or UT (i.e. converted to local time without any DST)? Normally it is a complication to have to convert the clock/timer to a "human time" interface.
I developed an algorithm and formula that approximated sunrise and sunset all throughout the year, but I can't translate that into picaxe code just yet. But by storing values in the EEPROM I think I can get close.
I have posted a PICaxe program that calculates Sunrise/Sunset times for any location on the Earth's surface (which could be automatically extracted/parsed from the appropriate GPS NMEA strings if desired). Alternatively @marks has posted an EEPROM-based program which works (unmodified) for latitudes up to (or south to) about 40 degrees. The EEPROM lookup table can be derived from a suitable spreadsheet program, or of course from my program running (multiple times or with an additional FOR.... NEXT loop) using a real PICaxe or the Simulator.

Cheers, Alan.
 
Top