David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
For Rob, I would suggest that each TX have a GPS/PPS reference with sky
view, and that each PC was identical (e.g. all Raspberry Pi cards), and
then getting them synced to with 12 microseconds should be easy. I
Of course that is
On 29/04/2014 09:41, Rob wrote:
[]
Of course that is what we have.
E.g. on a prototype here at home:
ntpq -p
remote refid st t when poll reach delay offset jitter
==
oPPS(0) .PPS.
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
Unfortunately that is not the same as performing some task like outputting
audio at an accuracy of 12us, but that is the next challenge :-)
Indeed, and you will likely want to look at very matched systems (PCs
and transmitters - the
On 2014-04-29, Rob nom...@example.com wrote:
David Taylor david-tay...@blueyonder.co.uk.invalid wrote:
Unfortunately that is not the same as performing some task like outputting
audio at an accuracy of 12us, but that is the next challenge :-)
Indeed, and you will likely want to look at very
William Unruh un...@invalid.ca wrote:
The problem is not the electronics, it is the response of the system to
the interrupt. That interrupt processing time is in the usec range.
This does not really matter when it is constant.
And my experience is that the jitter on the PPS refclock is usually
William Unruh un...@invalid.ca wrote:
On 2014-04-29, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
The problem is not the electronics, it is the response of the system to
the interrupt. That interrupt processing time is in the usec range.
This does not really matter
On 27/04/14 19:20, j...@specsol.spam.sux.com wrote:
The goal is not to have 12us difference in arrival time, but to be
within 12us for transmission time.
But it is the difference in arrival time that will affect the quality of
the audio that is heard, so it is that which you would need to
William Unruh un...@invalid.ca wrote:
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
David Woolley david@ex.djwhome.demon.invalid wrote:
On 27/04/14 19:20, j...@specsol.spam.sux.com wrote:
The goal is not to have 12us difference in arrival time, but to be
within 12us for transmission time.
But it is the difference in arrival time that will affect the quality of
the audio
On 2014-04-28, Rob nom...@example.com wrote:
Jochen Bern jochen.b...@linworks.de wrote:
However, that *does* leave me wondering where the 12 us figure comes
into play. With the typical distances between 2m and even 70cm
repeaters, the mobile transceivers will see shifts *far* beyond that
On 28/04/14 16:19, William Unruh wrote:
For voice, the max frequency is something like 4KHz (eg telephone
quality) which is 250us (125us sampling) .
Telephone quality is 3.1 kHz bandwidth from 300Hz to 3.4kHz, which
allows for channel filters/realisable anti-aliasing filters.
I believe that
William Unruh un...@invalid.ca wrote:
All in all it is funny to read all the that cannot be done-like comments
by several persons on a ntp newsgroup while systems like this have been in
use since the seventies, and in fact have already been build by amateurs
and are in operation today. So I
On 2014-04-28, David Woolley david@ex.djwhome.demon.invalid wrote:
On 28/04/14 16:19, William Unruh wrote:
For voice, the max frequency is something like 4KHz (eg telephone
quality) which is 250us (125us sampling) .
Telephone quality is 3.1 kHz bandwidth from 300Hz to 3.4kHz, which
allows
On Mon, Apr 28, 2014 at 10:14 AM, William Unruh un...@invalid.ca wrote:
Not sure why they would need a lower cutoff, except that it would allow
the ancient telephone receivers to comply. Certainly one can make
cheap receivers now that go a lot lower than 300Hz.
Because 3.1 kHz of bandwidth is
On 04/28/2014 07:37 PM, Henry Hallam wrote:
On Mon, Apr 28, 2014 at 10:14 AM, William Unruh un...@invalid.ca wrote:
Not sure why they would need a lower cutoff, except that it would allow
the ancient telephone receivers to comply. Certainly one can make
cheap receivers now that go a lot lower
On 28/04/14 18:14, William Unruh wrote:
Not sure why they would need a lower cutoff, except that it would allow
the ancient telephone receivers to comply.
To give good carrier suppression on analogue carrier systems! I believe
that there is also a lot of energy below 300Hz that doesn't
On 2014-04-28, Rob nom...@example.com wrote:
William Unruh un...@invalid.ca wrote:
All in all it is funny to read all the that cannot be done-like comments
by several persons on a ntp newsgroup while systems like this have been in
use since the seventies, and in fact have already been build by
For Rob, I would suggest that each TX have a GPS/PPS reference with sky
view, and that each PC was identical (e.g. all Raspberry Pi cards), and
then getting them synced to with 12 microseconds should be easy. I
achieve this even with indoor GPS puck antennas:
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
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
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
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:
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 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
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.
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
On Fri, Apr 25, 2014 at 11:22 PM, William Unruh un...@invalid.ca wrote:
I have 8 machines that reliably sync from one GPS PPS driven
machine (all using chrony) and they get time reliability of about
10microseconds
How do you determine the 10 micosec. value?
And why are you conflating NTP
On 2014-04-26, Paul tik-...@bodosom.net wrote:
On Fri, Apr 25, 2014 at 11:22 PM, William Unruh un...@invalid.ca wrote:
I have 8 machines that reliably sync from one GPS PPS driven
machine (all using chrony) and they get time reliability of about
10microseconds
How do you determine the 10
On Sat, Apr 26, 2014 at 8:30 PM, William Unruh un...@invalid.ca wrote:
use the offset scatter as an estimate of the
time performace (It is at least some sort of upper bound, but as I have
said, not terribly accurate)
I suspect you shouting CANNOT is probably overstating the issue. After all
On 2014-04-27, Paul tik-...@bodosom.net wrote:
On Sat, Apr 26, 2014 at 8:30 PM, William Unruh un...@invalid.ca wrote:
use the offset scatter as an estimate of the
time performace (It is at least some sort of upper bound, but as I have
said, not terribly accurate)
I suspect you shouting
On 2014-04-24, Montgomery, Peter BIS peter.montgom...@fs.utc.com
wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server
within 1ms if the client and server are Linux applications on a
Montgomery, Peter BIS writes:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a
server within 1ms if the client and server are Linux applications on a
simple local network ( less than 10 nodes).
Yes, in
Le 25 avr. 2014 à 08:34, William Unruh a écrit :
On 2014-04-24, Montgomery, Peter BIS peter.montgom...@fs.utc.com
wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server
within 1ms if
On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS
peter.montgom...@fs.utc.com wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server
within 1ms if the client and server are Linux
Henry Hallam he...@pericynthion.org wrote:
On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS
peter.montgom...@fs.utc.com wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server
I would like to know whether NTP can sync between a
client and a server within 1ms if the client and server
are Linux applications on a simple local network ( less
than 10 nodes).
Yes, if simply go by the offset figure in NTP, you can usually get
sub-millisecond figures between two
On 2014-04-25, Rob nom...@example.com wrote:
Henry Hallam he...@pericynthion.org wrote:
On Thu, Apr 24, 2014 at 8:07 AM, Montgomery, Peter BIS
peter.montgom...@fs.utc.com wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP
On Thu, Apr 24, 2014 at 11:07 AM, Montgomery, Peter BIS
peter.montgom...@fs.utc.com wrote:
I would like to know whether NTP can sync between a client and a server
within 1ms if the client and server are Linux applications on a simple
local network ( less than 10 nodes).
As previously
In article
8188ba2b01fb534a99c03d79c62ce1d80982f...@uusnwe3a.global.utcmail.com,
Montgomery, Peter BIS peter.montgom...@fs.utc.com wrote:
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server
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 to NTP. But I have a quick question that I need to answer soon.
I would like to
I am new to NTP. But I have a quick question that I need to answer soon.
I would like to know whether NTP can sync between a client and a server within
1ms if the client and server are Linux applications on a simple local network (
less than 10 nodes).
Sincerely,
Peter
56 matches
Mail list logo
