Hi there
Rob van der Putten wrote:
Cut
A lot of people however, by an embedded system, hook op a GPS receiver,
find that PPS doesn't work and then just give up.
Apparently GPSD supports PPS on CTS.
So if you already have got an embedded system and a GPS receiver and
your 232 cape supports
On 09/07/2014 18:45, Paul wrote:
[]
However you're showing a bias which steers away from a better
solution, not needing the overhead of fully-featured NTPd isn't a
defect it's an advantage.
Simply that different folk have different needs.
You later say: It's a Reference Clock not an instance
On 7/9/2014 11:40 PM, Paul wrote:
On Wed, Jul 9, 2014 at 8:05 PM, Null wrote:
[stuff]
Please check the links provided. It would seem the most common
problem people have is not being able to think about a network
attached reference clock that uses NTP responses rather than PPS +
serial stream
On Thu, Jul 10, 2014 at 4:20 AM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
Simply that different folk have different needs.
This true but not nearly as much as people think. But yes different
folks have different needs. Despite that in the next sentence
You later say: It's a
On Thu, Jul 10, 2014 at 9:07 AM, Brian Utterback
brian.utterb...@oracle.com wrote:
You still have the keys problem. Keys authenticate the NTP server to the
client. How would you manage keys?
Are you asking if it supports autokey? It currently doesn't,
according to the doc there's one
On 7/10/2014 9:26 AM, Paul wrote:
On Thu, Jul 10, 2014 at 9:07 AM, Brian Utterback
brian.utterb...@oracle.com wrote:
You still have the keys problem. Keys authenticate the NTP server to the
client. How would you manage keys?
Are you asking if it supports autokey? It currently doesn't,
On 10/07/2014 14:13, Paul wrote:
On Thu, Jul 10, 2014 at 4:20 AM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
Simply that different folk have different needs.
This true but not nearly as much as people think. But yes different
folks have different needs. Despite that in the
On Thu, Jul 10, 2014 at 10:17 AM, Brian Utterback
brian.utterb...@oracle.com wrote:
Well, at least it supports the one key and it is apparently changeable. But
NTP authentication is not mutual authentication, nor does it have anything
to do with entitlement of the client.
I spoke overly
On 08/07/2014 19:14, Paul wrote:
[]
The previous version let you monitor the GPS data stream and I monitor
time performance indirectly e.g. using ntpdate. Since it doesn't
actually run NTP typical NTP status and management is irrelevant.
I have to disagree with you there. As I understand, it
On Wednesday, July 9, 2014, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
I have to disagree with you there. As I understand, it is an NTP server
Quoting the maker:
... Laureline is an embedded SNTP server that receives time from a GPS
receiver in the form of a pulse-per-second
On Wed, Jul 9, 2014 at 8:38 AM, Paul tik-...@bodosom.net wrote:
... Laureline is an embedded SNTP server
By the way that was the description of the previous generation product
-- the original is here:
http://www.eevblog.com/forum/oshw/'laureline'-embedded-gps-ntp-server/
The current version
On 09/07/2014 14:23, Paul wrote:
On Wed, Jul 9, 2014 at 8:38 AM, Paul tik-...@bodosom.net wrote:
... Laureline is an embedded SNTP server
By the way that was the description of the previous generation product
-- the original is here:
On Wed, Jul 9, 2014 at 11:42 AM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
However, for me, if someone wants an NTP server something like the Raspberry
Pi with GPS/PPS is a good, simple, cheap solution, which is easily managed
by the user.
No management required can be better
Paul wrote:
A Laureline is a better NTP response provider than an RPi (see mike cook's
plots)
and doesn't require *any* configuration or monitoring
(but mike cook shows graphs for those that care about such things).
No compiling, no OS updates, no conf file fiddling, no management.
On Wed, Jul 9, 2014 at 8:05 PM, Null wrote:
[stuff]
Please check the links provided. It would seem the most common
problem people have is not being able to think about a network
attached reference clock that uses NTP responses rather than PPS +
serial stream as a solution to time transfer. It's
Hi there
Paul wrote:
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Obviously.
A lot of people however, by an embedded system, hook op a GPS receiver,
find that PPS doesn't work and then just give up.
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
You mean something like this? *grin*
http://www.rabel.org/pics/Net4501-2.jpg
Yes, that is one of
On 08/07/2014 11:01, Rob van der Putten wrote:
Hi there
Paul wrote:
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Obviously.
A lot of people however, by an embedded system, hook op a GPS receiver,
On Mon, Jul 7, 2014 at 4:38 PM, David Lord sn...@lordynet.org wrote:
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
Perhaps you're referring to
On Tue, Jul 8, 2014 at 6:01 AM, Rob van der Putten r...@sput.nl wrote:
A lot of people however, by an embedded system, hook op a GPS receiver, find
that PPS doesn't work and then just give up.
That's appropriate. If you don't know what you're doing and choose
not to do the work to learn then
Paul wrote:
On Mon, Jul 7, 2014 at 4:38 PM, David Lord sn...@lordynet.org wrote:
I'd have to look this up but think board using Elan 486 used the
on chip high speed timer to timestamp the pps input at a gpio
port along with a custom ntpd on FreeBSD to obtain sub us offset.
Perhaps you're
On 08/07/2014 14:37, Paul wrote:
[]
People looking for inexpensive, low overhead NTP appliances should be
supporting Partially Stapled's Laureline development.
I would have supported that, partially because I like the chap what he
does, but their server didn't support any of the standard NTP
On Tue, Jul 8, 2014 at 1:00 PM, David Taylor
david-tay...@blueyonder.co.uk.invalid wrote:
I would have supported that, partially because I like the chap what he
does, but their server didn't support any of the standard NTP management
commands last time I looked
I did talk to him about
I bought one of these to see what it could do and wrote a review on the
Tindie site. One of the issues I raised was the volume and ad hoc format of
stats messages he puts out on port 514 for syslog . I just updated that review
with info on a log message filter I wrote, which makes loopstats
Hi there
Jaap Winius wrote:
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Thus far I've always attached my GPS and radio time signal receivers to
much larger x86 hardware platforms, but those machines have
On Mon, Jul 7, 2014 at 12:39 PM, Rob van der Putten r...@sput.nl wrote:
AFAIK the BBB 232 cape doesn't support DCD, so PPS is not available.
One normally uses a so-called GPIO pin to read PPS on systems that
lack a DCD line or a parallel port. E.g. BeagleBone or Raspberry Pi.
Rob van der Putten wrote:
Hi there
Jaap Winius wrote:
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Thus far I've always attached my GPS and radio time signal receivers to
much larger x86 hardware
On Sat, 05 Jul 2014 23:37:05 +, Jaap Winius wrote:
Hi folks,
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Thus far I've always attached my GPS and radio time signal receivers to
much larger x86
On Sun, Jul 6, 2014 at 2:25 AM, detha de...@foad.co.za wrote:
Be sure to include some form of
external RTC though.
While sometimes useful a real time clock isn't required on a typical*
S1 server. By the way, some GPS modules have an RTC which (if battery
supported) will produce a reasonable
Jaap,
You can skim over these past few months on the time-nuts list. There's lots of
threads with discussion on ARM, Beaglebone, Rasberry
Pi, etc... for GPS based NTP servers...
http://www.febo.com/pipermail/time-nuts/2014-March/date.html
Hi folks,
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Thus far I've always attached my GPS and radio time signal receivers to
much larger x86 hardware platforms, but those machines have other things
to do
On Sat, Jul 5, 2014 at 7:37 PM, Jaap Winius jwin...@umrk.nl wrote:
Has anyone here managed to turn a relatively cheap, ARM-based embedded
system with a serial port into a decent stratum 1 NTP server?
Yes (Google NTP Beaglebone or NTP Raspberry Pi I have both) although
since that almost
32 matches
Mail list logo
