Re: [RFC] Should a DVB frontend report the board name?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2/7/07, CityK <CityK@xxxxxxxxxx> wrote:
I don't want to derail the underlying discussion at hand (although it
strikes me as not everyone talking about the same thing), but I do want
to just pick up on a particular point:

Manu Abraham wrote:
> for the average person, frontend = RF module, inclusive of the demod

And if that is what the average person believes, then they would indeed
be correct.   (Although I have serious doubts that the average person
knows what a frontend is ;) )

A Frontend is just an abstraction.  In some cases a frontend can be
described entirely by a NIM/RF module such as the LGH06xF (which is
inclusive of the demodulator) or, in the case of older designs like the
pcHDTV HD-2000 or DVICO FusionHDTV3 series, both the RF module AND the
external demodulator comprise the frontend.


There are different cases, for example

* a complete tuner is never in one chip, unless it is a silicon tuner
* a silicon tuner and a demod is never in one chip, unless it is a
Direct Conversion receiver, similar to the Superhet radio's, no
Intermediate Frequencies in such a case.

when you have a device implemented in silicon and the integration is
high, similarly to your integration constant "C" the greater the
integration, the greater the "noise floor".

when you have a demod, these days many demods are implemented on a
FPGA . In such cases the operational noise is too high for the analog
core to be very near the digital core.

In any RF design, looking at the electrical side of it, we do have
separate electrical grounds such as Analog RF ground and Digital RF
ground separately, to avoid loops which create
oscillations/intermodulate distortion.


So the concept of a frontend /nim/dc receiver are all names which are
used in different contexts for different categories of devices. But it
is quite hard to draw a distinct line, in such a case. It could be
argued either ways. (Just like painting the bikeshed green)



> frontend = demod name (that's what we have currently),

And that would technically be wrong ... although if it works into the
coding framework, then so be it.

> Tuner is unimportant in this case as it doesn't have much of ops.

I'm not certain what you mean by "ops", but I gather that its minor role
is what has lead to the project's definition of frontend to equal demod


The project has never stated that at any place. Or is there ?

But i don't understand what your argument is -- for example when i
have a "tuner module" (tin can inclusive of the demod) say one based
on a STV0299, what advantage do you get by telling the user that it
uses a TSA5059 PLL in the RF stage ?



Lastly, as some food for thought -- we're already starting to see the
move towards multi-purpose IC's.  Examples:
- Xceive 3028 tuner and analog demod;
- ATI theater 650 analog demod, A/V decoder & mpeg encoder.
It likely will be a few years yet, but pretty soon we WILL run into the
case where the traditional frontend and "backend" components on the DTV
devices merge into one IC.  How then does one define the abstraction?

even though the entire thing is in one chip, it is an abstraction, so
it doesn't matter whether the MPEG decoder and the demodulator are on
the same chip. Still they are separate functional blocks requiring
separate control (You can't ask a MPEG decoder to do some job on a RF
signal)


At that point, the concept will only refer to the relevant processing
stages carried out in that single IC.


IC  = Integrated Circuit. Integration doesn't mean that you loose
control. Of course noise is added into the system. The greater the
integration the greater the noise, in a constant environment.


> With this it gives the bridge name, Generic name and the frontend
> name, all in it's own relevant place and not in the frontend. it will
> be just messing up the frontend to a state where it will be hopeless.
>
> for example:
> bridge name = "Mantis PCI rev 1.0"
> Generic name = "VP-1034"
> frontend name = "MB86A16 DVB-S/DSS DC receiver"
>
> It additionally fixes some other issues as well, such as handling
> bridge reset 's etc.

Will this solution account for a single, multifunctional IC, as I have
just described?


Why not ? look at the MB86A15/16 (tuner + demod in a single chip in that sense)

manu

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux