dvbt/t2 and mux ID

Ideas for the future versions
Post Reply
Vlad
Posts: 3
Joined: Tue Apr 14, 2020 8:23 pm

dvbt/t2 and mux ID

Post by Vlad »

Hi,
is it possible to add for a scanner transport stream standard recognition - DVB-T or DVB-T2 and multiplexer`s ID as SAMdecontis software does?
For example, I can see names of multiplexes as: Norddeutschland 1 (NDR) - Germany, Mux1 ro - Denmark, NW02 POM - Poland.
Would be very convenient for users.
An of course, please add unicode support asap, receiving Kaliningrad transmitters I see abracadabra symbols instead of Cyrillic written channels names, btw Latvian language is also distorted.
User avatar
Mr. Orbita
Posts: 51
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: dvbt/t2 and mux ID

Post by Mr. Orbita »

For Multiplexer ID please check "info" button in Scanner window (marked in red):

Image

To get this work - AltDVB needs to be locked into desired mux. To check other name - firstly relock is needed.
Name is taken from NIT Actual table in the DVB stream.

For standard recognition, that might be more complicated. I'm not sure how SAMdecontis is doing this. To have 100% correct result it is needed to analyze physical layer of signal, for which AltDVB does not have access.

This information can be also readed from NIT table, but only if NIT Actual is present and having in mind that NIT doesn't necessarily have to carry correct informations. Everything depends on what broadcaster will put there. For terrestrial networks it might be more accurate, on satellite it is not always correct...
Vlad wrote: Sat Aug 08, 2020 7:41 pm An of course, please add unicode support
+1 for that ;) It's one of my current biggest wishes for AltDVB (beside DVB subtitles and moving to new database format for channels list to lift limitations of eg channel name length and ES/CA PIDs count). Unfortunately DVB-SI standard originates from 90s, charset handling got a lot in common of 90s IT approach - the whole ISO hell. Might be not easy to implement this, it might be a time consuming thing. But also I'm supporting this suggestion for future releases ;)

Thanks for your input and ideas 8-)
Vlad
Posts: 3
Joined: Tue Apr 14, 2020 8:23 pm

Re: dvbt/t2 and mux ID

Post by Vlad »

"To get this work - AltDVB needs to be locked into desired mux. To check other name - firstly relock is needed.
Name is taken from NIT Actual table in the DVB stream" - thank you, but, to my mind, not very convenient, a lot of unnecessary manipulations, especially when you take a sporadic tropo. Crazyscan2 and/or SAMcorder are much better for that :-)
Please just take it from NIT tables, for terrestrial, as you said, it`s mostly correct. More than enough.
The same about a standard recognition - why not to extract "T/T2" from TS loop entry/descriptor/terrestrial_delivery_system_desc ?
Vlad
Liepaja
User avatar
Mr. Orbita
Posts: 51
Joined: Fri Jan 03, 2020 11:05 pm
Location: Warsaw
Contact:

Re: dvbt/t2 and mux ID

Post by Mr. Orbita »

Crazyscan2 is dealing with a physical layer, so information from this source will be always correct (or at least as long as device hardware is reporting this correctly), it does not read NIT, it doesn't have to. For SAMcorder I've got no information how it is obtaining this data (but surely with one of already mentioned ways).

Using descriptor has one important drawback - it is just a descriptor, issued by broadcaster. It can contain anything, informationg there might be correct, might be incorrect or might not be available at all. For terrestrial broadcasting it might be correct in more cases than in satellite (satellite broadcasters often do not treat this too seriously), but still - it gives absolutely no 100% certainty, that parameters given there are really used.

Because of a highly customized nature of this information, probably it's not the best idea to use it without an additional verification.

Eg in Poland from 6 muxes at least for two informations provided by terrestrial_delivery_system descriptor are partially incorrect and using this will mislead. Additionally T2_delivery_system_descriptor has to be taken into account aswell.

If possible false results when descriptor content is incorrect, are not an issue, then it could be considered for addition in future, but I'm not sure if this won't miss the point of implementation.

Alternative ideas, that I've came across:
- some devices might report back some details for locked signal, but if so, rather by some dedicated interfaces, only specific device brands
- Dev_StreamRead could be used to get back technical details of locked signal from StreamReader.dll library (same that is used by CrazyScan2), but additional code would be needed and it would work only with this device interface

Eventual solution is up to @altxro ;)
Vlad
Posts: 3
Joined: Tue Apr 14, 2020 8:23 pm

Re: dvbt/t2 and mux ID

Post by Vlad »

You're absolutely right. look at the screens I got in Estonia last week. They started DVB-T2 broadcasts, frequencies - 586 and 682 MHz, but did not change previous settings. The results: Crazyscan and SAMbuddy_RF recognize the signal as DVB-T2 (as they analyze a physical layer), but SAMcorder - as DVBT.
I think that it is unacceptable for the developer of the software package (especially paid), but the developers think differently.
Vlad
Liepaja
Attachments
varska_scan_02.09.2020.png
varska_scan_02.09.2020.png (9.54 KiB) Viewed 94 times
varska_scan_02.09.2020_sambuddy_rf.png
varska_scan_02.09.2020_sambuddy_rf.png (26.03 KiB) Viewed 94 times
varska_scan_02.09.2020_crazyscan2.png
varska_scan_02.09.2020_crazyscan2.png (59.2 KiB) Viewed 94 times
Post Reply