Blindscan on linux with tbs cards

[deeptho]

I have written that using the tbs drivers 6903x can tune to the specific freq but 6909x does not.
But why neumo drivers don't work with 6903x at least ?

Why do you think I would be able to guess the answer to that question? I already gave possible reasons of the "guess type".

If you wish to get help then you need to provide information that can help find the cause...

 

[tasoss]

Why do you think I would be able to guess the answer to that question? I already gave possible reasons of the "guess type".

If you wish to get help then you need to provide information that can help find the cause...

Thank you for your help.
ps: Just in case you didn't see my previous message

I can give you access and see by yourself. Tell me how i can contact you.
------------------------------------------------------------------------
I am available to provide whatever you want. Just ask me.

 

[deeptho]

Thank you for your help.
ps: Just in case you didn't see my previous message

Yes I noticed that. I also noticed that you did not want provide extra information....
Let us first try that. For any bug report, the minimum needed is
-which command did you start, with which parameters
-what appeared on the console (as text, not a screen shot, not omitting some parts)
-what drivers are you using (cat /sys/module/dvb_core/info/version)
-what appears in /var/log/debug (or similar file which kernel debug output)

I just double checked at home. neumo-tune and stid135-blindscan work as expected with the current drivers
on tbs6909x. I did not try 6903x because I do not have it in my pc.

So I can tell you "it works for me", but that is as useful for you as you saying to me "it does not work for me".
It brings us no closer to any solution.

 

[tasoss]

Sir, i am not here to spam or troll.
I need to take a serious decision for my job.
I am giving you total control and you are telling me i don't WANT to provide info.
For God's sake!
I am not also here for creating problems or arguing with people. Really.
Ok i will send you send the info that you have asked from now on.
Thanks again for your help.

 

[tasoss]

Hello again.
I am including the things that you have asked.
The debug output can be found here

cat /sys/module/dvb_core/info/version
type = "neumo";
version = "1.6";

The command is

stid135-blindscan -cblindscan -a 2 3 4 5 6 7 8 9 --rf-in=0

and the output is here and the transponders found here

