127 replies to this topic

[Huevos]

S2X patch from Vu+

 

http://code.vuplus.c...7c75c5158ee9c38

[littlesat]

How do the other tuners do it that have already DVB-S2X...?

 

The patch looks clean ... Did you already tried it?

 

It also 'sounds' a lot of missing DVB-Sx2 parameters were added

 

http://code.vuplus.c...8ce6b9a993e8150

Edited by littlesat, 7 December 2017 - 10:25.

[Erik Slagter]

We're in discussion with VU+ about this.

[Abu Baniaz]

We're in discussion with VU+ about this.

Can you also mention the tuner driver patch in your discussions please?

 

https://forums.openp...ue/#entry786053

[Erik Slagter]

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

[Huevos]

How do the other tuners do it that have already DVB-S2X...?

There is currently only one real S2X transponder on the whole arc. SF4008 handles this in auto mode without realizing there is a problem. But that is a blindscan capable tuner. No idea how other tuners will handle this. But yes, all the S2X fec stuff is missing for all brands.

[athoik]

The real problem is how to indentify the tuner capabilities.

LinuxDVB eventually might use another delsys for S2X, although does S2X means that tuner support all extensions?

Certenly no!

So, the real need is a new mechanism to query tuner capabilities.

See:

https://www.mail-arc.../msg122572.html

https://www.mail-arc.../msg122600.html

[littlesat]

The tuner identification is as far I understand the first thing vu needs to fix...

[Huevos]

Yes. NimManger does not recognize the tuner type from the /proc output so without the attached commit the tuner doesn't even display in the GUI, (Vu+ Zero 4K).

 

https://github.com/B...c7bedcc46963f26

[Erik Slagter]

It's something not unique to the Zero4k. It's just that the Zero4k is the first receiver we support that has a S2x tuner. And S2x as a delsys needs to be implemented into enigma. It's not like it needs a "workaround" to be recognised or similar. Applying a foreign patch 1:1 into our enigma for this doesn't seem like a good idea, we need to implement it properly.

[twol]

It's something not unique to the Zero4k. It's just that the Zero4k is the first receiver we support that has a S2x tuner. And S2x as a delsys needs to be implemented into enigma. It's not like it needs a "workaround" to be recognised or similar. Applying a foreign patch 1:1 into our enigma for this doesn't seem like a good idea, we need to implement it properly.

Mut@nt HD51 has a S2X tuner like the SF4008 (but follow on chip), so how does OpenPli support that?

Edited by twol, 8 December 2017 - 11:47.

[Erik Slagter]

No it doesn't. It has a DVB S2 multistream extensions capable tuner. That is not DVB S2x.

Edited by Erik Slagter, 8 December 2017 - 13:20.

[twol]

No it doesn't. I has a DVB S2 multistream extensions capable tuner. That is not DVB S2x.

So is the SF4008 tuner a DVB-S2 multistream capable tuner or the SF4008 drivers better or are both using just marketing "blurb" for these "s2x" tuners at the moment?!

[WanWizard]

Correct. DVB-S2X and Multistream and two different things.

 

DVB-S2X factsheet: https://www.dvb.org/...x_factsheet.pdf

 

The confusion (or marketing speak) comes from ETSI EN 302 307 part 2 (https://www.dvb.org/...den302307-2.pdf), which defines the DVB-S2X extension to DVB-S2.  However, the current generation of multistream capable tuners don't implement any of these extensions apart from multiple input streams. which is (largely) a software implementation, not a hardware implementation.

 

In other words: an DVB-S2X tuner is always multisteam compliant, a "multistream capable" tuner isn't always a DVB-S2X tuner.

[dhwz]

In other words: an DVB-S2X tuner is always multisteam compliant, a "multistream capable" tuner isn't always a DVB-S2X tuner.

Little correction a DVB-S2X tuner is NOT always Multistream compatible, e.g. Si2166C is S2X capable but not fully MIS.
But MIS was also available at DVB-S2, for both its not mandatory.

Oh and don't forget all current Demods do always AutoScan. So there is no real need to use parameters like modulation or fec.

Also Vu+ is now patching E2, but LinuxAPI is right now not knowing any of these values. So the drivers as said always do use Auto...

Looks linke nobody told Vu+ that the whole parch is not really necessary.

Edited by dhwz, 8 December 2017 - 15:00.

[dhwz]

Seems also that nobody did tell them that 16/32APSK are also available for DVB-S2, for me it looks like the whole patch is not really conclusive. Or what do you think @athoik? Also scanning a DVB-S2 tp in DVB-S2X mode will result the services getting stored as DVB-S2X (as S2X is only an extension to S2 this will always work) which then results in not portable settings, as not S2X capable tuners will not recognize the stored delsys.

Edited by dhwz, 8 December 2017 - 15:22.

[littlesat]

Then it is still nice to have the outcome on the UI, just to see what the modulation of a transponder finally is set to...

 

In addition when we have these kind of "auto" tuners we could also remove these settings completely from e.g. the 'manual scan' input... just to simplify the UI. Why enter all these gadgets (FEC, modulation type) when it is not required at all..? Then I prefer to add a feature to remove all the details when they are not required...

[WanWizard]

Little correction a DVB-S2X tuner is NOT always Multistream compatible, e.g. Si2166C is S2X capable but not fully MIS.

 
Great. So it's not fully compliant. The specsheet states:
 

DVB-S2X (ETSI EN302 307-2 V1.0.0)
- Support the normative broadcast services
- QPSK/8PSK, 8/16/32 APSK demodulator
- Roll-off factors from 0.05 to 0.35

 
and
 

The satellite reception allows demodulating ... , and new Part II of DVB-S2 (S2X) satellite broadcast standard.

 

which is in contradtion, as not everything from Part II (Part I being DVB-S2) is implemented.

 

So I would say that this is not an S2X tuner, but an S2 tuner with a partial S2X implementation.

[dhwz]

Then it is still nice to have the outcome on the UI, just to see what the modulation of a transponder finally is set to...

Yes agreed, it's a nice to have feature, but needs Kernel patching as long as LinuxAPI doesn't support it itself. And also the drivers need to support it too
 

In addition when we have these kind of "auto" tuners we could also remove these settings completely from e.g. the 'manual scan' input... just to simplify the UI. Why enter all these gadgets (FEC, modulation type) when it is not required at all..? Then I prefer to add a feature to remove all the details when they are not required...

Yes nice idea, but this also need properly working drivers

 

@WanWizard

Where does the ETSI standard state that MIS is mandatory? It's not mandatory for broadcast.

Edited by dhwz, 8 December 2017 - 15:33.

[littlesat]

Then we should at least wait for an upgrade of the LinuxAPI... 

And we have to wait for a solution that the drivers give workable properties...