First Look: Dish Network's DTVPal Digital Converter

[Anole]

why no clock on DTVpal

There has been a lot of discussion about the ability of the DTVpal to work in the absence of accurate timing from ALL received TV stations.
While I like to give a good groin-kick where needed, this time I'll explain why it doesn't have a clock.

As a former product developer (in an unrelated industry), you try to make it do the job for a budget, and in a certain time frame.
The less coding that goes into a product, the quicker it can be developed, tested, debugged, and sent to market.
The less hardware that goes into the product, the smaller the board, the lower the power, the quicker it gets designed, and the easier it is to manufacture and test.

You are given a list of features, a desired manufacturing cost, and a delivery date.
And you're given a bunch of specs to work from.
One of those specs says all the TV stations are in lock-step with WWV, and they all broadcast the identical and correct time.
(I have three WWV clocks in my house that are like that, so it sounds good to me!)

So, with all the above info at hand, I'm not about to put a clock chip in this design, because all the associated parts cost money, take space, require a backup battery or capacitor, and probably need a tweak on the production line!
That would have been a clock that could have held to a couple of seconds per month.

And the alternative, a clock function as part of the firmware is just ludicrous.
Why is that? There is a whole laundry list, but here are some highlights:
- the cpu clock isn't necessarily that accurate, nor trimmed
- the random interrupts to carry out core TV functions could throw off timekeeping (test/verifying to the contrary would be onerous)
- the power-down and power-off capability could cause loss of time
- user dissatisfaction with a bad cpu-based clock would be significant
- auto resynch to any station standard (as now) is no solution
- and besides, all those stations are in lock-step with WWV anyhow, right?! -

So, who do I blame?
The TV stations for not having a clue, much less the correct time which they could get from a $40 WWV wall-clock!

How do we fix this most easily?
Echostar should have expected or discovered the time-warp problem.
You know they thought about the box receiving from two time zones...
You solve it by making the timekeeping in the box, either:
- Automatic, as it is now, looking at whatever channel it's tuned to, or ...
- Manual, where the user gets to select from a menu which one local TV station is the master timekeeper.

Obviously, Automatic Time is the default.
If that turns out to not be satisfactory, the user changes it.
Solves the problem of receiving from an adjacent time zone, too, I suspect.

Choosing that station could be made from a channel list, with each stations time shown.
You see if the times all agree, and pick one. (Any which are way off, you don't pick!)
If it proves unstable, then next week, you pick the next channel in the list 'till you are happy.


We now return you to your regularly scheduled Echostar-bashing.

-[30]-

 

[rglore]

the Pal receives and displays both NTSC and ATSC that is it's reason for existance after all. it just can't tune NTSC but it does pass it through.

It does not receive NTSC, doing pass through by simply connecting the input to the output is not receiving. It appears to have no ability to get any data from the NTSC signal.

 

[Malouff]

You solve it by making the timekeeping in the box, either:
- Automatic, as it is now, looking at whatever channel it's tuned to, or ...
- Manual, where the user gets to select from a menu which one local TV station is the master timekeeper.

That's what I would have done but called the Manual setting something else as people would be expecting to enter in their own time.

We all forget about the need of a internal battery to keep the clock going with a manual user entered time and how something like this does require more than the above.

I heard on the AVS forum ideas to average all the times and to see if any of the times match. Both of these ideas would waste resources and are more complicated than the above. separate

You would think that with the time zone setting they would have thought that people can border two time zones and get stations from both sides.

 

[navychop]

the Pal receives and displays both NTSC and ATSC that is it's reason for existance after all. it just can't tune NTSC but it does pass it through.

18 months? that's only true if the average price on an ATSC set drops dramatically. You know something the rest of us don't?

I believe he means that almost all the folks that have analog only sets will have bought their converters fairly soon after the conversion. And since no more analog only TVs are being made, the market will quickly dry up. I suspect that the cliff will be around 3 months, say by the end of May 09. And only that long to take into account the folks that will pick up used analog only TVs sold off by people that prefer to just buy a new HDTV than to fool with a converter box.

 

[navychop]

It does not receive NTSC, doing pass through by simply connecting the input to the output is not receiving. It appears to have no ability to get any data from the NTSC signal.

It's not required to decode NTSC. The converter box exists, in the government's eyes, solely to convert a digital ATSC signal into one that an analog only TV can see. No support for monitors with no tuners at all is required. And judging by the number of converter boxes that don't even pass the NTSC signal, there is no requirement to support that, or the remaining low power NTSC stations. The government has a vested interest in removing even those low power NTSC stations- they are hardly going to go out of their way to further their continued existence.

 

[TalkingRat]

I believe he means that almost all the folks that have analog only sets will have bought their converters fairly soon after the conversion. And since no more analog only TVs are being made, the market will quickly dry up. I suspect that the cliff will be around 3 months, say by the end of May 09. And only that long to take into account the folks that will pick up used analog only TVs sold off by people that prefer to just buy a new HDTV than to fool with a converter box.

That would be nasty cliff for the people whose coupons expire in May 09.

 

[Smith P.]

Speaking of a possible debug screen I wonder if there is one.
Any hints pabeader?
<...>

While he keep silence or ignoring the question, take a look on the picture and connect TTL to RS-232 converter to RS232_J5 spots.

 

[Anole]

mode 1, mode 2 ?

You solve it by making the timekeeping in the box, either:
- Automatic, as it is now, looking at whatever channel it's tuned to, or ...
- Manual, where the user gets to select from a menu which one local TV station is the master timekeeper.

That's what I would have done but called the Manual setting something else as people would be expecting to enter in their own time.

oh, good point:
Automatic & Semi-Automatic
Then the gun lovers will get a giggle, and the gun haters will have a melt down! -

How about this?
Automatic & Single-Station mode?
That's a better description, anyway.

Anyway, the whole reason for the second mode is because the box probably can't be trusted to keep good time beyond half a day.
Not without that clock chip, the backup battery, and all that other stuff described in the previous post.
So, I see no justification for a true Manual Time Entry mode at all. Sad to say. -

I heard on the AVS forum ideas to average all the times and to see if any of the times match.

Imaginative. I can refute those proposals, but probably not worth the ink. -

You would think that with the time zone setting they would have thought that people can border two time zones and get stations from both sides.

I got to thinking about that later.
Even if the stations transmitted Universal Time, you'd still have to know that some stations were in the different time zone, so you could calculate what time they thought it was.
I see multi-time-zone operation as a big nightmare. We already have enough of those!
. . . so, let's sweep it under the rug and not deal with it, here. -

 

[pabeader]

sorry everybody. i'm in the middle of moving and internet is spotty. sorry, can't say anything about debug screen

 

[Malouff]

Anole I was thinking about the Single-Station mode.

Would the Guide need to be also have settings for channels to delay or advance in the EPG?

I know the clock would be correct but would the show listings in the EPG also be correct?

In a multi-time-zone operation I think this Single-Station mode could also have a bug with incorrect listings.

I would have never thought that the clock and listings would be that complicated and am understanding on how it really needs to be carefully thought out to be implemented correctly.

 

[Anole]

Mal -
. . . . and what do you do if the show in the guide really does start at 9:05 pm ???

Afterthought: no, if the guide says a show starts at 8pm, and even though that station's timer is off by 10 minutes, as long as you know the correct time, you use the correct time, ... derived from Single Station Mode.
In Single Station mode, you just have to ignore the clock of all other channels.
If those channels are so screwed up that their clock is 20 minutes off and their shows start 20 minutes off, then I don't want to deal with 'em! -
I think we have to make the (foolish?) assumption that their shows start on time, even if they don't know what correct time is.
And as for why, it's because the broadcast time is independent of show-start time and probably not monitored.

This all makes my brain hurt! -
But as I said above, let's not even think about adjacent time zones.

Think I'll look for a Channel Master CM-7000 to play with 'till this all blows over.

 

[navychop]

That would be nasty cliff for the people whose coupons expire in May 09.

Anybody know when they stop sending out coupons? I'm not sure any will expire past May of 09.

 

[johnpost]

Anybody know when they stop sending out coupons? I'm not sure any will expire past May of 09.

3/31/09 is last apply date

 

[harshness]

Anybody know when they stop sending out coupons? I'm not sure any will expire past May of 09.

They stop sending out coupons when they run out of money. Congress set aside $890 million funding for coupons with a $450 million contingency (total $1.34 billion).

Here's the weekly status report: https://www.dtv2009.gov/docs/Weekly_Stats_Report_en.pdf

The telling story is the 2.93 million expired coupons. Some fulfillment company in Portland, Oregon is sending out a whole lot of coupons that aren't getting used in the allotted time frame.

 

[Malouff]

I was just wondering if it did have the Single Station mode if all of the listings in the Guide would be correct.

Would there need to be a option to have the listings for each station have their show times either advanced or delayed to show the correct listings?

The Single Station mode would have the correct time is displayed if we assume one station is transmitting the correct time.

If there was no station transmitting the correct time then it would again need a option to advance or delay the time from that single station.

For everything to work in the worst case it would need options to advance and delay.

However, these options would not make it as user friendly and a person can't also trust a set it and forget it as the stations can also change the times they are broadcasting.

Maybe they did take the best user friendly approach but didn't implement it correctly.

Who knows they could have forgot to have a station time setting for the timers and are using a last station viewed something like our single station approach but the station changes.

They should have had it monitor the stations clock for the first station's timer when it is turned off or had another threaded process monitor the clock for that timer.

Once the first timer completed then it would need to monitor the next timer's clock.

So it should actually be keeping two clocks one that is shown like it does and another hidden one for the timers.

I also hope the fix the bug where if you are tuned to a station with a incorrect clock that all of the listings in the guide are based off of that clock.

The fix for now is you need to change the channel to a station with the correct time or use the browse for each station.

 

[JMS2008]

Check Your Visa Bill

I bought a DTVPal on-line for $34.46 with shipping & tax (minus $40 coupon). Then got a DishNetwork statement 2 days after getting the box which looked like I was signed up for dish network and was charged $74.46. Called customer service and was shuttled thru 5 different people who all said I had NOT provided a coupon (I did) and that I was charged $74.46. While on numerous holds I checked my on-line Visa statement. Dishnetwork charged me $34.46, $34.46, $34.46, $74.46 - yes charged 3 times at $34.46 and once at $74.46. 3 days after that they credited the 1st 3 $34.46 charges but left the $74.46. I finally got tentative agreement that they will credit me $40 - will see - it has not shown on my visa statement yet ...
Check your actual credit card bill - DishNetwork may charge you more than what you agreed to pay!

 

[TalkingRat]

If there are coupons remaining at the end (OTA only), we can count on mid-July for the last coupon expiration, assuming a fast 2 weeks processing time.

 

[navychop]

Yes, they are going faster than I expected. I really suspect some folks won't really understand until their analog TV stops working. They they'll learn and want a coupon or two. And there may not be any left.

Assuming there are, I guess that "cliff" might hold off until July. But this converter box matter may set a record for the shortest sales lifespan of any consumer product.

 

[noremac]

18 months? that's only true if the average price on an ATSC set drops dramatically. You know something the rest of us don't?

I thought it was common knowledge that NTSC-only sets are no longer being produced or sold per FCC rules. The only purpose of these CECB's is to work with legacy TV's. I suspect there will be a last-minute flurry of purchasing next Feb when all the procrastinators and hermits discover the tee vee no longer works, but basically, that's it. My 18 month guess allowed for a few six sigma types to come around

 

[A guy who read the manual]

More interesting timer test results

Well, my day off from DTVPal testing on Friday got extended over the weekend.

I did get my 16 ft. RG-59 antenna cable (indoors) replaced with a 22 ft. RG-6 cable, and got a signal strength gain of about 5 on all channels. I'm going to replace the splitter next and see if that will improve things further.

Now, about the timer tests I performed yesterday and today:

A guy who read the manual,

Test
Have you tested setting multiple timers all to a channel that does shift
Timer 1 - 29.2 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 1
After Timer 1 fires do you get results like this after the shift?
Where it changed the channel only for timer 1
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 29.2 timer for Mon-Fri, 9:29pm CDT

Possible Result 2
That or do you get results like this after the shift?
Where it changed both channels for the timers
Timer 1 - 23.1 timer for Mon-Fri, 8:59pm CDT
Timer 2 - 23.1 timer for Mon-Fri, 9:29pm CDT

Hmm. . . Interesting question.

The timers do not shift immediately after they have been triggered, only after some bug triggers an unnecessary extra download of Guide data (usually complete with the progress bar screen).

So the first part of the answer is that you would get neither result after the first timer was triggered; both would still say 29.1. But if I force a shift error after the first timer has triggered, then look to see what has shifted, I'm not sure which result I would get. I'll have to test it and get back to you.

On the other hand, here's a test where I could predict the results:

if I first set both those timers to 29.1, then forced a shift before either one had triggered, they'd BOTH switch to 23.1. Then, after the earlier one had triggered, if I forced a shift yet again, the previously triggered 23.1 would shift again to 9.1, [STRIKE]but the other 23.1 timer (that hadn't been triggered yet) would stay at 23.1.[/STRIKE] (The no-additional-shifts-until-after-being-triggered rule.)

