Hello,
I want to keep the time updated on a small Embedded Linux device.
The clock doesn't have to be very accurate. An offset of a few seconds
is OK.
This small device only has Internet for a few minutes a day and I have
to pay for each byte that gets transmitted, so I want to keep the
Le 27 avr. 2014 à 10:49, Manuel Reimer a écrit :
Hello,
I want to keep the time updated on a small Embedded Linux device.
The clock doesn't have to be very accurate. An offset of a few seconds is OK.
This small device only has Internet for a few minutes a day and I have to pay
for
mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux so responsibility should
reside there.
IIRC, the OP was a heads up which IS useful, but complaints should go to
the
Paul tik-...@bodosom.net wrote:
On Sat, Apr 26, 2014 at 6:30 PM, Rob nom...@example.com wrote:
Can't they add just one simple package to that?
Well pps-tools is clearly special. E.g. it's no longer advertised for 12.04
Well, it is for Ubuntu 14.04 LTS
Paul tik-...@bodosom.net wrote:
I don't know what terribly accurate might be to you but in the real world
sufficient accuracy depends on the circumstance.
Someone should conduct an experiment.
I am in a group that works on a project that needs synchronous audio
on geographically distributed
Le 27 avr. 2014 à 12:28, Rob a écrit :
mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux so responsibility should
reside there.
IIRC, the OP was a heads up which IS useful, but
On 27/04/14 11:28, Rob wrote:
is there a mailinglist or newsgroup where all those distributors
are reading so I don't need to create accounts on a zillion different
bugzillas and file a bug there?
You are still going to have to submit the individual bug reports as it
will be such a minor
mike cook michael.c...@sfr.fr wrote:
Le 27 avr. 2014 à 12:28, Rob a écrit :
mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux so responsibility
should reside there.
IIRC, the OP
On -10.01.-28163 20:59, Rob wrote:
Apparently there is unresolved discussion whether a .h describing a
PPS API belongs in the set of kernel include files or in a separate
package.
There is? Can't say I've ever dealt with PPS, but *if* this .h provides
the necessary information that *several*
I use Windows 8.1 and regularly see offsets of less than 1 ms.
Right now the offset is -0.105 and the jitter is 0.028. Twas not
always thus; several factors contributed to these results:
1. Use of Gigabyte Ethernet on the LAN, and the LAN is lightly loaded.
2. A high speed
On 04/27/2014 11:37 AM, mike cook wrote:
use the tinker directive in the ntp conf file.
ex. tinker panic 600
Thank you for this information, but where is this documented? At least
my man ntp.conf doesn't know a tinker.
$ ntpd --version
ntpd 4.2.6p5
ntpd 4.2.6p5@1.2349-o Tue Mar 11
Jochen Bern jochen.b...@linworks.de wrote:
On -10.01.-28163 20:59, Rob wrote:
Apparently there is unresolved discussion whether a .h describing a
PPS API belongs in the set of kernel include files or in a separate
package.
There is? Can't say I've ever dealt with PPS, but *if* this .h
First, we sync all machines to locally connected GPS receivers with
PPS output. We use ntpd and kernel PPS. This is wellknown territory.
In the ntpq -p stats this appears to bring the systems within 10us,
often within 2us, of the PPS signal. We still have to find out if this
is reality or
I want to keep the time updated on a small Embedded Linux device.
The clock doesn't have to be very accurate. An offset of a few seconds
is OK.
This small device only has Internet for a few minutes a day and I have
to pay for each byte that gets transmitted, so I want to keep the
I noticed yesterday morning that my time dispersion suddenly tightened up on my
server... Odd...
http://www.rabel.org/ntp/graph_dispersion.png
(Sorry for the jump at the end, that is when I restarted it earlier this
morning.)
At first I thought maybe NTP switched to a different server, so I
On -10.01.-28163 20:59, Rob wrote:
What I mean is that for building packages they need not only building
tools but also -dev packages for many libraries that are going to be
used by the packages being built. There is a long list of packages that
one is supposed to install before even
On Sun, Apr 27, 2014 at 12:57 AM, mike cook michael.c...@sfr.fr wrote:
If you look at those, they are included because the API does not ( or
didn't ) exist in the OSs whereas it does for Linux
I'll admit to being largely uninformed but to me it looks like all the
complete (per the RFC)
On 2014-04-27, mike cook michael.c...@sfr.fr wrote:
Le 27 avr. 2014 ? 05:36, Paul a ?crit :
On Sat, Apr 26, 2014 at 5:05 PM, Paul tik-...@bodosom.net wrote:
I think it's fair to wonder why the NTP tar ball doesn't include
timepps-Linux.h along with others they do include.
On Sat, Apr
On 2014-04-27, mike cook michael.c...@sfr.fr wrote:
Le 27 avr. 2014 ? 10:49, Manuel Reimer a ?crit :
Hello,
I want to keep the time updated on a small Embedded Linux device.
The clock doesn't have to be very accurate. An offset of a few seconds is OK.
This small device only has
On 2014-04-27, Rob nom...@example.com wrote:
Notice:
Several years ago I wanted to sync my clock to a GPS providing PPS.
At that time, PPS support in the kernel was only available as a set
of patches. You had to apply them to a kernel source tree and rebuild
the kernel. And I think
On 2014-04-27, Rob nom...@example.com wrote:
Paul tik-...@bodosom.net wrote:
I don't know what terribly accurate might be to you but in the real world
sufficient accuracy depends on the circumstance.
Someone should conduct an experiment.
I am in a group that works on a project that needs
In article ljf8q0$mt2$3...@dont-email.me, William Unruh
un...@invalid.ca wrote:
On 2014-04-26, Joe Gwinn joegw...@comcast.net wrote:
In article
8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com,
Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote:
I am new
William Unruh un...@invalid.ca wrote:
But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing requirements if they can be solved with an
interrupt driven pps.
Well, the kernel PPS
Jochen Bern jochen.b...@linworks.de wrote:
On -10.01.-28163 20:59, Rob wrote:
What I mean is that for building packages they need not only building
tools but also -dev packages for many libraries that are going to be
used by the packages being built. There is a long list of packages that
one
William Unruh un...@invalid.ca wrote:
The next problem is to send output to a soundcard and making it send
a sample at the sampling clock edge closest to a specified time.
(48kHz sampling rate corresponds to a sampling clock period of 20.8us)
It will certainly depend on the sound card. AFAIK
On 27/04/14 15:54, mike cook wrote:
So it looks like -g allows the step even with the tinker variable when the
difference is really big.
Yes. That's its purpose. It disables the first panic.
Also -x sets a large but finite value for when ntpd will step. (That
value also disables the
On 27/04/14 17:28, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas partly overlap.
This problem has already been solved using COFDM (aka
On Apr 27, 2014 10:19 AM, David Woolley david@ex.djwhome.demon.invalid
wrote:
On 27/04/14 17:28, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive
[Resend to list, rather than non-working(?) sender e-mail address]
On -10.01.-28163 20:59, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters. Experts in the field tell us we should
be within 12us.
Unless
On 2014-04-27, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing requirements if they can be solved with an
David Woolley david@ex.djwhome.demon.invalid wrote:
On 27/04/14 17:28, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the receive areas partly overlap.
William Unruh un...@invalid.ca wrote:
On 2014-04-27, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
But those modules give timing to one a few (5-10) usec. because of
interrupt handling issues. Your shm solution would seem to me to be more
than adequate for any timing
Jochen Bern jochen.b...@linworks.de wrote:
[Resend to list, rather than non-working(?) sender e-mail address]
On -10.01.-28163 20:59, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters. Experts in the field tell us we
Rob nom...@example.com wrote:
David Woolley david@ex.djwhome.demon.invalid wrote:
On 27/04/14 17:28, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same signal on the same
frequency on different sites, where the
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Your transmitters will have to be contained within a circle of 3.6km,
reduced by the timing errors in the modulation at 0.3km/microsecond.
This turns out to be not the case. Networks like this have been operating
for decades, only
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of
Rob nom...@example.com wrote:
Jochen Bern jochen.b...@linworks.de wrote:
[Resend to list, rather than non-working(?) sender e-mail address]
On -10.01.-28163 20:59, Rob wrote:
We are setting up a co-channel diversity network. That means multiple
FM transmitters that are transmitting the same
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Your transmitters will have to be contained within a circle of 3.6km,
reduced by the timing errors in the modulation at 0.3km/microsecond.
This turns out to be not the case. Networks like this have
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should
On -10.01.-28163 20:59, Rob wrote:
Jochen Bern jochen.b...@linworks.de wrote:
I'm afraid I don't get it yet. You're trying to sync waveforms on the HF
side (~100 MHz?) instead of switching between two transmitters on the AF
side (couple kHz, with that much more leeway for the sync), a la
On 2014-04-27, Rob nom...@example.com wrote:
j...@specsol.spam.sux.com j...@specsol.spam.sux.com wrote:
The listeners should enjoy a smooth reception while driving around.
So of course there should be no time lag between the modulation signals
of the different transmitters. Experts in the
45 matches
Mail list logo
