Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-03-13 Thread Andy Walls
On Fri, 2010-03-12 at 21:34 +1100, Vincent McIntyre wrote:
 On 2/20/10, Mauro Carvalho Chehab mche...@redhat.com wrote:
  Robert Lowery wrote:
  Mauro,
 
  I had to make 2 changes to get the patch to work for me
 
  Ok. Please test this (hopefully) final revision.
 
  --
 
  commit bd8bb8798bb96136b6898186d505c9e154334b5d
  Author: Mauro Carvalho Chehab mche...@redhat.com
  Date:   Fri Feb 19 02:45:00 2010 -0200
 
 I finally found time to test carefully and if anyone still cares, the
 patch works fine for me too.
 I pulled it in from the hg tree, by the time it got there it had
 morphed a little...
 Many thanks for your (and Rob's) patient work on this.
 
 I've attached a test log that shows what happens with signaltest.pl,
 on each tuner.
 The first two adapters are the Dual Digital 4 rev1, the next two
 belong to a FusionHDTV Dual Digital Express.
 
 The errors are nice and small now, compared with the values I got
 before the patch.
 I noticed something a little odd - the UNC error value always
 increases, even though
 signaltest.pl does a fresh invocation for each station in the sequence.

This is proper behavior for the frontend.  The UNC count should not be
reset when it is read (think of what would happen when more than one app
was trying to monitor the frontend status).

What matters is the slope of the UNC curve over a measurement interval:
== 0 is good,  0 is bad.


 Switching to a different tuner seems to reset the UNC error counters.

The zl10353 driver will maintain the UNC block count for each paticular
ZL10353 chip in the system.  It will only go back to 0 for a particular
ZL10353 chip when the the driver's 32 bit state-ucblocks variable for
that chip rolls over.

Regards,
Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Robert Lowery
Mauro,

I had to make 2 changes to get the patch to work for me

see below

HTH

-Rob

 Robert Lowery wrote:
 Mauro's new code does the 50 offset unconditionally for DTV7 by
 setting offset = 225, not just when the ZARLINK456 or DIBCOM52
 tables
 were explicitly selected.  This change is what appears to cause issues
 for
 me.

 I've reviewed all information and troubles we have with xc3028 tuning,
 including the reports related to newer firmwares for XC3028L. I think
 that the right fix is the one provided on this patch.

 Could you all please verify if this patch fixes the issues, without
 causing
 any regression?

 Cheers,
 Mauro.

 ---

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/common/tuners/tuner-xc2028.c |   51
 
  1 files changed, 37 insertions(+), 14 deletions(-)

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..eb782a0 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version = 0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 50;
This should be offset += 50;

 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
I had to also delete the
if (type  DTV7)
demod += 500

I suspect this is no longer required due to the offset += 50 above
 --
 1.6.6.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html




Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Mauro Carvalho Chehab
Robert Lowery wrote:
 Mauro,
 
 I had to make 2 changes to get the patch to work for me
 
 see below
 
 HTH
 
 -Rob
 
 +if (priv-firm_version = 0x0302) {
 +if (priv-cur_fw.type  DTV7)
 +offset -= 30;
 +else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 +offset += 20;
 +} else {
 +if (priv-cur_fw.type  DTV7)
 +offset -= 50;
 This should be offset += 50;
 
  /*
   * The DTV7 S-code table needs a 700 kHz shift.
   * Thanks to Terry Wu terrywu2...@gmail.com for reporting this
 I had to also delete the
 if (type  DTV7)
 demod += 500
 
 I suspect this is no longer required due to the offset += 50 above

Both lines should be doing the same thing, but IMO, the better is to keep 
the change at the demod.

Could you please preserve the above and remove the offset +=50 ?

Note: are you available for irc? if so, please join #linuxtv at freenode.net.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Mauro Carvalho Chehab
Robert Lowery wrote:
 Mauro,
 
 I had to make 2 changes to get the patch to work for me

Ok. Please test this (hopefully) final revision.

-- 

commit bd8bb8798bb96136b6898186d505c9e154334b5d
Author: Mauro Carvalho Chehab mche...@redhat.com
Date:   Fri Feb 19 02:45:00 2010 -0200

V4L/DVB: tuner-xc2028: fix tuning logic

There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.

Thanks-to: Robert Lowery rglow...@exemail.com.au
Thanks-to: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..ef61815 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,52 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 
freq /* in HZ */,
 * that xc2028 will be in a safe state.
 * Maybe this might also be needed for DTV.
 */
-   if (new_mode == T_ANALOG_TV)
+   if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
 
-   /*
-* Digital modes require an offset to adjust to the
-* proper frequency.
-* Analog modes require offset = 0
-*/
-   if (new_mode == T_DIGITAL_TV) {
-   /* Sets the offset according with firmware */
+   /* Analog modes require offset = 0 */
+   } else {
+   /*
+* Digital modes require an offset to adjust to the
+* proper frequency. The offset depends on what
+* firmware version is used.
+*/
+
+   /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
if (priv-cur_fw.type  DTV6)
offset = 175;
else if (priv-cur_fw.type  DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+   if ((priv-cur_fw.type  DTV78)  freq  47000)
+   offset -= 50;
 
/*
-* We must adjust the offset by 500kHz  when
-* tuning a 7MHz VHF channel with DTV78 firmware
-* (used in Australia, Italy and Germany)
+* xc3028 additional magic
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
 */
-   if ((priv-cur_fw.type  DTV78)  freq  47000)
-   offset -= 50;
+
+   if (priv-firm_version  0x0302) {
+   if (priv-cur_fw.type  DTV7)
+   offset += 50;
+#if 0
+   /* Still need some tests */
+   } else {
+   if (priv-cur_fw.type  DTV7)
+   offset -= 30;
+   else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
*/
+   offset += 20;
+#endif
+   }
}
 
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,17 +1136,22 @@ static int xc2028_set_params(struct dvb_frontend *fe,
 
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
-   demod = priv-ctrl.demod + 200;
+   /*
+* Newer firmwares require a 200 kHz offset only for ATSC
+*/
+   if (type == ATSC || priv-firm_version  0x0302)
+   demod = priv-ctrl.demod + 200;
/*
 * The DTV7 S-code table needs a 700 kHz shift.
-* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
 *
 * DTV7 is only used in Australia.  Germany or Italy may also
 * use this firmware after initialization, but a tune to a UHF
 * channel should then cause DTV78 to be used.
+*
+* Unfortunately, on real-field tests, the s-code offset
+* didn't work as expected, as reported by
+* Robert Lowery rglow...@exemail.com.au
 */
-   if (type  DTV7)
-   demod += 500;
}
 
return generic_set_freq(fe, p-frequency,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-19 Thread Robert Lowery
 Robert Lowery wrote:
 Mauro,

 I had to make 2 changes to get the patch to work for me

 Ok. Please test this (hopefully) final revision.

This version works for me

 --

 commit bd8bb8798bb96136b6898186d505c9e154334b5d
 Author: Mauro Carvalho Chehab mche...@redhat.com
 Date:   Fri Feb 19 02:45:00 2010 -0200

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..ef61815 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,52 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version  0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset += 50;
 +#if 0
 + /* Still need some tests */
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 +#endif
 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,17 +1136,22 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
 -  * Thanks to Terry Wu terrywu2...@gmail.com for reporting this
*
* DTV7 is only used in Australia.  Germany or Italy may also
* use this firmware after initialization, but a tune to a UHF
* channel should then cause DTV78 to be used.
 +  *
 +  * Unfortunately, on real-field tests, the s-code offset
 +  * didn't work as expected, as reported by
 +  * Robert Lowery rglow...@exemail.com.au
*/
 - if (type  DTV7)
 - demod += 500;
   }

   return generic_set_freq(fe, p-frequency,
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-18 Thread Mauro Carvalho Chehab
Robert Lowery wrote:
 Mauro's new code does the 50 offset unconditionally for DTV7 by
 setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
 were explicitly selected.  This change is what appears to cause issues for
 me.

I've reviewed all information and troubles we have with xc3028 tuning,
including the reports related to newer firmwares for XC3028L. I think
that the right fix is the one provided on this patch.

Could you all please verify if this patch fixes the issues, without causing
any regression?

Cheers,
Mauro.

---

V4L/DVB: tuner-xc2028: fix tuning logic

There's one reported regression in Australia (DTV7) and some
reported troubles with newer firmwares. Rework the logic to improve
tuner on those cases.

Thanks-to: Robert Lowery rglow...@exemail.com.au
Thanks-to: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/media/common/tuners/tuner-xc2028.c |   51 
 1 files changed, 37 insertions(+), 14 deletions(-)

diff --git a/drivers/media/common/tuners/tuner-xc2028.c 
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..eb782a0 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe, u32 
freq /* in HZ */,
 * that xc2028 will be in a safe state.
 * Maybe this might also be needed for DTV.
 */
-   if (new_mode == T_ANALOG_TV)
+   if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
 
-   /*
-* Digital modes require an offset to adjust to the
-* proper frequency.
-* Analog modes require offset = 0
-*/
-   if (new_mode == T_DIGITAL_TV) {
-   /* Sets the offset according with firmware */
+   /* Analog modes require offset = 0 */
+   } else {
+   /*
+* Digital modes require an offset to adjust to the
+* proper frequency. The offset depends on what
+* firmware version is used.
+*/
+
+   /*
+* Adjust to the center frequency. This is calculated by the
+* formula: offset = 1.25MHz - BW/2
+* For DTV 7/8, the firmware uses BW = 8000, so it needs a
+* further adjustment to get the frequency center on VHF
+*/
if (priv-cur_fw.type  DTV6)
offset = 175;
else if (priv-cur_fw.type  DTV7)
offset = 225;
else/* DTV8 or DTV78 */
offset = 275;
+   if ((priv-cur_fw.type  DTV78)  freq  47000)
+   offset -= 50;
 
/*
-* We must adjust the offset by 500kHz  when
-* tuning a 7MHz VHF channel with DTV78 firmware
-* (used in Australia, Italy and Germany)
+* xc3028 additional magic
+* Depending on the firmware version, it needs some adjustments
+* to properly centralize the frequency. This seems to be
+* needed to compensate the SCODE table adjustments made by
+* newer firmwares
 */
-   if ((priv-cur_fw.type  DTV78)  freq  47000)
-   offset -= 50;
+
+   if (priv-firm_version = 0x0302) {
+   if (priv-cur_fw.type  DTV7)
+   offset -= 30;
+   else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
*/
+   offset += 20;
+   } else {
+   if (priv-cur_fw.type  DTV7)
+   offset -= 50;
+   }
}
 
div = (freq - offset + DIV / 2) / DIV;
@@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend *fe,
 
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
-   demod = priv-ctrl.demod + 200;
+   /*
+* Newer firmwares require a 200 kHz offset only for ATSC
+*/
+   if (type == ATSC || priv-firm_version  0x0302)
+   demod = priv-ctrl.demod + 200;
/*
 * The DTV7 S-code table needs a 700 kHz shift.
 * Thanks to Terry Wu terrywu2...@gmail.com for reporting this
-- 
1.6.6.1

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-02-18 Thread Robert Lowery
 Robert Lowery wrote:
 Mauro's new code does the 50 offset unconditionally for DTV7 by
 setting offset = 225, not just when the ZARLINK456 or DIBCOM52
 tables
 were explicitly selected.  This change is what appears to cause issues
 for
 me.

 I've reviewed all information and troubles we have with xc3028 tuning,
 including the reports related to newer firmwares for XC3028L. I think
 that the right fix is the one provided on this patch.

 Could you all please verify if this patch fixes the issues, without
 causing
 any regression?

Thanks Mauro,  I'll test this ASAP.

I suspect there will still be issues with the demod + 500 shift in my
scenario as I had to remove this in the past when changing the offset back
to 275 or else I could not get a tuning lock.

I'll let you know.

-Rob

 Cheers,
 Mauro.

 ---

 V4L/DVB: tuner-xc2028: fix tuning logic

 There's one reported regression in Australia (DTV7) and some
 reported troubles with newer firmwares. Rework the logic to improve
 tuner on those cases.

 Thanks-to: Robert Lowery rglow...@exemail.com.au
 Thanks-to: Stefan Ringel stefan.rin...@arcor.de
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 ---
  drivers/media/common/tuners/tuner-xc2028.c |   51
 
  1 files changed, 37 insertions(+), 14 deletions(-)

 diff --git a/drivers/media/common/tuners/tuner-xc2028.c
 b/drivers/media/common/tuners/tuner-xc2028.c
 index ed50168..eb782a0 100644
 --- a/drivers/media/common/tuners/tuner-xc2028.c
 +++ b/drivers/media/common/tuners/tuner-xc2028.c
 @@ -932,30 +932,49 @@ static int generic_set_freq(struct dvb_frontend *fe,
 u32 freq /* in HZ */,
* that xc2028 will be in a safe state.
* Maybe this might also be needed for DTV.
*/
 - if (new_mode == T_ANALOG_TV)
 + if (new_mode == T_ANALOG_TV) {
   rc = send_seq(priv, {0x00, 0x00});

 - /*
 -  * Digital modes require an offset to adjust to the
 -  * proper frequency.
 -  * Analog modes require offset = 0
 -  */
 - if (new_mode == T_DIGITAL_TV) {
 - /* Sets the offset according with firmware */
 + /* Analog modes require offset = 0 */
 + } else {
 + /*
 +  * Digital modes require an offset to adjust to the
 +  * proper frequency. The offset depends on what
 +  * firmware version is used.
 +  */
 +
 + /*
 +  * Adjust to the center frequency. This is calculated by the
 +  * formula: offset = 1.25MHz - BW/2
 +  * For DTV 7/8, the firmware uses BW = 8000, so it needs a
 +  * further adjustment to get the frequency center on VHF
 +  */
   if (priv-cur_fw.type  DTV6)
   offset = 175;
   else if (priv-cur_fw.type  DTV7)
   offset = 225;
   else/* DTV8 or DTV78 */
   offset = 275;
 + if ((priv-cur_fw.type  DTV78)  freq  47000)
 + offset -= 50;

   /*
 -  * We must adjust the offset by 500kHz  when
 -  * tuning a 7MHz VHF channel with DTV78 firmware
 -  * (used in Australia, Italy and Germany)
 +  * xc3028 additional magic
 +  * Depending on the firmware version, it needs some adjustments
 +  * to properly centralize the frequency. This seems to be
 +  * needed to compensate the SCODE table adjustments made by
 +  * newer firmwares
*/
 - if ((priv-cur_fw.type  DTV78)  freq  47000)
 - offset -= 50;
 +
 + if (priv-firm_version = 0x0302) {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 30;
 + else if (type != ATSC) /* DVB @6MHz, DTV 8 and DTV 7/8 
 */
 + offset += 20;
 + } else {
 + if (priv-cur_fw.type  DTV7)
 + offset -= 50;
 + }
   }

   div = (freq - offset + DIV / 2) / DIV;
 @@ -1114,7 +1133,11 @@ static int xc2028_set_params(struct dvb_frontend
 *fe,

   /* All S-code tables need a 200kHz shift */
   if (priv-ctrl.demod) {
 - demod = priv-ctrl.demod + 200;
 + /*
 +  * Newer firmwares require a 200 kHz offset only for ATSC
 +  */
 + if (type == ATSC || priv-firm_version  0x0302)
 + demod = priv-ctrl.demod + 200;
   /*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
 --
 1.6.6.1

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Terry Wu
Hi,

The 6MHz patch is for Taiwan only.
It should not change anything for 7MHz and 8MHz.

Terry

2010/1/7 Robert Lowery rglow...@exemail.com.au:
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my
 card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
     http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.

 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

 OK.  I forgot there were two offsets at play here: one for the RF
 frequency and one for the SCODE/Intermediate Frequency.

 Right, the S-CODE offsets are somewhat of a mystery to me as I don't
 exactly know the mathematical basis behind them.  The 500 kHz came from
 the best interpretation Maruo and I could make at the time, but it could
 very well be the wrong thing.  (I was guessing it came from a relation
 something like this: 8 MHz - 7 MHz / 2 = 500 kHz)

 If it is the wrong thing, and it looks like it could be, we can back it
 out.  As my colleauge, who used to work at CERN, says Experiment trumps
 theory ... *every* time.  Terry had positive results, you and Vincent
 have negative results.  So I'd like to see what Devin finds, if he can
 test with a DVB-T generator.

 Andy,

 Resend of my proposed patches attached.

 My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just
 change the ATSC test to DTV6 but at the same time a cleanup that was done
 inadvertently removed the 500kHz offset subtraction for DTV7 introducing
 the defect.  01_revert_966ce12c444d.diff partially fixed this regression
 for Terry, but not for me or Vincent.

 I'm having trouble convincing Mauro of this though :), so I would
 appreciate it if Terry could test my patch set and confirm it is ok for
 him.

 So in short, my 01 and 02 patches attached revert the changes that break
 tuning for me and 03 re-implements the DTV6 fix, but without the cleanup
 which breaks me.

 Please review and comment

 -Rob




 The channel with the biggest problem (most stuttering) is Channel 8 in
 Melbourne, which looks correct at 191.625 MHz on the above site.

 OK.  Vincent must have been the one with all the Sydney stations.

 DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is
 interesting; it comes from the same towers as the adjacent analog
 channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200
 kW).

 I guess if anything is off center when setting up the XC3028, the analog
 stations may show up as strong noise - a situation that would 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Terry Wu
Hi,

And the 6MHz patch you mentioned is a wrong patch.
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0

 +  if (priv-cur_fw.type  DTV6)
 +  offset = 175;
 +  if (priv-cur_fw.type  DTV7)
 +  offset = 225;
 +  else/* DTV8 or DTV78 */
 +  offset = 275;

and latest patch should be:
 +  if (priv-cur_fw.type  DTV6)
 +  offset = 175;
 +  else if (priv-cur_fw.type  DTV7)
 +  offset = 225;
 +  else/* DTV8 or DTV78 */
 +  offset = 275;


Terry

2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

    The 6MHz patch is for Taiwan only.
    It should not change anything for 7MHz and 8MHz.

 Terry

 2010/1/7 Robert Lowery rglow...@exemail.com.au:
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my
 card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
     http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.

 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

 OK.  I forgot there were two offsets at play here: one for the RF
 frequency and one for the SCODE/Intermediate Frequency.

 Right, the S-CODE offsets are somewhat of a mystery to me as I don't
 exactly know the mathematical basis behind them.  The 500 kHz came from
 the best interpretation Maruo and I could make at the time, but it could
 very well be the wrong thing.  (I was guessing it came from a relation
 something like this: 8 MHz - 7 MHz / 2 = 500 kHz)

 If it is the wrong thing, and it looks like it could be, we can back it
 out.  As my colleauge, who used to work at CERN, says Experiment trumps
 theory ... *every* time.  Terry had positive results, you and Vincent
 have negative results.  So I'd like to see what Devin finds, if he can
 test with a DVB-T generator.

 Andy,

 Resend of my proposed patches attached.

 My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just
 change the ATSC test to DTV6 but at the same time a cleanup that was done
 inadvertently removed the 500kHz offset subtraction for DTV7 introducing
 the defect.  01_revert_966ce12c444d.diff partially fixed this regression
 for Terry, but not for me or Vincent.

 I'm having trouble convincing Mauro of this though :), so I would
 appreciate it if Terry could test my patch set and confirm it is ok for
 him.

 So in short, my 01 and 02 patches attached revert 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Terry Wu
Hi,

The following codes in the 6MHz patch are not for 6MHz.
Please read the mchehab's comments.
1.28/*
1.29 -   * We must adjust the offset by 500kHz in two cases in 
order
1.30 -   * to correctly center the IF output:
1.31 -   * 1) When the ZARLINK456 or DIBCOM52 tables were 
explicitly
1.32 -   *selected and a 7MHz channel is tuned;
1.33 -   * 2) When tuning a VHF channel with DTV78 firmware.
1.34 +   * We must adjust the offset by 500kHz  when
1.35 +   * tuning a 7MHz VHF channel with DTV78 firmware
1.36 +   * (used in Australia)
1.37 */
1.38 -  if (((priv-cur_fw.type  DTV7) 
1.39 -   (priv-cur_fw.scode_table  (ZARLINK456 | 
DIBCOM52))) ||
1.40 -  ((priv-cur_fw.type  DTV78)  freq  47000))
1.41 +  if ((priv-cur_fw.type  DTV78)  freq  47000)
1.42offset -= 50;


BTW, the DTV7 firmware or DTV78 firmware is using if you are
tuning a VHF channel (frequency  470MHz).
And the above mchehab's new codes will not  do offset -= 50;
if DTV7 firmware is using.

Terry

2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

 And the 6MHz patch you mentioned is a wrong patch.
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0

     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;

 and latest patch should be:
     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          else if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;


 Terry

 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

    The 6MHz patch is for Taiwan only.
    It should not change anything for 7MHz and 8MHz.

 Terry

 2010/1/7 Robert Lowery rglow...@exemail.com.au:
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my
 card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
     http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.

 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

 OK.  I forgot there were two offsets at play here: 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Terry Wu
Hi,

You can check the dmesg output to verify which XCEIVE
firmware/SCODE is using.
For examples,
(1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7
firmware is using,
SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260
[  266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[  267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7
(90), id .
[  267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
SCODE HAS_IF_5260 (6280), id .

(2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78
firmware is using,
SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760
[ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
(110), id .
[ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
SCODE HAS_IF_4760 (62000100), id .

Terry

2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

    The following codes in the 6MHz patch are not for 6MHz.
    Please read the mchehab's comments.
    1.28                /*
    1.29 -               * We must adjust the offset by 500kHz in two cases in 
 order
    1.30 -               * to correctly center the IF output:
    1.31 -               * 1) When the ZARLINK456 or DIBCOM52 tables were 
 explicitly
    1.32 -               *    selected and a 7MHz channel is tuned;
    1.33 -               * 2) When tuning a VHF channel with DTV78 firmware.
    1.34 +               * We must adjust the offset by 500kHz  when
    1.35 +               * tuning a 7MHz VHF channel with DTV78 firmware
    1.36 +               * (used in Australia)
    1.37                 */
    1.38 -              if (((priv-cur_fw.type  DTV7) 
    1.39 -                   (priv-cur_fw.scode_table  (ZARLINK456 | 
 DIBCOM52))) ||
    1.40 -                  ((priv-cur_fw.type  DTV78)  freq  47000))
    1.41 +              if ((priv-cur_fw.type  DTV78)  freq  47000)
    1.42                        offset -= 50;


    BTW, the DTV7 firmware or DTV78 firmware is using if you are
 tuning a VHF channel (frequency  470MHz).
    And the above mchehab's new codes will not  do offset -= 50;
 if DTV7 firmware is using.

 Terry

 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

 And the 6MHz patch you mentioned is a wrong patch.
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0

     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;

 and latest patch should be:
     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          else if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;


 Terry

 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,

    The 6MHz patch is for Taiwan only.
    It should not change anything for 7MHz and 8MHz.

 Terry

 2010/1/7 Robert Lowery rglow...@exemail.com.au:
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my
 card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-07 Thread Robert Lowery
Hi Terry,

Thanks for your comments, my responses are inline below.

 Hi,

 You can check the dmesg output to verify which XCEIVE
 firmware/SCODE is using.
 For examples,
 (1). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV7
 firmware is using,
 SCODE SCODE DTV7 ZARLINK456/HAS_IF_5260
 [  266.008596] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
 [  267.098011] xc2028 0-0061: Loading firmware for type=D2633 DTV7 (90),
id .
 [  267.48] xc2028 0-0061: Loading SCODE for type=DTV7 ZARLINK456
SCODE HAS_IF_5260 (6280), id .

 (2). DVB-T 7MHz bandwidth, frequency=177.5MHz and BASE F8MHZ/DTV78
 firmware is using,
 SCODE DTV78 ZARLINK456/SCODE HAS_IF_4760
 [ 1089.192377] xc2028 0-0061: Loading firmware for type=BASE F8MHZ (3),
id .
 [ 1090.265461] xc2028 0-0061: Loading firmware for type=D2633 DTV78
(110), id .
 [ 1090.278523] xc2028 0-0061: Loading SCODE for type=DTV78 ZARLINK456
SCODE HAS_IF_4760 (62000100), id .

My firmware load logging looks as follows
[  376.312248] xc2028 4-0061: Loading firmware for type=BASE F8MHZ (3), id
.
[  380.832015] xc2028 4-0061: Loading firmware for type=D2633 DTV7 (90),
id .
[  380.912010] xc2028 4-0061: Loading SCODE for type=DTV6 QAM DTV7 DTV78
DTV8 ZARLINK456 SCODE HAS_IF_4760 (620003e0), id .


 Terry

 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,
    The following codes in the 6MHz patch are not for 6MHz.
    Please read the mchehab's comments.
    1.28                /*
    1.29 -               * We must adjust the offset by 500kHz in two
cases in order
    1.30 -               * to correctly center the IF output:
    1.31 -               * 1) When the ZARLINK456 or DIBCOM52 tables
were
 explicitly
    1.32 -               *    selected and a 7MHz channel is tuned;  
 1.33 -               * 2) When tuning a VHF channel with DTV78
firmware.
    1.34 +               * We must adjust the offset by 500kHz  when  
 1.35 +               * tuning a 7MHz VHF channel with DTV78 firmware  
 1.36 +               * (used in Australia)
    1.37                 */
    1.38 -              if (((priv-cur_fw.type  DTV7) 
    1.39 -                   (priv-cur_fw.scode_table  (ZARLINK456 |
DIBCOM52))) ||
    1.40 -                  ((priv-cur_fw.type  DTV78)  freq 
47000))
    1.41 +              if ((priv-cur_fw.type  DTV78)  freq 
47000)
    1.42                        offset -= 50;
    BTW, the DTV7 firmware or DTV78 firmware is using if you are tuning
a VHF channel (frequency  470MHz).
    And the above mchehab's new codes will not  do offset -= 50;
if DTV7 firmware is using.
 Terry
Mauro's new code does the 50 offset unconditionally for DTV7 by
setting offset = 225, not just when the ZARLINK456 or DIBCOM52 tables
were explicitly selected.  This change is what appears to cause issues for
me.

The working (old) code used to do something like the following for DTV7

+   offset = 275;
...
+   if (((priv-cur_fw.type  DTV7) 
+(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
+   ((priv-cur_fw.type  DTV78)  freq  47000))
offset -= 50;

My firmware type is DTV7, but priv-cur_fw.scode_table == 129 == SCODE,
which does not match the test for (ZARLINK456 | DIBCOM52), so offset is
left as 275 which works perfectly for me.

The current hg tip which does not work well for me now does a
-   else if (priv-cur_fw.type  DTV7)
-   offset = 225;

including the 500kHz offset adjustment in the initial value.  This causes
a lot of stuttering, corruption etc for me.

My patch set proposes to revert back to the original working code, but
still implement the change from testing against ATSC to DTV6 for (Taiwan?)

That is
diff -r 32b2a1875752 linux/drivers/media/common/tuners/tuner-xc2028.c ---
a/linux/drivers/media/common/tuners/tuner-xc2028.c  Fri Nov 20 12:47:40
2009 +0100
+++ b/linux/drivers/media/common/tuners/tuner-xc2028.c  Fri Nov 27 10:29:22
2009 +1100
@@ -936,7 +936,7 @@
 */
if (new_mode == T_ANALOG_TV) {
rc = send_seq(priv, {0x00, 0x00});
-   } else if (priv-cur_fw.type  ATSC) {
+   } else if (priv-cur_fw.type  DTV6) {
offset = 175;
} else {
offset = 275;

Were you able to test my proposed patches to see if they continue to work
for you

-Rob

 2010/1/7 Terry Wu terrywu2...@gmail.com:
 Hi,
 And the 6MHz patch you mentioned is a wrong patch.
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0
     +          if (priv-cur_fw.type  DTV6)
     +                  offset = 175;
     +          if (priv-cur_fw.type  DTV7)
     +                  offset = 225;
     +          else    /* DTV8 or DTV78 */
     +                  offset = 275;
 and latest 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-06 Thread Andy Walls
On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in the
 subject line was unfamiliar to me, so sorry for any late response or dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
  http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/- 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.
 
 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

OK.  I forgot there were two offsets at play here: one for the RF
frequency and one for the SCODE/Intermediate Frequency.

Right, the S-CODE offsets are somewhat of a mystery to me as I don't
exactly know the mathematical basis behind them.  The 500 kHz came from
the best interpretation Maruo and I could make at the time, but it could
very well be the wrong thing.  (I was guessing it came from a relation
something like this: 8 MHz - 7 MHz / 2 = 500 kHz)

If it is the wrong thing, and it looks like it could be, we can back it
out.  As my colleauge, who used to work at CERN, says Experiment trumps
theory ... *every* time.  Terry had positive results, you and Vincent
have negative results.  So I'd like to see what Devin finds, if he can
test with a DVB-T generator.



 The channel with the biggest problem (most stuttering) is Channel 8 in
 Melbourne, which looks correct at 191.625 MHz on the above site.

OK.  Vincent must have been the one with all the Sydney stations.

DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is
interesting; it comes from the same towers as the adjacent analog
channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200
kW).

I guess if anything is off center when setting up the XC3028, the analog
stations may show up as strong noise - a situation that would not be
obvious with a single channel DVB-T signal generator.  GTV8 is probably
a good channel for you to use for testing.


(BTW, given that the analog channel of where GTV8 now resides would have
been Fr = 189.25 MHz, I would have expected GTV8 to really be operating
at Fc = Fr + 2.25 MHz = 191.50 MHz and not 191.625 MHz)



 With debug enabled on the the current hg tip (stuttering case) we have
 divisor= 00 00 2f 58 (freq=191.625)
 
 With the patch reverted (working case)
 divisor= 00 00 2f 38 (freq=191.625)
 
 Have you reviewed my patch.  It leaves your original DTV6 fix in place,
 but reverts the cleanup which broke the offset calculation for me.

I don't have a copy in my email archives, I'll have to go check for them
on the list archives.

Regards,
Andy

 -Rob
 
 
  Regards,
  Andy
 
 
  BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
  cxusb_dvico_xc3028_tuner_attach(), this 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-06 Thread Robert Lowery
 On Wed, 2010-01-06 at 14:20 +1100, Robert Lowery wrote:
  On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
  On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
Mauro,
   
I've split the revert2.diff that I sent you previously to fix the
  tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate
  patches
that will hopefully allow you to review more easily.
   
The first two patches revert their respective changesets and
 nothing
  else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
  6MHz
   
The third patch does what I believe is the obvious equivalent fix
 to
e6a8672631a0 but without the cleanup that breaks tuning on my
 card.
   
Please review and merge
   
Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
   Mauro,
  
   I'm yet to receive a response from you on this clear regression
  introduced
   in the 2.6.31 kernel.  You attention would be appreciated
  
   Thanks
  
   -Rob
  Robert,
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
 and
  some other cards I can't remember, using a DVB-T pattern generator
 for
 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)
  I haven't been following this thread really at all as the board in
 the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb
 questions by me.
  May I ask:
  1. what are the exact problem frequencies?
  2. what is the data source from which you are getting the frequency
 information?
  3. what does tuner-xc2028 debug logging show as the firmware loaded
 when
  tune to one of the the problem frequencies?
 
 
  Robert,
 
  I just found that ACMA has a very nice compilation licensed DTV
  transmitters in Australia and their frequencies.  Have a look at the
 Excel spreadsheet linked on this page:
 
 http://acma.gov.au/WEB/STANDARD/pc=PC_9150
 
  The DTV tab has a list of the Area, callsign, and DTV center freq. The
 Glossary tab mentions that DTV broadcasters can have an offset of +/-
 125
 kHz from the DTV center freq.
 
  If you could verify that the frequencies you are using for the problem
 stations match the list, that would help eliminate commanded tuning
 frequency as source of the problem.

 Andy, I don't think this issue is frequency, it is the removal of the
 500kHz offset.

 OK.  I forgot there were two offsets at play here: one for the RF
 frequency and one for the SCODE/Intermediate Frequency.

 Right, the S-CODE offsets are somewhat of a mystery to me as I don't
 exactly know the mathematical basis behind them.  The 500 kHz came from
 the best interpretation Maruo and I could make at the time, but it could
 very well be the wrong thing.  (I was guessing it came from a relation
 something like this: 8 MHz - 7 MHz / 2 = 500 kHz)

 If it is the wrong thing, and it looks like it could be, we can back it
 out.  As my colleauge, who used to work at CERN, says Experiment trumps
 theory ... *every* time.  Terry had positive results, you and Vincent
 have negative results.  So I'd like to see what Devin finds, if he can
 test with a DVB-T generator.

Andy,

Resend of my proposed patches attached.

My hypothesis is that 02_revert_e6a8672631a0.diff was really meant to just
change the ATSC test to DTV6 but at the same time a cleanup that was done
inadvertently removed the 500kHz offset subtraction for DTV7 introducing
the defect.  01_revert_966ce12c444d.diff partially fixed this regression
for Terry, but not for me or Vincent.

I'm having trouble convincing Mauro of this though :), so I would
appreciate it if Terry could test my patch set and confirm it is ok for
him.

So in short, my 01 and 02 patches attached revert the changes that break
tuning for me and 03 re-implements the DTV6 fix, but without the cleanup
which breaks me.

Please review and comment

-Rob




 The channel with the biggest problem (most stuttering) is Channel 8 in
 Melbourne, which looks correct at 191.625 MHz on the above site.

 OK.  Vincent must have been the one with all the Sydney stations.

 DTV Channel GTV8 (Fc = 191.625 MHz at 50 kW) for Melbourne is
 interesting; it comes from the same towers as the adjacent analog
 channels HSV7 (Fr = 182.25 MHz @ 200 kW) and GTV9 (Fr = 196.25 MHz @ 200
 kW).

 I guess if anything is off center when setting up the XC3028, the analog
 stations may show up as strong noise - a situation that would not be
 obvious with a single channel DVB-T signal generator.  GTV8 is probably
 a good channel for you to use for testing.


 (BTW, given that the analog channel of 

Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-05 Thread Robert Lowery
 On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
 On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
   Mauro,
  
   I've split the revert2.diff that I sent you previously to fix the
 tuning
   regression on my DViCO Dual Digital 4 (rev 1) into three separate
 patches
   that will hopefully allow you to review more easily.
  
   The first two patches revert their respective changesets and
nothing
 else,
   fixing the issue for me.
   12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
   11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @
 6MHz
  
   The third patch does what I believe is the obvious equivalent fix
to
   e6a8672631a0 but without the cleanup that breaks tuning on my card.
  
   Please review and merge
  
   Signed-off-by: Robert Lowery rglow...@exemail.com.au
 
  Mauro,
 
  I'm yet to receive a response from you on this clear regression
 introduced
  in the 2.6.31 kernel.  You attention would be appreciated
 
  Thanks
 
  -Rob
 Robert,
 The changes in question (mostly authored by me) are based on
 documentation on what offsets are to be used with the firmware for
various DVB bandwidths and demodulators.  The change was tested by Terry
 on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028)
and
 some other cards I can't remember, using a DVB-T pattern generator for
7
 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
(Devin,
  Maybe you can double check on the offsets in tuner-xc2028.c with any
documentation you have available to you?)
 I haven't been following this thread really at all as the board in the
subject line was unfamiliar to me, so sorry for any late response or dumb
questions by me.
 May I ask:
 1. what are the exact problem frequencies?
 2. what is the data source from which you are getting the frequency
information?
 3. what does tuner-xc2028 debug logging show as the firmware loaded
when
 tune to one of the the problem frequencies?


 Robert,

 I just found that ACMA has a very nice compilation licensed DTV
 transmitters in Australia and their frequencies.  Have a look at the
Excel spreadsheet linked on this page:

   http://acma.gov.au/WEB/STANDARD/pc=PC_9150

 The DTV tab has a list of the Area, callsign, and DTV center freq. The
Glossary tab mentions that DTV broadcasters can have an offset of +/- 125
kHz from the DTV center freq.

 If you could verify that the frequencies you are using for the problem
stations match the list, that would help eliminate commanded tuning
frequency as source of the problem.

Andy, I don't think this issue is frequency, it is the removal of the
500kHz offset.

The channel with the biggest problem (most stuttering) is Channel 8 in
Melbourne, which looks correct at 191.625 MHz on the above site.

With debug enabled on the the current hg tip (stuttering case) we have
divisor= 00 00 2f 58 (freq=191.625)

With the patch reverted (working case)
divisor= 00 00 2f 38 (freq=191.625)

Have you reviewed my patch.  It leaves your original DTV6 fix in place,
but reverts the cleanup which broke the offset calculation for me.

-Rob


 Regards,
 Andy


 BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
 cxusb_dvico_xc3028_tuner_attach(), this declaration
 static struct xc2028_ctrl ctl = {
 .fname   = XC2028_DEFAULT_FIRMWARE,
 .max_len = 64,
 .demod   = XC3028_FE_ZARLINK456,
 };
 really should have .type = XC2028_AUTO or .type = XC2028_D2633, but
since XC2028_AUTO has a value of 0, it probably doesn't matter.
Regards,
 Andy
 --
 To unsubscribe from this list: send the line unsubscribe linux-media
in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

 --
 To unsubscribe from this list: send the line unsubscribe linux-media
in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html







--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-04 Thread Andy Walls
On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
  Mauro,
 
  I've split the revert2.diff that I sent you previously to fix the tuning
  regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
  that will hopefully allow you to review more easily.
 
  The first two patches revert their respective changesets and nothing else,
  fixing the issue for me.
  12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
  11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
 
  The third patch does what I believe is the obvious equivalent fix to
  e6a8672631a0 but without the cleanup that breaks tuning on my card.
 
  Please review and merge
 
  Signed-off-by: Robert Lowery rglow...@exemail.com.au
 
 Mauro,
 
 I'm yet to receive a response from you on this clear regression introduced
 in the 2.6.31 kernel.  You attention would be appreciated
 
 Thanks
 
 -Rob

Robert,

The changes in question (mostly authored by me) are based on
documentation on what offsets are to be used with the firmware for
various DVB bandwidths and demodulators.  The change was tested by Terry
on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and
some other cards I can't remember, using a DVB-T pattern generator for 7
and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.

(Devin,
 Maybe you can double check on the offsets in tuner-xc2028.c with any
 documentation you have available to you?)


I haven't been following this thread really at all as the board in the
subject line was unfamiliar to me, so sorry for any late response or
dumb questions by me.  

May I ask:

1. what are the exact problem frequencies?
2. what is the data source from which you are getting the frequency
information?
3. what does tuner-xc2028 debug logging show as the firmware loaded when
tune to one of the the problem frequencies?




BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
cxusb_dvico_xc3028_tuner_attach(), this declaration

static struct xc2028_ctrl ctl = {
.fname   = XC2028_DEFAULT_FIRMWARE,
.max_len = 64,
.demod   = XC3028_FE_ZARLINK456,
};

really should have .type = XC2028_AUTO or .type = XC2028_D2633, but
since XC2028_AUTO has a value of 0, it probably doesn't matter.


Regards,
Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-04 Thread Andy Walls
On Mon, 2010-01-04 at 21:27 -0500, Andy Walls wrote:
 On Mon, 2010-01-04 at 15:27 +1100, Robert Lowery wrote:
   Mauro,
  
   I've split the revert2.diff that I sent you previously to fix the tuning
   regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
   that will hopefully allow you to review more easily.
  
   The first two patches revert their respective changesets and nothing else,
   fixing the issue for me.
   12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
   11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz
  
   The third patch does what I believe is the obvious equivalent fix to
   e6a8672631a0 but without the cleanup that breaks tuning on my card.
  
   Please review and merge
  
   Signed-off-by: Robert Lowery rglow...@exemail.com.au
  
  Mauro,
  
  I'm yet to receive a response from you on this clear regression introduced
  in the 2.6.31 kernel.  You attention would be appreciated
  
  Thanks
  
  -Rob
 
 Robert,
 
 The changes in question (mostly authored by me) are based on
 documentation on what offsets are to be used with the firmware for
 various DVB bandwidths and demodulators.  The change was tested by Terry
 on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and
 some other cards I can't remember, using a DVB-T pattern generator for 7
 and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 
 (Devin,
  Maybe you can double check on the offsets in tuner-xc2028.c with any
  documentation you have available to you?)
 
 
 I haven't been following this thread really at all as the board in the
 subject line was unfamiliar to me, so sorry for any late response or
 dumb questions by me.  
 
 May I ask:
 
 1. what are the exact problem frequencies?
 2. what is the data source from which you are getting the frequency
 information?
 3. what does tuner-xc2028 debug logging show as the firmware loaded when
 tune to one of the the problem frequencies?


Robert,

I just found that ACMA has a very nice compilation licensed DTV
transmitters in Australia and their frequencies.  Have a look at the
Excel spreadsheet linked on this page:

http://acma.gov.au/WEB/STANDARD/pc=PC_9150

The DTV tab has a list of the Area, callsign, and DTV center freq.
The Glossary tab mentions that DTV broadcasters can have an offset of
+/- 125 kHz from the DTV center freq.

If you could verify that the frequencies you are using for the problem
stations match the list, that would help eliminate commanded tuning
frequency as source of the problem.


Regards,
Andy


 BTW, I note that in linux/drivers/media/dvb/dvb-usb/cxusb.c:
 cxusb_dvico_xc3028_tuner_attach(), this declaration
 
 static struct xc2028_ctrl ctl = {
 .fname   = XC2028_DEFAULT_FIRMWARE,
 .max_len = 64,
 .demod   = XC3028_FE_ZARLINK456,
 };
 
 really should have .type = XC2028_AUTO or .type = XC2028_D2633, but
 since XC2028_AUTO has a value of 0, it probably doesn't matter.
 
 
 Regards,
 Andy
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-04 Thread Andy Walls
On Mon, 2010-01-04 at 22:13 -0500, Devin Heitmueller wrote:
 Hey Andy,
 
 On Mon, Jan 4, 2010 at 9:27 PM, Andy Walls awa...@radix.net wrote:
  The changes in question (mostly authored by me) are based on
  documentation on what offsets are to be used with the firmware for
  various DVB bandwidths and demodulators.  The change was tested by Terry
  on a Leadtek DVR 3100 H Analog/DVB-T card (CX23418, ZL10353, XC3028) and
  some other cards I can't remember, using a DVB-T pattern generator for 7
  and 8 MHz in VHF and UHF, and live DVB-T broadcasts in UHF for 6 MHz.
 
  (Devin,
   Maybe you can double check on the offsets in tuner-xc2028.c with any
   documentation you have available to you?)
 
 At this point the extent to which I've looked in to the issue was
 validating that, for a given frequency, the change resulted in a
 crappy SNR with lots of BER/UNC errors, and after reverting the change
 the signal looked really good with zero BER/UNC.  I haven't dug into
 *why* it is an issue, but I examined the traces and looked at the
 testing methodology and can confirm that there was definitely a
 regression and Robert narrowed it down to the patch in question.
 
 I was kind of hoping that one of the people that helped introduce the
 regression would take on some of responsibility to help with the
 debugging.  ;-)

I take responsiblity for the change.  However, if fixing a known problem
unmasks another problem, then is that a regression?


I puzzled over the docs for a while until I had the Aha! moment and
understood what they were saying.  I'm really confident about the freq
offset changes - especially since using the wrong center freq in
channels.conf is an easy way to mask incorrect freq offsets in the
driver module.

I'm less confident about the xc3028 firmware segments as extracted and
repackaged for linux.  I was not involved in that development and I
conveniently (for me) assume it is correct -- although that may be an
assumption worth challenging.

I also do not know the source of the commanded DTV freq's that are in
use in the reported problem case.  Using the wrong DTV center freq can
cause the same problem symptoms as moving the offset used in the
tuner-xc2028 module (two wrongs making a right).  I just found a nice
authoritative Australian source on DTV freq licensees (see my other
foloow-up email), so hopefully Robert can double check that.

Of course testing with a DVB-T generator instead of a broadcaster's
signal would eliminate any doubt about the center freq in use.


 I think I have one of the boards that will demonstrate the issue (a
 Terratec board with xc3028/zl10353), and will try to find some time
 with the generator once I wrap up the xc4000 work for the PCTV 340e.

OK, thanks.  I have no hardware with which to test.

Regards,
Andy

 Devin


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2010-01-03 Thread Robert Lowery
 Mauro,

 I've split the revert2.diff that I sent you previously to fix the tuning
 regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
 that will hopefully allow you to review more easily.

 The first two patches revert their respective changesets and nothing else,
 fixing the issue for me.
 12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
 11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz

 The third patch does what I believe is the obvious equivalent fix to
 e6a8672631a0 but without the cleanup that breaks tuning on my card.

 Please review and merge

 Signed-off-by: Robert Lowery rglow...@exemail.com.au

Mauro,

I'm yet to receive a response from you on this clear regression introduced
in the 2.6.31 kernel.  You attention would be appreciated

Thanks

-Rob

 Thanks

 -Rob



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-15 Thread Robert Lowery
Mauro,

I've split the revert2.diff that I sent you previously to fix the tuning
regression on my DViCO Dual Digital 4 (rev 1) into three separate patches
that will hopefully allow you to review more easily.

The first two patches revert their respective changesets and nothing else,
fixing the issue for me.
12167:966ce12c444d tuner-xc2028: Fix 7 MHz DVB-T
11918:e6a8672631a0 tuner-xc2028: Fix offset frequencies for DVB @ 6MHz

The third patch does what I believe is the obvious equivalent fix to
e6a8672631a0 but without the cleanup that breaks tuning on my card.

Please review and merge

Signed-off-by: Robert Lowery rglow...@exemail.com.au

Thanks

-Rob


01_revert_966ce12c444d.diff
Description: /


02_revert_e6a8672631a0.diff
Description: /


03_refix_e6a8672631a0.diff
Description: /


Re: [RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-08 Thread Vincent McIntyre
 Mauro,

 Resend of my proposed patch attached that reverts tuning regressions with
 my DViCO card, whilst still fixing the original 6Mhz tuning issue.  Please
 merge or let me know how else I should proceed to get this merged.

 Thanks

 -Rob

perhaps the attached notes will help Rob's case here.
I did a few more tests, with just one tuner.
First I changed a cable that I was suspicious of (it was way too long anyway)
but I got no significant improvement.
Then I applied the 'revert2.diff' patch that Rob sent and cold-booted.
I reran the test and got significantly lower BER and UNC values.

There is still something odd going on, in that the UNC seem to get
worse with repeated tunings to the same channel, a few minutes apart
(less than 10min). This might be a
measurement artefact, I don't know. I might try changing the channel
order - that should
test whether the trend of the UNC values is with frequency or order in
the tuning sequence.

Cheers
VInce
2009-12-07

Try signaltest.pl again.

First, with old cable and no code changes
hg identify = c57f47cfb0e8+ tip

tuner 0 is usbid 0fe9:db78
do three consecutive runs to see if things worsen with repeated tuning.

Frequency   Signal  Ber Unc
=   
17750 75.9 %   318.9   376.2
191625000 74.5 %   280.1   904.9
21950 77.0 %   245.2  1862.2
22650 77.0 %   186.4  3525.4
57150 77.1 %   502.9  6161.3
57850 77.2 %   541.1  9128.8

Frequency   Signal  Ber Unc
=   
17750 75.5 %   314.6 11219.2
191625000 74.0 %   384.3 12057.3
21950 76.8 %   118.7 13236.9
22650 76.8 %   173.5 15256.6
57150 77.0 %   472.3 17930.7
57850 77.1 %   550.0 20888.8

Frequency   Signal  Ber Unc
=   
17750 75.4 %   346.0 23052.8
191625000 73.3 %   347.5 24087.7
21950 76.7 %   236.0 25289.0
22650 76.8 %   190.1 27241.0
57150 76.9 %   541.1 29910.0
57850 77.1 %   511.7 32902.1


Now repeat with the 1.5m cable connecting wall socket to splitter.
cold boot the machine
hg identify = c57f47cfb0e8+ tip

dvb0.frontend0: usbid 0fe9:db78

Frequency   Signal  Ber Unc
=   
17750 74.0 %   288.2   784.8
191625000 73.3 %   487.2  1890.9
21950 76.7 %   147.2  3189.8
22650 76.8 %   202.2  5094.7
57150 76.9 %   443.1  7640.6
57850 76.9 %   499.9 10675.3

Frequency   Signal  Ber Unc
=   
17750 73.0 %   330.7 12795.4
191625000 72.6 %   291.8 13844.3
21950 76.7 %   132.5 15005.5
22650 76.8 %   136.2 16928.0
57150 76.9 %   525.2 19480.7
57850 77.0 %   522.7 22361.7

Frequency   Signal  Ber Unc
=   
17750 75.5 %   361.6 24584.2
191625000 73.8 %   480.9 25816.4
21950 76.7 %   143.4 26962.2
22650 76.8 %   187.5 28846.1
57150 77.0 %   468.4 31448.9
57850 77.0 %   547.3 34511.8


Now make the code change. Cold boot.
dvb0.frontend0: usbid 0fe9:db78

Frequency   Signal  Ber Unc
=   
17750 76.5 % 0.0 0.0
191625000 76.9 %   136.8   102.3
21950 76.9 %   297.6   549.0
22650 76.8 %   304.7  1461.4
57150 76.9 %   505.0  3801.0
57850 77.0 %   573.7  6818.6

Frequency   Signal  Ber Unc
=   
17750 76.4 % 0.0  8345.0
191625000 76.8 %   169.7  8476.0
21950 76.7 %   243.8  8967.2
22650 76.9 %   271.6  9904.7
57150 76.9 %   525.9 12097.4
57850 77.1 %   

[RESEND] Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-07 Thread Robert Lowery
 On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre
 vincent.mcint...@gmail.com wrote:
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I
 thought would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

   I got rather different baseline results. All channels had
 significantly higher BER
   than I'd noticed before. After patching, snr on some channels
 seemed a little higher
   and BER was lower. On ch9, I think snr was up and BER improved a
 little.

  here are the signaltest summary tables:
  without patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.0 %           322.6           672.4  Seven
  191625000         76.0 %           320.2          1783.3  Nine
  21950         76.8 %           329.8          2948.2  Ten
  22650         76.9 %           296.6          4885.0  ABC
  57150         77.0 %           542.0          7529.4  SBS
  57850         77.1 %           539.5         10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.6 %             2.3             0.0
  191625000         77.0 %           235.5            83.3
  21950         76.9 %           288.0           501.8
  22650         76.9 %           295.1          1416.4
  57150         77.0 %           523.4          3980.0
  57850         77.1 %           549.9          7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         71.2 %             3.1             0.0
  191625000         21.7 %           645.4           246.4
  21950         73.6 %             1.9          1632.0
  22650         73.5 %             2.8          1632.0
  57150         73.9 %            13.6          2134.6
  57850         72.7 %            58.2          6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         73.2 %             4.0             0.0
  191625000         74.0 %            37.0             0.0
  21950         73.9 %             0.0             0.0
  22650         73.0 %             4.6             0.0
  57150         74.2 %            76.7           193.6
  57850         72.8 %           213.8          4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
  Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.5 %           293.7          1926.4
 191625000         75.9 %           363.2          2993.3
 21950         76.7 %           304.5          4225.8
 22650         76.9 %           223.8          6153.3
 57150         77.0 %           491.7          8726.0
 57850         77.1 %           558.9         11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.9 %           327.9         13893.6
 191625000         76.0 %           392.8         14939.0
 21950         76.7 %           252.0         16052.0
 22650         76.8 %           254.0         18063.1
 57150         76.9 %           533.2         20644.1
 57850         76.9 %           464.1         23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         76.3 %             2.5             0.0
 191625000         76.8 %           227.6           119.0
 21950         76.8 %           262.6           604.5
 22650         76.8 %           282.7          1545.4
 57150         77.0 %           486.8          3541.7
 57850         77.1 %           521.5          6537.7


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-02 Thread Devin Heitmueller
On Tue, Dec 1, 2009 at 4:18 AM, Vincent McIntyre
vincent.mcint...@gmail.com wrote:
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the 
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I thought 
 would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

   I got rather different baseline results. All channels had
 significantly higher BER
   than I'd noticed before. After patching, snr on some channels
 seemed a little higher
   and BER was lower. On ch9, I think snr was up and BER improved a little.

  here are the signaltest summary tables:
  without patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.0 %           322.6           672.4  Seven
  191625000         76.0 %           320.2          1783.3  Nine
  21950         76.8 %           329.8          2948.2  Ten
  22650         76.9 %           296.6          4885.0  ABC
  57150         77.0 %           542.0          7529.4  SBS
  57850         77.1 %           539.5         10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency       Signal          Ber             Unc
  =                       
  17750         76.6 %             2.3             0.0
  191625000         77.0 %           235.5            83.3
  21950         76.9 %           288.0           501.8
  22650         76.9 %           295.1          1416.4
  57150         77.0 %           523.4          3980.0
  57850         77.1 %           549.9          7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         71.2 %             3.1             0.0
  191625000         21.7 %           645.4           246.4
  21950         73.6 %             1.9          1632.0
  22650         73.5 %             2.8          1632.0
  57150         73.9 %            13.6          2134.6
  57850         72.7 %            58.2          6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency       Signal          Ber             Unc
  =                       
  17750         73.2 %             4.0             0.0
  191625000         74.0 %            37.0             0.0
  21950         73.9 %             0.0             0.0
  22650         73.0 %             4.6             0.0
  57150         74.2 %            76.7           193.6
  57850         72.8 %           213.8          4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
  Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.5 %           293.7          1926.4
 191625000         75.9 %           363.2          2993.3
 21950         76.7 %           304.5          4225.8
 22650         76.9 %           223.8          6153.3
 57150         77.0 %           491.7          8726.0
 57850         77.1 %           558.9         11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency       Signal          Ber             Unc
 =                       
 17750         75.9 %           327.9         13893.6
 191625000         76.0 %           392.8         14939.0
 21950         76.7 %           252.0         16052.0
 22650         76.8 %           254.0         18063.1
 57150         76.9 %           533.2         20644.1
 57850         76.9 %           464.1         23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency       Signal          Ber             Unc
 =                       
 17750         76.3 %             2.5             0.0
 191625000         76.8 %           227.6           119.0
 21950         76.8 %           262.6           604.5
 22650         76.8 %           282.7          1545.4
 57150         77.0 %           486.8          3541.7
 57850         77.1 %           521.5          6537.7



Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-01 Thread Vincent McIntyre
Hi Rob

I missed your followup and tested the 'revert.diff' patch, attached
for reference.
I have been slow replying because I've been scratching my head over the results.

I used 'signaltest.pl' to test[1], which uses tzap under the hood.
Perhaps this is not the best choice, but I wanted something that I thought would
allow objective comparisons. That's trickier than I thought...
Unfortunately I only discovered last night how easy 'vlc
./channels.conf' makes doing quick visual checks. I didn't have enough
time to re-patch and test again.

My test procedure was:
 - get a baseline with tzap and signaltest.pl
 - patch, make, install. cold boot.
 - test with tzap and signaltest.pl
 - revert patch, for the moment.

I tested two kernels, and both cards. I tested all the tuners but I'll
spare you that for now.

 * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

   I got rather different baseline results. All channels had
significantly higher BER
   than I'd noticed before. After patching, snr on some channels
seemed a little higher
   and BER was lower. On ch9, I think snr was up and BER improved a little.

  here are the signaltest summary tables:
  without patch. usb device (dvb0) usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.0 %   322.6   672.4  Seven
 191625000 76.0 %   320.2  1783.3  Nine
 21950 76.8 %   329.8  2948.2  Ten
 22650 76.9 %   296.6  4885.0  ABC
 57150 77.0 %   542.0  7529.4  SBS
 57850 77.1 %   539.5 10669.7  D44

 with patch. usb device (dvb0) usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.6 % 2.3 0.0
 191625000 77.0 %   235.583.3
 21950 76.9 %   288.0   501.8
 22650 76.9 %   295.1  1416.4
 57150 77.0 %   523.4  3980.0
 57850 77.1 %   549.9  7409.4

 without patch. pcie device (dvb1) pciid db78:18ac
 Frequency   Signal  Ber Unc
 =   
 17750 71.2 % 3.1 0.0
 191625000 21.7 %   645.4   246.4
 21950 73.6 % 1.9  1632.0
 22650 73.5 % 2.8  1632.0
 57150 73.9 %13.6  2134.6
 57850 72.7 %58.2  6393.4

 with patch. pcie device (dvb1) pciid db78:18ac
 Frequency   Signal  Ber Unc
 =   
 17750 73.2 % 4.0 0.0
 191625000 74.0 %37.0 0.0
 21950 73.9 % 0.0 0.0
 22650 73.0 % 4.6 0.0
 57150 74.2 %76.7   193.6
 57850 72.8 %   213.8  4480.3


 * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
  Hard to say if I'm seeing an improvement.

before patching - adapter0 usbid db78:0fe9
Frequency   Signal  Ber Unc
=   
17750 75.5 %   293.7  1926.4
191625000 75.9 %   363.2  2993.3
21950 76.7 %   304.5  4225.8
22650 76.9 %   223.8  6153.3
57150 77.0 %   491.7  8726.0
57850 77.1 %   558.9 11787.1

adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
Frequency   Signal  Ber Unc
=   
17750 75.9 %   327.9 13893.6
191625000 76.0 %   392.8 14939.0
21950 76.7 %   252.0 16052.0
22650 76.8 %   254.0 18063.1
57150 76.9 %   533.2 20644.1
57850 76.9 %   464.1 23836.8

after patching - adapter0 usbid db78:0fe9
Frequency   Signal  Ber Unc
=   
17750 76.3 % 2.5 0.0
191625000 76.8 %   227.6   119.0
21950 76.8 %   262.6   604.5
22650 76.8 %   282.7  1545.4
57150 77.0 %   486.8  3541.7
57850 77.1 %   521.5  6537.7


before patching - adapter1 pciid db78:18ac
Frequency   Signal  Ber Unc
=   
17750 

Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-12-01 Thread Robert Lowery
 Hi Rob

 I missed your followup and tested the 'revert.diff' patch, attached
 for reference.
 I have been slow replying because I've been scratching my head over the
 results.

 I used 'signaltest.pl' to test[1], which uses tzap under the hood.
 Perhaps this is not the best choice, but I wanted something that I thought
 would
 allow objective comparisons. That's trickier than I thought...
 Unfortunately I only discovered last night how easy 'vlc
 ./channels.conf' makes doing quick visual checks. I didn't have enough
 time to re-patch and test again.

 My test procedure was:
  - get a baseline with tzap and signaltest.pl
  - patch, make, install. cold boot.
  - test with tzap and signaltest.pl
  - revert patch, for the moment.

 I tested two kernels, and both cards. I tested all the tuners but I'll
 spare you that for now.

  * 2.6.24-23-rt + v4l (c57f47cfb0e8+ tip)

I got rather different baseline results. All channels had
 significantly higher BER
than I'd noticed before. After patching, snr on some channels
 seemed a little higher
and BER was lower. On ch9, I think snr was up and BER improved a
 little.

   here are the signaltest summary tables:
   without patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.0 %   322.6   672.4  Seven
  191625000 76.0 %   320.2  1783.3  Nine
  21950 76.8 %   329.8  2948.2  Ten
  22650 76.9 %   296.6  4885.0  ABC
  57150 77.0 %   542.0  7529.4  SBS
  57850 77.1 %   539.5 10669.7  D44

  with patch. usb device (dvb0) usbid db78:0fe9
  Frequency   Signal  Ber Unc
  =   
  17750 76.6 % 2.3 0.0
  191625000 77.0 %   235.583.3
  21950 76.9 %   288.0   501.8
  22650 76.9 %   295.1  1416.4
  57150 77.0 %   523.4  3980.0
  57850 77.1 %   549.9  7409.4

  without patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 71.2 % 3.1 0.0
  191625000 21.7 %   645.4   246.4
  21950 73.6 % 1.9  1632.0
  22650 73.5 % 2.8  1632.0
  57150 73.9 %13.6  2134.6
  57850 72.7 %58.2  6393.4

  with patch. pcie device (dvb1) pciid db78:18ac
  Frequency   Signal  Ber Unc
  =   
  17750 73.2 % 4.0 0.0
  191625000 74.0 %37.0 0.0
  21950 73.9 % 0.0 0.0
  22650 73.0 % 4.6 0.0
  57150 74.2 %76.7   193.6
  57850 72.8 %   213.8  4480.3


  * 2.6.31-14-generic + v4l (19c0469c02c3+ tip)
   Hard to say if I'm seeing an improvement.

 before patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 75.5 %   293.7  1926.4
 191625000 75.9 %   363.2  2993.3
 21950 76.7 %   304.5  4225.8
 22650 76.9 %   223.8  6153.3
 57150 77.0 %   491.7  8726.0
 57850 77.1 %   558.9 11787.1

 adapter0 repeat usbid db78:0fe9 (not sure what happened to UNC here..)
 Frequency   Signal  Ber Unc
 =   
 17750 75.9 %   327.9 13893.6
 191625000 76.0 %   392.8 14939.0
 21950 76.7 %   252.0 16052.0
 22650 76.8 %   254.0 18063.1
 57150 76.9 %   533.2 20644.1
 57850 76.9 %   464.1 23836.8

 after patching - adapter0 usbid db78:0fe9
 Frequency   Signal  Ber Unc
 =   
 17750 76.3 % 2.5 0.0
 191625000 76.8 %   227.6   119.0
 21950 76.8 %   262.6   604.5
 22650 76.8 %   282.7  1545.4
 57150 77.0 %   486.8  3541.7
 57850 77.1 %   521.5  6537.7


 before patching - adapter1 pciid db78:18ac
 Frequency   Signal  

Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Robert Lowery
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
 DVB @ 6MHz)
Actually, in addition to the above changeset, I also had to revert
http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
things going.  Seems this one might have been an attempt to fix an issue
introduced by the latter, but for me both must be reverted.

-Rob


 In this change, the offset used by my card has been changed from 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 Thanks

 -Rob



 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Vincent McIntyre
Hi Rob

would you mind very much posting a patch that implements these two reversions,
so I can try it easily? My hg-fu is somewhat lacking...
I have the same hardware and noticed what I think is the same issue,
just with Channel 9.
Another manifestation is huge BER and nonzero REC in the output from 'tzap'.

Kind regards,
Vince


On 11/26/09, Robert Lowery rglow...@exemail.com.au wrote:
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
 DVB @ 6MHz)
 Actually, in addition to the above changeset, I also had to revert
 http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
 things going.  Seems this one might have been an attempt to fix an issue
 introduced by the latter, but for me both must be reverted.

 -Rob


 In this change, the offset used by my card has been changed from 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 Thanks

 -Rob



 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Vincent McIntyre
On 11/26/09, Vincent McIntyre vincent.mcint...@gmail.com wrote:

 Another manifestation is huge BER and nonzero REC in the output from
 'tzap'.
doh! I meant huge BER and nonzero UNC.

Apologies also for the top-post.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-26 Thread Robert Lowery
 Hi Rob

 would you mind very much posting a patch that implements these two
 reversions,
 so I can try it easily? My hg-fu is somewhat lacking...
 I have the same hardware and noticed what I think is the same issue,
 just with Channel 9.
 Another manifestation is huge BER and nonzero REC in the output from
 'tzap'.

 Kind regards,
 Vince
revert patch attached



 On 11/26/09, Robert Lowery rglow...@exemail.com.au wrote:
 Hi,

 After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4
 (rev
 1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d
 everything
 appeared to be ok, but I have now noticed certain channels in Australia
 are showing corruption which manifest themselves as blockiness and
 screeching audio.

 I have traced this issue down to
 http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies
 for
 DVB @ 6MHz)
 Actually, in addition to the above changeset, I also had to revert
 http://linuxtv.org/hg/v4l-dvb/rev/966ce12c444d (Fix 7 MHz DVB-T)  to get
 things going.  Seems this one might have been an attempt to fix an issue
 introduced by the latter, but for me both must be reverted.

 -Rob


 In this change, the offset used by my card has been changed from
 275
 to 225.

 The old code which works used to do something like
 offset = 275
 if (((priv-cur_fw.type  DTV7) 
 (priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
 ((priv-cur_fw.type  DTV78)  freq  47000))
 offset -= 50;

 In Australia, (type  DTV7) == true _BUT_ scode_table == 129 ==
 SCODE,
 so the subtraction is not done.

 The new code which does not work does
 if (priv-cur_fw.type  DTV7)
 offset = 225;
 which appears to be off by 500khz causing the tuning regression for me.

 Could any one please advice why this check against scode_table 
 (ZARLINK456 | DIBCOM52) was removed?

 Thanks

 -Rob



 --
 To unsubscribe from this list: send the line unsubscribe linux-media
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



 --
 To unsubscribe from this list: send the line unsubscribe linux-media
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



revert.diff
Description: Binary data


DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-25 Thread Robert Lowery
Hi,

After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screeching audio.

I have traced this issue down to
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
DVB @ 6MHz)

In this change, the offset used by my card has been changed from 275
to 225.

That is, the old code which works used to do something like
offset = 275
if (((priv-cur_fw.type  DTV7) 
(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
((priv-cur_fw.type  DTV78)  freq  47000))



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1) tuning regression

2009-11-25 Thread Robert Lowery
Hi,

After fixing up a hang on the DViCO FusionHDTV DVB-T Dual Digital 4 (rev
1) recently via http://linuxtv.org/hg/v4l-dvb/rev/1c11cb54f24d everything
appeared to be ok, but I have now noticed certain channels in Australia
are showing corruption which manifest themselves as blockiness and
screeching audio.

I have traced this issue down to
http://linuxtv.org/hg/v4l-dvb/rev/e6a8672631a0 (Fix offset frequencies for
DVB @ 6MHz)

In this change, the offset used by my card has been changed from 275
to 225.

The old code which works used to do something like
offset = 275
if (((priv-cur_fw.type  DTV7) 
(priv-cur_fw.scode_table  (ZARLINK456 | DIBCOM52))) ||
((priv-cur_fw.type  DTV78)  freq  47000))
offset -= 50;

In Australia, (type  DTV7) == true _BUT_ scode_table == 129 == SCODE,
so the subtraction is not done.

The new code which does not work does
if (priv-cur_fw.type  DTV7)
offset = 225;
which appears to be off by 500khz causing the tuning regression for me.

Could any one please advice why this check against scode_table 
(ZARLINK456 | DIBCOM52) was removed?

Thanks

-Rob



--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html