I had to strike part of what I said above, because apparently if ONE timer is triggered or edited, it makes EVERY timer in the list "shiftable" again. More details follow.

Yesterday morning, I set up this test--

Timer 1: 7/14 29.2 WFTC Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/14 29.2 WFTC Mon-Fri AUTO (11:00am - 11:10am)
(Timers 3-5 were blank, and would remain so throughout the test.)

The timer worked properly (if turning on with a 2:00 countdown, switching channels at 0:00, and then staying on after the duration is over, is considered proper behavior), then at 10:20am, the timers looked like this:

Timer 1: 7/14 29.2 WFTC Mon-Fri AUTO (11:00am - 11:10am)
Timer 2: 7/15 29.2 WFTC Mon-Fri AUTO (10:05am - 10:15am)

Note that channel numbers did not change, but the timers changed their order because the DTVPal keeps them sorted in the order that they will be triggered.

Then I forced the timer bug to happen. [Note to readers: Remember, this bug often happens at my location without being "forced." Others have trouble reproducing it, and I think that is related to the way PSIP and/or TV Guide data is being broadcast (or not) in their locations, and/or due to better signal strength where they are.

When it happens to me without being "forced," there is a tip off that it MAY have happened before I check the timer list to find out: If the DTVPal downloads PSIP Guide data when it is turned on, complete with the progress bar screen, timer channels are likely to be altered. When the DTVPal turns on without going through the download process, the timers seem to be unaltered.

When the bug has had its effect, I don't know if the timer channels were shifted while the DTVPal was off, or if it happened at the moment it is turned on, but SOMETHING happens during the time the the DTVPal is off that sets up the conditions that make BOTH things happen (causing complete reload of PSIP Guide data AND shifting timer channels) IT MAY BE AS SIMPLE AS SOME BAD PSIP CAUSING THE DTVPal TO RESET ITS CLOCK that starts off the whole chain of events.

Also remember, certain channels shift to other channels within timers, and with other channels, the timers disappear after the shift. I found that this behavior is completely predictable, depending on what channel the timer is set for ( link ).]

