ATSC 3.0: Washington, DC / Baltimore, MD

ATSC 3.0 Forum
joblo
Posts: 25
Joined: Fri Mar 05, 2021 2:45 am
x 5

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by joblo »

Now qpsk 6/15, 1-1.5 Mbps... PLP0 lock around 1 dB SNR, 14.9 dB = 100%...

stvcmty
Posts: 3
Joined: Fri Mar 26, 2021 12:06 pm
x 2

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by stvcmty »

Will 760246, Sinclair’s experimental ATSC 3.0 LPTV on CH24 in Hunt valley, MD have any consumer-receivable content?
https://enterpriseefiling.fcc.gov/datae ... yId=760246
https://www.rabbitears.info/tvq.php?req ... cid=760246
https://www.tvtechnology.com/news/sincl ... ntegration

RabbitEars’ signal search map predicts I will get a stronger signal for it than WIAV. Unfortunately, 760246’s heading is in the null between the main lobe on my HD8800 and the first side lobe when my HD8800 is aimed for the DC stations so getting it at home would take some work.

I may have to take my Connect 4k, an antenna and a laptop to see if I can get the signal over on York Road.



I am not sure if the antenna they are using matches the purpose of the STA. The station is horizontally polarized but they want to test mobile devices. I would think some amount of vertical polarization would help them in the mobile space.

Trip
Posts: 56
Joined: Sat Aug 07, 2010 6:49 am
Location: Alexandria, VA, USA
x 8
Contact:

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by Trip »

FCC rules require that horizontal power exceed vertical. The best they could do is to go circular with it. Perhaps they're testing the worst case--trying to do mobile from an H-only antenna.

If you happen to get over to look at it, I'd be extremely interested to find out what you see. I assume at least some of it will be consumer-receivable, as there's no need to put encryption on a test feed.

- Trip

ctbarker32
Posts: 83
Joined: Fri Aug 26, 2011 8:56 am

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by ctbarker32 »

I just did a rescan today and noticed "WIAV HEVC". This is my first reception of a ATSC 3.0 signal.

I am curiouis that the HDHomeRun "RED Record" button is hidden while viewing this channel. Is the type of DRM we have to look forward to in our ATSC 3.0 future? I really hope not!

jasonl
Expert
Posts: 15605
Joined: Sun Oct 28, 2007 9:23 pm
x 29

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by jasonl »

Does it have guide listings? The record button won't be there if there are no guide listings for the channel. You'll need to post in the guide issues forum to have them add listings for that channel.

Thunderthud
Posts: 526
Joined: Sun Apr 12, 2015 6:59 am
Device ID: 1080B565, 1322B8A6, 13257C3D, 1041CFDB, 10514020, 101886A, 10120815
Location: Virginia
x 4

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by Thunderthud »

WIAV shows up as channels 158.1 and 158.3 here. 158.1 has guide info and the record button shows up and recorded.

Works fine for audio and video on my 4K fire stick with an old Toshiba 720p tv .

2nd gen fire stick and my Android devices say "no video codec" and hang.

My Shield 2017 has video, but no audio, hooked up to 4k Samsung TV VIA HDMI

Haven't checked my PC's yet.

Not a good track record, so far....

xmguy
Posts: 130
Joined: Sun Feb 14, 2021 8:30 am
Device ID: 10815046, 1037F17E
Location: McMinnville, TN
x 3

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by xmguy »

Trip wrote: Fri Apr 16, 2021 5:57 am FCC rules require that horizontal power exceed vertical. The best they could do is to go circular with it. Perhaps they're testing the worst case--trying to do mobile from an H-only antenna.

If you happen to get over to look at it, I'd be extremely interested to find out what you see. I assume at least some of it will be consumer-receivable, as there's no need to put encryption on a test feed.

- Trip
I wish they'd use a circular polarization for xmitting. Most antennas are horizontal in orientation anyway. Hence the favortism toward that polarization.

jonw747
Posts: 6
Joined: Wed Oct 21, 2020 2:28 pm
x 1

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by jonw747 »

Some good news!
Following extensive engineering and operational planning and installation of a new transmitter and related equipment and upgrades to the station's physical plant, WHUT is expected to sign on with NEXTGEN TV signals from five different network sources later this summer.

...

Howard University's WHUT will serve as the host station for NEXTGEN TV broadcasts for local stations WHUT (PBS), WJLA (ABC), WUSA (CBS), WTTG (FOX), and WRC (NBC).  WJLA will carry high-definition programming from both the ABC network and WHUT, along with several standard-definition commercial sub-channels and the WHUT PBS Kids service.
https://www.prnewswire.com/news-release ... 13526.html

