Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

TV Aerial Alignment Calculator

1,251 views
Skip to first unread message

Java Jive

unread,
May 7, 2009, 12:35:02 PM5/7/09
to
I've now got a more sophisticated version of the TV Aerial Alignment
Calculator up and running. There's a transmitter list with aerial
heights (and potentially a more complete one with lots of other info
not yet used), 60% and 100% Fresnel zones, and the curvature of the
earth:

http://www.macfh.co.uk/Test/UKTerrestrialTVTest.html

The biggest long term need is for directional information, without
which taking this much further, say to make the overlays I envisaged,
is perhaps of marginal value.

You wouldn't believe the trouble I've had even getting this far,
reconciling around 250 inconsistencies in all the conflicting source
documents from Ofcom - most are small, but too many are major. If
anyone has any knowledge of the particular dozen or so numbered
problems which follow, any help gratefully received.

1) There is still a conflict of information for Rosneath:

http://www.ofcom.org.uk/tv/ifi/tech/dsodetails/81plan.pdf
Rosneath NS258811
PSB Muxes COM Muxes ERP Aerial
54 58 61 53 57 60 2 C/DH
54 58 61 53 57 60 0.008 C/DV

In addition to the main horizontally polarised signals at 2kW, the
Rosneath transmitter will also broadcast a separate beam at 0.008kW
vertically polarised. This is intended to improve reception in
Rosneath itself.

http://www.ofcom.org.uk/tv/ifi/tech/dsodetails/stvcentralreg.pdf
Rosneath NS258811
PSB Muxes COM Muxes ERP Aerial
54 58 61 53 57 60 8W C/DH
54 58 61 53 57 60 2kW C/DV

Which way round is correct? The explanation above suggests that it
must be the first doc, but the second is 13 months more recent.

2) Aberbeeg, SO217030, SO215029 - neither location seems to have
mast either visible on satellite photo or marked on OS map, but
there's one across the valley at SO225023 both visible and marked.
Where exactly is the mast?

3) Beddgelert SH582476, Beddgelert Link SH592490 - two different
sites, one SW of the village the other NE, or just one? To the NE
there appears to be a small mast like structure visible at SH592490,
while nothing is visible to the SE. Neither are marked on OS maps.
Where exactly is/are the mast(s)?

4) Bleachgreen, NX984197, NX984199 - latter is there but not marked
on OS, but there's another at NX987187 which is. Is this second mast
relevant to TV?

5) Brockwell, SK367707, SK373707 - no mast visible or marked on OS
at either location, or even nearby. Where exactly is the mast?

6) Bronnant, SN664661, SN664664 - no mast visible or marked on OS
at either location, or even nearby. Where exactly is the mast?

7) Propsed new TX at Budleigh Salterton. Does anyone know the
proposed antenna height AOD?

8) Catrine, NS529255, NS528255 - first is there, but there's
another at NS533252, both on OS. Is this at all relevant to TV?

9) Glenridding, NY395172, NY386184 - no mast visible or marked on
OS at either location, or even nearby. Where exactly is the mast?

10) Lochgoilhead NS196977, Lochgoilhead AD NS190977 - two different
sites, or just one? There is actually a mast marked on OS at
NS196977, and NS190977 could easily be a misread for that (hand
written '0' for '6'). However, there is nothing really visible in
satellite views there or at any of the specified locations, though
there is something resembling a mast further south along the same road
at NS194972, but this is not marked on the OS map nor is this NGR
mentioned in Ofcom documentation. Where exactly is the mast?

11) Manchester Hulme. Does anyone know the antenna height AOD?

12) Scoval, NG180516, NG181514, according to the OS 2 transmitters
very close to one another, though actually at NG182514 and NG181517,
satellite pictures are too poor to help. Is it correct that both are
used for TV transmissions, and if so which mast is used for which
transmissions, or is only one used for TV, and if so, which?

13) Strathyre Link NN581171 & NN581170, according to OS correct NGR is
actually NN582171, and Strathyre, NN559171 & NN559170. According to
OS, there is no mast at the latter and satellite pictures are too poor
to tell. Two sites or which one?

The following further minor inconsistencies occur. On the whole, I've
been able to get round these programmatically, and there probably
perhaps another 15-30 that won't show up because, before I realised
just how many would be required, I spent quite some time hand editing
corrections.

Phew ... Can I have a pint now?

Same names, different NGRs:
Aberdare,SO034012,SO034013
Aberfoyle,NS523991,NS523990
Abertridwr,ST123886,ST123885
Addingham,SE076492,SE075492
Ardentinny,NS186864,NS186863
Arisaig,NM699873,NM669873
Ashbourne,SK182460,SK181460
Auchmore Wood,NH484502,NH483501
Avening,ST880975,ST881975
Ayr South,NS354187,NS355188
Bala,SH969375,SH968375
Ballachulish,NN059593,NN059592
Bampton,SS966237,SS966236
Bellanoch,NR803919,NR804920
Betws-y-Coed,SH825582,SH824582
Black Hill,NS828647,NS831645, real location seems to be NS829648
Blackburn,SD703276,SD703275
Blackmill,SS930867,SS930866
Blaenplwyf,SN569757,SN569756
Bolehill,SK295552,SK294553
Borve,NF648019,NF648018
Bridge of Allan,NS793985,NS792985
Bridgnorth,SO719913,SO719914
Bromsgrove,SO947730,SO948730
Burrington,ST477606,ST477605
Buxton,SK060753,SK059753
Callander,NN670064,NN671063
Canongate,NT263736,NT264736
Cathcart,NS566615,NS565616
Cerne Abbas,ST645012,ST645013
Chalford,SO883017,SO882017
Chilfrome,SY580991,SY579991
Coleford,SO569107,SO569106
Collafirth Hill,HU335835,HU335834
Compton,SX495563,SX495564
Conisbrough,SK516981,SK516980
Copley,SE080223,SE081223
Countisbury,SS749501,SS748500
Crickhowell,SO207202,SO206202
Crieff,NN814200,NN814199
Croeserw,SS858952,SS857952
Crosby Ravensworth,NY619152,NY618152
Crucorney,SO323221,SO323222
Cupar,NO378139,NO377139
Daliburgh,NF736216,NF735217
Dalton,SD230745,SD229745
Dawlish,SX950772,SX951772
Dollar,NS951984,NS950984
Dronfield,SK362791,SK363791
Durris,NO763899,NO764899
Easter Compton,ST567830,ST566830
Ewyas Harold,SO389269,SO390269
Fenton,SJ902451,SJ903451
Ferndale,ST006970,ST006969
Fetlar,HU589914,HU588913, first is correct
Fitful Head,HU347136,HU346135
Fiunary,NM602468,NM603468
Fodderty,NH512606,NH511606
Fort Augustus,NH361049,NH360049
Frome,ST778482,ST778481
Garelochhead,NS235919,NS235918
Gartley Moor,NJ547326,NJ546326
Glasgow West Central,NS565683,NS565682
Grangemouth,NS921796,NS921795
Gravelly Hill,SP109897,SP109899, second is correct
Grimsby,TA280091,TA279090
Gronant,SJ089833,SJ088833
Hagg Wood,SE148105,SE149105
Halifax,SE103242,SE102241
Haltwhistle,NY674628,NY674627
Hamstead,SP043931,SP044931
Harbertonford,SX780559,SX781559
Harborne,SP017836,SP016836
Haverfordwest,SN029262,SN028261
Hemel Hempstead,TL088045,TL087044
Hereford,SO524364,SO524365
Holmfield,SE089295,SE089294
Hope,SK170830,SK169829
Idle,SE163374,SE164374
Ilfracombe,SS507465,SS507464
Keelylang Hill,HY377102,HY378102
Keighley,SE068443,SE069444
Kettlewell,SD986680,SD987680
Killearn,NS483848,NS484848
Kilmelford,NM818101,NM816100, real location is NM816101
Kilvey Hill,SS671940,SS672940
Kingskerswell,SX873681,SX872682
Kington,SO290553,SO290552
Kinlochleven,NN178630,NN178629
Kirkconnel,NS745150,NS745149
Ladder Hill,SK027789,SK027788
Lairg,NC574056,NC573056
Langholm,NY358830,NY358831
Largs,NS208594,NS209594
Leicester,SK584033,SK585033
Lindores,NO251159,NO250158
Llandderfel,SH990359,SH990358
Llanddona,SH583810,SH582810
Llanharan,SS998831,SS998832
Llanhilleth,SO213004,SO213003
Llwyn Onn,SH625175,SH625174
Lochmaddy,NF950727,NF951727
Lydgate,SD933253,SD932253
Machynlleth,SH724004,SH723003
Maentwrog,SH656406,SH656407
Maesteg,SS841913,SS841912
Marystow,SX437829,SX435828
Merthyr Tydfil,SO057066,SO057065
Millthrop,SD659926,SD658926
Moffat,NT077050,NT078050
Monmouth,SO526128,SO526127
Mottram In Longdendale,SJ987962,SJ988961
Mynydd Bach,ST168925,ST168926
North Oldham,SD928059,SD928060
Ogbourne St George,SU205732,SU205731
Oxenhope,SE029338,SE028338
Pendle Forest,SD825383,SD825384
Penifiler,NG489417,NG489416
Pennorth,SO103266,SO103267
Perry Beeches,SP067932,SP066932
Pitlochry,NN923565,NN923564
Plympton,SX530555,SX531555
Plympton,SX531555,SX530555
Pontypridd,ST085905,ST084904
Port Ellen,NR338452,NR339452
Porthtowan,SW694478,SW695478
Ravenstonedale,NY733047,NY733048
Redbrook,SO538093,SO538092
Redruth,SW690394,SW690395
Rhayader,SN985701,SN985702
Rhymney,SO127042,SO127043
Ripponden,SE043186,SE043188, latter is correct
Risca,ST240905,ST240906
Rosehearty,NJ934663,NJ933663
Rosemarkie,NH761622,NH762623
Rugeley,SK034179,SK034178
Saddleworth,SD987049,SD987050
Salcombe,SX753398,SX753397
Shatton Edge,SK194814,SK194813
Skipton,SD909517,SD908516
South Brent,SX690607,SX690608
Stanton Moor,SK246637,SK245637
Tarbert,NR858679,NR857680
Tedburn St Mary,SX831941,SX830941
The Wrekin,SJ628082,SJ629082
Tideswell Moor,SK149780,SK150780
Tighnabruaich,NR993745,NR993743, real location is NR994744
Tillicoultry,NS925971,NS925970
Torosay,NM703357,NM703358
Trebanog,ST020907,ST020906
Troon,NS324315,NS324314
Tunbridge Wells,TQ607440,TQ607439
Ubley,ST539594,ST538594
Uplawmoor,NS437563,NS436563
Van Terrace,ST169864,ST168864
Voe,HU408634,HU409634
Walsden,SD927235,SD927234
Washford,ST058410,ST058409
Weisdale,HU379513,HU379512
Wenvoe,ST110741,ST110742
West Kilbride,NS215483,NS214483
West Linton,NT164508,NT164507
Westwood,ST817597,ST816597
Whaley Bridge,SK010815,SK011815
Wheatley,SE068264,SE068265
Whitworth,SD886203,SD886202
Widecombe In The Moor,SX725754,SX725753
Wrexham Rhos,SJ301537,SJ300537

