Mailing List Archive

Re: Ticket #1945: DVB-S/diseqc patch
I see now. Thanks.

- Mark.

On 7/12/06, MythTV <mythtv@cvs.mythtv.org> wrote:
>
> #1945: DVB-S/diseqc patch
>
> --------------------------------+-------------------------------------------
> Reporter: yeasah@schwide.net | Owner: danielk
> Type: enhancement | Status: new
> Priority: minor | Milestone: 0.20
> Component: dvb | Version: head
> Severity: medium | Resolution:
>
> --------------------------------+-------------------------------------------
> Comment (by yeasah@schwide.net):
>
> Replying to [comment:34 Mark.Buechler@gmail.com]:
> > Looking at the bandstack patch, I don't see anywhere where the voltage
> is being overridden to 18 volts.
>
> Take a look at DiSEqCDevLNB::GetVoltage() ...
>
> --
> Ticket URL: <http://svn.mythtv.org/trac/ticket/1945>
> MythTV <http://www.mythtv.org/>
> MythTV
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
I've been testing this branch for several days now very successfully. My
setup is as follows:

1. Quad (circular/linear) LNB behind a rotor configured for 8 orbital
locations ranging from 61 degrees to 130 degrees (lower ones not tested due
to an annoying tree in my yard). Between the LNB and the rotor is a 4-port
DiSEqC switch, two ports in use from the quad-LNB.

2. Single LNB on a stationary dish hanging off of port 3 of the 4-port LNB
behind the rotor.

3. Two sources connected to a single stationary LNB (each source with a
different LOF).

4. Two LNBs connected to a stationary dish configured with two sources
available on two DVB cards. Connecting these LNBs is a built-in 2-port
DiSEqC switch. One source is shared with the #2 above. These LNBs are
bandstacked.

I have a total of 4 DVB cards in use (Genpix, SkyStar2, 2x Twinhan) so my
setup is not trivial. As far as I've tested, I've only seen one issue wrt to
the two Twinhan cards connected to the bandstacked LNBs and 2-port switch
where the switch did not switch properly. I've not been able to reproduce
this.

I have two suggestions for this branch:

1. Allow a rotor position of "none" to be entered in for an orbital location
which would result in the rotor not moving for a given switch position. This
is handy for my #2 configuration above.

2. (Optionally) execute any DiSEqC switch commands on every retune of the
DVB card. This would hande the case of stubborn switches which sometimes
fail to switch on the first command (or repeat afterwards).

- Mark.

On 7/13/06, MythTV <mythtv@cvs.mythtv.org> wrote:
>
> #1945: DVB-S/diseqc patch
>
> --------------------------------+-------------------------------------------
> Reporter: yeasah@schwide.net | Owner: danielk
> Type: enhancement | Status: new
> Priority: minor | Milestone: 0.20
> Component: dvb | Version: head
> Severity: medium | Resolution:
>
> --------------------------------+-------------------------------------------
> Comment (by danielk):
>
> (In [10493]) Refs #1945. Applies modified retune patch.
>
> The Retune() function was using prev_tuning for retuning, but this only
> gets set when the hardware tells us the tuning has been successful. This
> adds another variable, desired_tuning, which gets set whether or not the
> tuning has been successful the first time around, and uses this for
> retuning.
>
> --
> Ticket URL: <http://cvs.mythtv.org/trac/ticket/1945>
> MythTV <http://www.mythtv.org/>
> MythTV
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
For whatever reason, I am unable to switch to Port #2 of my diseqc
switch.

My Setup:
Genpix->Rotor->2 port diseqc->LNB's


Any pointers?

-----Original Message-----
From: mythtv-dev-bounces@mythtv.org
[mailto:mythtv-dev-bounces@mythtv.org] On Behalf Of Mark Buechler
Sent: Monday, July 17, 2006 12:55 PM
To: mythtv-dev@mythtv.org
Subject: Re: [mythtv] Ticket #1945: DVB-S/diseqc patch

I've been testing this branch for several days now very successfully. My
setup is as follows:

1. Quad (circular/linear) LNB behind a rotor configured for 8 orbital
locations ranging from 61 degrees to 130 degrees (lower ones not tested
due to an annoying tree in my yard). Between the LNB and the rotor is a
4-port DiSEqC switch, two ports in use from the quad-LNB.

2. Single LNB on a stationary dish hanging off of port 3 of the 4-port
LNB behind the rotor.

3. Two sources connected to a single stationary LNB (each source with a
different LOF).

4. Two LNBs connected to a stationary dish configured with two sources
available on two DVB cards. Connecting these LNBs is a built-in 2-port
DiSEqC switch. One source is shared with the #2 above. These LNBs are
bandstacked.

