neumoDVB

[satesco]

Deeptho,

I take your proposal(ad-hoc) to change antennas cum grano salis because tests done with a 1.10m antenna, smaller than the one used in previous tests, 1. 50m, gave me the same result. Moreover, with a Tratec (Holland) 20dB variable attenuator, the signal not only decreased but, on the contrary, increased with both antennas, discovering another mux in the lower band, 11140 H, 30000, 3/4, which in the upper band is at 12689 H, being in the vicinity of 12725 H, which I mentioned on the topic.
If I go by the explanation given with the lnb's, then I have to blame this lnb for the similar result to 12725 H.So two lnbs with two different antennas and two stid cards provide the same effect in both operating systems.
I'm sorry, but the fact that I have to reduce the signal with an attenuator or wet close is not conclusive. Rather it indicates a symptom. I didn't use the wet close, but the attenuator only boosted my signal rather than reduced it, even on a 1.10 m dish. (See pictures). And even if it confirms your assumption, I don't see what it proves. As they say, a nail can be removed with another nail, but the hole remains.
Your answer leaves me with the impression that beyond the arithmetic calculations made (and these are useful), there is no solution to the problem I raised. We must go into the face's inner "chip" to find a solution. As long as we don't see a solution to a particular situation, I find it hard to accept that it is just "my problem." Yes, you're right; it's just my problem; the message delivered belongs to the sender, not the receiver.
Here's how the attenuator signal test looks with the 6903x/6909x cards with 1.50m and 1.10m antennas:

 

[deeptho]

Deeptho,

I take your proposal(ad-hoc) to change antennas cum grano salis because tests done with a 1.10m antenna, smaller than the one used in previous tests, 1. 50m, gave me the same result. Moreover, with a Tratec (Holland) 20dB variable attenuator, the signal not only decreased but, on the contrary, increased with both antennas, discovering another mux in the lower band, 11140 H, 30000, 3/4, which in the upper band is at 12689 H, being in the vicinity of 12725 H, which I mentioned on the topic.

Which is also a difference of 1550 Mhz.

If I go by the explanation given with the lnb's, then I have to blame this lnb for the similar result to 12725 H.So two lnbs with two different antennas and two stid cards provide the same effect in both operating systems.

Then it is not the lnb .

I'm sorry, but the fact that I have to reduce the signal with an attenuator or wet close is not conclusive. Rather it indicates a symptom. I didn't use the wet close, but the attenuator only boosted my signal rather than reduced it, even on a 1.10 m dish. (See pictures). And even if it confirms your assumption, I don't see what it proves. As they say, a nail can be removed with another nail, but the hole remains.

There is some gain control going on, so the lnb (or the card) compensates for the reduced signal. At the same time noise is also
suppressed and apparantly the next effect is increased snr (because the high frequencies are more attenuated)

Your answer leaves me with the impression that beyond the arithmetic calculations made (and these are useful), there is no solution to the problem I raised. We must go into the face's inner "chip" to find a solution. As long as we don't see a solution to a particular situation, I find it hard to accept that it is just "my problem." Yes, you're right; it's just my problem; the message delivered belongs to the sender, not the receiver.
Here's how the attenuator signal test looks with the 6903x/6909x cards with 1.50m and 1.10m antennas:

If it is not signal level related, then it is also possible there is something wrong with your card.
I tested my self on 6909x and did not see any such problems. Of course it could also be that 6903x is designed differently.
Still, if this is not a problem of an excessively strong signal, then it should not be like this

It could be as simple as some capacitor or inductor somehere failing, not soldered well or ...
Or perhaps some driver bug (but then I would have seen it in my own tests).

A simple solution would be to insert a splitter "teresstrial/sat". Normally the terrestrial signal would be surpressed in the
satellite output.

Why not ask TBS's opinion?

 

[satesco]

