Hello and Merry Christmas,
I made an embedded (S)NTP server. The software is still under
development and will eventually include a low-grade GPSDO but right now
even the simplistic algorithm is working quite well so I figured I'd share.
http://www.eevblog.com/forum/oshw/%27laureline%27-embedd
12:18:30 -0500
From: Michael Tharp
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] An embedded NTP server
Message-ID: <50d9dfe6.2050...@partiallystapled.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hello and Merry Christmas,
I made an e
The NXP LPC111x series has a PLL that runs at 156 to 320 MHz. You then divide
the clock down (internally by 2,4,8, or 16) to what you want. 50 MHz is the
max. for the LPC111x series. Giving you capture ticks in 20nS increments.
I have some experiments in the works with an LPC1114 chip and a 40
Hello and Merry Christmas,
I made an embedded (S)NTP server. The software is still under
development and will eventually include a low-grade GPSDO but right now
even the simplistic algorithm is working quite well so I figured I'd share.
http://www.eevblog.com/forum/oshw/%27laureline%27-embedded-
On 12/25/2012 02:51 PM, David J Taylor wrote:
I think you should be able to do better on the jitter as your algorithms
develop.
Yes, for starters something is causing a silly amount of extra latency
hence the 2.4ms round-trip. I managed to cut that in half by changing
compiler options but tal
This is good. And really good that you have opened the design. Once
a few of these get out into the "wild" you can start seeing software
contributions and the performance will improve. We know that an ARM
based NTP server can do very well. Hopefully it can one day beat a
low-end Linux setup wh
time-nuts@febo.com
Subject: Re: [time-nuts] An embedded NTP server
On 12/25/2012 02:51 PM, David J Taylor wrote:
> I think you should be able to do better on the jitter as your
> algorithms develop.
Yes, for starters something is causing a silly amount of extra latency hence
the 2.4ms round
From: Michael Tharp
[]
Oh, and your Windows box 172.24.0.68 is either poorly configured or
broken - they can work much, much better than yours illustrates as I
expect you know.
Yes, it's not healthy. I installed Meinberg's NTP build and configured
it using defaults other than the server list bu
ke an OSH Park "gold plated" board. I love
> their service.
>
>
> Simon
>
> ===
>
>
> Message: 1
> Date: Tue, 25 Dec 2012 12:18:30 -0500
> From: Michael Tharp
> To: Discussion of precise time and frequency measurement
>
>
On 12/26/2012 12:01 PM, Chris Albertson wrote:
The VXCO quality hardly matters for an NTP server. As long as it
does not gain out loose more then 1 uSecond per second. In other
words one part per million is fine for NTP. The goal is not to
produce a 10MHz GDPDO. Clients using this server ove
albertson.ch...@gmail.com said:
> The VXCO quality hardly matters for an NTP server. As long as it does not
> gain out loose more then 1 uSecond per second. In other words one part per
> million is fine for NTP. The goal is not to produce a 10MHz GDPDO. Clients
> using this server over the Et
On 12/27/2012 01:41 AM, Michael Tharp wrote:
The good news is that the disciplining algorithm I lifted from my
previous GPSDO project works quite well, and I have the gritty details
of measuring the PPS worked out. If I can get the Trimble working
tomorrow I might have much better results soon, o
On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray wrote:
>
> It would be interesting to see what ntpd would do on a system with a very
> good clock and/or what you could do to the code/heuristics to take advantage
> of a stable clock.
>
I've read reports of people who have un-soldered the crystal from
Hi
Much easier to simply use a cheap chip set (as in sub $3) that supports 1588
packet time stamping. It's doing everything you would need to do as far as
packet time of arrival. The heavy lifting would all be in the area of porting
that data into the NTP server.
Bob
On Dec 28, 2012, at 12:34
On 12/28/12 9:34 AM, Chris Albertson wrote:
On Thu, Dec 27, 2012 at 1:36 AM, Hal Murray wrote:
One idea that I like is to first get a large FPGA. Then you load in a
"soft CPU" and then you run an OS and NTP on the soft CPU. Inside
the softCPU the counter is implemented like it is in a rea
On 12/28/2012 12:34 PM, Chris Albertson wrote:
One idea that I like is to first get a large FPGA. Then you load in a
"soft CPU" and then you run an OS and NTP on the soft CPU. Inside
the softCPU the counter is implemented like it is in a real CPU but
you can add the ability for a PPS to "latch
Hi
The only problem you may run into with an input capture is that the 72 MHz may
be from an internal VCO that's locked to the external clock source or crystal.
Often these micro's don't have VCO's that are as good a one might hope. You
will indeed have less than 1 UI jitter, you may not have a
On Tue, 1 Jan 2013 11:23:57 -0500
Bob Camp wrote:
> The only problem you may run into with an input capture is that the
> 72 MHz may be from an internal VCO that's locked to the external clock
> source or crystal. Often these micro's don't have VCO's that are as good
> a one might hope. You will
On 01/01/13 17:34, Attila Kinali wrote:
On Tue, 1 Jan 2013 11:23:57 -0500
Bob Camp wrote:
The only problem you may run into with an input capture is that the
72 MHz may be from an internal VCO that's locked to the external clock
source or crystal. Often these micro's don't have VCO's that are
Hi
Most of the small micro's don't get very fancy on the clock chain. You are
lucky if the VCO is running at twice the CPU clock. In some cases the input
capture(s) (and PWM's) are running directly on the VCO (at say 72 MHz) and the
CPU is running at half or a quarter of that.
Bob
On Jan 1
Hoi Bob,
On Tue, 1 Jan 2013 12:03:49 -0500
Bob Camp wrote:
> On Jan 1, 2013, at 11:34 AM, Attila Kinali wrote:
>
> > What about those uC that use a VCO that runs up at several 100MHz (i've
> > seen up to 800MHz) and devide it down to what they actually need.
> > Shouldnt this improve jitter qu
Hi
The little Arm7/ Cortex-M3 micro's don't pay as much attention to the clock
chain as some of their bigger brothers (like a Sandy Bridge I7) do. At least
the M3's and M4's I have seen are running the VCO at 50 to 150 MHz to generate
a CPU clock at that frequency. The clock is divided by two f
Hi
I'm not bashing the Arm parts, they are nice gizmos. They don't do the clock
chains the way they do because they are lazy. They very much plan things out.
Their main target audience is low power portable gear. Having a part that drops
down to very low current when nothing much is going on is
In message , Bob Camp writes:
>I'm not bashing the Arm parts, [...] They worry about every uA of
>current drain
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expectations but a little bit
flakey at high clock
r's Vcc is enough to keep it running. Saves a
jumper.
Didier
Sent from my Droid Razr 4G LTE wireless tracker.
-Original Message-
From: Poul-Henning Kamp
To: Discussion of precise time and frequency measurement ,
Bob Camp
Sent: Tue, 01 Jan 2013 2:16 PM
Subject: Re: [time-nuts]
In message <1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com>, "M. Si
mon" writes:
>The NXP LPC111x series [...]
My personal preference is the LPC1343, because it has a USB port, and
because there is a reltively nice codebase to start from:
https://github.com/microbuil
On 1/1/13 12:16 PM, Poul-Henning Kamp wrote:
In message , Bob Camp writes:
I'm not bashing the Arm parts, [...] They worry about every uA of
current drain
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expe
t at a
profit.
>
> From: Poul-Henning Kamp
>To: M. Simon ; Discussion of precise time and frequency
>measurement
>Sent: Tuesday, January 1, 2013 9:26 PM
>Subject: Re: [time-nuts] An embedded NTP server
>
>
>In message <1357073110.354
enning Kamp
>To: M. Simon ; Discussion of precise time and frequency
>measurement
>Sent: Tuesday, January 1, 2013 9:26 PM
>Subject: Re: [time-nuts] An embedded NTP server
>
>
>In message <1357073110.35421.yahoomail...@web160905.mail.bf1.yahoo.com>, "M
Hi
The VCO is part of the process, the PLL and it's loop are another part. There's
no reason why they can't put a good loop in a micro, other than chip area for
the passive parts. What ever they do, the loop will probably be a compromise,
since the frequencies involved are not known at design t
t too
> much trouble.
>
>
> Simon
>
>
> Engineering is the art of making what you want from what you can get at
> a profit.
>
>
>
>>
>> From: Poul-Henning Kamp
>>To: M. Simon ; Discussion of precise
On 1/1/2013 4:58 PM, time-nuts-requ...@febo.com wrote:
True story:
Many years ago when the very first ARM silicon arrived and they started
testing it, it was generally execeeding expectations but a little bit
flakey at high clock rates.
After the bubbly had been drunk and hangovers subdued, th
In message <50e45382.8090...@irtelemetrics.com>, Dan Kemppainen writes:
>Back on topic (sort of). I've been playing with some of the PIC24
>chips lately. They have some neat oscillator options internally,
I've given up on PIC and Atmel microcontrollers and their antiquated
CPU designs.
On Wed, Jan 2, 2013 at 11:16 AM, Poul-Henning Kamp wrote:
> I've given up on PIC and Atmel microcontrollers and their antiquated
> CPU designs.
>
> My life is too short to fight odd-ball compilers, when I can get a
> real 32 bit CPU and a good compiler instead.
That is a valid point if you are b
In message
, Chris Albertson writes:
>That is a valid point if you are building a one-off project. Your
>time is worth something. But if you plan to sell a million AA cell
>battery chargers using a 32-bit controller is uneconomical.
But that's generally not what we discuss here on tim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2013 19:25, Chris Albertson wrote:
> For an NTP server I'd go with something that can run an OS and the
> NTP reverence implementation. ARM (and others) can do that.
>
This is exactly what I've done using the Raspberry Pi (Broadcom ARM
SOC
From: James Harrison
[]
This is exactly what I've done using the Raspberry Pi (Broadcom ARM
SOC running Linux) and a GPS module with the PPS kernel hook for Linux
GPIO. Still a beginner/aspiring time-nut so I'm not sure on accuracy
(PLL offset jitter suggests ~5-10ms worst-case but I've not looked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/01/2013 20:05, David J Taylor wrote:
> James,
>
> You might be interested in my write-up:
>
> http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html
>
> and its performance:
>
> http://www.satsignal.eu/mrtg/performance_ntp.php
>
> I was playing
On 1/2/13 11:37 AM, Poul-Henning Kamp wrote:
Actually, the OS is not important, floating point support is.
floating point support in the sense that the compiler supports it and
generates appropriate code to use software FP or hardware FP as available?
Or you need HW floating point for per
On Wed, Jan 2, 2013 at 12:37 PM, Poul-Henning Kamp wrote:
>
> Actually, the OS is not important, floating point support is.
That is one reason that the recent crop of inexpensive ARM Cortex M4
experimenter boards is quite interesting. I picked up two of the TI
Stellaris Launchpads on pre
Hi
That's the point I've been trying to make for about a month now. At some point,
for a hobby project, the cost of the CPU becomes irrelevant. In my book, once
the CPU goes below the price of lunch at McDonalds, it really doesn't matter
much.
Bob
On Jan 2, 2013, at 7:36 PM, Joseph Gray wrot
On 1/2/13 4:46 PM, Bob Camp wrote:
Hi
That's the point I've been trying to make for about a month now. At some point,
for a hobby project, the cost of the CPU becomes irrelevant. In my book, once
the CPU goes below the price of lunch at McDonalds, it really doesn't matter
much.
yes.. it's
Hi
Arduino's original popularity was based on low cost. These days you can get a
*lot* more for your money.
Bob
On Jan 2, 2013, at 8:07 PM, Jim Lux wrote:
> On 1/2/13 4:46 PM, Bob Camp wrote:
>> Hi
>>
>> That's the point I've been trying to make for about a month now. At some
>> point, for
+1 for Forth!
+1 for your opinions on PICs & AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of intelligent
design!
Do you really need an OS? Surely for a box that is only
On 1/2/13 5:34 PM, Tom Harris wrote:
+1 for Forth!
+1 for your opinions on PICs & AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of intelligent
design!
Do you really ne
On 01/02/2013 08:34 PM, Tom Harris wrote:
Do you really need an OS? Surely for a box that is only ever going to be an
NTP server you just need a network interface and good maths? I've just seen
a later comment where you mention floating point support, but would 64 bit
integer maths work just as w
On 03/01/13 03:26, Jim Lux wrote:
On 1/2/13 5:34 PM, Tom Harris wrote:
+1 for Forth!
+1 for your opinions on PICs & AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of in
how about a Propeller? 8 cpu's no waiting :-)
Don
Magnus Danielson
> On 03/01/13 03:26, Jim Lux wrote:
>> On 1/2/13 5:34 PM, Tom Harris wrote:
>>> +1 for Forth!
>>>
>>> +1 for your opinions on PICs & AVRs. We can buy low end NXP ARM
>>> Cortex M0
>>> chips (e.g. LPC1113) for less than the PIC18 we
On 03/01/13 05:13, Don Latham wrote:
how about a Propeller? 8 cpu's no waiting :-)
Lack of interrupts is disturbing.
http://en.wikipedia.org/wiki/Parallax_Propeller#Dedicated_cores_instead_of_interrupts
Let's not discuss particular chips like this.
Cheers,
Magnus
__
From: Tom Harris
+1 for Forth!
+1 for your opinions on PICs & AVRs. We can buy low end NXP ARM Cortex M0
chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
has a real compiler and (unlike the real world) evidence of intelligent
design!
Do you really need an OS? Surely for
Not only SSH access, loggin g things like DNS lookup and rading the
ntp.comf file from local (flash?) memory. And then without an OS
you'd have to implement sceduling and process creation yourself. How
else to accept SSH log ins, talk to multiple NT clients and yu
reference clocks and write to th
In message <50e4c479.5080...@earthlink.net>, Jim Lux writes:
>On 1/2/13 11:37 AM, Poul-Henning Kamp wrote:
>>
>> Actually, the OS is not important, floating point support is.
>
>floating point support in the sense that the compiler supports it and
>generates appropriate code to use softwa
In message
, Tom Harris writes:
>+1 for Forth!
Indeed, but for me that is only an indulgence :-)
>+1 for your opinions on PICs & AVRs. We can buy low end NXP ARM Cortex M0
>chips (e.g. LPC1113) for less than the PIC18 we were using before, and it
>has a real compiler and (unlike the rea
In message <50e4ec50.1030...@earthlink.net>, Jim Lux writes:
>On 1/2/13 5:34 PM, Tom Harris wrote:
>I think the dividing line might be [...]
I would say: When you need TCP/IP.
USB (unless it is ether-over-usb) is trivial to do in "big-loop" but
a TCP/IP network stack is not.
--
Poul-
On 1/3/13 12:53 AM, Poul-Henning Kamp wrote:
In general, you should reuse as much code as you can, life is too short
to write another UDP checksum subroutine.
You captured it exactly..
The thrill of implementing sin() is long past.
Heck, I'd be happy with something that ran Matlab/Octave/Sci
55 matches
Mail list logo
