Intelsat 35e 34.5 w

[Chr0nik]

Locked here no trouble.

A blast from the past, the package used to be on 43W (and 45W for a while) some 20 years ago

Also Cherifla is coming in well at 11543, plus a radio feed on te SF8008

Yeah, me too. I used to watch a lot of Telehit back in 2008-2010 and then went dark for a looong time.

 

[satesco]

So empty now, no more Ku band channels over 34.5w for Europe

All Ku-band TV muxes are active at 34.5W, and all TV packages are running, even with a 1.10m antenna in my area:

11524 V, 12330, 3/4,8 8PSK- SMTD package,
11540 V, 1500, 2/3-Cherifla TV,
11556 H, 14321, 5/6, S2- Televisa Network package.

 

[Joolz]

F0X News, MS Now & BBC HD as IP Stream on 11.675H 34285 DVB-S2X Hard to get even with 15dB signal using TBS6909X SS8 Voile.

 

[satesco]

F0X News, MS Now & BBC HD as IP Stream on 11.675H 34285 DVB-S2X Hard to get even with 15dB signal using TBS6909X SS8 Voile.

...

Thanks for finding it. There are several streams for TV services, including major networks.

 

[EnoSat]

It's a shame that Mio4K uses the AVL6261C instead of the AVL6261A

 

[deeptho]

Thanks for finding it. There are several streams for TV services, including major networks.

What dish size did you use and what SNR do you get? I tried on my biggest dish (about 15.6dB SNR) and got to decode something with my not-ready software, but there are too many errors to even attempt viewing.

There are two streams with isi=0 and isi=1. I see something fake-news like on image on stream 1, so that is a partial
success.

The question is if my GS parsing sofware still has some bugs or if my signal is too weak.
I suspect it is the software.

If you have better reception than me (e.g., good picture on windows), you could possibly help by
reporting your signal level or by capturing a stream (e.g. 1 minute)
as follows:

Tune using neumodvb (6903X or 6909X card) using positioner dialog.
select ISI MINUS-1
and then record a stream like this

~/blindscan/build/src/neumo-dmx --adapter XXXX --fe-stream > /tmp/stream.gs

XXX should be replaced by the correct adapter number, which you can find on the "frontends" list.
In my case XXX = 8 (shown in first column)

 

[satesco]

I received the signal at 34.5 MHz using a 1.10 m antenna with the 6909x card and Windows 11. By the way, in my area, this signal position worked well for me even with a small antenna.
I’ll also try to receive this mux with neumoDVB and let you know if it’s a bug. For now, since the signal is pretty good, I haven’t found anything like that on Windows.
Surprisingly, the signal on 11673 H is strong with Crazyscan.
I detected two streams, Fox News and BBC HD.
Until I capture a stream with neumoDVB, I’ll provide you with a file recorded on Windows 11.

 

[deeptho]

If this works under windows, then there are probably some bugs left in my software.

 

[deeptho]

My software finds something, but no picture.

 

[satesco]

My software finds something, but no picture.

In the Skyscraper8_release_18 with the Voile app on Windows 11, there are two folders: one named "Voile_pcap_out" for PCAP files and another named "Voile_subts_out" for TS files

 

[deeptho]

In the Skyscraper8_release_18 with the Voile app on Windows 11, there are two folders: one named "Voile_pcap_out" for PCAP files and another named "Voile_subts_out" for TS files

This was useful. I was able to extract more data from the files you sent me once, than was possible with my own software. So hopefully it can help to find bugs. But your streams are still heavily corrupted. It could be due to needing a very strong signal, but also due to the weird nature of this mux, which confuses drivers and even causes loss of lock.

Note that voile crashes a lot, there are no windows drivers for the card I use most (tbs6916), vma stream reader cannot tune my 6909x card (maybe diseqc problem), but crazyscan can. So it is a bit frustrating, but I managed to capture some data with the windows drivers my self on 6909x, which could be useful for comparison.

Here are some strange things about te mux

• The mux claims that it is a "single input stream" in the bbheader. Crazyscan also detects is as such, but it clearly has two streams:
  • ISI=1 with two matypes: 67 (generic-continuous, multistream, acm/vcm) and matype 179 (reserved, single stream, acm/vcm)
  • ISI=0 matype=179 (reserved, single stream, CCM)
