Qirx 4.0.8: Only in case of "Radio fuer NRW" = WDR multiplex the location of the station disappears after 1 sec.

[schluckspecht]

Qirx 4.0.8: Only in case of "Radio fuer NRW" = WDR multiplex the location of the station disappears after 1 sec in the map view. And this happens only one time, until you start Qirx completely new. One time one second displayed the WDR station (Baumberge) will never be displayed again until you restart Qirx completely new. All other stations of the multiplex of "DR Deutschland", "Antenne DE", "Mein NRW DAB+" and "NDR NDS OS" are displayed normally. Updating the DAB database did not help. Before the update even the NDR was not displayed anyway, but after all stations were visible. Moving or zooming the map does not solve the problem. See video.

https://user-images.githubusercontent.com/84860874/234984781-2a9e7d65-fc2e-45a4-a0c6-0013dbb159cc.mp4

[softsyst]

Would a raw file be possible?

[schluckspecht]

This is a zipfile splitted in 4 parts, because only 10 M per file are supported. Because it must end with .zip, otherwise githup rejects the file, I added an unneccessary .zip after the splitted zip files. Please remove this additional .zip suffix. I splitted it with 7 zip.

What I did: Qirx was tuned to NDR, then I switched to WDR. This is the only possibility to be fast enough to record this event. If you start directly with the WDR you are to slow to click record, before the station disappears . A few seconds after the station location disappeared, that was really at the correct location in the map for about 1 sec, I stopped the recording.

2023_04_27_22_57_36_2048000_fHz209936000.zip.001.zip 2023_04_27_22_57_36_2048000_fHz209936000.zip.002.zip 2023_04_27_22_57_36_2048000_fHz209936000.zip.003.zip 2023_04_27_22_57_36_2048000_fHz209936000.zip.004.zip

[softsyst]

Thanks for the files. I'll try to reproduce the error.

[softsyst]

The 10s recording is too short. To investigate this, I need a recording where the muxes have solidly settled which is not the case here. Preferred in this case would be at least 30s for each mux, better 1minute each. Otherwise a proper investigation will be not possible. Using zip's with 10MB each is of course possible, but inappropriate for DAB raw files. There are a number of sites offering upload services for such large files, e.g. Google dropbox, ionos hidrive (2GB).

[andimik]

@schluckspecht

Can you also receive Dortmund/Florianturm? Then you have a TII collission.

https://www.ukwtv.de/cms/deutschland-dab/nordrhein-westfalen-dab.html

[schluckspecht]

Why a collision? 0701 vs 0301. Here all stations in the region of the WDR. And when I look to the CIR, there is nearly nothing from Dortmund. That fits to the experience, as long as Münster did not use 9B (Antenne DE), Antenne DE could only be received by Bielefeld 5D with a weak signal, but nothing from Dortmund 9B. Since December Münster uses 9B too for Antenne DE. And because of the fact that my solar panels are in the south of the vertically polarized VHF dipol antenna that is located under the roof, Dortmund is weak anyway. The solar panels act as a reflector anyway so that I have gotten a very good reception of the NDR (Dörenberg in Bad Iburg-Grafensundern) by choosing a good distance between the antenna and the panels. This situation is the same since 3 years, that means, even when I tested 3.2.2 and where this problem with the map did not happen.

11D Schöppingen 1 v 0703 * 16.06.2021 11D Dortmund/Florianturm 10 v 0301 11D Münster/Baumberge 10 v 0701

[schluckspecht]

Hi, I send an email to the developer. 1 min of raw recording.

[softsyst]

The download worked at last. Apple seems a little slow. I'will check it. Thanks!

[softsyst]

As @andimik had correctly pointed out, it is a TII collision. Please remember: Same Sub id, different Main id leads to a TII collision which the software is not able to resolve. Here, the colliding Sub Id is the 1.

What is new in the 4.0.8 is that such a collision is indicated by the pseudo Main Id 99 and the colliding Sub Id, as is here the case. This Sub Id can be selected in "Show Collisons for Sub Id" and all possible (NOT necessarily real) transmitters are indicated.

What happens erroneously is that on the map all icons vanish after a 99 has discovered. This is a software bug and will be fixed in an interim version. The file provided by @schluckspecht then looks like so:

What can be noted in addition is that the 7/1 is shown although it should be hidden in the collision set. It is due to the fact that the TII software steps down from a rather high threshold down to the threshold selected by the user or automatically. On the higher threshold, there are usually much less collisions than on the lower threshold, adding that collision-free detection to the indicated TII values.

The basics for TII recognition and in particularly the cases where collisions happen is presented in the tutorial about the issue.

[superblyb]

Sometimes this also happens at my location with 12A VRT from Belgium. The symptoms look alike (flashing flags, "99" pseudo values), but it isn't always occuring.

[schluckspecht]

Is it possible in case of a collision to withdraw the weaker signal for the TII decoding automatically? Or to enable the "High-Res" Button automatically as a default in case of a collision? Because If I enable the "High-Res" Button the TII is decoded correctly and the map is working correctly . Obviously as a result the very weak, but a collision causing signal, is not used any more. And so the map works.

[softsyst]

No, this will not work. If it would, it would be purely accidental, as in that case a clear distinction could be made from the amplitude of the carriers.

In the collision case you have instead of four carriers five (or even more) carriers available for the selection. A Main Id is an unambiguous combination of four carriers. If you got five, you get five possibilities for the main id, so which one should you chose? If you have six carriers, you already have 15 possibilities for the main id.

If you know that carriers of a colliding mux are much weaker than the others, you could adjust the threshold manually and get an unambiguous indication. However, this would never work in the general case, as you very often have a mix of strong and weak TII carriers for a multiplex.

Thus, any automatism would need other information than the ones in the null symbol (the TII carriers). These could come from the CIR, or from the database (distance, transmitter power, transmitter antenna direction) and from the multipath situation, etc. To derive a robust and working algorithm from it would be a very difficult task. As a result, my only advice can be to draw these conclusions "manually" from the available information, as I describe it in the tutorial example (part II).

[DigiBC]

I can confirm the observations of schluckspecht with regard to version 4.0.8, referring to the same mux, but from the virtually other end of the broadcast area of WDR (11D). Recently I’ve got similar problems and I don’t believe that this has anything to do with the collisions discussed here.

My reception site is only 3.2 km away from the local 10kW transmitter, but QIRX indicates up to 3 or 4 collisions (pseudo Main ID 99), which makes no sense at all:

I had initially suspected that signal reflections from the strong transmitter in the vicinity, which can significantly interfere with parts of the signal, were causing these alleged collisions. However, the other muxes from the same transmitter site (5C / 9B / 9D) never show any collisions. (schluckspecht had noted this as well.)

So, there must be another reason....

For analysis here is a 1:30 minute recording of the mux from an AIRSPY Mini (as zipped RAW file): https://1drv.ms/u/s!AjUX78udOFCXgv1nKbBTuQThHpdSOA?e=MQmtFt

[softsyst]

Hi DigiBC,

thanks for your raw.

Sorry, but I have to disappoint you. What you see in your reception are TII collisions. Nothing else. The reason is very simple. Due to the very low threshold there are also very weak carriers caught. You can easily verify it when you manually increase the threshold. The collisions will disappear.

If you are in doubt, you need to inspect the TII spectrum. As you certainly are aware of, the four compartments separated by yellow dashed lines must for an unambiguous reception show exactly four carriers for a given sub id. Now look at the following spectrum, taken from your file and zoomed. I lifted the threshold slightly, to get a stable picture. The blue lines are the carriers indicated in the TII list.

If one hovers over these blue lines and looks for a sub id of 2, one will find five instead of four, clearly indicating a collision. No hidden secrets. You get similar findings for Sub Id 1 and Sub Id 3. Thus, to get rid of the collision (here!), you need to lift the threshold.

As a side note, the threshold is low due to the fact that the magnitude is normalized to a value of 1 for the strongest carrier. As you are near a transmitter, this lowers the threshold considerably. In such a case a manual threshold is preferable.

To make a decision which ones of the shown transmitters in the list are you really receiving, you need to consult other information, as written in my last posting. The software cannot make this decision.

Hope this helps.

[DigiBC]

Many thanks for your explanations. I will take a closer look at the TII spectrum.

Still, I wonder why only the WDR mux seems to be affected by this behavior, especially since schluckspecht's experiences were not made close to the transmitter.

[schluckspecht]