Same NGRs, different names:
Ashford-in-Water,Ashford in the Water,SK189691
Bretch Hill,Bretch Hill BBC2,SP438400
Brierley Hill,Brierley Hill PSB,SO916856
Bristol Kings Weston Hill,Bristol King's Weston,Bristol Kings
Weston,ST547775
Caldbeck,Caldbeck (Scottish),NY299425
Charlbury,Charlbury BBC1,SP344197
Cwm Twrch,Cwmtwrch,SN760106
Cwmgors,Cwm-gors,SN705123
Douglas (IoM),Douglas,SC373746
Dychliemore,Dychliemore Link,NN138238
Edgebaston,Edgbaston,SP058851
Efail Fach,Efail-fach,SS786958
Eitshal (Lewis),Eitshal,NB305303
Glenmaye (IoM),Glenmaye,SC232803
Kilbride (S. Uist),Kilbride South Uist,NF752148
Kilmacolm,Kilmalcom,NS343691
Kimmeragh (IoM),Kimmeragh,NX450000
Kirkcudbright,Kirkudbright,NX686506
Knock More,Knockmore,NJ321497
Llanarmon-yn-Ial,Llanarmon-yn-i�l,SJ194582
Llangranog,Llangrannog,SN322538
Llanrhaeadr ym Mochnant,Llanrhaeadr-ym-Mochnant,SJ174260
Moel-Y-Parc,Moel y Parc,Moel-y-Parc,SJ123701
Montpelier,Bristol Montpelier,ST590745
Mynydd Pencareg,Mynydd Pencarreg,SN577430
Nant-Y-Moel,Nant-y-Moel,SS934935
Netherton Braes,Netherton Brae,NS581575
Norwich (Central),Norwich,TG237098
Olivers Mount,Oliver's Mount,TA040869
Over Norton,Over Norton BBC2,SP309282
Penicuik,Penicuick,NT252590
Port St Mary (IoM),Port St Mary,SC206678
Presely,Preseli,SN172306
Rampisham,Rampisham UHF,ST544008
Ridge Hill,Ridge Hill West,SO630333
Ross-on-Wye,Ross On Wye,SO605243
Sedbergh,Sedburgh,SD607879
Skriaig (Skye),Skriaig,NG451408
Storeton,Storeton Wales,SJ314841
Stranraer,Stanraer,NX111632
Sutton Coldfield,Sutton Coldfield PSB,SK113003
Sutton-Craven,Sutton in Craven,SE004428
Swinster,Swinister,HU440727
Tarbert (Harris),Tarbert Harris,NB154001
Tenburywells,Tenbury Wells,SO588691
Ton Pentre,Tonpentre,SS960955
Union Mills (IoM),Union Mills,SC343769
Walton-Le-Dale,Walton Le Dale,SD545291
Weston Mill,Plymouth Weston Mill,SX454574

======================================

Please always reply to news group as the email address in
this post's header does not exist. Alternatively, use the
contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html

ne...@address.invalid

unread,
May 7, 2009, 1:18:28 PM5/7/09
to
On Thu, 07 May 2009 17:35:02 +0100, Java Jive <ja...@evij.com> wrote:

>The biggest long term need is for directional information, without
>which taking this much further, say to make the overlays I envisaged,
>is perhaps of marginal value.
>
>You wouldn't believe the trouble I've had even getting this far,
>reconciling around 250 inconsistencies in all the conflicting source
>documents from Ofcom - most are small, but too many are major. If
>anyone has any knowledge of the particular dozen or so numbered
>problems which follow, any help gratefully received.
>

Remember that Ofcom are only retailing location data given to them by
planners from the two different groups that originally built them.

In many cases the NGR's changed slightly between the original site
survey, planning approval and final installation, and the change may
not always have been considered significant to pass on.
With NGR's the convention is to define the bottom-left corner of the
square containing the site, rather than the *nearest* corner, so the
quoted location for a four-figure NGR100m grid could in theory up to
141m from the actual point. However I believe that this rule may not
have been adhered to in all cases.
It's after my time, but I suspect that the mast locations used for
official predictions are now recorded much more accurately, since the
available topographical databases are now much detailed than
previously.

For your purposes the location 'error' is not really significant since
at any distance from the site the calculated bearing error will be far
less than manual compass errors at the receiving site. And the SRTM
database you will use for coverage is not much better than the errors
from the published locations.

For sites 3) and 13) you can ignore the 'link' sites since these are
intended to feed the relay rather than provide broadcast coverage.
There might be a very few isolated viewers looking directly at the
link tx but they will already have been sorted without recourse to
your facility.

charles

unread,
May 7, 2009, 1:45:35 PM5/7/09
to
In article <874605li5qeolegmk...@4ax.com>,

<ne...@address.invalid> wrote:
> On Thu, 07 May 2009 17:35:02 +0100, Java Jive <ja...@evij.com> wrote:

> >The biggest long term need is for directional information, without
> >which taking this much further, say to make the overlays I envisaged,
> >is perhaps of marginal value.
> >
> >You wouldn't believe the trouble I've had even getting this far,
> >reconciling around 250 inconsistencies in all the conflicting source
> >documents from Ofcom - most are small, but too many are major. If
> >anyone has any knowledge of the particular dozen or so numbered
> >problems which follow, any help gratefully received.
> >

> Remember that Ofcom are only retailing location data given to them by
> planners from the two different groups that originally built them.

> In many cases the NGR's changed slightly between the original site
> survey, planning approval and final installation, and the change may
> not always have been considered significant to pass on.
> With NGR's the convention is to define the bottom-left corner of the
> square containing the site, rather than the *nearest* corner, so the
> quoted location for a four-figure NGR100m grid could in theory up to
> 141m from the actual point. However I believe that this rule may not
> have been adhered to in all cases.

