Blindscan on linux with tbs cards

[Satspot]

@deeptho +1 on that sentiment. Something that needed saying and was long overdue. Can you imagine what would be said here if you charged for your services.

 

[moonbase]

Well, Frankviana,

unless I am mistake, ebspro does not run on linux.
So you have a a number of options
1) install linux and use my drivers and then post something good or bad in this thread
2) keep using windows, test the latest drivers and open an another thread to complain about them.
3) complain to the manufacturer
4) keep waiting
5) combination of one of the above

Remember that blindscan on windows (and linux) is implemented by volunteers. You could encourage the ebspro
and streamreader developers. The best way is by a constructive attitude, e.g,. by reporting to them specific, clearly decribed
problems with the latest version of their software and/or making a financial donation to them.

PS. I am not one of them.

Please note that forum member @frankviana is not English, I think he is from Brazil with possibly Portugese as his native language.
When English is not the native language there can sometimes be confusion over how a reply was intended, particularly if an online translation tool was used to create a reply.

 

[frankviana]

Sorry.... this thread is for linux with tbs cards...

Please delete previous post about ebspro/Windows software.

Thx

 

[frankviana]

Some tests today (70W)

neumoDVB:






frank@Frank-X99-TF:~$ uname -a
Linux Frank-X99-TF 5.13.0-51-generic #58~20.04.1-Ubuntu SMP Tue Jun 14 11:29:12 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

frank@Frank-X99-TF:~$ dvbsnoop -s feinfo
dvbsnoop V1.4.50 -- dvbsnoop - DVB Stream Analyzer, MPEG Analyzer

---------------------------------------------------------
FrontEnd Info...
---------------------------------------------------------

Device: /dev/dvb/adapter0/frontend0

Basic capabilities:
Name: "TurboSight TBS 6903x "
Frontend-type: QPSK (DVB-S)
Frequency (min): 950.000 MHz
Frequency (max): 2150.000 MHz
Frequency stepsiz: 0.000 MHz
Frequency tolerance: 0.000 MHz
Symbol rate (min): 0.010000 MSym/s
Symbol rate (max): 520.000000 MSym/s
Symbol rate tolerance: 0 ppm
Notifier delay: 0 ms
Frontend capabilities:
auto inversion
FEC AUTO
QPSK

Current parameters:
Frequency: 1139.391 MHz
Inversion: ON
Symbol rate: 34.284013 MSym/s
FEC: FEC 3/4

frank@Frank-X99-TF:~$

Tvheadend:

 

[pk008]

how can i remove Uninterruptible sleep (usually IO) state of process (in htop) while doing spectrum analysis of all 4 ports simultaneously in TBS6909X card? And what can be reason, is it because of demod(card) limitation or driver or kernel?

If I run spectrum scan in only one adapter, it takes around 6-7 secs but if i run all 4 adapters simultaneously, it talks 20 to 30 secs to finish!

Kernel: 5.9.0-050900-generic
OS: Ubuntu 18.04.6 LTS
CPU: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz

 

[deeptho]

how can i remove Uninterruptible sleep (usually IO) state of process (in htop) while doing spectrum analysis of all 4 ports simultaneously in TBS6909X card? And what can be reason, is it because of demod(card) limitation or driver or kernel?

Sorry., I have no idea what you are talking about.

If I run spectrum scan in only one adapter, it takes around 6-7 secs but if i run all 4 adapters simultaneously, it talks 20 to 30 secs to finish!

Kernel: 5.9.0-050900-generic
OS: Ubuntu 18.04.6 LTS
CPU: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz

A spectrum scan of one band should take 30 seconds on one demod. On 4 in parallel it might be slower due to the i2c bus being shared
and most of the time is actually wasted in data transfer over this "slow" link (400 kBit/s)

 

[pk008]

A spectrum scan of one band should take 30 seconds on one demod. On 4 in parallel it might be slower due to the i2c bus being shared
and most of the time is actually wasted in data transfer over this "slow" link (400 kBit/s)

ok, that make sense, but cant we increase i2c bus speed?

what can be the reason behind getting mixed modulation (QPSK and 8-PSK) constellation picture? Im not getting same noise/extra cluster every time, sometimes I get fine points, sometime dont!

8-PSK:

QPSK:

 

[satesco]

It might be true on Linux what I noticed on Windows, that is, if the transmission is in the generic stream with several streams at the same time, then the modulation changes depending on the stream.
I noticed this once on ChinaSat 12 on 87.5E. It was transmitting simultaneously multistream and I could see the parameters change for each stream used. 5 streams were transmitted at the same time in clear.
Of course, I am waiting for Deeptho's opinion on this matter.

 

[deeptho]

It might be true on Linux what I noticed on Windows, that is, if the transmission is in the generic stream with several streams at the same time, then the modulation changes depending on the stream.
I noticed this once on ChinaSat 12 on 87.5E. It was transmitting simultaneously multistream and I could see the parameters change for each stream used. 5 streams were transmitted at the same time in clear.
Of course, I am waiting for Deeptho's opinion on this matter.

Well, With Adaptive or variable coding, you would expect this to occur.

