Reply to thread

Message

<blockquote data-quote="deeptho" data-source="post: 1162614" data-attributes="member: 215446">Lately I have been working on improvving the drivers for stid135, mainly to make it easierto support tbs6916, which has 4 RF inputs, 8 tuners, and 16 demods. This requires solvingall kinds of small problems such as preventing two stid135 chips connected to the same cablefrom causing conflicts, such as one selecting a high band and the other a low band. It also requiredmaking small changes to neumoDVB.The new drivers (not yet released) also solve some other &quot;race&quot; problems which could affect tbs6909x and tbs603x as well. These races can cause some muxes to not be scanned properlyafter switching band/pol because demods do not wait for a tuner to be properly configured (by which I mean: sending diseqc, setting tone...)Most of the bugs seem to be gone. Today I&nbsp; scanned many satellites without problem,but I know one more bug is left.The card runs fast and well. Here is an example of a blindscan of 52E, which takesabout 4 minutes, including getting the spectrum (which is not included in the 3min 24s).When the card fails to scan muxes, usually there seems to be a good reason for it.[ATTACH=full]156470[/ATTACH]The new drivers also expose all kinds of useful information in /sys. For example, the following2 commands show the temperature of the two stid135 chips, while in use.[CODE]$cat /sys/module/stid135/card0/chip0/temperature37$cat /sys/module/stid135/card0/chip1/temperature36[/CODE]The value is rather low as the card has a fan (which is also a downside: there is some noise)And this shows what is happening during a scan: 16 demods are using the same 'input (cable &quot;in0&quot;), which is currently on 18BVolt and no tone[CODE]$cat /sys/module/stid135/card0/statecard_no = 0 dev =00000000c01c2d8fuse_count = 2chips: 00000000408871bf 000000006af36acarf_in[0]: use_count=16 owner=13559 controller=0 voltage=18V tone=offrf_in[1]: use_count=0 owner=-1 controller=-1 voltage=off tone=offrf_in[2]: use_count=0 owner=-1 controller=-1 voltage=off tone=offrf_in[3]: use_count=0 owner=-1 controller=-1 voltage=off tone=off[/CODE]And using a script, we can inspect the registers of the chips fo debugging. In thiscase, the first demod on&nbsp; the second chip has set a 22kHz tone on the cable[CODE]stidmap.py|grep REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG0.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(2)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(3)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(4)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(1)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000000.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(2)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(3)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(4)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x000000020.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(1)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; = 0x00000002[/CODE]What the script does is read a binary file /sys/module/stid135/card0/chip0/registers/stid135and then interpret the registers. It is also possible to write to them, but that is for hackers...All of the above also works on tbs6909x and tbs6903x.During the testing, the power supply of my PC died. I also discovered, using an oscillosope,that some of my diseqc switches behaved very badly and caused voltage drops of several volts formany milliseconds. This could also be related to my power supply.I also found out that the drivers by TBS program the chip to output 21KHz instead of 22kHz and this caused diseqc switching to fail from time to time on some switches. I still need to check if this problem is also present on tbs6909X. That requires me to swap cards and there is some work involved.</blockquote>

[QUOTE="deeptho, post: 1162614, member: 215446"] Lately I have been working on improvving the drivers for stid135, mainly to make it easier to support tbs6916, which has 4 RF inputs, 8 tuners, and 16 demods. This requires solving all kinds of small problems such as preventing two stid135 chips connected to the same cable from causing conflicts, such as one selecting a high band and the other a low band. It also required making small changes to neumoDVB. The new drivers (not yet released) also solve some other "race" problems which could affect tbs6909x and tbs603x as well. These races can cause some muxes to not be scanned properly after switching band/pol because demods do not wait for a tuner to be properly configured ( by which I mean: sending diseqc, setting tone...) Most of the bugs seem to be gone. Today I scanned many satellites without problem, but I know one more bug is left. The card runs fast and well. Here is an example of a blindscan of 52E, which takes about 4 minutes, including getting the spectrum (which is not included in the 3min 24s). When the card fails to scan muxes, usually there seems to be a good reason for it. [ATTACH type="full" alt="x.png"]156470[/ATTACH] The new drivers also expose all kinds of useful information in /sys. For example, the following 2 commands show the temperature of the two stid135 chips, while in use. [CODE]$cat /sys/module/stid135/card0/chip0/temperature 37 $cat /sys/module/stid135/card0/chip1/temperature 36 [/CODE] The value is rather low as the card has a fan (which is also a downside: there is some noise) And this shows what is happening during a scan: 16 demods are using the same ' input (cable "in0"), which is currently on 18BVolt and no tone [CODE] $cat /sys/module/stid135/card0/state card_no = 0 dev =00000000c01c2d8f use_count = 2 chips: 00000000408871bf 000000006af36aca rf_in[0]: use_count=16 owner=13559 controller=0 voltage=18V tone=off rf_in[1]: use_count=0 owner=-1 controller=-1 voltage=off tone=off rf_in[2]: use_count=0 owner=-1 controller=-1 voltage=off tone=off rf_in[3]: use_count=0 owner=-1 controller=-1 voltage=off tone=off [/CODE] And using a script, we can inspect the registers of the chips fo debugging. In this case, the first demod on the second chip has set a 22kHz tone on the cable [CODE] stidmap.py|grep REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG 0.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(2) = 0x00000002 0.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(3) = 0x00000002 0.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(4) = 0x00000002 0.0: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(1) = 0x00000000 0.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(2) = 0x00000002 0.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(3) = 0x00000002 0.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(4) = 0x00000002 0.1: REG_RC8CODEW_DVBSX_DISEQC_DISTXCFG(1) = 0x00000002 [/CODE] What the script does is read a binary file /sys/module/stid135/card0/chip0/registers/stid135 and then interpret the registers. It is also possible to write to them, but that is for hackers... All of the above also works on tbs6909x and tbs6903x. During the testing, the power supply of my PC died. I also discovered, using an oscillosope, that some of my diseqc switches behaved very badly and caused voltage drops of several volts for many milliseconds. This could also be related to my power supply. I also found out that the drivers by TBS program the chip to output 21KHz instead of 22kHz and this caused diseqc switching to fail from time to time on some switches. I still need to check if this problem is also present on tbs6909X. That requires me to swap cards and there is some work involved. [/QUOTE]

Verification