Transponder data stream references?

[Woofle]

I know that individual video and audio streams are defined by the DVB-S standard and are basically MPEG-2 (like standard definitions DVDs).

OK, but each transponder typically carries multiple independent streams of audio and video on them. So somehow all the bitstreams have to merge together into one master bitstream that the satellite downlinks to our satellite box, and presumably there's some "magic' inside the box that separates out the bits we want from the other channels that we don't.

If anyone is familiar with the transmit side of the equation, do each of the channel users somehow "cooperate" and merge their signals with the other uses sharing their transponder, or is there some central place where the bitstreams are multiplexed/merged together and uplinked to the satellite? In other words, are the uplinking stations participating in the sharing process, or is this somehow being done inside the satellite or at some central location?

Also, I notice when blind-scanning, that there's a tag associated with each stream. Does anyone know if that is encoded within each channel, or is some sort of "table of contents" thing. I'm thinking of some software ideas for automating the discovery of new feeds and.....
wondering if there are any formal specifications or URLs that say how the process works at a semi-technical level.

The technology is very interesting IMHO

Sorry for all the questions. Mostly, I have no idea where the standards for this sort of thing would be called or how you would find them.

It's mostly curiosity. Though if things work like I assume, there might be a place for "legitimate software hacking" in the sense of a box whose only function is to go to each satellite, check for any changes in the table of contents for each transponder, and send RS-232 or USB to a PC for each change, then search for new transponders and new FTA channels, then motor to the next satellite, repeat.... as often as you want.

Might be a really powerful way to find new feeds. Just a wild thought.

