neumoDVB

[deeptho]

I have 2 cards, one attached to H and another to V port of LNB. While at 7e, V scan usually crashes, while H scan completes. Just moving dish to another position is enough for both cards to complete scan without problem.
For that reason i was convinced the problem is due to RF level parsing, just few days ago accidentaly noticed in spectrum window x is actually frequency related.
Is there a way to obtain samples from memory somehow, because during the window when crash happens only zeroes are written into .dat file?

Tom55,
you speak in riddles. Why not send me the log file of the crash and any messages appearing on the console?
What is "RF level parsing"?
What is "x"?

 

[tom55]

sorry, i thought at least you could easily figure out what i'm talking about.

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)

i thought it is x pointed in screenshot. "Rf level parsing" being y on the plot if i'm correct?

The log is also attached as well as two .dat files, at 02:23 scan completed, at 02:28 it crashed. window is 84mhz

 

[deeptho]

sorry, i thought at least you could easily figure out what i'm talking about.

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)

Tom55,
It seems that your spectrum - for the low band - starts with a lot of frequencies which are all equal to 10400, instead of increasing.
This could be due to the changes you made (or a driver bug). The assertion simply detects this problem, but the fix is to not
produce it

10400.000000 0 0
10400.000000 0 0
10400.000000 0 0
10400.000000 0 0
10400.000000 0 0

i thought it is x pointed in screenshot. "Rf level parsing" being y on the plot if i'm correct?

this extra "x=..." indication should not be there. I have never seen such a thing before, but it must be related to a matplotlib error and
perhaps a result of the other errors.

The log is also attached as well as two .dat files, at 02:23 scan completed, at 02:28 it crashed. window is 84mhz

 

[tom55]

It seems that your spectrum - for the low band - starts with a lot of frequencies which are all equal to 10400, instead of increasing.

Look more closely, i think they once scan completes should be sorted from lowest to highest, but as the scan breaks it is left unsorted. So these would acrually be above 12548mhz

Also, if i do scan without correcting dips between scan windows, the dip at 12548 looks quite large. Maybe it is the reason of crash?

 

[deeptho]

Like I wrote: a problem in the drivers or the modifications you made...

Update to the latest versions of drivers and neumoDVB and provide more info on your setup.
E.g., which card you are using

 

[deeptho]

Sometimes people ask for a neumoDVB version running under windows, but that will never be made.

However, it may be possible to run neumoDVB in a virtual machine. The virtual machine runs linux. It is installed on
windows. You can then use neumoDVB under window.

For this to work, the virtual machine software and the PC must support "PCI express passthrough"
and "intel VTD". Modern PC hardware typically can handle this, but you need enough memory (preferably 16Gbyte,
but 8 can work as well)

Has anyone ever tried this?

Myself, I have already tried running a KVM machine on a linux computer. The linux computer runs fedora on the hardware
and the KVM virtual machine runs another type of linux. I use this to test if the software runs on ubuntu, which I normally
don't use.

I have no PCs running windows and on windows you will probably need to use another type of virtual machine software,
but in principle it should be possible. If that works, then it would be possible to run neumoDVB on windows.

It is a bit tricky to configure: you need to enable VT-D in the bios, and then in the VM software also indicate which
card(s) should be attached to the VM machine, but once setup it works well.

 

[satesco]

Those using tbs6903x/6909x cards will need to update their deeptho drivers to benefit from DAB NRK streams at 1.0W on 10720 V,5400,3/4,8PSK and DAB DR.Deutschlans MIS 1 and Antenne DE MIS2 at 23.5E on 12641 V,1500,2/3,8PSK, but also other DAB radio streams from different satellites.
The developer of neumoDVB has optimized his driver to be compatible with applications(dvbsnoop, bedframe-tools/pts2bbf, dablin) that make it possible to run these DAB streams.
The most suitable is dvbsnoop. For this to work, you need to start neumoDVB to activate/lock the mux via Positioner.
You can also use the tune-s2 utility to lock the signal and run dvbsnoop. And voila:
Thanks @deeptho

 

