xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
xc3028: force reload of DTV7 firmware in VHF band as DTV78 firmware is not working with bw=7 MHz.
The patch is effective only with Zarlink demodulators.
--- drivers/media/common/tuners/tuner-xc2028.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-)
(quoted diff) +0 -0
b/drivers/media/common/tuners/tuner-xc2028.c
index e531267..d92f862 100644
drivers/media/common/tuners/tuner-xc2028.c +2 -1
@@ -1129,7 +1129,8 @@ static int xc2028_set_params(struct dvb_frontend *fe, priv->ctrl.vhfbw7 =1 ; else priv->ctrl.uhfbw8 = 0; - type |= (priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ?DTV78 :DTV7 ; + type |= (priv->ctrl.demod !=XC3028_FE_ZARLINK456 && + priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ?DTV78 :DTV7 ; type |=F8MHZ ;break ;case BANDWIDTH_6_MHZ :
Signature · 1 line
1.7.0.4
cover xc3028: force reload of DTV7 firmware in VHF band with Zarlink demodulator
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;
For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz);
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is slightly slower.
Devices using the D2620 firmwares are unaffected.
Best regards,
Gianluca Gennari
Quoted 17 lines · Gianluca Gennari
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz);
Quoted 8 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is slightly slower.
Devices using the D2620 firmwares are unaffected.
Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences on the VHF/UHF bands.
I prefer if you could work into a patch that would add some modprobe parameter to disable the current "autodetection" way, allowing to override the firmware used for VHF and UHF.
Thanks,
Mauro
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 35 lines · Gianluca Gennari
Quoted 17 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz);Quoted 8 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.
Quoted 9 lines
I prefer if you could work into a patch that would add some modprobe parameter
to disable the current "autodetection" way, allowing to override the firmware
used for VHF and UHF.Thanks,
Mauro
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East.
Can you provide a reference about problems in other continents like Australia?
Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick?
Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter?
Best regards,
Gianluca
Quoted 46 lines · Gianluca Gennari
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 35 lines · Gianluca Gennari
Quoted 17 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the firmwares with type D2633 for the XC3028 tuner.
I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz);Quoted 8 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do, we end by having troubles, as the issue is Country-dependent. For example, Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.Quoted 9 lines
I prefer if you could work into a patch that would add some modprobe parameter
to disable the current "autodetection" way, allowing to override the firmware
used for VHF and UHF.Thanks,
Mauro
Quoted 6 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East.
Even in Europe, there are some differences.
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to have a developer in Australia, but he moved away, and it seems that he lost interest on DVB development, as we were unable to contact him ever since.
Quoted 3 lines
Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware for VHF and UHF.
Quoted 6 lines
Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter?
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current default doesn't look a good idea, as it will cause regressions, if the new way is not backward-compatible.
Quoted 7 lines
Best regards,
Gianluca--
To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 87 lines · Gianluca Gennari
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
Quoted 51 lines · Gianluca Gennari
Quoted 50 lines
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 48 lines · Gianluca Gennari
Quoted 18 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the
firmwares with type D2633 for the XC3028 tuner.I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not work at all in VHF band (bw=7MHz);Quoted 9 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a 7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do,
we end by having troubles, as the issue is Country-dependent. For example,
Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.I prefer if you could work into a patch that would add some modprobe parameter
to disable the current "autodetection" way, allowing to override the firmware
used for VHF and UHF.Thanks,
MauroQuoted 9 lines
Quoted 6 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East.Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Quoted 7 lines
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to have a developer in Australia, but he moved away, and it seems that he lost interest on DVB development, as we were unable to contact him ever since.
Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware for
VHF and UHF.Seems reasonable.
Quoted 7 lines
Quoted 6 lines
Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter?
Quoted 6 lines
Quoted 3 lines
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current default doesn't look a good idea, as it will cause regressions, if the new way is not backward-compatible.
With the proposed patch DTV78 will be used in UHF band, while DTV7 in VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
Quoted 5 lines
What about a kernel parameter to specify the country? Something like:
country={0-4}
Quoted 7 lines
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding the firmware-related problems to the user (which will have problems understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country, in order to test. Also, a per-country setup like that sucks. Ideally, the driver should use the bandwidh and the other information at the standard DVB parameters, in order to select the right firmware. This works with all other frontends. Not sure what's broken on xc3028 design that it requires a per-country hack. I suspect that it is not a pure per-country hack, but it is also per demod.
As we don't have much complains about it nowadays, I assume that the current behavior is ok for most users. So, a parameter would be used only for those where the default behavior doesn't work.
Btw, we already have a similar parameter to force the audio demodulation standard, due to the same reasons.
Regards,
Mauro
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Quoted 160 lines
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
Quoted 133 lines · Gianluca Gennari
Quoted 92 lines
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
Quoted 53 lines · Gianluca Gennari
Quoted 52 lines
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 50 lines · Gianluca Gennari
Quoted 19 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the
firmwares with type D2633 for the XC3028 tuner.I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
work at all in VHF band (bw=7MHz);Quoted 10 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do,
we end by having troubles, as the issue is Country-dependent. For example,
Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.I prefer if you could work into a patch that would add some modprobe parameter
to disable the current "autodetection" way, allowing to override the firmware
used for VHF and UHF.Thanks,
MauroQuoted 9 lines
Quoted 6 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East.Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Quoted 9 lines
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to have a developer in Australia, but he moved away, and it seems that he lost
interest on DVB development, as we were unable to contact him ever since.Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware for
VHF and UHF.Seems reasonable.
Quoted 8 lines
Quoted 7 lines
Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let
the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter?Quoted 8 lines
Quoted 5 lines
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
default doesn't look a good idea, as it will cause regressions, if the new
way is not backward-compatible.With the proposed patch DTV78 will be used in UHF band, while DTV7 in VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
Quoted 5 lines
What about a kernel parameter to specify the country? Something like:
country={0-4}
Quoted 7 lines
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding the firmware-related problems to the user (which will have problems understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country, in order to test. Also, a per-country setup like that sucks. Ideally, the driver should use the bandwidh and the other information at the standard DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a per-country
hack. I suspect that it is not a pure per-country hack, but it is also per demod.As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those where the default behavior doesn't work.Quoted 7 lines
Btw, we already have a similar parameter to force the audio demodulation standard,
due to the same reasons.Regards,
MauroProbably there are no complains about the firmware because in most countries VHF is not used at all, or is only used for marginal TV stations. In Italy instead the main DTT mux (RAI mux 1) is broadcasted in VHF band for historical reasons, so many Italian users are concerned about it. I've already faced problems related to DTT VHF reception, that were never noticed before by users from other countries.
Moreover, another problem is that there are 2 firmwares types: D2633 and D2620; also there are 2 completely different files: xc3028-v27.fw and xc3028L-v36.fw.
In my case, my stick uses firmwares of type D2633 from file xc3028-v27.fw; I cannot test anything else. It is also possible that the VHF part of the DTV78 firmware of type D2633 in file xc3028-v27.fw is simply broken. As far as I know, this firmware is older than than the first DTT mux in VHF band here in Italy, so maybe it was optimized for analog reception and has never been tested with digital modulations.
Quoted 10 lines
What about a module parameter "alternative-VHF-firmware" which can be either on/off (default=off)?
By default, we keep current behavior; when enabled, DTV7 firmware is always loaded for VHF channels, for all firmware types and files.
Best regards,
Gianluca
Thinking about it, maybe a shorter name like "vhf-fw" = default(0)/alternative(1) would be better.
Best,
Gianluca
Quoted 146 lines · Gianluca Gennari
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Quoted 145 lines
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
Quoted 133 lines · Gianluca Gennari
Quoted 92 lines
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
Quoted 53 lines · Gianluca Gennari
Quoted 52 lines
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 50 lines · Gianluca Gennari
Quoted 19 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using the
firmwares with type D2633 for the XC3028 tuner.I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
work at all in VHF band (bw=7MHz);Quoted 10 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we do,
we end by having troubles, as the issue is Country-dependent. For example,
Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.I prefer if you could work into a patch that would add some modprobe parameter
to disable the current "autodetection" way, allowing to override the firmware
used for VHF and UHF.Thanks,
MauroQuoted 9 lines
Quoted 6 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which kind of firmware is needed on other parts of the world. All I know is what is happening here in Italy, and what I can understand reading the code. I suppose my findings can be extended to the rest of Europe, and maybe Africa and Middle-East.Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Quoted 9 lines
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to have a developer in Australia, but he moved away, and it seems that he lost
interest on DVB development, as we were unable to contact him ever since.Quoted 1 line
Quoted 6 lines
Quoted 2 lines
Do you think a simple module parameters that allows to enable/disable the usage of the DTV78 firmware would do the trick?
Perhaps one or two module parameters to allow forcing a certain firmware for
VHF and UHF.Seems reasonable.
Quoted 8 lines
Quoted 7 lines
Eventually, do you agree that the default solution should be to DISABLE DTV78 firmware, since this seems to be the more robust solution, and let
the user enable it through the kernel parameter if it is working in his country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the kernel module parameter?Quoted 8 lines
Quoted 5 lines
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
default doesn't look a good idea, as it will cause regressions, if the new
way is not backward-compatible.With the proposed patch DTV78 will be used in UHF band, while DTV7 in VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
Quoted 5 lines
What about a kernel parameter to specify the country? Something like:
country={0-4}
Quoted 7 lines
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding the firmware-related problems to the user (which will have problems understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country, in order to test. Also, a per-country setup like that sucks. Ideally, the driver should use the bandwidh and the other information at the standard DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a per-country
hack. I suspect that it is not a pure per-country hack, but it is also per demod.As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those where the default behavior doesn't work.Quoted 7 lines
Btw, we already have a similar parameter to force the audio demodulation standard,
due to the same reasons.Regards,
MauroProbably there are no complains about the firmware because in most countries VHF is not used at all, or is only used for marginal TV stations.
Makes sense. Well, it is not hard to detect VHF. If the DTV bandwidth is properly filled, detecting between 8/7/6 MHz is also easy.
Quoted 7 lines
Quoted 7 lines
In Italy instead the main DTT mux (RAI mux 1) is broadcasted in VHF band for historical reasons, so many Italian users are concerned about it. I've already faced problems related to DTT VHF reception, that were never noticed before by users from other countries.
Moreover, another problem is that there are 2 firmwares types: D2633 and D2620;
AFAIKT, this is related to the demux sensibility: D2633 is normal level, D2620 is lower output level.
Quoted 2 lines
Quoted 2 lines
also there are 2 completely different files: xc3028-v27.fw and xc3028L-v36.fw.
The v3.6 is for xc3028L (low power). It was reported that using v2.7 on a xc3028L will cause it to overheat.
Quoted 4 lines
Quoted 4 lines
In my case, my stick uses firmwares of type D2633 from file xc3028-v27.fw; I cannot test anything else. It is also possible that the VHF part of the DTV78 firmware of type D2633 in file xc3028-v27.fw is simply broken.
Maybe. From my remarks, Australia would use only 7MHz firmware on both VHF and UHF bandwidths. B/G countries would use 7/8 MHz. There were several discussions at the ML by the time we've added support for this tuner, and later on. The logs for it can provide some useful info about the changes.
Quoted 9 lines
Quoted 9 lines
As far as I know, this firmware is older than than the first DTT mux in VHF band here in Italy, so maybe it was optimized for analog reception and has never been tested with digital modulations.
What about a module parameter "alternative-VHF-firmware" which can be either on/off (default=off)?
By default, we keep current behavior; when enabled, DTV7 firmware is always loaded for VHF channels, for all firmware types and files.
Maybe vhf_firmware, being 0 (default behavior), 6, 7, 8 or 78?
Quoted 11 lines
Quoted 5 lines
Best regards,
GianlucaThinking about it, maybe a shorter name like "vhf-fw" = default(0)/alternative(1) would be better.
Best,
Gianluca
Il 07/12/2011 17:21, Mauro Carvalho Chehab ha scritto:
Quoted 177 lines · Gianluca Gennari
Quoted 167 lines
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Quoted 166 lines
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
Quoted 153 lines · Gianluca Gennari
Quoted 107 lines
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
Quoted 69 lines · Gianluca Gennari
Quoted 57 lines
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 52 lines · Gianluca Gennari
Quoted 20 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using
the
firmwares with type D2633 for the XC3028 tuner.I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
work at all in VHF band (bw=7MHz);Quoted 11 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
do,
we end by having troubles, as the issue is Country-dependent. For example,
Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.I prefer if you could work into a patch that would add some modprobe
parameter
to disable the current "autodetection" way, allowing to override the
firmware
used for VHF and UHF.Quoted 3 lines
Thanks,
MauroQuoted 10 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which
kind of firmware is needed on other parts of the world. All I know is
what is happening here in Italy, and what I can understand reading the
code. I suppose my findings can be extended to the rest of Europe, and
maybe Africa and Middle-East.Quoted 2 lines
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Quoted 10 lines
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to
have a developer in Australia, but he moved away, and it seems that he lost
interest on DVB development, as we were unable to contact him ever since.Quoted 1 line
Quoted 8 lines
Quoted 3 lines
Do you think a simple module parameters that allows to enable/disable
the usage of the DTV78 firmware would do the trick?Perhaps one or two module parameters to allow forcing a certain firmware
for
VHF and UHF.Seems reasonable.
Quoted 11 lines
Quoted 10 lines
Eventually, do you agree that the default solution should be to DISABLE
DTV78 firmware, since this seems to be the more robust solution, and let
the user enable it through the kernel parameter if it is working in his
country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the
kernel module parameter?Quoted 8 lines
Quoted 5 lines
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
default doesn't look a good idea, as it will cause regressions, if the new
way is not backward-compatible.With the proposed patch DTV78 will be used in UHF band, while DTV7 in VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
Quoted 5 lines
What about a kernel parameter to specify the country? Something like:
country={0-4}
Quoted 7 lines
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding the firmware-related problems to the user (which will have problems understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard
DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.Quoted 8 lines
Btw, we already have a similar parameter to force the audio demodulation
standard,
due to the same reasons.Regards,
MauroProbably there are no complains about the firmware because in most countries VHF is not used at all, or is only used for marginal TV stations.
Makes sense. Well, it is not hard to detect VHF. If the DTV bandwidth is properly filled, detecting between 8/7/6 MHz is also easy.
Quoted 5 lines
Quoted 5 lines
In Italy instead the main DTT mux (RAI mux 1) is broadcasted in VHF band for historical reasons, so many Italian users are concerned about it. I've already faced problems related to DTT VHF reception, that were never noticed before by users from other countries.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Moreover, another problem is that there are 2 firmwares types: D2633 and D2620;
AFAIKT, this is related to the demux sensibility: D2633 is normal level, D2620 is lower output level.
In fact I tried to force the load of the D2620 firmwares on my stick but there was no signal.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
also there are 2 completely different files: xc3028-v27.fw and xc3028L-v36.fw.
The v3.6 is for xc3028L (low power). It was reported that using v2.7 on a xc3028L will cause it to overheat.
Thanks for the info.
Quoted 14 lines
Quoted 4 lines
Quoted 4 lines
In my case, my stick uses firmwares of type D2633 from file xc3028-v27.fw; I cannot test anything else. It is also possible that the VHF part of the DTV78 firmware of type D2633 in file xc3028-v27.fw is simply broken.
Maybe. From my remarks, Australia would use only 7MHz firmware on both VHF and UHF bandwidths. B/G countries would use 7/8 MHz. There were several discussions at the ML by the time we've added support for this tuner, and later on. The logs for it can provide some useful info about the changes.
Quoted 4 lines
Quoted 4 lines
As far as I know, this firmware is older than than the first DTT mux in VHF band here in Italy, so maybe it was optimized for analog reception and has never been tested with digital modulations.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
What about a module parameter "alternative-VHF-firmware" which can be either on/off (default=off)?
By default, we keep current behavior; when enabled, DTV7 firmware is always loaded for VHF channels, for all firmware types and files.
Maybe
vhf_firmware, being 0 (default behavior), 6, 7, 8 or 78?
In a simpler way:vhf_firmware = 0 (default, allows 78 under certain conditions), 1 (select 6, 7 or 8 depending on bandwidth);
or with a shorter description:vhf_firmware = 0 (universal), 1 (bandwidth specific);
In the end the problem is not the VHF itself, but the firmware loaded for channels with 7MHz bandwidth. In Europe 7MHz=VHF, but this is may not be the case in the rest of the world.
By the way, in June 2009 Italy adopted the European VHF canalization (GE '06) abandoning the old national canalization (channels D-E-F-G-H-H1-H2). I think this is the new standard in Europe. So I don't see how things can be significantly different in Germany or Spain.
As you pointed to me, in Australia all channels (UHF and VHF) use 7MHz bandwidth, so this explains way nobody is complaining: in this situation the DTV7 is the only firmware ever loaded. And the VHF canalization in Australia seems identical to the European one.
So the patch will never affect Australian users, no matter how they set the module parameter.
It would be great if someone from Germany or Spain could test a device with the xc3028 tuner and give some feedback about VHF reception.
In the meantime I will post a new patch.
Best,
Gianluca
Quoted 240 lines · Gianluca Gennari
Il 07/12/2011 17:21, Mauro Carvalho Chehab ha scritto:
Quoted 177 lines · Gianluca Gennari
Quoted 167 lines
Il 07/12/2011 16:45, Gianluca Gennari ha scritto:
Quoted 166 lines
Il 07/12/2011 16:05, Mauro Carvalho Chehab ha scritto:
Quoted 153 lines · Gianluca Gennari
Quoted 107 lines
Il 07/12/2011 15:20, Mauro Carvalho Chehab ha scritto:
Quoted 69 lines · Gianluca Gennari
Quoted 57 lines
Il 07/12/2011 14:12, Mauro Carvalho Chehab ha scritto:
Quoted 52 lines · Gianluca Gennari
Quoted 20 lines
Hi All,
I have a Terratec Cinergy Hybrid T USB XS stick (USB 0ccd:0042). This device is made of the following components:
- Empiatech em2880 USB bridge;
- Zarlink zl10353 demodulator;
- Xceive XC3028 tuner;For this device, the ZARLINK456 define is set to true so it is using
the
firmwares with type D2633 for the XC3028 tuner.I found out that:
1) the DTV7 firmware works fine in VHF band (bw=7MHz);
2) the DTV8 firmware works fine in UHF band (bw=8MHz);
3) the DTV78 firmware works fine in UHF band (bw=8MHz) but it doesn not
work at all in VHF band (bw=7MHz);Quoted 11 lines
In fact, when the DTV78 firmware is loaded and I try to tune a VHF channel, the frequency lock is ciclically acquired for a second and
immediately lost.
So the proposed patch forces a reload of the DTV7 firmware every time a
7MHz channel is requested.
The only drawback is that channel change from VHF to UHF or viceversa is
slightly slower.
Devices using the D2620 firmwares are unaffected.Hi Gianluca,
The issues with firmware DTV78 x DTV7/DTV8 are old. No matter what we
do,
we end by having troubles, as the issue is Country-dependent. For example,
Australia requires a different firmware than Germany, due to the differences
on the VHF/UHF bands.I prefer if you could work into a patch that would add some modprobe
parameter
to disable the current "autodetection" way, allowing to override the
firmware
used for VHF and UHF.Quoted 3 lines
Thanks,
MauroQuoted 10 lines
Hi Mauro,
thanks for the feedback. Unfortunately I do not have any info on which
kind of firmware is needed on other parts of the world. All I know is
what is happening here in Italy, and what I can understand reading the
code. I suppose my findings can be extended to the rest of Europe, and
maybe Africa and Middle-East.Quoted 2 lines
Even in Europe, there are some differences.
OK, so the validity of my findings are restricted to Italy.
Quoted 10 lines
Quoted 2 lines
Can you provide a reference about problems in other continents like Australia?
All I know is from the constant reports at the ML from users. We used to
have a developer in Australia, but he moved away, and it seems that he lost
interest on DVB development, as we were unable to contact him ever since.Quoted 1 line
Quoted 8 lines
Quoted 3 lines
Do you think a simple module parameters that allows to enable/disable
the usage of the DTV78 firmware would do the trick?Perhaps one or two module parameters to allow forcing a certain firmware
for
VHF and UHF.Seems reasonable.
Quoted 11 lines
Quoted 10 lines
Eventually, do you agree that the default solution should be to DISABLE
DTV78 firmware, since this seems to be the more robust solution, and let
the user enable it through the kernel parameter if it is working in his
country? Or do you prefer the other way around, so by default DTV78 firmware is enabled, and users with problems can disable it through the
kernel module parameter?Quoted 8 lines
Quoted 5 lines
AFAIK, DTV78 should be used in Spain and in Germany. Changing the current
default doesn't look a good idea, as it will cause regressions, if the new
way is not backward-compatible.With the proposed patch DTV78 will be used in UHF band, while DTV7 in VHF band. Will this make any difference in Spain or Germany?
Not sure. I don't live there ;)
Quoted 5 lines
What about a kernel parameter to specify the country? Something like:
country={0-4}
Quoted 7 lines
DEFAULT=0,ITALY=1,GERMANY=2,SPAIN=3,AUSTRALIA=4
Then we could specify a well-defined behavior for each country, hiding the firmware-related problems to the user (which will have problems understanding parameters like force-DTV7-firmware-in-VHF-band).
All I need to know is what is the best behavior for each country.
That's the hardest part ;) We would need someone on each possible Country,
in order to test. Also, a per-country setup like that sucks. Ideally, the
driver should use the bandwidh and the other information at the standard
DVB
parameters, in order to select the right firmware. This works with all other
frontends. Not sure what's broken on xc3028 design that it requires a per-country
hack. I suspect that it is not a pure per-country hack, but it is also per
demod.As we don't have much complains about it nowadays, I assume that the current
behavior is ok for most users. So, a parameter would be used only for those
where the default behavior doesn't work.Quoted 8 lines
Btw, we already have a similar parameter to force the audio demodulation
standard,
due to the same reasons.Regards,
MauroProbably there are no complains about the firmware because in most countries VHF is not used at all, or is only used for marginal TV stations.
Makes sense. Well, it is not hard to detect VHF. If the DTV bandwidth is properly filled, detecting between 8/7/6 MHz is also easy.
Quoted 5 lines
Quoted 5 lines
In Italy instead the main DTT mux (RAI mux 1) is broadcasted in VHF band for historical reasons, so many Italian users are concerned about it. I've already faced problems related to DTT VHF reception, that were never noticed before by users from other countries.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
Moreover, another problem is that there are 2 firmwares types: D2633 and D2620;
AFAIKT, this is related to the demux sensibility: D2633 is normal level, D2620 is lower output level.
In fact I tried to force the load of the D2620 firmwares on my stick but there was no signal.
Quoted 5 lines
Quoted 2 lines
Quoted 2 lines
also there are 2 completely different files: xc3028-v27.fw and xc3028L-v36.fw.
The v3.6 is for xc3028L (low power). It was reported that using v2.7 on a xc3028L will cause it to overheat.
Thanks for the info.
Quoted 14 lines
Quoted 4 lines
Quoted 4 lines
In my case, my stick uses firmwares of type D2633 from file xc3028-v27.fw; I cannot test anything else. It is also possible that the VHF part of the DTV78 firmware of type D2633 in file xc3028-v27.fw is simply broken.
Maybe. From my remarks, Australia would use only 7MHz firmware on both VHF and UHF bandwidths. B/G countries would use 7/8 MHz. There were several discussions at the ML by the time we've added support for this tuner, and later on. The logs for it can provide some useful info about the changes.
Quoted 4 lines
Quoted 4 lines
As far as I know, this firmware is older than than the first DTT mux in VHF band here in Italy, so maybe it was optimized for analog reception and has never been tested with digital modulations.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
What about a module parameter "alternative-VHF-firmware" which can be either on/off (default=off)?
By default, we keep current behavior; when enabled, DTV7 firmware is always loaded for VHF channels, for all firmware types and files.
Maybe
vhf_firmware, being 0 (default behavior), 6, 7, 8 or 78?In a simpler way:
vhf_firmware= 0 (default, allows 78 under certain conditions), 1 (select 6, 7 or 8 depending on bandwidth);
or with a shorter description:vhf_firmware= 0 (universal), 1 (bandwidth specific);In the end the problem is not the VHF itself, but the firmware loaded for channels with 7MHz bandwidth. In Europe 7MHz=VHF, but this is may not be the case in the rest of the world.
By the way, in June 2009 Italy adopted the European VHF canalization (GE '06) abandoning the old national canalization (channels D-E-F-G-H-H1-H2). I think this is the new standard in Europe. So I don't see how things can be significantly different in Germany or Spain.
As you pointed to me, in Australia all channels (UHF and VHF) use 7MHz bandwidth, so this explains way nobody is complaining: in this situation the DTV7 is the only firmware ever loaded. And the VHF canalization in Australia seems identical to the European one.
So the patch will never affect Australian users, no matter how they set the module parameter.
Quoted 4 lines
It would be great if someone from Germany or Spain could test a device with the xc3028 tuner and give some feedback about VHF reception.
In the meantime I will post a new patch.
(C/C Christoph, as he is maintaining the DVB-T tables at both dvb-utils and Kaffeine).
Hmm... looking at w_scan, we see:
switch(txt_to_country(country)) {
//**********DVB freq lists*******************************************//
case AT: // AUSTRIA
case BE: // BELGIUM
case CH: // SWITZERLAND
case DE: // GERMANY
case DK: // DENMARK
case ES: // SPAIN
case GR: // GREECE
case HR: // CROATIA
case HK: // HONG KONG
case IS: // ICELAND
case IT: // ITALY
case LU: // LUXEMBOURG
case LV: // LATVIA
case NL: // NETHERLANDS
case NO: // NORWAY
case NZ: // NEW ZEALAND
case PL: // POLAND
case SE: // SWEDEN
case SK: // SLOVAKIA
switch(*dvb) {
case FE_QAM:
*channellist = DVBC_QAM; info("DVB-C\n");
break;
default:
*channellist = DVBT_DE; info("DVB-T Europe\n");
break;
}
break;
...
case DVBT_AU: //AUSTRALIA, 7MHz step list
switch (channel) {
case 5 ... 12: return 142500000;
case 21 ... 69: return 333500000;
default: return SKIP_CHANNEL;
}
case DVBT_DE: //GERMANY
case DVBT_FR: //FRANCE, +/- offset
case DVBT_GB: //UNITED KINGDOM, +/- offset
switch (channel) {
case 5 ... 12: return 142500000;
case 21 ... 69: return 306000000;
default: return SKIP_CHANNEL;
}...
int freq_step(int channel, int channellist) {
switch (channellist) {
case DVBT_AU: return 7000000; // dvb-t australia, 7MHz step
case DVBT_DE:
case DVBT_FR:
case DVBT_GB: switch (channel) { // dvb-t europe, 7MHz VHF ch5..12, all other 8MHz
case 5 ... 12: return 7000000;
case 21 ... 69: return 8000000;
default: return 8000000; // should be never reached.
}
}
From the above, all w_scan-known European Countries are using 7 MHz/8 MHz, including Italy and Germany.
However, looking at the DVB-T tables at dvb-apps:
$ grep "T [12]" dvb-t/*|grep 8MHz dvb-t/auto-Italy:T 177500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 186000000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 194500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 203500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 212500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 219500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/auto-Italy:T 226500000 8MHz AUTO NONE AUTO AUTO AUTO NONE dvb-t/it-Aosta:T 226500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Catania:T 226500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Firenze:T 219500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Genova:T 219500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Milano:T 184500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Milano:T 191500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Milano:T 219500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Pagnacco:T 226500000 8MHz 3/4 NONE QAM64 8k 1/32 NONE dvb-t/it-Sassari:T 177500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE dvb-t/it-Sassari:# T 177500000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz).
This may explain why, from time to time, we have complaints about tuner-xc2028.
The above bad tables may explain the issue. Are you sure you're using 7MHz for your 7MHz-bandwidth channels?
There is a hack inside tuner-xc2028, in order to allow it to work in Australia:
switch (bw) {
case BANDWIDTH_8_MHZ:
if (p->frequency < 470000000)
priv->ctrl.vhfbw7 = 0;
else
priv->ctrl.uhfbw8 = 1;
type |= (priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ? DTV78 : DTV8;
type |= F8MHZ;
break;
case BANDWIDTH_7_MHZ:
if (p->frequency < 470000000)
priv->ctrl.vhfbw7 = 1;
else
priv->ctrl.uhfbw8 = 0;
type |= (priv->ctrl.vhfbw7 && priv->ctrl.uhfbw8) ? DTV78 : DTV7;
type |= F8MHZ;
break;The idea on the hack is to avoid firmware reload, when the standard changes, e. g. on Countries like Australia where only 7 MHz is used, it will fix the frequency to 7MHz. The same applies to Countries with just 8MHz. Countries that have both 7MHz and 8MHz will load DTV78 firmware after the first switch from 7 to 8 (or from 8 to 7).
I think that the modprobe parameter could be to enable the above hack or to disable it. something like "use_dtv78". If not, then it will just use DTV7 or DTV8, depending if the frequency is 7 or 8 MHz. This will likely slow down a scan with auto-italy, as the driver will need to switch the firmware each time a 8MHz is used for VHF.
Anyway, I think we should fix the Italy tables to remove the bad 8MHz VHF frequencies, if you're sure that there's no city using it anymore.
Regards,
Mauro
Quoted 15 lines · Gianluca Gennari
thanks a lot for the detailed explanation, but it is not needed anymore. I think I got it: reading the comments in the code and in particular a couple of weird "hacks", I think I figured out what is going on.
I have prepared a patch that fixes center frequency adjustment:
basically, this let us get rid of this weird code:if ((priv->cur_fw.type& DTV78)&& freq< 470000000) offset -= 500000;which assumes all channels below 470000000 have 7MHz bw.
Also we can get rid of this adjustment that seems to come out of nowhere:
Quoted 8 lines
if (priv->cur_fw.type& DTV7) offset += 500000;Maybe those hacks where necessary for old firmwares, but the updated ones (a comment mentions updates SCODE tables, whatever this means) seems to use the same center frequency value for all bandwidths and all firmwares (well, at least DTV7, DTV8 and DTV78; we will never know about DTV6).
Old firmwares behave like newer ones, AFAIK. DTV78 is there since at least firmware v2.2.
Quoted 11 lines
I tested this patch with all firmwares:
DTV7 -> OK in VHF band
DTV8 -> OK in UHF band
DTV78 -> OK in both VHF and UHFPlease note also that the patch is not changing anything for DTV7 and DTV8 firmwares. The only thing really affected is the center frequency calculation for DTV78 firmware in VHF band.
What do you think about it?
It makes sense. The offset adjustment should be done based on the bandwidth and if the firmware is either DTV78 or DTV7/DTV8, and not based on the frequency.
Quoted 10 lines
By the way, DVB-T tables from dvb-apps are really outdated, and anyway they are completely useless in Italy. Here we have a jungle of frequencies (about 50 in my area), which are appearing/disappearing/changing some modulation parameter almost every day, and also if you move a few km away you will probably get some different ones.
So no table will be ever up-to-date, and even if it is, it will be only useful to the person who created it. Maybe in a year or two the situation will stabilize (after the switch-off is completed everywhere), but until then it's a mess.
It would be nice to at least fix the auto-italy table, in order for it to match whatever Italy channel frequencies are in use, currently.
Quoted 3 lines
Best regards,
Gianluca
Regards,
Mauro
2011/12/7 Mauro Carvalho Chehab <[email protected]>:
<snip>
Quoted 4 lines
Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is
the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz).
Well, auto-Italy is a superset of the it-* files. For example "T 177500000 7MHz" exists in some files (Modena, Montevergina) and "T 177500000 8MHz" in others (Sassari), so both possibilities have to appear in auto-Italy (similar for other VHF frequencies, it simply doesn't seem to be regulated). There's nothing to fix there, auto-Italy exists exactly because of these irregularities.
<snip>
Christoph
Hi Christoph,
Quoted 7 lines · Christoph Pfister
2011/12/7 Mauro Carvalho Chehab<[email protected]>:
<snip>Quoted 4 lines
Several channels in Italy are marked as if they are using 8MHz for VHF (the auto-Italy is
the most weird one, as it defines all VHF frequencies with both 7MHz and 8MHz).
Quoted 6 lines
Well, auto-Italy is a superset of the it-* files. For example "T 177500000 7MHz" exists in some files (Modena, Montevergina) and "T 177500000 8MHz" in others (Sassari), so both possibilities have to appear in auto-Italy (similar for other VHF frequencies, it simply doesn't seem to be regulated). There's nothing to fix there, auto-Italy exists exactly because of these irregularities.
I see. From Gianluca's email and from w_scan code, I understood that 8 MHz on VHF in Italy is not used there anymore.
If there are places there using 8 MHz, then w_scan requires a fix.
Regards,
Mauro