neumoDVB

[deeptho]

That's the one one I wanted deeptho. Thanks. Blindscan is now ticked in the frontend list.

However, that list arrangement is unfamiliar to me - there's two mac addresses to each TBS tuner. If I choose the TBS6903X that shows as available to me, and go to the LNB in the list, its availability is unticked, hence I cannot tune anything in the spectrum list.

I can show the logfile, but I was hoping you might give me a clue as to where I might be missing something obvious before I do? As I say, I'm not familiar the layout of the adapters in the frontend list.

(I've highlighted adapter2, but obviously I chose A2 TBS 6903X when I went to the LNB list).

View attachment 144729

View attachment 144728

Llew, the non-available ones are probably the result of using some older driver version. You can remove them, then it will
be less confusing. The one(s) you want are A2 and A3 (note: each corresponds to one input).

The only LNB you have currently defined is for the wrong adapter. Try changing it to "A2 TBS6903x". If the lnb is listed as unavailable after this, then it is a bug, or you have already something using the LNB (tune or scan in progress. Can happen when accidentally pressing keys).

 

[Llew]

Working fine now that I've deleted the ghost adapters. A section of the spectrum for testing.
Thanks for your help deeptho.

 

[deeptho]

About the Ka band: today - thanks to satesco - I had access to a Ka band system. There are a few obstacles to making
KaBand work, the main one being that the LOFrequency entered is not accepted correctly. This was fixed in the
latest version and it was possible to scan one of the KaBands afterwards. The fix is on github.

I repeat that if someone gives me a list of bands and oscillator frequencies, then I can add LNB types in a future version.

For instance
Band A: ?
Band B: ?
Band C: ?
Band D; low=21200 high=22200 lo=20250

There is no need for these lnb types. You can also select a Ku-type and enter the correct parameters
yourself, but having defaults is easier.

 

[Llew]

About the Ka band: today - thanks to satesco - I had access to a Ka band system. There are a few obstacles to making
KaBand work, the main one being that the LOFrequency entered is not accepted correctly. This was fixed in the
latest version and it was possible to scan one of the KaBands afterwards. The fix is on github.

I repeat that if someone gives me a list of bands and oscillator frequencies, then I can add LNB types in a future version.

For instance
Band A: ?
Band B: ?
Band C: ?
Band D; low=21200 high=22200 lo=20250

There is no need for these lnb types. You can also select a Ku-type and enter the correct parameters
yourself, but having defaults is easier.

For our purposes, the Ka (strictly K) bands that the LNBs we have do cover those four, namely -

Band A: 18200 - 19200 LOF = 17250 (My Hughes LNB uses a LOF of 17350 - the LOF is adjustable in Crazyscan, perhaps will also be in the app?
*Band B: 19200 - 20200 LOF = 18250
Band C: 20200 - 21200 LOF = 19250
Band D: 21200 - 22000 LOF = 20250

*The Band B LNB used for the Irish Saorsat service uses a LOF of 21200, and an inverted output spectrum of 20200 -19700.

There are various other LNBs with different LOFs, for instance those used for Dish TV and HughesNet in NA, one or two of which members have acquired for experimentation, but best not to muddy the waters at this stage.

 

[Llew]

Seems to be working on KA for me, at least on a data TP on 19.2E.

The LOF of my Hughes (17350 MHz) is recognised.

Can't do a spectrum scan as yet.

 

[Llew]

Column input for my Hughes KA LNB -

 

[Llew]

The spectrum scan of KA Verticals of Astra 1L 19.2E. There's Newsnet at 18557 and a feed at 18511. Unfortunately too weak for me at present.

 

[satesco]

Try 6903. Although with 6903x app finds and lock the signal, if it is weak and at the limit with great difficulty play the image, It does not seem to keep and manage the signal well as in other band.
I used 6903x and 6902se cards and although it finds the signal and saves the program, it fails to show it.
With the 6983's sensitive tuner, even though the spectrum is not yet set up as on other cards, it manages to play the found programs better.
Here's what the spectrum looks like with 6983 and 6903x. With the former you have to manually search for the signal and find the TV program, while 6903s finds them on blindscan, but the signal disappears when you want to see the program even if it has over 12dB.
So for 6903x you need strong signal, while 6983/6903 can play with weaker signal.
I add that this is my first experience with DVB cards on Ka-band. I'll see when I move to 16.0E, where transponders are much closer and have low symbol rate.
We have to thank Deeptho for giving us the opportunity to test his application in this band as well.To my knowledge, I hope I'm not mistaken but this is the first time that we, you or I, are the first users to scan the Ka band on Linux

 

[Llew]

That's interesting. I shall try for a better response with the 6903.

 

[Llew]

Better with TBS6903, although it may also be an increased signal reception (time of day makes a difference with me).

 

[satesco]

On 47.7E we have two frequencies #26(11790 H & 12102 V) with a high symbol rate of 13300 Ks/s. I tried to see if neumoDVB could find it and lock it, as Crazyscan could under Windows.
Strange spectrum for symbol rates of 133000 Ks/s obtained with neumoDVB. It looks like a kind of pyramid made of more than 300 low symbol rate frequencies, from 125 to 1000 Ks/s, none of which is locked.
Just by searching manually, you can see that we have a signal at this high symbol rate without locking it.
Is there another method of scanning this frequency and symbol rate to lock it blindscan or at least manually?
So far, only the 6903x/6909x card could handle these high symbol rates.

 

[Llew]

On 47.7E we have two frequencies #26(11790 H & 12102 V) with a high symbol rate of 13300 Ks/s. I tried to see if neumoDVB could find it and lock it, as Crazyscan could under Windows.
Strange spectrum for symbol rates of 133000 Ks/s obtained with neumoDVB. It looks like a kind of pyramid made of more than 300 low symbol rate frequencies, from 125 to 1000 Ks/s, none of which is locked.
Just by searching manually, you can see that we have a signal at this high symbol rate without locking it.
Is there another method of scanning this frequency and symbol rate to lock it blindscan or at least manually?
So far, only the 6903x/6909x card could handle these high symbol rates.

Could it be a product of the 6903x/6909x tuner using fft to compute the spectrum and showing the individual 'frequencies' of the computation before the analysis has completed in the scan ?

I have come across this in an ACM feed on 14W, but couldn't replicate it later.

Maybe deeptho could explain the effect to us?

 

[deeptho]

No idea, but this does not look right. What card is this?l

 

[satesco]

If you're referring to my screenshot, then it's the 6903x card. I tried several times to get a cleaner spectrum, but each time neumoDVB displayed what you see.
Do you think it's possible to get a better spectrum with this sr 133000?
Added:
I should add that I edited the spectra after BS, then after scanning and then used the cross to show those frequencies.

 

[Llew]

Maybe not related, but on a scan I often get a lot of frequencies other than those on the actual satellite or any nearby. In this instance, 14W.

That's with the TBS6903X.

 

[Llew]

Testing a KA transponder (here Astra1L @ 18767H) with theTBS6903 on the two Linux apps neumoDVB and updateDVB, it's noticeable the difference between the two spectrum scans.

The neumoDVB scan finds a quite broad peak within which you can attempt to lock 18767H. I was unable to do so this time, relying on inputting the frequency/SR details in the tune/mux section for a lock.

In comparison, updateDVB presents a very narrow peak which you need to be quite precise with the pointer to lock the true frequency - the frequency shown in the chart is just the topmost point of the peak, not necessarily the actual TP frequency.

Of course, in updateDVB you can blindscan a required section of the band, which will find the required TP.

I do find updateDVB more convenient to use with the TBS6903 until I'm better aquainted with neumoDVB. ( As yet there's no working driver for the TBS6903X).

 

[deeptho]

Testing a KA transponder (here Astra1L @ 18767H) with theTBS6903 on the two Linux apps neumoDVB and updateDVB, it's noticeable the difference between the two spectrum scans.

The neumoDVB scan finds a quite broad peak within which you can attempt to lock 18767H. I was unable to do so this time, relying on inputting the frequency/SR details in the tune/mux section for a lock.

In comparison, updateDVB presents a very narrow peak which you need to be quite precise with the pointer to lock the true frequency - the frequency shown in the chart is just the topmost point of the peak, not necessarily the actual TP frequency.

Of course, in updateDVB you can blindscan a required section of the band, which will find the required TP.

I do find updateDVB more convenient to use with the TBS6903 until I'm better aquainted with neumoDVB. ( As yet there's no working driver for the TBS6903X).