at one point, the IBA planners tended to "round up". Also a number of
masts were rebuilt to carry mobile phones and may have moved into the next
grid square as a result.

--
From KT24 - in "Leafy Surrey"

Using a RISC OS computer running v5.11

Java Jive

unread,
May 7, 2009, 1:52:09 PM5/7/09
to
On Thu, 07 May 2009 18:18:28 +0100, ne...@address.invalid wrote:
>
> In many cases the NGR's changed slightly ...

Yes, programmatically, I've gone for pre-DSO digital and/or post DSO
ones on the grounds that they are probably more recent and therefore
likely to be more accurate. Then where there was more than 1 digit
difference in either E or N or both, I've tried to locate the mast
myself using OS maps or satellite photos (using my own page, in fact)

> For your purposes the location 'error' is not really significant since
> at any distance from the site the calculated bearing error will be far
> less than manual compass errors at the receiving site. And the SRTM
> database you will use for coverage is not much better than the errors
> from the published locations.

Yes, I'd realised that, but the problem is that I need
programmatically to identify each site uniquely and precisely, for
example to avoid duplicate transmitter records, where one has the
analogue data, another the pre-DSO digital data, perhaps even a third
with the post-DSO data! The obvious thing to use as an index is the
NGR, hence the need to resolve ambiguities and duplicates.

> For sites 3) and 13) you can ignore the 'link' sites since these are
> intended to feed the relay rather than provide broadcast coverage.
> There might be a very few isolated viewers looking directly at the
> link tx but they will already have been sorted without recourse to
> your facility.

Great, thanks for that.

Regards

Peter Crosland

unread,
May 7, 2009, 2:02:49 PM5/7/09
to
A real technical tour de force that you are to be congratulated on. Thank
you!


Peter Crosland


ne...@address.invalid

unread,
May 7, 2009, 2:19:34 PM5/7/09
to
I notice your NGR/ lat-long conversions are a little in error,
although not seriously so compared to the other variables. It's not
clear from your notes exactly which of the many coordinate conversions
you have used but you might like to check your results against
http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp

particularly for sites in the far north and far south-west where most
conversions tend to be least accurate.

The OS site uses the definitive OSTN02 transform. There is a matching
transform for Irish coordinates at
http://www.osi.ie/en/alist/co-ordinate-converter-tool.aspx

You can download the required software FOC.

Mark Carver

unread,
May 7, 2009, 2:55:48 PM5/7/09
to
Java Jive wrote:

> Rosneath


> Which way round is correct? The explanation above suggests that it
> must be the first doc, but the second is 13 months more recent.

Current transmissions have the main 10kW beam as VP, so I'd go with the higher
power 2kW DTT beam post DSO as being VP too.

>
> 2) Aberbeeg, SO217030, SO215029 - neither location seems to have
> mast either visible on satellite photo or marked on OS map, but
> there's one across the valley at SO225023 both visible and marked.
> Where exactly is the mast?

Do these pics etc help ?

http://tx.mb21.co.uk/gallery/aberbeeg.php

>
> 3) Beddgelert SH582476, Beddgelert Link SH592490 - two different
> sites, one SW of the village the other NE, or just one? To the NE
> there appears to be a small mast like structure visible at SH592490,
> while nothing is visible to the SE. Neither are marked on OS maps.
> Where exactly is/are the mast(s)?

http://tx.mb21.co.uk/gallery/beddgelert.php

http://tx.mb21.co.uk/gallery/beddgelert-link.php

>
> 4) Bleachgreen, NX984197, NX984199 - latter is there but not marked
> on OS, but there's another at NX987187 which is. Is this second mast
> relevant to TV?

http://tx.mb21.co.uk/gallery/bleachgreen.php

>
> 5) Brockwell, SK367707, SK373707 - no mast visible or marked on OS
> at either location, or even nearby. Where exactly is the mast?

It moved, see

http://tx.mb21.co.uk/gallery/brockwell.php


> 7) Propsed new TX at Budleigh Salterton. Does anyone know the
> proposed antenna height AOD?

Site is 96 metres, aerial height est at 30. AOD about 125-130 ?

http://tx.mb21.co.uk/gallery/budleigh-salterton.php

>
> 9) Glenridding, NY395172, NY386184 - no mast visible or marked on
> OS at either location, or even nearby. Where exactly is the mast?

http://tx.mb21.co.uk/gallery/glenridding.php


>
> 10) Lochgoilhead NS196977, Lochgoilhead AD NS190977 - two different
> sites, or just one? There is actually a mast marked on OS at
> NS196977, and NS190977 could easily be a misread for that (hand
> written '0' for '6'). However, there is nothing really visible in
> satellite views there or at any of the specified locations, though
> there is something resembling a mast further south along the same road
> at NS194972, but this is not marked on the OS map nor is this NGR
> mentioned in Ofcom documentation. Where exactly is the mast?

Mb21 says 194978

http://tx.mb21.co.uk/gallery/lochgoilhead.php

>
> 11) Manchester Hulme. Does anyone know the antenna height AOD?

Self Help that carries C5 only. Will cease at DSO

http://www.ofcom.org.uk/consult/condocs/selfhelp/selfhelp.pdf (see last page)


>
> 12) Scoval, NG180516, NG181514, according to the OS 2 transmitters
> very close to one another, though actually at NG182514 and NG181517,
> satellite pictures are too poor to help. Is it correct that both are
> used for TV transmissions, and if so which mast is used for which
> transmissions, or is only one used for TV, and if so, which?

http://tx.mb21.co.uk/gallery/scoval.php


>
> 13) Strathyre Link NN581171 & NN581170, according to OS correct NGR is
> actually NN582171, and Strathyre, NN559171 & NN559170. According to
> OS, there is no mast at the latter and satellite pictures are too poor
> to tell. Two sites or which one?

http://tx.mb21.co.uk/gallery/strathyre.php

Nice work JJ, go and grab that pint !


--
Mark
Please replace invalid and invalid with gmx and net to reply.

www.paras.org.uk

ne...@address.invalid

unread,
May 7, 2009, 2:59:12 PM5/7/09
to
On Thu, 07 May 2009 18:45:35 +0100, charles
<cha...@charleshope.demon.co.uk> wrote:

>In article <874605li5qeolegmk...@4ax.com>,
> <ne...@address.invalid> wrote:

>> With NGR's the convention is to define the bottom-left corner of the
>> square containing the site, rather than the *nearest* corner, so the
>> quoted location for a four-figure NGR100m grid could in theory up to
>> 141m from the actual point. However I believe that this rule may not
>> have been adhered to in all cases.
>

>at one point, the IBA planners tended to "round up".

Yes, that is what I was referring to :)

>Also a number of
>masts were rebuilt to carry mobile phones and may have moved into the next
>grid square as a result.

A few did yes. Many more had the mast extended to accommodate cellular
aerials, pushing up the TV aerial and increasing its service area. One
Rowridge relay seems to grow taller every time I pass it.

Java Jive

unread,
May 7, 2009, 3:02:07 PM5/7/09
to
On Thu, 07 May 2009 19:19:34 +0100, ne...@address.invalid wrote:

> I notice your NGR/ lat-long conversions are a little in error,
> although not seriously so compared to the other variables. It's not
> clear from your notes exactly which of the many coordinate conversions
> you have used

I am just using standard proj4 conversion ...

http://proj4js.org

... by pulling in ...

http://proj4js.org/lib/proj4js-compressed.js

... and defining ...

Proj4js.defs["EPSG:27700"] = "+proj=tmerc +lat_0=49 +lon_0=-2
+k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +datum=OSGB36
+units=m +no_defs ";

... for UKNG

> but you might like to check your results against
> http://gps.ordnancesurvey.co.uk/etrs89geo_natgrid.asp
> particularly for sites in the far north and far south-west where most
> conversions tend to be least accurate.

Think I know what may be coming next ...



> The OS site uses the definitive OSTN02 transform. There is a matching
> transform for Irish coordinates at
> http://www.osi.ie/en/alist/co-ordinate-converter-tool.aspx
>
> You can download the required software FOC.

:-) Thought so.

I've actually downloaded it. Thinking it would be needed, I
translated their spreadsheet macros into javascript, ran their test
results through it, and, once I'd got the bugs out, I ended up with 2
locations, GLAS & LEED I think, that differed in the last digit (a few
mms). Naturally I thought my programming was still at fault, but
tracing through the interim results, they agreed up to the last
conversion. So I took my last interim result and put it through their
spreadsheet, and got my final result, not theirs. At this point I
contacted OS, "Is there an error in your results, I think there might
be". After the inevitable "you don't know anything" response (I was
apparently the first person to query them in years of use), a very
helpful gut did concede that it was a genuine anomaly, probably due to
a combination the different accuracy of different
programming/scripting languages before the results were rounded, and
of no consequence. I'm not entirely happy with that, as the different
languages should be more accurate by orders of magnitude, but I felt
I'd done my duty by letting them know, they seemed happy, and a few
mms is not relevant to my work, so I let it rest.

