[linux-dvb] possible afatech af9005 bug
luca at ventoso.org
Wed Apr 25 18:38:14 CEST 2007
En/na P. van Gaans ha escrit:
> Luca Olivetti wrote:
>> En/na P. van Gaans ha escrit:
>>> Sorry, that doesn't seem to help, I don't see any difference at all.
>>> It doesn't seem to hurt either.
>> Not that I was really expecting it to help (after all it cannot report
>> an mpeg sync without a tps lock, or can it?), but it was the only
>> thing I could think of driver side.
> Sorry Luca, but my e-mail client automatically starts at the top of the
> message (Thunderbird)
oh, they must have changed the default recently (though I just created a
test account and it defaulted to "repky at bottom").
>, in any e-mail conversation with companies I
companies don't get the internet and don't get email (otherwise they
won't be using any microsoft software connecting to the internet at
large). Anyway it has nothing to do with dvb.
> receive top-posted replies (and they expect me to top-post back or else
> I risk not getting a response) and trust me it's really hard to remember
> to do a different posting style just for one person. I'm trying but it's
> so easy to forget. If bottom-posting were the "standard" I would use it
> by default but it simply isn't, at least not in e-mail. It's not
> intentional, I don't mean to annoy you but how can I remember?
Simple, read the message you're composing from top to bottom and see if
it makes sense. If you're top-posting it surely won't. Companies don't
usually make sense either, that's because they don't mind top posting,
or actually require it ;-)
> I gave "scan" a go and scan is a lot faster than Kaffeine. And good
> thing, more frequencies allow to be scanned, but still not all.
with or without the suggested modification?
> On the
> ones that don't work I get "(tuning failed)". But if the driver wouldn't
> be the problem I couldn't explain why the MSI scans (also in Kaffeine)
> without problems. So "scan" works better.. I'm not far enough into the
> technical stuff to explain this.
As I said earlier (and if I didn't I'm telling it now ;-)) I'm not a dvb
expert, but the driver is trying to report what the stick is telling, so
if the stick is reporting a lock when there isn't one I cannot do much.
Of course I could have misinterpreted the data sheet or didn't match
exactly what it's reporting to the linux dvb infrastructure.
The af9005 provides 3 bits:
- "agc lock" that I mapped to FE_HAS_SIGNAL
- "tps lock" that I mapped to FE_HAS_CARRIER
- "mpeg 2 lock signal" that I mapped to FE_HAS_LOCK, FE_HAS_SYNC,
"scan" only looks at FE_HAS_LOCK, and that correspond to "mpeg 2 lock
signal". With the modification I suggested I made it dependent also on
"tps lock". I think the driver cannot do much more (besides filtering
the signal, waiting for it to be stable for, e.g. 200ms, but I'm not
sure that's the correct thing to do)
There are also various bits that I ignored: "fractional frequency offset
estimator lock", "integer frequency offset estimator lock" and "sampling
clock offset lock".
What I'm asking now is if I got the mapping right, if not what should be
the correct one.
More information about the linux-dvb