[linux-dvb] [discussion] Frontend capable of reporting and
supporting supported diseqc version
abraham.manu at gmail.com
Tue Dec 12 14:55:17 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 card
>>> does support.
>> The difference that i understand as related to a frontend is in the need
>> 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 the
>> 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 16
>> 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 and
>> 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, did
>> 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 advertise
>> 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 the
> 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.
> The mb86a16 does handle errors but blames them all on "I2C transfer error".
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
▪ 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.
> The others i did not check but error value returned tells something about
> 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 so
> 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