or Connect
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!
New Posts  All Forums:Forum Nav:

The Official AVS Dish DTVPal DVR Topic! - Page 545

post #16321 of 18096
Quote:
Originally Posted by schultdw View Post

Quote:
Originally Posted by JHBrandt View Post

Multiple users have reported the identical drift of 8 sec/day, or 1 sec every 3 hours, for an unsynchronized Pal clock. It sounds like the internal clock is very precise but not very accurately calibrated - it's always fast by just about .01%. Probably another firmware bug rolleyes.gif

No. Just hardware.

8 seconds day per day works out to a bit less than 100ppm. Which is a not uncommon accuracy specification for your run of the mill quartz crystals. While you might expect more variation in the +/-100ppm range, I wouldn't. One thing that could happen is that after manufacturing a batch of crystals the manufacturer will run a test on accuracy. Typically a bunch will get pulled out and thrown in the +/-20ppm bin or other more precise bins. So instead of a nice uniform (or normal) distribution over +/-100ppm, there is a big hole in the middle.

Yes, 100 ppm = .01%. But I'd think the next more accurate "bin" would be +/- 50 ppm at worst. If Echostar bought +/- 100 ppm crystals for the Pal, we should see a range of inaccuracies from 4 to 8 seconds per day (because every crystal would be at least 50 ppm off but no more than 100 ppm off), and there'd be just as many slow clocks as fast ones. But hasn't everyone who's measured their Pal's clock found it to be just about 8 secs/day fast?
post #16322 of 18096
Do you know for sure there is a crystal in there -- they could be just using the A/C line frequency for the clock. Even if there is a quartz oscillator, devices like the Pal DVR, that were designed around using a periodic external time source to keep the clock accurate, generally don't devote a lot of design effort to the clock circuit. If the assumption is that the clock will be refreshed periodically by an external source, then they are only concerned with keeping it accurate to a couple seconds between refresh periods.
post #16323 of 18096
Quote:
Originally Posted by JHBrandt View Post

But hasn't everyone who's measured their Pal's clock found it to be just about 8 secs/day fast?
Yes.
post #16324 of 18096
Quote:
Originally Posted by WillN937 View Post

My experience is that you can change channel, time and duration with no problem.
You can change the channel, but if you change the start time, the duration, or the repetition schedule, the event timer gets converted to a manual timer.  If you can't find an existing guide entry with the right date, start time, and duration, you'll end up with a manual timer, so you might as well
Quote:
Just create a manual timer.
in the first place.  (If you entered it originally with the wrong repetition, you can delete it and reenter it from scratch and still have an event timer.)

Quote:
Originally Posted by JHBrandt View Post

In DFW, on 6/12/2009 KTVT went back to their old analog frequency, RF 11, from their pre-transition digital assignment of RF 19. But VHF reception was so bad they quickly got permission from the FCC to move back to RF 19. They simulcasted on VHF and UHF until last November, when they finally stopped the VHF transmission for good.

Did your area have a similar experience?
Yes, with one major difference: WLS's original digital channel was 52, which was out-of-core after transition.  They apparently hadn't minded using an out-of-core channel because they intended all along to use their legacy analog channel for ATSC after the transition date.  Thus, when VHF proved disappointing, they couldn't return to the same pre-transition digital channel.

So on transition day, RF52 went dark and RF7 went digital, and the result was the same as KTVT's and as those for a number of other ABC O&O's that had been so enamored of clinging to RF7.  RF44 was WSNS's old analog channel (their digital channel is 45), so WLS started simulcasting on RF7 and RF44, and RF7 will go dark this coming Monday.  I wouldn't care one way or the other except that the room where I need to use the PAL DVR has no connection to the roof antenna, and an indoor antenna there gets RF7 so much more reliably than RF44, despite RF44's recent power increase.  Thus, on my DVR, RF44 sticks, pixelates, and breaks up while RF7 comes through smoothly.

Obviously Disney isn't going to change its plans to accommodate me, nor are they going to pay for the purchase and installation of a second roof antenna so that my DVR can receive RF44 better.  Thus, I'm left with my sighs of disappointment.
Edited by dattier - 3/15/13 at 10:34am
post #16325 of 18096
An interesting quirk!

I have 3 units. One of the older ones is currently out of service. I'll call that one unit #1. Unit #1 and unit #2 are both a little over 3 years old, unit # 3 is less than one month old. As the clocks drift I would manually reset them. No problems resetting #1 and #3. However whenever I reset #2 the clock resets 2 minutes later than the time I set. IE if I set it for 10:31 AM the clock will set at 10:33 AM. The only way for me to get the correct time is to input the time 2 minutes earlier than the correct time. I have tried resetting at diffent times, and even after going through the whole installation wizard get the same results.
post #16326 of 18096
Quote:
Originally Posted by anant View Post

An interesting quirk!

