Eureka Digital rate compensators for EM clocks

Hi Everybody,

As much as I love my EM clocks (Eureka, Bulle, and ATO), the rate variability is a bit of thorn in my side. Besides the inherent rate issues with each clock, external influences such as decaying battery voltage, temperature, and so forth make keeping the herd of clocks in sync a bit of a challenge. I have a couple of Bulle's that are glass domed and on shelves that don't permit the dome being removed without taking the clock off of the shelf, which I always find nerve racking.

So I've been developing a digitally controlled rate compensation system over the last several months. Of course, the devil is in the details and the project has taken far longer than I originally imagined. Nonetheless, I have an ATO keeping time within a 1 sec of true time (I'm using a GPS chip to source 'real time'). Its been running for a week now and I'm satisfied that all the bugs have been worked out. I'm going to apply it to one of the Bulle's next and finally to a Eureka. In principle, the controls methodology should work on each of the various types of clocks (but we shall see ...).

Anyways, I've always wondered why Brian Mumford stopped selling his controller many years ago. I've read theories that the profit margin just wasn't that great. But I suspect it was the customer support that really triggered his decision to stop selling them. Adjusting the controller to the clock is somewhat a time consuming process and in today's world of immediate expectations, I can see customers complaining that the controller wasn't just 'plug and play'.

I'm going to spin a PCB for my system since I have numerous clocks that I want to apply it to, which got me wondering if others would be interested in the controller. But I'm bit nervous about the ramifications that may come with doing so (something made Mr. Mumford decide to stop selling his).

Any insight into experiences with his product would be appreciated (such as 'it worked great', or 'I could never get it run just right and he got sick of me calling him all the time for help').

Thank you,

Peter

 

Hi Frank,

I does sound like I'm reinventing the wheel as I look at the features in your controller. I have basically the same list of features in my prototype. The one thing that was driving me nuts, though, was the tendency of the quartz oscillator to drift over time. I'm using a PIC and I can tweak the oscillator rate to a fairly good rate but I'm finding that the true value that is necessary for precise, long term time keeping is always somewhere between one of two discrete values. I've played around with modulating the oscillator tune value but never to my complete satisfaction.

So I started looking at a means to externally determine 'real time'. I first tried using the WWVB signal here in the US ( the 60 kHz so called 'atomic clock' signal). This worked ok but its signal is very weak in various parts of the US, especially on the East coast (where I am). Its the strongest at 3am and weakest during the day - very frustrating for development. And I didn't like the idea of not being able to sync with 'real time' at my choosing. I'm still not sure why the WWVB signal's range varies with the hours of the day, but it does. There are maps on the NIST website showing the signal as a function of time.

So, I switched over to using a GPS chip, which has worked out really well. I get a solid signal all the time and my clocks are staying within 1 sec for weeks on end. And I don't foresee any reason for them to ever get off. The downside is the cost. The cheapest GPS chips are around $15 and work ok most of the time. I settled on a $40 chip that is solid all them time and has lots of nice features built in to help keep the power consumption down.

I'm slowly applying the controller to different types of EM clocks. So far I'm running an ATO and Bulle with it. Next on the list is a Brillie. I've saved my Eureka's for last, as I have the least experience with them.

By the way, when you say 'low cost', could you give me an idea of a price? My material cost is around $70 now (mainly because of the GPS). Also, would you know what Brian used to sell his controller for?

Thanks for the reply to my original post and I look forward to future regulator discussions,

Peter

 

I had considered a WiFi approach to source the actual time but I decided against it for several reasons.

I personally have a desire to keep my old EM clocks as original as possible. To me, this meant that there can't be any power cords going to the clock. Power consumption of an EM clock in its original state is incredibly small (typically uA pulses ever 800ms which is why the clocks run so long a single D cell). As soon as one introduces an Arduino and WiFi, the current draw immediately jumps into the mA regime, which doesn't sound like much but it will run down a D cell in substantially shorter period than most EM clock owners would like.

Another reason, that you might have a hard time believing, is that I don't have a WiFi network in my house. In fact, I have limited internet (via a tethered phone) because I live in the nether regions of Vermont (we don't have cable TV service either). I'm sort of glad this sort of stuff hasn't gotten too close to me or my clocks

For a Nixie clock, I think the Arduino/Wifi solution is perfectly suited, but for an old timer in the backwoods that moderately embraces technology, I'm going to stick with the old fashioned GPS signal

Peter

 

The GPS chip I'm using draws 20 mA when its actively tracking the satellites, but only 15 uA when its in a sleep mode (it remembers where the satellites were last located for a quick wake up and resume tracking). So I wake up the chip once every 10 minutes, wait 15 seconds for it to relocate the satellites, ask it for the 'real time' to update my internal counters/timers, and then put it back to sleep. No doubt, it's consuming power, but my calculations show that I should be able to run at least 1 year on a D cell (zinc carbon) and over 2 years with an alkaline type.

 

Hi Frank,

Is the DCF77 signal always reliably there for your controller? I wish I could have used the WWVB here in the US instead of GPS, mainly because of power considerations. I just had too many issues receiving the signal during the day on the east coast. If I lived in central or western part of the US, the reception maps show that I wouldn't have had an issue.

Peter

 

Reception varies greatly between the 4 different chips I evaluated. All four have internal antenna's, which is generally considered inferior than a external antenna. Of course, the most expensive of the 4 chips has the best performance and has worked well inside my lab (which is right up against an adjacent steel structured building, which keeps the cheapest of the chips from working at all). Another aspect to be aware of when considering GPS chips is when they start reporting UTC time. The cheaper ones wait until they get at least 4 satellites for the position lock, which isn't necessary for time reporting. The better chips start reporting the UTC time as soon as they see one satellite, which is almost instantaneous.

Peter

 

Hi Frank,

I'm still experimenting with the length of my 'off' time from GPS. The clock follows the PIC's sense of time and if the PIC's time wanders too far from reality, then both the PIC and clock need to catch up (or slow down). I'm finding that some clocks (ATO) respond well to my controls and I can alter their rates fairly quickly. Other clocks (Bulle) are a bit sluggish to respond so I don't like the PIC getting too far from real time. I was hoping that I could run the GPS once a day for maximum power savings, but I'm not so sure if I'll be able to go that long. I'm still experimenting so we'll see.

As for the Bulles being slow to respond, I suspicious of the isochron spring as being the 'problem'. I think its doing a good job keeping the beat steady even with different pendulum amplitudes. I plan on disconnecting the spring on one of the Bulle's as an experiment to see if my theory is true or not. Ultimately, I don't want to tinker with the clock (like disconnecting isochron springs) so I've been tweaking the controls to work with the Bulle in its natural state.

Peter

 

Hi Eric and Frank,

I believe my control strategies are what Frank is describing. Basically, the power of the pulse has to be altered and it can be done in one of two ways. The voltage can be altered (I like to decrease it from a nominal voltage), or the pulse width of the mechanical switch is reduced using a transistor. I've been using the pulse width modulation approach because I like the benefit of opening the circuit electrically prior to the mechanical switch opening the circuit. Most wear on switches, relays, contactors, etc. occur during the opening phase where a slight arc is maintained until the gap is just too big to sustain the arc anymore. By opening the circuit via a transistor, the clocks contacts never see the wear of opening the circuit while 'live'. I don't have any data to make a claim that the contacts will last longer - just theorizing at this point. Maybe in five years, when some of my Bulle's run without any maintenance, I'll be able to claim the theory to be true.

As far as feedback, I originally watched (via an ADC) the BEMF of the coil to get a sense of the rate of the clock. This worked well on the ATO I started with but I didn't look far enough ahead with regard to Bulle's. On the ATO the coil is mechanically fixed (not swinging) so adding a discrete sense wire was easy. But on the Bulle, the coil is swinging and routing a discrete sense wire to that part of the circuit was impossible. And I didn't like adding a sense wire in general because I wanted the controller to be completely unobtrusive to the clock. So I switched the feedback over to watching the pulsed power drawn from the battery, which has worked equally as well. And because the controller is obviously in series between the clock and the battery, the signal information was on board already. So what I have now is completely unobtrusive to the clock (regardless of type).

I'm working on packaging the controller with a small battery holder at the moment (vs the breadboard prototypes I have running right now). I'm going to use NiMH batteries (which are rechargeable), so that when a micro-USB connection is made, it will automatically recharge the batteries. The micro-USB port was originally designed in as my debug/parameter tuning serial port, but I realized that it could be a 5V source for charging the batteries. In theory, I plug a mico-USB cable (from a cell phone charger or from a PC) once every 6 months, let it sit overnight, and the clock should have enough energy for another 6 months.

Peter