I'm about 25 miles from NextGen (ATSC 3.0) towers and easily pick up the legacy ATSC 1.0 stations. Anyone have an idea why my new Flex 4K isn't picking up any of the 3.0 stations?
Under channel lineup on the hdhr ui atsc 3.0 channels show up in the 100’s. So channel 5.1 would be 105.1 for atsc 3.0. Try rescanning?
I was aware of that, but thanks for the response. The problem was actually the signal strength. I assumed if my signal was good on the ATSC 1.0 channels then it would at least discover the 3.0 equivalents... not the case. I've read that 3.0 channels often pick up better, but as you can see they are a good bit weaker for me...
You may get answers from the AVS Forum in the Charlotte OTA section.
I would start at this page Charlotte, NC - OTA | Page 753 | AVS Forum and work to the end.
Thanks, I assume the 3.0 channels are just being broadcast at a lower power. They are coming in fine even with my temporary setup, should be great once I get everything setup in the attic.
In my market in Norfolk/VABeach, the are running atsc 3.0 off a translator at lower power. I can get it at about 70% signal strength and I can see the tower from my house. I feel bad for people that are further away than I am. You may be in a similar situation in your market. Also I was thinking that I may try to re-aim my antenna to maximize the signal strength for 3.0. I really didn't have to when I did the initial install since the signal on atsc 1.0 was so strong.
WAXN the ATSC 3.0 lighthouse station carrying those channels in Charlotte broadcasts at a much lower power level than the other Charlotte stations do. I receive all the rest fine at my location (about 40 miles away) but can't get them either. That most likely is your biggest issue.
Other than a slightly better picture the 3.0 signals in Charlotte have audio issues. None of my devices can get anything other than two channel stereo and a couple of the channels have out of phase sound. Signal is rock solid though.
In my market, Cincinnati, the locals all got together and moved their ATSC 3.0 channels to a central tower. This was good news for me, now I get the 5 main networks from Cincy with strong signals, where before I got none. Perhaps something similar happened there?
The issue for me is the new AC-4 audio and general HEVC (H.265 video codec) issues with the stations, who, BTW, are still broadcasting in 720 and 1080p. I'm going to go out on a limb and guess my old quad-core Intel CPU from 2010(?) won't be stout enough to handle the 4K/HEVC when it does come to fruition.
There is a great app to use with your tuner for iOS called GH Signal when pointing your antenna and see noise factor. Also, I've had great results with Kitztech preamps. They are very low noise and that made all the difference a very low power ATSC 3 station in Raleigh for me.
Here is the latest reasons why ATSC3 in Charlotte is not working.
Bug report for ATSC 3.0 channel 3.1 WBTV in Charlotte NC
Audio track:
The audio track contains a sidx box specifying a timescale of 48,000. The audio track contains a mdhd box specifying a timescale of 240,000.
The standard section 8.16.3.3 recommends that the sidx timescale and the mdhd timescale match. This recommendation is not being followed.
The standard section 8.16.3.3 specifies that the sidx timescale provides the timescale for the time and duration fields within the sidx box (only).
The standard section 8.4.2.3 defines the mdhd timescale specifies the timescale for the media in this track.
The sidx box contains an earliest_presentation_time field. Comparing successive segments shows a delta of 96,096 which is 2.002s at 48,000. This is correct as per the timescale specified in the sidx box.
The tfdt box contains a base_media_decode_time which exactly matches the sidx earliest_presentation_time. Comparing successive segments shows a delta of 96,096 indicating that the timebase of the tfdt base_media_decode_time field is actually 48,000, not the 240,000 specified in the mdhd box.
The tfhd box contains a default_sample_duration of 1601. The compressed audio data contains 1601.6 audio samples per frame at 48kHz indicating that the timebase of the tfhd default_sample_duration field is actually 48,000, not the 240,000 specified in the mdhd box.
The trun box does not contain sample duration information which means the tfhd defaullt_sample_duration of 1601 applies. This value results in an accumulated error within the segment as the actual audio duration is 1601.6/48.000 or 8,008/240,000.
Recommendations for the audio track:
- Keep the mdhd timescale 240,000. Change the sidx timescale to 240,000 to match. This follows the section 8.16.3.3 recommendation that the timescales match.
- Change the sidx earliest_presentation_time to be based on a timescale of 240,000.
- Change the tfdt base_media_decode_time to be based on a timescale of 240,000. This corrects the base_media_decode_time to be based the mdhd timescale.
- Change the tfhd default_sample_duration to be be based on a timescale of 240,000 making the value 8008 (29.97 audio frames per second). This corrects the default_sample_duration to be based on the mdhd timescale and eliminates the accumulation of error within the segment.
Video track:
The video track contains a sidx box specifying a timescale of 90,000. The audio track contains a mdhd box specifying a timescale of 60,000.
The standard section 8.16.3.3 recommends that the sidx timescale and the mdhd timescale match. This recommendation is not being followed.
The standard section 8.16.3.3 specifies that the sidx timescale provides the timescale for the time and duration fields within the sidx box (only).
The standard section 8.4.2.3 defines the mdhd timescale specifies the timescale for the media in this track.
The sidx box contains an earliest_presentation_time field. Comparing successive segments shows a delta of 180,180 which is 2.002s at 90,000. This is correct as per the timescale specified in the sidx box.
The tfdt box contains a base_media_decode_time which is 1502 behind the sidx earliest_presentation_time. Comparing successive segments shows a delta of 180,180 indicating that the timebase of the tfdt base_media_decode_time field is 90,000, not the 60,000 specified in the mdhd box.
The tfhd box contains a defaullt_sample_duration of 1502. The compressed video data contains video frames spaced at 1501.5 / 90,000 indicating that the timebase of the tfhd defaullt_sample_duration field is 90,000, not the 60,000 specified in the mdhd box.
The trun box does not contain sample duration information which means the tfhd defaullt_sample_duration of 1502 applies. This value results in an accumulated error within the segment as the actual video duration is 1501.5/90,000 or 1,001/60,000.
Recommendations for the video track:
-
Change the mdhd timescale and the sidx timescale to 240,000. This follows the section 8.16.3.3 recommendation that the timescales match. It would be valid to keep the mdhd timescale at 60,000 and to change the sidx timescale to 60,000 to match however selecting 240,000 (clean multiple of 60,000) would make the timebase match between the audio and video.
-
Change the sidx earliest_presentation_time to be based on a timescale of 240,000.
-
Change the tfdt base_media_decode_time to be based on a timescale of 240,000. This corrects the base_media_decode_time to be based the mdhd timescale.
-
Change the tfhd defaullt_sample_duration to be be based on a timescale of 240,000 making the value 4004 (59.94 video frames per second). This corrects the default_sample_duration to be based on the mdhd timescale and eliminates the accumulation of error within the segment.
Review of other sub channels:
- 36.1 WCNC appears to have the same issues as 3.1 WBTV.
- 46.1 WJZY appears to have the same issues as 3.1 WBTV.
- 9.1 WSOC uses the same timescale between sidx and mdhd (48,000 for audio and 90,000 for video) however there is a minor accumulation of error within each segment similar to 3.1 WBTV.
- 64.1 WJZY uses the same timescale between sidx and mdhd (48,000 for audio and 90,000 for video) however there is a minor accumulation of error within each segment similar to 3.1 WBTV
Contact:Nick Kelsey – CTO, Silicondust USA Inc.