I have a total of 4 DVB cards in use (Genpix, SkyStar2, 2x Twinhan) so
my setup is not trivial. As far as I've tested, I've only seen one issue
wrt to the two Twinhan cards connected to the bandstacked LNBs and
2-port switch where the switch did not switch properly. I've not been
able to reproduce this.

I have two suggestions for this branch:

1. Allow a rotor position of "none" to be entered in for an orbital
location which would result in the rotor not moving for a given switch
position. This is handy for my #2 configuration above.

2. (Optionally) execute any DiSEqC switch commands on every retune of
the DVB card. This would hande the case of stubborn switches which
sometimes fail to switch on the first command (or repeat afterwards).

- Mark.
On 7/13/06, MythTV <mythtv@cvs.mythtv.org> wrote:
#1945: DVB-S/diseqc patch
--------------------------------+---------------------------------------
----
Reporter:  yeasah@schwide.net  |        Owner:  danielk
     Type:  enhancement         |       Status:  new
Priority:  minor               |    Milestone:  0.20
Component:  dvb                 |      Version:  head
Severity:  medium              |   Resolution:
--------------------------------+---------------------------------------
----
Comment (by danielk):

(In [10493]) Refs #1945. Applies modified retune patch.

The Retune() function was using prev_tuning for retuning, but this only
gets set when the hardware tells us the tuning has been successful. This

adds another variable, desired_tuning, which gets set whether or not the
tuning has been successful the first time around, and uses this for
retuning.

--
Ticket URL: < http://cvs.mythtv.org/trac/ticket/1945>
MythTV <http://www.mythtv.org/>
MythTV

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.2/393 - Release Date:
7/19/2006

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.2/393 - Release Date:
7/19/2006


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Zdzislaw Gorlicki wrote:

>For whatever reason, I am unable to switch to Port #2 of my diseqc
>switch.
>
>My Setup:
>Genpix->Rotor->2 port diseqc->LNB's
>
>
>Any pointers?
>
>
A log with "-v channel" turned on would be helpful, that way you'll see
all the diseqc stuff happening. A few things come to mind:

* It could be a configuration issue of some kind (if you don't see
"switching to port 2/2" or something like that in the log, this is
probably it)
* I've heard a report of a 2-port diseqc switch that is actually
controlled as a 4-port with the two physical positions on ports other
than 1 and 2. That might be worth trying.
* Alternatively, controlling it as a tone switch might work (though
cards based on the dst frontend driver have broken toneburst control
right now; I have a patch outstanding against the dst driver for that
but it still needs people to test before being applied)

_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Yeasah, I did notice a few times today something odd with your switch code.
The very first switch command sent (as the backend starts) doesn't seem to
work on either on my switches, or doesn't always work, anyway. I'm wondering
if your diseqc reset is throwing the switch for a loop for a brief period.
What's the wait time between switch commands? Is this reset necessary?
Tomorrow I'll test by taking out the reset to see if that helps though this
problem doesn't happen all the time for me.

- Mark.

On 7/20/06, MythTV <mythtv@cvs.mythtv.org> wrote:
>
> #1945: DVB-S/diseqc patch
>
> --------------------------------+-------------------------------------------
> Reporter: yeasah@schwide.net | Owner: danielk
> Type: enhancement | Status: closed
> Priority: minor | Milestone: 0.20
> Component: dvb | Version: head
> Severity: medium | Resolution: fixed
>
> --------------------------------+-------------------------------------------
> Comment (by danielk):
>
> (In [10611]) Refs #1945. Fixes #2074. Allows adding non DVB-S DVB
> recorders again...
>
> --
> Ticket URL: <http://cvs.mythtv.org/trac/ticket/1945#comment:45>
> MythTV <http://www.mythtv.org/>
> MythTV
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Mark Buechler wrote:

> Yeasah, I did notice a few times today something odd with your switch
> code. The very first switch command sent (as the backend starts)
> doesn't seem to work on either on my switches, or doesn't always work,
> anyway. I'm wondering if your diseqc reset is throwing the switch for
> a loop for a brief period. What's the wait time between switch
> commands? Is this reset necessary? Tomorrow I'll test by taking out
> the reset to see if that helps though this problem doesn't happen all
> the time for me.
>
> - Mark.

The reset is there just to get everything into an initialized state --
it only does it when the frontend device is first opened, as you say. It
isn't strictly required, since all the devices should be explicitly
reset to their desired values anyway, it's just in there to make sure
everything is completely sane before proceeding.