But what does the High-Res button exactly do? If I enable it, the TII diagram does not show anything any more, but the WDR station is correctly identified.

[softsyst]

Thanks for the question. This behavior indeed needs an explanation.

This checkbox had its use stand-alone in the older versions. It showed the TII spectrum in a high resolution, just like the picture below. Please remember that the TII carriers are always a pair of carriers separated by 1kHz. The standard "low-resolution" spectrum (like in my last posting) shows both carriers of a pair as a broadened single, smeared peak, which is usually sufficient.

In the current version, to see the Hi-Res spectrum the checkbox "Phase-based TII calculation" needs to be checked. In that case the spectrum, when zoomed, shows the carrier pairs, like so:

The same spectrum in "Low Resolution":

In the Hi-Res view it is also possible to hover over the carriers. Always, both carriers of a pair should indicate the same Sub Id, as always both belong to the same Sub Id. Please remeber: The Sub Id can be extracted from the position in the spectrum alone, in contrast to the Main Id, which is a combination of exactly four carrier (pairs).

But why not always use the phase-based calculation of the TII Ids?

Two answers: It is in no way reliable (yet), as there are scenarios where it simply does not work. The reason is still not known. Therefore, I introduced it as "Highly Experimental". In many scenarios it works very well, also resolving very weak carriers in the CIR, 30dB or more below the main peak. The second answer: It is slow. The "High-Resolution" means a higher resolution of the spectrum. For this to work, the data from a single Null symbol (every 96ms) are not sufficient. As a result, the software collects null symbol data from more than one Null symbol and concatenates them - with the correct phases at the end and the beginning of the next.

Thus, for a single FFT of the spectrum eight Null symbols are used (almost one second). Additionally, one always needs rather high averaging, easily resulting in some minutes for the capturing of TII Id's.

Therefore, the fast "Standard" calculation of the TII Id's is magnitude-based and updated every frame (96ms), without using the phases of the carriers. However, for the indication of the positions of the Ids in the CIR spectrum the phases are used in a very similar way than in the Hi-Res mode.

To make a long story short: The isolated operation of the Hi-Res checkbox does not make sense. Either its old functionality should be re-introduced again or It should be removed, as it is obviously confusing.

[schluckspecht]

To make a long story short: The isolated operation of the Hi-Res checkbox does not make sense. ---> It makes the local station visible again and delivers the correct Main- and Sub-ID in my case.

But I read, that the BR (Bayrischer Rundfunk) uses phase-based coding of TII in a manner that does not fit to the standard.

[superblyb]

Would it be possible to create a database for the TII data, made and maintained especially for Qirx? I am thinking of this because it seems to me this bug is maybe related to the recognition of the used TII from the database where the provided data are sometimes incomplete or not up-to-date, or not standardized is some way.

[softsyst]

@superblyb No, this will not happen. The TII database is the DABLIST which is very well maintained. Here we deal with TII collisions. Please make yourself familiar with what they are in case you are uncertain about it.

A TII Collision is not a bug, what I accepted as a bug was the following (see above): "What happens erroneously is that on the map all icons vanish after a 99 has discovered. This is a software bug and will be fixed."

All the rest of this discussion circled more or less around an explanation what a "TII collision" is. Thanks for your understanding.

[WIHDIA]

Would it be possible to create a database for the TII data, made and maintained especially for Qirx? I am thinking of this because it seems to me this bug is maybe related to the recognition of the used TII from the database where the provided data are sometimes incomplete or not up-to-date, or not standardized is some way.

Hi superblyb

I don't know of any database of TII codes better than the one now used (from fmlist.org). As Belgium editor I can tell you collecting data is NOT a piece of cake, especially in Flanders. When a new mux is on air we usually do a field trip to make sure the observed TTI code is from the presumed location. A few weeks ago I was in Wavre to check out the 12A TII code. Operators over here think TII codes are top secret stuff :-(

Best regards,

Herman

My logblog Belgium editor of fmlist.org

[superblyb]

Sorry for calling this a bug. I think the pseudo label 99 is very helpful and I am much more familiar with the TII collision phenomenon now than I was before. Thumbs up.

[softsyst]

I will close this one. I think all was about TII collisions. In case you think part of it should remain open, please be so kind and open a new issue.

[schluckspecht]

With 4.0.9. the station is not deleted any more in the map even in case of a collision.