(I'm a programmer and have done some radio stuff, but nothing above 440 Mhz

 

[qwert1515]

You should take a look here: North American MPEG-2 Information


The simple answer: The information in the Transport Stream are usually incorrect because they are broadcasting to one of their stations that already knows all the required information. Since they usually do not know the other broadcasters information they only transmit their own.

How a receiver uses the TS Stream
When you blind scan the receiver finds active frequencies and the symbol rate, which is proportional to the amount of bandwidth/data the transponder transmits.

With the frequency and symbol rate the receiver tunes the mux and detects the PAT. Inside the PAT is the PMT which tells the receiver which PIDS (streams) belong to each channel.
Also in the PAT (optional) are the TDT, CAT, SDT, EIT, NIT.

The TDT contains the time that the broadcaster has set.
The CAT tells the receiver what the types of encryption are available in the stream.
The SDT has the channels that the provider has defined for their system.
The EIT has the program guide, if they choose to provide one.
The NIT has the other transponders that the provider is using.

The best example to explain the transport stream is in a "perfect condition", a good example is a subscription receiver.

1. When you turn the receiver on it decodes all the information from a transponder.
2. When you want to change the channel the receiver looks up the channel in the SDT, which provides the transponder ID number.
3. The receiver then looks up in the NIT the frequency information to TUNE.
4. Once the transponder is locked the receiver decodes the PAT, which contains the PMT, which tells the Receiver which streams to use for the audio and video.
The PAT also holds the time, encryption, and EPG for the channels on the transponder.

EDIT - The transport stream is a long binary/HEX stream.

A Simple Example (My made up transport stream ):

Transport Stream:
(Start)(Length)(PID)(Payload)(Stop)

I have defined the following:

Start: AA
Length: Second byte.
PID: Third byte
Payload: follows the PID.
Stop: FF

PID 1: Name
PID 2: Description
PID 3: Audio

Example:

AA1301536174656c6c69746547757973FF
[AA][0D][01][536174656c6c69746547757973][FF]

The above decoded would mean:

The length of the message is 13 bytes (0D in HEX), and I am using PID 1.

The Message/Payload is : SatelliteGuys

---
So an example of a stream is:
AA0D01536174656c6c69746547757973FFAA2702416d6572696361277320536174656c6c69746520496e666f726d6174696f6e20536f75726365FFAA0703506f6463617374FF

Made easier to read:
[AA][0D][01][536174656c6c69746547757973][FF][AA][27][02][416d6572696361277320536174656c6c69746520496e666f726d6174696f6e20536f75726365][FF][AA][07][03][506f6463617374][FF]

Decoded :

Name: SatelliteGuys
Description: America's Satellite Information Source
Audio: Podcast

A real transport stream has many messages following each other.

OK, I am done with this post

 

[Anole]

short answer

The multi-channel contents of each transponder is multiplexed together on the ground and sent to the satellite on a specific frequency.
The satellite receives the signal, changes it to the downlink frequency, amplifies it to 100 watts (or so) and sends it back to earth.

You could have multiple multiplex and uplink sites , each for a specific transponder, but in practice, much content is uplinked for multiple transponders from one location.
And, it depends on the bird.

And, since QWERT is still typing, he may come up with a better answer (see above)

 

[Woofle]

You should take a look here: North American MPEG-2 Information


The simple answer: The information in the Transport Stream are usually incorrect because they are broadcasting to one of their stations that already knows all the required information. Since they usually do not know the other broadcasters information they only transmit their own.

How a receiver uses the TS Stream
When you blind scan the receiver finds active frequencies and the symbol rate, which is proportional to the amount of bandwidth/data the transponder transmits.

With the frequency and symbol rate the receiver tunes the mux and detects the PAT. Inside the PAT is the PMT which tells the receiver which PIDS (streams) belong to each channel.
Also in the PAT (optional) are the TDT, CAT, SDT, EIT, NIT.

The TDT contains the time that the broadcaster has set.
The CAT tells the receiver what the types of encryption are available in the stream.
The SDT has the channels that the provider has defined for their system.
The EIT has the program guide, if they choose to provide one.
The NIT has the other transponders that the provider is using.

The best example to explain the transport stream is in a "perfect condition", a good example is a subscription receiver.

1. When you turn the receiver on it decodes all the information from a transponder.
2. When you want to change the channel the receiver looks up the channel in the SDT, which provides the transponder ID number.
3. The receiver then looks up in the NIT the frequency information to TUNE.
4. Once the transponder is locked the receiver decodes the PAT, which contains the PMT, which tells the Receiver which streams to use for the audio and video.
The PAT also holds the time, encryption, and EPG for the channels on the transponder.

EDIT - The transport stream is a long binary/HEX stream.

A Simple Example (My made up transport stream ):

Transport Stream:
(Start)(Length)(PID)(Payload)(Stop)

I have defined the following:

Start: AA
Length: Second byte.
PID: Third byte
Payload: follows the PID.
Stop: FF

PID 1: Name
PID 2: Description
PID 3: Audio

Example:

AA1301536174656c6c69746547757973FF
[AA][0D][01][536174656c6c69746547757973][FF]

The above decoded would mean:

The length of the message is 13 bytes (0D in HEX), and I am using PID 1.

The Message/Payload is : SatelliteGuys

---
So an example of a stream is:
AA0D01536174656c6c69746547757973FFAA2702416d6572696361277320536174656c6c69746520496e666f726d6174696f6e20536f75726365FFAA0703506f6463617374FF

Made easier to read:
[AA][0D][01][536174656c6c69746547757973][FF][AA][27][02][416d6572696361277320536174656c6c69746520496e666f726d6174696f6e20536f75726365][FF][AA][07][03][506f6463617374][FF]

Decoded :

Name: SatelliteGuys
Description: America's Satellite Information Source
Audio: Podcast

A real transport stream has many messages following each other.

OK, I am done with this post

Thanks!!!!!!!!!!

This is *exactly* what I was looking for. Basically I'm a geek and I want to know how it all actually works. And maybe script up something to find feeds.

(Though decoding the transponder stream is surely overkill for that -- a Perl script driving an IR LED and a receiver with RS-232 channel dump and a channel file comparison utility to ferret out changes between each scanning run could do the same job without having to understand the "how" of what the data stream looks like -- but what fun is that?
I was thinking about this because my fortec Merc II can dump its channel contents over RS-232 from IR remote control, so at least theoretically, it could be automated and dedicated to nothing but seaching for any changes in transponders and epage or auto-tune whatever just popped up new.

A lot of work. Just getting the basic concepts of how it all works is great.

Thanks again!

 

[qwert1515]

it could be automated and dedicated to nothing but searching for any changes in transponders

I use a similar procedure (One of my c++ programs) for hiding feeds from showing up on TheList from my sky scans

I sent you a PM, could you please send me a channel scan from the Mercury II? Thanks.

 

[Woofle]

The multi-channel contents of each transponder is multiplexed together on the ground and sent to the satellite on a specific frequency.
The satellite receives the signal, changes it to the downlink frequency, amplifies it to 100 watts (or so) and sends it back to earth.

You could have multiple multiplex and uplink sites , each for a specific transponder, but in practice, much content is uplinked for multiple transponders from one location.
And, it depends on the bird.

And, since QWERT is still typing, he may come up with a better answer (see above)

Oh, OK. Thanks for explaining. That makes great sense. I was envisioning that each channel within a transponder might be independently feeding its signal up to the satellite directly, but it occurred to me that due to the very precise timing required to make it work, and the variation in transmission delay vs. uplink location, that this would be a bear to get working (and if one station was a little out of sync, it might totally screw up the whole transponder.)

So it makes sense that there would be a central multiplexer for each transponder, that could do all the "magic" with a single master timing reference at a central location per transponder.

Thanks again! I'd be a dead cat if curiosity applied to satellite TV in the proverbial way.

 

[Woofle]

I use a similar procedure (One of my c++ programs) for hiding feeds from showing up on TheList from my sky scans

That's a great point and a good idea.

Having tools to find feed changes = good. Publishing them could be harmful. I was being selfish, just wanting a tool to find new stuff and keep my personal list up to date. ;P

Thanks. I see it's possible, and that's cool

Are you using Linux or Windows or some other animal, if you wish to comment?

 

[Woofle]

I use a similar procedure (One of my c++ programs) for hiding feeds from showing up on TheList from my sky scans

I sent you a PM, could you please send me a channel scan from the Mercury II? Thanks.

Oh, OK, I can do that too.

 

[qwert1515]

Are you using Linux or Windows or some other animal, if you wish to comment?

I am using Windows because I did a online video session and Microsoft sent Visual Studio free , since the programs are in c++ they could be ported to Linux easily.

TheList is also in PHP for the online parts.

EDIT - Thank you for sending me the channel scan, I looked at it quickly but I will look at it more tomorrow. Unfortunately it looks like the file is Binary/Hex so working with it will not be very easy.

 

[Woofle]

I am using Windows because I did a online video session and Microsoft sent Visual Studio free , since the programs are in c++ they could be ported to Linux easily.

TheList is also in PHP for the online parts.

EDIT - Thank you for sending me the channel scan, I looked at it quickly but I will look at it more tomorrow. Unfortunately it looks like the file is Binary/Hex so working with it will not be very easy.

Agreed. I also only looked at it briefly. There is a free program I found at download.com called Hexprobe which gives you an old-fashioned hex/ASCII display file editor like one used in the olden days to repair or undelete a DOS file before Norton Utilities came along.

I'm busy programming/working but should I get a few hours to figure out what the receiver format is doing, I may figure out enough to read the file with another app.

I was wrong about one thing though. You can't apparently do channel downloads and uploads via IR control, because the application wants to see the STD box powering up. Presumably this means you'd need to cycle power to fully automate scanning.

At any rate, the details of how this all works are very very cool IMHO

 

[Woofle]

The multi-channel contents of each transponder is multiplexed together on the ground and sent to the satellite on a specific frequency.
The satellite receives the signal, changes it to the downlink frequency, amplifies it to 100 watts (or so) and sends it back to earth.

You could have multiple multiplex and uplink sites , each for a specific transponder, but in practice, much content is uplinked for multiple transponders from one location.
And, it depends on the bird.

And, since QWERT is still typing, he may come up with a better answer (see above)

Thanks to your explanation, I think I now finally "grok" SCPC and MCPC.

If I understand correctly, from synthesizing your reply with the URL North American MPEG-2 Information, I'm guessing you're describing MCPC, with centralized multiplexing and timing.

And what I was thinking of originally sounds like SCPC, where you just carve out some dedicated frequency range for each uplinker, but relaxes the timing by setting aside some "slop" to remove the need for central or highly accurate synchronization.

I suppose most of those lyngsat "Feed" listings are SCPC and the TV broadcast stuff is MCPC? Am I anywhere near understanding this right yet?




So it looks like both are used, but I'm surprised how it works out.