[linux-dvb] CAM inserted/used reduces signal and SNR ?

[Luc Brosens]

Manu Abraham wrote:
> Luc Brosens wrote:
>> so I changed gnutv to only initialise the CAM after obtaining FE_HAS_LOCK
>> apparantly, initialising the CAM is enough to loose the tuning lock, not to return afterwards
>> so this is not a solution
>>
> 
> This won't help. The CPU on the CAM is running irrespective whether 
> you are trying to initialize it or not. In fact the CPU usage is much lower 
> at initialization time.
> 
>> here's a run with femon monitoring the tuning status :
>>
>> I start of with the CAM in the slot, and try to gnutv-tune to BBC World (which is not scrambled, so need for the CAM)
>> mythtv at silverstar:~/dvb-apps> femon -a 1 -H
>> FE: ST STV0299 DVB-S (DVBS)
>> status S     | signal  63% | snr  49% | ber 14077 | unc 0 |
>> status S     | signal  79% | snr  51% | ber 13311 | unc 0 |
>> status S     | signal  69% | snr  50% | ber 13776 | unc 0 |
>> status S     | signal  31% | snr  49% | ber 13116 | unc 0 |
>> status S     | signal  54% | snr  49% | ber 13085 | unc 0 |
>> status S     | signal  75% | snr  49% | ber 13509 | unc 0 |
>> status S     | signal  80% | snr  50% | ber 13017 | unc 0 |
>> status S     | signal  21% | snr  41% | ber 0 | unc 0 |
>>
>> no FE_HAS_LOCK achievable, both signal levels and snr are too low
>> so I pull out the CAM (and restart gnutv)
>> the lock is immediate :
>>
>> status SCVYL | signal  80% | snr  84% | ber 0 | unc 0 | FE_HAS_LOCK
>> status SCVYL | signal  79% | snr  84% | ber 0 | unc 0 | FE_HAS_LOCK
>> status SCVYL | signal  79% | snr  84% | ber 0 | unc 0 | FE_HAS_LOCK
>> status SCVYL | signal  78% | snr  84% | ber 0 | unc 0 | FE_HAS_LOCK
>>
>> signal is around 80%, snr a consistent 84%
>> I re-insert the CAM, which is detected by gnutv, and the CAM is initialised
>> tuning lock is lost at once :
>>
>> status S     | signal  62% | snr  50% | ber 13585 | unc 0 |
>> status S     | signal  31% | snr  49% | ber 13498 | unc 0 |
>> status S     | signal  82% | snr  49% | ber 13540 | unc 0 |
>> even though the signal level drops, it's probably the drop in snr that's causing trouble
>>
>> both cards have the same problem, so it doesn't appear that they're defective (or they both happen to have the same fault, which is unlikely)
>>
> 
> It looks to me that something is wrong with the frontend drivers (someplace) 
> which causes a phase distortions, alongwith that in that "tender" state the 
> digital noise from the CA module CPU's adds to it. The "tenderness" can be
> possibly attributed to a wrong device setup.
> 
> You might like to check with your windows installation whether you see the 
> same issue. Most likely, i guess not. If you see the same with windows 99% 
> chance is that that whatever you might do, digital noise is affecting your 
> demodulator and the tuner.
> 
>> question time :
>>> how much of a chance do I have of solving this if I somehow increase the signal strength ? would that increase the snr too ? (I could shorten the
>> cables, even if it means relocating the PC)
>>> without the CAM, I have a signal strength of 80%. Is that considered a good, strong signal ? (my settop box is happy with it)
>>> I asked in a previous post if it's possible to capture scrambled to disk, and descramble later. This is what my settop box does. Is this even
>> theoretically possible (sending data to the CAM from a file instead of from the tuner) ? Anybody know of  a utility that supports this ?
>>
>> and now I'm off installing W2K on the damn thing, to see if that works ...
>>
>> Luc
> 
> 
> Manu
> 
> 
Manu,

your guess is correct, under W2K no tuning problems. The scrambled channels tune in an instance, now and then there are some artifacts though. But
tuning works !

so my hardware setup works, now how to find that 'tenderness' in the driver ? You think that the tuning-part of the drivers (that would be the
STV0299-stuff wouldn't it ?)

if somebody can set me off in the right direction, I'll get it solved

the Windows TV-viewer that came with the cards reports a signal of 95%, even for scrambled channels : another indication that tuning could be done a
bit better ?

Luc