mark.buechler at gmail.com
Wed May 24 22:30:09 UTC 2006
Wow, this calculation could be done on the backend and sent to the frontend
as a status showing approximate rotor move percentage. Interesting idea.
On 5/24/06, Yeasah Pell <yeasah at schwide.com> wrote:
> >This is mainly because I'm fearful of touching it because I have
> >neither here to do any testing with. If you could come up with a
> >clean DiSEqC implementation this would be much appreciated.
> >The code is just scary in so many ways, just look at that
> >handle_diseqc loop in DVBChannel, retries really should be
> >handled within the DiSEqC class, don't you think?
> Absolutely. There's a ton of things like that in the diseqc stuff.
> >Chained DisEqC devices aren't handled, except for the special
> >case of a switch+rotor*. We should at minimum support a tree
> >of switches, possibly ending in rotors and other devices;
> >preferably we should support devices anywhere in the tree.
> >This would require a new setup GUI in addition to the DiSEqC
> >code changes.
> I deliberately avoided talking about cascaded switches (didn't want to
> get lynched), but you're absolutely right. :-)
> There's other even more crazy situations that can arise with rotors too:
> * Two tuners driven by LNBs that are attached to the same motor. The
> first card controls the position, and the second one is a slave.
> * Two tuners driven by daisy chaining a single LNB. The first card
> controls the position, polarization and frequency range, and the second
> one is a slave (VDR does support this with a plugin.)
> Given that this has scheduling ramifications, and that even just
> recording multiple programs from a single multiplex is AFAIK still in
> development (right?), that kind of stuff seems way out there (certainly
> outside this discussion), but they are real world configurations that
> are definitely useful.
> >BTW Do you know if there is some way to determine when a rotor
> >command has been processed, i.e. when the dish is pointing where
> >you told it too? It would greatly aid the tuning code to know this.
> DiSEqC 2.0 supports bidirectional commands, and the spec defines
> everything you'd need to know what the motor is doing. Unfortunately I
> don't know of any motor that supports this, and even if they existed,
> the linux dvb api doesn't support 2.0 (although many cards do.) However,
> for my setup I have the diseqc class calculate how long it will take to
> do the move based on the last known location, and the motor manufacturer
> specifications for the angular speed at 13V and 18V. It works fairly
> well, though it's obviously not as good as having real motor feedback.
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev