DTT_CABLE Analyzer and Player

DTT & CABLE Analyser v.2.1 by PantaSat 2026

Greetings to all forum members,

I am pleased to present the latest developments of my analyzer, now reaching version 2.1. The application has been fully localized into English: every single element of the graphical user interface (from configuration menus and dynamic mouse tooltips to graph headers), as well as physical log files and generated text reports (.txt), now natively speak English. This ensures maximum international compatibility and readability of technical logs and global statistical summaries, making them ready to be shared and analyzed anywhere without any language barriers.

I have prepared a complete image and a comprehensive demonstration video showing the entire operational cycle: rapid RF level scanning, deep spectral Blind Scan with MUX locking, and live streaming management toward external media players.

DEMO VIDEO

This software stands as one of the very few amateur DTT and Cable analyzers to bring together and integrate four distinct modules within a single interface:

1. Continuous RF leveling and real-time visual spectrum tracking featuring advanced spline interpolation.
2. Automatic tabular logging of all port physical parameters (Standard, Modulation, Constellation, FEC, Guard Interval, FFT, Cell ID, dBm, and real SNR).
3. Instantaneous parsing of PAT/SDT tables with extraction of logical channel numbering (LCN), station names, and service types (TV/Radio/Data).
4. A dedicated Multicast Streaming Controls hub for instantaneous forwarding of the video/technical stream to the most prominent external players and analyzers (FFplay, VLC, TSReader, VMA).

Demonstration Video Content

• RF SCAN & Dynamic Threshold: The analyzer maps out the UHF grid (channels 21-69), plotting the spectral curve directly onto a Matplotlib filled area. The dashed red line represents the hardware sensitivity threshold, which can be configured directly via software or adjusted in real time by dragging it across the graph with the mouse. During the scan, a green radar tracking line visually follows the active frequency under analysis.
• AIR BLIND SCAN & Lock Detection: Upon completion of the RF scan, the algorithm isolates authentic signal peaks and executes a targeted Blind Scan exclusively on active frequencies. The software pilots the radar positioning (marking red dots on the graph centered precisely on the peak of maximum power) and triggers an audible beep at every hardware LOCK confirmed by the demodulator.
• PAT Analysis & LCN Extraction: Upon locking each multiplex, the software performs an 8-second deep analysis, directly querying the DVB card's C++ libraries via Python ctypes structure mapping. The full station list is extracted, complete with local LCN allocation, Service ID (SID), and service stream encoding (e.g., TV HEVC, TV SD, Data).
• Clickable Station List & Multi-Player Streaming: All identified channels populate the listbox on the right side in real time. Double-clicking any station instructs the background thread to trace back the base multiplex frequency, isolate the requested SID within the UDP multicast stream, and deploy the external video stream. FFplay initializes with native YADIF deinterlacing filters applied, preserving the window title bar with the channel name and enforcing an "always on top" desktop placement.

Code Architecture Details

The underlying architecture relies strictly on multi-threaded programming designed to keep the user interface responsive and eliminate standard Windows thread freezing:

1. C++ Data Structures via Ctypes (Direct Hardware Mapping) Physical parameter recovery directly maps the StreamReader DLL memory. Utilizing a custom Python Structure, the software polls the SignalInfo2 function to read the hardware tuner chip registers:

class SEARCH_RESULT2(Structure): fields = [ ("Lock", c_bool), ("Freq", c_uint), ("BW", c_uint), ("SR", c_uint), ("StdType", c_uint), ("ModType", c_uint), ("FEC", c_uint), ("FECLP", c_uint), ("Inversion", c_uint), ("TransMode", c_uint), ("Guard", c_uint), ("Hierarchy", c_uint), ("PLP", c_uint), ("LID", c_ubyte * 16), ("CellID", c_uint), ("RFLevel", c_long), ("SNR", c_double), ("BER", c_double)... ]

This infrastructure allows the software to output critical parameters in the treeview table that commercial set-top boxes typically hide (such as 32K FFT sizing, complex guard intervals, or the local transmitter Cell ID).

2. Thread Monitoring & Asynchronous Process Cleanup (Anti-Freeze) When a live stream is initiated, the secondary thread continuously monitors the external process handle via proc.wait(). If you close the FFplay or VLC window manually, the thread catches the termination event and immediately executes a cleanup callback on the GUI main loop, safely releasing the hardware resource. Furthermore, halting a stream triggers a forced asynchronous cleanup routine through subprocess.Popen via a taskkill /F /T command executed inside an invisible prompt boundary (CREATE_NO_WINDOW), preventing rogue worker processes from dangling in memory.

3. Relative Export Paths & Full Portability (No Absolute Paths) As of version 2.1, the application is completely standalone and portable, having been purged of all hardcoded directory references. The script automatically determines its base directory at runtime via os.path.dirname(os.path.abspath(__file__)) and merges it with the relative sub-paths declared in the config.cfg file (e.g., Report_Scansione and DTT_Frequencies). You can rename, restructure, or move the root folder anywhere on your storage drive without breaking report logging or changing path access definitions for the external player suite.

DOWNLOAD: DTT_CABLE_Analyzer_2.1

Comments, test results, and technical feedback are welcome as always.

PantaSat 2026

Hi everyone,