joblo
Posts: 25
Joined: Fri Mar 05, 2021 2:45 am
x 5

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by joblo »

Trip wrote: Thu Mar 25, 2021 11:39 am And nickk, how about making access to the manifest.xml file a part of the standard firmware somehow? Assuming the parameters are pretty straight-forward, that would be a good way to get data onto RabbitEars about what the stations are up to on 3.0.
How do you get it with the dev firmware? And what's in it? Can you PM or email me a copy?
Trip wrote: Thu Apr 01, 2021 7:57 am I wish plpinfo (or a more detailed version of it) could spit out some of the other parameters, like the LDPC, FFT, Guard Interval, etc.
Agreed. I'd especially like to see the BSID, which, according to A/322 Table 9.8, is in the preamble along with the plp parameters.

Ideally, it would be nice to get a dump of the whole preamble, which seems to be the source of the HDHR's plpinfo.

And even better, it would be nice if it could detect and report the presence of the 4.5 MHz A/321 bootstrap bytes, even if the A/322 preamble is malformed or completely absent. WIAV seems obviously to have been broadcasting something between 20:00 EDT last night and 14:50 EDT today, but none of the 4K boxes could recognize it.

And finally, just one more thing. ([tm] Lt. Columbo) Does the RabbitEars band scanner software piggyback off the SD scan functionality, or does it do its own set/get operations on the channel range? Because it seems very clear that both the SD scan command and the RE scanner cannot detect 3.0 signals at the same level at which the HDHR can decode them. I'm assuming, for now, that this is a timing issue, because the 3.0 detection at low SNRs takes more time than the scan functions allow. And since a big part of the reason I bought the HDHR was for its automated DX'ing capabilities, I'm interested in fixing this, even if it means modifying the code, myself. Been a long time since I wrote code, but I made a decent living at it when I did it, so I think I could do it, and I have both the time and the inclination.

Trip
Posts: 56
Joined: Sat Aug 07, 2010 6:49 am
Location: Alexandria, VA, USA
x 8
Contact:

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by Trip »

joblo wrote: Tue Jun 22, 2021 7:28 pm How do you get it with the dev firmware? And what's in it? Can you PM or email me a copy?
I just did a packet collection:

Code: Select all

wget "http://1080xxxx.local:5004/auto/v158.1?duration=60&format=dash-tar" -O wiav.tar
And then the file was just included in it.

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<MPD availabilityStartTime="1970-01-01T00:00:00Z" maxSegmentDuration="PT1.001S" minBufferTime="PT1S" minimumUpdatePeriod="PT12H0M43S" profiles="urn:mpeg:dash:profile:isoff-live:2011" publishTime="2021-06-23T07:55:12Z" timeShiftBufferDepth="PT6S" type="dynamic" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" xmlns:scte35="http://www.scte.org/schemas/35/2016" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemalocation="urn:mpeg:dash:schema:mpd:2011 DASH-MPD.xsd">
   <Period id="P0" start="PT0S">
      <AdaptationSet contentType="video" id="0" maxFrameRate="60000/1001" maxHeight="1080" maxWidth="1920" mimeType="video/mp4" minFrameRate="60000/1001" minHeight="1080" minWidth="1920" par="16:9" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
         
      <Representation bandwidth="1000000" codecs="hvc1.2.4.L123.11" frameRate="60000/1001" height="1080" id="Video1_1" sar="1:1" scanType="Progressive" width="1920">
            <SegmentTemplate duration="1001000" initialization="video-init.mp4" media="video-$Number$.mp4v" startNumber="1" timescale="1000000"/>
         </Representation>
</AdaptationSet>
<AdaptationSet contentType="audio" id="1" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1">
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
         
      <Representation audioSamplingRate="48000" bandwidth="96000" codecs="ac-4.02.01.00" id="a02_2">
            <AudioChannelConfiguration schemeIdUri="tag:dolby.com,2015:dash:audio_channel_configuration:2015" value="00a000"/>
            <SegmentTemplate duration="48048" initialization="a0-$RepresentationID$-init.mp4" media="a0-$RepresentationID$-$Number$.m4s" startNumber="1" timescale="48000"/>
         </Representation>