DiSEqCDevTree::ResetDiseqc is where the reset is done, you can look
there for details on what exactly happens at reset time. Basically the
reset delays are 100ms, and by default currently it power cycles the
diseqc devices as well. It would be interesting to know if the situation
improved if you disabled the power cycle (change it to call ResetDiseqc
with a the hard_reset parameter set to false).

Does this happen on more than one kind of DVB card, or have you only
noticed it on one type so far? I think you have a couple of twinhan dst
cards in your setup, don't you? I have a couple of patches outstanding
for that driver, one of which has been accepted but doesn't yet seem to
be in the main hg tree yet. One of them improves tone/power control, but
more importantly the other one improves error reporting. Without that
patch, failed commands would often not be reported to the application
(and in my experience there are times when the driver won't successfully
complete commands for extended periods of time, 100s of ms -- hence the
relatively lengthy ioctl retry sequences in the diseqc code.) I could
easily see that being part of the problem...

-y
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
This is with two different switches connected to two different DV cards (one
of them being a Twinhan). I'll test more tomorrow.

Thanks, Mark.

On 7/20/06, Yeasah Pell <yeasah@schwide.com> wrote:
>
> Mark Buechler wrote:
>
> > Yeasah, I did notice a few times today something odd with your switch
> > code. The very first switch command sent (as the backend starts)
> > doesn't seem to work on either on my switches, or doesn't always work,
> > anyway. I'm wondering if your diseqc reset is throwing the switch for
> > a loop for a brief period. What's the wait time between switch
> > commands? Is this reset necessary? Tomorrow I'll test by taking out
> > the reset to see if that helps though this problem doesn't happen all
> > the time for me.
> >
> > - Mark.
>
> The reset is there just to get everything into an initialized state --
> it only does it when the frontend device is first opened, as you say. It
> isn't strictly required, since all the devices should be explicitly
> reset to their desired values anyway, it's just in there to make sure
> everything is completely sane before proceeding.
>
> DiSEqCDevTree::ResetDiseqc is where the reset is done, you can look
> there for details on what exactly happens at reset time. Basically the
> reset delays are 100ms, and by default currently it power cycles the
> diseqc devices as well. It would be interesting to know if the situation
> improved if you disabled the power cycle (change it to call ResetDiseqc
> with a the hard_reset parameter set to false).
>
> Does this happen on more than one kind of DVB card, or have you only
> noticed it on one type so far? I think you have a couple of twinhan dst
> cards in your setup, don't you? I have a couple of patches outstanding
> for that driver, one of which has been accepted but doesn't yet seem to
> be in the main hg tree yet. One of them improves tone/power control, but
> more importantly the other one improves error reporting. Without that
> patch, failed commands would often not be reported to the application
> (and in my experience there are times when the driver won't successfully
> complete commands for extended periods of time, 100s of ms -- hence the
> relatively lengthy ioctl retry sequences in the diseqc code.) I could
> easily see that being part of the problem...
>
> -y
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Yeasah Pell wrote:

>Mark Buechler wrote:
>
>
>
>>Yeasah, I did notice a few times today something odd with your switch
>>code. The very first switch command sent (as the backend starts)
>>doesn't seem to work on either on my switches, or doesn't always work,
>>anyway. I'm wondering if your diseqc reset is throwing the switch for
>>a loop for a brief period. What's the wait time between switch
>>commands? Is this reset necessary? Tomorrow I'll test by taking out
>>the reset to see if that helps though this problem doesn't happen all
>>the time for me.
>>
>>- Mark.
>>
>>
>
>The reset is there just to get everything into an initialized state --
>it only does it when the frontend device is first opened, as you say. It
>isn't strictly required, since all the devices should be explicitly
>reset to their desired values anyway, it's just in there to make sure
>everything is completely sane before proceeding.
>
>DiSEqCDevTree::ResetDiseqc is where the reset is done, you can look
>there for details on what exactly happens at reset time. Basically the
>reset delays are 100ms, and by default currently it power cycles the
>diseqc devices as well. It would be interesting to know if the situation
>improved if you disabled the power cycle (change it to call ResetDiseqc
>with a the hard_reset parameter set to false).
>
>Does this happen on more than one kind of DVB card, or have you only
>noticed it on one type so far? I think you have a couple of twinhan dst
>cards in your setup, don't you? I have a couple of patches outstanding
>for that driver, one of which has been accepted but doesn't yet seem to
>be in the main hg tree yet. One of them improves tone/power control, but
>more importantly the other one improves error reporting. Without that
>patch, failed commands would often not be reported to the application
>(and in my experience there are times when the driver won't successfully
>complete commands for extended periods of time, 100s of ms -- hence the
>relatively lengthy ioctl retry sequences in the diseqc code.) I could
>easily see that being part of the problem...
>
>-y
>
>
Yeasah,