The result of forcing the bug to happen (by going in and out of TV Guide mode, complete with PSIP Guide data re-downloaded), was that the timers looked like this:

Timer 1: 7/14 23.1-W WUCW Mon-Fri AUTO (11:00am - 11:10am)
Timer 2: 7/15 23.1-W WUCW Mon-Fri AUTO (10:05am - 10:15am)

(The channel shift happened in both timers, from 29.2 to 23.1.)

Then, I turned the DTVPal off again and waited for the 11:00-11:10am timer. It came "on" 3 minutes late, at 11:03am, without any countdown. I say "on" in quotes, because the light on the front of the DTVPal was NOT on. From what I've observed in the past, I expected that no countdown appearance while turning on meant it would turn itself "off" also, probably at 11:03 (I assumed the DTVPal clock was probably slow by 3 minutes, but I didn't want to disturb the timer operation by checking). Well, the DTVPal did go "off" by itself (screen went black, light still off), but after only about 4 minutes, at 11:07! I waited until 11:20 (the picture stayed dark) to see if there would be any more activity before turning the DTVPal back on.

I guess we learn from this that timers that have been "shifted" by the bug will probably still be triggered at (what they think is) the correct time (at least those timers that still appear in the timer list), but they may sometimes (if not always) behave strangely. However, I think some sort of bug or clock reset may have hit again somehow in the middle of the timer's duration, and that's what caused the screen to go dark early.