I have 3 units. One of the older ones is currently out of service. I'll call that one unit #1. Unit #1 and unit #2 are both a little over 3 years old, unit # 3 is less than one month old. As the clocks drift I would manually reset them. No problems resetting #1 and #3. However whenever I reset #2 the clock resets 2 minutes later than the time I set. IE if I set it for 10:31 AM the clock will set at 10:33 AM. The only way for me to get the correct time is to input the time 2 minutes earlier than the correct time. I have tried resetting at diffent times, and even after going through the whole installation wizard get the same results.
I would do factory reset to default ...
post #16327 of 18096
P Smith, did you receive a PM from me earlier this week? I haven't received a response.

I was asking whether or not you still do repairs on these, the cost, and details to get them to you. I have one in a loop.

If you still do this kind of work, could you share that information with us?
post #16328 of 18096
Quote:
Originally Posted by Kelson View Post

Do you know for sure there is a crystal in there -- they could be just using the A/C line frequency for the clock. Even if there is a quartz oscillator, devices like the Pal DVR, that were designed around using a periodic external time source to keep the clock accurate, generally don't devote a lot of design effort to the clock circuit. If the assumption is that the clock will be refreshed periodically by an external source, then they are only concerned with keeping it accurate to a couple seconds between refresh periods.

I've tried several hypotheses; nothing seems to make sense.

If they're using a crystal (I assume there's a crystal in there to clock the CPU, but there's no guarantee they're keeping time by it), the error should vary from one Pal to the next.

If they're using the AC power line for the clock, it should be accurate. Power companies constantly adjust their line frequencies to stay in sync with each other, so over the long term, it's more accurate than a crystal.

If they're counting frames from the composite (NTSC) output, it should be slow by 8 secs/day, unless they apply a correction.

Unless ... maybe they're using the AC power line, but (incorrectly) applying the correction for NTSC! That could be it!!

That sounds like the kind of mistake those silly 50 Hz Brits would make. wink.gif If so, it's like I said - another firmware bug. Of course, under "normal" circumstances no one would notice because the clock would periodically be resynced to either TVGoS or the PSIP average.
Edited by JHBrandt - 3/15/13 at 1:16pm
post #16329 of 18096
Quote:
Originally Posted by JHBrandt View Post

If so, it's like I said - another firmware bug.
Or, as I said, the clock circuit was never designed for long-term accuracy because it was assumed that the clock would be periodically reset with the accurate time at least once per day.
post #16330 of 18096
Quote:
Originally Posted by Kelson View Post

... it was assumed that the clock would be periodically reset with the accurate time at least once per day.
Regardless of what accounts for the Pal's clock drift, I'm sure that's true. And I probably don't have to remind anyone what happens when you assume wink.gif
post #16331 of 18096
Quote:
Originally Posted by JHBrandt View Post

If they're using a crystal (I assume there's a crystal in there to clock the CPU, but there's no guarantee they're keeping time by it), the error should vary from one Pal to the next.

Looking at the board image I see 5 obvious crystal packages.

One other thing that I didn't mention is that crystal operating frequency is sensitive to capacitive loading. It is possible that they used a nice +/-20ppm crystal but loaded it so that it is offset. Now if you can figure out just which one is used for time keeping and tweak the capacitive load, you could get it to keep better time.
post #16332 of 18096
Quote:
Originally Posted by schultdw View Post

Quote:
Originally Posted by JHBrandt View Post

If they're using a crystal (I assume there's a crystal in there to clock the CPU, but there's no guarantee they're keeping time by it), the error should vary from one Pal to the next.

Looking at the board image I see 5 obvious crystal packages.

One other thing that I didn't mention is that crystal operating frequency is sensitive to capacitive loading. It is possible that they used a nice +/-20ppm crystal but loaded it so that it is offset. Now if you can figure out just which one is used for time keeping and tweak the capacitive load, you could get it to keep better time.

 

If anyone figures out which crystal is the clock, here's a Magnavox tinkerer's post on adding a capacitor to make the Mag's clock run more true... might help a DIY tinkerer get started on this unit?

post #16333 of 18096
Quote:
Originally Posted by wiscojim View Post

P Smith, did you receive a PM from me earlier this week? I haven't received a response.

I was asking whether or not you still do repairs on these, the cost, and details to get them to you. I have one in a loop.

If you still do this kind of work, could you share that information with us?
I did answer same day...to your email addy; all process outlined there.
post #16334 of 18096
Quote:
Originally Posted by P Smith View Post

I did answer same day...to your email addy; all process outlined there.
Thank you. Apparently it didn't make it through, nothing in my gmail inbox from you. Could you please try to resend the information via PM?
post #16335 of 18096
Quote:
Originally Posted by wajo View Post

If anyone figures out which crystal is the clock, here's a Magnavox tinkerer's post on adding a capacitor to make the Mag's clock run more true... might help a DIY tinkerer get started on this unit?
Next one to CPU's can. Per se , there is no separate xtal for asked purpose. Time derived from reference clock of the CPU.
post #16336 of 18096
Quote:
Originally Posted by trp2525 View Post

