neumoDVB

[Llew]

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.

Point taken. If I had been able to find and lock the wanted transponder as in the scan below and used that, it would have made more sense in the app comparison.

The spectrum looks quite noisy.

My cable distribution is quite old now. Some buried and some overbends. Needs an upgrade. When I can I'll check the many connections between dishes and PC for gain losses.

 

[deeptho]

The spectrum is quite noisy here as well. It is probably due to the content.

 

[satesco]

I went back to 15.0W to check the spectrum on the two muxes (11013 V & 11137 V) with a symbol rate of over 100000Ks/s with the tbs6903x card. This time I got a valid spectrum and a correct constellation and parameters with neumoDVB.
At 47.0 E it is a problem to get the same thing with a symbol rate of 133000 Ks/s for 11790 H and 12010 V. The only difference between the two positions (15.0W and 47.0E) is that the signal at the former is strong, while at the latter it is much weaker. I wonder if this difference in signal strength contributes to different results at the two positions with the same card.
Recently CrazyCat solved the problem in his app for max result SR in the carrier search dialog on Windows.

 

[deeptho]

About the large number of spectral peaks problem: I need to check, but apart from what I mentioned before (perhaps it is because the spectrum is so noise like), it could also be that the software hits a built-in limit: it was designed for peaks as broad as 102Mhz. This one is a bit on the large side.

 

[satesco]

Thanks,@deeptho.
I'm curious what you get at 47.7E with your antenna. If you don't succeed, I invite you to try my antenna.
I have to say that the signal on Vertical is weaker. It happens that the signal cannot be lock on this polarity between certain hours.
But I don't think this is important as soon as we succeed on one of the polarities, i.e., Horizontal.
Regards

 

[deeptho]

Definitely something interesting to try on your dish, but first I need to complete the newest neumodvb code,
which will implement parallel blindscan. That will be up to 8 times faster on tbs6909x, but causes
many headaches.

 

[tom55]

I went back to 15.0W to check the spectrum on the two muxes (11013 V & 11137 V) with a symbol rate of over 100000Ks/s with the tbs6903x card. This time I got a valid spectrum and a correct constellation and parameters with neumoDVB.
At 47.0 E it is a problem to get the same thing with a symbol rate of 133000 Ks/s for 11790 H and 12010 V. The only difference between the two positions (15.0W and 47.0E) is that the signal at the former is strong, while at the latter it is much weaker. I wonder if this difference in signal strength contributes to different results at the two positions with the same card.
Recently CrazyCat solved the problem in his app for max result SR in the carrier search dialog on Windows.

Do you still get hundreds of peaks here? If yes are they present accross all high bitrate transponders?
I tried to scan this position, and only one transponder gives such a behavior (similar at least with my cards the peaks have width 6900), but others are detected properly.

 

[satesco]

I don't know what position you scanned, and I'm slightly annoyed by the spectrum you post. If you scanned at 7.0E with neumoDVB, as it appears in Tuner mux and range, then you should know that there are no muxes between 11700-12500 MHz at this position. The spikes on the spectrum probably come from nearby satellites, either at 9.0E or 4.9E, which have transponders in this part of the band.
In one respect, you are right; indeed, neumoDVB finds many such signal peaks, some of which have active transponders. These peaks are detected by an algorithm known only to Deeptho, but not all of which are indications that they are muxes. Some of them probably result from signals of all kinds in the area where the antenna is, perhaps interference and not only from the satellite(?).
I might be wrong about these many spikes, so better let Deeptho tell us.

 

[tom55]

I was referring to the specific issue you described. So the spectrum is from 48 east, it's just at the time i loaded it from the database to take screenshots, there was another scan running at 7e

 

[satesco]

Excuse me, and I didn't think it was 47.7E. I took the picture as an illustration of what you wanted to know. As they say, a divorce between word and image, like so many others on the forums.
Anyway, I'm waiting for Deeptho to clarify when he'll finish what he's working on now. We have to wait.
Regards

 

[tom55]

I'd say 11790Mhz H transponder is quite strong, and it's reflections appear on V polarization scan. You have big dish and probably all transponders are very strong so you got a bunch of small peaks accross all of the scanned tp.
Maybe a better spectrum algo can work it around since you say it is good on windows

 

[satesco]