But to return to your point, if you are using the NGR readout on my
site, I unthinkingly set that to round rather than use the 'floor'
value, which may account for some of it. Also, the proj4 conversion
doesn't use the NGR 'rubber sheet', but, IIRC, I think that could only
account for a few metres (12 springs to mind)?

If you'd let me know just how you're deducing this, I might be able to
explain further, or perhaps may need to correct something.

Java Jive

unread,
May 7, 2009, 3:05:26 PM5/7/09
to
(Blushing with maidenly modesty) "Why, thank you kind sir" and such a
change from the remarks of some others in other threads!

Here's hoping that people find it useful.

On Thu, 7 May 2009 19:02:49 +0100, "Peter Crosland"
<g6...@yahoo.co.uk> wrote:

> A real technical tour de force that you are to be congratulated on. Thank
> you!

======================================

Mark Carver

unread,
May 7, 2009, 3:09:38 PM5/7/09
to
Mark Carver wrote:

>> 11) Manchester Hulme. Does anyone know the antenna height AOD?
>
> Self Help that carries C5 only. Will cease at DSO

No scrub that, I can't read. It will continue post DSO, but sorry can't locate
any antenna height data.

Java Jive

unread,
May 7, 2009, 3:18:01 PM5/7/09
to
(drily) An unfortunate typo ... no reference to the physical
appearance of the GUY should be deduced, as we were communicating via
email :-)

On Thu, 07 May 2009 20:02:07 +0100, Java Jive <ja...@evij.com> wrote:
>
> a very
> helpful gut did concede

======================================

Java Jive

unread,
May 7, 2009, 3:20:31 PM5/7/09
to
Ah well, thanks for trying Mark, and the Rosneath pointer as well ...

On Thu, 07 May 2009 20:09:38 +0100, Mark Carver
<mark....@invalid.invalid> wrote:

> Mark Carver wrote:
>
> >> 11) Manchester Hulme. Does anyone know the antenna height AOD?
> >
> > Self Help that carries C5 only. Will cease at DSO
>
> No scrub that, I can't read. It will continue post DSO, but sorry can't locate
> any antenna height data.

======================================

Brian Gaff

unread,
May 7, 2009, 3:21:43 PM5/7/09
to
This all brings back bad memories from when I used to be on the EBU mailing
lists for transmitter information books.

So often their co-ordinates and powers were wrong in the UK, goodness knows
what it must have been like for stations in Eastern Europe.

shudder.

Brian

--
Brian Gaff....Note, this account does not accept Bcc: email.
graphics are great, but the blind can't hear them
Email: bri...@blueyonder.co.uk
______________________________________________________________________________________________________________


<ne...@address.invalid> wrote in message
news:874605li5qeolegmk...@4ax.com...

Phil

unread,
May 7, 2009, 3:30:06 PM5/7/09
to

Manchester Hulme is at SJ829966 or 2W15, 53N28 (sorry about the poor
resolution). Site height 30m, ant ht 33m.

The profile plotter looks very good. At first I thought you had
forgotten earth curvature, but I tried a long distance one and it was
there. Virtually the same as the one I've got.

Phil

ne...@address.invalid

unread,
May 7, 2009, 3:37:26 PM5/7/09
to
On Thu, 07 May 2009 20:02:07 +0100, Java Jive <ja...@evij.com> wrote:

>
>But to return to your point, if you are using the NGR readout on my
>site, I unthinkingly set that to round rather than use the 'floor'
>value, which may account for some of it. Also, the proj4 conversion
>doesn't use the NGR 'rubber sheet', but, IIRC, I think that could only
>account for a few metres (12 springs to mind)?
>

I was doing a simple comparison between your site and my GIS which
uses OSTN02. No doubt your access records will show which locations I
chose!
You are quite correct about the extent of the errors using just the
basic transform. The worst will be about 14m up in the Shetlands and
8m in Cornwall, which as I said are much less than the other errors
you have to cope with, e.g. site locations.

I must admit to being sceptical at the start about your chances of
success, and you still have some of the most difficult problems to
overcome, but you have certainly approached this is a very
professional manner so far. Keep it up!

ne...@address.invalid

unread,
May 7, 2009, 3:48:29 PM5/7/09
to
On Thu, 07 May 2009 19:21:43 GMT, "Brian Gaff"
<Bri...@blueyonder.co.uk> wrote:

>This all brings back bad memories from when I used to be on the EBU mailing
>lists for transmitter information books.
>
>So often their co-ordinates and powers were wrong in the UK, goodness knows
>what it must have been like for stations in Eastern Europe.
>
>shudder.

You have to remember that where international coordination is
concerned, you get into the realm of politics. Often the clearances
sought are something different to what is actually needed, e.g. in
order to reserve capacity for possible future developments. These
clearances then get written up as actual services. I've seen
non-existent transmitters in those books.


Java Jive

unread,
May 7, 2009, 3:49:10 PM5/7/09
to
On Thu, 07 May 2009 20:30:06 +0100, Phil <spam...@freeserve.co.uk>
wrote:

>
> Manchester Hulme is at SJ829966 or 2W15, 53N28 (sorry about the poor
> resolution). Site height 30m, ant ht 33m.

Great, that's one of the two missing heights down (and the other's not
in service yet)



> The profile plotter looks very good. At first I thought you had
> forgotten earth curvature, but I tried a long distance one and it was
> there. Virtually the same as the one I've got.

It's probably not exactly the same because the bottom of the vertical
scale may be missing. The scale goes not from 0, in which case the
whole curvature would be visible, but from the lowest point of the
terrain or of the Fresnel zone, whichever is lower. This is done to
differentiate the differences in terrain height as much as possible in
the available space, but it means that sometimes the curvature only
appears in the middle, or is not visible at all. Nevertheless, it's
calculated for in all cases, using the 4/3 adjustment that I
understand is standard procedure for this purpose.

Java Jive

unread,
May 7, 2009, 3:59:44 PM5/7/09
to
On Thu, 07 May 2009 20:37:26 +0100, ne...@address.invalid wrote:

> On Thu, 07 May 2009 20:02:07 +0100, Java Jive <ja...@evij.com> wrote:
>
> I was doing a simple comparison between your site and my GIS which
> uses OSTN02. No doubt your access records will show which locations I
> chose!

But I won't necessarily know which visitor you were. To help me
decide how important this is, what was the maximum error you
encountered?

> You are quite correct about the extent of the errors using just the
> basic transform. The worst will be about 14m up in the Shetlands and
> 8m in Cornwall, which as I said are much less than the other errors
> you have to cope with, e.g. site locations.

Yes, 'rubber sheet' errors aren't really an issue in this context, or
even with the greater accuracy required for satellite dish alignment.

> I must admit to being sceptical at the start about your chances of
> success, and you still have some of the most difficult problems to
> overcome, but you have certainly approached this is a very
> professional manner so far. Keep it up!

Again, thanks for the positive response, particularly welcome from
someone who was sceptical. But you're right about it being relatively
easy so far, I'll look to you to tell me, nicely of course, if I f*k
up in future :-)

ne...@address.invalid

unread,
May 7, 2009, 5:39:29 PM5/7/09
to
On Thu, 07 May 2009 20:59:44 +0100, Java Jive <ja...@evij.com> wrote:

>But I won't necessarily know which visitor you were. To help me
>decide how important this is, what was the maximum error you
>encountered?
>

The two sites I checked were 6 and 12 metres different from OSTN02.

Java Jive

unread,
May 7, 2009, 7:45:45 PM5/7/09
to
Now corrected the NGR coordinate readout, and working to resolve TX
data from the wonderfully helpful (not to mention encouraging)
replies.

Wrt Beddgelert Link ...

On Thu, 07 May 2009 17:35:02 +0100, Java Jive <ja...@evij.com> wrote:
>
> 3) Beddgelert SH582476, Beddgelert Link SH592490 - two different
> sites, one SW of the village the other NE, or just one? To the NE
> there appears to be a small mast like structure visible at SH592490,
> while nothing is visible to the SE. Neither are marked on OS maps.
> Where exactly is/are the mast(s)?

