TBS 5927

[EnoSat]

And let's not underestimate the legendary dvbsnoop either

 

[Wolfclaw]

Here I must correct you: "standard tools" is not the correct wording - I consider VMA Transport Stream Analyser a very specialized tool, which aims to be a reference tool for broadcast engineers. It is not free, either. Comparable tools are TSReader Pro (unfortunately the author is no longer with us), Dektec StreamXpert and 4T2 Content Analyser. The list is by no means complete and I am only mentioning Windows tools.

Also, you might want to take a look at my free online tools: Online Tools – VMA Broadcast

Here you will find several tools for TS analysis, among other tools.

For Linux you have of course deeptho's neumoDVB.

Thank you for the correction: "specialized professional tool" is of course a better characterization, and I appreciate the context.

I've been looking through your website and I'm genuinely impressed. The VMA Ultimate Stream Reader looks particularly interesting. Building on StreamReader CLI with a modern GUI for blindscan automation is exactly the kind of workflow I've been trying to understand. Is that available for download or still in development?

I also noticed your browser-based MPE/IP Analyser, which is actually directly useful for my purposes since dontlookup outputs PCAP files with extracted IP traffic, and having a lightweight tool to inspect encapsulated IP in .ts files is valuable.

One question your SDR description raised: you mentioned locking to very low symbol rates that TBS tuners struggle with. In the context of datatransponders on GEO satellites, the kind carrying SCADA/IEC-104 backhaul rather than broadcast TV, are those typically low SR, or do they tend to be higher SR links?

 

[Wolfclaw]

And let's not underestimate the legendary dvbsnoop either

Thanks, this is a great example. dvbsnoop is powerful and the decode of that DSM-CC/MPE datagram is very clean. The PRTG ICMP ping payload is fully visible, including source and destination addresses.

A few things I find interesting about your setup: you appear to be running this on an osmio4kplus receiver directly, is that correct? And the transponder in your PID scan has no TV services at all in the PAT, just data PIDs? Was that a known data-only transponder you targeted, or did you find it via blind scan?

I understand dvbsnoop handles MPE/IP encapsulation well. Does it also handle the GSE encapsulation variants that dontlookup targets, or is that a different layer it can't reach?

I'd be curious to know more :-)

 

[vma]

I've been looking through your website and I'm genuinely impressed. The VMA Ultimate Stream Reader looks particularly interesting. Building on StreamReader CLI with a modern GUI for blindscan automation is exactly the kind of workflow I've been trying to understand. Is that available for download or still in development?

All my applications are in constant development for improvements and new features.
The software is available for download. However, bear in mind that VMA Ultimate Stream Reader is free, while VMA Ultimate Stream Reader Pro requires a paid license. The difference is mainly the inclusion of a complete Transport Stream Analyser.

One question your SDR description raised: you mentioned locking to very low symbol rates that TBS tuners struggle with. In the context of datatransponders on GEO satellites, the kind carrying SCADA/IEC-104 backhaul rather than broadcast TV, are those typically low SR, or do they tend to be higher SR links?

Honestly I don't know, but I imagine that these will be higher SR links.

 

[Wolfclaw]

All my applications are in constant development for improvements and new features.
The software is available for download. However, bear in mind that VMA Ultimate Stream Reader is free, while VMA Ultimate Stream Reader Pro requires a paid license. The difference is mainly the inclusion of a complete Transport Stream Analyser.


Honestly I don't know, but I imagine that these will be higher SR links.

Thanks, I'll download VMA Ultimate Stream Reader and try it with whatever hardware I end up with.

One last thing I'm curious about: your MPE/IP browser tool on the online tools page: can that open the PCAP output files that dontlookup generates, or does it only handle raw .ts files? If it can bridge those two workflows it would be genuinely useful.

 

[EnoSat]

Thanks, this is a great example. dvbsnoop is powerful and the decode of that DSM-CC/MPE datagram is very clean. The PRTG ICMP ping payload is fully visible, including source and destination addresses.

A few things I find interesting about your setup: you appear to be running this on an osmio4kplus receiver directly, is that correct? And the transponder in your PID scan has no TV services at all in the PAT, just data PIDs? Was that a known data-only transponder you targeted, or did you find it via blind scan?

I understand dvbsnoop handles MPE/IP encapsulation well. Does it also handle the GSE encapsulation variants that dontlookup targets, or is that a different layer it can't reach?

