neumoDVB

[Llew]

What is strange is that your spectrum shows that you have a mux at 11227 H(why?)

I don't know, I'll check again when I go back to it in a while.

 

[Llew]

New neumodvb build on another disk. Ubuntu 20.04.1 kernel 5.15.0-48 -generic.

Uncluttered by any other satellites/channels, just 16A @16E.

Still the same mysterious, unresolvable 'TP' at 11227H SR 16500 (at least that's what its designated in the chart). More to the point, nothing at the real 11221H.

As before, 11262H locks, then shuts down. Similarly, a channel on that TP opens, then shuts down. Screenshots made just before they disappear.

I can't find any errors to point to in neumo or sys.logs to explain my odd channel anomaly in the spectrum scan chart, or indeed the errors in the log mentioned by satesco.

 

[satesco]

I scanned 11221 H and 11261 H again. It looks like the bug is in 11261 H.
@deeptho will have to try these muxes and fix the bug.
@Llew, I am not sure, but probably 11227 H,16500 on your spectrum, is on the South East Africa spot with a stronger signal than 11221 H(?).
added:
manually scanned 11262 H, and after a short time, it crashed.

 

[Llew]

I am not sure, but probably 11227 H,16500 on your spectrum, is on the South East Africa spot with a stronger signal than 11221 H(?).

Well yes, but I think I'd have to be under the footprint to get that strong a signal

Is that spot shown on flysat satesco? I can't access flysat today, seems down for me, and Lyngsat doesn't have it. I'll try satbeams.

 

[Llew]

Well yes, but I think I'd have to be under the footprint to get that strong a signal

Is that spot shown on flysat satesco? I can't access flysat today, seems down for me, and Lyngsat doesn't have it. I'll try satbeams.

Checked Lyngsat again, the S.E. African beams are well out of my reach.

 

[satesco]

11227 H is not reported on FlySat, but looking better at your screenshot, I notice the signal at this mux and that neumoDVB scans 11221 H. It's most likely that 11227 H is a bug.
If I understand correctly, when the app searches muxes, the values displayed are estimates, not real ones. Only after scanning will we know what the actual parameters are.

 

[deeptho]

New neumodvb build on another disk. Ubuntu 20.04.1 kernel 5.15.0-48 -generic.

Uncluttered by any other satellites/channels, just 16A @16E.

Still the same mysterious, unresolvable 'TP' at 11227H SR 16500 (at least that's what its designated in the chart). More to the point, nothing at the real 11221H.

As before, 11262H locks, then shuts down. Similarly, a channel on that TP opens, then shuts down. Screenshots made just before they disappear.

I can't find any errors to point to in neumo or sys.logs to explain my odd channel anomaly in the spectrum scan chart, or indeed the errors in the log mentioned by satesco.

This is 11221H. Because your muxes have this strange fluctuations on top, it triggers a sub-peak detection.

 

[deeptho]

11227 H is not reported on FlySat, but looking better at your screenshot, I notice the signal at this mux and that neumoDVB scans 11221 H. It's most likely that 11227 H is a bug.
If I understand correctly, when the app searches muxes, the values displayed are estimates, not real ones. Only after scanning will we know what the actual parameters are.

It is not really a bug: it is always a matter of making assumptions and putting thresholds. Here the fluctuation is large enough to find a peak in the middle of another peak. It is not possible to get all cases right. If the fluctuations were even a bit more deeper, then it would find 4 muxes instead of 1.

I suspect Llew has some impendance mismtach on his cables. That could mean bad connectors, some problem in a cable or even connecting different cables to each other.

 

[Llew]

It is not really a bug: it is always a matter of making assumptions and putting thresholds. Here the fluctuation is large enough to find a peak in the middle of another peak. It is not possible to get all cases right. If the fluctuations were even a bit more deeper, then it would find 4 muxes instead of 1.

I suspect Llew has some impendance mismtach on his cables. That could mean bad connectors, some problem in a cable or even connecting different cables to each other.

That's interesting to know deeptho. Thanks. Another aspect of neumodvb to consider as I get more used to it. .

 

[deeptho]

Another aspect of ANY program to get used to. They all have their peculiar properties.

 

[Llew]

Another aspect of ANY program to get used to. They all have their peculiar properties.

It was that particular aspect that had me guessing, as it didn't show in any other programs that I use.

 

[satesco]

Deeptho,

At 23.5E Astra 3B, neumoDBN gets stuck at 12031 H,27500,500,9.10 on the auto search without moving to the next transponder. As you see in the screenshot, the app jumps directly from 11914 H to 12031 H without scanning 11953 H. What could it be?
Did you fix 11221 H at 16.0E, where neumoDVB crashes every time? Did you check what's wrong with this mux or 11261 H?
Regards

 

[tom55]

I don't know, I'll check again when I go back to it in a while.

It is the coax causing this. Can you check if anything's printed on your cable?

 

[moonbase]

Deeptho,

At 23.5E Astra 3B, neumoDBN gets stuck at 12031 H,27500,500,9.10 on the auto search without moving to the next transponder. As you see in the screenshot, the app jumps directly from 11914 H to 12031 H without scanning 11953 H. What could it be?
Did you fix 11221 H at 16.0E, where neumoDVB crashes every time? Did you check what's wrong with this mux or 11261 H?
Regards

Would you know what 12148H, SR31151 is in that scan?
Is it data as listed on Flysat, or possibly S2X/NS3/NS4?

 

[satesco]

Would you know what 12148H, SR31151 is in that scan?
Is it data as listed on Flysat, or possibly S2X/NS3/NS4?

Indeed, 12148 H is Data and will likely be in S2X after RollOff. It's not NS3/NS4(apud neumoDVB and tbs6903x card/TSReader)

 

[Llew]

It is the coax causing this. Can you check if anything's printed on your cable?

I replaced some runs a few years ago with WF100 (foam dielectric), but as you imply, it's probably the older stuff that are the guilty parties, and will need an upgrade ( probably early next year now).

 

[moonbase]

Indeed, 12148 H is Data and will likely be in S2X after RollOff. It's not NS3/NS4(apud neumoDVB and tbs6903x card/TSReader)

12604H SR34284 looks interesting, that SR is used for NS3?

 

[deeptho]

Deeptho,

At 23.5E Astra 3B, neumoDBN gets stuck at 12031 H,27500,500,9.10 on the auto search without moving to the next transponder. As you see in the screenshot, the app jumps directly from 11914 H to 12031 H without scanning 11953 H. What could it be?
Did you fix 11221 H at 16.0E, where neumoDVB crashes every time? Did you check what's wrong with this mux or 11261 H?
Regards

I would suggest trying the newest version.
Usual instructions:

cd neumodvb/build
git reset --hard
git pull
make -j4
cd ../gui
./neumodvb.py

 

[deeptho]

Indeed, 12148 H is Data and will likely be in S2X after RollOff. It's not NS3/NS4(apud neumoDVB and tbs6903x card/TSReader)

It is probably a Generalised packetised stream

 

[tom55]

I replaced some runs a few years ago with WF100 (foam dielectric), but as you imply, it's probably the older stuff that are the guilty parties, and will need an upgrade ( probably early next year now).

Well, i bought brand new piece and have this problem with it. I think there is something wrong with these cables, maybe the skin effect related as this cable is not pure copper.