Re:

On Wed, Feb 06, 2008 at 06:50:05PM +0000, Måns Rullgård
wrote:
> Rich Felker <daliasaerifal.cx> writes:
> 
> > On Wed, Feb 06, 2008 at 07:02:11PM +0100, Michael
Niedermayer wrote:
> >> > A clock this bad would drift by 1/4 an
hour per day. I doubt anyone
> >> > would buy such a clock...
> >> 
> >> No, but people buy various embeded devices to
watch videos and their clocks
> >> are supposed to be cheap. And while i dont
think they would be off by
> >> 15min/day i doubt you can expect more than
1min/day accuracy from them.
> >
> > FWIW, this matches the estimates in my other email
of 0.1% error.
> >
> > Also, maybe this is getting OT, but truely
"broadcast" (in the sense
> > of airwaves being involved) applications have a
matched-to-sender
> > clock pulse already via the PLL or whatever
similar circuits they use
> > in the tuner equipment.
> 
> There is no correlation between the carrier and the
data.  The carrier
> has nothing whatsoever to do with sender/receiver
synchronisation.

Not in existing devices, but there's no fundamental reason
it can't be
used for this purpose. That was my only point in mentioning
this
otherwise OT tidbit.

> > Incidentally, at least as I understand it, PLL
itself works on a
> > concept similar to what I described, consisting of
local clock
> > (oscillator) plus adjustments from the input
signal, and operating
> > without a separate reference clock source.
> 
> The input signal *is* the reference clock.  You are
suggesting we
> remove the input signal.

Depending on the application, it can be, but it can also be
a signal
modulated on a carrier, and the circuit can synchronize to
the carrier
without having a separate pure reference signal. I agree
that argument
by analogy is not a good argument method, but here I'm using
it as a
suggestion of a line of thinking based on something
familiar. Anyway
it's all just an aside, and if you don't like the analogy,
drop it,
because its truth is not in any way tied to the truth of the
important
claims.

Rich
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

On Wed, Feb 06, 2008 at 02:00:52PM -0500, Rich Felker
wrote:
> On Wed, Feb 06, 2008 at 06:50:05PM +0000, Måns Rullgård
wrote:
> > Rich Felker <daliasaerifal.cx> writes:
> > 
> > > On Wed, Feb 06, 2008 at 07:02:11PM +0100,
Michael Niedermayer wrote:
> > >> > A clock this bad would drift by 1/4
an hour per day. I doubt anyone
> > >> > would buy such a clock...
> > >> 
> > >> No, but people buy various embeded
devices to watch videos and their clocks
> > >> are supposed to be cheap. And while i
dont think they would be off by
> > >> 15min/day i doubt you can expect more
than 1min/day accuracy from them.
> > >
> > > FWIW, this matches the estimates in my other
email of 0.1% error.
> > >
> > > Also, maybe this is getting OT, but truely
"broadcast" (in the sense
> > > of airwaves being involved) applications have
a matched-to-sender
> > > clock pulse already via the PLL or whatever
similar circuits they use
> > > in the tuner equipment.
> > 
> > There is no correlation between the carrier and
the data.  The carrier
> > has nothing whatsoever to do with sender/receiver
synchronisation.
> 
> Not in existing devices, but there's no fundamental
reason it can't be
> used for this purpose. That was my only point in
mentioning this
> otherwise OT tidbit.

<pic showing rich floating in space with a screwdriver,
screeming
"I must fix the satelites, so they synchronize their
transmitters with
the data transmitted" >

[...]

-- 
Michael     GnuPG fingerprint:
9FF2128B147EF6730BADF133611EC787040B0FAB

I hate to see young programmers poisoned by the kind of
thinking
Ulrich Drepper puts forward since it is simply too narrow --
Roman Shaposhnik

_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel

Rich Felker <daliasaerifal.cx> writes:

> On Wed, Feb 06, 2008 at 06:50:05PM +0000, Måns Rullgård
wrote:
>> Rich Felker <daliasaerifal.cx> writes:
>> 
>> > On Wed, Feb 06, 2008 at 07:02:11PM +0100,
Michael Niedermayer wrote:
>> >> > A clock this bad would drift by 1/4
an hour per day. I doubt anyone
>> >> > would buy such a clock...
>> >> 
>> >> No, but people buy various embeded devices
to watch videos and their clocks
>> >> are supposed to be cheap. And while i dont
think they would be off by
>> >> 15min/day i doubt you can expect more than
1min/day accuracy from them.
>> >
>> > FWIW, this matches the estimates in my other
email of 0.1% error.
>> >
>> > Also, maybe this is getting OT, but truely
"broadcast" (in the sense
>> > of airwaves being involved) applications have
a matched-to-sender
>> > clock pulse already via the PLL or whatever
similar circuits they use
>> > in the tuner equipment.
>> 
>> There is no correlation between the carrier and the
data.  The carrier
>> has nothing whatsoever to do with sender/receiver
synchronisation.
>
> Not in existing devices, but there's no fundamental
reason it can't be
> used for this purpose.

The carrier is rarely, if ever, generated at the signal
source.  A
satellite broadcast always has at least two links (earth to
satellite
and satellite to earth).  On each leg, the sender generates
its own
carrier (this is true whatever the medium of the link), and
attempting
to synchronise them would be madness.  The carrier
frequencies on
different links can differ by orders of magnitude (from
10GHz
satellite to 500MHz terrestrial).  There need not even be a
carrier at
all.

>> > Incidentally, at least as I understand it, PLL
itself works on a
>> > concept similar to what I described,
consisting of local clock
>> > (oscillator) plus adjustments from the input
signal, and operating
>> > without a separate reference clock source.
>> 
>> The input signal *is* the reference clock.  You are
suggesting we
>> remove the input signal.
>
> Depending on the application, it can be, but it can
also be a signal
> modulated on a carrier, and the circuit can synchronize
to the
> carrier without having a separate pure reference
signal. I agree
> that argument by analogy is not a good argument method,
but here I'm
> using it as a suggestion of a line of thinking based on
something
> familiar. Anyway it's all just an aside, and if you
don't like the
> analogy, drop it, because its truth is not in any way
tied to the
> truth of the important claims.

Judging by the above nonsense, you are in no way familiar
with
modulation, PLLs, or anything else related to signal
transmission.

-- 
Måns Rullgård
mansmansr.com
_______________________________________________
NUT-devel mailing list
NUT-develmplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/nut-devel