[linux-dvb] [discussion] Frontend capable of reporting and
supporting supported diseqc version
michel at verbraak.org
Tue Dec 12 15:48:15 CET 2006
> Michel Verbraak wrote:
>>> Hello Michel,
>>> Michel Verbraak wrote:
>>>> As Joep also posts I'm not talking about can it receive diseqc 2.0
>>>> replies. But why can the driver not tell what version of diseqc the
>>>> does support.
>>> The difference that i understand as related to a frontend is in the
>>> to identify whether it supports Diseqc 2x or 1x. Obi wrote the same on
>>> the list.
>>> In this case , as i wrote earlier on the list, you can check whether
>>> device supports 2x by seeing what the ioctl returns.
>>>> I took me some time, through the suppliers websites, to find out if a
>>>> dvb-s card was capable of supporting diseqc and which version. Twinhan
>>>> does specify it on its website but there are plenty which do not. The
>>>> TechnoTrend crads only support diseqc 1.0 and not higher.
>>> Which frontend is this based on ? the STV0299 ? Or do you mean the
>>> AV7110 based cards ? Or do you mean to say that they supported only the
>>> 22k tone ?
>> If you look on the technotrend webshop site for their TT-premium® S-2300
>> it says:
>> Steuerung LNB / (DiSEqC-) Switch (14/18V, 22KHz / DiSEqC1.0)
>> As wel for their other dvb-s cards.
> It is based on the STV0299 ? Wondering why it supports only Diseqc 1.0
> (22k tone control)
> Whereas the STV0299 has a diseqc FIFO itself, for sending Diseqc 1x
>> On the KNC one website their specs do not even mention diseqc level
>> A friend of mine has a hauppauge Nexus-s where only in the pfd manual it
>> was described only capable of diseqc 1.0 (on the box was nothing
>> mentioned). This card is maybe from before the diseqc 1.2/2.x specs.
>>> What happened with Twinhan was that earlier they had the dst based (a
>>> bit x86 style microcontroller on the CI based cards and a 8 bit MCS51
>>> style microcontroller on the FTA cards) DVB cards. These cards did not
>>> expose the frontends as it is, like other cards. In this case, the
>>> Diseqc commands what you can send is limited on them. On the oldest
>>> cards there wasn't any diseqc support also, IIRC. (they did not have a
>>> PCI subsystem ID also, no EEPROM) Later, they added support for the PCI
>>> subsystem ID and 22k tone, in a later model, it would support only 3
>>> 4 byte long commands only , in another 3, 4 and 5. This were all
>>> dependant on the assembly code running on the microcontroller.
>>> For example, the same card with a STV0299 based frontend on 2 different
>>> models would support different functionality, depending upon the
>>> software running on the host microcontroller on these cards.
>>> So they advertised different diseqc versions as they changed things,
>>> eventhough the hardware remained completely the same. (The last touted
>>> by them was diseqc 1.2, for rotor control)
>>> What i remember is that some of the older Twinhan (dst based) cards,
>>> not support 5 bytes and or some others. If you look at dst.c , in
>>> dst_tlist, you will see what i mean.
>>> So with the newer cards eventhough without the dst, they still
>>> the same.
>> If I look trough the different frontend sources for their
>> diseqc_send_master_cmd I can see the following:
>> The stv0299 does return an error depending if it was not able to write
>> diseqc command byte or had a timeout writing. As far as I can see the
>> problem of the error does not tell if the diseqc command bytes were not
>> The cx24110 always return 0 only when the amount of diseqc command bytes
>> 3 or > 6 then return -EINVAL
>> The MT312 does the same as the stv0299.
> The MT312, according to the specs,
> Full DiSEqC™ v2.2 is provided for both writing and reading DiSEqC™
> messages. Storage in registers for up to
> eight data bytes sent and eight data bytes received is provided.
As far as I can see the MT312 does not have the diseqc_recv_slave_reply
call back function set so the driver can never be queried for the diseqc
The only frontend with sets diseqc_recv_slave_reply call back function is
>> The mb86a16 does handle errors but blames them all on "I2C transfer
> In the case of the MB86A16, the device supports all diseqc 1.x levels
> The highlighted features are like this ..
> ▪ DVB-S (SCPC) and DSS compatible
> ▪ No external inductors and variable capacitance diodes required
> ▪ No 30V power supply for tuning required. (Supply voltage : +5V, +3.3V
> and +2.5V)
> ▪ Input frequency range : 950MHz to 2150MHz
> ▪ Input signal level per channel : typ. -75dBm to -10dBm
> ▪ Symbol rates : 1Mbaud to 45 Mbaud
> ▪ Carrier capture range : ±5MHz
> ▪ IQ automatic detection
> ▪ Automatic detection of Viterbi code rate R=1/2, 2/3, 3/4, 5/6, 7/8(for
> ▪ I2C bus interface
> ▪ DiSEqCTM 1.x compatible
> ▪ Built-in carrier frequency offset monitor (via I2C bus interface)
> In such a case all errors are considered to be communication errors, ie
> I2C transfer error, because all "1x" operations are supported.
> Diseqc 2x IOCTL will return an error in this case, not I2C error.
> Depending on the error returned, you can know what caused it to fail,
> whether it is unsupported or a failed operation.
Is this true because normally for a diseqc 2.x command you would first
send a FE_DISEQC_SEND_MASTER_CMD ioctl with the diseqc command bytes and
then a FE_DISEQC_RECV_SLAVE_REPLY ioctl to read the reply. The
FE_DISEQC_SEND_MASTER_CMD might return without an error and the
FE_DISEQC_RECV_SLAVE_REPLY would return -EOPNOTSUPP.
I will test this tonight with the vp-1034 (mb86a16) i have.
>> The others i did not check but error value returned tells something
>> the transfer of the diseqc command bytes to the card and not if the card
>> can support them.
>> As I understand from you it will be a big problem to get this into the
>> driver because the same hardware with different firmware/microcontroller
>> software supports different diseqc levels.
> Regarding the dst, yes, it had been a big pain to have all the different
> cards to work with one common driver.
>> I started this thread just to see if the driver model could be adjusted
>> the applications written to use the drivers can handle errors or not
>> supported diseqc commands better. Currently they only get an error back
>> which could be due to the card not supporting the diseqc command or
>> probably even more that the driver could not communicate to the card
>> because of a hw failure or a broken card.
> Then there is a bug in the driver and or elsewhere, if errors for
> unsupported features are returned back as communication errors.
More information about the linux-dvb