Is a Gray code counter more energy efficient?

The implementation of divide-by-16/17 is relatively trivial, and a Bresenham application can dither so, and calibrate any reasonably-close frequency to a standard. Pulse swallowing is not hard, and the result won't have to exceed a millisecond.

The item in question, though, has a sweep second hand with NO jerky motion, and a minute hand that never points at fractional minutes... a catch-up correction would be jarring to the user (and it's a pricey item, this watch). One would want the calibration correction high up the divider chain, to manage the smooth second hand.

The real trick is to divide by the right amount when averaged over a day so that the long term accuracy is around 1ppm but still subject to thermal drift. The effective divisor is fractional.

You don't just pick a single divisor you dither between a pair of them in such a way that it is virtually exact when averaged over a day.

You only need to represent fractional steps of N/32 to get 1ppm. Phase noise is a bit rubbish but you generally don't care in a timepiece.

That looks to me like 100% marketing BS. Anything that moves quickly

Fast spinning disk close to other non moving parts but with air in between. Boundary layers are invariably bad news friction wise.

You appear to be describing the Accutron watch. Is this what you are trying to duplicate? Why? Are you looking to actually build such a device?

As I said, you are making assumptions about relative power losses. I still don't know what the OP is trying to do, so it's pointless to speculate.

I'd risk suggesting that the Shannon entropy of either Gray code or plain-old binary is the same.

I suspect it's implementation-dependent because the Shannon entropy of Gray codes vs binary is the same. So d(entropy)/dt would also be the same.

The fact that there's state maintained might be a clue, but that would depend on how said state is represented.

I did find this:

I'm not sure that goes anywhere.

Oh, that's exactly the answer; the shift-register type counters (pseudorandom sequences) are clearly also worse than ripple counter, though their hardware implementation is attractively minimal.

I still think shift-register implementation of the phases necessary for a synchronous secondhand drive (electrostatic motor) is the likely winner for a low-power motor like that Accutron DNA product.

Continuing with the reverse-engineering thought experiment: The minute-hand 'tick' is the slowest clock required for that watch (with minutes/hours being gear-connected). A crystal with power-of-two division to minutes(rather than seconds) would be expected; nearest to the common 32768 Hz would be 30720 Hz. Digikey doesn't stock that particular value, though: it'd be a custom rock.

1/64th of one minute means the electrostatic motor might have 16 poles and four phases.

Sure, the charged cap stores 1/2 C V^2 joules.

But charging a cap through a switch and a resistor is 50% efficient. That turns 1/2 into 1.

You are not thinking. I see a lot of that.

The lowest power divider will be a ripple counter where each stage is clocked by the output of the previous stage. You can't just compare the mode of the counters, you also need to compare the implementation.

The crystal frequency is not important. As you say, custom frequencies can be obtained. However, I'm not sure of the cost. It seems frequencies around 32.768 kHz are very, very rare and I expect you need to buy a large number of units to lower the price of such a frequency.

[about Accutron DNA watch]

In the old days of AT-cut disks, that would be correct (off-spec units for TV colorburst made it very inexpensive to get 4 MHz rocks). The tuning-fork crystals at 32 kHz, though, are cut to rough frequency, then tuned by metal-plating the tines' ends. It'd be trivial to rescale, and yields are high because the plating is an easy-to-adjust trim (adding thickness to a ground-down quartz disk, is NOT easy).

But this is all academic, since you aren't actually building anything. I'm willing to bet it is far less power to run the digital circuit than to move the hands, so who cares what frequency is picked? 32.768 kHz is fine.

So, what's wrong with that? I'm analyzing, to learn something new.

I didn't say anything was wrong. It's just that you can't actually do a decent design since there are no constraints, no purpose. When you first posted, I thought you were trying to do something. In reality, none of the thoughts about the digital logic have any meaning, since we know nothing of the constraints. There's many, many ways to skin this cat, and which is lowest power depends on which are practical.

The real power consumption is in moving the second hand. I'm not sure how well you can minimize that. Is the second hand on the Accutron balanced? I think I posted about my $10 digital wall clock that gets 50% more days from the battery after adding a crude balance on the second hand.

I did a search for the term of this balance, but never came up with anything. The way virtually ever part of a clock has a specific term makes me think there is a term for this, but I've simply not found it.

The second hand is NOT stepping at 1 Hz, though; it's a synchronous electrostatic motor, so there's no benefit to 'dividing down' to one-per-second, rather one can just factor any 2^N precursor of the one minute clock, and use a number of poles and phases for the drive to accomplish the smooth sweep hand motion.

Two pole pairs and 60 Hz (60 cycles/sec) electricity makes for a 1800 RPM (30 rotations/sec) motor; the 'divide by two' was just done by having that many poles and two 60 Hz phases. No dividers.

32768 Hz is the normal watch crystal frequency.

It's 'normal' for a clock that does one step per second; there's no use for one-per-second increments for a multiphase motor with one minute per revolution. The one-minute hand is the only ticking item in this timepiece.

32737 Hz actually IS stocked; that might be useful in a pseudorandom sequence for 1 second where the 'countdown' isn't by binary division (flipflops).

Uh, how do you count down without using flipflops?

Shift register, gates determine the inshifted bit... there's latched bits (flipflops, if you will) but not 'toggle' control of them. The pseudorandom sequence generated only goes to all-ZERO outputs once per cycle, but cannot do all-ONE outputs without stalling. So, it cannot do divide-by-2^N, but at most divide-by-((2^N) -1).

Sorry, I have no idea what you are trying to say about this. So they use FFs. Glad we have that clear. I'm familiar with pseudo random sequences, but what advantage to they provide here?

It is not a general truth that the fact of calculating only one FF input with gates, means it will be lower power than other counters. As I've already explained, the binary ripple counter should have the lowest power consumption of any counter type, given that none of the inputs require logic and the transitions of FFs average 2N per clock cycle. It could be second to a gray coded counter (N FF transitions per clock cycle) if the impact on power of the FF outputs is much more significant than the logic gates themselves. But this ALWAYS depends on the details of the logic implementation. If you use boulders and donkeys for implementing FFs, all bets are off.

We do NOT have that clear; a CCD (like the shift-bits-out action in a camera sensor) also implements a shift register, without a true flip-flop. It takes clocking, and some kind of latch, but the static memory of a flip flop and the dynamic memory of a CCD are both suitable bit storage elements.

The dynamic RAM power utilization advantage over static RAM is the possible advantage.