Coosat 8100HD: Weird behaviour

[Mike045]

I have a CS8100 and CS6100; the LNB feed signal goes first into CS8100, then CS6100. I have been watching NET (Nebraska PBS) on G28/89W lately and something really curious is happening: On the CS6100, all the signals are OK, but on CS8100, some channels like 9, 11, 15 pulsates about once a second: the video and audio are ON, then OFF, and so on; but on 14 and 21 (same program but one in SD, the other in HD) the signal stays constant. I would use the CS6100, was it not for the AC3 audio signal.
I have not encountered such a behaviour with others C or Ku signals; first time.
I am using 3740 H 25320 3/4 (funny, Lyngsat says instead 5/6; a typo ?). I am using the latest SW version on CS8100: 2.02.5A

Any idea ?


Mike

 

[brentb636]

My CS8000 is frquently squirelly when I have another device on the Loop out connector. I don't think they are very well isolated. Try turning off the lnb voltage of the CS6100 and see if that changes any behavior.

 

[Mr Tony]

Its not that brent...I just duplicated it on the 8000

First off...that signal is a bugger to get...on the 6 footer its barely 30 (which proves the FEC IS 3/4...I'll explain later)

Hooked up Pansat 1500 and all play flawlessly (minus the HD channel) minus audio (no AC-3 on the Pansat)
Hooked up Coolsat 5000 and all play flawlessly (minus the HD channel again)
Hooked up Coolsat 8000 and it does the EXACT same thing Mike you posted. The one second on, then black screen, then back etc

must be something with the software (I am using 2025 too)

reason I say the FEC is 3/4 because the Pansat plays them with no pixeling at 30 quality. This TV on 87W is 5/6 FEC and it pixelates at 30 quality (plays fine at 45)

 

[B.J.]

THis has been discussed a bit over in Satforums, and maybe a bit here (can't remember), however the problem is with the NET signal. It drives TSREADER absolutely crazy, with the PMT tabs blinking on and off.

The best I can figure it out, is that NET is sending out multiple PMT PIDs, with different information, some of which is corrupt. It's changing so fast, I can't figure out what information is different, but it's probably blank audio PID info or something like that. This behavior has been observed by other people as well.

Anyway, although TSREADER is affected, and will eventually bomb if you leave it on the transponder too long, my Azbox plays the video fine. I haven't tried with my Coolsat 8100 yet.

But anyway, since my theory is that it is corrupt PMT info that is responsible, I think that there is a good possibility that if you have a receiver that can create a manual PID type of channel, that the wierd behavior wouldn't occur, since it would basically be using a PMT that you've generated yourself. The problem is, however, that the Coolsat doesn't have a manual PID entry capability that will allow you to enter channels that have AC3 audio, and I'm pretty sure that most if not all the audio channels in this mux are AC3, although it's hard to tell with TSREADER because when you click on the audio PID, it instantly goes away when the corrupt PMT data kicks in every fraction of a second. So I think that a manually creaded channel might solve the problem, doing this with an 8100 might not be possible, and that actually might be related to why the 8100 is has a problem with this mux, ie perhaps the 8100 relies upon the PMT for info even after a channel has been created and stored.

But anyway, this is NOT the receiver's fault, it is a problem with the NET mux. Hope it's not intentional on NET's part, as it does nasty things to some receiver software, particularly if the receiver is relying upon the PMT for the info relative to what PIDs are used for audio.


EDIT: And yes, the FEC does calculate to a 3/4 FEC , ie bitrate of ~ 35000 and SR 25319 , however my Broadlogic control app seemed to be confused for a while relative to the FEC. Ie if first came up saying that the FEC was 1/2, but eventually stabilized saying that it was 3/4 . One more thing suggesting that there is a problem with the way they've put this mux together.

NET turned it off for a good 6 or 7 hours a couple days after they started it up, and I was hoping that they would fix the PMT thing, but if anything, it was worse after it came back on line.

EDIT2: BTW, TSREADER reports continuity errors, but ONLY on the PMT PIDs, which is related to my conclusion that they have corrupt PMT PIDs.

EDIT3: I've attached below a DVBSNOOP output of the PMT 553 for the channel 9. I only went 6 sections into the recording, so I'm not sure if I went far enough to see the problem area, and I'm not experienced enough with DVBSNOOP to know much about what I'm seeing. But I do see at least 3 different types of packets in this stream, but this may be normal, I'm not sure.
SORRY, I forgot to convert it for notepad display. It's linux output. Use Wordpad to display.

 

[Mike045]

Thanks guys; I thought for a moment that my CS8100 was at fault somehow.


Mike

 

[Mr Tony]

THis has been discussed a bit over in Satforums, and maybe a bit here (can't remember), however the problem is with the NET signal. It drives TSREADER absolutely crazy, with the PMT tabs blinking on and off.

found your post on it
http://www.satelliteguys.us/c-band-satellite-discussion/182476-pbs-g-28-a.html

The problem is, however, that the Coolsat doesn't have a manual PID entry capability that will allow you to enter channels that have AC3 audio, and I'm pretty sure that most if not all the audio channels in this mux are AC3, although it's hard to tell with TSREADER because when you click on the audio PID, it instantly goes away when the corrupt PMT data kicks in every fraction of a second.

The Coolsat 8000 can do manual entry but not AC-3 and yes all those channels are AC-3 audio (Pansat 1500 shows AC3 on audio pids)

But anyway, this is NOT the receiver's fault, it is a problem with the NET mux. Hope it's not intentional on NET's part, as it does nasty things to some receiver software, particularly if the receiver is relying upon the PMT for the info relative to what PIDs are used for audio.

but I wonder why the Coolsat 8000/8100 wont play them right yet 2 other receivers I tried did?

 

[B.J.]

......
The Coolsat 8000 can do manual entry but not AC-3 and yes all those channels are AC-3 audio (Pansat 1500 shows AC3 on audio pids)


but I wonder why the Coolsat 8000/8100 wont play them right yet 2 other receivers I tried did?

Yeah, I don't know. Like I said, it just seems to me that the 8000/8100 must somehow rely on the PMT data, even though the channels have been saved, ie somehow changing what PIDs are associated with the different channels.


I hope this channel gets fixed, because it's hard to record via TSREADER not knowing how long it will run without bombing. TSREADER seems to collect dozens and dozens of different PID entries under each channel, until it maxes out the program and it bombs.

While typing this in, I hooked up my Diamond 9000 to C-band, and it works fine.
Then I hooked up my 8100, and as the two of you above reported, it blinks on and off, both video and audio. So I tried entering the manual PIDs, and as I expected, the video is solid. No blinking. Also, as expected, it doesn't pick up the AC3 audio, so no audio. Got to figure out a workaround for that.

So I'm more convinced than ever that it's the corrupted PMTs that's messing things up. And the Coolsat 8100 must have some strange way of storing the channel data (obvious since no-one has come up with a channel editor that works yet), and this method must rely on reading the PMTs continuously while viewing channels. I can't imagine WHY they would do it that way, but I can't think of any other explanation.

 

[Mr Tony]

interesting one HD receiver works fine but the other doesnt

I might have to try the Quali on it and see what it does

As for the 8000 adding channels, there **might** be a channel editor out there

 

[gillham]

My CS8000 is frquently squirelly when I have another device on the Loop out connector. I don't think they are very well isolated. Try turning off the lnb voltage of the CS6100 and see if that changes any behavior.

This point shouldn't be overlooked in this discussion. I also believe the CS8100 doesn't block power properly. So the device on the loop out can send DiSEqC commands and can interfere with the CS8100's control of the equipment.

I recommend putting the 6100 first and slaving the 8100 off of it. I know the 6100 is quite different from the 6000, but the 6000 blocks the power (and DiSEqC signals) off the loop out port properly. I'm guessing the 6100 probably does as well.

My setup works much better with the 6000 first as it only allows the 8100 to control the equipment if I put the 6000 in standby. The other way around all kinds of odd things would go on, including the slaved receiver moving the dish out from under the main receiver.

 

[B.J.]

This point shouldn't be overlooked in this discussion. I also believe the CS8100 doesn't block power properly. So the device on the loop out can send DiSEqC commands and can interfere with the CS8100's control of the equipment.

I recommend putting the 6100 first and slaving the 8100 off of it. I know the 6100 is quite different from the 6000, but the 6000 blocks the power (and DiSEqC signals) off the loop out port properly. I'm guessing the 6100 probably does as well.
....

This situation doesn't have anything to do with the 8100's passthru. When I duplicated the results of the other posters, I didn't have anything connected to the passthru, plus the C-band dish was controlled by my Drake 1824, not by the 8100. This problem is clearly being caused by the very unusual signal being sent down by NET, and the strange way that the 8000/8100 receivers seem to store channel data. As mentioned above, the problem is fixed by creating a manual channel with the A/V PIDs, however until a channel editor comes out allowing you to specify AC3 audio on these manual channels, you won't get audio on this mux.

 

[Mr Tony]

agreed BJ

When I did my testing on NET, I had a cable form LNB to receiver. Nothing in between

 

[B.J.]

Being curious, and trying to understand what this transponder is doing to TSREADER and the Coolsat 8000/8100, I first looked at the data for the scanned channel and the manual channel in the Coolsat channel data file. Both saved channels have the correct PIDs for A/V, however the scanned channel DOES contain the PID of the PMT PID, so the Coolsat must keep checking the PMT to see if the A/V PIDs have changed or something like that. Perhaps THIS is related to the common Coolsat error that says something like "channel data has changed" or whatever, every once in a while, requiring you to re- scan channels???

However, I also recorded a bit of the PMT data for one of the channels, and I found out that it's not quite what I had expected. Ie I thought that there were occasional BAD PMT packets being sent. This doesn't seem to be the case. What DOES seem to be the case, is that there are 2 separate, and nearly identical PMT packets being sent continuously. The two different PMT sections both have the correct A/V PIDs listed properly, and are identical, except for one byte. The ONLY difference between the two is that the version number of one set is version=3 and the others are version=23 . Also, the packets that the good versions are sent in have a different counter for continuity counting. I looked packet by packet, and saw continuity counter numbers of:

11
15
12
13
14
0
15
0
1
1
2
3
4
2
5
6
7
3
8
9
10
4

there are actually two separate counters going on at the same time here, one with the 11,12,13,14,15,0,1,2,3,4,5,6,7,8,9,10,
and the other with the
15,0,1,2,3,4
The GOOD PMT packets are in the 15->4 sequence, and the old version 3 PMT packets, and some non-PMT packets are being sent in the 11->10 sequence.
Each time the counter fails to incriment by one, there is a continuity error. These errors wouldn't cause the problems seen, however what I think is happening is that the receiver is seeing version 3 go to version 23 and then back to version 3, etc,etc, and each time the PMT version changes, the receiver resets. I think the other receivers are just ignoring this version change.
It looks like Nebraska must have changed the PMT values, but just happened to leave in the old values as well.

Anyway, it's been fun looking at the raw data in these PMT files.

 

[Mike045]

Is it just me ? I don't get the signal anymore.

Helios

 

[B.J.]

Is it just me ? I don't get the signal anymore.

Helios

I'm a day late reading this, but I'm still getting it right now, however it does seem to be a weaker signal than it was before.
It's possible that they were off the air yesterday though. I saw them go completely off the air one day for about 5 hours.