As I said on the topic the first time, I noticed that some frequencies in the lower band appeared in the upper band in the last four years after CrazyCat provided support for 6903x/6909x cards. This problem was not so severe and widespread, only at 90.0E, and again, on another satellite, I can't remember which one. Fortunately, after repeated updates of Crazyscan, I no longer noticed such problems.
Only now, with the tests on the latest version of neumoDVB, I saw the appearance of the two muxes at 5.0W. Of course, I immediately checked the 6903x card, then with 6909x, with Crazyscan on Windows. That's why I also said it was a bug in neumoDVB. That's why I thought it would be good to signal as feedback this on your thread, to get to know what problems I have using your application. By reporting this issue, I thought you or CrazyCat would analyze the situation and eventually find a fix.
My version of 6903x hardware is v12, and for 6909x, it is v11. It works well compared to the first tests four years ago after I installed the last driver, 1.0.0.3. I was pleasantly surprised that it also locks a low symbol rate like neumoDVB, which was impossible with the first tbs driver 1.0.0.1. I don't know what to think because I haven't found any problems with the 6903s card.
Indeed CrazyCat is doing a great job(on silent) for tbs cards without telling us. That's why I think the improvements made to these X cards are the fruit of this ongoing concern to solve the problems these cards raise. And what helps it a lot is that the user doesn't get so much involved in using his Windows application because, isn't it, everything comes to him in a nutshell. You do the same; only your involvement comes from your application's desire for perfection (I hope I'm not wrong) so that users are attracted to your advent of improving your neumoDVB. For many of us, Window-ists is a bit of a complicated job.
I came to you because neumoDVB is your application, which, together with the driver, you know in detail and can tell in full knowledge what causes the bug when you get feedback from the user.
But if you say it's better to report the problem to the manufacturer, I'll do it if I notice other errors/bugs.
Regards.

 

[deeptho]

Satesco,

it is not clear if the new problem you reported (12725 H) also occurs on windows or not.

First you said it did: "I did the signal test at 5.0W with Crazyscan under Windows with the 6909x,6983,usb5927 cards. Same result as on Linux."

Then you said "Of course, I immediately checked the 6903x card, then with 6909x, with Crazyscan on Windows. That's why I also said it was a bug in neumoDVB." Which suggests to me that the problem does NOT occur on windows

So which is it?

And about the card versions: I onliy know of versions v1 and v2. Is this what you mean by v11 and v12?

It woukld be good if you could also test you 6909x card on linux. Just to see if the problem occurs there as well or not.

 

[satesco]

The two frequencies,12689 H,30000,3/4 and 12725 H,30000,3/4, at 5.0W, which appear on the spectrum in the upper band, only occur on tbs6903x/6909x cards, both on Linux ( neumoDVB ) and on Windows (Crazyscan). So it does not depend on the application and/or operating system.
Maybe I wasn't clear, and I apologize for that, but on other cards,tbs6983,tbs5927, etc the two lower band muxes don't appear. So only cards with X find the two muxes.
You are right, it is good to know what hardware versions we have for the 6903x/6909x cards, although from a functional point of view, there is no difference between fan cards (V.1) and heatsink cards (V.2).
TBS has simplified the name of the two versions of (hdw) cards after dropping the fan and switching to the heatsink for 6903x, now V2(heatsink), and for 6909X V2(heatsink).
I have the 6903x card version hdw 12 with fan, V.1, and the tbs6909x hdw 11 card, V.1, before switching to the heatsink.
In the meantime, I welded an extra 22uf capacitor to both cards.

 

[moonbase]

... In the meantime, I welded an extra 22uf capacitor to both cards.

@satesco

Can you please tell me what benefit the extra 22uf capacitor provides to the tbs6903x and where it is soldered on the board?
I have a fanless tbs6903x that I have not yet installed and if there is benefit with the extra 22uf capacitor it might be worth trying?

 

[satesco]

@satesco

Can you please tell me what benefit the extra 22uf capacitor provides to the tbs6903x and where it is soldered on the board?
I have a fanless tbs6903x that I have not yet installed and if there is benefit with the extra 22uf capacitor it might be worth trying?

There is no need to make any modifications to your card, I assume, V2 (fanless). That capacitor was more for those who run IPTV streams at high speed, for stability. The V2 versions offer all this, nothing extra.

 

[deeptho]

There is no need to make any modifications to your card, I assume, V2 (fanless). That capacitor was more for those who run IPTV streams at high speed, for stability. The V2 versions offer all this, nothing extra.

There are more differences between the two versions of the card then just the heatsink. I know, because I helped test several versaions of the v2 card after reporting a problem with v1. In the end also helped verify that the (small) problems with the v1 card were really solved in v2. For this I compared all stream errors between two different cards in two different dishes for a whole day. The few stream errors that remained occurred at the same time on the two dishes with the different cards (the other was 5927).

Soldering things never really helped. The problems with the v1 cards was that on a few muxes stream errors occured, enough to get noticed. In fact, this was mainly restricted to one multistream on 5.0W, which no longer exists, but the details of the problem varied from card to card (I have several, including some that are now damaged from the soldering process).

I doubt the heatsink was the main solution for this problem. There are other small changes as well and there is an (in my opinion unneeded)
additional low noise variable gain amplifier in it.

I am still using the V1 card myself. It works well overall. Of course if you order a new one, best buy v2.

 

[CrazyCat]

all issues witb ACM/VCM transponders solved with one capacitor VGLNA on V2 cards work in passthrougth mode (default mode, can work without soft init)

 

[deeptho]

all issues witb ACM/VCM transponders solved with one capacitor VGLNA on V2 cards work in passthrougth mode (default mode, can work without soft init)

Yes and these things are very small....

 

[satesco]

With neumodVB version 1.2, I tested the diseqc 1.1 switches (uncommitted) on the toroid with 15 lnb. I understand that the count on this switch is from 0-15. I managed to set each position according to diseqc 11 instructions. Still, at the first position,0,42.0E, Turksat, I have a problem; namely, the spectrum shows muxes that do not belong to this Sat, plus the polarities overlap (see picture). What's wrong with port 0?
For the second issue, I tried to set the local oscillator to position two on 10750 for a circular lnb for receiving Russian muxes at 36.0E. I succeeded only halfway because I was wrong somewhere and unsure where exactly. I set the LNB in neumoDVB, when the Ku Right/Left lnb, when the UPC Right/Left, lof 10750, but I did not get a spectrum with all muxes (11700-12500 LR). What am I missing in the setting?
The 1.1 switch I use works fine; each position has no setting problems. I checked the Crazyscan switch at 36.0E on the toroid. Diseqc 1.1 ports to Crazyscan start at 1-16. All ports are ok, including port 1(0 in your app).

 

[EnoSat]

12174 tuned as 12022 ( ie 150 MHz difference + 2MHz offset drift LNB ) , are you sure that LOF is 10750 and not 10600?

 

[satesco]

lof 10750 Ku circular LNB for 36E

 

[deeptho]

Difficult to comment: there are no log files, no kernel messages and the card is one I do not have....
Config setting for the switch seems ok.

 

[satesco]

If it was still needed, I tested with Crazyscan setting LOF10750 circular lnb at 36.0E.
I scanned all dvb applications (utilities, dvb players) with this configuration.

 

[deeptho]

The LOF bug is fixed.

 

[satesco]

Where did you find the bug, at lof for circular or port 0 for lnb 0?
Here is neumo log before repair.

 

[satesco]

I updated neumoDVB after setting LOF for Ku circular at 36.0E: "HEAD is now at c49e812 Bug: custom lnb settings low_low/high freq_low/mid/high ignored".
I left the LOF of 10750 Mhz, same as yesterday, and I want to hope that this lof is not wrong because, as I showed yesterday, this setting with Crazyscan is correct. The spectrum comes ready to set for the LNB between 11700-12200 MHz. Between these limits, the scanning usually goes with each mux, but after the 12200 MHz does not work even if I manually choose the boundaries between 11700-12500 MHz. I failed to select other settings to scan the whole circular band (11700-12500 LR). The spectrum remains dead between the limits I set. It seems the setting is the default. That is, it displays nothing.
I noticed on this occasion that after the update, in the Connections settings, at each position, instead of FIXED DISH, as before, now appears MASTER MANUAL, which does not affect the regular operation of the Diseqx 1.1 switch. So everything is ok from this point of view. But it didn't help to eliminate errors either.
And one of them is port 0 on Diseqc 1.1, for the first position,42.0E Turksat. The value 0 for the first port seems not to work at all. For what reason, I can't figure it out because otherwise, all ports for each position with the new option, MASTER MANUAL, usually work.
As I said, apart from 36.0E, at all Diseqc 1.1 positions, I use universal LNBs. So there are no problems with the settings for each port, only at position 2, at 36.0E, where I use circular lnb; I chose the KU option to select the right LOF of 10750. And I hope this option is correct.
You will have to see why,1. port 0 does not work, and 2. why does neumoDVB not scan after 12200 MHz? Any advice is welcome.
Below, I also attach the neomoDVB log.

 

[EnoSat]

maybe it is related to the incorrect definition of the range in the algorithm for non-universal LNB (if it happens to calculate 12200-9750=2450, I don't know what the maximum value of the input frequency is set in the program)

 

[deeptho]

The problem is that the information needed to shed some light on the problem is missing:
-what is your lnb defintion (the screenshot exactly misses the needed part)
-what do the kernel logs show about your "port 0" problem?
-what is the correct (the one you want) range for the lnb?
-what range did you actually set? did you set one?
-is port 0 the problem or port 2? Or both?

The frequency ranges you mention are indeed the correct ones for a Ku Lnb. So unless you changed them, neumoDVB does what it is told
and refuses to scan frequencies that the lnb does not support -according to how you configured it
Check the documentation once more:

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

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

github.com

The error on the console should not occur, but may be the result of trying illegal input values.