I have also included blind scan results from 6903x (using TBS's blind scanner) here

Moreover using neumodvb the results are as expected (simular to the results of 6903(not X) and 6903x(using TBS's app)).

 

[deeptho]

I think I finally understand what you mean: your earlier message suggested that scanning does not work and finds only one transponder, but your log files now show that it is all working mostly correctly and that you are probably wondering about
why there are no frequencies found above 12500Mhz.

The answer is simple: it does not find any peaks there. The reason that neumodvb finds more peaks is that it uses a different (better) peak finding algorithm. The fact that the missing ones are above 12500Mhz is just a coincidence.

What satellite is this?

 

[tasoss]

I am glad! Really.

How can you explain the fact that windows blind scanning using 6903x can find the frequencies that we are talking
about and the linux version does not ? I mean does it have to do with the drivers(i don't mean that it's your fault)? I suppose the peak finding
algorithm that you are talking about is software based. So they may be missing something in Linux implementation.(I am asking out of curiosity)

The sattellite is Eutelsat 16A at 16.0°E.
I would like to ask you a question , in case there is no solution but to use neumodvb.
How difficult is it to change stid135-blindscan in order to use your better algorithm ?
I am in no way good in C/C++ but i could give it a try and maybe with some help to achieve it.
Currently i am investigating the source code of neumodvb. You have created great stuff.
Thanks again!
ps: If you need access to the satellite please let me know.

 

[deeptho]

It is not difficult. It is the code in spectrum_algo5.cc

 

[tasoss]

Thank you i will give it a try.

 

[deeptho]

I have just release a driver update. Note that these drivers have not been well tested yet and there may
be some problems, but at least basic functionality works.

From a practical point, the drivers fix a problem on the multistream on 12606V @5.0W, which no longer
worked on stid135 cards due to what is probably a hardware bug. To make this stream work add
the following line to /etc/modprobe.d/stid135.conf:

options stid135 bbframes_auto=1

Install the new drivers and reboot.

Internally the code works by asking the chip to output a "bbframes stream" and let the drivers extract
the transport stream. This happens only for multistreams, but has as a side effect that ALL streams in the
mux are available at the output. This means that multiple streams can be accessed with a single demod at the
same time.

Currently the only program that supports using this is neumo-dmx, part of the command-line neumo tools.
Here is an example. Note that this only works on stid135 based cards!!

First tune to a mux, using adapter 8 and the LNB the cable connected to RF input 1. The LNB is connected to a switch
on uncommitted port 3. The mux we tune is 12606V on 5.0W. It uses physical layer srambling with code ROOT+16416.
We ask the frontend to output bbframes instead of a stransport stream:

neumo-tune -ctune -A blind -a 8 -r 1 -U3 -f 12606000 -pV --pls-code=ROOT+16416  --stream-id=4 -b &

Now extract the two streams by connecting to frontend 0 on demux 8. We specify 0x2000 as the pid,
which means the whole transport stream. the two streams have ISI 3 and 5:

neumo-dmx -a 8 -d 0 --pid 0x2000 -b   --bbframes-isi=4 > /tmp/stream4.ts &
neumo-dmx -a 8 -d 0 --pid 0x2000 -b   --bbframes-isi=5 > /tmp/stream5.ts &

After a while stop the three commands (neumo-tune and neumo-dmx):

killall -KILL neumo-dmx neumo-tune

Stream 4 is a regular transport stream as can be seen by inspecting it with

tsanalyze /tmp/stream4.ts

Stream 5 is a transport stream containing one T2mi stream with pid 0x1000. Extract it as follows:

tsp -P t2mi --pid=0x1000  < /tmp/stream5.ts > /tmp/stream5b.ts

Then it can be analyzed as follows:

tsanalyze /tmp/stream5b.ts

These streams can also be played by vlc.

With some appropriate linux piping, these streams can also be streamed over the network, simultaneously.

 

[tasoss]

Happy new year and thanks for the updates!
Nice present.
In the blindscan app the file neumo-dmx.cc is missing.
Can you please take a look ?
Thanks!

 

[deeptho]

It should be fixed now.

 

[tasoss]

Yes it's ok now.
Could your changes justify additional time in the blind scanning process(almost double time) ?

I will contact again in the following days because i haven't solved my main issue(make stid135-blindscan use your algorithm).
I will try it a little bit more.
Thanks again.

 

[deeptho]

Yes it's ok now.
Could your changes justify additional time in the blind scanning process(almost double time) ?

No.

I will contact again in the following days because i haven't solved my main issue(make stid135-blindscan use your algorithm).
I will try it a little bit more.
Thanks again.

Ok.

 

[satesco]

"sat@ubu:~$ neumo-tune -ctune -A blind -a 8 -r 1 -U3 -f 12606000 -pV --pls-code=ROOT+16416 --stream-id=4 -b &
[1] 35605
sat@ubu:~$ neumo-tune: command not found
^C
[1]+ Exit 127 neumo-tune -ctune -A blind -a 8 -r 1 -U3 -f 12606000 -pV --pls-code=ROOT+16416 --stream-id=4 -b &"

What is the command to activate neumo-tune?
Here is what I got after giving the above command.

 

[tasoss]

try the following to find the location of the file

find ~ -name neumo-tune -executable -type f

in my case it is

/home/tasoss/bin/neumo-tune

then run

/home/tasoss/bin/neumo-tune -ctune -A blind -a 8 -r 1 -U3 -f 12606000 -pV --pls-code=ROOT+16416 --stream-id=4 -b

 

[satesco]

Thanks, @tasoss, for the tip.

I have updated the drivers for the 6909x. I hope they are correctly installed.

Unfortunately, it didn't help me to find out more about the 12606 V, as @deeptho indicated, and I think that's because of the weak signal this mux and 12627 H have with my antenna(?).
But what intrigues me more is that the same bug in the 6909x card that our colleague is talking about seems to affect muxes 12648 V and 12731 V as well.
I'm not sure about that, but we'll have to hear from those who work with 6909x on those muxes.

But what reinforces my belief is that this bug on the 6909x card affects and manifests similarly on the two muxes,12648 V and 12731 V, under Windows 11. These also cannot be locked with Crazyscan.
Unfortunately, I can't save the Crazyscan spectrum because the app crashes when I try to lock these muxes.
The tbs6903x card scans and locks the signal in the upper band at 5.0W.
I would be surprised if it only showed these problems with the 6909x card. I don't know how it is with @deeptho's card.

I scanned the upper band at 5.0W with different cards, the best-behaved 6902se, which found MIS mux on auto search.
TBS 6590 scans signal correctly but doesn't lock any MIS mux,
As we already know, the driver for tbs6983 is not friendly, so neumoDVB doesn't even identify muxes. Instead, it finds a manual signal locked on these.
The 6909x card found and locked only some of these muxes at 5.0E.
Probably, the signal is too weak for 6909x to lock12606 V,12627 H. However, it is inexplicable that this card does not lock 12648 V and 12731 V, whereas with 6983 and 6902se, it is strong.

Here's what the neumoDVB spectrum looks like with the mentioned cards at 5.0W:

 

[satesco]

Continuation of the previous message:

 

[deeptho]

Thanks, @tasoss, for the tip.

I have updated the drivers for the 6909x. I hope they are correctly installed.

Unfortunately, it didn't help me to find out more about the 12606 V, as @deeptho indicated, and I think that's because of the weak signal this mux and 12627 H have with my antenna(?).
But what intrigues me more is that the same bug in the 6909x card that our colleague is talking about seems to affect muxes 12648 V and 12731 V as well.
I'm not sure about that, but we'll have to hear from those who work with 6909x on those muxes.

But what reinforces my belief is that this bug on the 6909x card affects and manifests similarly on the two muxes,12648 V and 12731 V, under Windows 11. These also cannot be locked with Crazyscan.
Unfortunately, I can't save the Crazyscan spectrum because the app crashes when I try to lock these muxes.
The tbs6903x card scans and locks the signal in the upper band at 5.0W.
I would be surprised if it only showed these problems with the 6909x card. I don't know how it is with @deeptho's card.

I scanned the upper band at 5.0W with different cards, the best-behaved 6902se, which found MIS mux on auto search.
TBS 6590 scans signal correctly but doesn't lock any MIS mux,
As we already know, the driver for tbs6983 is not friendly, so neumoDVB doesn't even identify muxes. Instead, it finds a manual signal locked on these.
The 6909x card found and locked only some of these muxes at 5.0E.
Probably, the signal is too weak for 6909x to lock12606 V,12627 H. However, it is inexplicable that this card does not lock 12648 V and 12731 V, whereas with 6983 and 6902se, it is strong.

Here's what the neumoDVB spectrum looks like with the mentioned cards at 5.0W:

Satesco,

as you can lock 12606V with other cards (including 6903x? Your message is not clear), this clearly shows that the signal is strong enough.
So it should also work on tbs6909x if you configure everything properly (and not if you don't). Please read what it says in the README.md of linux_media, specifically "Changes in release-1.5".