> The sources.conf file could include an additional field that > references switching/positioning information... But... the > problem is that it's easy to make assumptions about topology > that don't necessarily hold. > > Most people imagine a rotor, a switch, and multiple LNB's in > that order. > > Now imagine that you had a dual LNB on a dish, with a rotor > ... in fact several such dish/rotor pairs... and a multiswitch... > You'd have to select your dish/rotor pair first, drive it into > position, choose your polarity, and then tune your LNB last. > > Versus having a fixed dish with a switch and multiple LNB's > (which you'd do if you had a narrow arc and a toroidal dish). Hmm I see; I can see my 'P' command suggestion maybe isn't sophisticated enough for this. Perhaps we need to rethink the diseqc.conf completely. Instead of simply specifying the diseqc commands, it could specify the steps needed to tune a channel on a particular source... so you do something like: setswitch(1), setswitch(2), rotate(), setvoltage(), setpolarization(), setfrequency() So it controls all steps in the positioning/tuning process, not just diseqc. Although, this does add a lot more complication. How common are these multi-dish/switch/positioner setups BTW? If they're rare, maybe we'd be better off keeping diseqc.conf simple for the "easy" cases, but export the functions above in the perl API; then people can write tuning apps for the complex setups in their favourite scripting lanaguge, and exploit the full power of that instead of us trying to write our own mini-language. I like the idea of moving away from the raw hex diseqc commands. > Here in North America, we have relatively few satellites, spaced > apart, with relatively sparse content (unless you have C-band). > > In Europe, it's a small arc... small enough that sometimes you can > even fit all of your satellites into the cone of a single fixed toroidal > dish... and all you need to do is to select the LNB pointing at the > appropriate satellite with the switch. > > Don't know what the case would be for South Asia, the former > Russian Republics, or central Russia or Siberia... Much less how > things are in the southern hemisphere. > > The interesting thing about the sources.conf file, is that you can > almost parse it into enough information to prime a USALS > positioner (assuming the user can somehow figure out his > long/lat). > > I've taken the sources for one of the many online Javascript > calculators for doing satellite positions and converted it into C. > > Assuming that your rotor supports "Goto angle(x)"... which is > part of the Diseqc 1.2 spec... and most are... then we could drive > the dish to a little bit east or a little bit west of the satellite, tune > to the beacon frequency, and drive it in small increments (while > waiting a few seconds for a lock), swing past the falling edge of > the lock, and remember how many steps past the initial position > we went to see the peak signal. Yup, I see. But I assume some do not support that? argh :) > >Hmm, will think about the merging idea; I think the main reason it isn't > > in the same file is because I got the idea originally from VDR which has > > a separate sources.conf. People might say they want to have seperate > > files for each transmission system; but theres nothing stopping them - > > the libdvbcfg library would support either method of doing things. > > Minor nit: why is there 'T' for Europe and 'A' for North America? > > As people in North America aren't likely to have DVB-T cards (and > vice versa), we could make it mean the 'broadcast', and just leave the > interpretation as "a local matter" (as the CCITT likes to put it). > > Of course, if laptops with builtin tuners and the back of the screen > being a VSAT antenna start appearing... and roaming the planet... > then this might cause confusion. But that doesn't seem too likely. :) It was because thats what the DVB API has, and as I know little about ATSC, I just maintained the convention... I don't like using "broadcast" though - that could also describe DVBS. However, ATSC appears to be a direct equivalent to DVBT in the EU, so perhaps 'T' for terrestrial is most appropriate instead of 'A'? > >>>>Lastly, the configuration files could be more flexible, and more > >>>>human readable. Embedding "7" for the FEC rather than "7/8" > >>>>is less clear than it could be, and risks breaking should the enum > >>>>values change in a future release of the kernel. > >>> > >>>Which configuration format were you looking at? The libdvbcfg > >>>multiplex.conf ones use either '7' or FEC_7_8, depending on what the > >>>application wants (the first is for machine-readable-only files on STBs > >>>with limited space, the second is for human edited files). I was asked > >>> to add the "brief" format by STB manufacturers concerned about the > >>> space used by the new file formats. > >> > >>I really don't think that 40-100 bytes is going to break an STB (and yes, > >>I've worked making STB's). Having config files that are easy to create > >>and verify make it easier for resellers/carriers/installers to tailor to > >>their > >>users... > > > >Hmm, its more than than 40-100; maybe 40-100 per multiplex, but if you > > have a lot of multiplexes it would add up. I don't actually need this > > saving myself, but I added it because there was a demand for it from > > several people. The library is switchable between both formats at > > runtime, so I felt it was best to leave it up to the users of the lib > > what they choose to do. > > How many multiplexes are we talking? Hmm, actually not that many; e.g. hotbird 19.2E has about 90ish that I can detect here. Perhaps the brevity isn't necessary for the actual frontend parameters. However, at the same time I also shortened other things - in those 90 multiplexes, there are 1716 individual services, and I made the service definitions more compact, so perhaps thats all that was really needed. DVBS multiplexes don't actually have that much data - e.g.: "12345 INVERSION_OFF H 27500000 FEC_AUTO" DVBT is the biggie: "12345 INVERSION_OFF BANDWIDTH_8_MHZ FEC_2_3 FEC_NONE QAM_64 TRANSMISSION_MODE_2K GUARD_INTERVAL_1_32 HIERARCHY_NONE" But generally there are only a few DVBT multiplexes. Perhaps we can simply drop the minimal tuning parameters format? Obviously keep the rest of the minimalisation I did, but thats not in question really as only the tuning parameters format has the issue you brought up. > >>>>All of the satellite information, position, positioning info for a > >>>>rotor or toroidal dish (i.e. which switch input, what stored position, > >>>>or what angular azimuth and elevation for a 1- or 2-axis position), > >>>>the frequencies, transponder numbers, beacon frequencies, sids, > >>>>aids, pids, vids, encoding and encryption methods, etc. should all > >>>>go into a single configuration file (but a structured, heirarchical > >>>> one). > >>> > >>>Most of that already is in the libdvbcfg multiplexes.conf file. I > >>> decided that keeping diseqc.conf, adapters.conf, and sources.conf > >>> seperate was better from my POV, since I want to share some data (i.e. > >>>multiplexes.conf), but keep other, machine specific data in seperate > >>>files. > >> > >>Is there a man page that discusses these file formats? I was looking at > >>test/test_multiplex*.txt > >>but couldn't figure out much just from looking at the same data... > > > >It should all be documented in the libdvbcfg header files. > > Let me stare at it some... > > One issue is how to handle the case of a multimode adapter in the > adapter_backend.conf file: > > DVBS1.0 ... > DVBT1.0 T-uk-Reading > DVBC1.0 > > I'm also thinking that the "C" field should include the standardized name > of the service offering for the locale... i.e. something like: > > C-us-ca-SF-TCI-premium_digital > > for example. That way, if there's ever a standardized way to pull down > service "bouquets" for a given market (since it's again not a user-specific > bit of information, but is "regional") from a server, then we'd have a > fixed naming convention. Someone else actually had an idea for that. It was to define a presets file format (which I haven't done yet BTW). It would consist of GSIDs, human readable channel descriptions, and some form of channel grouping. On tuning, the GSIDs would the be looked up in the multiplex.conf file to determine the exact tuning parameters. One use of this presets file was to provide bouquet information - and the idea was you would be able to download them from a central source. I think you could even define multiple GSIDs for any one 'channel' - so if the same channel was transmitted on multiple networks, an app could easily identify which networks you have access to and hence 'hide' channels you could not receive at all. > The backend file should only contain the "portable" information... and > maybe a specific Id for looking for the diseqc string elsewhere... Or we > could use the <source_id> as the key in that file... > > Seems to me that enabling high voltage isn't something you do on > some source_id's and not others. You do it on all of them or none of them. Yeah you're right. > As for the contents of the diseqc.conf file... Sigh. I don't think it > should > contain "raw" diseqc commands... I'd prefer to see it be in symbolic > format... like "goto_angle(-16.2) switch(C) ..." or "goto_pos#(5) > switch(B)". > > Let the logic that handles the "goto_angle()" or "goto_pos#()" deal with > delays, error management, etc. Otherwise, you risk (1) people entering the > wrong hex codes, and (2) a lot of duplication of repetative sequences like > "W15"... > > Can you walk me through the multiplex_backend file? And how much of > it is globally true, and how much of it (such as the CA stuff) is per-user? Not sure what you want to know - heres a basic description, just ask more if I've not explained anything properly. Its hiererarchical - basically you have an [m] entry defining the ID and tuning parameters for a multiplex, followed by multiple [s] entries defining properties for the services attached to that multiplex. [s] entries belong to the immeidately preceding [m] entry. As for how much is globally true - all of it is AFAIK. The CA stuff is not actually user specific - those are extracted directly from the DVB transmission itself. Those CA IDs are basically the transmission telling you what CA hardware you would need to decode that channel. > Not sure I understand the seed_backend.conf file either... Its basically to provide the same thing as the files in dvb-apps/util/szap/channels-conf/*/* but in the new encoding format. Just a simple list of tuning parameters for scanning. Actually now I come to think of it, that format isn't really necessary - you could just have a multiplex.conf with with those entries and no service definitions.