[Adam792]

Great that this is working so nicely now with DVB-GSE! I need to give neumoDVB a proper try out myself, currently my PC with the TBS card is in a cupboard with no monitor though so I’ll need to think about how I do it

This way of being able to get the full raw BBFrame data from the TBS6903X/6909X may also help us with investigating the content of other continuous stream/GSE transponders without packet corruption.

 

[deeptho]

Great that this is working so nicely now with DVB-GSE! I need to give neumoDVB a proper try out myself, currently my PC with the TBS card is in a cupboard with no monitor though so I’ll need to think about how I do it

Well, that is the best place for it, assuming some good ventilation.

What I recommend is Xpra. Once this is installed and set up, you can run applications in your cupboard and watch them on another computer, even one running windows (I never tried that). You need a reasonably fast network, but with a proper setup even video (perhaps at lower frame rate) and audio will work.

 

[deeptho]

Those using tbs6903x/6909x cards will need to update their deeptho drivers to benefit from DAB NRK streams at 1.0W on 10720 V,5400,3/4,8PSK and DAB DR.Deutschlans MIS 1 and Antenne DE MIS2 at 23.5E on 12641 V,1500,2/3,8PSK, but also other DAB radio streams from different satellites.
The developer of neumoDVB has optimized his driver to be compatible with applications(dvbsnoop, bedframe-tools/pts2bbf, dablin) that make it possible to run these DAB streams.
The most suitable is dvbsnoop. For this to work, you need to start neumoDVB to activate/lock the mux via Positioner.
You can also use the tune-s2 utility to lock the signal and run dvbsnoop. And voila:
Thanks @deeptho

dvnsnoop is just an easy way to read the transport stream from the device (/dev/dvb/apapterX/frontend0) while neumoDVB is tuning some mux, and
send that transport stream to some other program. Other people use "dvbstream" which could also work. That means you can use neumoDVB
to find the muxes and inspect their SNR, constellation.... and use any other program like dablin to do something useful.

Programs which do tuning themselves will also work, but only when neumoDVB is not using the adapter, and of course they usually do not have an interface for blindscanning and they have bugs (e.g., dvblast does not handle uncommitted switches properly in all cases).

"bedframe-tools" are probably useful to get in and out of bed when you are getting old, but satesco means "bbframe-tools"

 

[satesco]

At 96.5E, 11087 H,15500,1/2 crashes every time I scan.
To make sure it's not a simple mistake, I tried several times to scan 11087 H, and each time it crashed.
If you want to test this mux yourself, I invite you to check it yourself.
I provide neumo.log to see what and how.
I should add that 11167 V is also crashing. Must it be due to signal fluctuation?

 

[deeptho]

At 96.5E, 11087 H,15500,1/2 crashes every time I scan.
To make sure it's not a simple mistake, I tried several times to scan 11087 H, and each time it crashed.
If you want to test this mux yourself, I invite you to check it yourself.
I provide neumo.log to see what and how.
I should add that 11167 V is also crashing. Must it be due to signal fluctuation?

The log files have no useful information. The message that could be useful is printed on the console.

 

[Llew]

I have that message (rc failed) occasionally in the console with the frequent crashes occuring in neumodvb on the Raspberry Pi. Also bus error or segmentation fault. For me it's probably the RPi's CPU isn't powerful enough to run the project hiccup-free..

 

[deeptho]

I have that message (rc failed) occasionally in the console with the frequent crashes occuring in neumodvb on the Raspberry Pi. Also bus error or segmentation fault. For me it's probably the RPi's CPU isn't powerful enough to run the project hiccup-free..

Can you post the full message? It is unlikely that the software would crash because of "speed issues"

 

[deeptho]

Can you post the full message? It is unlikely that the software would crash because of "speed issues"

