On Monday 05 Sep 2005 08:04, Marian Durkovic wrote: > > Strange. Is the value of inversion always 0 in this case? > > Yes, every succesfull tuning has inversion=0 > > > @all: > > Why could the frontend require a transition from 1 to 0? > > Just two more observations: > > 1) When the standard driver code is used (no inversion changes during > retuning), after lost lock and unsuccessfull retuning the card gets > into state, that even the next normal full tuning takes long time - i.e. > the frontend is not able to tune at first attempt as usual (freq.offset=0, > inversion=0), but must cycle through complete zigzag and only tunes when > it returns to the freq.offset=0 and inversion transitions from 1 to 0. > > 2) The application must always use INVERSION AUTO, if retuning should > succeed. In other words, if you have INVERSION OFF in your .dvbrc > (or hardcoded in the application), retuning never happens. > > I have no idea why the transition from 1 to 0 helps, maybe changing of > inversion resets some other internal parameters of STV 299B and the problem > is in fact somewhere else (bad initialization settings or so). Actually, I noticed this yesterday on the site I'm having problems with (I'm testing with dvbtune). If I specify anything but INVERSION_AUTO, it doesn't tune. BUT: on all other sites, using exactly the same cards (13c2/000f), I do _not_ see this problem. I can tune if I specify either INVERSION_OFF or INVERSION_AUTO. Interestingly, the site with the problem has extremely high error rates (we're going to see if that can be fixed). All of the sites which do not have the problem have error rates (verror, blockerror, ucblocks) of 0. I don't have any stv099b errata information sorry. All these problems seem to be affecting only stv0299b based cards though.