View attachment 144791
View attachment 144792

View attachment 144793
View attachment 144794

LLew,
tbs6983, and specifically the tuner part is not supported. So the tuner is set to an incorrect bandwidth and that is what you are seeing.

 

[satesco]

....

I do find updateDVB more convenient to use with the TBS6903 until I'm better aquainted with neumoDVB. ( As yet there's no working driver for the TBS6903X).
...

This is normal because STV091X-based cards have been the target of most DVB application developers, especially under Windows, even in Linux, like this DVB update.
That's why the success of these DVB applications has been immediate, and their improvement process is continuously under the attention of these developers.
There are few applications of this kind in Linux because few developers invest time and creativity to develop and improve them.
Now we are fortunate to have Deeptho who has created such a complex application for DVB users on Linux. And he started with the stid135 chip-based card, the most difficult of all that exists today, for which he is to be congratulated.
If he probably had the 6983 or 6903 cards, then the situation would probably be different, and now we would have a neomoDVB capable of matching the performance of those working under Windows.
Hopefully, he will perfect their code for these STV091X-based cards, and we'll be able to use them just like Windows.

ps_Now I see that Deeptho is replying to Llew about 6983/6903. I hope he won't mind me replying to him, especially since I am talking about his application. But I hope what I said above is valid and topical for him.

 

