neumoDVB

[Llew]

NeumoDVB 0.9.1

@deeptho

A partial scan check of Hispasat 30W

Blindscan was proceeding in good time until stuck forever at the end H TP scanning in this example. It's not the sole TP that's stalling; there are others that do the same during my test spectrum runs - I haven't yet been able to complete a scan because of this.

What are the isi numbers that are being continually run through while it's stuck on the TP in the service results section? Is there a clue there as to why it stays halted checking the TP?

Edit > Just realised isi = input stream identifier

View attachment 143442

Logs for these problem TPs show them as no longer locked (in this case 11675V) yet they don't move on to the next TP.

 

[Llew]

This time I did wait for it to finish scanning 12589H, but it took 20 minutes before carrying on to the last TP, so 25m. is misleading if 12589H had not taken so long to complete. About 5 minutes would most probably be usual when spectrum scanning such a range.

Screengrab mistitled 0.8. (is 0.9 version).

 

[deeptho]

Logs for these problem TPs show them as no longer locked (in this case 11675V) yet they don't move on to the next TP.

View attachment 143445

It is just scanning all multistreams looking for dvb data. On some muxes there really are 255 of them and many of them do not contain dvb data, which can only be known after scanning,

 

[Llew]

Point taken. Thanks.

 

[deeptho]

Here you can see one of the multistreams: it takes about 5 seconds before there is enough evidence that there is no DVB.
The stream is a generic stream. As you can, see 253 streams have been identified, but there are 256. The longer you
stay tuned the more are discovered.

It is in fact possible to also get some stream data. I am using adapter 2 , and while running neumodvb,
the following command reads some data (interrupt it after a while or your disk will fill up):
dvbsnoop -adapter 2 -s ts -tsraw -b > /tmp/stream.ts
Then
tsanalyze /tmp/stream.ts
shows packets all with pid 280, which is how the drivers pass on encapsulated stream data.

As a quick look,
the command strings /tmp/stream.ts reveals (among some garbage):
Call-ID: 8c5ec72c-c75b45d2@192.168.202.2 CSeq: 12097 NOTIFY Content-Length: 0 P-Charging-Vector: icid-value=v7r23146p1ds2rk6ehcs2pg6GA hhoamfde9rpulo4623m0gne9;icid-generated-at=194.65.2.241;orig-ioi=internet

and CSeq: 1 INVITE Contact: <sip:100@162.55.131.8:49485> Content-Type: application/sdp Content-Length: 207 Allow: ACK, BYE, CANCEL, INFO, IGA NVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH User-Agent: Asterisk PBX 1.8.20.1 o=100 16264 18299 IN IP4 192.168.1.83 s=call c=IN GA IP4 192.168.1.83 t=0 0 m=audio 25282 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11

It looks like some voice over ip internet stream (see Asterisk (PBX) - Wikipedia) . Using commands like the above, you can find interesting stuff. I once found what looked like the firmware for an in-flight entertainment system on some transponder (I forgot which one). That firmwere was based on linux, which was evident from the data.

By the way: the software at airports showing flight data and announcements often runs windows,
as you can sometimes tell from the "blue screen of death" on the monitors. AIr France probably also runs on windows
on its in flight entertainment systems, because I once saw their flight entertainment system crash during a flight.
I might be wrong, because crashes tend to remind me of windows anyway.
The plane itself did not crash by the way.

The proper way to decode these streams is to attach a linux network device to the mux. I haven't tested that yet.

 

[Llew]

View attachment 143458

Here you can see one of the multistreams: it takes about 5 seconds before there is enough evidence that there is no DVB.
The stream is a generic stream. As you can, see 253 streams have been identified, but there are 256. The longer you
stay tuned the more are discovered.

It is in fact possible to also get some stream data. I am using adapter 2 , and while running neumodvb,
the following command reads some data (interrupt it after a while or your disk will fill up):
dvbsnoop -adapter 2 -s ts -tsraw -b > /tmp/stream.ts
Then
tsanalyze /tmp/stream.ts
shows packets all with pid 280, which is how the drivers pass on encapsulated stream data.

