127 replies to this topic

[littlesat]

WTE thanks for this overview...

[twol]

Sorry I am missing something here.
I am told here that the SF4008/HD51 DVB/S2X capability is marketing blurb, although people demonstrate it working, but Vu+ have a S2X tuner and its abilities are not a debateable issue?

 
Don't believe everything you read. Here can been found lot of fake news.
All the DVB-S2x transponders which are now available in the world works fine on the HD51.
This doesn't mean that in future this is still so. Below you can find more info and make your own conclusions.
 
DVB-S2x interest to read is follow:
http://www.newtec.eu...s2x-demystified
1. Smaller Roll-Offs
2. Advanced Filtering
3. Supporting Different Network Configurations
4. Increased Granularity in MODCODs
5. Higher Modulation Schemes up to 64/128/256APSK
6. Very Low SNR MODCODs
7. Linear and non-linear MODCODs
8. Bonding of TV streams
9. Additional standard scrambling sequences
10. Wideband Support
 
 
HD51 should support all point except point 8 as this is not possible by Broadcom SOC used in HD51.
8. Bonding of TV streams
 
Other models (like SF4008) claim to have full support DVB-S2x however this tuner fails on many points.
For point 1 I am not sure but specifications of chipset doesn't mention it.
1. Smaller Roll-Offs
6. Very Low SNR MODCODs
8. Bonding of TV streams
10. Wideband Support

Thank you..... but tells me that I need to read a lot more before I understand all this ...

[jpuigs]

Thanks WTE.

Then, looking at current Openpli supported boxes, which ones do really support full specifications for DVB-S2X and Multistream ?

[WanWizard]

From the looks of it, none.

 

As WTE wrote, the HD51 comes close(st), and we don't yet know what the VU+ Zero 4K tuner exactly does. 

[amila4341]

From a source I've never heard of? Don't think so.

Source is chip maker you may contact them and verify.

http://www.availink.com/contact.aspx

support@availink.com

[Erik Slagter]

As request HD51 picture with dvb-s2x tuner and audio works as well with AC3+ (EAC) track.

 

hd51-dvb-s2x-channel.jpg

 

hd51-scan-dvb-s2x-transponder.jpg

 

hd51-scan-dvb-s2x-transponder-2.jpg

I guess the resolves the debate then. I haven't unpacked my Zero4k yet, but apparently it has a Si2166 tuner just like the HD51 and the newer Zgemma receivers do, so the netto difference is zero. I was under the impression the Zero4k would have a "value edition" Broadcom FBC tuner, but apparently it doesn't.

 

The only difference left, then, is that VU+ makes the tuner announce as DVB-S2X tuner and the other offer them in a sort of DVB-S2 "compatibility" mode. That means there's still work left to be done to make full use of all of the capabilties, see athoik's remarks, regardless.

[Erik Slagter]

From the looks of it, none.

 

As WTE wrote, the HD51 comes close(st), and we don't yet know what the VU+ Zero 4K tuner exactly does. 

The question is whether it's relevant. Many receivers will lack some of the exotic features of S2X and we can expect that they won't be used by the providers therefore. Mostly used are multistream, extended SR and extended FEC.

[Erik Slagter]

So apparently I was wrong, I don't hesitate to admit. The Si2166D is a full featured DVB-S2X tuner (where maybe some features are not supported by the SoC, that's another story).

 

The confusion is caused by:

 

- some manufacturers make this tuner announce as a S2 tuner, some as S2X

- I was under the impression the VU+ Zero4k would come with a Broadcom "half" FBC tuner, maybe that's for the C version instead

- last but not least, multistream is still an S2 feature and not S2X, and exactly multistream is the most interesting feature of the Si2166 tuner (or I should say: demodulator).

[athoik]

It's fine if we are going to "display" the "real" values of FEC to the UI.

But since those are NOT values that LinuxDVB has, it means that we have to patch libc or define then in E2 only.

Also that means, that all user-space utilities (femon, etc) will be broken, because they will not know the new "unknown values", new modulation etc.

Also the UI will be broken because we really don't know the tuner capabilities? (and patch doesn't improve that situation).

Or you really like to hack this around by using "if tuner A" then capability_A = True, capability_B = True? (Really???)



Honestly, we are using LinuxDVB, and we like to call our selfs "OpenSource" (talking for the whole E2 community).

The "OpenSource" game requires to give in order to take more.


Now what? We have a situation that new tuners arrive, manufacturers create their solutions, announce S2X, but offer 0 (ZERO/NULL) back to OpenSource!


In List the Mauro was clear, in order to add new values we need a driver also that uses those values.

So now WE, the so called open source community (not speaking only for OpenPLi here, but for all E2 distros monitoring that thread) we are going to solve that?


If we like "OpenSource" we need those values to LinuxDVB OFFICIAL in order to use them.

We need a solution for querying capabilities, because S2X is just optional extensions, that one tuner might implement other not. S2X DOESN'T imply all features implemented.

