neumoDVB

[Llew]

According to the pictures, it looks like a badly set SKEW or insufficient separation of polarizations in the LNB

Yes, that's what it will be I'm sure. I'm going out now to adjust it. The dish is very much ground mounted, and will proably have had its LNB knocked by a cat (or an urban fox perhaps).

 

[tom55]

I get it now. 10714 V dont exist in lyngsat (10914 was a typo), probably a reason for scan halt.
If skew adjusting doesn't help, maybe a scalar ring would? They claim it helps with cross polarization issues.

 

[Llew]

It still stays parked on 10714H, even though I've adjusted the LNB skew to the best I can. The scan isn't showing a locked 10714V as it did before, so I would have thought it would pass 10714H after finding its parameters.

Maybe my BU LNB is failing to separate the polarities ahead of its switching circuit, which wouldn't help.

I'll have to use my Gibby dish as I intended.

 

[Llew]

If skew adjusting doesn't help, maybe a scalar ring would?

Unlikely for my Black Ultra KU LNB. I could use a Teflon depolariser in the feedhorn, but it would mean removing the sealed cap.

Better to replace the LNB, but I don't have another one with four outputs.

 

[tom55]

I had that cap completely broken due to heat on my old STi that was lay down in the attic for years.
I used it for a while before got BU in all possible weather conditions, fog, rain, snow and in 99% cases had no issues at all. In fact it performed even better in rain as the raindrops had nothing to stack on to.
One time after the storm there was a little rain inside it and no reception, i just dried the water out and everything was good. I guess if the electronics inside are sealed with glue/silicone a water won't do any damage to antenna probes.
A scalar ring could also serve as a protection from raindrops. I'll check that soon.

I tried to scan 28.2 to see what's the situation. Indeed there are cross polarization issues even on eu beam (inverto wideband LNB currently in use)

 

[Llew]

Using my Gibertini 1.2 dish. No problem with 10714H now.

Blindscan almost completed, it stays put on the 12570H feed. Frustrating.

I'm not particularly keen on staying with 28.2E. I'll be checking some more interesting satellites.

 

[deeptho]

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.

This is a DVBS qpsk mux, but without services and with some streams with service information

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...

I have noticed that as well in Llew's graphs. I have several switches and no problems. It could be a sign of bad cables or poor switches.

 

[deeptho]

New build, same problem on 10714 polarities.

Then you should send me a log file.

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'.

This seems like a problem with incorrect skew?

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

Indeed

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

 

[tom55]

I have noticed that as well in Llew's graphs. I have several switches and no problems. It could be a sign of bad cables or poor switches.

I have distortion without any switches. Normally, only small amount of range looks good, e.g 11200-11600mhz

When i add this

https://ae01.alicdn.com/kf/H26822c5e9d2a4370a1bffde905b3620f4.jpg

distortitons are reduced, maybe DC is causing this?

I did test this few months ago, and even with a 50cm cable was able to reproduce it.

Only without any cable spectrum graph looks perfect (almost) as on screenshot in previous page

 

[Llew]

Blindscan completes full 28.2E spectrum ~13m. TBS6903X.

 

[Llew]

Blindscan completes full 28.2E spectrum ~13m. TBS6903X.

View attachment 146093

I'm assuming this is now with both demodulaters in parallel, as you can only choose C0#0 or C0#3 in the LNB list?

 

[deeptho]

I'm assuming this is now with both demodulaters in parallel, as you can only choose C0#0 or C0#3 in the LNB list?

View attachment 146095

Llew,

yes indeed. It is using both demods. There are 8 inside, but I think the chip is wired in such a way that only two can be used.
Otherwise blindscan would be 4x faster.

 

[Llew]

Quick test of Ka Band option in this version. We now have the respective Ka Bands available in the LNB Type column drop-down list, in this case for the test, KaD.



Test on 7E, (the New World mux at 21627 has disappeared at present). Not a lot locking for me, just the three.





A small ask @deeptho - can you allow us to choose the spectrum range for the Ka Bands? At present we have to have the full range.



oops - forget that. Just noticed I had entered out-of-range frequencies.

 

[Llew]

Quick test of Ka Band option in this version. We now have the respective Ka Bands available in the LNB Type column drop-down list, in this case for the test, KaD.

View attachment 146129

Test on 7E, (the New World mux at 21627 has disappeared at present). Not a lot locking for me, just the three.

View attachment 146130

View attachment 146131

A small ask @deeptho - can you allow us to choose the spectrum range for the Ka Bands? At present we have to have the full range.

View attachment 146133

oops - forget that. Just noticed I had entered out-of-range frequencies.

 

[deeptho]

Then you should send me a log file.


This seems like a problem with incorrect skew?


Indeed

Llew the fix I made earlier for the "hanging scan" problem was incorrect, but today I fixed it and uploaded to github

 

[Llew]

Llew the fix I made earlier for the "hanging scan" problem was incorrect, but today I fixed it and uploaded to github

That seems to have cleared the hanging problem deeptho, at least with a repeat scan of 28.2E. No stopping on the usual suspects. Takes a minute less for a full H & V blindscan (12m) with the TBS6903X.

 

[satesco]

I don't know if it only happens to me, but with the 6903 cards, every time it scans 11221 H,30000,3/5,8PSK(or 11261 H,30000,2/3,8PSK) at 16.0E, neumoDVB crashes.
@Lwel, can you check if you also have problems with this mux at 16.0E? Thanks

 

[EnoSat]

maybe data is sent at an inappropriate time interval, it was described in detail on the OpenPLi forum where e2 boxes cannot correctly display station names (but it concerned Croatian transponders)

 

[Llew]

I don't know if it only happens to me, but with the 6903 cards, every time it scans 11221 H,30000,3/5,8PSK(or 11261 H,30000,2/3,8PSK) at 16.0E, neumoDVB crashes.
@Lwel, can you check if you also have problems with this mux at 16.0E? Thanks

satesco, 11221H doesn't show for me. Seems to have disappeared. Next that, 11227H has no SNR.

Trying 11262H shuts neumodvb down (I just managed to take a screenshot before that happened.)

 

[satesco]

Thanks, @Llew, for trying. It may well be that the crash happened at the time of the switch from 11221 H to 11261 H because before the crash, I noticed that 11261 H turned green, indicating that the mux had been scanned but without being able to take a screenshot.
What is strange is that your spectrum shows that you have a mux at 11227 H(why?) and not at 11221 H. Probably that's why the app didn't crash until 11262 H(?).
In the neumoDVB log I posted above, I highlighted the error 34938 that occurs when the crash occurs. That error occurs every time.