How did this translator get here?

[ssnake]

I recently started school at the University of Georgia, and I am helping the student station, WUOG, with engineering.

Although the station is well staffed and manages to stay on the air live all day, every day, it seems like some aspects have been neglected, like engineering and FCC paperwork. The station is currently operating on an STA since they did not file a license renewal on time (the advisor did not click the final submit button).

WUOG is located in Athens, Ga., about 65 miles from Atlanta, and broadcasts with 26kW from 55m HAAT. Just 38 miles away, towards the Atlanta suburbs, is a co-channel translator, W213BE, rebroadcasting a satellite format with 10W from 77m AGL (and 0m HAAT, but I haven't verified that). According to the contour overlap rules, the 40dBu interfering of the translator (6+ miles) should not overlap with our 60dBu protected (19 miles). Just based upon that, the translator should be allowable, but I have not computed HAAT along the radials or taken into account WUOG's directional pattern.

However, the translator seems to carry much further than the predicted distance, and it is interfering significantly with our fringe coverage towards Atlanta. It went on the air in 2000 and had its license renewed last year, but I am sure no one at WUOG knew to object.

Is there any way to challenge this translator? Has anyone here had experience dealing with interfering co-channel translators?

Under 47 CFR 74.1203(a)(1), An authorized FM translator or booster station will not be permitted to continue to operate if it causes any actual interference to: The transmission of any authorized broadcast station. How does one demonstrate "actual interference"?

 

[tpt]

Once your license is renewed have a few "listeners" (e.g., someone connected with the school) file complaints about the interference from the translator.

Sit back and watch the FCC do nothing.

Then go to the "right" part of town, slip one of those guys on the corner a few bucks, and have him sharpen a machete on the translator's feedline.

Seriously, you will get nowhere with the FCC. 38 miles is 61 kilometers separation. The translator's 40 dbu seems to be between 20 and 24 km out, depending on azimuth; while WUOG's 60 dbu varies between 20 and 30 km. depending on the radial. Hence the contours don't overlap. (if you don't have the program to generate these contours, send me a note directly & I'll send you WORD files showing the respective contours)

Even if they did overlap, the Commission has decided to ignore it's own rules by espanding the loophole at Sec. 74.1204(d). If you can find it, read the recent FCC decision on a protest by the Lousivlle Public Library (WFPL) of a translator app. inside it's protected contour.

 

[ssnake]

That's disappointing, but I think I can distinguish that case in that it was a second-adjacent to the WFPL, and the translator applicant used "unpopulated area" arguments. I am thinking that if I can show that "actual listeners" to WUOG, a full-service station, are being affected, whether in the protected contour or not, I should be able to support an objection. Whether the FCC will listen is is another thing.... As near as 25-30 km away, the translator is on top of WUOG depending on multipath.

I wonder if we might be able to increase the power on a lobe toward Atlanta when the next filing window opens. If the translator is operating in that direction, my guess is that there is might be area we could add. Then we would kick out the translator.

Is there a free program out there to calculate the HAAT along a radial?

In the few days that I've been working with the station, I can say that I've already greatly increased the coverage area; their news/talk studio console was connected out-of-phase with the main board. I'm sure the folks with mono radios are welcoming the opportunity to listen to our public service programming for the first time in years.

> Once your license is renewed have a few "listeners" (e.g.,
> someone connected with the school) file complaints about the
> interference from the translator.
>
> Sit back and watch the FCC do nothing.
>
> Then go to the "right" part of town, slip one of those guys
> on the corner a few bucks, and have him sharpen a machete on
> the translator's feedline.
>
> Seriously, you will get nowhere with the FCC. 38 miles is
> 61 kilometers separation. The translator's 40 dbu seems to
> be between 20 and 24 km out, depending on azimuth; while
> WUOG's 60 dbu varies between 20 and 30 km. depending on the
> radial. Hence the contours don't overlap. (if you don't
> have the program to generate these contours, send me a note
> directly & I'll send you WORD files showing the respective
> contours)
>
> Even if they did overlap, the Commission has decided to
> ignore it's own rules by espanding the loophole at Sec.
> 74.1204(d). If you can find it, read the recent FCC
> decision on a protest by the Lousivlle Public Library (WFPL)
> of a translator app. inside it's protected contour.
>

 

[BrokeEngineer]

OT

Hey ssnake, what ever happened to that Codec you were writing code for? I remember you passing along a screen shot....any luck with it?

 

