The BBC4 Mux
Graham C
sometimes transmitted in MUX 1, along with all the other BBCs, and
sometimes in MUX B. Websites seem to have problems using the old
1,2,A,B,C,D and the newer PSB, BBCA, D3+D4 etc names.
I was aware of BBC4 moving into MUX1 / PSB1 at ther last changeover in
my area (Bristol).
The query originated from a friend in the Welsh valleys who have been
'reliably' informed that they will be able to receive all the BBCs
except BBC4. Their two local TXs are now digital, and they cannot
receive any main transmitters. They will install an aerial if BBC4 is
available.
Is thislikely, or are many of the websites well out of date.
GrahamC
GrahamC
tony sayer
<graha...@btopenworld.com> scribeth thus
Or go Freesat, its all up there:)...
--
Tony Sayer
Phil Cook
The websites are out of date and their informer is unreliable.
My understanding is that BBC4 moves to the same MUX as BBC1, 2 and 3
at DSO.
This site gives an up to date list for each region/transmitter group.
http://www.unsatisfactorysoftware.co.uk/dtt/dtt.cgi?
--
Phil Cook looking north over the park to the "Westminster Gasworks"
Java Jive
<graha...@btopenworld.com> wrote:
> A visit to a significant number of websites reveals that BBC4 is
> sometimes transmitted in MUX 1, along with all the other BBCs, and
> sometimes in MUX B. Websites seem to have problems using the old
> 1,2,A,B,C,D and the newer PSB, BBCA, D3+D4 etc names.
The reason for the confusion is the comparatively late decision to
transmit Mux B as HD, combined with the change of mux names at DSO.
There is also an incidental further source of confusion in the
comparatively late decision to release different UHF bandwidth for
non-TV uses than that originally intended, to align ourselves with the
rest of Europe.
The following information on these three points is appended to the DSO
details for Meridian (one of the most recent three sets of DSO details
to be published, 17/6/2010)
http://stakeholders.ofcom.org.uk/binaries/broadcast/guidance/tech-guidance/Meridian.pdf
a) "Multiplex Names
The current designations of the six multiplexes will change at
switchover, and the table below compares their current and future
names:
Current Multiplex Name Post-Switchover Name Operator
1 BBC A BBC
2 D3&4 Digital 3 & 4
A SDN SDN
B BBC B BBC
C Arqiva A Arqiva
D Arqiva B Arqiva"
b) "Transmission Mode
It is anticipated that the post-switchover transmission mode for all
multiplexes except BBC B, will be 64QAM modulation, coding rate 2/3, &
8K FFT.
The BBC B multiplex is being converted to the DVB-T2 standard using
256QAM modulation, coding rate 2/3, & 32K FFT. Conversion to DVB-T2
will take place at (or shortly after) DSO in each region, with
conversion in early switchover regions taking place during 2010."
c) "800 MHz clearance
In order to align the frequencies released by digital switchover for
alternative uses with those released by other European countries, UHF
channels 61 and 62 will be ‘cleared’ of digital TV services over the
coming years. UHF channels 39 and 40 (which were previously among the
channels to be released after switchover) will instead now be retained
for TV broadcasting.
In order to minimise changes to domestic aerial groups, the general
approach for adopting these changes is that multiplexes using channels
61 or 62 will move to channels 49 or 50, and multiplexes using
channels 49 or 50 will move to channels 39 or 40. The changes will
either be carried out at digital switchover, or sometime after
switchover completes (e.g. during 2013). If the changes will be
carried out at digital switchover, an updated version of this guide
will be issued.
Multiplexes using channels 61, 62, 49, or 50 are highlighted in red in
this guide to indicate that these allocations are likely to change in
the future."
> I was aware of BBC4 moving into MUX1 / PSB1 at ther last changeover in
> my area (Bristol).
Yes, that sounds right. I still have BBC4 as being in MUX B pre-DSO
from Hannington, but it seems clear that if it hasn't moved already (I
no longer have a working FV box, so I don't know), then it will at
DSO, as from DSO Mux B will contain only HD broadcasts.
> The query originated from a friend in the Welsh valleys who have been
> 'reliably' informed that they will be able to receive all the BBCs
> except BBC4. Their two local TXs are now digital, and they cannot
> receive any main transmitters. They will install an aerial if BBC4 is
> available.
Wales being one of the earlier areas of DSO, Mux B was mostly
retro-converted to HD, but this is supposed to have been completed by
the end of June this year. As I haven't heard anything to the
contrary, I presume that it was.
Therefore your friends should be able to receive BBC4 from Mux 1. If
they want information about their local relay broadcasts, including
the retro-conversion for HD, they can put their post code into my
aerial alignment calculator and for transmitters choose either "Find
the nearest" or "Find the likeliest".
http://www.macfh.co.uk/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.html
> Is thislikely, or are many of the websites well out of date.
The scale and complexity of the DSO project result in huge potential
for websites being out of date, or carrying erroneous information for
a number of other reasons:
0) AFAIAA there is no one reliable source of structured information
covering the entire DSO project. Analogue data copies and pastes
quite well from web-pages as Tab-Seperated Values (TSV) and thus can
be used with minimal hand-editing, but the pre- and post-DSO digital
data comes from PDFs, which lose all structure under c'n'p, and this
makes using such information as is published extremely time consuming
and difficult. To amplify this point ...
1) DSO transmissions details are published at the following link, and
these are updated on average every month or so, though it usually
actually happens in batches some months apart.
http://stakeholders.ofcom.org.uk/broadcasting/guidance/tech-guidance/dsodetails/
2) Yet DSO Switchover dates are published seperately at the Digital
UK site:
http://www.digitaluk.co.uk/when_do_i_switch
3) While HD information comes from the BBC:
http://www.bbc.co.uk/pressoffice/pressreleases/stories/2009/11_november/16/freeview.shtml
4) Many transmitter names have changed pre- and post- DSO, or are
subject to other confusion, which makes connecting information on
particular transmitters from different sources very difficult to
automate. Some examples:
Whitehawk Hill <=> Brighton Whitehawk Hill
Knock More (OS correct pre-DSO) <=> Knockmore (incorrect post-)
5) About 25% of the transmitters have incorrectly rounded NGRs in the
pre-DSO Analogue listings, and these have been corrected in the pre-
and post-DSO digital listings, which again makes connecting
information on particular transmitters from different sources very
difficult to automate.
6) There are further inconsistencies between the various sources of
information with regard to aerial heights, groups, and polarities.
7) A small number of transmitters become disused at DSO, while a
larger number come into use for the first time. Others change
'allegiance' (become a relay of a different main), while others become
mains in their own right.
8) Some transmitters broadcast directionally to more than one region,
for example: Storeton and Storeton (Wales) are actually different
transmissions from the same transmitter, so are Ridge Hill and Ridge
Hill (West).
All the above make keeping a website up-to-date a nightmare.
My own calculator linked above has just been updated with changes from
recent threads here, up to and including the change of Durris Arqiva B
from channel 44 as advertised to channel 51 as happened at DSO stage
2. I hope and believe these data changes should bring it pretty much
up to date, but perhaps it's worth mentioning that besides my own
tolerably regular checking of the various websites linked above, I
rely on people keeping me informed of any erroneous data they do
discover, either by posting them here or via email, but very few
people actually bother with the latter. This means that I often
discover errors entirely by accident, as with Berwick.
--
=========================================================
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html
Java Jive
Mark can enlighten us?
On Tue, 21 Sep 2010 15:59:20 +0100, Phil Cook
<ph...@p-t-cook.freeserve.co.uk> wrote:
>
> This site gives an up to date list for each region/transmitter group.
>
> http://www.unsatisfactorysoftware.co.uk/dtt/dtt.cgi?
--
Mark Carver
> A visit to a significant number of websites reveals that BBC4 is
> sometimes transmitted in MUX 1, along with all the other BBCs, and
> sometimes in MUX B. Websites seem to have problems using the old
> 1,2,A,B,C,D and the newer PSB, BBCA, D3+D4 etc names.
>
> I was aware of BBC4 moving into MUX1 / PSB1 at ther last changeover in
> my area (Bristol).
>
> The query originated from a friend in the Welsh valleys who have been
> 'reliably' informed that they will be able to receive all the BBCs
> except BBC4. Their two local TXs are now digital, and they cannot
> receive any main transmitters. They will install an aerial if BBC4 is
> available.
Every transmitter in Wales, carries BBC 4 on Mux 1 (the same mux as used
for BBC1,2,3 and BBC Radio). Mendip, also receivable in the valleys is
the same.
--
Mark
Please replace invalid and invalid with gmx and net to reply.
Mark Carver
> But what would be the *official* source of such information? Perhaps
> Mark can enlighten us?
All post DSO transmitters carry all *SD* BBC TV services, and radio on
Mux 1 (aka PSB 1, aka BBC A)
For *Post* DSO transmitters, Mux B/PSB 3/BBC B carries BBC, ITV and C4
(S4C in Wales) *HD* channels.
*Pre* DSO transmitters carry BBC 4, BBC Radio, and Ch 301 (BBCi) on Mux
B.
Java Jive
I was a non-technical member of the GP, and wanted some reliable
OFFICIAL information on which channel was carried by which mux,
whither would I go?
On Tue, 21 Sep 2010 18:16:22 +0100, Mark Carver
<mark....@invalid.invalid> wrote:
> On 21/09/2010 18:10, Java Jive wrote:
> > But what would be the *official* source of such information? Perhaps
> > Mark can enlighten us?
>
> All post DSO transmitters carry all *SD* BBC TV services, and radio on
> Mux 1 (aka PSB 1, aka BBC A)
>
> For *Post* DSO transmitters, Mux B/PSB 3/BBC B carries BBC, ITV and C4
> (S4C in Wales) *HD* channels.
>
> *Pre* DSO transmitters carry BBC 4, BBC Radio, and Ch 301 (BBCi) on Mux
> B.
--
Andy Burns
> But what would be the *official* source of such information?
Dunno about official, but pretty close to the horse's mouth
Woody
news:xIGdncBwTugubgXR...@brightview.co.uk...
Agreed, good site but 'specialist' for people like us.
Joe Public needs accurate data from sites that are widely
advertised and that is clearly not happening.
--
Woody
harrogate three at ntlworld dot com
wrights...@f2s.com
> "Andy Burns" <usenet.aug2...@adslpipe.co.uk> wrote in message
> Joe Public needs accurate data from sites that are widely
> advertised and that is clearly not happening.
Joe public isn't aware of the concept of a multiplex, never mind
wondering what each one contains. I know this because they ring up and
tell me in wonderment which channels are missing and which are OK, and
they obviously have no idea why it is.
Bill
Java Jive
<harro...@ntlworld.spam.com> wrote:
> "Andy Burns" <usenet....@adslpipe.co.uk> wrote in message
> >
> > Dunno about official, but pretty close to the horse's mouth
> >
> > http://www.dmol.co.uk/
>
> Agreed, good site but 'specialist' for people like us.
Nevertheless, I thought it was clear enough to be worth a link from my
pages. Thanks Andy.
> Joe Public needs accurate data from sites that are widely
> advertised and that is clearly not happening.
Yes, it's a public relations disaster. There is no one site that can
tell you everything you need to know about DSO, and, besides the
points already made in my rather long reply to the OP, even the three
or four most relevant sites are appallingly designed ...
Ofcom's data is further subdivided into three different sources for
analogue, and digital pre- and post-DSO. One can't help but think if
they put all the information for each transmitter on one page, some of
the more glaring errors we've discovered over the last year or so
would have been easily spotted and thus avoided. And I wish they'd
give us structured data and lose those unwieldy PDFs.
On the Freeview site, which one would have thought was the obvious
place to look, there is absolutely nothing at all about which channels
are in which muxes. Given that many relays won't be broadcasting the
COM muxes, this is a ridiculous omission.
The Digital UK site is too slow anyway, and to make matters worse, if,
like me, you choose not to have Flash installed, every single blasted
page in the relevant section throws up an alert box about it.
Everywhere is plastered with that childish logo from the TV ads that
insults customers by patronisingly treating them as if they have a
mental age of 2. As if all that wasn't bad enough, the site doesn't
present what little information it does actually contain in a useable
form. For example it doesn't have all the DSO dates for a single
region in a single table - wearisomely, you have to go to the
details of each individual main transmitter, waiting for them to load,
just to pick up its two dates ...
.
.
.
Then the next ...
.
.
.
Then the next ...
.
.
.
FFS, who designs this cr*p? When are Digitak UK ever going to give us
- the public, its customers, who paid the taxes and licence fees that
made DSO possible - a clear, professional site that lists the
required information in a tabular form that can actually be used by
any member of the public QUICKLY and EFFICIENTLY.
So, all in all, things could hardly be worse if they'd been
deliberately designed to be so.
I'm reminded of a documentary or film that I once saw involving a
legal case where a company being sued had to supply information vital
to the prosecution before a deadline. They complied at the very last
possible moment, burying the vital information in boxes and boxes of
irrelevant information, in the hope that the prosecution wouldn't be
able to find it in the short time available before the trial. (I
can't remember the outcome.)
Andy Burns
> Andy Burns<usenet....@adslpipe.co.uk> wrote:
>
>> http://www.dmol.co.uk/
>
> Strange site though E,S,NI but no mention of Wales anywhere that I can
> see.
Isn't all of Wales now post-DSO? Certainly "W" appears on those pages,
rather than the pre-DSO pages ...
Andy Burns
> Andy Burns<usenet....@adslpipe.co.uk> wrote:
>
>> Isn't all of Wales now post-DSO?
>
> Yes of course.
Strange though, they've cut the Wales column from the pre-DSO mux page,
but left the rows in for the Wales channels, even though none of those
rows intersect with any of the remaining columns.
Dickie Mint
What could be more official than the DTG - the quasi-standards body of
Digital Broadcasting :
http://www.dtg.org.uk/industry/dtt_channels.html
Richard
Andy Burns
> What could be more official than the DTG - the quasi-standards body of
> Digital Broadcasting :
>
> http://www.dtg.org.uk/industry/dtt_channels.html
Which seems to be an out-dated version of information from the dmol site ...
Dickie Mint
> Which seems to be an out-dated version of information from the dmol site
> ...
>
Hmmph!! Typical!
Richard
Ian
<richard_ta...@trapyahoo.co.uk> writes
As someone with a knowledge that falls somewhere between Joe Public and
the experienced members of this n/g, I've always found this site to be
informative and useful.
Andy Burns
> As someone with a knowledge that falls somewhere between Joe Public and
> the experienced members of this n/g, I've always found this site to be
> informative and useful.
>
> http://www.ukfree.tv/transmitters.php
I don't know if it's generally improved lately (I do know it has some
specific good info such as the transmitter radiation patterns). But
previously it seemed to re-post speculation from all over the place as
though it were fact.
Charles, if you're still listening, does your aerial alignment predictor
use the radiation patterns?
Java Jive
have all the DSO dates on a single page. Hooray! However, they are
set in chronological order, and cannot be sorted by region or by main
within region. Still, at least it's only one Flash alert to dismiss,
and the data is all on one page ...
http://www.digitaluk.co.uk/transmitternetwork/transmitter_groups
On Wed, 22 Sep 2010 02:17:46 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>
> When are Digitak UK ever going to give us
> - the public, its customers, who paid the taxes and licence fees that
> made DSO possible - a clear, professional site that lists the
> required information in a tabular form that can actually be used by
> any member of the public QUICKLY and EFFICIENTLY.
Java Jive
Although it was admittedly a while ago, I did take a look at the ones
on that site, and they didn't seem to me to have enough hard
information to be useful for predictive purposes.
Also a while ago, I asked Ofcom for radiation pattern details, but
their reply was that they would not be making them available in a
manner that I would consider useful. This is from a previous post of
mine on the subject:
"""
Ofcom have finally replied to my requests for information. There will
be no directional information published for pre-DSO broadcasting:
"Patterns for the pre-switchover network have not been published. The
original network information is paper-based, is becoming increasingly
outdated and is of little value to most people. As these old papers
also contain some confidential information we have not made them
publicly available. Instead, coverage information for both the pre-
and post-switchover networks is available via the postcode checker
that is carried on Digital UK's website (www.digitaluk.co.uk). This
checker takes into account not only pattern information, but also the
effect of terrain height and varying propagation and interference from
distant transmitters to predict the likelihood of reception at a
particular location. If you click on the trade view option, more
detailed information is given."
...
There will be directional information for post-DSO broadcasting, but
only after some months, so too late help anyone cope with the actual
changeover!
"""
As it happens, I'm currently working on a new version of the
calculator that doesn't rely on my friend's Google App Engine terrain
database, but reads SRTM height and UMD clutter data directly - the
latter is an enhancement not in the current live version.
I should stress that this is very much beta stage, for example it's
been tested in FF3, IE6, and Opera 9, but only partially in IE8,
Chrome, and Safari, and not at all in Opera 10. However, if anyone is
interested enough to have a play and feed back, they can at the
following URL:
Deliberately munged. Please remove the spaces and carriage returns to
use. Please do not post elsewhere without munging and without this
notice. This is to prevent is being discovered by search engines -
once they start listing a page it's a devil's own problem to remove it
permanently. It will appear for ever and future users be directed to
it long after it has moved to its intended final location on the site
and become live:
h t t p : / / w w w . m a c f h . c o . u k /
PrivTest/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.
p h p
Note:
One of the resources that takes longest to load is the almost 1Mb of
OpenLayers code for drawing the OS map, and that begins to load after
the form is unlocked ready for user entry. Therefore, if you set a
search going immediately the form unlocks, you will get a timeout or
two, though usually the search will complete eventually. Occasionally
however, the OL load will choke the search, and it will fail to
complete. If this happens, you may be able to wait for everything to
finish loading, then search again, or you may have to reload the page
and be more patient next time.
Technical explanation: In an attempt to reduce demands on the server,
I've commented out some code that, when a search is recommenced, wipes
the data not yet completely received, which was forcing a new series
of GETs to the server. I've done this because the majority of it will
be successfully received, and it is therefore pointless to refetch it.
The difficulty then is in deciding which previous GETs have actually
totally failed, and the system is only partially successful at this -
the frustrating thing is that looking at it in a debugger such as
Firebug, it's blindingly obvious which have failed, the response is
empty, but, except in Opera, there is no way of knowing that directly
from within the client's JavaScript.
If I can't fix this problem any better way - I'm thinking about
removing those OpenLayers modules that my code doesn't actually need,
but this could be quite involved - I'll shall just have to replace
the commented out code, but in the meantime, I'd be interested to hear
of people's real live experiences with this problem particularly and
the updated version generally.
On Wed, 22 Sep 2010 12:56:50 +0100, Andy Burns
<usenet....@adslpipe.co.uk> wrote:
>
> Charles, if you're still listening, does your aerial alignment predictor
> use the radiation patterns?
PeterC
> As it happens, I'm currently working on a new version of the
> calculator that doesn't rely on my friend's Google App Engine terrain
> database, but reads SRTM height and UMD clutter data directly - the
> latter is an enhancement not in the current live version.
>
> I should stress that this is very much beta stage, for example it's
> been tested in FF3, IE6, and Opera 9, but only partially in IE8,
> Chrome, and Safari, and not at all in Opera 10. However, if anyone is
> interested enough to have a play and feed back, they can at the
> following URL:
>
> Deliberately munged. Please remove the spaces and carriage returns to
> use. Please do not post elsewhere without munging and without this
> notice. This is to prevent is being discovered by search engines -
> once they start listing a page it's a devil's own problem to remove it
> permanently. It will appear for ever and future users be directed to
> it long after it has moved to its intended final location on the site
> and become live:
> h t t p : / / w w w . m a c f h . c o . u k /
> PrivTest/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.
> p h p
Well, it seems to work in the latest build of Opera 10.7; distance and
azimuth look OK. The Signal Profile is a bit frightening, having what
appears to be the highest point - 160m - about 12km away (my aerial is at
about 90m) towards Oxford.
The DigitalUK checker is correct about using Sandy Heath at the same
distance but can't take account of the N. Coast main line about 100m away -
or the trains atop that and the interference.
I notice that Sandy Heath has both dates in but Oxford doesn't, but ISTR
that they're about the same.
--
Peter.
The gods will stay away
whilst religions hold sway
Java Jive
On Wed, 22 Sep 2010 15:16:10 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>
> Deliberately munged. Please remove the spaces and carriage returns to
> use. Please do not post elsewhere without munging and without this
> notice. This is to prevent is being discovered by search engines -
> once they start listing a page it's a devil's own problem to remove it
> permanently. It will appear for ever and future users be directed to
> it long after it has moved to its intended final location on the site
> and become live:
> h t t p : / / w w w . m a c f h . c o . u k /
> PrivTest/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.
> p h p
Andy Burns
> h t t p : / / w w w . m a c f h . c o . u k /
> PrivTest
The signal profile certainly loads much faster then the previous
version, I take it it's deliberate to show the fresnel zones above the
LoS as well as below it now?
What does the "clutter" consist of (buildings, trees?) and where do you
grab the data for that from?
Java Jive
<giraffe...@homecall.co.uk> wrote:
>
> Well, it seems to work in the latest build of Opera 10.7; distance and
> azimuth look OK.
Glad to hear that, previous versions of Opera 10 were struggling with
one particular function in one particular script. As that is still in
there, I can only conclude that Opera have fixed the previous problem
- good to know.
> The Signal Profile is a bit frightening, having what
> appears to be the highest point - 160m - about 12km away (my aerial is at
> about 90m) towards Oxford.
'Frightening'? Is perhaps that a euphemism for 'Wrong'? I'd rather
know the truth if it is ...
> The DigitalUK checker is correct about using Sandy Heath at the same
> distance but can't take account of the N. Coast main line about 100m away -
> or the trains atop that and the interference.
Does the embankment show up on the calc's signal path profile? The
underlying SRTM data has a resolution of about 90m, so it's probably a
matter of chance whether it does or not.
> I notice that Sandy Heath has both dates in but Oxford doesn't, but ISTR
> that they're about the same.
No dates for Oxford yet other than just '2011', see the Digital UK
link I gave in the original thread.
Thanks for the feedback.
UnsteadyKen
> However, if anyone is
> interested enough to have a play and feed back, they can at the
> following URL:
Works fine and produces Google & OS maps and Signal profile with no
observable delay using Chrome versions:
7.0.524.0 canary build
6.0.472.62 beta
Input. Receiving aerial = Post Code and selecting transmitter from UK
National list.
--
Ken O'Meara
http://www.btinternet.com/~unsteadyken/
Java Jive
<usenet....@adslpipe.co.uk> wrote:
> Java Jive wrote:
>
> > h t t p : / / w w w . m a c f h . c o . u k /
> > PrivTest
>
> The signal profile certainly loads much faster then the previous
> version,
Yes, the data is now read by a python script on the server direct from
the SRTM files, where necessary interpolating over data voids and
between the four nearest data points. Previously, with my friend's
system, all the points were held in a Google App Database which was
much slower. The only slight downside may be scalability, but I
already have a back up system in a Google App if that should prove to
be a problem. The speed of that should still be quite a bit faster
than the previous system, because it reads the data directly from the
files in the same way as the new system, but the files have has to be
left in their downloaded zipped form to get over Google App's size
limits, so, if I find I have to use it, it will be somewhat slower
than the current new system.
> I take it it's deliberate to show the fresnel zones above the
> LoS as well as below it now?
Yes, it's deliberate to show the top half of the zones as well, to
give a better idea of the amount of obstruction. I thought it was
useful to show that because initially by default the method of
calculation ignores transmitters whose paths are obstructed beyond the
top of the Fresnel zone, and only does an extra iteration looking
again at such transmitters if the first iteration finds none likely to
give a useable signal.
> What does the "clutter" consist of (buildings, trees?) and where do you
> grab the data for that from?
It's a free dataset from the University of Maryland, having a 1km
resolution - not ideal but it's all I could find for free. I
decided to implement the data by assigning arbitrary heights to the
different types of clutter, which are simply added to the terrain
height at the point in question. The following comment from the
python script gives details which may be of interest, or may be too
much information (the BI Freq column is the frequency of that clutter
type within the BI file). I accept that these height ratings are
something of a judgement call, and am open to argument on what the
figures should be:
# University of Maryland's 1km Global Land Cover Data:
http://www.geog.umd.edu/landcover/1km-map.html
# UMD1km_L_BI.bin is an extract from UMD1km_L.img covering the British
Isles 11W to 3E, 49N to 60N
# Format: X,Y starting from 11W,49N, Lon within Lat, 120 x 120 pixels
per degree, 1800 x 1440 pixels
# ID BI Freq Ht Inc Description
# 0 1889706 0 Water
# 1 6514 20 Evergreen Needleleaf Forest
# 2 0 20 Evergreen Broadleaf Forest
# 3 0 20 Deciduous Needleleaf Forest
# 4 530 20 Deciduous Broadleaf Forest
# 5 2538 15 Mixed Forest
# 6 53814 15 Woodland
# 7 243316 5 Wooded Grassland
# 8 3209 4 Closed Shrubland
# 9 80 2 Open Shrubland
# 10 255222 0 Grassland
# 11 116061 1 Cropland
# 12 0 0 Bare Ground
# 13 21010 15 Urban And Built-Up
The UMD data comes as one large file covering most the globe, from
which I extracted, as with the SRTM data, the range of lat/lon which
included the UK, CI, NI, and Eire (so it therefore has exactly the
same coverage area as the SRTM data on the server).
This means that users anywhere in the British Isles and Channel
Islands can now get a signal path profile, not just UK mainland as
previously.
Java Jive
BTW, did you try a "Find the likeliest" search, and if so, did it give
sensible results?
On Wed, 22 Sep 2010 17:15:49 +0100, UnsteadyKen
<unste...@gmail.com> wrote:
>
> Works fine and produces Google & OS maps and Signal profile with no
> observable delay using Chrome versions:
> 7.0.524.0 canary build
> 6.0.472.62 beta
>
> Input. Receiving aerial = Post Code and selecting transmitter from UK
> National list.
--
UnsteadyKen
> BTW, did you try a "Find the likeliest" search, and if so, did it give
> sensible results?
Yes, I'm here http://goo.gl/JSu8 in Corby and it picked Waltham which
at 21 miles is the nearest but most people use Sandy Heath at 34 miles
as we think of ourselves as East Angulars not Middle Landers
Andy Burns
> I'm here http://goo.gl/JSu8
How do you get the google url shortener to do that, when I've wanted to
create a link, it just seems to tell me it's for google's own use not
mine ...
Java Jive
On Wed, 22 Sep 2010 20:24:19 +0100, UnsteadyKen
<unste...@gmail.com> wrote:
> Java Jive said...
>
> > BTW, did you try a "Find the likeliest" search, and if so, did it give
> > sensible results?
>
> Yes, I'm here http://goo.gl/JSu8 in Corby and it picked Waltham which
> at 21 miles is the nearest but most people use Sandy Heath at 34 miles
> as we think of ourselves as East Angulars not Middle Landers
--
UnsteadyKen
> How do you get the google url shortener to do that, when I've wanted to
> create a link, it just seems to tell me it's for google's own use not
> mine ...
I use Google Chrome and the shortener is installed as a Chrome
extension, I hadn't realised that it wasn't generally available.
http://goo.gl/
Andy Burns
> I use Google Chrome and the shortener is installed as a Chrome
> extension
Yes, I spotted the extension, but I only use Chrome for testing.
> I hadn't realised that it wasn't generally available.
> http://goo.gl/
If you visit the website, it effectively says "go away, this isn't for
you sunshine" I did see one article about how to fool it into generating
an URL, but I'll stick with tinyurl.
PeterC
> On Wed, 22 Sep 2010 16:23:19 +0100, PeterC
> <giraffe...@homecall.co.uk> wrote:
>>
>> The Signal Profile is a bit frightening, having what
>> appears to be the highest point - 160m - about 12km away (my aerial is at
>> about 90m) towards Oxford.
>
> 'Frightening'? Is perhaps that a euphemism for 'Wrong'? I'd rather
> know the truth if it is ...
Just that is shows as a 'peak' in a flattish area. However, the land there
goes to about 130m then has woods on it, so not far out, at about SP 73 44
http://tinypic.com/view.php?pic=20t2xxs&s=7
>
>> The DigitalUK checker is correct about using Sandy Heath at the same
>> distance but can't take account of the N. Coast main line about 100m away -
>> or the trains atop that and the interference.
>
> Does the embankment show up on the calc's signal path profile? The
> underlying SRTM data has a resolution of about 90m, so it's probably a
> matter of chance whether it does or not.
Damn me, it does!
http://tinypic.com/view.php?pic=11w9hec&s=7
last little bump.
The hump next in line is about correct as well.
>
>> I notice that Sandy Heath has both dates in but Oxford doesn't, but ISTR
>> that they're about the same.
>
> No dates for Oxford yet other than just '2011', see the Digital UK
> link I gave in the original thread.
>
Yes, thanks, that's where I looked.
I might just have a Log40 aerial installed and be done with it.
> Thanks for the feedback.
--
Java Jive
<giraffe...@homecall.co.uk> wrote:
>
> Just that is shows as a 'peak' in a flattish area. However, the land there
> goes to about 130m then has woods on it, so not far out, at about SP 73 44
> http://tinypic.com/view.php?pic=20t2xxs&s=7
Yes that description agrees with the OS map for that location (sigh of
relief).
However, that picture comes from the old calculator. I can tell
because the top of the Fresnel zone is not displayed, and there's no
clutter shown.
> >> The DigitalUK checker is correct about using Sandy Heath at the same
> >> distance but can't take account of the N. Coast main line about 100m away -
> >> or the trains atop that and the interference.
> >
> > Does the embankment show up on the calc's signal path profile? The
> > underlying SRTM data has a resolution of about 90m, so it's probably a
> > matter of chance whether it does or not.
>
> Damn me, it does!
> http://tinypic.com/view.php?pic=11w9hec&s=7
> last little bump.
That's the old calculator as well.
But, except for the clutter, the new one calculator should look much
the same as the old one, I've compared several location up and down
the country, and they all looked the same in both calculators.
Java Jive
On Wed, 22 Sep 2010 15:16:10 +0100, Java Jive <ja...@evij.com.invalid>
wrote:
>
> As it happens, I'm currently working on a new version of the
> calculator that doesn't rely on my friend's Google App Engine terrain
> database, but reads SRTM height and UMD clutter data directly - the
> latter is an enhancement not in the current live version.
The normal live URL is now redirecting automatically to a compressed
*.php version in the same directory (which will load quicker).
It will probably be necessary to <shift-reload> the page to ensure
that altered scripts and data files are picked up from the server
rather than from cache. With some browsers this may not be enough, it
may be necessary to clear the cache.
> One of the resources that takes longest to load is the almost 1Mb of
> OpenLayers code for drawing the OS map, and that begins to load after
> the form is unlocked ready for user entry. Therefore, if you set a
> search going immediately the form unlocks, you will get a timeout or
> two, though usually the search will complete eventually.
I've made a cut down, compressed version of the OL code, which loads
much more quickly.
In many, hopefully most, circumstances where the user has data to
enter into the form, OL should've just about finished loading by the
time the user is ready to choose 'Find the likeliest', so the problem
previously described should not then occur. However, where the form
picks up data via the URL parameters, and the user chooses 'Find the
likeliest' at the earliest possible opportunity, then timeouts may
still occur, but the 'Find' should still complete given enough time.
> Technical explanation: In an attempt to reduce demands on the server,
> I've commented out some code that, when a search is recommenced, wipes
> the data not yet completely received, which was forcing a new series
> of GETs to the server. I've done this because the majority of it will
> be successfully received, and it is therefore pointless to refetch it.
However, Opera is so hopeless at letting the programmer know that a
GET has failed, that eventually I had no choice but to put the code
back in, just for the one browser.
Java Jive
>
> I found the link.
Just to clarify, this is the link you should be using:
http://www.macfh.co.uk/JavaJive/AudioVisualTV/TerrestrialTV/TerrestrialCalculator.php
> If I use Safari, it goes into a loop forever.
Oo-er!
In response, I've just tested Safari v5.0.2 on W7, firing 5 or 6 UK
postcodes and two UK place names at it, and, although it timed out on
one, it successfully completed 'Find the likeliest' for all the inputs
I gave it.
Can you help me to help you by:
a) Confirming that you've cleared the browser's cache. Three scripts
and the format of the data files has changed, so it is important to
ensure that the browser is not trying to use old versions from its
cache.
b) Confirming that your client will accept compression. As
indicated, I have had no problems with Safari v5.0.2, but perhaps you
are using Safari Mobile? If so, in my own self-defence I will point
out that neither this nor the Satellite Calculator were ever intended
to be used on such a small screen device, if they happen to work on
any, that's a bonus.
c) Which of the following numbered processes is hanging?
1) Basic normal loading as with any other page. The page is quite
big however - it's got a lot of HTML, JavaScript, and data (besides
the complicated functionality that must be achieved, there are over
1100 transmitters in the UK) - so this may take as little as 10s for
a reload, or as many as 60s or even more for a first time load with a
slow browser such as IE6 on a slow machine, say a PIII. However, the
page is now compressed, which should help significantly compared with
earlier versions. You can tell when this process has completed,
because the page is displayed in full, but the form is greyed out as
it has not yet been initialised.
2) Next the site statistics are updated. Unfortunately, this
sometimes takes too long, several seconds, and I'm considering
alternative ways of achieving this. There are various ways of
gathering site stats, but no individual one is utterly reliable. There
is usually a message concerning 'statcounter' in the status bar during
this process.
3) Next there is a period of high CPU activity while an
initialisation routine loops through all the form elements giving them
correct initial values. This takes as little as a few seconds on some
browsers to as many as 20s in IE6, W2k, 3GHz P4. When this completes
the form unlocks and the user, you, can start to enter data.
4) Next, while hopefully the user is setting up the form with his/her
desired data, the OpenLayers and Google mapping scripts are loaded in
the background. As each script loads, the corresponding map button is
made visible.
Subsequently, the only processes that are likely to hang are:
5) So that maps will both run and print properly, the page loads in
Compatibility View even in IE8, which means that all versions of IE
will use the much slower IE6/7 JavaScript engine. On a sufficiently
slow machine such as a 1GHz PIII, a browser can appear to have hung
while loading the 'UK National List' (over 1100 transmitters = over
1100 <option> tags to be loaded into the <select> element for choosing
a transmitter). The browser may give a message that the script is not
responding, but if the users perseveres, and chooses 'Continue',
perhaps as many as three times, it will eventually complete
successfully, the form will unlock, and the <select> tag will give a
choice of all the UK's transmitters.
6) The 'Find the likeliest' option is the likeliest to hang. I've
not attempted to disguise the fact that this is the piece of
functionality that has given me most problems. Getting good,
self-consistent, and reliable transmitter data from all the
conflicting sources was quite bad enough, as was deciding on a method
of calculation that was passably accurate yet achievable in a
browser's JavaScript.
However the real problem has been in fetching data asynchronously from
the server in such a way that no matter how it might fail, the routine
will recover - if not (for preference) 'on the fly', at least at the
next timeout - so that it can eventually complete successfully. The
problem is that there is no accepted method in the client's JavaScript
of reliably determining if a GET has failed. Although I've tested it
a great deal IE6, Opera 9, and FF3, and quite a lot in IE8, Chrome 5,
and Safari 5, and a little, though not recently, in Opera 10, I'm sure
that out there will be a combination of browser, operating system, and
hardware platform that will break it!
> A Java problem?
Java is not used in the system. JavaScript is used on the client's
browser, and the terrain and clutter files are read by python scripts
on the server.
Java Jive
>
> I meant Java Script.
Ok, I wondered if you did, but Java can be used in web pages as well.
> I have the latest version of Safari, I am running it on a Dell 4550 PC with
> WinXP. I have not had any other problems using Safari.
>
> It got as far as correctly suggesting the full location (Ruswarp Yorkshire) and
> the TX location Whitby Yorkshire correctly and then went into sulk mode.
>
> I reset Safari before trying.
>
> I tried again with the link you gave above and it works.
>
> I tried a post code and Sheffield and that worked too.
Phew (wipes sweat off brow)!
> Yesterday I took the link from your website. I hope that explains it.
Odd! I think everything else on the site has been linking to the
correct version of the page for a couple of days now, and I tested all
the changed links before posting here yesterday.
You didn't by any chance use the old test page under /PrivTest/etc did
you?
Glad it's sorted anyway.