I've been messing around more with the KWorld DVB-S 100 (cx24123
frontend) card I have here trying to get something tuned, and finally
had some succcess this weekend. Here's a list of things that I've found
so far:
1) The main problem that was preventing my tuning was that the software
zigzag was kicking in faster than the card could lock onto a frequency,
so it never got a lock. This seems to depend on the particular
transponder, presumably the hardware's search time varies depending on
how much FEC/inversion/etc searching it has to do. I've definitely seen
cases where the card won't acquire a lock unless you leave the frequency
alone for almost 100ms. I've temporarily gotten around this by changing
the dvb_override_tune_delay parameter to 100, but that obviously
increases the acquisition time if zigzag is required. I'm not 100% sure
what the correct solution is for this. I'd very much appreciate any
hints from anybody who has a better understanding of the zigzag stuff.
(I see that there are a couple of ways to override the zigzag behavior
from the driver, anyway, so that's good)
2) I corrected the lower frequency bandselect values. To help in doing
this, I added a module parameter 'force_band', which takes an integer
from 0-10, where 0 is normal behavior, and 1-10 forces the use of the
specified band select for ALL frequencies. In this way I was able to
determine some limits on the range of the bandselects (but only up to
1382MHz -- I don't have any signals higher than that)
For the lower bands, it really looks a lot like the first bandselect
should be 950-1075 (instead of 950-1019 -- i.e. the first band step is
skipped), and everything falls into place from there from the datasheet,
up to the limit that I have satellite frequencies for (only up to band 5
unfortunately). There is of course a lot of overlap of the bands, but
the range of the bands (on my hardware) go surprisingly high (i.e. band
1 can go at least up to 1178MHz reliably), so I wouldn't be at all
surprised if the pattern continued and band 10 could be eliminated, and
perhaps just shifting all the bands up by 1 band would work well (it
works for the lower 5 bands anyway)
3) I noticed that the register initialization list was a little unclean
-- some read-only status bits being set (indicating that the register
table may at least be partially from an i2c sniffer), so I cleaned that
up and added some comments for the registers telling what they are
setting. Also, on an extremely minor point, two of the FILTUNE voltage
values were off by 1 according to my math (though the end result in
voltage will be certainly lost in the forest of power supply regulation,
ripple, noise, etc.)
4) The way that setting the FEC was handled wasn't quite right in my
mind -- when you set a specific value the driver left it in auto mode,
with some arbitrary primary FEC mode and narrowed the secondary search
table to only search that specific value. I changed that so that any
mode but AUTO turns off search entirely and sets the primary mode, which
I think is what you'd expect as a user. Also, does anybody know for sure
if this chip supports 4/5 or 6/7 FEC coding? I can't see where the
datasheet rules that out, and if the card is capable of it, it should
advertise it in the caps (I have no idea if these FEC rates are even
used in reality)
5) The demodulator sample gain wasn't being set at all. I've added some
code to set that using a pretty cheesy approximation of the
log2(sample_rate / symbol_rate) equation, but I think it's probably
close enough. The only time it really gets set to any meaningfully high
value is for the low symbol rates (it can go up to 20 or so, whereas
it's usually 1-2 for the higher symbol rates) -- which brings me to a
theory (that I haven't made any attempt to verify yet) -- possibly the
low symbol rate VGA offsets are actually correct in the spec, but the
low symbol rate problem was actually caused by the lack of setting the
sample gain (but was worked around by changing the VGA offsets)
6) The tuner control bits are specified in several places as (0 << 18),
(2 << 18), (4 << 18), etc. instead of (0 << 19), (1 << 19), (2 <<19) --
it's the same value, but the former makes no sense semantically, since
the control bits are 2 bits starting at bit 19, not 3 bits starting at
bit 18. That caused me a little confusion at first.
Things I haven't changed, but I'm curious about:
7) Would I be correct in assuming that the phase rotator frequency stuff
in registers 0x0c and 0x0d determine how the chip does some kind of
hardware frequency scan (similar to the software zigzag)? It doesn't
seem to work if so (i.e. if I turn off swzigzag and try to tune to a
slightly detuned frequency, it never acquires), but maybe that's because
it isn't configured right (i.e. the nominal phase rotator frequency is
never set to anything but the default of 0, though the search range
select default seems reasonable -- you probably don't want to search
much further than (symbol_rate / 4) or you'll risk running into the next
frequency) I notice that the datasheet lacks an explanation of the
nominal frequency value, but it does have a status register that reports
the current frequency value in the same units (including the weird
disjoint MSB packing), so that might not be so hard to determine
experimentally.
-Yeasah
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
