On Thursday 29 July 2004 22:45, Andreas Share wrote:
Comments are welcome
here we go ;-)
Note: The frequence ranges dependent charge pump current value are based on
an Philips comparison measurement between sp5659 and tsa5059, hopefully
this values are correct;)
- raising up the
Hermann Gausterer wrote:
maybe somebody can mail me the datasheet for the ves1893?
google for
Philips_VES1993_Single_Chip_Satellite_Channel_Receiver.pdf
Jrg
On Thursday 29 July 2004 23:18, Andreas Share wrote:
there is some thing missing in the patch ...in sp5659_set_tv_freq() is a
u8 pwr = 0; needed.
2.6.7 with hand applied ves1x93_cpc.V2.diff does not compile ...
you remove the last parameter from sp5659_set_tv_freq
and in function
On Thursday 29 July 2004 22:45, Andreas Share wrote:
Comments are welcome
here we go ;-)
Note: The frequence ranges dependent charge pump current value are based
on
an Philips comparison measurement between sp5659 and tsa5059, hopefully
this values are correct;)
- raising up
Andreas Share wrote:
Btw: Rev 1.3 cards have some problem with one of the 5V line in newer,
faster pcs. this cause unrealiable lock an jumping str snr values.
There exist an hardware mod to around this problem, using down regulated 5V
from the 12V line. This eliminates this problems.
Please take
Andreas Share wrote:
Btw: Rev 1.3 cards have some problem with one of the 5V line in newer,
faster pcs. this cause unrealiable lock an jumping str snr values.
There exist an hardware mod to around this problem, using down regulated 5V
from the 12V line. This eliminates this problems.
I have
On Friday 30 July 2004 20:51, Andreas Share wrote:
Maybe the lock will get lost for a moment, this could caused by the afc
funktion from the ves1893. So we must give it the nessasary time to get a
reliable lock.
the problem is that it happens long after a tuning, so a additional timeout
does
Btw: Rev 1.3 cards have some problem with one of the 5V line in newer,
faster pcs. this cause unrealiable lock an jumping str snr values.
There exist an hardware mod to around this problem, using down regulated
5V
from the 12V line. This eliminates this problems.
that sounds very
Hermann Gausterer wrote:
Please take a look to my last message and the attached stuff.
Since I switched back to the bsrv2 frontend driver with my 1.3-cards
havn'd had any brocken recording. I ran at least 20 cold boot recordings
and 50 recordings on the fly.
what kernel are you using now? i read
On Friday 30 July 2004 22:07, Alfred Zastrow wrote:
I'm using dvb-kernel with linux 2.4.26.
oh thats heavy .. have never tried this combination ...
Copy the bsrv2.c to the other frontend drivers, excange the frontend.h
and the Makefiles (one in the frontend driver directory and the other
one
On Friday 30 July 2004 21:19, Joerg Riechardt wrote:
I have done this mod on my two 1.3 cards, but the UPT etc. still exists.
Jrg
what exactly have you done with your card? was there any change in the
behavior after this?
hermann
On Friday 30 July 2004 21:31, Andreas Share wrote:
BTW: Here is the bit shifting corrected correction;) Sorry
version 3 of the patch is even better .. the apperience of status
changes is now very decreased and only happens ~ all 10
seconds .. a big step forward for me :-)
hermann
Hi,
here are some patch against the current ves1x93.c dvb-kernel code.
The patch do following:
- .frequency_stepsize is set to (the correct) 125 (kHz), because both
pll´s
using a clock comparision frequency of 125 kHz.
- correct the pwr shifting in sp5659_set_tv_freq() from 5 to 6,
13 matches
Mail list logo