[ssnake]

Re: OT

> Hey ssnake, what ever happened to that Codec you were
> writing code for? I remember you passing along a screen
> shot....any luck with it?

Yes, there seems to be a lot of interest in IP codecs these days, at least judging by the radio-tech mailing list.

The status is: I've rewritten it in Java, so it will run on Windows, and added support for MP2, Speex and Ogg Vorbis. It works.

But I still have to:
(1) Make an installation process
(2) Provide connection quality feedback on the remote end
(3) Improve stability

I'm back in school again, so I don't have a lot of time to work on it at the moment unfortunately. I might release a beta version after I finish (1).

 

[tpt]

Don't need a window if you can do a minor change.

Hoiwever, appears the station is already directional, so you may find the channel a bit tight for any changes.

 

[CW]

> Don't need a window if you can do a minor change.
>
> Hoiwever, appears the station is already directional, so you
> may find the channel a bit tight for any changes.
>
IIRC a minor change also includes a change of one channel up or down on an AM and even a transmitter site relocate right??

Funny how some things that should be considered major are included in "minor"
changes

 

[ssnake]

> Don't need a window if you can do a minor change.
>
> Hoiwever, appears the station is already directional, so you
> may find the channel a bit tight for any changes.

I'll have to look into the minor change rules, but I think expanding out of the existing contours is precluded.

I can't find the current directional polar plot online, because the facility ID and call sign are invalid, from the license cancellation. I'm sure the public file has it though... I hope.

There was a study done in the early 90s that showed the potential to upgrade to 65 kW at the current, low height. I don't know if that opportunity still exists, but the decision to upgrade only to 26kW may have been a cost tradeoff, given that they already had to buy a 20kW transmitter to feed the chosen, low-gain antenna. There might even be RFR issues, since it is located on top of a dorm.

 

[SamBuca]

Re: OT

> Yes, there seems to be a lot of interest in IP codecs these
> days, at least judging by the radio-tech mailing list.

Is it TCP or UDP? If it's TCP, do you set the TTL to 0? I'm curious as to how you avoid the retransmission delay.<P ID="signature">______________
</P>

 

[Neal]

I sure hope we are Not talking about a translator.
The MAX power output for a translator is only 250 Watts.



sounds Like your talking about a full Power station.
65kw ? 26kw? 20kw transmitter with an 8-12 bay to get 65kw
is far from a Low gain antenna. and that would be a Minor change,
No way

Im dizzy reading this thread..
>
> There was a study done in the early 90s that showed the
> potential to upgrade to 65 kW at the current, low height. I
> don't know if that opportunity still exists, but the
> decision to upgrade only to 26kW may have been a cost
> tradeoff, given that they already had to buy a 20kW
> transmitter to feed the chosen, low-gain antenna. There
> might even be RFR issues, since it is located on top of a
> dorm.
>

 

[ssnake]

Sorry for the confusion. Here's the deal:

(1) NCE college station broadcasts with 26kW DA/55m HAAT
(2) Satellite translator broadcasts with 10W/77m AGL just 38 miles away on the *same channel*

According to the rules for contour overlap, the translator is legal. BUT, it is causing significant actual interference to the fringe coverage of (1) towards a more densely populated area.

I want to find a way to knock out the translator or otherwise make it discontinue interference in areas where our signal is listenable. The two methods I have considered are:

(1) Complain to the FCC and substantiate actual interference with listener testimony; or
(2) If permissible, modify the directional pattern to expand the contours towards the densely populated area.

Keep in mind, this is in the reserved band, so we have no one-step power upgrades; lots of odd, directional facilities; and networks of translators that relay by satellite.

> I sure hope we are Not talking about a translator.
> The MAX power output for a translator is only 250 Watts.
>
> sounds Like your talking about a full Power station.
> 65kw ? 26kw? 20kw transmitter with an 8-12 bay to get 65kw
>
> is far from a Low gain antenna. and that would be a Minor
> change,
> No way
>
> Im dizzy reading this thread..

 

[ssnake]

Re: IP RPUs

> > Yes, there seems to be a lot of interest in IP codecs
> these
> > days, at least judging by the radio-tech mailing list.
>
> Is it TCP or UDP? If it's TCP, do you set the TTL to 0?
> I'm curious as to how you avoid the retransmission delay.

