[linux-dvb] DVB API update

Manu Abraham abraham.manu at gmail.com
Wed Oct 3 14:21:59 CEST 2007


Hi,

Simon Hailstone wrote:
> 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
> 

If someone has the hardware, we can take a go at it.

Regards,
Manu

> Best Regards,
> Simon Hailstone
> 
> On 16/09/2007, *Wolfgang Wegner* < wolfgang at leila.ping.de
> <mailto: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 <mailto:linux-dvb at linuxtv.org>
>     http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 
> 




More information about the linux-dvb mailing list