When turned back on, the DTVPal did its PSIP Guide reloading, which usually means the bug has hit again. This was one of those times when the download progress bar got stuck, exactly in the middle, as I'd seen a few times before. I had to press Select to cancel the rest of the download and found I had PSIP guide data for only channels 2 & 23. I don't know why the progress bar even got halfway when it had collected data for only 2 of 10 stations. Maybe it had collected more, but some data was corrupted somehow and not entered into the Guide.

I found the DTVPal's clock was now 3 minutes fast, not slow. The timer had a 10 minute duration. If the clock was 3 minutes slow when it turned on, and then the clock changed to 3 minutes fast in the middle of the timer duration, that would explain the 10 minute duration being shortened to 4 minutes.

The timers appeared this way:

Timer 1: 7/15 23.1-W WUCW Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/15 23.1-W WUCW Mon-Fri AUTO (11:00am - 11:10am)

Once again, timers were resorted into the order that they will be triggered. And, as always, the triggering itself did not cause a channel shift. However, it has set up an interesting situation: The 10:05am timer has been shifted, but has NOT been triggered after the shift (only before the shift). The 11:00 timer was also shifted, but then was triggered after the shift (although the triggering behaved oddly, it did occur), which "reset" the next trigger from 7/14 to 7/15.

If the patterns I've observed before hold up now, I'd expect the 10:05am timer is NOT shiftable at this point, because it has already been shifted, but the 11:00 timer IS shiftable because of the "reset" after it was triggered.

So, I just have to "force the bug" one more time to see the results. . .

This time, the download progress bar made it all the way, and I had almost full PSIP Guide data, except on 11.3 (discontinued subchannel), and 45.1 (weak channel with my current antenna orientation).

Now the timers appeared this way:

Timer 1: 7/15 9.1-W KMSP Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/15 9.1-W KMSP Mon-Fri AUTO (11:00am - 11:10am)

Well, both channels shifted again, which surprised me. I'd have guessed only the 11:00am timer could shift. But maybe that extra clock reset that happened during the 11:00am timer duration, and/or that extra PSIP Guide download when I turned the DTVPal on afterward, caused the 10:05 timer to be "shiftable" again also. Or maybe triggering ONE timer (and the resorting that follows?) makes ALL timers "shiftable." (I thought I'd checked that out before, but perhaps not.)

I left the timers set and watched their behavior again this morning.

When I turned the DTVPal on this morning, it did its complete PSIP Guide data download. The timer channels were still set to 9.1 (no additional shift, as expected, since they had both been shifted yesterday after the later one had been triggered). The clock was now set accurately, within a minute of the correct time or better.

The timer worked on schedule, picture from 9.1 appearing at 10:05am, once again WITHOUT a countdown, and WITHOUT the green light turning on. It also turned OFF (picture went dark) BY ITSELF at 10:15am (end of duration). It's looking like this "special" timer behavior may always happen when a shifted channel is left sitting in the timer, and is not edited before it is triggered.

When I turned the DTVPal on this time, at 10:20am, between the 10:05am and 11:00am timer triggerings, it did NOT do the full PSIP Guide download. This reinforces my impression that yesterday a "bug event" happened during the 11:00-11:10am timer duration, which reset the DTVPal clock from 3 minutes slow to 3 minutes fast (in effect shortening the 10 min duration to 4 min), and also forced a full PSIP Guide download when I turned the unit on afterward.