It's UDP, of course, but I use an RTP stack to give me connection management and sequencing. With TCP, you also have to worry about the congestion control -- additive increase, multiplicative decrease, and slow start. If you lose a packet, you want to continue transmitting regardless, although the application developer might want to use the packet-loss information to change the codec.

Thus, to avoid dropouts, we are limited to networks than can guarantee QoS, or those which have no TCP flows that will try to max out the link. IP is a best-effort protocol, so in absence of an Automatic Repeat ReQuest (ARQ) protocol like TCP, we need to use Forward Error Correction (FEC) to protect against dropouts, especially on the Internet.

The easiest FEC is to send duplicate packets with the same sequence number, but this also has the highest overhead. So long as you leave some overhead in the link for TCP flows, this will give you fewer actual dropouts. A more sophisticated FEC uses code packets (e.g. Reed-Solomon coding) to give you a way to reconstruct lost audio packets from the packets you have received. This requires a modest buffer, which you need for out-of-order packets anyway.

Not having modified the RTP stack, I have achieved end-to-end delays of better than 1000 ms. I'm using the Java Media Framework, which has some imperfections that need to be addressed in order to get this down. Also, because it uses JavaSound, a relatively significant soundcard buffer (say 250 ms) is required to avoid skips due to Windows process switching.

I've been working on this issue for a few years, partly as my graduate research in networking. I really want to get a useable free program out there because I think the prices being charged for similar software are ridiculous.

Here's a screenshot of my interface:
http://opdesk.wrek.org/~thomas/ipremotescr.jpg

 

[tpt]

I have the information in the Contour program, which can be converted into a polar plot with some polar paper.

Send me a contact off line & I'll send what I have; you can reach me at:

[email protected]

 

[techie]

Re: IP RPUs

> > > Yes, there seems to be a lot of interest in IP codecs
> > these
> > > days, at least judging by the radio-tech mailing list.
> >
> > Is it TCP or UDP? If it's TCP, do you set the TTL to 0?
> > I'm curious as to how you avoid the retransmission delay.
>
> It's UDP, of course, but I use an RTP stack to give me
> connection management and sequencing. With TCP, you also
> have to worry about the congestion control -- additive
> increase, multiplicative decrease, and slow start. If you
> lose a packet, you want to continue transmitting regardless,
> although the application developer might want to use the
> packet-loss information to change the codec.
>
> Thus, to avoid dropouts, we are limited to networks than can
> guarantee QoS, or those which have no TCP flows that will
> try to max out the link. IP is a best-effort protocol, so
> in absence of an Automatic Repeat ReQuest (ARQ) protocol
> like TCP, we need to use Forward Error Correction (FEC) to
> protect against dropouts, especially on the Internet.
>
> The easiest FEC is to send duplicate packets with the same
> sequence number, but this also has the highest overhead. So
> long as you leave some overhead in the link for TCP flows,
> this will give you fewer actual dropouts. A more
> sophisticated FEC uses code packets (e.g. Reed-Solomon
> coding) to give you a way to reconstruct lost audio packets
> from the packets you have received. This requires a modest
> buffer, which you need for out-of-order packets anyway.
>
> Not having modified the RTP stack, I have achieved
> end-to-end delays of better than 1000 ms. I'm using the
> Java Media Framework, which has some imperfections that need
> to be addressed in order to get this down. Also, because it
> uses JavaSound, a relatively significant soundcard buffer
> (say 250 ms) is required to avoid skips due to Windows
> process switching.
>
> I've been working on this issue for a few years, partly as
> my graduate research in networking. I really want to get a
> useable free program out there because I think the prices
> being charged for similar software are ridiculous.
>
> Here's a screenshot of my interface:
> http://opdesk.wrek.org/~thomas/ipremotescr.jpg
>

I would love to try this thing out if you ever put out a beta.

 

[taylorengineer]

Re: IP RPUs