As a quick look,
the command strings /tmp/stream.ts reveals (among some garbage):
Call-ID: 8c5ec72c-c75b45d2@192.168.202.2 CSeq: 12097 NOTIFY Content-Length: 0 P-Charging-Vector: icid-value=v7r23146p1ds2rk6ehcs2pg6GA hhoamfde9rpulo4623m0gne9;icid-generated-at=194.65.2.241;orig-ioi=internet

and CSeq: 1 INVITE Contact: <sip:100@162.55.131.8:49485> Content-Type: application/sdp Content-Length: 207 Allow: ACK, BYE, CANCEL, INFO, IGA NVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE, PUBLISH User-Agent: Asterisk PBX 1.8.20.1 o=100 16264 18299 IN IP4 192.168.1.83 s=call c=IN GA IP4 192.168.1.83 t=0 0 m=audio 25282 RTP/AVP 0 101 a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11

It looks like some voice over ip internet stream (see Asterisk (PBX) - Wikipedia) . Using commands like the above, you can find interesting stuff. I once found what looked like the firmware for an in-flight entertainment system on some transponder (I forgot which one). That firmwere was based on linux, which was evident from the data.

By the way: the software at airports showing flight data and announcements often runs windows,
as you can sometimes tell from the "blue screen of death" on the monitors. AIr France probably also runs on windows
on its in flight entertainment systems, because I once saw their flight entertainment system crash during a flight.
I might be wrong, because crashes tend to remind me of windows anyway.
The plane itself did not crash by the way.

The proper way to decode these streams is to attach a linux network device to the mux. I haven't tested that yet.

No screenshot deeptho.

 

[satesco]

I found such multi-streams also at 30.0W with Crazyscan under Windows. When I saw this on neumoDVB I moved on to another transponder.They are, as Deeptho says, generic streams, but unlike him, for the time being it cannot be exploited on Linux. I hope I'm not right?!

 

[deeptho]

No screenshot deeptho.

 

[satesco]

The latest updates to Neumodvb allowed me to run three DVB cards simultaneously from three different signal sources,19.0E with 6902se,on 5.0W with 6903x for MIS trps,and with 6504 watching TV programs from Cable. The UHD promo program at 19.2E ran smoothly,with no interruptions,hangs or freezes,as if it didn't even need a...processor
I have tried and I am also working with the fourth card, but so far I have not succeeded, it is true that I have not insisted. I will try next time to use more cards at the same time.
The dvb players we find on Linux are old and no longer meet the demands of today's users. That's why I really appreciate Deeptho's effort to improve his application, even more so as it brings new features in terms of reception and viewing of TV/radio programs.
Now I really realize how much work and commitment Deeptho puts into making his application work perfectly, especially since he has to take into account each card individually, to eliminate bugs that appear in the process of improving neumoDVB. We must admit that it is still a virgin territory to explore under Linux
Another novelty that neumoDVB has implemented is an original, pleasant graphical interface for radio programs.
This time neumodvb finds the auto low symbol rate 543 and 667 with the 6903x card on 5.0W. Under Windows this card finds it and lock these symbol rates with great difficulty.

 

[deeptho]

Some more bugifxes where added yesterday. They relate to scanning hanging on some muxes on 19.2E.

 

[deeptho]

Updating is easy:
cd ~/neumodvb
git pull
cd build
make -j8
cd ../neumodvb
./neumodvb.py

 

[satesco]

