[mythtv] diseqc

[Yeasah Pell]

Emboldened by Daniel's semi-endorsement of hierarchical diseqc devices, 
I cranked out some fancy tree-based diseqc code last night. It involves 
some DB changes of course, and I'm not sure how that is generally 
handled (obviously if such a patch is accepted a schema version needs to 
be assigned, a schema upgrade needs to be added to dbcheck.cpp, and I 
assume a requirement is that everything be backwards-compatible -- i.e. 
no removing anything from the DB, just deprecation)

I figure it could use some going over anyway, so I'm posting the rough 
schema changes that the tree-based code uses currently (with some 
explanation). Essentially there are two new tables -- a table called 
"diseqc" (probably should be called diseqcsetup or something) which 
contains id/value pairs forming a particular configuration of a 
particular diseqc tree (these are associated with card inputs), and a 
table called "diseqctree" which contains the actual tree of diseqc 
devices (these are associated with capture cards)

All these names are just what I could come up with in 15 seconds or less 
and they generally suck, so feel free to suggest improvements there as 
well as in the structure. Even calling everything "diseqc" is a bit of a 
misnomer since the LNBs have been absorbed into the network (though 
there are apparently diseqc controlled LNBs in this world, and one could 
argue that tone-controlled LNBs are "diseqc-ish", since diseqc is just 
tone modulation)

The diseqc configuration table assumes that every device that needs 
per-input configuration can represent it in a single value, which is 
more or less true for current devices (float vs. integer 
notwithstanding) LNBs needs no configuration from that table (they take 
their configuration directly from the tuning parameters)

I represented the tree structure with parent pointers and child ordinals 
(diseqcparent and diseqcport), which saves having to represent the tree 
structure in a separate table, but does make traversing the tree 
slightly more interesting. I think the tradeoff is worth it, but I 
haven't tried to do the GUI part yet, so maybe there's a surprise 
lurking in there :-)

Everything else ought to be relatively self-explanatory, except for the 
rotor stuff perhaps. The two speeds represent the motor angular rotation 
speed at 13V and 18V, and are used to calculate the rotor's approximate 
progress of rotation. Then there's the rotorpositions field, which as 
I've written it is optional. If you have a non-usals motor, and you 
don't set that field, then your configuration chains set the motor by 
stored location index as you would normally expect. In this case, we 
can't possibly provide rotation status information. However, if the user 
populates this field with a list of orbital positions for the stored 
locations, the configuration chains are then done by actual orbital 
location (just as for usals), and we are able to calculate rotational 
progress (assuming the lat/long is also set in the db)

That rotorpositions field actually represents a list of floats, but for 
the time being I decided just to represent it as a formatted string 
rather than another table. The format is "n1:n2:n3:n4:..." giving the 
configured orbital positions of indices 1-n. I don't have any kind of 
feeling for how common non-usals motors are out there, so maybe nobody 
cares about that, but it didn't cost much to add so I threw it in there.

Oh, as for the LNB types -- those are the gross categories of LNBs that 
I'm aware of, I'm sure there's others. Fixed has no control of polarity 
or bandselect (those legacy switches are typically used with those kind 
of LNBs, and the polarization is selected at the switch), the voltage 
control LNB is the most common in north america (where there is only one 
frequency band), and the voltage+tone LNB is basically a universal LNB 
where the tone controls the high/low frequency band.

Thanks all,

Yeasah

capturecard table
=================
   deprecate
       diseqc_type
   add
       diseqcnodeid    root node of connected diseqc devices (i.e. what 
is connected)

cardinput table
===============
   deprecate
       lnb_lof_switch
       lnb_lof_hi
       lnb_lof_lo
       diseqc_port
       diseqc_pos
   add
       diseqcid    id of diseqc configuration (i.e. how it should be 
configured)


diseqc table (new)
==================
   diseqcid        id of this configuration chain
   diseqcnodeid    id of a diseqc device
   diseqcvalue     configuration of this device (motor position or 
switch port)

diseqctree table (new)
======================
   diseqcnodeid    unique id of this node in the diseqc tree
   diseqcparent    id of parent (or NULL for root)
   diseqcport      port number of this node (if parent is switch)

   diseqctype      device type -- (switch, rotor or lnb)

   switchtype      switch type (for switches only)
   switchports     number of ports (for switches only)

   rotortype       rotor type (for rotors only)
   rotorhispeed    rotor speed at 18V (for rotors only)
   rotorlospeed    rotor speed at 13V (for rotors only)
   rotorpositions  array of orbital positions of stored positions (for 
non-usals rotors only)

   lnbtype         lnb type (for lnbs only)
   lnb_lof_switch    (as in cardinput)
   lnb_lof_hi
   lnb_lof_lo

switch types
============
SW21
SW42
SW64
Tone
DiSEqC 1.0
DiSEqC 1.1

rotor types
===========
DiSEqC 1.2
DiSEqC 1.3 (USALS/GotoX)

lnb types
=========
Fixed Polarization
Voltage-Selected Polarization
Voltage/Tone LNB