>> Michel Verbraak wrote: >>>> Hello Michel, >>>> >>>> Michel Verbraak wrote: >>>>> Manu, >>>>> >>>>> 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 >>> card >>> (http://shop.technotrend.de/shop.php?mode=show_detail&lang=de&group=3&sid=0f192923a0f47071359497f16673c527&s=&id=26) >>> 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 >> commands. >> >>> On the KNC one website their specs do not even mention diseqc level >>> (http://www.knc1.com/gb/download/datasheet_digital_tv_cards.pdf) >>> >>> 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. >>>> >>>> >>>> Manu >>>> >>> >>> 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 >>> supported. >>> 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 > 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 >>> 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 >> 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 >> DVB) >> ▪ 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 >>> 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. >> >> >> Regards, >> Manu >> > > > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
