TBSDTV Community Forum

DeEmEx wrote:From EnoSat:
- 16APSK
- 31°E
- 11914 Mhz
- Horisontal
- SR 26400

strong signal:

switch off 16APSK , now use some 8PSK - http://www.youtube.com/watch?v=MBDWzqhPWMA

cody
May be it's time to move this topic in 6925 section?
What about price of 6925?

EnoSat wrote:

DeEmEx wrote:From EnoSat:
- 16APSK
- 31°E
- 11914 Mhz
- Horisontal
- SR 26400

strong signal:

switch off 16APSK , now use some 8PSK - http://www.youtube.com/watch?v=MBDWzqhPWMA

next switch MODE - http://www.youtube.com/watch?v=r5lSiQTT81c , no LOCK on my Prof 7301

Which PCIe bridge will be used?
Is it possible to receive the RAW BBFrame payload to support other encapsulations like GSE?

freddy wrote:Which PCIe bridge will be used?

no final decision about that is made yet

freddy wrote:Is it possible to receive the RAW BBFrame payload to support other encapsulations like GSE?

the feature is under the investigation and that's why what PCIe bridge will be used in the final product is not decided yet.

cody wrote:the feature is under the investigation and that's why what PCIe bridge will be used in the final product is not decided yet.

That sounds great.
Any time plan on this?
Please consider the driver licence too when choosing the bridge.
I know that ST allows open source drivers and open source drivers are an important "feature" for us.

PS: Do you know if anyone from Tbsdtv is at the IBC in Amsterdam?

freddy wrote:Any time plan on this?

that's kind of tricky to answer considering that it's very complicated, but within Q4 i guess is safe estimation.

freddy wrote:Please consider the driver licence too when choosing the bridge.

that's not a concern - if we managed to provide the feature as it's planned, the bridge driver will be open-source and GPL.

freddy wrote:I know that ST allows open source drivers and open source drivers are an important "feature" for us.

yes, ST code is open-source and under GPL license.

freddy wrote:PS: Do you know if anyone from Tbsdtv is at the IBC in Amsterdam?

last year i attended IBC, but this year i'm too busy working on our on-going projects and decided that i don't have the time and after all i can exchange the same information with customers via e-mails or forums. sure, it's not like meet with them face to face, but considering our current priorities it seems like good compromise to me.

One more feature request:
In case you have to design your own PCI bridge (FPGA/ASIC based), it would be great if it supports ACM signaling as describe in "Mode Adaptation Input and Output Interfaces for DVB-S2 equipment" section L.3/L.4 by SatLabs [1].
Probably can be done in software too but I guess offloading it to the hardware is much faster. I just hope that the STM demod can handle this.

[1] http://satlabs.org/pdf/sl_561_Mode_Adap ... t_v1.3.pdf

@freddy

as far as i understand what you're referring to is just sending back some information to the modulator, right? it's something you have to implement in software - you can get that information from the hardware and do with it whatever you want.

cody wrote:@freddy

as far as i understand what you're referring to is just sending back some information to the modulator, right? it's something you have to implement in software - you can get that information from the hardware and do with it whatever you want.

Yes, in the end it's used for ACM. To do this it would be great to have the SNR for each received PLFrame/BBFrame. AFAIK the only way to get the SNR from the STM demod is to read the DSTATUS register via I²C.
To query the register on every received frame might not be possible in software (timing issues) and it will be quiet expensive on the CPU side (a lot of I/O wait).
If it can be done in hardware and the SNR is sent as part of the data, it's the most efficient way to do this.