[linux-dvb] DVB API update
abraham.manu at gmail.com
Wed Oct 3 14:21:59 CEST 2007
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 :
If someone has the hardware, we can take a go at it.
> 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
> 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
> > 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
> > 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
> 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
> > 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
> > > 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,
> linux-dvb mailing list
> linux-dvb at linuxtv.org <mailto:linux-dvb at linuxtv.org>
More information about the linux-dvb