Hello mailinglist, unfortunately my last posting was not readable, because my email client produced something in html format with white characters on white background :-o. Sorry for that. This time it's text format.
Today I found the new release 0.2.3 of the libdvb on http://www.metzlerbros.de/mbros/dvb/. A diff to to the 0.2.2 release showed the bugfix I proposed. Thanks to Marcus Metzler. Sven Severus ============================================= > Hello newsgroup, > > I am not sure, but I think I found a bug in libdvb (0.2.2). > > Frank Verlinden reported the following problem in a posting dated 3 Mar 2003 > (http://www.linuxtv.org/mailinglists/linux-dvb/2003/03-2003/msg00009.html): > > After loading the Convergence or the Metzler DVB drivers the n-tv screen > > is showed. When starting Tuxzap and trying to switch to an FTA channel > > the screen becomes blank. With the Convergence driver, it is still > > possible to switch with szap. > I had the same problem, but unfortunalety Frank did not continue the thread, > so I tried to find out the reason and a solution by myself. Let me now report > my results: > > In source DVB.cc is a function set_diseqc_nb. Its purpose is to > assign proper values to the six bytes and the length attribute of > the struct dcmd, used as parameter for the frontend API function > FE_DISEQC_SEND_MASTER_CMD later on. > Here is a part of the C code: ------------------------------ > dcmd.msg[3]=0xF0 | > ((nr * 4) & 0x0F) | > (tone ? 1 : 0) | > (voltage ? 2 : 0); > ------------------------------------------------------------------------ > > According to the DiSEqC specification bus_spec.pdf (found at > http://www.eutelsat.com/satellites/4_4_5.html), chapter 8.3 > "Command Byte" and chapter 9.1 "Write Port Group", and > slave_microcontroller_spec.pdf, chapter 7.2 "Committed > Control Pins", dcmd.msg[3] is the data byte in the > "Write N0" command (hex code 0x38, "write to port group 0 > (committed switches)"). > The meaning of the least significant bit in this data byte is: > 1 <=> "High L.O. frequency selected". > > Now lets look at what happens if tuxzap switches to a transponder > in the high band area: > In function DVB::SetTP tone is properly set to SEC_TONE_ON, > but unfortunately the enum type of tone is: > ------ linux/dvb/frontend.h --------------------------------- > typedef enum fe_sec_tone_mode { > SEC_TONE_ON, > SEC_TONE_OFF > } fe_sec_tone_mode_t; > --------------------------------------------------------------------- > (see also "Linux DB API Version 3", V1.0.0 pre1, > chapter 2.1.7 "SEC continuous tone") > That means, that "tone" has _zero_ value and "(tone : 1 : 0)" > evaluates to 0, resulting in the least significant bit in > dcmd.msg[3] NOT set in this case. > This is a contradiction to the eutelsat specs. > > I patched the expression to: ((tone == SEC_TONE_ON) ? 1 : 0), > and a very similar piece of code in function set_diseq the same > way. This is much more robust coding, and it worked properly. > > ============================================= > > Is this a bug? > I am doubtfull, because only one posting reported this problem. > I would highly appreciate a statement of Marcus Metzler. > > Thanks in advance for any answer. > > Best regards, > Sven Severus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