Now that I know there are actually two TXs, I may as well try and
accommodate both, but I need the aerial height AOD for Beddgelert
Link. I'm pretty certain it's not on the web.

The site height reads off the map as 188m

Can anyone qualified take a look at the photos on ...
http://tx.mb21.co.uk/gallery/beddgelert-link.php
... and make an educated guess at the transmitting antenna height
above ground, using as a yardstick perhaps the height of the
fence-posts, anti-personell railings at the foot of the mast, or
anything else of dimensions known to them?

TIA

Phil

unread,
May 8, 2009, 6:08:50 AM5/8/09
to

Beddgelert Link is just an active deflector of Blaenplwyf. NGR is
SH59224903, site ht 190m, ant ht 3m.

Phil

res...@gmail.com

unread,
May 8, 2009, 8:08:04 AM5/8/09
to
On 7 Maj, 19:52, Java Jive <j...@evij.com> wrote:
> ....

Do you know this page
http://bbs.keyhole.com/ubb/ubbthreads.php?ubb=showflat&Number=916321&page=1

and the Google kmz file
Transmitter_Sites_090317a.kmz

Lars :)

Java Jive

unread,
May 8, 2009, 9:51:19 AM5/8/09
to
On Thu, 07 May 2009 20:30:06 +0100, Phil <spam...@freeserve.co.uk>
wrote:
>
> Manchester Hulme is at SJ829966 or 2W15, 53N28 (sorry about the poor
> resolution). Site height 30m, ant ht 33m.

Ah, now I realise that's yet another name clash:

Station Name BBC1 BBC2 ITV Channel 4 ERP Aerial Group
Polarity Site Number Landlord NGR Aerial Height AOD BBC
Region
Hulme 51 44 41 47 10W B V 103.28 Arq SJ829966 101 North
West

Site Name NGR BBC A Ch BBC A ERP D3&4 Ch D3&4 ERP BBC B Ch
BBC B ERP DSO Aerial Group Pre-DSO Aerial Group BBC1 BBC2
ITV1 C4 C5 Notes
Manchester Hulme SJ828966 44 2W 41 2W 47 2W BV BV 51 44
41 47

101 is a radically different site height from yours though. Could I
prevail upon you to check your data? Also, as mb21 gives the
structure height as 6.5m, I take it that your antenna height is AOD
rather than above ground ...
http://tx.mb21.co.uk/gallery/hulme.php

Java Jive

unread,
May 8, 2009, 9:57:14 AM5/8/09
to
Thanks again Phil. You obviously have good info to hand. I'll update
the transmitter file as soon as I've collated the corrections.

On Fri, 08 May 2009 11:08:50 +0100, Phil <spam...@freeserve.co.uk>
wrote:

Java Jive

unread,
May 8, 2009, 10:00:53 AM5/8/09
to
Depending on the precise locations, probably within "rubber sheet"
range then, and certainly not significant in terms of the page's
purpose, so I'll ignore that.

As a matter of interest, you mentioned your own site I think, are you
using the OS dll? If so, how do you find it? ISTR looking at that,
but deciding against if for some reason, it may have been cost, or it
may have been superfluous complexity to achieve a level of accuracy I
didn't need - can't remember now.

Regards

======================================

ne...@address.invalid

unread,
May 8, 2009, 12:20:42 PM5/8/09
to
On Fri, 08 May 2009 15:00:53 +0100, Java Jive <ja...@evij.com> wrote:

>Depending on the precise locations, probably within "rubber sheet"
>range then, and certainly not significant in terms of the page's
>purpose, so I'll ignore that.
>
>As a matter of interest, you mentioned your own site I think, are you
>using the OS dll? If so, how do you find it? ISTR looking at that,
>but deciding against if for some reason, it may have been cost, or it
>may have been superfluous complexity to achieve a level of accuracy I
>didn't need - can't remember now.
>

I don't have an on-line facility. I use the MapInfo GIS application
with a variety of topographical databases. It has all the standard
coordinate systems built-in so it can convert directly between OSGB,
OSI and WGS84 (amongst many others). I have added a look-up table to
apply the OSTN02 etc corrections so that it matches to <1m anywhere in
the UK and Ireland.

Phil

unread,
May 8, 2009, 2:32:14 PM5/8/09
to

Looking at another source of data, the site height is 30m AOD and the
antenna height is 71m above ground level (the block of flats it's on
looks fairly high). A more accurate NGR is SJ82879662.

Phil

Java Jive

unread,
May 8, 2009, 5:03:07 PM5/8/09
to
On Fri, 08 May 2009 19:32:14 +0100, Phil <spam...@freeserve.co.uk>
wrote:

>
> Java Jive wrote:
> >
> > 101 is a radically different site height from yours though.

Of course, should have been antenna height.

> Looking at another source of data, the site height is 30m AOD and the
> antenna height is 71m above ground level (the block of flats it's on
> looks fairly high). A more accurate NGR is SJ82879662.

That's a match then, great! Thanks again, Phil.

Java Jive

unread,
May 9, 2009, 12:03:02 PM5/9/09
to
I have a puzzle for you nemo ...

The OS state that distance measurements over the country are correct
to 20m. A Guide to Coordinate Systems in GB.pdf, p24, s5.2.2, para 2:

"Hence the overall size of the TRF still used for British mapping came
to be derived from the measurement of a single distance between two
stations on Hounslow Heath in 1784 using eighteen-foot glass rods! The
error thus incurred in OSGB36 is surprisingly low � only about 20
metres in the length of the country."

And I believe you agree with this order of magnitude:


> You are quite correct about the extent of the errors using just the
> basic transform. The worst will be about 14m up in the Shetlands and
> 8m in Cornwall, which as I said are much less than the other errors
> you have to cope with, e.g. site locations.

Interested to have an overall maximum figure on my web-page, I ran the
OSTN02_OSGM02 Tests through my javascript conversion, that I mentioned
previously, again today, but this time adding some simple statements
to pick up the maximum differences between ENH_ETRS89 and ENH_OSGB36.
The results were not what I expected:

Maximum easting discrepancy at FLA1 of 102.16718247160315m
Maximum northing discrepancy at Scilly of 81.19831999984853m
Maximum height discrepancy at Flannan of 56.80961243338895m

Any idea what's going on?

On Fri, 08 May 2009 17:20:42 +0100, ne...@address.invalid wrote:
>
> I don't have an on-line facility. I use the MapInfo GIS application
> with a variety of topographical databases. It has all the standard
> coordinate systems built-in so it can convert directly between OSGB,
> OSI and WGS84 (amongst many others). I have added a look-up table to
> apply the OSTN02 etc corrections so that it matches to <1m anywhere in
> the UK and Ireland.

======================================

ne...@address.invalid

unread,
May 9, 2009, 4:20:09 PM5/9/09
to
On Sat, 09 May 2009 17:03:02 +0100, Java Jive <ja...@evij.com> wrote:

>I have a puzzle for you nemo ...
>
>The OS state that distance measurements over the country are correct
>to 20m. A Guide to Coordinate Systems in GB.pdf, p24, s5.2.2, para 2:
>
>"Hence the overall size of the TRF still used for British mapping came
>to be derived from the measurement of a single distance between two
>stations on Hounslow Heath in 1784 using eighteen-foot glass rods! The
>error thus incurred in OSGB36 is surprisingly low � only about 20
>metres in the length of the country."
>
>And I believe you agree with this order of magnitude:
>> You are quite correct about the extent of the errors using just the
>> basic transform. The worst will be about 14m up in the Shetlands and
>> 8m in Cornwall, which as I said are much less than the other errors
>> you have to cope with, e.g. site locations.
>
>Interested to have an overall maximum figure on my web-page, I ran the
>OSTN02_OSGM02 Tests through my javascript conversion, that I mentioned
>previously, again today, but this time adding some simple statements
>to pick up the maximum differences between ENH_ETRS89 and ENH_OSGB36.
>The results were not what I expected:
>
>Maximum easting discrepancy at FLA1 of 102.16718247160315m
>Maximum northing discrepancy at Scilly of 81.19831999984853m
>Maximum height discrepancy at Flannan of 56.80961243338895m
>
>Any idea what's going on?

No idea I'm afraid. I might have suggested a programming error but I
wouldn't have the temerity to suggest you have got your java wrong!
Assuming that you have coded everything correctly and are using the
right ellipsoids - Airy and GRS80, those errors seem way too high.

Sorry I can't be more helpful.

Java Jive

unread,
May 9, 2009, 9:27:58 PM5/9/09
to

Especially when the results for those locations beyond that stage in
the test calculations agree with the OS, so the interim results I was
using have to be right!