> > > > Yes, there seems to be a lot of interest in IP codecs
> > > these
> > > > days, at least judging by the radio-tech mailing list.
>
> > >
> > > Is it TCP or UDP? If it's TCP, do you set the TTL to 0?
>
> > > I'm curious as to how you avoid the retransmission
> delay.
> >
> > It's UDP, of course, but I use an RTP stack to give me
> > connection management and sequencing. With TCP, you also
> > have to worry about the congestion control -- additive
> > increase, multiplicative decrease, and slow start. If you
>
> > lose a packet, you want to continue transmitting
> regardless,
> > although the application developer might want to use the
> > packet-loss information to change the codec.
> >
> > Thus, to avoid dropouts, we are limited to networks than
> can
> > guarantee QoS, or those which have no TCP flows that will
> > try to max out the link. IP is a best-effort protocol, so
>
> > in absence of an Automatic Repeat ReQuest (ARQ) protocol
> > like TCP, we need to use Forward Error Correction (FEC) to
>
> > protect against dropouts, especially on the Internet.
> >
> > The easiest FEC is to send duplicate packets with the same
>
> > sequence number, but this also has the highest overhead.
> So
> > long as you leave some overhead in the link for TCP flows,
>
> > this will give you fewer actual dropouts. A more
> > sophisticated FEC uses code packets (e.g. Reed-Solomon
> > coding) to give you a way to reconstruct lost audio
> packets
> > from the packets you have received. This requires a
> modest
> > buffer, which you need for out-of-order packets anyway.
> >
> > Not having modified the RTP stack, I have achieved
> > end-to-end delays of better than 1000 ms. I'm using the
> > Java Media Framework, which has some imperfections that
> need
> > to be addressed in order to get this down. Also, because
> it
> > uses JavaSound, a relatively significant soundcard buffer
> > (say 250 ms) is required to avoid skips due to Windows
> > process switching.
> >
> > I've been working on this issue for a few years, partly as
>
> > my graduate research in networking. I really want to get
> a
> > useable free program out there because I think the prices
> > being charged for similar software are ridiculous.
> >
> > Here's a screenshot of my interface:
> > http://opdesk.wrek.org/~thomas/ipremotescr.jpg
> >
>
> I would love to try this thing out if you ever put out a
> beta.
>
Naw.....snake is too busy gettin' the law degree....it'll be a few years until he gets the time to write the code!!
How's it goin' over there, ssssnake?? I see your in head deep fixing the Bulldawg station....I can still loan you some chain link fence to hang behind that 4 bay....that'll take care of that bible thumpin' translator. As for the studio being out of phase.....well....after listening to the snoozola coming out of most "student stations".....I think "out of phase" could be considered an enhancement.
Are you the new engineer or did they already have someone to unstop the toilet?

 

[ssnake]

Re: College stations

> Naw.....snake is too busy gettin' the law degree....it'll be
> a few years until he gets the time to write the code!!
> How's it goin' over there, ssssnake?? I see your in head
> deep fixing the Bulldawg station....I can still loan you
> some chain link fence to hang behind that 4 bay....that'll
> take care of that bible thumpin' translator. As for the
> studio being out of phase.....well....after listening to the
> snoozola coming out of most "student stations".....I think
> "out of phase" could be considered an enhancement.
> Are you the new engineer or did they already have someone to
> unstop the toilet?

I sure wish they had a engineer like you on call... I have yet to meet him, but their engineer is in his 80s, and despite being at the station since it signed on in 1972, it doesn't appear that he's on top of the issues. Some I have identified:
- Peak mod is around 90%
- None of the console channels have been calibrated for levels
- They are mostly using black wires for high and red wires for low
- Probably more phase issues due to wiring
- Sloppy excess stripping of wire insulation allows bare wires to short when nudged
- Little in the way of effective cable management
- No central interconnect or patch bay before STLs; everything is hard-wired
- Analog STLs are running at 10W TPO despite a path length of only about 1km
- The computer being used to play promos doesn't have the Windows dings and dongs muted
- When the station is signed on, the operators have to raise the power level manually
- Streaming is being fed off of a table-top radio rather than the program bus
- Different models of CD players are being used; no remote starts are hooked up
- They are running talk shows with one awful conference-call type microphone in the middle of the room
- I haven't been able to check out the public file because it has been in someone's locked office

And I could go on and on... it's a disaster.
I'm fairly busy with school as you have suggested, but I am looking into what can be done to try to marshal some effort among the student staff (mostly liberal arts majors) to get this fixed. A new studio is on the way, but that will be 5+ years from now.

 

[tpt]

Re: College stations

Naw.....snake is too busy gettin' the law degree....it'll be
> a few years until he gets the time to write the code!!

Oh no, another good engineer ruining his mind detangling torts, and trying to figure out why cause can be probable! ;-) !

Here in Ohio, we had to be fingerprinted first before we could crack open that first contracts book... Probably to save time later in our careers.