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
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
