> 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 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