> Assuming that you have coded everything correctly and are using the
> right ellipsoids - Airy and GRS80, those errors seem way too high.

Think I've got it. I shouldn't be comparing ENH_ETRS89 and
ENH_OSGB36, the latter being ENH_ETRS89 transformed by OSTN02_OSGM02,
but non 'rubber sheet' conversion against 'rubber sheet'
transformation of ENH_ETRS89 to ENH_OSGB36. That is, the mathematical
conversions of Proj4s against ENH_OSGB36 'proper'.

ne...@address.invalid

unread,
May 10, 2009, 6:03:06 AM5/10/09
to
On Sun, 10 May 2009 02:27:58 +0100, Java Jive <ja...@evij.com> wrote:

>> Assuming that you have coded everything correctly and are using the
>> right ellipsoids - Airy and GRS80, those errors seem way too high.
>
>Think I've got it. I shouldn't be comparing ENH_ETRS89 and
>ENH_OSGB36, the latter being ENH_ETRS89 transformed by OSTN02_OSGM02,
>but non 'rubber sheet' conversion against 'rubber sheet'
>transformation of ENH_ETRS89 to ENH_OSGB36. That is, the mathematical
>conversions of Proj4s against ENH_OSGB36 'proper'.
>

Time to leave this bit now. I want to see how you get on with the
propagation....

Java Jive

unread,
May 10, 2009, 6:32:52 AM5/10/09
to
No, next stage is to use the user's location to search for the
likeliest transmitters, based on the distance and path.

Propagation overlays seem rather pointless without directional
information. I've written to Ofcom, and they haven't deigned to
reply, though I'll certainly try again, but it's looking increasingly
unlikely that I'll be able to find any. Does anyone here know just
how many transmitters *are* directional, and even better, which? Even
that would be better than nothing. If the vast majority were
omni-directional, and I knew which weren't, I could have a crack at
the overlays, flagging the user not to trust those exceptions that I
know of.

On Sun, 10 May 2009 11:03:06 +0100, ne...@address.invalid wrote:
>
> Time to leave this bit now. I want to see how you get on with the
> propagation....

======================================

Mark Carver

unread,
May 10, 2009, 7:46:59 AM5/10/09
to
Java Jive wrote:
> Does anyone here know just
> how many transmitters *are* directional, and even better, which? Even
> that would be better than nothing.

Directional restrictions (that are *NOT* present for analogue) exist at these
main Tx sites on DTT (By no means exhaustive)

Hannington (towards the east)
Heathfield (towards the south)
Midhurst (different restrictions for different muxes)
Sudbury (towards the coast) Also has two separate versions of the ITV/4 mux)
Crosspool

I've never found a official list and details in the public domain ?

However, post DSO these restrictions should be lifted, presumably your tool is
for post DSO use ?

However, however, very few relay stations are omnidirectional. Most only
broadcast one or two narrow beams to 'surgically' cover specific black spots,
that policy won't change after DSO.

ne...@address.invalid

unread,
May 10, 2009, 8:00:55 AM5/10/09
to


[comments re main/relay sites deleted as Mark has beaten me to it]

I would expect that during and immmediately-post DSO, changes to relay
aerial patterns to optimise coverage could happen in many places.

In the past it was necessary for any changes to be agreed at TPG
between the two groups of planners and a hands-on regulator. Now there
is just one planning group and a hands-off regulator, they can do more
or less what they like when they like, as long as their broadcaster
customers are satisfied.

I doubt very much if individual site data will be made publicly
available in the future.

Mark Carver

unread,
May 10, 2009, 8:13:34 AM5/10/09
to
ne...@address.invalid wrote:

>
> [comments re main/relay sites deleted as Mark has beaten me to it]
>
> I would expect that during and immmediately-post DSO, changes to relay
> aerial patterns to optimise coverage could happen in many places.
>
> In the past it was necessary for any changes to be agreed at TPG
> between the two groups of planners and a hands-on regulator. Now there
> is just one planning group and a hands-off regulator, they can do more
> or less what they like when they like, as long as their broadcaster
> customers are satisfied.

Interestingly, just that *might* have occurred at the Torquay Town relay at
its DSO last month:-

http://tx.mb21.co.uk/gallery/torquay-town.php

ne...@address.invalid

unread,
May 10, 2009, 8:34:05 AM5/10/09
to
On Sun, 10 May 2009 13:13:34 +0100, Mark Carver
<mark....@invalid.invalid> wrote:

>ne...@address.invalid wrote:
>
>>
>> [comments re main/relay sites deleted as Mark has beaten me to it]
>>
>> I would expect that during and immmediately-post DSO, changes to relay
>> aerial patterns to optimise coverage could happen in many places.
>>
>> In the past it was necessary for any changes to be agreed at TPG
>> between the two groups of planners and a hands-on regulator. Now there
>> is just one planning group and a hands-off regulator, they can do more
>> or less what they like when they like, as long as their broadcaster
>> customers are satisfied.
>
>Interestingly, just that *might* have occurred at the Torquay Town relay at
>its DSO last month:-
>
>http://tx.mb21.co.uk/gallery/torquay-town.php

Yes, assuming that *is* a broadcast aerial and not another service
altogether. With so much site sharing going on it's not always easy to
tell.

Mark Carver

unread,
May 10, 2009, 8:41:56 AM5/10/09
to
ne...@address.invalid wrote:
> On Sun, 10 May 2009 13:13:34 +0100, Mark Carver

>>> In the past it was necessary for any changes to be agreed at TPG


>>> between the two groups of planners and a hands-on regulator. Now there
>>> is just one planning group and a hands-off regulator, they can do more
>>> or less what they like when they like, as long as their broadcaster
>>> customers are satisfied.
>> Interestingly, just that *might* have occurred at the Torquay Town relay at
>> its DSO last month:-
>>
>> http://tx.mb21.co.uk/gallery/torquay-town.php
>
> Yes, assuming that *is* a broadcast aerial and not another service
> altogether. With so much site sharing going on it's not always easy to
> tell.

Indeed. Although one dealer's observations in the town suggest that the
radiation pattern of the relay is now different:-

http://www.paras.org.uk/torbay.shtml

Phil Cook

unread,
May 10, 2009, 8:56:13 AM5/10/09
to
Mark Carver wrote:

>Java Jive wrote:
>> Does anyone here know just
>> how many transmitters *are* directional, and even better, which? Even
>> that would be better than nothing.
>
>Directional restrictions (that are *NOT* present for analogue) exist at these
>main Tx sites on DTT (By no means exhaustive)
>
>Hannington (towards the east)
>Heathfield (towards the south)
>Midhurst (different restrictions for different muxes)
>Sudbury (towards the coast) Also has two separate versions of the ITV/4 mux)
>Crosspool

This last only has restrictions pre ASO. The restrictions protect
analogue from Totley Rise. My aunt who lives in Totley is having to
wait to get freeview.

>I've never found a official list and details in the public domain ?
>
>However, post DSO these restrictions should be lifted, presumably your tool is
>for post DSO use ?

Indeed post ASO the restrictions on Crosspool will be a moot point
because the frequencies used for DTT now will no longer be used and
thus will not be interfering with Totley Rise.
--
Phil Cook looking north over the park to the "Westminster Gasworks"

charles

unread,
May 10, 2009, 9:50:06 AM5/10/09
to
In article <vsfd05dat7ml9te4f...@4ax.com>,
<ne...@address.invalid> wrote:

> I would expect that during and immmediately-post DSO, changes to relay
> aerial patterns to optimise coverage could happen in many places.

> In the past it was necessary for any changes to be agreed at TPG
> between the two groups of planners and a hands-on regulator. Now there
> is just one planning group and a hands-off regulator, they can do more
> or less what they like when they like, as long as their broadcaster
> customers are satisfied.

I suspect cost constraints will come into play. I can't see complete new
transmitter aerial configuations. Alter the configuration and you will
probably have to alter the transmitter power to keep the same field
strength in the original areas. That could mean bigger boxes inside, it
could mean a new feeder up the mast. It might just mean new aerial
hardware, but it all costs money.

Even with analogue, when the aerial radiation pattern didn't achieve what
was intended, nothing was done. Actually that's not quite true. Dorking
was such a **** up that it did have a completely redesigned tx aerial
fitted. I don't remember there being any others, but since I was the one
who spotted the problems with Dorking, I can hardly forget it. Plenty of
other sites (both vhf & uhf) were incorrectly installed, but that's another
matter.

--
From KT24 - in "Leafy Surrey"

