How will the US local area stations commerate the end of System-M?

On May 1, 9:26*pm, Bruce Tomlin wrote:

I'm wondering if this is a coincidence, or if an adjacent analog channel
(even from the same antenna farm) really does make an ATSC station hard
to tune in.

If this is true, then the shut-off can't come any too soon for me.

Yup. It's not a coincidence. Analog stations tend to transmit at much
higher ERP than their digital counterparts, and this was especially
true in the early days of the transition. So what happens is that
receivers with less than ideal selectivity, as many of the older
models are, will detect the strong analog adjacent channel and clamp
down their AGC. This will then cause the much weaker digital station
you're tuned to disappear in the noise level.

Matter of fact, FCC tests have shown that it's not just adjacent
channels that are vulnerable, but also N +/- 2, and in some cases,
others as well.

Anyway, I've noticed things improving over time, mostly because
broadcasters have either increased the power of the digital signal, or
improved the digital antenna location on the tower, or both. And since
adjacent digital stations don't seem to cause any problem, even with
my two older receivers, I can't help but believe that shutting off
analog will help matters.

Bert

On May 2, 7:47*am, Dennis Majewicz wrote:

You guys are mixing this up a bit. No one is looking for an extension
to the analog shutoff date because of the dynamic PSIP requirement.
It's the fast-closing date of the new PSIP rule that's in question.

Okay, you're right. I was mixing the two.

My guess is that most of the stations in this country have no way of
constantly updating the EIT to reflect sports running long, breaking
news or weather or even network special reports. Or how about Idol
running a few minutes long?

We're all looking into the hardware, software and automation changes
required, but there doesn't seem to be any way to meet the May 30
deadline. The manufacturers aren't ready. This is the extension we're
looking for.

How does this work? Is an automatic scheme necessary, or can the times
be changed manually? For example, if a program is going to un 30
minutes longer, and the station decides to shift the rest of the
evening's schedule by 30 minutes, is it difficult to change the times
manually?

Bert

In alt.tv.tech.hdtv Albert Manfredi wrote:

| On May 1, 9:26?pm, Bruce Tomlin wrote:
|
| I'm wondering if this is a coincidence, or if an adjacent analog channel
| (even from the same antenna farm) really does make an ATSC station hard
| to tune in.
|
| If this is true, then the shut-off can't come any too soon for me.
|
| Yup. It's not a coincidence. Analog stations tend to transmit at much
| higher ERP than their digital counterparts, and this was especially
| true in the early days of the transition. So what happens is that
| receivers with less than ideal selectivity, as many of the older
| models are, will detect the strong analog adjacent channel and clamp
| down their AGC. This will then cause the much weaker digital station
| you're tuned to disappear in the noise level.

OTOH, if you put 2 stations on _adjacent_ channels, with the same ERP, then
they should be fine transmitting from the same tower.

Apparently it takes quite a strong signal to do that. Even though WPBY-TV
would boom right into my home in my teen to college years, I could still
get WOSU-TV just fine ... weak, but fine ... on a TV made around 1968.
WBPY-TV (then known as WMUL-TV) is on 33, and WOSU-TV is on 34.

Maybe it is the case that today's tuners, being all digital in design even
for analog signals, might have traded off more of the selectivity and are
actually worse.

--
|WARNING: Due to extreme spam, I no longer see any articles originating from |
| Google Groups. If you want your postings to be seen by more readers |
| you will need to find a different place to post on Usenet. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

On 2 May 2008 19:50:40 GMT, wrote:



| We're all looking into the hardware, software and automation changes
| required, but there doesn't seem to be any way to meet the May 30
| deadline. The manufacturers aren't ready. This is the extension we're
| looking for.

And when was the rule change actually passed? Or even proposed? Did they
really not have enough time, or did they drag their feet hoping it would all
just "go away"?


It was made mandatory in the recent Report and Order by the FCC (3rd
Periodic Review) released on Jan 30 of this year. There has been no
foot dragging. It's generally considered too short a time to comply.

DM

On Fri, 2 May 2008 15:50:55 -0700 (PDT), Albert Manfredi
wrote:

We're all looking into the hardware, software and automation changes
required, but there doesn't seem to be any way to meet the May 30
deadline. The manufacturers aren't ready. This is the extension we're
looking for.

