Remote ATSC Transmitter Distribution Over IP Using Multi-Program Transport Stream

Application Example: Delivering 4 Subchannels from a Central Headend to Multiple Remote TV Transmitters

Broadcasters building a low-power television network often need a practical way to deliver multiple subchannels from one central location to remote transmitter sites. In many cases, the broadcaster already understands ASI transport and may be using an ASI-fed transmitter today, but wants to expand to several additional sites connected over leased fiber or public internet circuits.

A common question is whether DVB-ASI is obsolete and whether all transport must now move to IP. In practice, both methods remain useful. The more important issue is choosing the most efficient architecture for transporting a multi-program transport stream (MPTS) from the headend to each remote transmitter.

This application example shows how to use the Thor H-4ADHD-QAM-IPLL at the headend to generate a 4-program stream, then deliver that stream over IP to a remote Thor H-IRD-V3-ATSC, which converts the incoming IP transport stream back to ASI output for a transmitter. This creates a clean and scalable IP-to-ASI delivery path for stations that still prefer or require ASI at the final transmitter input. The H-4ADHD-QAM-IPLL product is listed here, and the H-IRD-V3-ATSC family / V3 IRD platform is documented here - read more.

System Goal

The goal is to distribute programming from a single master control / headend to remote transmitter locations. Each remote transmitter carries one physical ATSC channel containing up to four subchannels. Rather than placing all program origination equipment at every field site, the broadcaster creates the subchannels at the main facility and transports the resulting MPTS stream to each remote location over IP.

This is especially useful when:

• transmitters are located in different cities or coverage pockets

• programming originates from one central control room

• each site needs a stable transport stream delivered remotely

• the transmitter itself accepts ASI input, or the operator prefers ASI at the final handoff

How the System Works

At the central headend, four HDMI program sources are connected into the H-4ADHD-QAM-IPLL. This unit can encode and combine those programs into one multi-program transport stream and output that stream over IP. Thor’s product materials describe this unit as a 4-channel HDMI/component to COAX and IPTV HD modulator with separate IP stream output capability - read more.

That IP stream is sent over the customer’s WAN, leased fiber ethernet service, or public internet connection to the remote site. At the far end, the H-IRD-V3-ATSC receives the incoming transport stream and outputs ASI, allowing the broadcaster to connect directly into an ATSC transmitter that expects ASI. Thor’s IRD documentation states that the V3 series can receive RF, ASI, and IP sources and provide ASI/IP/video outputs, with the platform also supporting re-mux and program handling functions -  read more.

Recommended Architecture

Headend Equipment

Use one H-4ADHD-QAM-IPLL for each unique 4-program transport stream you want to create. If each remote transmitter needs a different set of four channels, then each destination will typically require its own dedicated headend encoder / MPTS generator. Thor’s product listing for the H-4ADHD-QAM-IPLL is here - click here.

Remote Site Equipment

Use one H-IRD-V3-ATSC at each transmitter site when the transmitter needs ASI input. The IRD receives the IP stream and outputs the equivalent transport stream as ASI. Thor’s IRD product page and manuals indicate support for ASI and IP TS processing in the V3 platform - read more.

Signal Flow Example

At the Headend

1. Four HDMI program feeds enter the H-4ADHD-QAM-IPLL

2. The unit encodes and multiplexes them into one MPTS

3. The MPTS is sent out over IP / UDP

4. Each destination site receives its own assigned stream

At the Remote Transmitter Site

1. The H-IRD-V3-ATSC receives the incoming IP transport stream

2. The IRD converts that stream to ASI

3. The ASI output feeds directly into the ATSC transmitter

4. The transmitter broadcasts the multiplexed subchannels over one 6 MHz ATSC channel

Why This Approach Makes Sense

This design is useful because it allows a broadcaster to keep the transmitter-side workflow simple while still benefiting from IP transport over long distances. Many stations are comfortable with ASI at the transmitter, even if the transport path between buildings or remote sites is IP-based.

Advantages of this design include:

• centralized program origination

• easy expansion to multiple remote sites

• ability to keep ASI as the final transmitter handoff

• reduced need for separate local encoding at each transmitter site

• straightforward point-to-point delivery across public internet or managed ethernet circuits

ASI vs IP: Which Is Better?

The conversation correctly pointed out that ASI is not obsolete. It is still a valid and widely understood transport format. What has changed is that more systems now move transport streams over IP because IP networks are easier to scale across distance.

In this application, the most practical answer is:

• use IP for transport between sites

• use ASI at the transmitter if that is what the transmitter prefers

This gives the broadcaster the best of both worlds.

Important Technical Note: MPEG-2 vs H.265

For standard ATSC 1.0 transmission in the United States, the final broadcast transport stream must remain compatible with ATSC receivers. In practice, that means the broadcaster must be careful about codec selection. The phone conversation was correct in distinguishing ATSC 1.0 workflows from newer compression discussions. The H-4ADHD documentation and Thor broadcast encoder family material are focused around broadcast transport workflows and MPEG transport stream handling. (thorbroadcast.com)

Network Topology Consideration

If the broadcaster is using public internet or provider-managed ethernet circuits between locations, the typical configuration is point-to-point. Each remote site gets its own dedicated stream.

If all sites were connected on one private local network, then multicast could also be considered. Thor’s H-4ADHD materials note unicast or multicast streaming capability, but real-world multicast use depends on the network design. (thorbroadcast.com)

Capacity and Channel Planning

One ATSC 1.0 channel has roughly 19.39 Mbps of usable payload. That total bandwidth can be divided among multiple subchannels. In practice, four HD/light HD services is a common planning point, though exact picture quality depends on bitrate allocation and content complexity.

This is why the H-4ADHD-QAM-IPLL is a practical fit for a 4-subchannel deployment: it matches a common real-world multiplexing need without immediately overloading the transport budget. Thor’s quick guide also shows TS assignment behavior for multiple outputs/program groupings - read more.

Example Use Case

A broadcaster operates one central master control and wants to feed programming to nine remote low-power transmitters. Each site carries one ATSC RF channel with four subchannels. The broadcaster already understands ASI and may already have one existing site using an ASI-fed workflow.

Using Thor equipment, the broadcaster can:

• install one H-4ADHD-QAM-IPLL per remote program group at the headend

• assign four HDMI inputs into one outbound MPTS

• send that stream over IP to the destination

• install one H-IRD-V3-ATSC at each remote site

• convert incoming IP to ASI

• connect ASI into the transmitter

This approach is especially attractive when transmitter vendors charge extra for custom IP transport options, or when the operator wants to preserve a familiar ASI-based transmitter input structure.

Thor Products Used in This Application

H-4ADHD-QAM-IPLL
4-channel HDMI/component HD to COAX and IPTV HD modulator with IP stream output capability. Product page: click here.

H-IRD-V3-ATSC
ATSC IRD / V3 platform for receiving transport streams and outputting ASI/IP/video, suitable for remote IP-to-ASI conversion. Product page and related V3 documentation: click here.

Conclusion

For broadcasters expanding a low-power ATSC network, the most efficient architecture is often not “ASI or IP” but rather IP transport with ASI handoff at the transmitter. The H-4ADHD-QAM-IPLL can generate a multi-program stream at the headend, and the H-IRD-V3-ATSC can recover that stream at the far end as ASI output, creating a clean bridge between centralized content origination and remote transmitter delivery. Thor’s product materials support the relevant roles for both devices in this workflow - read more.

If you want, I can turn this into a more polished SEO website article with HTML formatting for the Thor site.