I'm in the final stages of rewriting my DTT and cable application, and in this new version I've tried to add — where technically possible — the ability to lock signals transmitted on different PLPs other than PLP 0.

I have to be honest: I wrote the PLP selection code based only on theory, and I couldn't find any official documentation about it. There are no guides, no examples, nothing written that explains how to select a PLP on a TBS card through StreamReader.dll. I had to deduce how it works by reading the SDK sources and doing some educated attempts. But we all know that the real test is only on the field: either it works, or it doesn't.

That's why I'm making an appeal here on the forum.

If there is any user living in border areas — Austria, Switzerland, France, Slovenia, Czech Republic, Germany — where signals are transmitted on the same frequency but with different PLPs (typically one PLP for the country on one side and another PLP for the country on the other side, so they don't interfere with each other), and who owns a TBS card compatible with StreamReader.dll, I would be happy to provide the beta version of the program so we can run field tests together and evaluate whether the mechanism actually works.

In the meantime, here are some screenshots kindly sent by femi , whom I thank. If he wishes, he can step in and explain the results directly in this thread.

The results are encouraging: on 554 MHz, using the "Manual Tune" popup with PLP=1, femi locked the Austrian ORF mux (ORF1 HD, ORF2 W HD, ORF III HD, ORF Sport+ HD, Radio Österreich 1). With PLP=0 nothing locks. On the same frequency, the main tab of the program (which has no PLP selector and always uses a default PLP) shows the Czech channels instead.

So the same frequency gives two different results depending on which PLP is selected, and this confirms that the PLP selection actually works.

[ Screenshots from femi ]

( Caption: Manual Tune, 554 MHz, PLP=0 → NO LOCK, empty service list Manual Tune, 554 MHz, PLP=1 → LOCK (SNR 19.2 dB), ORF Austrian services extracted)

Caption: Manual Tune on 585.960 MHz with PLP=0 → LOCK (SNR 26.2 dB) but no services extracted.

DTT Analyzer tab, 513.965 MHz → Czech services extracted (default PLP)

DTT Analyzer tab, 585.960 MHz → Czech/Slovak services extracted (default PLP)

What is still missing is a clean side-by-side test with the same tool on every available PLP: PLP 0, PLP 1, PLP 2 and so on, to understand how the mux is structured and which PLP carries the service tables. femi showed half of the test, but his reception is marginal (SNR around 19 dB on DVB-T2), which makes the lock unstable and does not allow a complete verification.

So I renew the appeal: if there are users living in border areas where muxes on different PLPs coexist (Austria, Switzerland, France, Slovenia, Czech Republic, Germany) and who own a TBS card compatible with StreamReader.dll, please come forward. I will provide the beta version of the program so we can run field tests with a stable signal.

Thanks everyone for your attention.

PantaSat

Hi femi ,

you are absolutely right about the regulatory coordination between neighbouring countries. Here in Tuscany we have the same situation: certain UHF channels are not available to Italian broadcasters because they are assigned to France for the coverage of Corsica, precisely to avoid cross-border interference.

That said, I would like to clarify one point about your situation, because it changes how we interpret your test.

You wrote in an earlier message:

Quote from femi

Since I'm receiving different PLP IDs here (0/CZ and 1/AT), I'm adding this to the wish list.

My question is: which of these two situations describes what you actually receive?

Case A — You receive shared frequencies where Czech and Austrian muxes coexist on the same frequency using different PLPs (PLP 0 = Czech, PLP 1 = Austria).

Case B — You receive Czech muxes on some frequencies (with their PLP 0) and Austrian muxes on different frequencies (with their PLP 1 instead of PLP 0).

In other words: are the Czech and Austrian transmissions sharing the same frequency with different PLPs, or are they on separate frequencies, and Austria simply uses PLP 1 as its normal configuration?

This will help us understand exactly how the muxes are structured on your side and whether the multi-PLP case is really a shared-frequency scenario or something else.

Thanks!

PantaSat

OK thank

Hi deeptho , you are absolutely right to be puzzled, and your technical explanation of DVB-T2 PLPs is spot on. This was just a classic "lost in translation" misunderstanding on our end!

To clear things up: the signals @femi is receiving are not on the same frequency. Since he lives near the border, he receives terrestrial multiplexes from two different countries. Naturally, these are broadcast on distinct, coordinated frequencies to avoid cross-border RF interference.

The confusion arose simply because the neighboring country's DVB-T2 network is configured to transmit its multiplex using PLP 0, whereas the Austrian network broadcasts its streams using PLP 1.

Because our team is heavily focused on the satellite world (DVB-S2) — where multiple Input Streams (MIS) routinely share the exact same transponder frequency — we initially misinterpreted his report. We mistakenly pictured a scenario where multiple PLPs from different countries were packed onto a single terrestrial frequency, which, as you correctly pointed out, wouldn't make sense for interference mitigation.

So, you are completely correct: the PLPs are not being used to manage cross-border interference (the different frequencies handle that). It just happens that the two independent national networks chose different PLP IDs for their distinct frequencies, and our software simply needed an update to correctly identify and lock onto PLP 1, rather than assuming PLP 0 is always the default.

Thanks for bringing this up and providing the excellent Enensys reference!

PantaSat