I'd be curious to know more :-)

Yes, direct launch on a Linux receiver.
This is a comparison of the transponder from post #72.
Since its development has stalled, I think it will have issues with GSE.

 

[deeptho]

Thanks for a very helpful clarification.
So the TBS-6903 (original, STV0910-based) shares the same tuner IC as the TBS-5927 and offers fast blind scan on both Windows and Linux.

My workflow is Linux-only and I’m also interested in the dontlookuo use case. For the dontlookup use case, the raw payload capture on PCIe cards requires EBS Pro on Windows rather than the Linux driver patch approach. Is that also your understanding?

And do you have any experience with whether the TBS-6903 can reliably lock onto ACM/GSE data transponders, as opposed to standard broadcast transponders?

Any advice would be very helpful.

I do not own a 6903, so do not know how well it works with the blindscan drivers. The stv chip is supported, but there is also a tuner in the card. Supporting that is in theory not very difficult but in practice difficult without a card. Also it is not worth spending much effort on a card that cannot even be bought anymore (at least not in europe - I have been looking as it would be be interesting for eshail).

 

[Wolfclaw]

I do not own a 6903, so do not know how well it works with the blindscan drivers. The stv chip is supported, but there is also a tuner in the card. Supporting that is in theory not very difficult but in practice difficult without a card. Also it is not worth spending much effort on a card that cannot even be bought anymore (at least not in europe - I have been looking as it would be be interesting for eshail).

Again, thanks, that's helpful context.
You're right that the 6903 is not relevant for my use case anyway, since the dontlookup driver patch requires a USB card. I hope to acquire the STV090x-based TBS5925, so that should cover both the dontlookup use case and general blind scanning under Linux with your drivers.

One last question if I may: once I have the TBS5925 running, is neumo-dmx the recommended starting point for GSE stream capture on Linux, or would you point me elsewhere at this stage?

 

[deeptho]

Again, thanks, that's helpful context.
You're right that the 6903 is not relevant for my use case anyway, since the dontlookup driver patch requires a USB card. I hope to acquire the STV090x-based TBS5925, so that should cover both the dontlookup use case and general blind scanning under Linux with your drivers.

That would work, but the patch is for the TBS drivers, so probably outdated and maybe not compatible with neumo-drivers. I am also not sure what format the patch produces, and what format dontlookup expects internally (I have never used it myself)

