I set the clock on my Mark2a an when switching to that visualization, the clock was not kept right. Does the clock only work when powered on? Doesn't the Mark2a have an internal battery to keep the clock current?

Please let me know if this is just a bug in the 2.0 Beta11 software.

Thanks,

Jason Sarich

Make sure to set your time zone first, then set your clock. Does the problem go away?

Check this thread. You supercap may be dead or dying.

if you're adventurous, you could test it yourself with a multimeter. Here is a picture of the cap.

As Hugo said:

"check the voltage between the top of the cap and the bottom of it (the other pin is just visible on the other side of the cap). It should be around 3.5v-ish. If it's dead, it'll read <0.5v when the empeg is not powered."

BUT, do what Tony said and make sure it's not software.

Any idea how long the cap will keep the clock running after 12V power to the Empeg is removed?

The clock is supposed to last several days without power.

Thanks Tony

So it's closer to the 1 hour of a typical VCR than the >1 year of a typical watch.

Barry

Tony,

When you say "without power" does that mean with the unit sitting on my floor? Or does a "car off" situation count as "without power"?

I think my clock is constantly off with 2.0b11 in my 95 M3, but I never bothered to re-set it.. I just know it hasn't gone more than a few hours without power, and it seems to always change how much it's off by.

- reid

Or does a "car off" situation count as "without power"?

Good question. It drops out of standby after a few minutes... If you left the player in the car for a week, in complete-power-off-mode would the cap still charge from the constant power wire? I don't know.

Hugo?

I wonder why they didn't just use a battery ?

I wonder why they didn't just use a battery ?

Because batteries have to be replaced, requiring opening the player. And for the most common usage of the player, the capacitor should be more than plenty.

Keep in mind that if your player's clock isn't keeping time, there's a malfunction. It's got nothing to do with their basic design decisions. Personally, I'm glad there's no battery inside my player that I have to worry about.

The RTC battey gets recharged in "car off but permanent 12v still supplied" situation, so that should last indefinitely... in theory!

Hugo

or until the car battery dies.

Hugo,

Has anyone else seen the case where the displayed time falls 20 minutes behind the RTC, typically overnight while the Empeg is on. A power cycle will recover the displayed time to the correct RTC time. This has happened to my Mk2a three or four times over the last month (most recently last night!) for no apparent reason.

Also should I expect to be able to set the time zone to something other than US-Alaska? Changes to the time zone parameter don't seem to be saved.

I am currently running beta 11 and Hijack though this has been the case with prior versions of the software.

Thanks,

Lynn

It's a very low drain, under 5mA I believe. 0mA drain if you take it out of the car

Hugo

Hmm, it may well not sync up - possibly we need to resync every now & then. Sounds like the linux timer isn't being very accurate, though 20 minutes overnight seems pretty extreme!

Hugo

It has been 20 minutes each time (one minute resolution) so an occasional resync seems like a simple solution. I see it more as a step error of lost time than a timer accuracy issue. The sample is too small to be sure but most of the time it is right on then occasionally I will find it off by this same amount.

I don't think I would ever have seen it if I hadn't left the Empeg running overnight.

Any comments on the time zone question?

Lynn

I see it more as a step error of lost time than a timer accuracy issue. The sample is too small to be sure but most of the time it is right on then occasionally I will find it off by this same amount.

That is really quite interesting, especially as, if the system timer ever stops for twenty minutes, or lurches backwards, not only will input stop working, but also transient info's scroll timer will fail... Hmm...

Peter

So are we to infer that clock drift could be causing the random lockups we might have been seeing recently?

So are we to infer that clock drift could be causing the random lockups we might have been seeing recently?

Clock drift won't cause lockups. Clock lurch might. Of course, any clock lurch is a bug.

Peter

Ah, okay... Well I'm glad we at least have a *possible* root cause for the lockups. I don't really keep track of or use my clock, so mine could be lurching around this way or that and I wouldn't notice. Since the lockups were never happening in 1.03, can you think of any clock-related changes that might have happened since then?

Clock lurch and input lockups and a stopped transient scroller could all have a common cause. Perhaps interrupts are being masked and not being correctly unmasked somewhere under certain conditions? Or the player is waiting for a short-term event with interrupts masked and the event occasionally actually takes 20 minutes to happen? (I'm thinking of things like off-chip communication here.)

As I understand it, having asked Peter exactly the same question, if interrupts were masked, then sound output wouldn't get serviced. In most of these lockups, it is.

Roger, have you seen this thread about my lockup experience yet?

Yes.

In reply to:

---

if interrupts were masked, then sound output wouldn't get serviced

---

Yes - I realised this as soon as I logged off yesterday .

I guess we need to establish whether the system clock is actually stopping during the lockup (see thread in Technical that suggests using Hijack to get output when player is locked up).

Does the player application get system time regularly, or does it get it once then do its own timekeeping? I ask because if it's the latter, then it's obvious that the UI thread is blocked on something; if the former, then there's something odd going on in the kernel.

If the linux system ticker stops, a lot goes wrong - I seem to remember, anyway. Any timed/regular calls stop within kernel, which is a bad thing. Oh, and processes can't schedule themselves unless something else blocks.

I don't think the system ticker is stopping, for that very reason.

Hugo