Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Mark Purcell]

----------  Forwarded Message  ----------

Subject: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for 
London transmitters
Date: Sun, 22 Apr 2012, 13:17:48
From: Russel Winder <russel@winder.org.uk>
To: Darren Salt <linux@youmustbejoking.demon.co.uk>
CC: 669715@bugs.debian.org

The representative of the Amalgamated Union of Philosophers, Sages,
Luminaries, and other professional thinking persons quoth:

On Sun, 2012-04-22 at 03:16 +0100, Darren Salt wrote:
> I demand that Russel Winder may or may not have written...
> 
> > The "digital switch over" (DSO) -- closing of analogue television
> > transmision -- has involved quite a convoluted rearrangement of the
> > multiplexes and channels.  The DSO completed for London, and in my case
> > Crystal Palace, 2012-04-18.  The channel data distributed with dvb-apps is
> > now incorrect.
> 
> You should use w_scan to gather the new information. It would be useful if
> you attach the new tuning information to this bug report.

Not sure about w_scan, I have scan.  It doesn't generate a channel list.

I calculated the following replacement for the uk-CrystalPalace file:

        # UK, Crystal Palace
        #
        # Manually calculated by RLW 2012-04-21T10:20+01:00
        #
        # T freq bw fec_hi fec_lo mod transmission-mode guard-interval
        hierarchy
        #
        # BBC A — 23
        T 490000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
        # D3&4 — 26
        T 514000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
        # BBC B — 30-
        T 545833000 8MHz 2/3 NONE QAM256 2k 1/32 NONE
        # SDN — 25
        T 506000000 8MHz 3/4 NONE QAM64 2k 1/32 NONE
        # Arqiva A — 22
        T 482000000 8MHz 3/4 NONE QAM64 2k 1/32 NONE
        # Arqiva B — 28-
        # ITV4
        T 529833000 8MHz 3/4 NONE QAM64 2k 1/32 NONE

The BBC A, D3&4, SDN, Arqiva A, and Arqiva B frequencies all work fine
with vlc, I get all the channels on the multiplex.  BBC B seems to fail
but I have a suspicion that may be that the TerraTec USB unit I have
does not handle HD.  I am not sure what the NONE entries are, and I am
not sure if the 1/32 is correct.  All other entries come straight from
the OfCom document -- which I assume is definitive.

Running scan I get:

|> scan uk-CrystalPalace_RLW
scanning uk-CrystalPalace_RLW
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 490000000 0 2 9 3 0 0 0
initial transponder 514000000 0 2 9 3 0 0 0
initial transponder 545833000 0 2 9 5 0 0 0
initial transponder 506000000 0 3 9 3 0 0 0
initial transponder 482000000 0 3 9 3 0 0 0
initial transponder 529833000 0 3 9 3 0 0 0
>>> tune to: 
490000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
490000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
>>> tune to: 
514000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
514000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
>>> tune to: 
545833000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_256:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
545833000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_256:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
>>> tune to: 
506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
506000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
>>> tune to: 
482000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
482000000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
>>> tune to: 
529833000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
>>> tune to: 
529833000:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_2K:GUARD_INTERVAL_1_32:HIERARCHY_NONE 
(tuning failed)
WARNING: >>> tuning failed!!!
ERROR: initial tuning failed
dumping lists (0 services)
Done.


> Also, as of 26 September, it'll also be incorrect for Pontop Pike...

Is that the last to go?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

-----------------------------------------

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Andy Furniss]

Mark Purcell wrote:

> Not sure about w_scan, I have scan.  It doesn't generate a channel list.
>
> I calculated the following replacement for the uk-CrystalPalace file:
>
>          # UK, Crystal Palace
>          #
>          # Manually calculated by RLW 2012-04-21T10:20+01:00
>          #
>          # T freq bw fec_hi fec_lo mod transmission-mode guard-interval
>          hierarchy
>          #
>          # BBC A — 23
>          T 490000000 8MHz 2/3 NONE QAM64 2k 1/32 NONE

Transmission mode changed from 2k to 8k in the uk after analogue switch off.

Chris Rankin already posted UK, Crystal Palace on here.

I guess the QAM 256 is T2 not T.


