[linux-dvb] More on the cx24123

Yeasah Pell yeasah at schwide.com
Sun Mar 19 19:02:07 CET 2006


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




More information about the linux-dvb mailing list