Hi, > Ideally when zigzag is employed, in the end result the offset should be zero or neglible. > In the case of the STB0899, IIRC it is rounded off. So in most cases, you don't have an > offset. Satellite transponders also tend to drift. Good operators will measure the exact drift and fix their NIT, but this isn't always done. Yes, ideally it would be zero, but in real world, it isn't. Userspace can read back the frequency, adjust their tables, but even that isn't perfect (if the LOF drifts with temperature, for example, the original center frequency might be closer to the current real frequency than the last compensated frequency). In really worse cases, you could drift into the next transponder. So I'd say that reading back the real frequency and using it for tuning should be avoided. Instead, the drift should be evaluated every time. Usually the drift can be fully compensated by the derotator, and in that case, it doesn't slow down tuning. Of course if you have a really big drift, something is wrong. > But even then you shouldn't be tuning to the entire bandwidth. But i guess then you are using Why not? We do our best to archive lock. The border line to avoid false positives (i.e. locking to neighbor channels) it the entire bandwidth. (or did I misunderstand you here?) > I just asked the question, since it affects other devices in an inverse way. > But this we cannot exactly say each device how it would respond to the same. > Some devices behave very bad. For a long time i tried disabling the swzigzag > for the dst, but then i had to come up with various hacks to get it going. Yes. We need a better control over the zigzack-process, and the possibility to disable it (and possibly handle it inside the demod driver). >> - Inversion might happen on up- and downconversion, depending on what >> frequency situation you have. >> - The SatelliteDeliverySystemDescriptor does not specify Inversion. > AFAICS, Inversion isn't a part of the transport. Why not? It's part of it like the frequency, isn't it? >> So you see, sometimes there is no way to know the Inversion setting. > When it is just a matter of wiring on the hardware/card, why not do it according > to the hardware rather than trying to do autodetection, by taking up more time ? > The point being, it is just a matter of detecting it one time, whether the specific > hardware has I/Q input swapped or not. I agree, the HW wiring should not be autodetected. But given the fact that its not possible to know whether the original, non-downconverted signal (as broadcasted by the satellite) has Inversion on or off (as it isn't specified in the NIT, for example), we don't know the end result. > Just because some hardware is capable of detecting the inversion, does it mean > that we need to emulate that same mode by doing it in software thereby making > tuning slow on the devices, that cannot do the AUTO mode ? Usually not, you are right (for example we don't try to autodetect symbolrate when the hardware is not capable of). But as said above, Inversion is a special case, because you don't know it. >>> At some point of time, i believed as well the fact that I/Q swap at the modulator (transmitter/satellite side) can cause an Inversion change. >> Not only that, it will also be swapped by a frequency inversion, which >> happens for example on a C-Band LNB (where the channel frequency is >> lower than the local oscillator). > Didn't think of that case. But in that case it would be a matter of the userspace > telling the driver whether it is negative or positive, ie INVERSION ON or OFF Yes, that's right. Felix _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