#------------------------------------------------------------------------------
# file automatically generated by w_scan
# (http://wirbel.htpc-forum.de/w_scan/index2.html)
#! <w_scan> 20120112 1 0 TERRESTRIAL GB </w_scan>
#------------------------------------------------------------------------------
# location and provider: Crystal Palace, UK
# date (yyyy-mm-dd)    : 2012-04-18
#
# T[2] [plp_id] [system_id] <freq> <bw> <fec_hi> <fec_lo> <mod> <tm> 
<guard> <hi> [# comment]
#------------------------------------------------------------------------------
T 490000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
T 514000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
T 545833330 8MHz 2/3 NONE QAM256 AUTO AUTO AUTO # London .
T 482000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
T 506000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
T 529833330 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Russel Winder]

[-- Attachment #1: Type: text/plain, Size: 1124 bytes --]

On Sun, 2012-05-13 at 11:15 +0100, Andy Furniss wrote:
[...]
> Transmission mode changed from 2k to 8k in the uk after analogue switch off.

Of course. I just failed to make that change in my files. With that
changed I got some response from gnome-dvb-setup but it only analysed
one multiplex.

> Chris Rankin already posted UK, Crystal Palace on here.
[...]
> T 490000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
> T 514000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
> T 545833330 8MHz 2/3 NONE QAM256 AUTO AUTO AUTO # London .
> T 482000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
> T 506000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
> T 529833330 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .

Should that be 545833000 instead of 545833330, and 529833000 instead of 529833330?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Andy Furniss]

Russel Winder wrote:
> On Sun, 2012-05-13 at 11:15 +0100, Andy Furniss wrote:
> [...]
>> Transmission mode changed from 2k to 8k in the uk after analogue switch off.
>
> Of course. I just failed to make that change in my files. With that
> changed I got some response from gnome-dvb-setup but it only analysed
> one multiplex.
>
>> Chris Rankin already posted UK, Crystal Palace on here.
> [...]
>> T 490000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
>> T 514000000 8MHz 2/3 NONE QAM64 8k 1/32 NONE # London .
>> T 545833330 8MHz 2/3 NONE QAM256 AUTO AUTO AUTO # London .
>> T 482000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
>> T 506000000 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
>> T 529833330 8MHz 3/4 NONE QAM64 8k 1/32 NONE # London .
>
> Should that be 545833000 instead of 545833330, and 529833000 instead of 529833330?
>
Possibly - I think if you calculate by hand from channel number and add 
or take the offset if it it <channel>+ or - then you do get the extra 33.

I don't live in London, but using a slightly newer w_scan for my 
transmitter gave different output from that, with the 330 -> 000.

Maybe it depends on the device, mine was a DVB T2 pctv nanostick and gave -

#------------------------------------------------------------------------------
# file automatically generated by w_scan
# (http://wirbel.htpc-forum.de/w_scan/index2.html)
#! <w_scan> 20120128 1 0 TERRESTRIAL GB </w_scan>
#------------------------------------------------------------------------------
# location and provider: Tacolneston UK
# date (yyyy-mm-dd)    : 2012-03-10
#
# T[2] [plp_id] [system_id] <freq> <bw> <fec_hi> <fec_lo> <mod> <tm> 
<guard> <hi> [# comment]
#------------------------------------------------------------------------------
T 642000000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE      # East Anglia
T 745833000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE      # East Anglia
T 777833000 8MHz  2/3 NONE    QAM64   8k 1/32 NONE      # East Anglia
T 666000000 8MHz  3/4 NONE    QAM64   8k 1/32 NONE      # East Anglia
T 706000000 8MHz  3/4 NONE    QAM64   8k 1/32 NONE      # East Anglia
T2 0 16417 802000000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO     # East 
Anglia

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Russel Winder]

