TNAP-7 Image Discussion

cyberham said:
I always use the higher voltage position since all my lines are 125 feet long. Today's measured no-load voltage was 18.5 V at the dish on horizontal which is fine. I replaced the no-name universal LNB (not an Avenger) with a Geosatpro SL1PLL standard LNB. So far, so good. I had forgotten I had the no-name LNB on for universal testing a long time ago but universal gives nothing extra on the current Ku band arc in this location.
Click to expand...
No problems here on 97W-ku for H or V tp. I'm get it on an old 10'mesh with a corotor 2.
 
No problems here anymore either after changing to a better LNB. PLL LNBs are the best types. FWIW, I flashed the latest image (0615) into a new slot, updated it, and did NOT restore any settings so I could have a perfectly clean installation. No green screens encountered during installation. As mentioned in another thread, it's cool that my Edision Mio+ in many cases now tells me which satellite it is tuned to via the NIT data. As I build up my satellite database, I'm encountering no issues.
 
EnoSat said:
Rod Hewitt KG6TTD (G6TTD) passed away March 2025 having spent a lifetime dedicated to programming and was the author of TSReader. His work will be available for download for free with just one version, TSReaderPro, being available both here and on a GitHub Page for others to continue the project.

Please feel free to donate to help us maintain the website hosting etc it would be very much appreciated.

Do you think it would be possible to integrate DCII processing into TNAP ?
github.com

TSReader/parser.c at main · TSReader/TSReader

Contribute to TSReader/TSReader development by creating an account on GitHub.
github.com github.com

A year ago, I took a quick look at what the PID 4094, which uses DCII, looks like
Click to expand...
DCII background: DigiCipher II is a Motorola/GI proprietary system used primarily on North American C-band and some Ku-band satellites (Galaxy, Telstar, AMC fleets). It predates DVB-S and uses its own framing, FEC, and SI table structure. The DVB-S tuner hardware on enigma2 receivers can often receive the RF signal, but the demodulator firmware typically speaks DVB-S only — DCII demodulation is a different chipset mode that most STB tuners don't support at all, or support only partially.

Short answer = No.
 
eelstrebor said:
TNAP 7 shows incorrect time on front panel but when connecting via telnet to the osmio4k and executing date the correct date and time is displayed. Why is that? I should also mention that when doing a blind scan via webif the display doesn't render correctly. It shows that scan was started but there is no progress showing. If I switch to the HDMI port on the osmio4k it'll give a normal display with progress and services found.
Click to expand...
The only place I could find a front display Time issue in osmio4k was during a blindscan, the front display would freeze. TNAP 7 did not have a decent display XML file for the mio4k, and once one was added, the clock functions correctly. That explains WHY.

The osmio4k is a slow receiver when compared to other models such as the Octagon SF8008. Basically what you saw in OpenWebif during a blindscan was a screen rendering issue. The same blindscan rendering issue is also seen in other distros such as OpenVix. The "fix" requires a slowing of the screen rendering, when really all that was needed was a manual refresh by the user which is available in the OpenWebif main screen.

Some of the OpenWebif code was edited to make the screens render properly in blindscan without needing a manual refresh, the trade-off being a noticeable lag in the receiver display window. But the screens render correctly now. Faster receivers do not get this OpenWebIf edit so they are unaffected. Your screens render correctly now..... However you also have to wait for the screens to properly render.

eelstrebor said:
I downloaded the latest TNAP 7 (06-15-2026) but now https doesn't work for webif. And I'm not able to scan in the ABC feeds on 97W and 99W. I did get the CBS feeds scanned in on 97W. The time display on the osmio4k front panel still shows the incorrect time but when I telnet into the box and run the date command it reports the correct date and time.
Click to expand...
HTTPS WORKS! This is verifed. Most likely you have installed a backup with an old file that does not allow https to work.

Blindscan:
I do not know what you expect out of a satellite blindscan, but it will not produce or return perfect results and is more inline with a crapshoot than anything else in most receivers, including Edision. An extensive amount of time and resources has been spent on TNAP images to get the best scan we can from a given group of receivers. It is what it is.

Seems though that anytime a polarity doesn't work or a transponder is missed, the image must be at fault. While there are things in an image that can cause signal problems, usually missed transponders or missing polarities are associated with hardware type issues instead of software.

TNAP receivers create scan logs everytime a scan is made. Posting a scan log helps because when one is available, little is left to imagine. I have attached a group of scan logs for you to review for 99w and 97w C band. Don't know what I am supposed to get, but all seems OK.

In your second posting, The time issue you reported some 5 hours earlier.... The osmio4k receiver display time has been fixed.... It was seen the first time, but perfectly ok to report it again.

To see your issues resolved, do an online update or in terminal, opkg update followed by opkg upgrade then reboot.
 

Attachments

Last edited:
el bandido said:
DCII background: DigiCipher II is a Motorola/GI proprietary system used primarily on North American C-band and some Ku-band satellites (Galaxy, Telstar, AMC fleets). It predates DVB-S and uses its own framing, FEC, and SI table structure. The DVB-S tuner hardware on enigma2 receivers can often receive the RF signal, but the demodulator firmware typically speaks DVB-S only — DCII demodulation is a different chipset mode that most STB tuners don't support at all, or support only partially.

Short answer = No.
Click to expand...
It's a shame, since the transponders on Lyngsat have the same PAT as standard DVB.
capture_001_21062026_064635.webp
Yes, the DVB-S system often used DCII modes such as Combo, Split I/Q, and Offset QPSK, which standard receivers cannot process,
with the transition to DVB-S2, the use of these modes has become minimal.
 
The sources you pointed to earlier for DCII are more of a roadmap than a complete version. This would take some work to implement, and then what would you have? DCII channels are scrambled. I personally cannot pursue it. The information is good to know about. Thanks for sharing it!
 
Edits for ATSC PSIP on DVB-S/C transponders continues:
Some examples:
Mexican OTA stations uplinked to C-band (like this one at 105.1W)
Canadian OTA feeds on Galaxy/Anik satellites
US broadcast network feeds (NBC, CBS, ABC, FOX affiliate uplinks)
PBS and religious broadcaster distribution feeds
Any headend that originates ATSC content and uplinks it without re-authoring the PSIP

The bug is systematic, not random. When a broadcaster takes an ATSC signal off-air and uplinks it, many just pass the PSIP through unchanged. The VCT was written for an ATSC transport where program_numbers are assigned differently than a DVB operator would do it. The mismatch between VCT program_number and PAT program_number is essentially the fingerprint of "ATSC content up-linked by someone who didn't touch the PSIP."

Before this fix, all of those transponders would have produced the same symptom: doubled channel count, named channels that wouldn't tune, unnamed channels that would. Anyone scanning C-band or Ku-band North American feeds on an enigma2 receiver would have hit this silently.

The combination of the two commits — ATSC VCT on DVB-S detection (the earlier work) plus this remapping fix means TNAP 7 now handles North American satellite content better than most other enigma2 distributions as I have not seen anyone else that ls working on this.
Here are 2 105w Examples:

Before
Code: 
                         Scan Report

< File created on Tuesday, June 23, 2026 at 12:37:44 >
< Satellite =  105.0W C-band AMC 15 & EchoStar 105/SES 11 105.1 W >
< Receiver =  SF8008-Supreme >
< Enigma2 Image = TNAP 7 >
< Kernel Version = 4.4.35 >
< DVB Driver Date = 20250111 >
< Blindscan Frequency Range =  to  MHz >
< Blindscan Symbol Rate Range =  to  Msps >
< Blindscan Only Free Channels or Services? =   >


< 'DVB-S2 8PSK 4025V / 4995 / 5/6' > Tp# 1
< [1] 7-1 XHFN-DT  1:0:1:4:1:0:9F58FB9:0:0:1: SNR = 15.05  />
< [2] 7-2 Coah  1:0:1:5:1:0:9F58FB9:0:0:2: SNR = 15.05  />
< [3] 7-3 Tamps  1:0:1:6:1:0:9F58FB9:0:0:3: SNR = 15.05  />
< [4] 7-4 a+  1:0:1:A:1:0:9F58FB9:0:0:9: SNR = 15.05  />
< [5] 4025V SID 0x01  1:0:1:1:1:0:9F58FB9:0:0:0: SNR = 15.05  />
< [6] 4025V SID 0x02  1:0:1:2:1:0:9F58FB9:0:0:0: SNR = 15.05  />
< [7] 4025V SID 0x03  1:0:1:3:1:0:9F58FB9:0:0:0: SNR = 15.05  />
< [8] 4025V SID 0x09  1:0:1:9:1:0:9F58FB9:0:0:0: SNR = 15.05  />
< Transponder SNR =['15.05db' raw=1505 -Locked], Strength = 100.0% >
< Tue, 23 Jun 2026 12:37:46 /> <

 Service Scan Completed in 0 Minutes  02 Seconds.

8 Channels ( TV = 8  Radio = 0)  1 of 1 Transponders Scanned.

After
Code: 
                         Scan Report

< File created on Tuesday, June 23, 2026 at 12:43:33 >
< Satellite =  105.0W C-band AMC 15 & EchoStar 105/SES 11 105.1 W >
< Receiver =  SF8008-Supreme >
< Enigma2 Image = TNAP 7 >
< Kernel Version = 4.4.35 >
< DVB Driver Date = 20250111 >
< Blindscan Frequency Range =  to  MHz >
< Blindscan Symbol Rate Range =  to  Msps >
< Blindscan Only Free Channels or Services? =   >


