TBSDTV Community Forum

Hello,

this one is for developers !
The current version of TBS6925 linux driver does not correctly manage values returned by FE_GET_PROPERTY. Returned status does not give real tuned information (SR, FEC, Inversion, Pilot, Rolloff...) but it does currently return values previously provided to FE_SET_PROPERTY. This is bad because I would like to display these real values
This is not a hardware issue because these values are well returned by the Windows driver. Does anyone know if there any chance to have this issue fixed in the next firmware release ? (in case yes, when ?)
Or alternatively, is there anyone here who has fixed this issue or who is working on it?

Tks

Thats true. FE_GET_PROPERTY isn't implemented in driver to TBS6925.
You can try this topic directly with support writing an email to support@tbsdtv.com

Best regards.

Thank you, this is what I have done yesterday just after having sent this post.

Hi deejayd

Would you mind sending this information to our euro_support@tbsdtv.com too.

Thanks

Hello, let me comment on those matters, because there is a lot that can be said.

so, first of all what you observed about FE_GET_PROPERTY is not (exactly) a bug, because FE_GET_PROPERTY returns the values from the S2API cache and that cache is (usually) set with the tuning parameters that the application software set and not the one detected by the hardware, i.e. the actually tuned parameters after different auto-detections made by the hardware. it could be debated a lot of FE_GET_PROPERTY and what it's supposed to do or what not and how that changes from the initial version of S2API, i.e. Linux DVB API version 5.0 to the current version, but it's pointless, because my understanding about what you need and want to get is achieved using FE_GET_FRONTEND - in fact in reality most likely FE_GET_PROPERTY just falls back to calling FE_GET_FRONTEND anyway. unfortunately, if you 'grep' all existing open-source DVB-S/S2 demodulator drivers in Linux you will see that 'get_frontend' is not implemented at all or there is some "fake" or partial implementation. unfortunately, that applies for the open-source STV090x demodulator driver too, which 6925 driver for Linux uses - we don't make STV090x demodulator driver for Linux and thus 'get_frontend' implementation of it is "as is". however, all DVB-S2 demodulator drivers we developed - for example for TBS 6981, etc have real 'get_frontend' implementation and report back the actual tuned signal parameters obtained from the hardware after the signal lock was acquired and my understanding that's what you want. however, 'get_frontend' is not aware of some S2 parameters and that's why what TBS drivers returns is 'proprietary' format in a sense that you need to know how to parse it to determine some parameters like the detected modulation type of the signal. anyway, in short in the current state of the Linux DVB-S2 drivers (and i'm talking just about the TBS drivers) the closest to what my understanding is you need you can get it with the TBS 6981 driver (and basically all other TBS cards based on NXP demodulator chips like 6984, etc). also, some of the real signal parameters you can get with parsing BBHeader information that 6925 can provide and for which recently i posted some easy-to-use patches for the TBS Linux driver packages here:

http://www.spinics.net/lists/linux-media/msg45597.html

so, bottom line is that you need to define more exactly which parameters of the actually tuned signal you're interested in (as i mentioned 'get_frontend' has some limitations and thus you can be facing even more issues for addressing, e.g. changes to the S2API), then see if what current implementation of 'get_frontend' for some of the TBS models is suitable for your needs (as i mentioned basically the only DVB-S2 hardware with real 'get_frontend' is made by TBS anyway, e.g. 6981, 6984, etc) and if yes use it and maybe for some parameters BBFrame capabilities of 6925 will be useful, i.e. use combination of 6925 and 6981. however, to count for 'get_frontend' implementation for 6925 due to single customer request owning one 6925 is something that can take forever, because it will be lowest priority in a really very long list of Linux tasks - for example 'get_frontend' implementation for the other boards i mentioned was made for a very big project and that's why it was cost effective and priority to make that implementation.

Thank you very much Cody for your very clear reply. I'll have a deep look at the BBFrame / BBHeader suggestion, if this is the only option for TBS6925 at the moment ...

Here are my patch's for the TBS src tree, this will enable FE_GET_PROPERTY to return the values actually used for the lock, not what you typed in.

https://docs.google.com/open?id=0B7PjDR ... lVOSnYwYkU

patch's some Prof 7500 things as well if you have one. Also includes crazycats multistream patch and some others tuning speedups for the 7500

UDL

Hello Updatelee,
Thank you very much for your patches ! This is exactly what I was looking for.
I applied the patches aiming at enabling FE_GET_PROPERTY real values for my TBS6925 (I already applied the multistream patch) and it works... partially.
I can now get real values for frequency, standard, SR, FEC, pilot and inversion.
However, Rolloff and Modulation values desperately remain empty.
Also, I noticed that sor some DVB-S txp, the FEC value is still returning "Auto" (seems to work fine for DVB-S2 txp).
Did you face the same issue and , if yes, do you have a fix for this ?

Update: I have been able to patch the driver to get the correct modulation and FEC values in all cases. The thing is, the "modcode" values returned by the 6925 driver do not seem to be 100% compliant with the DVB standard for DVB-S QPSK ...
I have only one remaining issue: I am unable to get any Roll-off value in DVB-S2 (zero is always returned). Any idea ?