Johannes Stezenbach wrote:
On Sun, May 07, 2006, Manu Abraham wrote:
Johannes Stezenbach wrote:
- it is wrong to believe that only the roll off factor is
relevant for the frontend, and other MATYPE bits are for the demux;
i.e. the frontend will do frame synchronization, needs to know
about ACM/CCM, and will output only one stream for MIS transmissions
MIS is optional for Broadcast Applications, Interactive Applications,
DSNG applications and Professional Applications. These are the profiles
supported by DVB-S2
Was looking at VCM applications only, rather ACM/CCM applications.
ok, what about adding the parameters like this then ..
enum fe_stream_type {
FE_TRANSPORT,
FE_GENERIC_PACKET,
FE_GENERIC_CONTINUOUS,
FE_STREAM_RESERVED
};
enum fe_stream {
FE_SINGLE_TS,
FE_MULTIPLE_TS
};
enum fe_coding {
FE_ADAPTIVE,
FE_CONSTANT
}
enum fe_istream_sync_indicator {
FE_ISSYI_ACTIVE,
FE_ISSYI_INACTIVE
};
enum fe_nullpacket_deletion {
FE_NPD_ACTIVE,
FE_NPD_INACTIVE
};
enum fe_rolloff {
FE_ROLLOFF_35,
FE_ROLLOFF_25,
FE_ROLLOFF_20,
FE_ROLLOFF_RESERVED
};
enum slicing_policy {
FE_SLICING_BREAK,
FE_SLICING_NO_TIMEOUT,
FE_SLICING_NO_PADDING,
FE_SLICING_NO_DUMMY
};
and add all these enumerations into the dvbs2 struct
I think this is too much.
What we need _now_ is the roll-off factor, which is announced
in the EN 300 468 satellite delivery system descriptor.
Ok.
However, if your hardware is giving you the 16-bit MATYPE
field, and you can even optionally set it, it might be useful
to have an __u16 matype in the API, at least for FE_GET_PARAMS.
I'm not sure, however...
Slicing Policy: It is handled in the DSP, we have no options to control it
UPL: 9.2 p 43,
The CRC encoder output is computed as: CRC = remainder [X8 u(X): g(X)]
where u(X) is the
input sequence (UPL 8 bits) to be systematically encoded. The computed
CRC-8 replaces the
sync byte of the following stream except if controlled differently
DFL: 9.3 (ST says like this)
9.3 Stream filter mechanism
A dedicated mechanism identifies the incoming streams based on the
MATYPE information.
A fixed length base-band header (BBHEADER) of 10 bytes is inserted in
front of the data field,
describing its format. The MATYPE can be found in the read-only register
MATSTR.
MATYPE (2 bytes) describes the input stream format, the type of mode
adaptation and the
transmission roll-off factor.
SIS/MIS (1 bit): describes whether there is a single input stream or
multiple input streams. If SIS/
MIS = multiple input stream, then the second byte is the input stream
identifier (ISI), otherwise
the second byte is reserved.
The stream filter can be handled by the I2C register where the MATYPE
register is forced.
More generally, all of the stream figures are stored in the MATSTR,
UPLSTR, DFLSTR,
SYNCSTR and SYNCDSTR registers. The respective parameters can be forced by
programming the MATCST, UPLCST, DFLCST, SYNCCST and SYNCDCST registers.
According to the specs, the rest of this fields are according to the
configuration/computation.
Certainly the demux would have to be changed for the case where
the demod does not output 188-byte MPEG-2 TS packets. But I
don't think any bits of the two-byte MATYPE field are of
any direct relevance to the demux. They are all for
use by the demod.
I was of the thought that the SYNC words and the stream lengths are for
the demux.
TR 102 376 v1.1.1 (2005-02) 6.2.2
Sure, the demux needs to know the format of the frontend output.
But first the demod needs to know how to synchronize to the stream
itself.
Right, I was wondering how we shall pass through the first stage itself. :-)
For Carrier Synchronization, the DSP has a Carrier Synchronization
Module, which is described like this.
The unique word processor (UWP) processes the physical layer header
symbols (PLHEADER) to:
* estimate the carrier frequency offset,
* determine frame timing,
* decode the PLSCODE to determine modulation format, code rate, and
pilot structure.
The digital carrier recovery loop has three phases:
* correlation peak detection,
* coarse and fine frequency estimation for acquisition,
* coarse and fine frequency tracking.
But, heck, the standard is not very verbose, it isn't clear
to me which bits of MATYPE you need to set before you are able
to receive a stream, and which parts are read from the stream
once you receive it. :-(
I think the fields in p 18 will suffice.
But UPL, DFL, SYNC, SYNCD, CRC8 won't be needed as inputs, since they
are either constants or the result of a computation in the driver.
Null Packet Deletion can be turned ON or OFF
The Transport Stream Sync byte Control can be setup like this
[7] DELSYNCBYTE.
0: normal mode
Used for bit error rate measurements using standard
Removes 1st byte of 188 bytes
[6] TSDEL_XXHEADER.
0: normal mode
Used for bit error rate measurements using standard
Removes 2nd, 3rd and 4th bytes of 188bytes
I don't fully understand the DVB-S2 spec yet, but I think
the way to select the stream is by using an 8bit
input_stream_identifier.
H.3 describes it. 8 bits isn;t needed, anyway boiling down to the
demod, that doesn't happen, it is a simple knob to select between the
streams.
Actually Appendix F is the backwards-compatible HP/LP mode.
going down ..
However, the discription doesn't make it clear how to
+struct dvbs2_params {
+ __u32 symbol_rate;
+
+ enum fe_modulations modulation;
+ enum fe_fecrates fecrate;
+ enum fe_stream streamtype;
+ enum fe_fecrates coderate_HP;
+ enum fe_fecrates coderate_LP;
+};
I think it speaks for itself. Isn't it descriptive ? Or is more comments
needed ?
If it needs more comments can add in.
What I meant is: "the description _in EN 302 307_ doesn't make it
clear"...
:-(
Well, EN50221 did not make many things clear, but we got it right .. :-)
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
