On Friday 02 Sep 2005 21:16, Jon Burgess wrote: > Johannes Stezenbach wrote: > > I now need to figure out what the code in question was intended > > to do, and why it causes this problem... > > I believe what the code was inteded to do is as follows:- > > If the FE is incapable of doing INVERSION_AUTO and the user requests the > auto mode then the driver will flip the inversion every now and again to > attempt to get a lock. > > When the signal does lock, this particular piece of code overwrites the > auto mode setting with the currently active inversion setting. > Presumably on the assumption that you can only get a lock if the current > invserion mode is correct (and never goes back to auto mode unless asked > to retune by the user). > > Removing this code means the driver will keep trying to flip the > inversion setting whenever it loses lock. > > In principle the code looks OK to me, perhaps the problem is that for > some reason the FE indicates a lock when the wrong inversion has been > selected and can never recover. yeah, that was it exactly. It was to speed up subsequent retunes if the signal was lost since we already knew what the desired inversion setting was. Removing the code obviously means that it will always cycle through the inversions when lock is accidentally lost. I don't understand why that is necessary though - perhaps we have a bug in the frontend driver?