[-- Attachment #1: Type: text/plain, Size: 1132 bytes --]

On Sun, 2012-05-13 at 15:23 +0100, Andy Furniss wrote:
[...]
> > Should that be 545833000 instead of 545833330, and 529833000 instead of 529833330?
> >
> Possibly - I think if you calculate by hand from channel number and add 
> or take the offset if it it <channel>+ or - then you do get the extra 33.

If I remember correctly the OfCom documentation states the +/- offset is
0.166.  Certainly that is what I used for my manual calculation.

> I don't live in London, but using a slightly newer w_scan for my 
> transmitter gave different output from that, with the 330 -> 000.

Where did you get this w_scan command from, I don't seem to have one.

[...]
> T2 0 16417 802000000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO     # East 

I wonder if the 0 and 16417 can be ascertained from OfCom documents?

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Andy Furniss]

Russel Winder wrote:
> On Sun, 2012-05-13 at 15:23 +0100, Andy Furniss wrote:
> [...]
>>> Should that be 545833000 instead of 545833330, and 529833000 instead of 529833330?
>>>
>> Possibly - I think if you calculate by hand from channel number and add
>> or take the offset if it it<channel>+ or - then you do get the extra 33.
>
> If I remember correctly the OfCom documentation states the +/- offset is
> 0.166.  Certainly that is what I used for my manual calculation.

I was told when asking on uk.tech.broadcast that the offset was 167000, 
perhaps, if that's rounded up, then 166670 may also be valid and would 
give the extra 330.

I don't know about ofcom docs but you can get other info if you check 
the "I am in the trade" box and enter your postcode here -

http://www.digitaluk.co.uk/postcodechecker/

for the details you have to hover mouse over channel numbers, and of 
course convert channels to freq. The formula I was told was -

(306 + (N x 8)) x 1000000 then if required +/- 167000

>
>> I don't live in London, but using a slightly newer w_scan for my
>> transmitter gave different output from that, with the 330 ->  000.
>
> Where did you get this w_scan command from, I don't seem to have one.

wirbel.htpc-forum.de/w_scan/index_en.html

To download there is a link at the bottom of the German page which is 
linked to from that page.


>
> [...]
>> T2 0 16417 802000000 8MHz AUTO AUTO     AUTO AUTO AUTO AUTO     # East
>
> I wonder if the 0 and 16417 can be ascertained from OfCom documents?

  I don't have a clue about that.

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Andy Furniss]

Andy Furniss wrote:
> Russel Winder wrote:
>> On Sun, 2012-05-13 at 15:23 +0100, Andy Furniss wrote:
>> [...]
>>>> Should that be 545833000 instead of 545833330, and 529833000 instead
>>>> of 529833330?
>>>>
>>> Possibly - I think if you calculate by hand from channel number and add
>>> or take the offset if it it<channel>+ or - then you do get the extra 33.
>>
>> If I remember correctly the OfCom documentation states the +/- offset is
>> 0.166. Certainly that is what I used for my manual calculation.

I've searched some of my defunct old scan created files and it seems 
that whatever card I used to do that scan generated freqs that ended 330 
- so maybe it's down to the hardware.

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Andrew Benham]

Of course it's not just the data for the London transmitters which needs
to be updated - most of GB has now switched to digital only with
different channel allocations.

I've been using the information from
http://stakeholders.ofcom.org.uk/broadcasting/guidance/tech-guidance/dsodetails/
to derive new data.

I don't know if it's just Crystal Palace, but one of the multiplexes
thinks it's using QPSK even though it's using QAM64 - this messes up
'scan' unless one reorders the frequency list.
Having done the scan, one then needs to replace 'QPSK' by 'QAM_64' in
the output.

See also:
http://www.adsb.co.uk/linuxtv/

-- 
Andrew Benham, Southgate, London N14, United Kingdom

The gates in my computer are AND OR and NOT, not "Bill"

Re: Fwd: Bug#669715: dvb-apps: Channel/frequency/etc. data needs updating for London transmitters

[Thomas Kernen]

On 5/14/12 1:54 PM, Andrew Benham wrote:

> I don't know if it's just Crystal Palace, but one of the multiplexes
> thinks it's using QPSK even though it's using QAM64 - this messes up
> 'scan' unless one reorders the frequency list.
> Having done the scan, one then needs to replace 'QPSK' by 'QAM_64' in
> the output.

I reported the issue through my channels and the issue was fixed earlier 
this evening. The DVB-SI tables have been updated so that now the 
constellation type has been changed from 0 (QPSK) to 2 (64-QAM).

Thomas