Also the patch is for tbs5927 (don't know what tbs5925 is)

One last question if I may: once I have the TBS5925 running, is neumo-dmx the recommended starting point for GSE stream capture on Linux, or would you point me elsewhere at this stage?

neumo-dmx can output both regular transport streams and GS-streams. The latter are embedded as private
sections in a transport stream containing PID 270.

I have only tested this on the stid135 cards, not the stv cards. Small changes may be needed for GSE streams on the stv cards (because also small changes were needed for stid135) or it might just work out of the box.

My view: tbs5927 is a good card but also difficult to buy, but 6909x is of 6903x are more versatile (and more expensive) and pci-express is more practical than all these external boxes. So the drivers for those stid135 cards get more attention

 

[Wolfclaw]

That would work, but the patch is for the TBS drivers, so probably outdated and maybe not compatible with neumo-drivers. I am also not sure what format the patch produces, and what format dontlookup expects internally (I have never used it myself)

Also the patch is for tbs5927 (don't know what tbs5925 is)



neumo-dmx can output both regular transport streams and GS-streams. The latter are embedded as private
sections in a transport stream containing PID 270.

I have only tested this on the stid135 cards, not the stv cards. Small changes may be needed for GSE streams on the stv cards (because also small changes were needed for stid135) or it might just work out of the box.

My view: tbs5927 is a good card but also difficult to buy, but 6909x is of 6903x are more versatile (and more expensive) and pci-express is more practical than all these external boxes. So the drivers for those stid135 cards get more attention

This is very candid and useful, thanks!
I take your point that the patch is 5927-specific and that the 5925 may not even have a clean driver path. I'll treat the 5925 (if I get hold of one) as a starting point for conventional DVB-S2 work and MPE/IP capture first, and approach the GSE/dontlookup layer as a separate challenge once I have the antenna system running.

Your neumo-dmx output format description is helpful. PID 270 as private sections is a good starting point to understand what to expect. I'll report back once I have the hardware.

 

[satopsguy]

Hey there,
after getting inspired by the "Don't look up" talk, I read a lot through this forum and realized my fascination for the entire satellite hobby. Anyway, since the 5927 is unavailable, I looked into alternatives and to my understanding 6909x and 6903x are working nicely as well (apart from the fact that they are not as portable as USB tuners). The patch "Don't look up" was using is just disabling the software filtering of the TS stream by using dvb_dmx_swfilter_raw feeding all frames without validation. Therefore neumo-dmx works just fine. I tried using Astra 1P and got it working. Very slow since pure python, but proof of concept works.

 

[Wolfclaw]

Hey there,
after getting inspired by the "Don't look up" talk, I read a lot through this forum and realized my fascination for the entire satellite hobby. Anyway, since the 5927 is unavailable, I looked into alternatives and to my understanding 6909x and 6903x are working nicely as well (apart from the fact that they are not as portable as USB tuners). The patch "Don't look up" was using is just disabling the software filtering of the TS stream by using dvb_dmx_swfilter_raw feeding all frames without validation. Therefore neumo-dmx works just fine. I tried using Astra 1P and got it working. Very slow since pure python, but proof of concept works.

Great to see another person inspired by the same talk!
Your explanation of dvb_dmx_swfilter_raw is the clearest technical description I've seen in this thread and useful to know. It makes sense that the patch is not fundamentally USB-specific if it's operating at the DVB demux layer.

I've just ordered a TBS6908 (STV091x-based, PCIe) and I'm planning to run Linux with neumo-dmx. Your success with the 6909X on Astra 1P is very encouraging. Did you use deeptho's drivers directly, or did you need any modifications? And did neumo-dmx handle the GSE encapsulation on that transponder, or was it standard MPE/IP traffic?

 

[deeptho]

tuners). The patch "Don't look up" was using is just disabling the software filtering of the TS stream by using dvb_dmx_swfilter_raw feeding all frames without validation. Therefore neumo-dmx works just fine. I tried using Astra 1P and got it working. Very slow since pure python, but proof of concept works.

That was not clear at all. neumo-dmx outputs bbframes encoded in private seconds. If that is what dontlookup also expects then all is fine,
but the diver patch seemed to be doing something different.

 

[deeptho]

I've just ordered a TBS6908 (STV091x-based, PCIe) and I'm planning to run Linux with neumo-dmx. Your success with the 6909X on Astra 1P is very encouraging. Did you use deeptho's drivers directly, or did you need any modifications? And did neumo-dmx handle the GSE encapsulation on that transponder, or was it standard MPE/IP traffic?

Where did you order this tbs6908?

 

[satopsguy]

That was not clear at all. neumo-dmx outputs bbframes encoded in private seconds. If that is what dontlookup also expects then all is fine,
but the diver patch seemed to be doing something different.

I'm still trying to get used to the terminology and protocols. But quoting the research paper dontlookup_ccs25_fullpaper.pdf, they explain it quite clearly:

We modified the tuner card’s dri-ver to record a raw transport stream at the DVB-S/S2(X) protocollayer and above instead of an MPEG-TS video/audio stream. MPEG-
TS frames are prefixed with a synchronization byte 0x47 [14, 15];when this byte is not observed, the driver assumes it has lost synchronization and discards bytes until the next available 0x47. This approach works for an MPEG-TS video/audio stream temporarily corrupted by noise, but it fails for non-MPEG-TS streams, such as raw DVB-S2(X), which do not use 0x47 for frame synchronization. To capture raw streams of DVB-S/S2(X) bytes, we modified and recompiled the tuner card’s Linux driver to disable this MPEG-TS internal filtering and forward the raw demodulated data directly to the demux0 device. Our modified driver is open source to support future satellite research [71].

In other words, this sounds like bbframes to me with the MPEG-TS stream filtering disabled. They were using dvbv5-zap and streamed bbframes into a TS file. I'm still reviewing both the paper and the Python files to understand what exactly is required.

Great to see another person inspired by the same talk!
Your explanation of dvb_dmx_swfilter_raw is the clearest technical description I've seen in this thread and useful to know. It makes sense that the patch is not fundamentally USB-specific if it's operating at the DVB demux layer.

I've just ordered a TBS6908 (STV091x-based, PCIe) and I'm planning to run Linux with neumo-dmx. Your success with the 6909X on Astra 1P is very encouraging. Did you use deeptho's drivers directly, or did you need any modifications? And did neumo-dmx handle the GSE encapsulation on that transponder, or was it standard MPE/IP traffic?

In my setup, I used a Fedora Virtual machine with TBS6903x passed to the VM. After compiling the out of tree kernel modules (using two modifications to support 6.19 kernel and a kernel panic - both are tracked on Github), I ran neumodvb and it worked out of the box. I was able to lock to 3 transponders marked with type GSE. One of them 12441 V 27500. I ran the recording twice - first dvbv5-zap and second neumo-dmx. In both cases, running Don't-look-up shows clear TCP IP traffic. Nothing interesting, but in general, things work.

 

[Wolfclaw]

Where did you order this tbs6908?

From the Swiss web shop GroupeMedia, I'm sending you the full link on DM.

 

[satopsguy]

I'm still at the beginning of my research, but it seems that Don't look up patch feeds raw byte streams directly from DVB-S modulation including those BB frames without TS sync byte. If I read the code correctly, the PCI-e drivers discard all frames without the TS sync byte - @deeptho can you confirm?
In that case, any data traffic encapsulated inside MPEG-Transport Stream would be recorded, but potentially non-standard streams would be discarded.

​

 

[deeptho]

I'm still at the beginning of my research, but it seems that Don't look up patch feeds raw byte streams directly from DVB-S modulation including those BB frames without TS sync byte. If I read the code correctly, the PCI-e drivers discard all frames without the TS sync byte - @deeptho can you confirm?

The DVB drivers do that indeed.

In that case, any data traffic encapsulated inside MPEG-Transport Stream would be recorded, but potentially non-standard streams would be discarded.

That depends on many factors and one what you mean by a nonstandard stream.
stid135 based cards and stv091x cards can embedded all streams inside a transport stream. Not sure if the stv091x drivers have it properly implemented, but it can be done.

 

[Wolfclaw]

Today there was an excellent Youtube video posted on the topic we have discussed - "Which TBS Satellite Tuners Work For Don't Look Up? 5925, 6983, 6903, 6908, And Newer 6903-X Tested!"

 

[deeptho]

Maybe one more comment about "We modified the tuner card’s driver to record a raw transport stream at the DVB-S/S2(X) protocollayer and above instead of an MPEG-TS video/audio stream. MPEG-
TS frames are prefixed with a synchronization byte 0x47 [14, 15];when this byte is not observed, the driver assumes it has lost synchronization and discards bytes until the next available 0x47. This approach works for an MPEG-TS video/audio stream temporarily corrupted by noise, but it fails for non-MPEG-TS streams, such as raw DVB-S2(X), which do not use 0x47 for frame synchronization. To capture raw streams of DVB-S/S2(X) bytes, we modified and recompiled the tuner card’s Linux driver to disable this MPEG-TS internal filtering and forward the raw demodulated data directly to the demux0 device. Our modified driver is open source to support future satellite research [71].
"

That is a poor approach: If the card with the modified driver really outputs the raw bbframe data (possible, but probably only on usb cards and even then only if the driver uses that as the default format), then most 0x47 bytes will simply not be there, except for a single one at the start of the bbframe (in the bbframe header) and some spurious 0x47 data bytes. So such an approach would be very error prone even on perfect streams

On the other hand, on pci-express cards I think the fpga prevents sending raw data (at least on tbs6909x), so that approach then
cannot work (the OS does not matter! It is probably the FPGA that blocks it). However, all cards based on stv091x and stid135 can embed bbframes in a transport stream, and that includes a header to easily find the bbframes. And that is the format already supported by drivers for years now. So it could have been used.

Note that the paper itself points to the authors not having much experience with satellite. E.g., they seem to have rediscovered the principle of the polar mount.. :->
" We introduce a new method to self-align a motorized dish to improve signal quality." and "Prior to this work, achieving accurate alignment required an expensive dual-axis steerable dish or phased-array steerable antenna. We demonstrate that with hidden alignment data in
satellite feeds, even a hobbyist-grade single axis rotor dish can achieve good enough alignment to receive high-quality signal from
all visible satellites. " The "hidden" data turns out to be the nit tables and public websites.