And the last part, the querying it's something that we can offer it (meaning it doesn't require to write a new driver, but extend existing ones).


In conclusion:

I would prefer to have the new fec in LinuxDVB in order to use them.
I don't like to patch libc in order to introduce the new values, that other manufacturers might choose different values, we have seen that happen 1M times.
We need an API to query extended tuner capabilities (the ones we are missing now) in order to create good UI. Making a new delsys, doesn't fix that.

So the patch that other E2 used already in NimManager (if S2X then S2) is the BEST solution.


Volunteers working on extended tuner capability API? The one that LinuxDVB misses now and the one that will be used by the whole LinuxDVB community?

Edited by athoik, 10 December 2017 - 10:03.

[littlesat]

I would-be consider to simply report it to dvbapi so they implement it first before creating a work a round

[Huevos]

@Athoik, thanks for the analysis.

 

I think the most important thing is a manufacturer is not allowed to force a set of values on the rest of us. Or even worse, several manufacturers start using different values. That would be a nightmare. We, the E2 community, and the wider Linux community as a whole should be dictating these values, not the writers of closed source drivers that work on one brand of receiver.

[littlesat]

Then first oe-a images should stop these kind of work-a-rounds...

[athoik]

Then first oe-a images should stop these kind of work-a-rounds...

I think nobody yet accepted changes for S2X.

On the other hand OE-A doesn't use shared feeds, shared libc etc. So for them, for their build environment is easy to apply such patches.

[Huevos]

Then first oe-a images should stop these kind of work-a-rounds...

That is nothing to do with the discussion in this thread which is related to extended FEC values.

 

That workaround is just a used for reading the output of /proc/bus/nim_sockets. There are plenty of examples of hacks/workarounds for interpreting /proc outputs including in OpenPLi so I don't see any reason to create a team versus team discussion here. All that does is weaken all of our positions against the people who might try to force this on us. Even if LinuxDVB had these values built in the hack in NimManager would still be necessary with the current Vu+ driver for the Zero 4K.

[Huevos]

 

Then first oe-a images should stop these kind of work-a-rounds...

I think nobody yet accepted changes for S2X.

On the other hand OE-A doesn't use shared feeds, shared libc etc. So for them, for their build environment is easy to apply such patches.

 

OpenViX used to use shared feeds but not any longer. No other OE-A team do.

[athoik]

We, the E2 community, and the wider Linux community as a whole should be dictating these values, not the writers of closed source drivers that work on one brand of receiver.

Today several manufacturers advertise S2X capable their products, NONE of them submitted something to LinuxDVB (and I am talking for all of the E2 manufacturers, also those who are not supported officially by OpenPLi, but they have OpenPLi somehow....)


We don't have the power to dictate those values, unless somebody creates a driver using reverse engineering and submit the driver WITH new values to LinuxDVB.

Until then, we can only hope, somebody like Digital Devices (https://github.com/D...alDevices/dddvb) (or TBS https://github.com/tbsdtv/linux_media) to send the patches for LinuxDVB.

So the best to do is discuss and help the Open Source ecosystem.

In the meanwhile the following days I will try to contact rjkm from Digital Devices and discuss with him about creating the official PLS property for Linux.

The Digital Devices already have it in their code.

A modified version based on LinuxDVB mailing list comments is the following (still missing documentation, the most important stuff and hard to create).

diff --git a/drivers/media/dvb-core/dvb_frontend.c b/drivers/media/dvb-core/dvb_frontend.c
index 3ad8335..a7c19e4 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -979,6 +979,7 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe)
        }

        c->stream_id = NO_STREAM_ID_FILTER;
