 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : GPS clock
  Page 5 of 5 |
|||||
| Author | Message | ||||
MicroBlocks Guru  Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Even in interpreted MMBasic you can get thousands of instructions per second. I remember that result from a post about the Duinomite, last year or so. BIPS. Even if the NMEA comes before the PPS it should be possible to do the parsing and have time enough to put it on a display. The biggest disadvantage, especially in Basic, C, and assembly is adding that second. It is not that easy to do with all the checks that have to be done. Some date/time functions are needed as you have to account for days in a month, and leap years. You have about a second to do that, so it is no problem. Such a pity that the PPS comes first, it seems so inefficient to do all that processing while if it is in the order order you just use the time as is.. Microblocks. Build with logic. |
||||
trippyben Regular Member  Joined: 26/06/2011 Location: AustraliaPosts: 91 |
It's not that hard. The PPS comes first, and then the NEMA string afterwards to tell you EXACTLY when that PPS occurred. Predicting the next PPS is low risk - it will nearly always be exactly 1 second later. As for incrementing the second to predict the next PPS for sync purposes. Pre-test the seconds, and then only do the increment and resulting sync if the NEMA seconds are less than 58. You'll never have to deal with the effects of a 59 to 00 rollover. |
||||
| cwilt Senior Member  Joined: 20/03/2012 Location: United StatesPosts: 147 |
60 is a valid second in mmbasic. 10:10:60 = 10:11:00 |
||||
| Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210 |
Gents, Adding 1 second? I've done all the hard work for you! See my code in this post. The only problem that I can't get around easily is that on the date turnover, i.e. 23:59:59 to 00:00:00 the date will changeover not on the 59 to 00 second but on 00 to 01 second, i.e. it will occur 1 second late. This is why it would be better to... 1. Load the MM on-board clock and the RTC with the correct GPS time. 2. Sync that time to the GPS PPS. 3. Have the system run off the now accurate MM/RTC clock. That way the MM clock with its calendar will take care of the correct time and date changeovers on the PPS. I'll leave that to the experts! The leading edge of the PPS is meant to be accurate to 1 uSecond. If anyone is interested, I can run some further tests on the time it takes to carry out the various tasks on the MM. From memory, it takes 7 milli seconds to write to the Futurlec 8 digit LED display. Talbit Talbit |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
What about daylight savings. :) Thailand does not have it, so not my problem. :) In the Netherlands for my website i use a small list with start and end in the database with the amounts of minutes i have to add to a timestamp. Easiest and fastest way in T-SQL. In C# it is baked into the langauage. MMBasic..... make it yourself. I actually like that because it makes the one programming it learn new things. Microblocks. Build with logic. |
||||
kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
I am sorry for jumping in this topic so late, but reading through 8 pages of posts and having made a few GPS-driven clocks in the past few years (usually as part of another, larger scale project), I simply couldn't resist 
The 1PPS output is NOT a good way to drive the time measuring. Typically the best way to do it is to have a local 32768Hz crystal, driving an internal RTC. Then during normal work you receive and parse the NMEA0183 strings from the GPS, extract the UTC field from the $GPRMC message and round it to the next whole second. Then compare with your local time at the next round second exactly and only if there is a difference, correct your local time from the GPS time, otherwise do nothing. Of course you need to know your local time zone since the UTC time is based on the GM. This model works proven very well and you can switch the GPS on for some short time (say two-three times in a day) just to correct your local time, while you are in a low-power RTC mode otherwise. Apologies if this has been discussed earlier, I didn't read through all the posts, just wanted to share my experience in this matter. http://rittle.org -------------- |
||||
| Dylan Regular Member Joined: 17/06/2013 Location: NetherlandsPosts: 81 |
Surely with a GPS you ... know your local time zone? ;) |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Timezones and daylight savings. Two things that can not be uninvented. For timezones you need a worldmap divided with polygons to be able to tell in which zone you are. http://www.worldatlas.com/aatlas/infopage/timezonz.htm Another way is to use reverse geolocating and get a country/state code. Then do a lookup for the timezone. Each country has a different set of rules for daylight savings, Olson database is a good source for that. For a stationary gps clock, you lucky b@stards, it is pretty simple. 
Just set one value for the timezone and 2 small routines for a daylight savings check. Have fun..... Microblocks. Build with logic. |
||||
| Dylan Regular Member Joined: 17/06/2013 Location: NetherlandsPosts: 81 |
I was thinking more in terms of something even the tiniest of MCUs could do: 1) Longitude->time zone ((lon + 7.5)//15) 2) User offset O: 2a) A single button press increases O by 1 hour... 2b) Unless the device has been running for more than 1 day with no button pressed, in which case it does everything symmetrically opposite ;) 2c) A second button press decreases O by 2 hours (to -1) 2d) A third button press increases O by 3 hours (i.e. back to +2). 3) people likely to be on half-hour boundaries can write their own bloody code! pseudocode
init: amount = 1 flipped = false on button_int: direction = +1 O += O + direction * amount direction = -direction amount++ last_time = now() on timer_int/loop: if last_time + 1 day > now() and flipped: direction = -direction flipped = false I'm sure there are bugs in there, but you get the idea of how tight the code could be. I have no idea how expensive GPS is in terms of battery power, but working on the assumption that running a 32768 crystal or for that matter internal clock of a pic can be done VERY cheaply if 10 minutes accuracy per half year is required. But of course it doesn't really matter, because in general UTC will be enough. ------------------------------------------------------------ ------------------ Complete derail now, sorry. Since I'm not Australian, but might want to visit some day, an idea which occurred to me (which doesn't necessarily require GPS, but it might help) for idiot visitors is to have a network of millions of "emergency stations". Basically signposts out in the dessert, the vast majority (90%) of which would be very low-tech (signpost only). Tier 2 would remain low-tech, but have a shovel above ground and a cache with water and rations nobody would want to steal buried shallowly. But obviously tier 3 would have more, namely a solar panel/battery for power, a simple shelter/shade where appropriate, and most importantly a (ham) radio. Except for the minor problem that there exist some criminals in your fine country, and furthermore keeping costs even lower than buying solar panels and GPS and that kind of stuff would allow more such stations to be installed. So perhaps a hand-cranked dynamo (knijpkat) which can power a radio transmitter which transmits whatever GPS info it has - either as programmed into MCU when installed at such a station, or as obtained from a smartphone (include a USB charger option). Don't get me wrong, I'm sure that as long as people stay on-road there are good options available. This is just one of my crazy ideas. But perhaps it is a good crazy idea ;) |
||||
| Talbit Senior Member Joined: 07/06/2011 Location: AustraliaPosts: 210 |
Dylan. You're idea? It's too expensive. Australia is mostly desert. The golden rule here is you never leave your car. If you do, you're dead. Epirbs are the way to go. They're cheap. Sat phones are even better but very expensive. But come to Australia. You'll love it. Just recently, an "experienced" Canadian "special forces" bushwalker was lost in our snowy mountains. They tried using a drone but it disappeared over the hill and was lost. See http://www.uavoutbackchallenge.com.au/ for some great work people are doing using micro technology. Back to GPS. I think the world should all run off UTC and use decimal clocks! Talbit Talbit |
||||
| aevertett Newbie  Joined: 25/06/2014 Location: United KingdomPosts: 1 |
I find this thread fascinating! Sorry if I have come to it a little late - it took me a while to find it. I have a fair bit of experience designing GPS-referenced network time servers and clocks. Most of our equipment is based on UTC time, which is is far easier to implement. However, occassionally, we do get a requirement to provide a GPS based time reference that can provide local time. We implement this by having a series of small files (or an array), one for each required timezone, which also includes the timezone code, such as BST, and a offset. Also included is the start and end time and offset for any daylight saving period. I find this solution works very well. AS |
||||
| kiiid Guru Joined: 11/05/2013 Location: United KingdomPosts: 671 |
The thread is old indeed but I just noticed this post by Talbit. I think I can help you out with that as it falls within my interests too. Check this out. I have even made a wristwatch and a rock-solid algorithm to use a standard 32.768kHz crystal (that in C but I can still publish it if anyone is interested). It can be easily adapted to UTC input as well. An experiment with my two young kids showed that they are much more susceptible to decimal time in comparison to what we use now. I am curious to find out is there any other 'crazy' people in the world, who are interested in decimal time? 
http://rittle.org -------------- |
||||
palcal Guru Joined: 12/10/2011 Location: AustraliaPosts: 1965 |
For a long time I have thought about decimal time, seems you have worked it out very well Kon, but I think it would be a very brave government that would even consider such a change. Paul. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| Page 5 of 5 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