And by the way: the only heavy load I have ever noticed is when processing EPG on the skyuk transponder that broadcasts it,
but changing the default compilation options from -g to -g -Og eliminates that problem allowing all epg data to be processed in less
than one minute. Not sure what is the effect on RPI

 

[Llew]

And by the way: the only heavy load I have ever noticed is when processing EPG on the skyuk transponder that broadcasts it,
but changing the default compilation options from -g to -g -Og eliminates that problem allowing all epg data to be processed in less
than one minute. Not sure what is the effect on RPI

Thinking about, it does seem strange that I have so many crashes because the CPU runs at a reasonable temperature (~40C) during spectrum scanning, mux channel finding and channel listing. The TBS5927 will do a blindscan over a range, then crash at the end, sometimes just the neumodvb program, sometimes the RPi itself.
Tuning a channel in the channel list always crashes before video or audio can appear.

I'll see if I can show some of the issues I have when I have it running again (I seem to have lost the adapter for the TBS6927 in /dev/dvb, probably an upgrade has changed the kernel). I still have a DVB-T/T2stick working OK. so I will have to rely on that for demonstration for now.

 

[Llew]

@deeptho

I seem to recall having this error at some stage building the project using Ubuntu 20.04 for the PC. Now with Ubuntu Mate 20.04 on the RPi (I did a successful build earlier using Ubuntus on the RPI, but new upgrades lost the TBS5927 adapter).

Could you give me any idea what the error signifies? I couldn't find any clues checking various knowledge bases.




Error in console -

 

[deeptho]

Llew, it could be because of using the wrong compiler version.

The second screenshot yields the expected result: if the code was not compiled, it cannot run.
It is all explained in the installation instructions for ubuntu. Installing a newer clang is possible, but needs
to be done from the clang website or using some ubuntu trick to install newer packages (never found out
the ubuntu trick).

The easiest is just to install the most recent ubuntu, which seems also available for RPI.

 

[Llew]

Llew, it could be because of using the wrong compiler version.

The second screenshot yields the expected result: if the code was not compiled, it cannot run.
It is all explained in the installation instructions for ubuntu. Installing a newer clang is possible, but needs
to be done from the clang website or using some ubuntu trick to install newer packages (never found out
the ubuntu trick).

The easiest is just to install the most recent ubuntu, which seems also available for RPI.

I have to use Ubuntu with kernel 5.4.0-x as later Ubuntu versions seem to use 5.15.0-x which don't recognise the TBS5927, even though the driver and firmware are loaded.

RPi doesn't give us a Grub Menu to go back to earlier installed kernels (there's UBoot, but that's not something I'm familiar with).

I'll do some more checks that you mention. Thanks.

 

[deeptho]

Ah.... Das U-Boot. That is a german submarine.
I have used it before on settop boxes and do things like booting different kernels. It required
a serial port connection.

For rpi, there is some info to use an other kernel here:

Raspberry Pi Kernel Compilation - eLinux.org

elinux.org

This would be the first solution.

There also seems to be exist procedure to be able to boot in more
pc like way. Boot a Raspberry Pi 4 using u-boot and Initramfs
It seems like a lot of work, but would be a 2nd solution.
However, tbs5927 is running fine here on linux with kernel 5.17.
You should use the latest blindscan drivers, because they have some fixes for a problem which prevents the upper Ku band being used.

So the third (and best) solution would be to fix the tbs5927 problem.


What happens when you disconnect and then reconnnect
the usb kabel to the RPI? Any kernel messages? They could shed some light on what goes on.

Also: does "lsmod" show that dvb_usb_tbs5927 is loaded?

If not, what happens when you execute "sudo modprobe dvb_usb_tbs5927"? And what messages appear in the kernel logs then?

The 4rd solution is to install a newer clang on the old ubuntu. The procedure is explained on the clang website. It was not too difficult,
but you should uninstall the old clang to avoid possible confusion.