[linux-dvb] [discussion] Frontend capable of reporting and
supporting supported diseqc version
michel at verbraak.org
Tue Dec 12 15:59:31 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.
>>>>> 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
>>>> 22k tone ?
>>> If you look on the technotrend webshop site for their TT-premium®
>>> 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
>>> 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
>>>> 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
>>>> 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
>>> 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
> 2.x reply.
> The only frontend with sets diseqc_recv_slave_reply call back function is
> the s5h1420.
>>> 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 have to correct myself the only diseqc level 2.2 command in spec if
diseqc command 64 and it will return 1 byte where the bits state the
different status values.
Should the FE_DISEQC_RECV_SLAVE_REPLY be used for this?
> 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
>>> 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
>>> 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.
> linux-dvb mailing list
> linux-dvb at linuxtv.org
More information about the linux-dvb