Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Andreas Oberritter]

Hallo Thomas,

thank you for your contribution. However, I'm against applying it.

On 01/10/2011 05:19 AM, Thomas Schlöter wrote:
> I have developed some modifications to the 2.6.37 DVB frontend code to support DVB satellite channel routing (aka "SCR", "Unicable", "EN50494"). Following this standard, all satellite tuners share the same cable and each of them has a fixed intermediate frequency it is supposed to tune to. Zapping is done by sending a special DiSEqC message while SEC voltage is temporarily pulled from 14 to 18 volts. This message includes the tuner's ID from 0 to 7, the frequency, band and polarisation to tune to as well as one out of two satellite positions.
> 
> I decided this should be supported by the kernel frontend code as it is impossible to send that special DiSEqC / voltage sequence from userspace.

Why do you think that's impossible? There's a userspace implementation
in Enigma2.

> Additionally, it adds fully transparent support for SCR to arbitrary applications that use the DVB API, such as MythTV, VDR, xine etc.

That statement is not true, because you have to configure Unicable LNBs,
which you do using dvb-scr-setup.c.

Regards,
Andreas

Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Thomas Schlöter]

Hallo Andreas,

Am 10.01.2011 um 14:09 schrieb Andreas Oberritter:

> Hallo Thomas,
> 
> thank you for your contribution. However, I'm against applying it.
> 
> On 01/10/2011 05:19 AM, Thomas Schlöter wrote:
>> I have developed some modifications to the 2.6.37 DVB frontend code to support DVB satellite channel routing (aka "SCR", "Unicable", "EN50494"). Following this standard, all satellite tuners share the same cable and each of them has a fixed intermediate frequency it is supposed to tune to. Zapping is done by sending a special DiSEqC message while SEC voltage is temporarily pulled from 14 to 18 volts. This message includes the tuner's ID from 0 to 7, the frequency, band and polarisation to tune to as well as one out of two satellite positions.
>> 
>> I decided this should be supported by the kernel frontend code as it is impossible to send that special DiSEqC / voltage sequence from userspace.
> 
> Why do you think that's impossible? There's a userspace implementation
> in Enigma2.

I think the kernel implementation would be superior for two reasons:
- There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code,

- In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.

> 
>> Additionally, it adds fully transparent support for SCR to arbitrary applications that use the DVB API, such as MythTV, VDR, xine etc.
> 
> That statement is not true, because you have to configure Unicable LNBs,
> which you do using dvb-scr-setup.c.

Sure, you have to configure Unicable LNBs as you have to configure for example Universal LNBs. So the viewer software has to be aware of your DVB setup's parameters. If you want to have a configuration menu in the viewer software, this software only needs to send a simple ioctl message to the frontend to configure Unicable. If you want to use Unicable with viewers that do not support it, you only have to set your parameters at boot time using dvb-scr-setup.c.

That way, they are also a bit more protected against unintentional changes. In a Unicable system, all participants have interferences if there is one participant using bad settings. So if you start a DVB viewer which is badly or not yet configured, all other participants are disturbed. If you configure your Unicable system using e.g. an init-script, it is impossible to disturb anyone by starting some "Non-Unicable" software.

This can be compared to the setup of serial ports, I think. As far as I know, there is a setup utility to have the parameters set (probably at boot time), afterwards you start the actual application.

Regards,
Thomas

Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Andreas Oberritter]

On 01/10/2011 04:07 PM, Thomas Schlöter wrote:
>>> I decided this should be supported by the kernel frontend code as it is impossible to send that special DiSEqC / voltage sequence from userspace.
>>
>> Why do you think that's impossible? There's a userspace implementation
>> in Enigma2.
> 
> I think the kernel implementation would be superior for two reasons:
> - There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code,

Unless there's proof, I won't believe that. We're not talking about
nanoseconds, but milliseconds, and it's about setting registers of slow
I2C devices. The same timing requirements are valid for each and every
backwards compatible DiSEqC sequence, which is the most common setting.

> - In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.

Many of these applications didn't or don't support DiSEqC 1.1
(uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still,
we don't put this logic into the kernel to make their life easier. Don't
add unneeded complexity to the kernel.

Of course, one could decide to start a reusable library to take care of
that stuff. Honestly, I don't know whether such a library exists today.

If you find the patch was simple enough to be applied to the kernel, it
must be as simple to patch your favourite application, even in a
platform independent way (not taking into account the required changes
to the UI, which have to be done anyway).

Regards,
Andreas

Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Oliver Endriss]

On Monday 10 January 2011 16:54:14 Andreas Oberritter wrote:
> On 01/10/2011 04:07 PM, Thomas Schlöter wrote:
> >>> I decided this should be supported by the kernel frontend code as it is impossible to send that special DiSEqC / voltage sequence from userspace.
> >>
> >> Why do you think that's impossible? There's a userspace implementation
> >> in Enigma2.
> > 
> > I think the kernel implementation would be superior for two reasons:
> > - There are some timing requirements regarding the 14/18V transitions and the DiSEqC message which could perform better directly from the frontend code,
> 
> Unless there's proof, I won't believe that. We're not talking about
> nanoseconds, but milliseconds, and it's about setting registers of slow
> I2C devices. The same timing requirements are valid for each and every
> backwards compatible DiSEqC sequence, which is the most common setting.
> 
> > - In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.
> 
> Many of these applications didn't or don't support DiSEqC 1.1
> (uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still,
> we don't put this logic into the kernel to make their life easier. Don't
> add unneeded complexity to the kernel.
> 
> Of course, one could decide to start a reusable library to take care of
> that stuff. Honestly, I don't know whether such a library exists today.
> 
> If you find the patch was simple enough to be applied to the kernel, it
> must be as simple to patch your favourite application, even in a
> platform independent way (not taking into account the required changes
> to the UI, which have to be done anyway).

Ack, this stuff should be implemented as a userspace library.
(Btw, there is an experimental unicable patch for VDR.)

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [InfraSchlot SPAM Check] Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Thomas Schlöter]

Hello Oliver,

Am 10.01.2011 um 18:28 schrieb Oliver Endriss:

> Ack, this stuff should be implemented as a userspace library.
> (Btw, there is an experimental unicable patch for VDR.)

Yes, there is. I have not testet it as I am going to use MythTV, but for what I have read in some forums, many people have problems using that patch. This is why I decided to make a kernel implementation for my system. But I agree it could also be implemented as a wrapper application between frontend device and viewer application (the quick and dirty way) or native support in a userspace library (which will take some time until it is used in all DVB applications).

What I thought makes my solution attractive is, that you can even use dvbscan, szap etc. without modification, which works perfectly in my setup. But anyway the purpose might be too special to have it inside the kernel.

Regards,
Thomas

Re: [PATCH] DVB Satellite Channel Routing support for DVB-S

[Thomas Schlöter]

Am 10.01.2011 um 16:54 schrieb Andreas Oberritter:
> 
>> - In many TV recording applications there is no support for SCR and it would be harder to implement in these. For VDR, there is a patch which is difficult to configure and has some technical limitations. In MythTV and XMBC I could not find any support for SCR. Their Wiki pages or forums say, that there are no plans for Unicable support as it would take huge changes.
> 
> Many of these applications didn't or don't support DiSEqC 1.1
> (uncommittted switches) or DiSEqC 1.2 (rotor commands) or USALS. Still,
> we don't put this logic into the kernel to make their life easier.

> Don't add unneeded complexity to the kernel.

I think this is the point we are talking about and I understand the feature might not be critical enough to justify a kernel implementation.

Regards,
Thomas