• And the modcodes clearly indicate that it is VCM/ACM encoded (with conflcting info in the two streams). See below. This is with some not yet released improvements in neumodv

I have noticed that the neumo-drivers also lose lock from time to time. This could perhaps be solved, but it might not
have a practical improvement. Note the absence of bit errors, but still lock is lost.

It would be interesting to try with other cards.

 

[deeptho]

Correction

• The mux claims that it is a "single input stream" in the bbheader. Crazyscan also detects is as such, but it clearly has two streams:
  • ISI=1 with matypes 66 and 67 (generic-continuous, multistream, acm/vcm) and matype 179 (transport stream, single stream, CCM)
  • ISI=0 matype=179 (transportstream, single stream, CCM).

Matype 179 seems to be noticed only by the driver, but seems to produce no data. This needs some more investigation

 

[deeptho]

It seems that some of my earlier reports produced incorrect values for matypes. One reason is a very confusing part of a manual which lead me to misinterpret the values even though the code was correct and another error where I mistypes 179 and got 197. However, there is more: a portion of the code changes the 4 upper bits of matype for no clear reason.

So I modified the code and got some more reasonable results, although this might break some things as well.

The debug logs now only report matype 66 and 67 and stream 0 and 1. Note that 179-67=112 which is a multiple of 16.
So 179 is a fake code produced by the drivers (ironical as the stream contains fox news...)

The difference between 66 and 67 is gse_lite on/off. I need to check some more why neumodvb reports only one of them in the gui.
Probably there is some hidden assumption that matype does not change for a stream, so only one code is reported per isi (?).
The standards are not clear on whether a changing matype is even allowed.

Note that there are still 2 streams, but stream 0 seems to have no content (perhaps it has only DUMMY frames, or perhaps
something goes wrong0.

Still the drivers report two streams and two matypes:

2026-05-01T22:09:54.830759+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x1
2026-05-01T22:09:54.842743+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x42 isi_read=0x1
2026-05-01T22:09:54.853747+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x0
2026-05-01T22:09:54.864742+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x42 isi_read=0x1
2026-05-01T22:09:54.875735+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x1
2026-05-01T22:09:54.886740+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x1
2026-05-01T22:09:54.897750+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x1
2026-05-01T22:09:54.908744+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x42 isi_read=0x1
2026-05-01T22:09:54.919742+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x43 isi_read=0x1
2026-05-01T22:09:54.930748+02:00  kernel: fe_stid135_read_hw_matype:5714 matype=0x42 isi_read=0x1

 

[deeptho]

Some other interesting facts: with tbs6904se, the driver constantly locks, unlocks, and then locks again. I do not think is possible to read generic streams with that card, but who knows...

 

[deeptho]

I finally figured it out: there really are two ISI's in the stream, but it may be that some are the results of bit errors, e.g., flipping the 1 to 0.
Or perhaps it is on purpose.

I can also see that the card reports 'BCH erorrs', even at an SNR of 15 dB

/stidmap.py |grep '0\.0:' |grep '(5)' |grep BBFCRCKO
addr=0x2f34 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO1(5)                     = 0x00000000
addr=0x2f35 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO0(5)                     = 0x00000000
$./stidmap.py |grep '0\.0:' |grep '(5)' |grep BBFCRCKO
addr=0x2f34 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO1(5)                     = 0x00000015
addr=0x2f35 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO0(5)                     = 0x00000074
$./stidmap.py |grep '0\.0:' |grep '(5)' |grep BBFCRCKO
addr=0x2f34 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO1(5)                     = 0x00000023
addr=0x2f35 0.0: REG_RC8CODEW_DVBSX_PKTDELIN_BBFCRCKO0(5)                     = 0x00000070

So the error counters keep going up, suggesting indeed that not all frames are decoded correctly

Apparently skyscraper does not check the ISI field and indeed if I stop checking it, the data from ISI=0 and ISI=1 are mixed
and I get a lot more video data. The stream is still almost unwatchable, just as the stream decoded wih sjyscraper and captured on windows.
Interestingly: decoding only ISI=0 produces nothing at all.

If people with bigger dishes can capture a stream with much better SNR (e.g. 18dB or more), then that would help my analysis.
However the current conclusion is that insufficient signal is the root cause. It is possible to ask the drivers to not output frames with errors, but that would not help to receive the signal.

 

[dreamsat]

11593 V 28265 with S2X extention

11557 H is clear