I just did the two back-to-back soft resets to get re-synced with the "weighted mean" of PSIP times in my area. It's running 10 seconds slow but I can live with that if it remains relatively consistent. Gaining 8 seconds/day when using the DTVPal DVR's internal clock wasn't consistent/accurate enough for me.
I just did the two soft resets because the clock kept running fast when set manually. Now let's see if it stabilizes.
post #16337 of 18096
Since TVGOS has disappeared in the Washington, DC area, it would be good to try to convince the local broadcasters to expand their PSIP listings beyond 12 hours.

Has anyone put together a list of individuals (preferably engineers) in Washington who can be contacted? I may be naive, but maybe they will take some action if they receive enough emails.
post #16338 of 18096
Quote:
Originally Posted by golinux View Post

I just did the two soft resets because the clock kept running fast when set manually. Now let's see if it stabilizes.
I did that too, but in my area the mean PSIP time is 45 seconds slow,
so I went back to setting the clock manually. frown.gif
post #16339 of 18096
Quote:
Originally Posted by Chuck44 View Post

I did that too, but in my area the mean PSIP time is 45 seconds slow,
so I went back to setting the clock manually. frown.gif

You would think that all of these TV stations would at least get their PSIP time correct seeing that the digital transition took place 4 years ago in 2009! I guess not many people pay attention to it or use it like we do with our OTA DVRs.

My DVRs are running 4 seconds fast right now being synced up with PSIP. I consider myself lucky that it is that close with the weighted mean of PSIP times in my area. That's much better than the 8-seconds-per-day drift (fast) that I had when I was setting the clock manually.
post #16340 of 18096
Quote:
Originally Posted by Chuck44 View Post

I did that too, but in my area the mean PSIP time is 45 seconds slow,
so I went back to setting the clock manually. frown.gif

Try contacting the stations, letting them know their times are off and that you need accurate times for your DVR clock. I did for the four serious drifters in my list; I received pretty quick replies from two of them and saw adjustments of all four times within a few days. (The general manager of one of the stations told me their equipment checked only once every 90 days eek.gif but would now do so every 24 hours.)
post #16341 of 18096
Has anyone ever contected Direct TV and found out who made the PALDVR for them? If we could find that out perhaps we could bypass Direct TV and go right to the manufacturer for support for our units.
post #16342 of 18096
Quote:
Originally Posted by LenL View Post

Has anyone ever contected Direct TV and found out who made the PALDVR for them? If we could find that out perhaps we could bypass Direct TV and go right to the manufacturer for support for our units.

Actually it was Dish, not DirecTV, who sold the DTVPal DVRs. wink.gif

They were made by Echostar, which was spun off from Dish some time ago to manufacture consumer-end equipment. Echostar also made the identical (except for branding) Channel Master version (the CM-7000 Pal).

Unfortunately, so far we've had no more luck with Echostar than we've had with Dish or CM. Echostar sees their "customers" as other businesses (chiefly Dish) and really isn't set up to deal with end users.
post #16343 of 18096
The DVR has been abandoned by echostar and dish because initial idea: to sell a content by OTA PayTV and Internet (see that smart card underneath) went south ...
post #16344 of 18096
That DTVPal DVR's price on eBay keeps rising every day. It's now $389.99 with 4 available!!! eek.gif
post #16345 of 18096
Time to assemble my test DVR and sell it ... nay, I still need it to help answering questions and play with a drive ...
post #16346 of 18096
If anyone needs a replacement or extra remote for their Dish DTVPal DVR or Channel Master CM-7000PAL DVR there is an excellent deal available on eBay right now. There is a seller (alwaysbuyalot) who is selling brand-new Dish 20.1 Learning Remotes for only $6.00 including FREE shipping. There are currently 193 available.

As has been posted in this thread in the past this remote is just about an exact replacement for the original remote with just a few minor button differences. The seller states that this remote also works with the Dish 222, 311, 522, 622, 625, 722 "and more." A side-by-side comparison picture of the two remotes is shown here with the original remote on the left and the replacement remote on the right.
post #16347 of 18096
I have one of these remotes and it works perfectly. Since I work it a LOT, I think I'll get a couple of spares. Thanks.
post #16348 of 18096
Is there a button on the 20.1 remote that will operate Closed Captions? I use that one often.
post #16349 of 18096
SWAP=CC
PIP=Sysinfo
Postion=Alt audio
post #16350 of 18096
Here's a link to the manual for the Dish Remote Control Model 21. It replaced the Dish Remote Control Model 20 that is selling on eBay for $6 but the manual should be about the same. Dish apparently, in their infinite wisdom, removes the manuals for older Dish products from their website just when someone would probably need them the most because they can no longer find their original manual! mad.gif
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: HDTV Recorders
AVS › AVS Forum › HDTV › HDTV Recorders › The Official AVS Dish DTVPal DVR Topic!