Using a RISC OS computer running v5.11

ne...@address.invalid

unread,
May 10, 2009, 10:31:08 AM5/10/09
to
On Sun, 10 May 2009 14:50:06 +0100, charles
<cha...@charleshope.demon.co.uk> wrote:

>In article <vsfd05dat7ml9te4f...@4ax.com>,
> <ne...@address.invalid> wrote:
>
>> I would expect that during and immmediately-post DSO, changes to relay
>> aerial patterns to optimise coverage could happen in many places.
>
>> In the past it was necessary for any changes to be agreed at TPG
>> between the two groups of planners and a hands-on regulator. Now there
>> is just one planning group and a hands-off regulator, they can do more
>> or less what they like when they like, as long as their broadcaster
>> customers are satisfied.
>
>I suspect cost constraints will come into play. I can't see complete new
>transmitter aerial configuations. Alter the configuration and you will
>probably have to alter the transmitter power to keep the same field
>strength in the original areas. That could mean bigger boxes inside, it
>could mean a new feeder up the mast. It might just mean new aerial
>hardware, but it all costs money.
>

Agreed that cost will be a severe limitation and nothing will be
changed if it isn't really needed. But the point I was making is that
the transmit parameters will be far less controlled than previously
(except where international coordination is needed of course). It
won't be strictly necessary to "keep the same field strength in the
original areas". Parameters *could* be changed almost on a whim unless
predictions suggest CCI or viewer complaints.

I can also see a question mark over the continuance of some relays
where they have been installed primarily due to analogue multipath.

charles

unread,
May 10, 2009, 10:44:14 AM5/10/09
to
In article <bqod05ti068efepog...@4ax.com>,

<ne...@address.invalid> wrote:
> It won't be strictly necessary to "keep the same field strength in the
> original areas". Parameters *could* be changed almost on a whim unless
> predictions suggest CCI or viewer complaints.

except that there will be an outcry if viewers need to upgrade their
aerials because of lower signals.

> I can also see a question mark over the continuance of some relays
> where they have been installed primarily due to analogue multipath.

I agree. Since, in general, these relays deal with main station problems,
and the main stations have been carrying DTT for some years, survey work
could have already been done, so that the relays wouldn't need to be
upgraded to DTTV and subsequently turned off. Far better to have given
notice of closure and let them go when analogue is removed.

Mark Carver

unread,
May 10, 2009, 10:52:30 AM5/10/09
to
charles wrote:

>> I can also see a question mark over the continuance of some relays
>> where they have been installed primarily due to analogue multipath.
>
> I agree. Since, in general, these relays deal with main station problems,
> and the main stations have been carrying DTT for some years, survey work
> could have already been done, so that the relays wouldn't need to be
> upgraded to DTTV and subsequently turned off. Far better to have given
> notice of closure and let them go when analogue is removed.

How many relays in the UK are there mainly for multipath reasons ?

I'm familair with Millbrook in Southampton, where are some of others ?

ne...@address.invalid

unread,
May 10, 2009, 11:05:33 AM5/10/09
to
On Sun, 10 May 2009 15:44:14 +0100, charles
<cha...@charleshope.demon.co.uk> wrote:

>In article <bqod05ti068efepog...@4ax.com>,
> <ne...@address.invalid> wrote:
>> It won't be strictly necessary to "keep the same field strength in the
>> original areas". Parameters *could* be changed almost on a whim unless
>> predictions suggest CCI or viewer complaints.
>
>except that there will be an outcry if viewers need to upgrade their
>aerials because of lower signals.
>

Certainly, hence my caveat above.
I would expect any changes to increase signal strength rather than
reduce it, as has already been done where Tx aerials have quietly been
raised to make room for cellular aerials.

>> I can also see a question mark over the continuance of some relays
>> where they have been installed primarily due to analogue multipath.
>
>I agree. Since, in general, these relays deal with main station problems,
>and the main stations have been carrying DTT for some years, survey work
>could have already been done, so that the relays wouldn't need to be
>upgraded to DTTV and subsequently turned off. Far better to have given
>notice of closure and let them go when analogue is removed.
>

I suspect the answer to that is simply political. Government wanted to
promise that *all* relays would be converted.
Once DSO is completed it will be possible to pick such relays off one
at a time without too much fuss, particularly if it gives the viewers
more channels by switching to the main station. In most cases it would
be economic for Arqiva and/or the broadcasters to subsidise the viewer
aerial changes.

J G Miller

unread,
May 10, 2009, 11:12:25 AM5/10/09
to
On Sun, 10 May 2009 15:52:30 +0100, Mark Carver wrote:

> How many relays in the UK are there mainly for multipath reasons ?

Alexandra Palace?

Definitely Croydon Old Town

<http://tx.mb21.co.UK/gallery/croydon-old-town.php>

charles

unread,
May 10, 2009, 12:26:17 PM5/10/09
to
In article <76o81eF...@mid.individual.net>,

Mark Carver <mark....@invalid.invalid> wrote:
> charles wrote:

> >> I can also see a question mark over the continuance of some relays
> >> where they have been installed primarily due to analogue multipath.
> >
> > I agree. Since, in general, these relays deal with main station
> > problems, and the main stations have been carrying DTT for some years,
> > survey work could have already been done, so that the relays wouldn't
> > need to be upgraded to DTTV and subsequently turned off. Far better to
> > have given notice of closure and let them go when analogue is removed.

> How many relays in the UK are there mainly for multipath reasons ?

> I'm familair with Millbrook in Southampton, where are some of others ?


a great many in south Wales, Croydon Old Town, Alexandra Palace, Ipswich
(Stoke) to name but a few.

Java Jive

unread,
May 12, 2009, 9:53:28 AM5/12/09
to
Just released an update to fix a few things, it should be stable for a
week or two now while I work on the next stage.

I suspect that memory is becoming a big issue. There are 18 script
tags in the page already, without searching for the best transmitters,
let alone using overlays. I'm not sure how much further I can take
this without introducing so many 'features' due to lack of memory that
extending functionality actually starts to become counter-productive.

The functional changes are:

Slightly quicker way of loading the transmitters file using a script
tag rather than an XML HTTP Request.

If necessary in unusual circumstances, the transmitter's precise
location can be adjusted similarly to the receiver's, with
<Ctrl-Double-Click> (for some strange, utterly baffling reason, this
works fine in FF and IE but f*ks up in Opera, yet Opera has no problem
with adjusting the receiver's location using <Alt-Double-Click> with
directly analogous coding!).

One can now click at different heights in the signal path to display
the terrain in the Google map, the OS map, or both.

The rest are mainly documentary changes, to reflect the fact that I've
done lots more testing, particularly of actually printing, and
discovered new cans of worms that have appeared since I wrote the
original satellite calculator page. I can not describe how
exasperating it is to find that upgrades to browsers and mapping
systems break code that was working fine before (isn't it bad enough
having so many browsers to support with so many departures from
standards, without them introducing new ones?).

One doc change may annoy nemo. For now, I'm stating the accuracy in
the coordinate readout as 5m. This is based on reading in the OS's
own conversion tests and results, converting the start positions using
Open Layers/Proj4js, and comparing the results with the OS's own
transformation:

Maximum easting discrepancy: Scilly, 4.707488964821096
Maximum northing discrepancy: StKilda, 4.9222134839510545

This agrees with the OS' own documentation ...

A Guide to Coordinate Systems in GB.pdf, p33, s6.6:

"The following Helmert transformation converts WGS84 (or ETRS89 or
ITRS, the differences are negligible here) coordinates to �something
like� OSGB36 and �something like� ODN heights. The error is up to five
metres both horizontally and vertically."

Sorry, nemo, but if you give me the actual coordinates of the points
you found, I'll check them in the OS calculator and maybe amend the
accuracy figure as a result.

On Thu, 07 May 2009 17:35:02 +0100, Java Jive <ja...@evij.com> wrote:

> I've now got a more sophisticated version of the TV Aerial Alignment
> Calculator up and running. There's a transmitter list with aerial
> heights (and potentially a more complete one with lots of other info
> not yet used), 60% and 100% Fresnel zones, and the curvature of the
> earth:
>
> http://www.macfh.co.uk/Test/UKTerrestrialTVTest.html

ne...@address.invalid

unread,
May 13, 2009, 3:50:51 PM5/13/09
to
On Tue, 12 May 2009 14:53:28 +0100, Java Jive <ja...@evij.com> wrote:

>Sorry, nemo, but if you give me the actual coordinates of the points
>you found, I'll check them in the OS calculator and maybe amend the
>accuracy figure as a result.
>

