[linux-dvb] DVB API update

Simon Hailstone simon.hailstone at gmail.com
Tue Oct 2 16:49:34 CEST 2007


Hi All,

If it sheds any light on the nature of DVB-ASI, there are Linux drivers
available ( with source ) for the DekTec ASI adapters here :

http://www.dektec.com/Products/LinuxSDK/Downloads/LinuxSDK.zip

Best Regards,
Simon Hailstone

On 16/09/2007, Wolfgang Wegner <wolfgang at leila.ping.de> wrote:
>
> Hi Manu,
>
> On Sun, Sep 16, 2007 at 02:17:55AM +0400, Manu Abraham wrote:
> > Please don't remove the CC's. The CC'd people generally don't bother
> > about mails from the ML, probably.
>
> sorry, it was definitely not my intention and I hope to include
> all previous CC here.
>
> [have to read about the multiproto changes myself...]
>
> > Can you please point me to some ASI specs if you don't mind ?  I was
> > once supposed to work on such a device, but then that company itself got
> > scrapped, hence never had to figure out on ASI.
>
> Well, AFAIK the ASI specification is not open, so I unfortunately I
> can not point to it.
> To be honest, the only thing about ASI comes from a fronted we use at
> the company in professional equipment, so I am not sure if the things
> I can tell from there are really valid for all ASI equipment. However,
> as from time to time questions come up concerning DekTec and other boards,
> at least some basic support for ASI seems to be desirable.
>
> So, coming to the facts, our ASI frontend gives these as "statistics":
> - BER
> - sync status
> - 204 or 188 byte/packet mode
>
> [...]
> > Since it is an IOCTL call straight away within the V3 API, i would like
> > to push this into the frontend thread where it is submitted as a job
> > kind of thing, where the userapplication can be notified in what
> > timeframe, or via GET_EVENTS, final details can be left out for the last
> > stage.
>
> This sounds very reasonable for me. I have no idea yet how this frontend
> thread is handled now, but after all all necessary information should be
> present there (e.g. lock state, to do a proper reset of averaging etc.).
>
> > Scale for BER is one thing that is still open ended, which i am off
> > hook. I need to still check on this, but if you have some ideas would be
> > nice.
>
> Hmm... I am not sure what is needed by others, so my voice should not
> be given too much weight here. We always use 10^-8 as the base, but for
> some equipment this might already be too rough. On the other hand, IIRC
> some demodulators do not return more accurate values anyways.
>
> > Signal Strength & SNR:
> >
> > In reality we can provide 2 ways for the same,
> > 1) Relative scale
> > 2) a scale in a decibels
> >
> > Even with Reverse Engineered drivers we can do 1) but for 2) we might
> > need more info. The user could probably select what he needs using an
> > IOCTL, relative or an absolute scale. For the relative one we can just
> > define a floor and ceiling and a relative value is extracted out.
>
> That is what I was thinking of, for most applications this would be
> sufficient. I do not know what is the better solution here. Following
> your proposal of two different styles of return values makes life easier
> for the application (which could request the "scale" type and just take
> this value). Even knowing the exact decibel value would make it necessary
> to interpret it differently for different transmission schemes, i.e. 8 dB
> SNR in DVB-S is no problem while there would be no reception in DVB-C...
> On the other hand it might be confusing to get different values for the
> same thing, which I treat as an argument for my proposal of always (if
> possible) returning the dB value and giving the application (and user)
> the demod min and max values for drawing a nice percentage scale.
>
> For a few demods I could provide the dB calculation (namely STV0299,
> STV0288, TDA10046, TDA1002x), but probably these are those with
> fewest problems anyways.
> For others (e.g. STV0297) there seems to be no calculation possible,
> I know of other implementations using a look-up-table. If needed, I
> could do some measurements and see if we manage to get good results
> with a look-up-table, too.
>
> > know anything. In some cases people would like to get the absolute value
> > for some instrumentation reasons.
>
> It makes comparison of different frontends/setups easier, too. At least
> in some forums people try to compare their dish and stuff with this, so
> not only addicts like us might want to see these values. ;-)
>
> [Sorry for deleting your most interesting part about silicon tuners -
> I have not had my hands on one yet, so cannot comment]
>
> > > I understand floating-point is not possible in the kernel, but what
> > > other possibilities are there to get rid of the device-dependent snr
> > > calculation in the application? Please, no debate about complete
> user-space
> > > driver here! I really hope there are other solutions, but I have no
> idea
> > > what is possible.
> >
> >
> > Currently we have a log10 implementation in dvb-core in dvb-math.c We
> > can use this for the same, but we will still need some careful hand
> > crafted integer calculations, complexity depending upon the hardware
> > itself, since it is vendor specific. This also requires that one must
> > have proper specifications for the devices for this to be done.
>
> This is good news! I will have a look at current implementation and see
> if I can play with it a bit (to test how my above mentioned calculations
> fit here). There will definitely be some re-work be necessary, because up
> to now I used float calculations without much thinking...
>
> > Thanks,
> > Manu
>
> Best regards,
> Wolfgang
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20071002/aeddb21a/attachment-0001.htm 


More information about the linux-dvb mailing list