About the i2c bus: nothing can be done about it, with perhaps one theoretical exception: it is possible to put the chip
in "versatile tuner mode". Then it would be possible to read data at much higher rates and perform the spectrum analysis
on a PC. While the stid135 chip supports this, it it not clear at all if the card supports is. It would probably require some
new fpga firmware, and perhaps even a redesign or some soldering. It depends on how the board is wired.

It would also allow things like the waterfall display, basically turning the card into a receiver for software defined radio
(or in fact: 8 of those with a user-selectable capture bandwidth between 100kHz and 129Mhz, so pretty high specs which could
also overload the pc)

 

[pk008]

Well, With Adaptive or variable coding, you would expect this to occur.

so how can we fix it?

about i2c speed: [UP2] How to select I2C speed mode ?
will this work?

 

[deeptho]

so how can we fix it?

What needs to be fixed?

about i2c speed: [UP2] How to select I2C speed mode ?
will this work?

This is completely unrelated

 

[pk008]

What needs to be fixed?

this:

what can be the reason behind getting mixed modulation (QPSK and 8-PSK) constellation picture? Im not getting same noise/extra cluster every time, sometimes I get fine points, sometime dont!

It might be true on Linux what I noticed on Windows, that is, if the transmission is in the generic stream with several streams at the same time, then the modulation changes depending on the stream.
I noticed this once on ChinaSat 12 on 87.5E. It was transmitting simultaneously multistream and I could see the parameters change for each stream used. 5 streams were transmitted at the same time in clear.
Of course, I am waiting for Deeptho's opinion on this matter.

 

[pk008]

This is completely unrelated

ok, thank you.
and even i dont see options to change I2C modes in BIOS

 

[CrazyCat]

Possible change I2C bus speed in tbsecp3 driver. i2c_speed in struct tbsecp3_board
default 9 (400 kHz), but for most card used 39 (100 kHz)

 

[pk008]

linux_media/drivers/media/pci/tbsecp3/tbsecp3-cards.c at latest · tbsdtv/linux_media

TBS linux open source drivers. Contribute to tbsdtv/linux_media development by creating an account on GitHub.

github.com

dont see i2c_speed assigned so should be default 9 (400 kHz)?!

linux_media/drivers/media/pci/tbsecp3/tbsecp3-i2c.c at latest · tbsdtv/linux_media

TBS linux open source drivers. Contribute to tbsdtv/linux_media development by creating an account on GitHub.

github.com

 

[CrazyCat]

yes

 

[deeptho]

this:

this:

The constellation is just showing what is broadcast....

 

[deeptho]

Possible change I2C bus speed in tbsecp3 driver. i2c_speed in struct tbsecp3_board
default 9 (400 kHz), but for most card used 39 (100 kHz)

Yes, but can it be larger than 400kHz without casing problems? Scanning one band/pol takes about
30 000 samples of each 4 bytes. That is 120k samples of 8 bits or about 1Mbit. On reflection, this is probably
not the bottleneck when working in parallel. I will need to investigate.

 

[deeptho]

The 400kHz sample rate is the maximum, according to the documentation.
After some investigation, I can confirm that most of the time in spectrum acquisition is spent
on i2c transfers, not so much on the FFT itself.

Typically, one fft takes 28milliseconds and reading its data takes about 240 ms.
However the code was not optimal and I could reduce that reading time to 155ms.
So that saves about 30% of the time in that part of the code. With these changes,
both polarisations and the high/low bands can then be scanned in 55 seconds.

The existing code also read some data that is not used afterwards. After removing needless
reads, I managed to get some more speedup, leading to only 40s for scanning the 4 bands.

The code also reads the spectrum with 32 bit precision, whereas probably 16 bits is more than
enough. I now implemented an experimental 16 bit mode, which can be activated with

sudo su
echo 0 > /sys/module/stid135/parameters/fft_mode32

This new code now only takes 27 seconds for the 4 bands. If I remember correctly, with the older code
(before any of the optimisations) it took 80 seconds. So that would mean that the new code is almost three
times faster, which is not a bad result.

About sepctrum acquisition on multiple demods in parallel: It appears that locking in the
code made one scan block until the other was finished. This also means that no other
activity, like tuning to a new channel, is possible while spectrum scan was running.

I removed those locks, but there is still some other problem (corruption of spectra), but that might
be solvable.

The i2c bus will remain the bottleneck: only 1 demod can use it at the same time. The good news is that the new code already uses the i2c bus a lot less, and while one demod is reading fft data, the other can compute a new fft. So some parallelisation will be
possible and the total parallel spectrum acquisition time will still be less than double the time for one scan

 

[deeptho]

So after some more testing and fixing bugs: running 2 spectral scans (two satellites) in parallel
takes 42 seconds. If run serially it would two times 27 or 54 seconds. That is a speedup of 50%
due to parallelisation. This speedup is only possible because of the hugely reduced number of i2c
reads. It is still a pity to have a card with 4 fft engines that can run in parallel, but with no way of
quickly reading the data. Of course the fft engines can still be used in parallel for blindscanning,
which is what they were added for.

One more thing to try could be to overclock the i2c bus and see what happens. I think errors will
start to appear.

The current status is that for evey fft 28 ms is needed to compute it (actually it is many ffts that are
computed and then added) and 50ms is needed to read the data. So reducing the 50ms would be
the goal.