[deeptho]

Maybe not related, but on a scan I often get a lot of frequencies other than those on the actual satellite or any nearby. In this instance, 14W.

That's with the TBS6903X.


View attachment 144788

The spectrum looks quite noisy. I repeat that the peaks are NOT detected transponders, but just "candidate" peaks.
There are many more than usual on this transponder. I see the same in an old spectrum and only on this mux.
It slows down scanning a lot and may make it difficult to lock, so it is a problem, but fixing it (adjusting some internal thresholds) may lead to missing some other muxes.

It would be good to see this spectrum on a bigger dish (or with a stronger signal) to better see what the spectrum is really
like. Also interesting would be what other programs do on this mux (lock it, or take a long time to not lock it or...)

Anyway, it is a good addition to my todo-list. :->

 

[deeptho]

This is normal because STV091X-based cards have been the target of most DVB application developers, especially under Windows, even in Linux, like this DVB update.
That's why the success of these DVB applications has been immediate, and their improvement process is continuously under the attention of these developers.
There are few applications of this kind in Linux because few developers invest time and creativity to develop and improve them.
Now we are fortunate to have Deeptho who has created such a complex application for DVB users on Linux. And he started with the stid135 chip-based card, the most difficult of all that exists today, for which he is to be congratulated.
If he probably had the 6983 or 6903 cards, then the situation would probably be different, and now we would have a neomoDVB capable of matching the performance of those working under Windows.
Hopefully, he will perfect their code for these STV091X-based cards, and we'll be able to use them just like Windows.

ps_Now I see that Deeptho is replying to Llew about 6983/6903. I hope he won't mind me replying to him, especially since I am talking about his application. But I hope what I said above is valid and topical for him.

I have boxes full of cards, enough to open a shop, but indeed no tbs6983, which is also an older card. It is also a matter of having time and distributing it over new features, older cards, or internal reworking of the code.

Another problem is that some existing drivers are poorly designed and cannot be unloaded without crashing the linux kernel. That means that development is quite slow then. So the first step is then to fix those problems first and before you know it a week of constant rebooting the PC passes by before the problem of unloading is fixed.... Only after that it is possible to work on the driver itself. To make matters worse, drivers are not very similar to each other, even the older TBS ones are quite different from the newer ones. What it is not just a matter of applying old learnings to new drivers.

Note sure about tbs6903, but the hauppage winTv card was one such "card" (stick) from hell and the tbs6504 as well.
I tend to work on cards I have myself, and on the ones that happen to be in the PC. It is a hobby, not a job.

Currently I am working on making better use of the 8 tuners in the 6903x, but that requires some fundamental changes.