</AdaptationSet>
<AdaptationSet contentType="text" id="2" lang="und" mimeType="application/mp4" segmentAlignment="true" startWithSAP="1">
         <SupplementalProperty schemeIdUri="http://dashif.org/guidelines/dash-atsc-closedcaption" value="ar:16-9;er:0;profile:0;3d:0"/>
         <Role schemeIdUri="urn:mpeg:dash:role:2011" value="subtitle"/>
         
      <Representation bandwidth="50000" codecs="stpp.ttml.im1t" id="d3_3">
            <SegmentTemplate duration="1001000" initialization="$RepresentationID$-init.mp4" media="$RepresentationID$-$Number$.m4s" startNumber="1" timescale="1000000"/>
         </Representation>
</AdaptationSet>

   </Period>
</MPD>
That's what came out of my 60-second capture this morning from manifest.xml.
joblo wrote: Tue Jun 22, 2021 7:28 pm And finally, just one more thing. ([tm] Lt. Columbo) Does the RabbitEars band scanner software piggyback off the SD scan functionality, or does it do its own set/get operations on the channel range? Because it seems very clear that both the SD scan command and the RE scanner cannot detect 3.0 signals at the same level at which the HDHR can decode them. I'm assuming, for now, that this is a timing issue, because the 3.0 detection at low SNRs takes more time than the scan functions allow. And since a big part of the reason I bought the HDHR was for its automated DX'ing capabilities, I'm interested in fixing this, even if it means modifying the code, myself. Been a long time since I wrote code, but I made a decent living at it when I did it, so I think I could do it, and I have both the time and the inclination.
It uses the standard scan functionality.

But I'm in full agreement that I really, really want a more advanced plpinfo function with the BSID and other advanced information if it's available.

- Trip

nickk
Silicondust
Posts: 16996
Joined: Tue Jan 13, 2004 9:39 am
x 110

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by nickk »

Trip wrote: Wed Jun 23, 2021 3:27 am But I'm in full agreement that I really, really want a more advanced plpinfo function with the BSID and other advanced information if it's available.
BSID - looking into it now.

Nick

nickk
Silicondust
Posts: 16996
Joined: Tue Jan 13, 2004 9:39 am
x 110

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by nickk »

Firmware with BSID reporting:
viewtopic.php?f=126&t=20613

If the BSID is being sent by the broadcaster AND the BSID that is being sent is non-zero the HDHomeRun will report the BSID at the end of the /tunerX/plpinfo information.

Note that in Phoenix neither of the two ATSC3 physical channels are sending BSID information - channel 27 is sending 0x0000 and channel 35 isn't sending the field.

Nick

Trip
Posts: 56
Joined: Sat Aug 07, 2010 6:49 am
Location: Alexandria, VA, USA
x 8
Contact:

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by Trip »

Just tried it and WIAV-CD must not be transmitting the BSID either. I'll have to see if I can pester someone there about it.

When doing a standard scan, will the BSID appear in the TSID field if it's available?

- Trip

bobchase
Posts: 66
Joined: Sun Nov 22, 2020 12:25 pm
Device ID: 10810736
x 10

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by bobchase »

nickk wrote: Wed Jun 23, 2021 1:59 pm Firmware with BSID reporting:
viewtopic.php?f=126&t=20613

If the BSID is being sent by the broadcaster AND the BSID that is being sent is non-zero the HDHomeRun will report the BSID at the end of the /tunerX/plpinfo information.

Note that in Phoenix neither of the two ATSC3 physical channels are sending BSID information - channel 27 is sending 0x0000 and channel 35 isn't sending the field.

Nick
Nick,
Ch35 - KFPH is transmitting a BSID of 3112. It's in the SLT. We were/are using that BSID for testing Signing.
-------------------------
<SLT
xmlns="tag:atsc.org,2016:XMLSchemas/ATSC3/Delivery/SLT/1.0/"
bsid="3112" />
<Service
--------------------------------------------------

Bob

nickk
Silicondust
Posts: 16996
Joined: Tue Jan 13, 2004 9:39 am
x 110

Re: ATSC 3.0: Washington, DC / Baltimore, MD

Post by nickk »

bobchase wrote: Wed Jun 23, 2021 7:23 pm Ch35 - KFPH is transmitting a BSID of 3112. It's in the SLT. We were/are using that BSID for testing Signing.
-------------------------
<SLT
xmlns="tag:atsc.org,2016:XMLSchemas/ATSC3/Delivery/SLT/1.0/"
bsid="3112" />
<Service
--------------------------------------------------
Ok, that is a higher layer.

The HDHomeRun plpinfo data comes from L1 detail which can contain the BSID.

We could probably add the SLT BSID to the streaminfo data.

Nick

Post Reply