How does this work? Is an automatic scheme necessary, or can the times
be changed manually? For example, if a program is going to un 30
minutes longer, and the station decides to shift the rest of the
evening's schedule by 30 minutes, is it difficult to change the times
manually?

Bert


Changing the EIT entries manually can be achieved, I think, but it's a
clumsy process in some cases (I'm going by the system we use). You
have to understand that TV stations don't operate like they have in
the past. Staffing has been cut and in cases such as ours, we don't
even have a master control operator on site. We are fed from a "hub"
in a distant city and during some hours of the day there are no
operators around. Hiring someone to enter PSIP data is out of the
question so we have to rely on an automated system to handle it.

Originally the EIT was to be a static table - it did not change. Two
years ago it was ordered that a dynamic PSIP be implemented that would
show a minimun of 9 hours ahead and ideally 3 days or so of correct
program info. This is the system we use now. Every night the editor
goes out and collects the Tribune xml file and updates the PSIP
generator. It's automated and works fine. Now this has to change and
I'm not sure there's anything out there that will work seamlessly with
our current system.

But it's not just changing the times. The mandated "accurate
information" will have to include titles in the case of breaking news
or other specials. And consider sliding a whole evening's schedule
because sports ran long. Newscasts are sometimes collapsed or
eliminated. It can really pile up and get to be a chore. Information
from the playback server's automation is the key but is still under
development.

DM

wrote in message
...


|
| KFMB is analog Ch 8 from Mount Soledad in San Diego. KFMB-DT is Ch 7
from
| the same place. No problems -- BUT -- I am receiving them with a UHF
| antenna. If I were to hook my box to a VHF antenna, the stronger signal
| might show up a problem. I'll try it and see what happens.
|
| I normally don't watch any VHF channels since all the locals are on
cable
| anyway. My real use for digital OTA is for LA stations that the local
| cableco doesn't import. They're all UHF.

But be aware that KABC-DT, KCAL-DT, KTTV-DT, and KCOP-DT will all be going
back to their VHF allocations (7, 9, 11, 13) post-transition. And you are
probably going to have problems with KFLA-LD on channel 8.

http://www.rabbitears.info/dtr.php

Thanks for the link. In/near San Diego, we will probably never see KFLA. I
see from the FCC web site that their antenna pattern has a deep null in my
direction and, given full-power KFMB or KFMB-DT on Ch 8 locally, that seals
it. (Maybe KFLA will never have anything I want. I'll hope.)

KCAL and KCBS are a duopoly, that is owned by the same company. I had heard
that on Day Zero KCBS-DT might move to Ch 9 and KCAL-DT might stay on Ch 43.
KCBS-DT must vacate Ch 60 on Day Zero and going digital on Ch 2 would seem
to be a bad move, given the known low-band noise problems. We shal see.

In alt.tv.tech.hdtv Dennis Majewicz wrote:
| On 2 May 2008 19:50:40 GMT, wrote:
|
|
|
|| We're all looking into the hardware, software and automation changes
|| required, but there doesn't seem to be any way to meet the May 30
|| deadline. The manufacturers aren't ready. This is the extension we're
|| looking for.
|
|And when was the rule change actually passed? Or even proposed? Did they
|really not have enough time, or did they drag their feet hoping it would all
|just "go away"?
|
|
| It was made mandatory in the recent Report and Order by the FCC (3rd
| Periodic Review) released on Jan 30 of this year. There has been no
| foot dragging. It's generally considered too short a time to comply.

Four months to update firmware and deliver it to the field? That depends on
the changes. But I don't see a time issue there ... from the perspective of
a programmer who has also programmed embedded stuff and built and loaded it
into device flash images. OK, so if the FCC gives them a couple more months,
can the get it done then? When are they saying they can deliver?

--
|WARNING: Due to extreme spam, I no longer see any articles originating from |
| Google Groups. If you want your postings to be seen by more readers |
| you will need to find a different place to post on Usenet. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

In alt.tv.tech.hdtv Dennis Majewicz wrote:

| Changing the EIT entries manually can be achieved, I think, but it's a
| clumsy process in some cases (I'm going by the system we use). You
| have to understand that TV stations don't operate like they have in
| the past. Staffing has been cut and in cases such as ours, we don't
| even have a master control operator on site. We are fed from a "hub"
| in a distant city and during some hours of the day there are no
| operators around. Hiring someone to enter PSIP data is out of the
| question so we have to rely on an automated system to handle it.

The PSIP data should come from the "hub". It should come from whoever
is changing the programming.


| Originally the EIT was to be a static table - it did not change. Two
| years ago it was ordered that a dynamic PSIP be implemented that would
| show a minimun of 9 hours ahead and ideally 3 days or so of correct
| program info. This is the system we use now. Every night the editor
| goes out and collects the Tribune xml file and updates the PSIP
| generator. It's automated and works fine. Now this has to change and
| I'm not sure there's anything out there that will work seamlessly with
| our current system.

Can you send me the DTD for that XML file? Then I might be able to comment
on just how complicated the update can be.


| But it's not just changing the times. The mandated "accurate
| information" will have to include titles in the case of breaking news
| or other specials. And consider sliding a whole evening's schedule
| because sports ran long. Newscasts are sometimes collapsed or
| eliminated. It can really pile up and get to be a chore. Information
| from the playback server's automation is the key but is still under
| development.

So the problem is that tying it to the playback server has NOT been done,
and it was really just a reflection of the original traffic schedule?

--
|WARNING: Due to extreme spam, I no longer see any articles originating from |
| Google Groups. If you want your postings to be seen by more readers |
| you will need to find a different place to post on Usenet. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

On May 2, 9:07*pm, wrote:

The PSIP data should come from the "hub". *It should come from
whoever
is changing the programming.

| Originally the EIT was to be a static table - it did not change.
Two
| years ago it was ordered that a dynamic PSIP be implemented that
would
| show a minimun of 9 hours ahead and ideally 3 days or so of
correct
| program info. This is the system we use now. Every night the
editor
| goes out and collects the Tribune xml file and updates the PSIP
| generator. It's automated and works fine. Now this has to change
and
| I'm not sure there's anything out there that will work seamlessly
with
| our current system.

Can you send me the DTD for that XML file? *Then I might be able to
comment
on just how complicated the update can be.

| But it's not just changing the times. The mandated "accurate
| information" will have to include titles in the case of breaking
news
| or other specials. And consider sliding a whole evening's
schedule
| because sports ran long. Newscasts are sometimes collapsed or
| eliminated. It can really pile up and get to be a chore.
Information
| from the playback server's automation is the key but is still
under
| development.

So the problem is that tying it to the playback server has NOT been
done,
and it was really just a reflection of the original traffic
schedule?

--
|WARNING: Due to extreme spam, I no longer see any articles
originating from *|
| * * * * Google Groups. If you want your postings to be seen by
more readers |
| * * * * you will need to find a different place to post on
Usenet. * * * * *|
| Phil Howard KA9WGN (email for humans: first name in lower case at
ipal.net) |

Who gives a hoot about those useless program guides anyway? Even if
they were all perfect, it is SO clunky to get the EPG updated as to be
useless. It takes the tuner minutes to go through all 18 carriers I
get. The TV is running on a computer anyway so Yahoo TV listings are
there in seconds and are more accurate besides

GG

On May 3, 1:24*am, G-squared wrote:

Who gives a hoot about those useless program guides anyway? Even if
they were all perfect, it is SO clunky to get the EPG updated as to be
useless. It takes the tuner minutes to go through all 18 carriers I
get. The TV is running on a computer anyway so Yahoo TV listings are
there in seconds and are more accurate besides

Stations don't have a choice, though. They need to comply, whether
users care or not.

As a viewer, I tend to agree with you. I have two older receivers that
make you wait while they gather the info from a few stations, before
drawing the matrix. Then, if you scroll down or to the rigth far
enough, another long wait until the received fetches the added
information. But this is entirely receiver-dependent. It doesn't have
to be done this way.

I have a new PVR/DVD recorder that takes a different approach. It only
shows the station you're tuned to, and basically devalues PSIP
entirely. It doesn't even provide the PSIP time.

I get the feeling there's a chicken and egg thing going on here. As
long as stations don't populate their EPGs well, e.g. including making
data available for a few days ahead of time, users will ignore the
EPG, and manufacturers won't spend time and money making it right.

Ideally, this EPG stuff COULD be a selling point for manufacturers,
just as the EPG is what made TiVo famous. Ideally, you'd see
manufacturers bragging about their great PSIP EPG in TV ads. Instead,
all you see in TV ads is the cable and DBS companies trying to lure in
more subscribers.

Bert