kb8tq@n1k.org said: > For a server (that gets inquiries at any time) the “wake up” process is going > to be a problem with a deep sleep approach. The GPS on the server also would > need to wake up and get going. That combo is going to give you a mighty long > turn around time on a request. I also suspect that the requests will come in > often enough (compared to a minute or two long GPS lockup) that it would > never go into deep sleep anyway. Handwave. Probably more work than you want to do, but ... I could imagine a setup where everybody wakes up at the same time, does some work, then goes back to sleep. The NTP server might have to wake up earlier in order to get the GPS going. You should be able to keep time at the ms level for an hour or 6 without GPS. Longer if you do temperature compensation. Do you need time synced to UTC or just everybody dancing in step? ---------- In the old days, systems used a periodic interrupt from the RTC for timekeeping. The next step was to use a cycle-counter running off the CPU clock to interpolate between ticks. Modern systems just use the CPU clock. For ms level accuracy at low power, I could imagine going back to timing based on the RTC. It may be simpler to keep your own clock in parallel with the OS rather than beat the OS into recovering good time after sleeping. One of the problems with RTCs is that you can only read them to the second. You can get much better time by polling to watch for the second to change. Better would be to set them up to interrupt on the second boundary and run the interrupt line into a GPIO setup as a PPS input. (Maybe newer RTCs have a sub-second register.) -- These are my opinions. I hate spam.

Hi There are a bunch of devices out each doing their own thing. Some are running 100% of the time, others get power cycled “as needed”. There also are a range of OS’s involved. Having everybody wake up at once …. not practical. However if the “broadcast” NTP approach was the method of choice, then a wake up and do it would work. for. the server. Bob > On Dec 4, 2019, at 5:23 PM, Hal Murray <hmurray@megapathdsl.net> wrote: > > > kb8tq@n1k.org said: >> For a server (that gets inquiries at any time) the “wake up” process is going >> to be a problem with a deep sleep approach. The GPS on the server also would >> need to wake up and get going. That combo is going to give you a mighty long >> turn around time on a request. I also suspect that the requests will come in >> often enough (compared to a minute or two long GPS lockup) that it would >> never go into deep sleep anyway. > > Handwave. Probably more work than you want to do, but ... > > I could imagine a setup where everybody wakes up at the same time, does some > work, then goes back to sleep. The NTP server might have to wake up earlier > in order to get the GPS going. > > You should be able to keep time at the ms level for an hour or 6 without GPS. > Longer if you do temperature compensation. > > Do you need time synced to UTC or just everybody dancing in step? > > ---------- > > In the old days, systems used a periodic interrupt from the RTC for > timekeeping. The next step was to use a cycle-counter running off the CPU > clock to interpolate between ticks. Modern systems just use the CPU clock. > For ms level accuracy at low power, I could imagine going back to timing based > on the RTC. > > It may be simpler to keep your own clock in parallel with the OS rather than > beat the OS into recovering good time after sleeping. One of the problems > with RTCs is that you can only read them to the second. You can get much > better time by polling to watch for the second to change. Better would be to > set them up to interrupt on the second boundary and run the interrupt line > into a GPIO setup as a PPS input. (Maybe newer RTCs have a sub-second > register.) > > > > -- > These are my opinions. I hate spam. > > >

Hal might be on to something actually and I don't believe it would require special hardware, just some configuration. The ntp client (in Linux at least) has two different intervals which can be configured - one for retry and a second for burst. The idea is your timekeeper could go into lower power and stop listening for a while. The clients try, and fail when it is down, but they keep trying every so often. Then when they do connect up they switch over to that shorter burst interval, and do a few rounds with the server to get a better estimate of the link delay. As long as the retry interval on the clients are set to half or less than the interval that the server is awake, then they should naturally find a window in which to sync. So if you get something working on the pi but it is still too power hungry, perhaps this trick would work. -David -------- Original Message -------- On Dec 4, 2019, 14:45, Bob kb8tq wrote: > Hi > > There are a bunch of devices out each doing their own thing. Some are running > 100% of the time, others get power cycled “as needed”. There also are a range > of OS’s involved. Having everybody wake up at once …. not practical. However > if the “broadcast” NTP approach was the method of choice, then a wake up and > do it would work. for. the server. > > Bob > >> On Dec 4, 2019, at 5:23 PM, Hal Murray <hmurray@megapathdsl.net> wrote: >> >> >> kb8tq@n1k.org said: >>> For a server (that gets inquiries at any time) the “wake up” process is going >>> to be a problem with a deep sleep approach. The GPS on the server also would >>> need to wake up and get going. That combo is going to give you a mighty long >>> turn around time on a request. I also suspect that the requests will come in >>> often enough (compared to a minute or two long GPS lockup) that it would >>> never go into deep sleep anyway. >> >> Handwave. Probably more work than you want to do, but ... >> >> I could imagine a setup where everybody wakes up at the same time, does some >> work, then goes back to sleep. The NTP server might have to wake up earlier >> in order to get the GPS going. >> >> You should be able to keep time at the ms level for an hour or 6 without GPS. >> Longer if you do temperature compensation. >> >> Do you need time synced to UTC or just everybody dancing in step? >> >> ---------- >> >> In the old days, systems used a periodic interrupt from the RTC for >> timekeeping. The next step was to use a cycle-counter running off the CPU >> clock to interpolate between ticks. Modern systems just use the CPU clock. >> For ms level accuracy at low power, I could imagine going back to timing based >> on the RTC. >> >> It may be simpler to keep your own clock in parallel with the OS rather than >> beat the OS into recovering good time after sleeping. One of the problems >> with RTCs is that you can only read them to the second. You can get much >> better time by polling to watch for the second to change. Better would be to >> set them up to interrupt on the second boundary and run the interrupt line >> into a GPIO setup as a PPS input. (Maybe newer RTCs have a sub-second >> register.) >> >> >> >> -- >> These are my opinions. I hate spam. >> >> >> > > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there.