neumoDVB

I have been implementing new code for parallel blindscan and it is starting to work. Here is a example
on 7.0E. The code needs more testing, so it is not yet uploaded.

7.0e_status.webp
 
deeptho said:
What would be good defaults for the local oscillator frequencies of Ka bands A,B,C,D,E?
Currently I assume that each of the Ka span 1 GHz of bandwidth, which is split in
a low and a high part of each 500 Mhz, which each have a different local oscillator frequency.
I also assume that these are the bands:
Ka A : 18.2 - 19.2 GHz
Ka B : 19.2 - 20.2 GHz
Ka C : 20.2 - 21.2 GHz
Ka D : 21.2 - 22.2 GHz
Ka E : 17.2 - 18.2 GHz
Click to expand...
No split of the frequency range in most of the LNBs we use (Invertos, SMW, XMW, Norsat etc). Just the one LO to cover the whole range. An exception would be the Inverto Saorsat or some Hughes LNBs, which use Ka B 19.7 to 20.2 GHz (higher 500 MHz). Or a more exotic LNB like my Gilat AN8024 ( four LOF's).

So for the four KA bands, you would need to have the default four local oscillators thus -

Ka A : 17.25 GHz
Ka B : 18.25 GHz
Ka C : 19.25 GHz
Ka D : 20.25 GHz
Ka E : 17.25 GHz

Any LNBs that use LO's outside of those ranges would I suppose have to carry on using the LNB Universal or C option in the LNB list.
 
Last edited:
Llew said:
No split of the frequency range in most of the LNBs we use (Invertos, SMW, XMW, Norsat etc). Just the one LO to cover the whole range. An exception would be the Inverto Saorsat or some Hughes LNBs, which use Ka B 19.7 to 20.2 GHz (higher 500 MHz). Or a more exotic LNB like my Gilat AN8024 ( four LOF's).

So for the four KA bands, you would need to have the default four local oscillators thus -

Ka A : 17.25 GHz
Ka B : 18.25 GHz
Ka C : 19.25 GHz
Ka C : 20.25 GHz

Any LNBs that use LO's outside of those ranges would I suppose have to carry on using the LNB C option in the LNB list.
Click to expand...

I guess these things are not as standardised as other LNBs.

By the way, I found a chinese Ka-band lnb here:
_https://www.aliexpress.com/i/1005002629719890.html?gatewayAdapt=glo2fra

L.O frequency:18.25GHz
Satellite:19.2ºE,42ºE

19.2E has muxes in the range 18.5-18.8 Ghz which should be band A, but the LO according to your list
would be fore band B. 42.E has muxes between 18.7 and 18.8.

With an LO of 18.25Ggz the RF output for 18.5-18.8 should be in the range 250Mhz - 750Ghz, which
does not make sense. So something seems wrong. Maybe the oscillator is 17.5 GHz?

And indeed: the picture (after magnification and rotation) says
input: 18.2-19.2Ghz
Output: 950 - 1950 Ghz
Gain: 50 dB noise. 0.7dB

Would it be useful in Europe to invest in such band A LNB, given that it is still quite expensive?
 
deeptho said:
I guess these things are not as standardised as other LNBs.

By the way, I found a chinese Ka-band lnb here:
_https://www.aliexpress.com/i/1005002629719890.html?gatewayAdapt=glo2fra

L.O frequency:18.25GHz
Satellite:19.2ºE,42ºE

19.2E has muxes in the range 18.5-18.8 Ghz which should be band A, but the LO according to your list
would be fore band B. 42.E has muxes between 18.7 and 18.8.

With an LO of 18.25Ggz the RF output for 18.5-18.8 should be in the range 250Mhz - 750Ghz, which
does not make sense. So something seems wrong. Maybe the oscillator is 17.5 GHz?

And indeed: the picture (after magnification and rotation) says
input: 18.2-19.2Ghz
Output: 950 - 1950 Ghz
Gain: 50 dB noise. 0.7dB

Would it be useful in Europe to invest in such band A LNB, given that it is still quite expensive?
Click to expand...
I think 18.25 LO is just a misprint on the page, as the LNB's label gives the correct LO of 17.25.

As with much Chinese hardware, whether the LNB comes up to standard compared to the better-known items from more established sources has to be considered before parting with your cash. A plus is that it appears to include a feedhorn, which can be an expensive purchase bought separately.
 
I have just uploaded the code for neumoDVB version 1.0.
This version has many changes.
Important:
  • You will need to use the latest blindscan drivers in order to make use of all features without problems.
  • It is possible to use neumoDVB with the standard TBS drivers, but features such as spectrum scan, blind scan, parallel scan and constellation display will not work.
  • Due to an incompatible change in the database format, you will need to re-enter your LNB and USALS information. Other data, such as services, muxes, ... is preserved.
  • You will need to read the documentation to understand how LNBs should be configured, because this has changed in the new version.
The full list of changes can be found here:
github.com

neumodvb/docs/changes.md at master · deeptho/neumodvb

neumoDVB DVB-S2/DVB-T/DVB-C settop box and DX program for Linux - deeptho/neumodvb
github.com github.com

Some highlights include:
  • New database format: data related to local setup is now stored in anew database, called devdb.mdb Also, the definition of LNBs and frontends has changed to better support new features. As a result of the move, old LNB definitions will be lost and need to be reentered. The remaining database now contain data that is independent of the local hardware setup and can therefore be shared with other users.
  • neumoDVB now makes better use of cards with and RF mux. These cards, such as TBS6909x and TBS6903x have multiple tuners (e.g., 4) and even more demodulators (e.g. 8). The RF mux allow connecting any demodulator to any tuner. This means that all demodulators can reach all connected satellite cables. Also, multiple muxes can share the same tuner and thus tune to multiple muxes in the same band and with the same polarisation simultaneously.
  • neumoDVB can longer needs concepts like "slave tuners" because all tuners can use al RF inputs. So the concept of slave tuner has been removed.
  • Parallel blind scan on supported cards, neumoDVB now uses all available demodulators to scan muxes. This makes blind scanning (almost) 8 times faster on supported cards
  • Parallel SI scanning was already possible in neumoDVB, but now it can exploit more parallelism by setting the RF mux than before.
  • Faster scanning: neumoDVB processes transponders with many (more than 200) multi-streams much faster by detecting streams which are not transport streams.
  • Improved spectrum analysis: very wide band muxes are no longer detected as dozens of very small peaks, but as a single or a small number of peaks. This speeds up blind scanning as well. The estimated symbol rate of peaks used to be very inaccurate and is not more accurate.
  • Change voltage from 0 to 18V in two steps to avoid current overloads when many diseqc switches switch simultaneously.
 
deeptho said:
I have just uploaded the code for neumoDVB version 1.0.
This version has many changes.
Important:
  • You will need to use the latest blindscan drivers in order to make use of all features without problems.
  • It is possible to use neumoDVB with the standard TBS drivers, but features such as spectrum scan, blind scan, parallel scan and constellation display will not work.
  • Due to an incompatible change in the database format, you will need to re-enter your LNB and USALS information. Other data, such as services, muxes, ... is preserved.
  • You will need to read the documentation to understand how LNBs should be configured, because this has changed in the new version.
The full list of changes can be found here:
github.com

neumodvb/docs/changes.md at master · deeptho/neumodvb

neumoDVB DVB-S2/DVB-T/DVB-C settop box and DX program for Linux - deeptho/neumodvb
github.com github.com

Some highlights include:
  • New database format: data related to local setup is now stored in anew database, called devdb.mdb Also, the definition of LNBs and frontends has changed to better support new features. As a result of the move, old LNB definitions will be lost and need to be reentered. The remaining database now contain data that is independent of the local hardware setup and can therefore be shared with other users.
  • neumoDVB now makes better use of cards with and RF mux. These cards, such as TBS6909x and TBS6903x have multiple tuners (e.g., 4) and even more demodulators (e.g. 8). The RF mux allow connecting any demodulator to any tuner. This means that all demodulators can reach all connected satellite cables. Also, multiple muxes can share the same tuner and thus tune to multiple muxes in the same band and with the same polarisation simultaneously.
  • neumoDVB can longer needs concepts like "slave tuners" because all tuners can use al RF inputs. So the concept of slave tuner has been removed.
  • Parallel blind scan on supported cards, neumoDVB now uses all available demodulators to scan muxes. This makes blind scanning (almost) 8 times faster on supported cards
  • Parallel SI scanning was already possible in neumoDVB, but now it can exploit more parallelism by setting the RF mux than before.
  • Faster scanning: neumoDVB processes transponders with many (more than 200) multi-streams much faster by detecting streams which are not transport streams.
  • Improved spectrum analysis: very wide band muxes are no longer detected as dozens of very small peaks, but as a single or a small number of peaks. This speeds up blind scanning as well. The estimated symbol rate of peaks used to be very inaccurate and is not more accurate.
  • Change voltage from 0 to 18V in two steps to avoid current overloads when many diseqc switches switch simultaneously.
Click to expand...

Hi deeptho.

In the new version I'm having a spot of trouble blindscanning a spectrum. In this case I'm using the TBS 6903X tuner 0 rf inputs 0,3. scanning 28.2E.

It blindscanned to 11675H, seemed to have missed all the remaining H polarities and finished on 12691H.

It has now stopped on the first H transponder, 10714H. Is it now attempting to use the second demodulator?

I have a feeling I've missed something during the setting up :confused

Adapters.png
LNB List_dish_1_first_entry.png
Blindscan 28.2E.png
End of H scan.png
 
Hello Llew,

your configuration looks ok.

The SNR on 10714H seems quite low. Perhaps the signal is border line and neumoDVB tries too hard to get SI data

When you say that it finished on 12691H, did a message box po up that mentioned that it was finished?
If so, then can you provide /tmp/neumo.log
 
LLew,

I just double checked using tbs6909x (so not the same card), and 28.2E scans without problem: 57 muxes locked in 3 min and 30seconds.
I also have got 867 services which seems the right order of magnitude.

two muxes were listed with TEMPFAIL. I think this can only happen on tbs6909x when it tries to scan too many high symbolrate muxes at once.
In that case, it should retry later but that is not implemented yet

I just noticed that there seems to be some error in the status message in the screenshot (DVB: 1)

Could you check your cables? Your SNR on 10714H seems much too low. I get 15dB on a 1m dish.


x.png
 
deeptho said:
Hello Llew,

your configuration looks ok.

The SNR on 10714H seems quite low. Perhaps the signal is border line and neumoDVB tries too hard to get SI data

When you say that it finished on 12691H, did a message box po up that mentioned that it was finished?
If so, then can you provide /tmp/neumo.log
Click to expand...
Edit - Posted after your last post.
No message. At least while I was at the PC or after it had completed its scan, so I don't know how long it took for the two polarity runthroughs. It didn't seem particularly fast compared to earlier scans in previous versions.

I'll check to see it there were any logs made when I next try. Bearing in mind I only did the one satellite, so it was just a tryout with the new version, not representative I suppose of what can be done with this version.

More to do when I've understood more the new documentation :)
 
deeptho said:
LLew,

I just double checked using tbs6909x (so not the same card), and 28.2E scans without problem: 57 muxes locked in 3 min and 30seconds.
I also have got 867 services which seems the right order of magnitude.

two muxes were listed with TEMPFAIL. I think this can only happen on tbs6909x when it tries to scan too many high symbolrate muxes at once.
In that case, it should retry later but that is not implemented yet

I just noticed that there seems to be some error in the status message in the screenshot (DVB: 1)

Could you check your cables? Your SNR on 10714H seems much too low. I get 15dB on a 1m dish.


View attachment 146054
Click to expand...
That was fast for a full spectrum :D

deeptho said:
Could you check your cables? Your SNR on 10714H seems much too low. I get 15dB on a 1m dish.
Click to expand...

Much work to do with my cable run. Many were laid 20-odd years ago, some underground. I'll replace eventually (I have some arthritis in my right hand).
 
Llew,

I was lucky and encountered the bug after retrying a few times. It was easy to fix.

You need to execute "git pull" and then recompile. It should work then. The low snr could be another problem as well (dish alignment
or lnb skew).
 
deeptho said:
LLew,

I just double checked using tbs6909x (so not the same card), and 28.2E scans without problem: 57 muxes locked in 3 min and 30seconds.
I also have got 867 services which seems the right order of magnitude.

two muxes were listed with TEMPFAIL. I think this can only happen on tbs6909x when it tries to scan too many high symbolrate muxes at once.
In that case, it should retry later but that is not implemented yet

I just noticed that there seems to be some error in the status message in the screenshot (DVB: 1)

Could you check your cables? Your SNR on 10714H seems much too low. I get 15dB on a 1m dish.


View attachment 146054
Click to expand...

Hi

Few questions:
The amplitudes of the 11953 look larger than other transponders. This indicates a specific type of mux? Lyngsat list it as empty while flysat says it's data.

On Llew's screenshot 11493, 11537 etc. have distortions while yours look good. Are you using any kind of inline filters, or high quality cable is enough to avoid this?

I have the same issue, it disappeared completely when card was attached directly to LNB...
 
tom55 said:
I have the same issue, it disappeared completely when card was attached directly to LNB...
Click to expand...
I'll try that myself. Meanwhile, I'll do another spectrum scan - I'm using my old Sky dish, which yesterday underperformed because the rainy conditions prevailing.

Today, 10714H TP SNR, which seems to have caused the problem, is well up -

28.2E_Sky_dish.PNG
 
I got brand new 15m piece of axing skb395. It's just shit quality cable i think. It's not any better than 4x cheaper noname coax bought 15 years ago
 
New build, same problem on 10714 polarities.

The scan sees a ghost TP at 10914V, which, AFAIK, doesn't exist on 28.2E. Consequently, blindscan sticks on 10914V when starting the vertical lower band scan. Checked with the Promax, and does show an 8dB 'TP' on Vpols. Similarly 10846 shows a horizontal 'TP'.

I will have to check the LNB on the Sky dsh. I think it might need some skew adjustment.

I'll use the Gibby dish. I didn't want to, as I have it finely tuned on a weak satellite at present.







10714V sticking on.png
10714H.png
10714V.png
 
10714 V is still weak (i'm not sure if that level is enough for your card), and looking at your yesterday's screenshot the subscribed channel was 10714 V - seems like it stuck on V not H.
Also, cant tell what you mean by ghost at 10914. I don't receive UK beam here so can't check that
 
tom55 said:
Also, cant tell what you mean by ghost at 10914.
Click to expand...
It's a V polarity presence that doesn't exist in reality. Cross-polarisation due to a wrongly adjusted LNB (or a high power signal interfering with an opposite polarity).
 
Back
Top