Andrew de Quincey wrote: >>>Johannes wanted not to have any malloc/freeing in that SI parser, since it >>>will be used to handle very high data rates. I agree malloc/free elsewhere >>>is ok; I use it myself in the dvbcfg libs, where it happens infrequently. >>> >>> >>Well, you could have a pointer to a buffer allocation strategy that the >>user could override. I guess I don't know enough about SI parsing to know >>why one would have to create a lot of buffers on the fly. >> >>Feel free to set me straight. ;-) >> >> > >I think he wanted to have it so it would do the minimum possible amount of >copying/work on the SI data for highspeed datastreams. In the libsi2, it >basically processes the received data in place. What I do doesn't actually >need this efficiency, but the library already had it. Johannes would be the >best person to ask for more info on this. > > Well, if he's reading this thread, he might chime in... >>>>A while back, I sent some comments about how the libraries work, >>>>and what might be done to improve them. >>>> >>>>For instance, having applications ask for a type of adapter, and >>>>having the system probe for all available (unused) adapters, detect >>>>their type, and returning the matching kind. Why? Imagine the >>>>following: you've got a tri-mode tuner card, and it's connected >>>>to a Spaun Diseqc NxM switch... The source can be chosen >>>>dynamically from off-the-air, cable, or satellite, and the front-end >>>>can be dynamically selected to be DVB-T/ATSC, QAM256, or >>>>8QPSK. Do you really want to burden the application with that >>>>logic? And do you want to have each application handle that >>>>configuration state differently? >>>> >>>> >>>This is what the combination of all the dvbcfg file formats does (well I >>>think; but I may be missing an important point - tell me if so!). I simply >>>haven't had the time to write the support yet. libdvb2 would have a high >>>level tune() function simply taking a GSID which works as follows: >>> >>>1) The GSID is parsed into source_id, UMID and USID. >>>2) It locates a free adapter in adapters.conf which supports that >>>source_id. 3) The DISEQC command string is looked up in diseqc.conf for >>>that source_id and sent to the switch. >>> >>> >>It might be a switch/positioner issue. Further, what happens if you >>have multiple >>steerable dishes or a toroidal dish with multiple LNB's? You might want >>to see if >>one of the LNB's is already locked up to the appropriate position and >>polarity... >> >>That would avoid using up resources unnecessarily (but then you'd also >>have to >>manage locking, so that the first process couldn't decide to move the >>dish or >>change the polarity now that it's being "shared"... so some sort of >>semaphores >>might be required). >> >> > >These are all good points. They need serious research, planning and thought. > > Unfortunately, we have mixed traffic on this list... Mostly usage (or -users) questions... not a lot of development (-devel) chatter. I've mentioned splitting the list in two to facilitate a more "condensed" forum to discuss development, but there's been limited (read: little) enthusiasm for that idea. Sigh. >>>4) Next, it looks up tuning information for the multiplex in >>>multiplex.conf using the UMID, and tunes the card. >>>5) Finally, it looks up the channel information in multiplex.conf using >>>the GSID and sets up the PID filters. >>> >>>Is this what you mean? Or am I missing a usage case. Bear in mind all the >>>DVB hardware I have access to is single mode only, wired to pretty dumb >>>switches; I'm happy to add support/include patches for more complex >>>things though... >>> >>> >>Hmmm.... this is a recurring theme... Most of the development is done >>by people >>with limited means to test more complicated set-ups... >> >> > >Unfortunately yeah. Although I do some of this work for my company, we don't >require any more complex setup. I suppose this is what you get with people >doing it in their spare time with little or no manufacturer support :( > > Well, I can usually justify purchasing equipment and "evaluating" it on the test bench, but... I'm no guru when it comes to troubleshooting (I'm actually a protocol hack for middleware stacks). >>>I'd want to keep the more primitive API as well, since different uses have >>>different requirements. >>> >>> >>Sure. Low-level diagnostics and scripting tools should have low-level >>access. >> >>Maybe even adding .xs stubs for Perl scripting. >> >> > >Now that is a good idea; now we are getting some kind of library, other >language bindings would be cool. I can imagine there could be lots of >interesting things if we have perl and python bindings... > > I could do the Perl bindings. That's trivial. >>>>I also think that we could do a better job abstracting the various >>>>kinds of Diseqc support that applications use... whether one is >>>>using a toroidal dish with a switch or a single LNB with a rotor, >>>>this sort of detail should be contained in the configuration, but >>>>abstracted away from the application. >>>> >>>> >>>Do you mean something beyond the libdvbcfg diseqc.conf file format? I was >>>attempting to make that a way to specify that sort of thing.. do you have >>>ideas for extending it/a better implementation? >>> >>> >>Yes. I propose using nesting... having a hierarchy of >>satellite/transponder/frequency/ >>streams... >> >>I also think that simple Diseqc strings to manipulate a switch aren't >>sufficient... and >>that this isn't the place to put them. >> >>A satellite's information isn't site-specific: the position, angle, >>frequencies, transponder >>ids, etc. are invariant WRT the user. (In fact, the CVS could have a >>single monolithic >>file that the user then extracts the useful lines from...) >> >> > >So we basically need another config file to describe the invariant technical >details for each transmission system (I dont want to call it "satellite" >since we need to support all systems). Could the "sources.conf" file be >expanded to contain this? Currently it just contains an ID and a human >readable description. I was envisaging the sources.conf to be a file held on >a wellknown system (e.g. linuxtv.org) that applications downloaded when it >was updated, much as you suggest. > > 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). 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. >We _almost_ have that hierarchy; simply that the sources information is stored >in a separate file (sources.conf) from the multiplexes (multiplex.conf)... >You're effectively suggesting merging these two? > > Maybe. I'm just pointing out, mostly, that it's easy to assume that everyone has the same (traditional) configuration. If you have a condominium building, multiple dish/rotor/LNB pairs with a switch, and a "server" with multiple tuner cards in it.. streaming DVB-S to IP-enabled set-top boxes over the building's ethernet wiring... then one can imagine more complex topologies than the monoblock LNB, fixed dish, and the single tuner card. >In that case, I'm not sure I entirely agree the frequencies are totally >identical; depending on the card/dish/cables/hardware etc you do get some >variation... e.g. reading the actual frequency the card reported locked it >locked to back and saving it out again in order to accelerate lock times. But >I suppose it would just be a matter of a localised version of the file, >autoupdated by the application. > > Sure. You could use the initial data for "priming", and the record drift... Either a global drive value, or per-frequency (or per transponder, etc). >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. >>On the other hand, the user's hardware configuration is extremely site >>specific by >>definition. So information about manipulating voltages, tones, input >>ids, rotor angles, >>rotor presets, etc. should all go into a separate file. >> >> > >To me, this sounds almost exactly like the diseqc.conf file. I know the IDs >that are currently used to key the information contain the orbital position >of the sat, but they could be anything really; the orbital position was >simply a good way to unqiuely identify each sat cluster since there didn't >seem to be another system. The IDs were meant to be opaque - even though they >might contain something like "S-13E", it could very well have been >"S-Hotbird156". > > Hmmm... Perhaps the sources.conf file could reference a tag (aka "anchor", label, whatever) that is external to the file... and then the contents of that tag could be given in the diseqc.conf file... >>>>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? >>>>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. 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. 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 I understand the seed_backend.conf file either... >>>>Priming and editting that file should be done by the dvb-apps package, >>>>not by applications. >>>> >>>>Applications should be patched to use a higher level abstraction of >>>>the libraries (and indeed, developping these patches and re-verifying >>>>that the applications continue to work would be a reasonable way to >>>>confirm that the libraries are correct and functionally adequate). >>>> >>>> >>>I agree. However my current priority is to get these libraries working for >>>my uses. The existing apps are working as they are currently; but if >>>someone else wants to patch them... >>> >>> >>I'm confused. Won't your changes break compatibility with the existing >>applications? >> >>If so then you'll need to patch, at a minimum, the applications that you >>use... unless >>you use only in-house applications... >> >> > >Yeah, thats it exactly: I only use in-house applications. > > Ah. Ding. Lightbulb. >>>Can you explain how rotor dishes are commanded? I have no experience of >>>them whatsoever. Would the current diseqc.conf format suffice? or could >>>it be better? >>> >>> >>Depends on the type of positioner... Some move in a single axis, some >>move in two >>axes... >> >>Some will give you status information as they move (since various >>conditions such >>as dish weight, snow load, wind, angle, etc. can affect their stepping >>speed). Others >>won't. >> >>Have a look at: >> >>http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/position_ap >>p_note_v1.pdf >> >>BTW: Some positioners will also turn a directional antenna to point the >>antenna >>for optimal signal strength and front/back discrimination on terrestrial >>antennas. >>They are programmed in a similar fashion. >> >> > >Cool, I shall have a read. > >Hmm, dishes that send DISEQC data back are not going to work that well - AFAIK >we only have one supported card that might possibly support that, and no one >AFAIK has actually tested if it actually works (I added the code just in >case, but have no DISEQC 2.0 hardware). Its the new s5h1420 DVBS card if >you're interested. > > I believe that most of the DST Twinhan/Chaintech/Visionplus clones will also handle responses... alas the DST driver doesn't support the FE_DISEQC_RECV_SLAVE_REPLY ioctl(). I've brought this up with Manu. Waiting to hear this thoughts on it. I'll go stare at the various file formats some more... -Philip