< 'DVB-S2 8PSK 4025V / 4995 / 5/6' > Tp# 1
< [1] 7-1 XHFN-DT  1:0:1:1:1:0:9F58FB9:0:0:0: SNR = 14.91  />
< [2] 7-2 Coah  1:0:1:2:1:0:9F58FB9:0:0:0: SNR = 14.91  />
< [3] 7-3 Tamps  1:0:1:3:1:0:9F58FB9:0:0:0: SNR = 14.91  />
< [4] 7-4 a+  1:0:1:9:1:0:9F58FB9:0:0:0: SNR = 14.91  />
< Transponder SNR =['14.91db' raw=1491 -Locked], Strength = 100.0% >
< Tue, 23 Jun 2026 12:43:34 /> <

 Service Scan Completed in 0 Minutes  01 Seconds.

4 Channels ( TV = 4  Radio = 0)  1 of 1 Transponders Scanned.

Before
Code: 
                         Scan Report

< File created on Tuesday, June 23, 2026 at 12:37:09 >
< Satellite =  105.0W C-band AMC 15 & EchoStar 105/SES 11 105.1 W >
< Receiver =  SF8008-Supreme >
< Enigma2 Image = TNAP 7 >
< Kernel Version = 4.4.35 >
< DVB Driver Date = 20250111 >
< Blindscan Frequency Range =  to  MHz >
< Blindscan Symbol Rate Range =  to  Msps >
< Blindscan Only Free Channels or Services? =   >


< 'DVB-S2 8PSK 3990V / 5833 / 3/4' > Tp# 1
< [1] 26-1 XHCGA  1:0:1:1:1770:0:9F58F96:0:0:1: SNR = 12.79  />
< [2] 26-2 XHCGASD  1:0:1:2:1770:0:9F58F96:0:0:2: SNR = 12.79  />
< [3] 26-3 XHCGA03  1:0:1:3:1770:0:9F58F96:0:0:3: SNR = 12.79  />
< [4] 3990V SID 0x01  1:0:1:1:1770:0:9F58F96:0:0:0: SNR = 12.85  />
< [5] 3990V SID 0x02  1:0:1:2:1770:0:9F58F96:0:0:0: SNR = 12.85  />
< [6] 3990V SID 0x03  1:0:1:3:1770:0:9F58F96:0:0:0: SNR = 12.85  />
< Transponder SNR =['12.85db' raw=1285 -Locked], Strength = 100.0% >
< Tue, 23 Jun 2026 12:37:13 /> <

 Service Scan Completed in 0 Minutes  04 Seconds.

6 Channels ( TV = 6  Radio = 0)  1 of 1 Transponders Scanned.

After
Code: 
                         Scan Report

< File created on Tuesday, June 23, 2026 at 12:43:10 >
< Satellite =  105.0W C-band AMC 15 & EchoStar 105/SES 11 105.1 W >
< Receiver =  SF8008-Supreme >
< Enigma2 Image = TNAP 7 >
< Kernel Version = 4.4.35 >
< DVB Driver Date = 20250111 >
< Blindscan Frequency Range =  to  MHz >
< Blindscan Symbol Rate Range =  to  Msps >
< Blindscan Only Free Channels or Services? =   >


< 'DVB-S2 8PSK 3990V / 5833 / 3/4' > Tp# 1
< [1] 26-1 XHCGA  1:0:1:1:1770:0:9F58F96:0:0:0: SNR = 12.79  />
< [2] 26-2 XHCGASD  1:0:1:2:1770:0:9F58F96:0:0:0: SNR = 12.79  />
< [3] 26-3 XHCGA03  1:0:1:3:1770:0:9F58F96:0:0:0: SNR = 12.79  />
< Transponder SNR =['12.79db' raw=1279 -Locked], Strength = 99.0% >
< Tue, 23 Jun 2026 12:43:12 /> <

 Service Scan Completed in 0 Minutes  04 Seconds.

3 Channels ( TV = 3  Radio = 0)  1 of 1 Transponders Scanned.

The duplicate channels shown above that display the frequency instead of the name would return a black screen with the message "SID not found in pat" or similar. Online update that is available now should solve this dilemma.
 
Efforts to fix audio type mis-matches are also in online updates today:

