Need info about HDHR device tuner behavior to troubleshoot ATSC 1.0 reception issue

[OTATVandSDHomeRunFan]

Notice:
Updated on 05/08/24 around 0245pm PT to fix one key error (missing word), some typos, and add some more info/questions.
I have underlined the changes/additions.
------------------------------------------------------------------------------------------------------------
I am trying to troubleshoot an interesting reception problem in my DMA.

BACKGROUND

I am trying to receive a low-power ATSC 1.0 Class A digital station with a directional pattern.
I am trying to be a bit vague in this posting for privacy reasons, so lets call this station A.

Potentially complicating reception are 2 co-channel stations, one with significantly higher power.
Lets call these stations B and C. Both also use directional antenna patterns.

Under "normal" reception conditions, these stations' coverage areas (while adjacent) should, theoretically, have no overlap for receiving devices at ground level.

(Unfortunately, lately, this area does not seem to be seeing such supposedly "normal" reception conditions that often.)

I am located within station A's normal coverage area, but approaching the edge of its minimum signal strength contour. Let's call my location "R" (for receiver).
This location is roughly 50 miles line of sight (LOS) from B and roughly 73 miles LOS from Station C. (See additional info at end of this message.)

At times, there are aircraft traversing my receiving area at an estimated altitude of 5K to 10K feet.

RECEPTION ISSUE

Depending on weather phenomena (Eg tropo ducting), I can totally lose are not be able to lock (for significant time intervals, sometimes hours) Station A at Site R with my multiple HDHR tuners and pretty good antennas.

(Without the (very?) good antennas, none of my NON-HDHR device's tuners can even detect (under "typical" conditions) stations on the RF channel all these 3 stations use/share.)

At other times, I can lock station A but reception is unstable because I am often close to the edge of achieving lock (Signal strength about 50-57%; Signal quality 47-52%). Obviously, symbol quality is sub-optimal most of the time but when signal quality rapidly/significantly fluctuates (eg due to "multipath", likely from passing planes), symbol quality is 0 or very low for the time interval (see next paragraph) where SS (Signal strength) or SNR (Signal quality) is poor.

I experience the most rapidly fluctuating and disruptive reception when station A barely locks (Signal quality (47-50%)) apparently due to planes traversing the R area. After some assessment and analysis of the received data, I suspect the passing aircraft is causing the receiver to lose lock on station A, briefly lock a signal from station B or C for a second or so and then lose the lock of that signal after 1-2 seconds and relock station A. This apparent signal lock loss/lock cycle appears to occur multiple times as the aircraft traverses. Finally, it relocks "A" signal for a more extended time interval.

I realize it is possible that only station A's signal is being lost and relocked (typical severe multipath?).
Based on what I have observed and measured so far, I'm suspecting that is not actually the case and that 1 or more signals (e.g. from stations B and C) is playing a role.

I would like to figure out what's actually happening and want to see what type of tools (ideally info from within HDHR tuner/firmware) can help me root cause this issue.
Are there any such tools? Or, can I use TSReader for this?

MY SPECIFIC QUESTIONS

1. Is there a log I can access in the HDHR (or have SD fetch and relay to me) that would give me better insight into the tuner's reception statistics?

In particular, I would find it helpful to know:
a. when the tuner "locks" a signal
b. when the tuner "loses" a currently locked signal.

Seeing a log or notifications of these events would be very helpful.

2. I want to understand how the firmware/software in the HDHR devices handles the construction and maintenance of the ATSC 1.0 PSIP data, including the construction, update and possible "reset" of the data in the ATSC 1.0 PAT, PMT and TVCT tables.

For example, does an upper layer (i.e. not physical layer) totally or partially "reset" any of the PAT, PMT, or TVCT data if lock is lost while the tuner is being used to actively "watch" a program stream? Depending on what happens to this data when a lock is lost, it seems to me this could affect reception if the next "lock" is for a station different than the one most recently lost.

Is there a way to monitor the PSIP data (including PAT, PM and TVCT data) with HDHR tools?

SUMMARY

I realize these concerns involve highly technical details.

If there is documentation available somewhere of what functionality related to above topics is required (or optional) to be implemented by tuner/receiving devices, I would appreciate pointers to that. I would also be happy to provide further details, in a more private setting than this forum, if that would be helpful.

I truly like my SD HDHR devices. Their reliability and performance, for me, have been excellent.

Thank You!
----------------------------------------------------
Additional Station Details:
a. Distance (LOS):
From A to B: ~ 90 miles
From A to C: ~ 92 miles
From B to C: ~ 80 miles
b. Power:
Station A: ~ 3 KW ERP
Station B: ~ 15 KW ERP
Station C: ~ 1000 KW ERP

[jasonl]

There isn't a log available, and the log data we get probably isn't useful for this as it only logs signal stats every 2 minutes. You would probably want to script something to use hdhomerun_config to retrieve the tuner status much more frequently.

When tuning by virtual channel number, the device generates a new PAT to create an SPTS so there are no references to PIDs that don't exist that might trip up apps. The PMT is only checked to generate the PID filter so that the correct elementary streams are passed through. I don't think it is monitored on an ongoing basis, but I'm not 100% sure on that. TVCT data is not generally used for actual tuning, just for the streaminfo and channel scan.

It's highly unlikely that you would be able to lock 2 different broadcasts on the same frequency. If one is strong enough to receive under normal circumstances and the other 2 can only come in with assistance, then you're either going to get the strong one or nothing. The weaker ones aren't going to ever be stronger enough to overcome the strong one.

[OTATVandSDHomeRunFan]

Thanks for your helpful reply.

Unfortunately, I just lost a long, detailed followup message that took me about 45 minutes to prepare, due to an apparent lack of auto-save in the message composition environment and forced automatic logout that only became apparent when I tried to post my reply.

I'll have to try and recompose it all tomorrow.

Sorry for the delay in my followup until then. Appreciate the response. Hope you can then respond to my clarifying comments/questions and a couple of additional questions after I recreate everything.

[OTATVandSDHomeRunFan]

Thanks again for your reply.

I would like to make some comments and then ask for some clarification. Since I lost my first reply, I'll keep this briefer than my initial reply.

Regarding paragraph 1:

I have in the past downloaded from your web site versions of both your old UDP server API document as well as the newer HTTP API document. I don't know if the HTTP version I have is the latest. Could you provide a link from where I can download the latest HTTP version? Thanks.

Regarding paragraph 2:

I appreciate the summary details you provide about the PAT, PMT, SPTS and TVCT actions.

I have a few additional, pretty geeky, questions which, instead of bugging others who might be reading this post, I will PM to you.

Regarding paragraph 3:

I suspect your characterization of the reception scenario as highly unlikely is probably right.

I do want to ask one followup question though:
1. Does a manufacturer of an ATSC 1.0 capable-tuner and/or playback device (like the SD HDHR devices) have to adhere to any (eg government, standards body, etc.) "standards" in developing the firmware/software that helps demux and further process the MPTS, PSI and/or SPTS? Or, is all of this behavior left to the manufacturer's discretion?

Thanks again!

[jasonl]

The HTTP API is covered in our documentation at https://info.hdhomerun.com/info/http_api .

All of the ATSC 1.0 standards are freely available on their site at https://www.atsc.org/atsc-documents/type/1-0-standards/ . Transport streams and associated structures like the PAT and PMT predate ATSC and were defined as part of MPEG2, specifically ISO/IEC 13818-1 aka ITU-T REC H.222.0, which technically costs money. The ATSC standards are incorporated by reference in federal code (47 CFR § 73.682) but this is for the broadcasters rather than the receivers. 47 CFR § 15.117(b) is the closest for receivers:

TV broadcast receivers shall be capable of adequately receiving all channels allocated by the Commission to the television broadcast service that broadcast digital signals using the DTV transmission standard in § 73.682(d) of this chapter, but need not be capable of receiving analog signals or signals using the Next Gen TV transmission standard in § 73.682(f) of this chapter.

[OTATVandSDHomeRunFan]

Thanks for the link to the current HTTP API.

Thanks also for the very detailed responses about ATSC 1.0 specs, MPEG2 TS related spec, broadcaster CFR & receiver CFR regulations.

I was familiar with all but the receiver requirements (the quoted CFR, it turns out) which was the attempted focus of my question.

Clearly, the receiving device has to understand and be able to process the specified ATSC 1.0 RF signal and its payload for anything to come out at the end that is "as expected" and useful.

That's why my question (perhaps poorly phrased; my apologies if so) was trying to determine if any of the receiver devices' functional or non-functional software capabilities (e.g. design, performance, robustness/reliability, security hardening, etc.) had to meet any specific regulations and/or testing (eg interoperability) requirements. I was expecting that all this was at the device manufacturer's discretion, since, to my knowledge, that is typically the case in the USA.

And, given your device receiver response, it seems my expectation was correct. (Please let me know if I misunderstood anything.)

Overall, a very helpful and thorough response. Thank You!