I said above, #503, what problem I have with the neumoDVB spectrum on these transponders. It's true that the signal at 11790 H is a bit stronger than at 12010 V, but that didn't help me to get a spectrum of the same quality as at 15.0W on 11013 H.
Now my antenna is in another position. When I have time, I'll try again the signal and spectrum on the two high symbol rate transponders.

 

[deeptho]

I said above, #503, what problem I have with the neumoDVB spectrum on these transponders. It's true that the signal at 11790 H is a bit stronger than at 12010 V, but that didn't help me to get a spectrum of the same quality as at 15.0W on 11013 H.
Now my antenna is in another position. When I have time, I'll try again the signal and spectrum on the two high symbol rate transponders.

Currently there could be two problems:
1. muxes wider than 100Mhz are not supported (easy to fix)
2. some spectra (data?) have a much higher variability than other muxes and smaller peaks in the spectrum rise above the "noise" threshold,
causing them to be detected as narrrow band muxes., Here there is a balance between detecting weak smallband muxes, which might be
missed with other thresholds.

I intend to look into this at a later time.

 

[tom55]

@deeptho
Have you faced this issue before?

neumodvb: /home/tom/neumodvb/src/receiver/spectrum_pybind.cc:145: py::object find_annot_locations(py::array_t<float>, py::array_t<int>, int, float, float): Assertion `x < n' failed.
Aborted (core dumped)

In spectrum.dat have samples with frequencies/levels up to the certain point, and then (probably after crash point) all the samples have LO frequency 10400 with level 0

 

[deeptho]

@deeptho
Have you faced this issue before?

neumodvb: /home/tom/neumodvb/src/receiver/spectrum_pybind.cc:145: py::object find_annot_locations(py::array_t<float>, py::array_t<int>, int, float, float): Assertion `x < n' failed.
Aborted (core dumped)

In spectrum.dat have samples with frequencies/levels up to the certain point, and then (probably after crash point) all the samples have LO frequency 10400 with level 0

No, but it sounds to me that the "crash" (actually an assertion testing for unexpected inputs resulting from bugs) is mosty the symptom
of an underlying problem, perhaps with the drivers, or with an unsupported card or an unusual lnb configuration or ....

Did you test the latest version of neumodvb? Can you reproduce the problem by simply opening the spectrum instead of rescanning
(=press control-enter on the bottom-right list on the spectrum screen).

 

[tom55]

Haven't tried latest version. I'm modifying spectrum code in driver, it should be faster and hopefully with less sloping. At one point i had the crash always at the same frequency, if loaded from db instead of rescanning it crashed the same way.
Spikes between two scan windows can cause this? I tried to use all 512 samples but perhaps 510 are usefull only with 1 sample discarded at each end..

 

[deeptho]

Well: if you modified the driver code, then the problem might be in those modifications?

 

[Llew]

Checking TBS 6903.

 

[Llew]

A test of the viability of receiving the Turksat 4A 42E KA circular polarised transponders using my modded Inverto Saorsat LNBF. Currently, there's only three that I can receive, and of those, I can only lock one.

The LOF of the LNB is 1 MHz adrift, so needs retuning. Otherwise it's remarkably stable considering the DRO puck is not even glued on properly (sticky tape).

As the LNBF outputs a reversed spectrum similar to a C-Band LNB, it was necessary to choose the C-Band LNB option as a 'fake KA' in neumodvb. This gives the correct frequency order in the spectrum chart.

Note - I'm not sure why, but the L polarities are shown as vertical (R). I can't remember if the polarity depends on which of the twin outputs you use.

 

[deeptho]

A test of the viability of receiving the Turksat 4A 42E KA circular polarised transponders using my modded Inverto Saorsat LNBF. Currently, there's only three that I can receive, and of those, I can only lock one.

The LOF of the LNB is 1 MHz adrift, so needs retuning. Otherwise it's remarkably stable considering the DRO puck is not even glued on properly (sticky tape).

As the LNBF outputs a reversed spectrum similar to a C-Band LNB, it was necessary to choose the C-Band LNB option as a 'fake KA' in neumodvb. This gives the correct frequency order in the spectrum chart.

Note - I'm not sure why, but the L polarities are shown as vertical (R). I can't remember if the polarity depends on which of the twin outputs you use.

View attachment 145396
View attachment 145397

View attachment 145398

Note that there is an option in the lnb settings to change L and R. I needed this myself because the depolarising plate (C-Band) went in one way better than the other causing L and R to swap.

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