Another test with neumoDVB for reception with multiple dvb cards working simultaneously; from 30.0E-6902se, 5.0W-5690, 54.9E-6903x,19.2E-6983, TV Cable-5604.
Some of the problems that occur when receiving and locking transponders, and then watching TV programmes, are more due to the way the tuners and demod handle the received signal.
An eloquent test of this is 12732 V,29.500,8/9 on 5.0W.
I tested the 6903x,6902se and 5690 cards on this transponder.
Although the signal is strong, the tuner of 6903x shows me a rather high BER, so only when scanning manually I could lock the signal. Because of this ber the image has artifacts, freezes and all that stuff.
The 6902 card can found and lock the signal at 12732 V when auto scanning and finds the TV programs in the package. Unfortunately when watching them, the screen remains black on this transponder. So no picture.
Strangely, of the cards tested the MIS packages on 5.0W , including 12732 V, the 5690 card performs best. Switching between tv programs at 12732 V is seamless and images run smoothly. An unpretentious card (it's a way of saying) but it offers stability in signal and when running TV programmes.

 

[deeptho]

Just a comment: be careful when comparing the values of BER between cards: they are all computed differently
and cannot be relied on. Especially for 6903x, I made some changes recently to produce more useful values.
Also these BER values are for the signal before error correction, so even with a non-zero BER the picture can be
usable.

Of course, when you see errors in the picture, then the signal is probably borderline. There can be differences
between cards, or even between driver versions. Cards with a real analog tuner will probably have an advantage over cards with a digital tuner (wich need some compromises in design)

On the multistreams, older stid135 drivers have another problem with can cause the type of problems in one of your screenshots.
This is just a bug and I noticed it mainly on some Italian muxes (and only sometimes). I think that the version you use has already fixes for this problem, but I just want to point out that similar problems can be caused by driver bugs.

 

[satesco]

Finally, a semi, or "partial" success at 10.0E with the 6903x card on the low symbol rate lock of 255 ks.This is the first time that a DVB application lock these transponders close to a few KHz at low symbol rate with this card.
With Crazyscan under Windows the signal is seen but is impossible to lock. Probably the same thing is happening now with neumoDVB, which lock the signal but can't find the program? I said it's a semi-success, because although neumoDVB sees the signal and lock it, it still can't find the Radio service (Maria).
I don't know what to think, Deeptho uses a different scanning algorithm on Linux than CrazyCat on Windows, but the results are more promising, but still awaited...
What I see now with the low symbol rate for Radio Maria is a start. Can Deeptho hope to get out of the card with stid135 what is not possible under Windows.
I apologize for expressing more of a user's opinion on these applications than a specialist's. And I can certainly be wrong, but what matters is that the application does what its creator intended. And fortunately, neumoDVB seems to promise a lot. Under Linux it is more likely to succeed than on Windows.
Congratulations, Deeptho
At the risk of filling the topic with lots of pictures, I think it's worth posting the low symbol rate transponders found and locked by neumoDVB.

 

[Llew]

That's good going satesco. I haven't done a thorough scan on 10E with neumodvb yet, or haven't checked on those transponders in particular.

I don't know if I'll manage those SNR's with my dish setup

 

[deeptho]

Finally, a semi, or "partial" success at 10.0E with the 6903x card on the low symbol rate lock of 255 ks.This is the first time that a DVB application lock these transponders close to a few KHz at low symbol rate with this card.
With Crazyscan under Windows the signal is seen but is impossible to lock. Probably the same thing is happening now with neumoDVB, which lock the signal but can't find the program? I said it's a semi-success, because although neumoDVB sees the signal and lock it, it still can't find the Radio service (Maria).
I don't know what to think, Deeptho uses a different scanning algorithm on Linux than CrazyCat on Windows, but the results are more promising, but still awaited...
What I see now with the low symbol rate for Radio Maria is a start. Can Deeptho hope to get out of the card with stid135 what is not possible under Windows.
I apologize for expressing more of a user's opinion on these applications than a specialist's. And I can certainly be wrong, but what matters is that the application does what its creator intended. And fortunately, neumoDVB seems to promise a lot. Under Linux it is more likely to succeed than on Windows.
Congratulations, Deeptho
At the risk of filling the topic with lots of pictures, I think it's worth posting the low symbol rate transponders found and locked by neumoDVB.

About "radio maria": according to what I see it is indeed locked and DVB data is being received. There is no SDT that is received.
So that means it is impossible to see a service named "maria". Perhaps it is listed under another name, like "service ..."?
You could capture some stream data as follows:

dvbsnoop -adapter 0 -s -ts -tsraw -b > /tmp/stream.ts
and then run
tsanalyze /tmp/stream.ts
these commands are from memory, and may contain errors. The zero after "-adapter" needs to be
replace by the correct value. This should be done while neumoDVB locks the signal.

Other useful commands:
dvbsnoop -adapter 0 -s ts -tssubdecode -ph 0 0x0 #inspect PAT
dvbsnoop -adapter 0 -s ts -tssubdecode -ph 0 0x10 #check for NIT presence (needs at least 30-40 seconds)
dvbsnoop -adapter 0 -s ts -tssubdecode -ph 0 0x11 #check for SDT presence

There could be something in this stream that prevents correct SDT parsing,
or SDT is absent

dvbs1 qpsk is the most difficult to receive low symbol rates. I do not know why exactly the symbol rate is limited, but what I can see on "Mars radio" on 30.0W (and with some experiments) is that a nice QPSK constellation appears for a few seconds and is then destroyed. This confirms the absence of a lock. There could be many reasons. For instance, here is another narrowband mux very nearby. The bandwidth of the digital filter may not go low enough, or even the AGC may be saturated. I have tried many parameter settings, but nothing really works.

Of course it is like using a screwdriver to hammer in a nail. It can work, but the tool was never made for this and if you
want to nail, then buy a hammer...

 

[satesco]

...

I don't know if I'll manage those SNR's with my dish setup

I think it's possible to pick up the signal with your 1.25m antenna.
I tested the 256 symbol rate transponders again with the 6903x card, this time with the 1.10m antenna. I managed to lock a few with this dish without any problems.It also locked the two horizontal transponders with symbol rates of 500 Ks and 550 Ks respectively.
I post below the spectrum obtained with 1.10m antenna and IBU lnb.The same transponders I locked with this antenna as with the 1.50m antenna. Maybe who knows, it encourages you to try it yourself

Deeptho,
I tried the dvbsnoop command to get a stream.ts file.Unfortunately it is empty

 

[satesco]

Deeptho,

Contrary to your failed experience with Mars Radio at 30.0W, this time, at 10.0E, the signal is strong and the constellation (in qpsk) is well highlighted on each transponder locked with symbol rate 256 Ks, and it doesn't go away. Which encourages anyone who receives these transponders to try it. For now I'm waiting for Llew to lock 256 Ks and then we'll see... Maybe he can do what I can't.
If you can't receive 10.0E with your dish,then I can provide you with one of my antennas with direct access to the signal to work with dvbsnoop and see what and how.
What does "PARTIAL" mean under "Scan result" in the list of muxes found by neumoDVB?
(Tomorrow I will test at 30.0W to see what I can get at 11697 V,185(Maria Radio). Last time the signal was very strong.)

 

[Llew]

I'm waiting for Llew to lock 256 Ks and then we'll see... Maybe he can do what I can't.

I'll be trying this morning satesco, Gibby busy at present using another app.

 

[satesco]

@Llew, If I may, try the signal first with the tune-s2 app and the 6903 card to locate the position and transponders, and then with the 6903x card.
Crossed fingers

Of all the DVB cards(6903x,6902se,etc) tried with the Tune-S2 app, only tbs6983 could lock low symbol rate 256 KS/s on all transponders.
And yet the neumoDVB spectrum at 10.0E does not reflect the extraordinary capabilities this card has!
I reran the test with 6983 on the 256kS/s symbol rate transponders, and although each time it locked them, the constellation is worse than with the 6903X card.
Also, with this card the sdt is missing, so we can't find the media content, i.e. the radio stream.The only difference is in the frequencies, which are 1, 2 or 3 MHz lower than normal.