On Mon, May 13, 2019 at 05:35:41PM +1000, Stuart Longland wrote:
> Actually, silly thought… the `chronyc` command, is there a way to make
> the `waitsync` call via an API of some kind (HTTP-based perhaps?).
>
> It'd be really handy to know for sure the clock is set rather than just
> checking to
On Sun, May 12, 2019 at 03:51:43PM +1000, Stuart Longland wrote:
> I gave this a shot, but had no joy:
> > root@hackerlab:~# chronyd -q -t 30 "server 127.0.0.1 port 3123"
> > 2016-11-03T18:02:55Z chronyd version 3.0 starting (+CMDMON +NTP +REFCLOCK
> > +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND
On 7/5/19 6:11 pm, Miroslav Lichvar wrote:
> I'd suggest to set maxdistance to 5 or 10 to make sure it's not a
> problem with selecting the source. Try to reproduce the problem and
> post the output from the chronyc ntpdata, sources, sourcestats and
> tracking commands.
Okay, so testing at home…
On 8/5/19 1:30 am, Lonnie Abelbeck wrote:
> BTW, at startup our project always steps the time using (8 second timeout
> would be too low for you):
> --
> chronyd -q -t 8 "server time.example.tld iburst"
> --
> before starting "chronyd" in the background. (no systemd).
I gave this a shot, but had
On 8/5/19 11:29 am, Bill Unruh wrote:
> If the detector simply needs to be in the field for a few days, you can
> always
> set the rtc just before you put it into the field. It might, or might
> not hold
> reasonable accuracy for a couple of days (they can be out by many PPM
> especially if the
If the detector simply needs to be in the field for a few days, you can always
set the rtc just before you put it into the field. It might, or might not hold
reasonable accuracy for a couple of days (they can be out by many PPM
especially if the temperater fluctuates) Let say 20PPM which is a
On 8/5/19 10:35 am, Bill Unruh wrote:
>> Doable, and I've made future provision for it, but as stated, I'm trying
>> to keep costs down. If more hardware is the answer, my first stop will
>> be for a battery-powered RTC rather than a GPS.
>
> really cheap rtc will have trouble keeping 1 sec
On Wed, 8 May 2019, Stuart Longland wrote:
On 8/5/19 9:41 am, Bryan Christianson wrote:
How about using a USB GPS device.
Navisys have the GR-701W
(https://www.globalsources.com/gsol/I/Car-GPS/p/sm/1145283340.htm?WT.pos_kw=prod_PrdtKWSImage_1_0_GR-701W_NonSP_id=1145283340#1145283340)
On 8/5/19 9:41 am, Bryan Christianson wrote:
> How about using a USB GPS device.
>
> Navisys have the GR-701W
> (https://www.globalsources.com/gsol/I/Car-GPS/p/sm/1145283340.htm?WT.pos_kw=prod_PrdtKWSImage_1_0_GR-701W_NonSP_id=1145283340#1145283340)
> which provides a PPS signal over USB and
Why not put in an adafruit gps pps unit. They cost about $40, and get their
power from the computer. Don't know what your computer costs mind you.
William G. Unruh __| Canadian Institute for| Tel: +1(604)822-3273
Physics _|___ Advanced Research _| Fax: +1(604)822-5324
UBC,
> On 8/05/2019, at 10:32 AM, Stuart Longland wrote:
>
> On 8/5/19 4:10 am, Chris Greenman wrote:
>> Is there any possibility of using GPS for time? I had a similar dilemma
>> on my raspberry pi based boat computer. I didn't want to rely on
>> internet provided time since it might not be
On 8/5/19 8:42 am, Lonnie Abelbeck wrote:
>> The only time I have DNS is when I plug a USB cable into the
>> PocketBeagle that connects to a computer with an Internet connection.
> Thanks for the added info ... I was not sure if your AX.25 TNC supported some
> SLIP-like protocol (KISS ?).
>
>
> On May 7, 2019, at 5:19 PM, Stuart Longland
> wrote:
>
> On 8/5/19 1:30 am, Lonnie Abelbeck wrote:
>> Just curious, it appears you have native DNS, why do you need to proxy NTP
>> over APRS (unless you use a similar technique for DNS).
>
> Ahh, because I actually do not have DNS at all.
On 8/5/19 4:10 am, Chris Greenman wrote:
> Is there any possibility of using GPS for time? I had a similar dilemma
> on my raspberry pi based boat computer. I didn't want to rely on
> internet provided time since it might not be available if away from the
> slip.
Well, two reasons we didn't go
On 8/5/19 1:30 am, Lonnie Abelbeck wrote:
> Just curious, it appears you have native DNS, why do you need to proxy NTP
> over APRS (unless you use a similar technique for DNS).
Ahh, because I actually do not have DNS at all. Not when the devices
are out in the field. :-)
The only time I have
Is there any possibility of using GPS for time? I had a similar dilemma on
my raspberry pi based boat computer. I didn't want to rely on internet
provided time since it might not be available if away from the slip.
On Tue, May 7, 2019, 11:30 AM Lonnie Abelbeck
wrote:
>
>
> > On May 6, 2019,
> On May 6, 2019, at 10:53 PM, Stuart Longland
> wrote:
>
> Hi all,
>
> I've got a problem where I need to provide a time synchronisation
> service for small embedded computers whose only link to the outside
> world is a slow and high-latency packet radio network.
Stuart, Indeed very
On Tue, May 07, 2019 at 05:54:04PM +1000, Stuart Longland wrote:
> http://static.vk4msl.id.au/wicen/rfid/chrony/measurements.log
> http://static.vk4msl.id.au/wicen/rfid/chrony/statistics.log
> http://static.vk4msl.id.au/wicen/rfid/chrony/tracking.log
It's not very clear to me which parts of the
On 7/5/19 5:28 pm, Miroslav Lichvar wrote:
>> `chronyd` worked beautiful then. If the clock is years off though,
>> `chronyd` seems reluctant to do anything about it, assuming that the one
>> NTP server it can reach is at fault.
> That's weird. It might help if we could see the measurements,
>
On Tue, May 07, 2019 at 01:53:36PM +1000, Stuart Longland wrote:
> Hi all,
>
> I've got a problem where I need to provide a time synchronisation
> service for small embedded computers whose only link to the outside
> world is a slow and high-latency packet radio network.
Very interesting
Hi all,
I've got a problem where I need to provide a time synchronisation
service for small embedded computers whose only link to the outside
world is a slow and high-latency packet radio network.
In the locations where these are utilised:
- there is no cellular mobile coverage
- the devices are
21 matches
Mail list logo