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@xxxxxxxxxxxxx > <mailto:wolfgang@xxxxxxxxxxxxx>> 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@xxxxxxxxxxx <mailto:linux-dvb@xxxxxxxxxxx> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