Now the timers appeared this way:

Timer 1: 7/15 9.1-W KMSP Mon-Fri AUTO (11:00am - 11:10am)
Timer 2: 7/16 9.1-W KMSP Mon-Fri AUTO (10:05am - 10:15am)

Once again, resorted after the triggering, but not shifted again from the triggering itself.

Then, after forcing a shift, the timers were like this:

Timer 1: 7/15 2.1 TPT 2 Mon-Fri AUTO (11:00am - 11:10am)
Timer 2: 7/16 2.1 TPT 2 Mon-Fri AUTO (10:05am - 10:15am)

Since there were no late on or early off issues during the first timer's operation today (unlike the second timer yesterday), this seems to be good evidence that triggering one timer is all that's needed to make ALL timers "shiftable" again.

Just to prove again that re-shifting wouldn't happen without a timer triggering first, I tried to force a shift again. The result:

Timer 1: 7/15 2.1 TPT 2 Mon-Fri AUTO (11:00am - 11:10am)
Timer 2: 7/16 2.1 TPT 2 Mon-Fri AUTO (10:05am - 10:15am)

(No change.)

I turned the DTVPal off and waited for the 11:00am triggering.

The timer worked on schedule, picture from 2.1 appearing at 11:00am, once again without a countdown, and without the green light turning on. And again it turned off (picture went dark) by itself at the end of the duration (11:10am). This "special" timer behavior has now happened for every timer triggered with a "shifted" channel left sitting in the timer. The only time it operated with the countdown timer 2:00 ahead, and stayed on after the duration, was for the first timer yesterday, before any channel shifting had taken place.

About 11:15am, after the later timer was finished, I turned the DTVPal on again. It did not do the full PSIP Guide download. Its clock was still set correctly.

By the way, as with all of these "special" timer triggerings, when I turned it back on, it was always tuned to the channel I'd been watching before turning the DTVPal off, NOT to the channel that the timer had just switched it to.

Timers looked like this:

Timer 1: 7/16 2.1 TPT 2 Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/16 2.1 TPT 2 Mon-Fri AUTO (11:00am - 11:10am)

Once again, resorted after the triggering, but not shifted again from the triggering itself.

And I forced another shift, with this result:

Timer 1: 7/16 45.1 KSTC Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/16 45.1 KSTC Mon-Fri AUTO (11:00am - 11:10am)

. . .Demonstrating again that triggering of one timer is enough to make all timers shiftable again.

And I forced another shift, with this result:

Timer 1: 7/16 45.1 KSTC Mon-Fri AUTO (10:05am - 10:15am)
Timer 2: 7/16 45.1 KSTC Mon-Fri AUTO (11:00am - 11:10am)

(No change.) . . .Demonstrating again that a shifted timer can't be shifted again unless one timer in the list is triggered first (or one timer in the list is edited first).

Just to prove that parenthetical point, that editing one timer may be enough to make both shiftable again, I edited the 10:05am timer by changing it to 10:30am. Note this did not change the order or resort the timers.

Timer 1: 7/16 45.1 KSTC Mon-Fri AUTO (10:30am - 10:40am)
Timer 2: 7/16 45.1 KSTC Mon-Fri AUTO (11:00am - 11:10am)

Then I forced another shift, with this result:

No Timers Set

This was a channel "shift," just like all the others, except that the channel index was finally "out-of-range." 45.1 has index 0016, which was doubled to 0032 by the shift, and with only 24 subchannels (0000-0023) in the DTVPal Channel List, 0032 is non-existent. Since both timers shifted and disappeared, this confirms that editing one timer makes both shiftable, even if the timers did not have to be resorted as a result of the editing.

Now the question is: Are the timers truly deleted, or are there "ghost timers" still sitting in the DTVPal? I'll keep an eye on it off and on over the next 24 hours, but since these "ghost timers" may come on without turning on the DTVPal light, any odd behavior may be hard to detect.

Tomorrow at 10:30am and 11:00am, I'll watch or record the output of the DTVPal to see if it puts out any picture.