Re: Some thoughts and questions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux