On Tue, 29 Jun 2004, Nathan Hand wrote: > > If the frontend (not the driver!) is smart enough to correct wrong > > parameters, why shouldn't it do so? IMHO what counts for most people > > is that they can watch TV ;-) > > I thought my point was clear, but I will try again. > > The problem is when the frontend corrects the values and GETS IT WRONG.
The patch that I proposed about 16 hours ago turns off all automatic parameter searching when one explicitly specifies all parameters which, I believe, is what you are after. It should work for the most case where one know parameters, but still lets one set FEC_AUTO, etc, when they don't know what's going on. > Imagine if write(2) corrected your spelling. It's a horrible idea. Providing that you have the guard interval and transmission mode set right, ETSI 300 744 suggests that you should be able to use the TPS information - and, it is error-corrected OTA too, so should be "as the broadcaster intended". If the broadcaster is sending the wrong values for these, I would expect many more problems to emerge with everyone's STB's, etc, that do use these parameters. That should mean it will get fixed rather quickly if it is ever set incorrectly - have you seen cases where the broadcaster is sending the wrong thing? So, whilst write(2) can't reliably correct your spelling, and shouldn't try to, the mt352 frontend/demodulator IC *is* in a position to make a decision should things change. It has the distinct advantage that it is being told repetitively by the broadcaster what the right "spelling" is, in the TPS information. Where the MT352 goes beyond the standard is that it provides functionality beyond that in the spec to let it quickly try different guard and mode settings to let it acquire the TPS information in the first place. (The device driver isn't necessarily privy to this information and (I agree with Johannes) should generally stay out of it beyond directing the frontend hardware to do its thing. That the driver shouldn't itself do a search for parameters is easily demonstrated by supposing the extreme case, where the broadcaster switches back and forth between two FEC settings every few superframes. There is no way that the driver could expect to keep up, whereas the frontend hardware can track it without loss of lock, as it's told in the TPS information what the new settings will be and the exact moment the change should take place.) Chris -- Christopher Pascoe IT Infrastructure Manager School of Information Technology and Electrical Engineering The University of Queensland Brisbane QLD 4072 Australia Web: http://www.itee.uq.edu.au/~chrisp