I would very much like to try out your patches for the dvb-s twinhan dst
card. I am running SVN 10628 and a week old mercurial v4l-hg, but still
have problems when changing a channel to another when these reside on
different multiplexes, as I quite frequently experience the cards are
not able to get a lock. I am running 8 cards connected to a multiswitch
controlling 4 quattro lnbs. Also, will increasing the dvb_tuning_delay
(currently at 0) in the capturecard table help me at all for these
cards? Appreciate your help on this.

//C


_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Mark Buechler wrote:

> Yeasah, I did notice a few times today something odd with your switch
> code. The very first switch command sent (as the backend starts)
> doesn't seem to work on either on my switches, or doesn't always work,
> anyway. I'm wondering if your diseqc reset is throwing the switch for
> a loop for a brief period. What's the wait time between switch
> commands? Is this reset necessary? Tomorrow I'll test by taking out
> the reset to see if that helps though this problem doesn't happen all
> the time for me.
>
> - Mark.

I think I might have an idea why this is happening. For a long time,
I've had the DVB global module parameter set to not power down the cards
after a timeout when it's closed -- since that feature makes it a pain
to do some kinds of things, and none of my cards run hot. I recently
turned that feature back on as part of getting back into spiffing up the
cx24123 driver, and I noticed a similar effect to what you've described
in various software -- the first command would generally fail.

It wasn't hard to isolate the behavior, and at least on the card and
diseqc devices I'm testing with, it looks like the following is true:

If the bus goes unpowered for > ~750 ms, no commands will succeed for a
period of ~500ms after the bus power is brought back up.

This kind of behavior is not surprising to me at all, but the required
delays are somewhat longer than I had thought they would be.

This has the following implications for the diseqc code:

1) The evidence is that a power-cycle will require on the order of ~1sec
of off time to be effective, and as such the hard_reset functionality
should probably be removed from the code (since nobody wants to wait a
whole second, and most people will be using the
voltage-off-when-device-is-closed feature so it should be coming up from
zero anyway)

2) When a device is first opened and the FE_SET_VOLTAGE command is
issued to bring up the bus, it should imply at least a 500ms wait before
sending any commands to allow everything to reach a sane state. That's
an annoyingly long time to wait, but I don't see any alternative.

I'll prepare a patch when I have a chance.

-y
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
Re: Ticket #1945: DVB-S/diseqc patch [ In reply to ]
Yeasah, thanks for looking into this. I've been meaning to look into this
the past few days but have not found the time.

As for the timing, I've noticed that the old DiSEqC code actually took a lot
longer. Did it have that long wait?

- Mark.

On 7/27/06, Yeasah Pell <yeasah@schwide.com> wrote:
>
> Mark Buechler wrote:
>
> > Yeasah, I did notice a few times today something odd with your switch
> > code. The very first switch command sent (as the backend starts)
> > doesn't seem to work on either on my switches, or doesn't always work,
> > anyway. I'm wondering if your diseqc reset is throwing the switch for
> > a loop for a brief period. What's the wait time between switch
> > commands? Is this reset necessary? Tomorrow I'll test by taking out
> > the reset to see if that helps though this problem doesn't happen all
> > the time for me.
> >
> > - Mark.
>
> I think I might have an idea why this is happening. For a long time,
> I've had the DVB global module parameter set to not power down the cards
> after a timeout when it's closed -- since that feature makes it a pain
> to do some kinds of things, and none of my cards run hot. I recently
> turned that feature back on as part of getting back into spiffing up the
> cx24123 driver, and I noticed a similar effect to what you've described
> in various software -- the first command would generally fail.
>
> It wasn't hard to isolate the behavior, and at least on the card and
> diseqc devices I'm testing with, it looks like the following is true:
>
> If the bus goes unpowered for > ~750 ms, no commands will succeed for a
> period of ~500ms after the bus power is brought back up.
>
> This kind of behavior is not surprising to me at all, but the required
> delays are somewhat longer than I had thought they would be.
>
> This has the following implications for the diseqc code:
>
> 1) The evidence is that a power-cycle will require on the order of ~1sec
> of off time to be effective, and as such the hard_reset functionality
> should probably be removed from the code (since nobody wants to wait a
> whole second, and most people will be using the
> voltage-off-when-device-is-closed feature so it should be coming up from
> zero anyway)
>
> 2) When a device is first opened and the FE_SET_VOLTAGE command is
> issued to bring up the bus, it should imply at least a 500ms wait before
> sending any commands to allow everything to reach a sane state. That's
> an annoyingly long time to wait, but I don't see any alternative.
>
> I'll prepare a patch when I have a chance.
>
> -y
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>