Felix Domke wrote: > 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. > True > 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. > I am not stating that zigzag is evil, but making a STV0299 specific zigzag for other devices is evil, since it can never be made generic for a wide range of hardware, While all the demodulators work perfectly fine. > Of course if you have a really big drift, something is wrong. > True >> 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?) > If we try to tune to the entire bandwidth in one shot, the centering wouldn't be correct. I just happen to do it in 3Mhz steps. A deviation from a 10 MHz step to a 3Mhz yielded in sufficiently large positive results. Regarding the time taken to tune. >> 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). Exactly. That is exactly what i do. I don't allow the zig-zag in dvb_frontend.c, but use the zigzag for the driver specific way, eventhough the zig-zag, what i do is in a STV0299 compatible method, There IS something wrong in the zig-zag in dvb_frontend.c as it resulted in bad tuning for me, when i initially took a go at the STB0899 http://jusst.de/hg/multiproto/file/557067efd932/linux/drivers/media/dvb/frontends/stb0899_algo.c What i do for the STB0899 is that in the frontend thread, i use a new callback called search rather than using set_frontend to define the zigzag in a more accurate way inside the STB0899 driver rather than using the one from dvb_frontend.c This is what i do in there. 295/* 296 * stb0899_search_carrier 297 * Search for a QPSK carrier with the derotator 298 */ 299static enum stb0899_status stb0899_search_carrier(struct stb0899_state *state) 300{ 301 struct stb0899_internal *internal = &state->internal; 302 303 short int derot_freq = 0, last_derot_freq = 0, derot_limit, next_loop = 3; 304 int index = 0; 305 u8 cfr[2]; 306 u8 reg; 307 308 internal->status = NOCARRIER; 309 derot_limit = (internal->sub_range / 2L) / internal->mclk; 310 derot_freq = internal->derot_freq; 311 312 reg = stb0899_read_reg(state, STB0899_CFD); 313 STB0899_SETFIELD_VAL(CFD_ON, reg, 1); 314 stb0899_write_reg(state, STB0899_CFD, reg); 315 316 do { 317 dprintk(state->verbose, FE_DEBUG, 1, "Derot Freq=%d, mclk=%d", derot_freq, internal->mclk); 318 if (stb0899_check_carrier(state) == NOCARRIER) { 319 index++; 320 last_derot_freq = derot_freq; 321 derot_freq += index * internal->direction * internal->derot_step; /* next zig zag derotator position */ 322 323 if(ABS(derot_freq) > derot_limit) 324 next_loop--; 325 326 if (next_loop) { 327 reg = stb0899_read_reg(state, STB0899_CFD); 328 STB0899_SETFIELD_VAL(CFD_ON, reg, 1); 329 stb0899_write_reg(state, STB0899_CFD, reg); 330 331 STB0899_SETFIELD_VAL(CFRM, cfr[0], MSB(state->config->inversion * derot_freq)); 332 STB0899_SETFIELD_VAL(CFRL, cfr[1], LSB(state->config->inversion * derot_freq)); 333 stb0899_write_regs(state, STB0899_CFRM, cfr, 2); /* derotator frequency */ 334 } 335 } 336 337 internal->direction = -internal->direction; /* Change zigzag direction */ 338 } while ((internal->status != CARRIEROK) && next_loop); >>> - 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? What i meant is that it does not depend on the transport, but the hardware. LNB + tuner <-> demod wiring Whereas frequency is not. >>> 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. The transmission from the satellite shouldn't matter, is it not ? With the case of the LNB, It matters when the Flo > Frf I/Q inputs come into the picture after the 90 degree Phase shifter, is it not ? Exception is the LNB mixer. Or something else i am missing in there ? >> 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. how come ? Am i missing something ? 1) config struct for all hardware defines it. 2) LNB, Flo > Frf >>>> 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 > Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