+       c->scrambling_sequence_index = NO_SCRAMBLING_CODE;

        switch (c->delivery_system) {
        case SYS_DVBS:
@@ -1069,6 +1070,7 @@ static struct dtv_cmds_h dtv_cmds[DTV_MAX_COMMAND + 1] = {

        _DTV_CMD(DTV_STREAM_ID, 1, 0),
        _DTV_CMD(DTV_DVBT2_PLP_ID_LEGACY, 1, 0),
+       _DTV_CMD(DTV_SCRAMBLING_SEQUENCE_INDEX, 1, 0),
        _DTV_CMD(DTV_LNA, 1, 0),

        /* Get */
@@ -1414,6 +1416,11 @@ static int dtv_property_process_get(struct dvb_frontend *fe,
                tvp->u.data = c->stream_id;
                break;

+       /* Physical layer scrambling support */
+       case DTV_SCRAMBLING_SEQUENCE_INDEX:
+               tvp->u.data = c->scrambling_sequence_index;
+               break;
+
        /* ATSC-MH */
        case DTV_ATSCMH_FIC_VER:
                tvp->u.data = fe->dtv_property_cache.atscmh_fic_ver;
@@ -1897,6 +1904,11 @@ static int dtv_property_process_set(struct dvb_frontend *fe,
                c->stream_id = data;
                break;

+       /* Physical layer scrambling support */
+       case DTV_SCRAMBLING_SEQUENCE_INDEX:
+               c->scrambling_sequence_index = data;
+               break;
+
        /* ATSC-MH */
        case DTV_ATSCMH_PARADE_ID:
                fe->dtv_property_cache.atscmh_parade_id = data;
diff --git a/drivers/media/dvb-frontends/stv090x.c b/drivers/media/dvb-frontends/stv090x.c
index 7ef469c..5d8f1b6 100644
--- a/drivers/media/dvb-frontends/stv090x.c
+++ b/drivers/media/dvb-frontends/stv090x.c
@@ -3429,6 +3429,23 @@ static enum stv090x_signal_state stv090x_algo(struct stv090x_state *state)
        return -1;
 }

+static int stv090x_set_pls(struct stv090x_state *state, u32 pls_code)
+{
+       if (pls_code == NO_SCRAMBLING_CODE)
+               pls_code = 1;
+       dprintk(FE_DEBUG, 1, "Set Gold PLS code %d", pls_code);
+       if (STV090x_WRITE_DEMOD(state, PLROOT0, 0x01) < 0)
+               goto err;
+       if (STV090x_WRITE_DEMOD(state, PLROOT1, (pls_code >> 8) & 0xff) < 0)
+               goto err;
+       if (STV090x_WRITE_DEMOD(state, PLROOT2, 0x04 | (pls_code >> 16)) < 0)
+               goto err;
+       return 0;
+err:
+       dprintk(FE_ERROR, 1, "I/O error");
+       return -1;
+}
+
 static int stv090x_set_mis(struct stv090x_state *state, int mis)
 {
        u32 reg;
@@ -3491,6 +3508,7 @@ static enum dvbfe_search stv090x_search(struct dvb_frontend *fe)
                state->search_range = 5000000;
        }

+       stv090x_set_pls(state, props->scrambling_sequence_index);
        stv090x_set_mis(state, props->stream_id);

        if (stv090x_algo(state) == STV090x_RANGEOK) {
diff --git a/include/uapi/linux/dvb/frontend.h b/include/uapi/linux/dvb/frontend.h
index b297b65..a9ba741 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -547,7 +569,10 @@ enum fe_interleaving {
 #define DTV_STAT_ERROR_BLOCK_COUNT     68
 #define DTV_STAT_TOTAL_BLOCK_COUNT     69

-#define DTV_MAX_COMMAND                DTV_STAT_TOTAL_BLOCK_COUNT
+/* PLS */
+#define DTV_SCRAMBLING_SEQUENCE_INDEX  70
+
+#define DTV_MAX_COMMAND                DTV_SCRAMBLING_SEQUENCE_INDEX

 /**
  * enum fe_pilot - Type of pilot tone
@@ -731,6 +756,7 @@ enum atscmh_rs_code_mode {
 };

 #define NO_STREAM_ID_FILTER    (~0U)
+#define NO_SCRAMBLING_CODE     (~0U)
 #define LNA_AUTO                (~0U)

 /**

Edited by athoik, 10 December 2017 - 20:25.

[zgemma-dvbs2x]

 

As request HD51 picture with dvb-s2x tuner and audio works as well with AC3+ (EAC) track.

 

hd51-dvb-s2x-channel.jpg

 

hd51-scan-dvb-s2x-transponder.jpg

 

hd51-scan-dvb-s2x-transponder-2.jpg

I guess the resolves the debate then. I haven't unpacked my Zero4k yet, but apparently it has a Si2166 tuner just like the HD51 and the newer Zgemma receivers do, so the netto difference is zero. I was under the impression the Zero4k would have a "value edition" Broadcom FBC tuner, but apparently it doesn't.

 

The only difference left, then, is that VU+ makes the tuner announce as DVB-S2X tuner and the other offer them in a sort of DVB-S2 "compatibility" mode. That means there's still work left to be done to make full use of all of the capabilties, see athoik's remarks, regardless.

 

I have a Zgemma H5.2S+ (DVB-S2X) receiver, it has Si2169D tuner. Multistream is OK (tested on 5°W), but no other DVB-S2X feature, enigma2 identifies it as a DVB-S2 tuner.

[Erik Slagter]

How enigma calls it is irrelevant.

 

Try it on the relevant 19.2E transponder mentioned. It may or may not work. The Si2166D can do both multistream and S2X, but it also needs driver support.

[zgemma-dvbs2x]

How enigma calls it is irrelevant.

 

Try it on the relevant 19.2E transponder mentioned. It may or may not work. The Si2166D can do both multistream and S2X, but it also needs driver support.

I tried to scan 12399H on Thor 7, but no succes 'cause of FEC 25/36.

Edited by zgemma-dvbs2x, 14 December 2017 - 19:42.

[athoik]

Did you use AUTO on FEC?