I'm travelling ATM. Will be back at base in a week and will look it up
then.

ne...@address.invalid

unread,
May 23, 2009, 7:00:39 AM5/23/09
to

OK. I'm back at base. What exactly do you need?

Java Jive

unread,
May 25, 2009, 1:23:09 PM5/25/09
to
Please see below ...

On Sat, 23 May 2009 12:00:39 +0100, ne...@address.invalid wrote:
>
> On Wed, 13 May 2009 20:50:51 +0100, ne...@address.invalid wrote:
>
> >On Tue, 12 May 2009 14:53:28 +0100, Java Jive <ja...@evij.com> wrote:
> >
> >>Sorry, nemo, but if you give me the actual coordinates of the points
> >>you found, I'll check them in the OS calculator and maybe amend the
> >>accuracy figure as a result.
>

> OK. I'm back at base. What exactly do you need?

Originally you wrote ...

On Thu, 07 May 2009 19:19:34 +0100, ne...@address.invalid wrote:

> I notice your NGR/ lat-long conversions are a little in error,

... and ...

On Thu, 07 May 2009 22:39:29 +0100, ne...@address.invalid wrote:

> On Thu, 07 May 2009 20:59:44 +0100, Java Jive <ja...@evij.com> wrote:
>
> The two sites I checked were 6 and 12 metres different from OSTN02.

... which runs counter to my measurements of about 5m for the accuracy
of the coordinate displays, measurements which also agreed with the OS
statement about the expected accuracy of Helmert calculations (but the
OS's own documentation does seem a trifle self-contradictory).

If you can remember which points you found, I'll put them through the
OS own calculator and maybe amend the accuracy figure given on the
page.

ALSO

Currently working on best transmitter choice by terrain, distance,
etc. I have another question relating to that. Document ITU-R P530
"PROPAGATION DATA AND PREDICTION METHODS REQUIRED FOR
THE DESIGN OF TERRESTRIAL LINE-OF-SIGHT SYSTEMS" p3 eqn2 ...
http://cict.inatel.br/nova2/docentes/dayan/Electronic_Library/Standards/Propagation/Rec.%20ITU-R%20P.530-8.pdf
... gives a figure for diffraction loss in dB over average terrain
intruding a distance h into the first Fresnel radius F:

A = -20h/F +10

However, the document appears to be concern mainly frequencies in the
GHz range, and it's not clear from the context whether that formula is
more widely applicable, and therefore could be applied to UHF TV in
the MHz range. Can it?

Have also swapped the mapping API to Google's own for the Google map,
as OpenLayers seems to have slipped backwards over the last 6 months.

ne...@address.invalid

unread,
May 25, 2009, 3:20:29 PM5/25/09
to
On Mon, 25 May 2009 18:23:09 +0100, Java Jive <ja...@evij.com> wrote:

>Please see below ...
>
>On Sat, 23 May 2009 12:00:39 +0100, ne...@address.invalid wrote:
>>
>> On Wed, 13 May 2009 20:50:51 +0100, ne...@address.invalid wrote:
>>
>> >On Tue, 12 May 2009 14:53:28 +0100, Java Jive <ja...@evij.com> wrote:
>> >
>> >>Sorry, nemo, but if you give me the actual coordinates of the points
>> >>you found, I'll check them in the OS calculator and maybe amend the
>> >>accuracy figure as a result.
>>
>> OK. I'm back at base. What exactly do you need?
>
>Originally you wrote ...
>
>On Thu, 07 May 2009 19:19:34 +0100, ne...@address.invalid wrote:
>
>> I notice your NGR/ lat-long conversions are a little in error,
>
>... and ...
>
>On Thu, 07 May 2009 22:39:29 +0100, ne...@address.invalid wrote:
>
>> On Thu, 07 May 2009 20:59:44 +0100, Java Jive <ja...@evij.com> wrote:
>>
>> The two sites I checked were 6 and 12 metres different from OSTN02.
>
>... which runs counter to my measurements of about 5m for the accuracy
>of the coordinate displays, measurements which also agreed with the OS
>statement about the expected accuracy of Helmert calculations (but the
>OS's own documentation does seem a trifle self-contradictory).
>
>If you can remember which points you found, I'll put them through the
>OS own calculator and maybe amend the accuracy figure given on the
>page.
>

IIRC it was Crystal Palace and Rumster Forest.

>ALSO
>
>Currently working on best transmitter choice by terrain, distance,
>etc. I have another question relating to that. Document ITU-R P530
>"PROPAGATION DATA AND PREDICTION METHODS REQUIRED FOR
>THE DESIGN OF TERRESTRIAL LINE-OF-SIGHT SYSTEMS" p3 eqn2 ...
>http://cict.inatel.br/nova2/docentes/dayan/Electronic_Library/Standards/Propagation/Rec.%20ITU-R%20P.530-8.pdf
>... gives a figure for diffraction loss in dB over average terrain
>intruding a distance h into the first Fresnel radius F:
>
>A = -20h/F +10
>
>However, the document appears to be concern mainly frequencies in the
>GHz range, and it's not clear from the context whether that formula is
>more widely applicable, and therefore could be applied to UHF TV in
>the MHz range. Can it?
>

That formula is useful, but *very* approximate because there is really
no such thing as "average" terrain. Diffraction caused by intrusion of
e.g. fields, woods and mountain tops is very different, which is why a
clutter database is key to accurate predictions.

The general principles apply to the UHF TV range, but the effect of
each clutter type is different because the dimension of the fresnel
zone is larger and relates differently to the granularity of the
clutter.

Don't forget though that in service planning you can't consider any
single tx's coverage in isolation. You have to consider other
co-channel tx-es and their relative signal levels, and this quickly
gets very complex because you have to assume rx aerial patterns and
their probable rejection of CCI.

[I'd better sign off here as I'm in danger here of repeating my
sceptical comments at the start of your project]

Java Jive

unread,
May 25, 2009, 6:53:36 PM5/25/09
to
On Mon, 25 May 2009 20:20:29 +0100, ne...@address.invalid wrote:
>
> IIRC it was Crystal Palace ...

Putting cursor on base of transmitter symbol:
TQ339711
533963E,171177N
-0.07462degE,51.42378degN

According to OS:
EN -> LL
0.07460354degW,51.42377848degN
Error:0.00001646,
Approx:1.83,0.17m

LL -> EN
533961.851E,171177.139N
Error:1.15,0.14m

> ... and Rumster Forest.

Putting cursor on base of transmitter symbol:
ND197385
319771E,938597N
-3.37159degE,58.32855degN

According to OS:
EN -> LL
3.37159392degW,58.32853267degN
Error:0.44,1.93m

LL -> EN
319771.269E,938598.924N
Error:1.93,0.27

> >A = -20h/F +10

> That formula is useful, but *very* approximate because there is really
> no such thing as "average" terrain.

But I don't have access to one, so this will have to do.



> Don't forget though that in service planning you can't consider any
> single tx's coverage in isolation. You have to consider other
> co-channel tx-es and their relative signal levels, and this quickly
> gets very complex because you have to assume rx aerial patterns and
> their probable rejection of CCI.

But I'm not service planning. Given a service that has already been
planned, I just have to find the most likely transmitter(s).

Java Jive

unread,
May 25, 2009, 7:33:42 PM5/25/09
to
On Mon, 25 May 2009 23:53:36 +0100, Java Jive <ja...@evij.com> wrote:
>
> > >A = -20h/F +10
>
> > That formula is useful, but *very* approximate because there is really
> > no such thing as "average" terrain.
>
> But I don't have access to one, so this will have to do.

[Too severe snipping] Access to a clutter database, that is ...

ne...@address.invalid

unread,
May 26, 2009, 5:06:20 AM5/26/09
to

I'll do another check and see where I got the figures.

>> >A = -20h/F +10
>
>> That formula is useful, but *very* approximate because there is really
>> no such thing as "average" terrain.
>
>But I don't have access to one, so this will have to do.
>
>> Don't forget though that in service planning you can't consider any
>> single tx's coverage in isolation. You have to consider other
>> co-channel tx-es and their relative signal levels, and this quickly
>> gets very complex because you have to assume rx aerial patterns and
>> their probable rejection of CCI.
>
>But I'm not service planning. Given a service that has already been
>planned, I just have to find the most likely transmitter(s).
>

Call it what you like, but the "most likely" transmitter may be
unusable due to CCI.
ISTM that your program is most likely to be used in marginal/difficult
situations where the installer cannot just copy the aerials on
adjacent houses. These are precisely the cases where CCI may be
significant.

0 new messages