* cut down some I/O operations by disabling "disable gate"
* budget_av was left with the gate open, thereby more susceptible
to RF interference due to I/O operations
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Marco Schluessler <marco@lordzodiac.de> for pointing it out
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* Better readability
* Avoids duplication
Comments from Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Bug: a string which contains 4 digits needs an array
of size 5. The fifth character will hold the terminating '\0'
Signed-off-by: Reinhard Nissl <rnissl@gmx.de>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Optimization: Round the requested value to achieve a
+/-1MHz error instead of +0/-2MHz
Signed-off-by: Reinhard Nissl <rnissl@gmx.de>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Bug #1: The 5 tap equaliser is set to correct simple perturbations
like reflections on the IF cable for DVB-S. In the case of DVB-S2
a more powerful equalizer is used to correct the filter group delay
allowing the bandwidth to be reduced by a factor of 1/3
Bug #2: The ZIF tuner takes badwidth to be set in Hz
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Note:
* At High Symbol Rates we do not have enouph machine cycles to handle the
incoming symbols and hence might run into problems at the very end of the
specified definition
* Most of the equations have been calculated for a master clock of 99 MHz,
running at 90MHz, raises lot of issues such as the need to recalculate
all of them , which is eventually very painful.
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to Marko Schluessler <marco@lordzodiac.de> for pointing it out
Signed-off-by: Marko Schluessler <marco@lordzodiac.de>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Bug was found by Arvo Jarve <arvo@softshark.ee>
It was a wonder how it worked in the case with this bug,
STM verified this that this nibble was in fact insignificant
and can be ignored.
But still we need to fix all inconsistencies.
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In this case, we will be sure that there exists a carrier
and the center frequency would be simply f1 - f2. In such
a circumstance, the TR loop is simplified to doing a simple
check for timing, rather than searching for the same.
Signed-off-by: Arvo Jarve <arvo@softshark.ee>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
BUG! Setting CRL parameter overwrote the CR Algorithm type,
eventually leading to wrong search algorithm to be employed in
the DVB-S carrier loop optimization.
Symptom: Once the CR optimization stage is passed either way, in
a successful or failed manner, the very next carrier search will
fail, due to no Carrier Search Algorithm specified.
Signed-off-by: Arvo Jarve <arvo@softshark.ee>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Marko Schluessler <marco@lordzodiac.de>
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* Saves 70 mS LOCK time on the STB6100 based
* Saves 100 mS LOCK time on the TDA8261 based
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
which should have happenend in the DVB-S2 mode only, but reading it as it is
for the other delivery systems causes nothing to say but LOCK_LOST, which
just causes confusion amongst users.
Signed-off-by: Manu Abraham <manu@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
