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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
