On Tue, Jan 06, 2004 at 05:46:42PM +1000, Michal Dobrzynski wrote:
And to answer my own question (I had just been grepping the source of
the CVS scan app for lnb) the answer is the new -l paramater. When I
used scan -l 11300,11300,11300 optusc1 to scan for channels it
You shouldn't have to have all three, just
-l 11300
would do in your case (since you don't have high / low)
immediately found the. Now why did it have to be so hard that it took
weeks to work out? :/
Was there no doco about this? Where should such a description go?
The problem with LNB's is that they seem to be different in parts
of the world. I had the same problem as you so I added the code you
found.
I wrote some doco for the dvsak library, which had a introductory
section which people new to DVB may find helpful as a starting
point. There is info about LNB's here.
Here is some of it, cut. I am / was working on a general library
and should put what I have so far up. But it actually has a long way
to go before being useful.
Jamie
-----------------------------------------------------------------------
--
DVB Info
Jamie Honan jhonan <at> optusnet.com.au
Introduction.
=============
The Linux DVB device drivers implement an API which is fully documented
elsewhere, at http://linuxtv.org/download/dvb/.
Background.
===========
In order to describe the <library> properly, some background in what
DVB
is and does, and in how the Linux DVB device drivers function, is
neccessary.
There are documents, books and standards that describe this in more
detail,
but as a general introduction, some simple statements that may not be
complete will be useful.
DVB, or Digital Video Broadcasting, is a set of standards that describe
how video and audio data should be transmitted over cable, satellite
and terrestial television systems.
The standards are very large, comprising many layers.
They can be read about in more detail on web sites such as
http://www.dvb.org or http://www.etsi.org
A short overview is presented here.
MPEG.
=====
For example, one part describes how the video and audio information
is to be compressed, the MPEG standard. We don't need to know about
this for the purposes of dvbsak, except to say that at some point
an MPEG stream must be presented to a decoder. dvbsak is really not
very concerned with this part.
Transmission.
=============
Other parts of these standards have to do with transmission coding :
how digital packets are to be coded in a wave based transmission
medium.
Again, we don't need to delve too greatly into details here, but
we do need some information in order to control the tuner devices
that recieve the signals we are interested in.
The three systems mentioned so far; cable, satellite and TV use
a modulated wave, based on a frequency.
How do we know which frequency?
===============================
For terrestial TV, the frequencies are decided on a national
basis. You can use a table for each country, and look to see
if there is a signal on each possible frequency.
For satellites, each satellite providor chooses a set of frequencies.
These are published on web sites such as http://www.satcodx.com or
http://www.lyngsat.com. They remain reasonably stable for a given
satellite position, though the satellites themselves are replaced.
Along with frequency, there are various other parameters that are
decided mostly on a national basis for terrestial TV and by individual
satellite operators.
These parameters include symbol rate, FEC, bandwidth amongst others.
The meaning of these parameters is unimportant, several of them
can be automatically determined by modern tuners. In some instances,
national standards require that they be automatically detected.
Satellite Specific Control.
===========================
Satellite systems have added layers of complexity in their
recievers.
If you were a pay TV subscriber, normally you would buy or lease
your dish and associated equipment from the pay TV operator, and would
not be concerned with these details.
Satellite systems have an LNB, or Low Noise Block device, mounted
in front of the satellite dish.
There are a variety of LNBs, and for historical reasons there
are important parameters that vary with the type of LNB.
LNB devices have a local oscillator, or LO. The frequency that
arrives at your reciever card is the offset from that LO.
Imagine you have an LNB with an LO of 11300 MHz. You wish
to recieve the frequency 12567 Mhz. At your reciever card you
would then look for a frequency of 1267 Mhz (which is 12567 - 11300).
Some LNB types can be grouped into names. These include 'Universal',
'DBS', 'Standard'. Others have no generic name, just a frequency.
Some satellite systems work on the C band. These frequencies
are much lower than Ku band frequencies of 10.7 to 12.75 GigaHerz. C
band
is around 3.6 - 4.2 GigaHerz.
Satellites also transmit their signal with a polarity. It could
be planar, as in vertical or horizontal. Other systems use a circular
polarity, left hand or right hand.
How this is implemented is not important. What is important is that
these details can't be hidden from a normal user unless the
system has already been set up for them by, for example, a pay tv
operator.
These details are also published on the satellite guide web sites
referred to earlier.
There is one other important aspect of satellite dish control, DiSEqC.
This is a standard for controlling satellite equipment such
as actuators and mux devices. Some satellite dish setups have a motor
that can move the dish to point to different satellites. This is
controlled by a DiSEqC sequence.
DiSEqC is a series of tones that are sent along the recieving cable
from the reciever card to the satellite dish or other equipment using
the recieving cable.
The full DiSEqC specification can be obtained from the Eutelsat
website, http://www.eutelsat.com.
DVB packets.
============
From one point of view of software that looks at recieved DVB data,
all data is broken into 188 byte packets.
The packets contain video, audio or other information.
We are not too concerned with the MPEG or video and audio information
here, except to note that the MPEG data is generally not
transmitted for a single 'program' on any one frequency, but for
multiple programs.
Most of us are used to choosing a station on a television set.
For analogue television, one frequency represents one station, which
carries one program.
For DVB, a frequency can and does carry a number of programs, which
may have little to do with each other.
The programs are considered to be 'multiplexed'.
So to select a program, a user is actually selecting a frequency,
and selecting one of the multiplexed programs on that frequency.
DVB 188 byte packets are called a transport stream. Each 188 byte
packet has four bytes as a header, and the rest as payload.
Inside the header, there are two fields of particular interest.
The first is the 'sync byte', 0x47, which indicates the start
of the 188 byte packet.
The second field of interest is a thirteen bit PID value. This value
is used to denote video and audio packets that belong to a common
program, but it is also used to indicate information, table, packets.
There are other fields in the header, but they are not discussed here.
DVB Tables.
===========
The informational, or table, packets are ones that dvbsak helps
in decoding, retaining and presenting.
These kinds of packets are called PSI or Program Specific Information
packets.
In particular, dvbsak helps with the following tables:
NIT - Network Information Table
PAT - Program Association Table
PMT - Program Map Table
SDT - Service Description Table
Network information is optional, and lets us know about this
and other frequencies, about the satellite position.
Program information lets us know how to identify the different
multiplexed streams, and how they are associated together to
make a program.
The two tables PAT and PMT make up the program information.
Service information describes the type of service, e.g. radio,
television,
teletext, data.
The specifications for DVB related tables are ETSI EN 300 468, ETSI TR
101
211 and ETSI ETR 211.
Linux DVB driver API.
=====================
As mentioned in the introduction, this API is fully documented
elsewhere,
but it is helpful to provide here a short overview.
The first thing to notice about the Linux DVB devices is their
place in the /dev/ tree.
The devices live, as far as this library and other software is
concerned,
under /dev/dvb/adapterN
where N is a number, 0, 1, 2 etc.
If you had a computer with two PCI cards, one for satellite
reception and the other for digital TV reception, then
/dev/dvb/adapter0 might refer to the satellite card, and
/dev/dvb/adapter1 the digital TV card. Which one would depend
on the order they were loaded, for example under module loading systems
such as modprobe.
Under the /dev/dvb/adapterN directory, are the controlling nodes
for that adapter.
The possible nodes are:
audioM
videoM
frontendM
netM
demuxM
dvrM
caM
where M is a number, 0, 1, 2 etc.
The frontendM device is the tuner, and things associated with
the tuner such as the satellite dish control.
The frontendM is controlled by ioctl system calls, these do things
such as tune to a frequency, determine if the device is tuned OK,
issue a DiSEqC command.
The demuxM device is used to control demultiplexing the DVB packets.
For example, you may only want the video and audio packets for
a single program. These would be specified by an ioctl on this
device interface, the packets would then be read on the dvrM device.
You may wish to demultiplex data to the same demuxM device. This
might be to read control information such as the program information.
The videoM and audioM devices are used to control the video
and audio decoder devices. These devices may not exist for cards
that have no MPEG decoder hardware.
The caM device controls the conditional access hardware, if it
exists. This is used to decrypt signals that are encrypted.
The netM device enables feeding multi protocol extension (MPE)
packets into the networking protocol stack. This might be used
for internet recieved by satellite.
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe
linux-dvb" as subject.