After #311 I/Q files no longer playback correctly

[pclov3r]

So after the recent pulls it seems some I/Q files will not play correctly.

If i revert back to https://github.com/theori-io/nrsc5/commit/31fe83bea1a0a7b0ed9bf9b42bbd39d662b1679c then the I/Q file plays correctly. Checking out to https://github.com/theori-io/nrsc5/commit/4ce42ea74a1e364e612fe3125801b0cd1685eb74 is when the problem occurs. So it appears https://github.com/theori-io/nrsc5/pull/311 is what has caused the problem.

Maybe a bug was introduced somewhere in the merges after that?

I am uploading a sample now and will include it once it's done uploading.

[pclov3r]

Gone ahead and uploaded the sample here https://gofile.io/d/jh8GEO

This was captured in a moving car with a RSPdx and then later converted in GNUradio.

@argilo Hopefully an easy fix.

[argilo]

Thanks for the report. If you have a chance, could you do a git bisect to track down which commit is the culprit?

[argilo]

Never mind, I see you already tracked down the problematic commit.

[pclov3r]

Thanks for jumping on it quickly.

The included sample in the repo does play correctly, But the signal here with picket fencing present is problematic. I do have a stable sample of the station without and strong it if it helps at all.

[argilo]

OK, I think I see the problem. The bit error rate in that file is very high, which causes some bits of the PCI value to be corrupted. The new has_audio check only allows audio through when the PCI value exactly matches one of the values that indicate the presence of audio data.

Since audio data is almost always present, I guess it should do the opposite and only refuse to decode audio when the PCI is equal to the "data-only" value.

[argilo]

I expect #315 will fix it. Let me know how it works for you.

[pclov3r]

Yep, #315 seems to fix it and now plays correctly.

[argilo]

Glad to hear it.

It occurs to me that there might also be some benefit to switching has_fixed to a fuzzy match; right now, data processing will be skipped if there's even a single bit error in the PCI value.

[argilo]

The PCI value is also very unlikely to change between PDUs within the same logical channel, so I suppose in the event of bit errors it could default to whatever the previous correctly received PCI value was.

[pclov3r]

@argilo Thank you for putting in a lot of effort of the past while to improve the project.

Just to throw it out there I wonder if there any improvements left to improve performance? The HD standard was designed to handle a lot less then ideal conditions. For example the sample I included in a moving car.

I suppose channel estimation and equalization are already in use?

Thanks!

[argilo]

I suppose channel estimation and equalization are already in use?

Yes, equalization is already in place, and I've put a decent amount of effort into improving the receive performance in the face of degraded signals. Of course, there still could be further improvements available.