Fix BSSD registration descriptor misidentifying ATSC AC-3 as LPCM
Stream_type 0x81 + BSSD registration (0x42535344) is used by ATSC cable operators for Dolby Digital AC-3 audio. The previous code unconditionally set LPCM for any BSSD, overriding the correct AC3 type already set by the stream_type 0x81 handler. BSSD means LPCM only in HDMV/Blu-ray context(is_hdmv=1); In ATSC cable, the stream_type 0x81 AC-3 assignment stands. Fixes silent audio on ATSC-origin channels where enigma2 reported the track as "LPCM" instead of "AC-3".
 
Here is an example that illustrates something that may be new operation. Or perhaps I just never noticed this before.

When using Signal Finder, if I select User defined transponder, then enter frequency, polarization and SR, then scan, the resulting transponder parameters will reflect the System (DVB-S or DVB-S2) and Modulation (QPSK, 8PSK, etc.) that happened to be set in the Signal Finder at time of scan regardless what the correct parameters are. So I can end up with the transponder showing DVB-S and QPSK even when that transponder actually is DVB-S2 8PSK. Even with the wrong parameters showing in this case, the transponder plays fine.

Is the above correct operation? If so, then when using Signal Finder, how would one know whether a signal is DVB-S or DVB-S2 and QPSK, 8PSK, etc. before you scan? The same applies for FEC. Whatever FEC happens to be set in Signal Finder is what shows for the transponder after scanning: right or wrong.

If I blind scan the satellite, the resulting transponders always show the correct parameters.
 
Signal finder auto detects some satellite transponder parameters on all of the receivers currently built for TNAP. The frequency, symbol rate and polarity are all that is needed. The rest is detected automatically. It has been that way for a good decade.
 
There are two separate things happening:

Demodulator-level detection (what makes it lock and play). This is real, automatic, and works exactly as described. For DVB-S2, the modulation and FEC are carried in the physical-layer header — the PLS/MODCOD in the PLHEADER. The demod has to decode that header to demodulate the payload at all, so it uses the real MODCOD regardless of what's typed in the Signal Finder fields. Your QPSK/8PSK and FEC inputs are simply ignored once it reads the PLHEADER. Delivery system (S vs S2) is auto-searched by the driver. That's why a DVB-S2 8PSK transponder locks and plays perfectly even with DVB-S / QPSK sitting in the boxes, the hardware is running on the detected parameters, not the entered ones.

Write-back of detected parameters into the stored transponder (what you are actually complaining about). Signal Finder builds the resulting transponder object from the config values you entered, not from a read-back of the locked frontend. So the stored/displayed system, modulation, and FEC are just an echo of the input fields... Cosmetic.

Blind scan is different: it derives each transponder's parameters from what the tuner actually reports during the scan, which is why blind scan always shows correct values.


Understand, this is not broken and it's not a regression. Signal Finder has never read back the actual locked parameters to populate the stored transponder for TNAP model receivers, and it's worked this way the whole decade I've been describing. Nothing changed. The "automatic detection" I referred to is the demod's internal detection that achieves lock, not an auto-correction of the on-screen fields.

As for the question "How would I know S/S2 or QPSK/8PSK before scanning in Signal Finder?" In Signal Finder you don't need to, because the demod figures it out for you to get lock. If the goal is an accurate catalog of what a transponder actually is, blind scan is the correct tool and it does exactly that by design. Signal Finder's job is "is there a signal here, and how strong/clean is it," not "characterize this carrier precisely."

Signal Finder auto-correcting and displaying the true values is technically doable. After lock you'd call getFrontendData() (i.e. read back FE_GET_PROPERTY for delivery system, modulation, inner FEC, pilot, rolloff) and overwrite the transponder's parameters before adding it, the same family of read-back that the blindscan path relies on. The one caveat worth verifying: Some demod drivers echo back the requested system/modulation/FEC on FE_GET_PROPERTY rather than the detected ones.

Since blind scan reports correct values on your target hardware, the underlying capability clearly exists on those chips, but the plain post-tune read-back in the Signal Finder path may or may not surface the detected values cleanly. So it's a reasonable enhancement to consider, just one to test on the SF8008 and the Broadcom Edisions before committing to it. This is work I am not interested in doing right now because the system we have has functioned on various FTA receivers for over a decade.
 
Good explanation. It's almost like Claude wrote it. Knowing this is all that's needed to address this issue. If I want to know the complete technical data for a transponder, then I'll blind scan. If I just want to quickly check for a feed, I'll use Signal Finder.

Wouldn't it be great if Claude could be given the assignment to review every post in this site relating to Enigma2 receivers and summarize the information into a grand user's manual.
 
el bandido said:
We should make these edits for Positioner setup and its Tune menu...
Click to expand...
Auto Focus works well on my Edision Mio+ even on Ku. It peaked the dish location correctly on several different satellites when I used it. And the bigger display was not necessary for me since I use a 55" TV, but it's nicer and more colourful too.
 
Back
Top