Author Topic: Slightly over the top central clock drive.  (Read 1429 times)

0 Members and 1 Guest are viewing this topic.

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Slightly over the top central clock drive.
« on: August 24, 2020, 02:38:56 pm »
Hi,

I've just bought two displays ("clocks") for a central clock system, you know the kind that was popular in schools and other facilities. They're supposed to be driven from a central clock giving a 24V DC pulse at the start of every minute, with the added twist that the polarity is flipped every time (ie. minute 1, a +ve DC pulse, minute 2 a -ve pulse, etc).

The simple idea is a Rπ with two GPIOs pulling two different transistors depending on even or odd minute, and running from NTP.  That's OK. Probably better than 90% of such systems in their heyday. (We still have one at work, though..)

Now, I've got a Meinberg GPS receiver, with 1PPS out. Obviously I want it to trigger the pulse, without being fuzzed by non-real-time control in a multi-user OS. (that the clock displays are mechanical and likely have significant delay from trig to movement, is beside the point!)

If I really want to do this the hardcore way, I'd do a /60 divider in logic circuits, top it off with a state storage that selects +/- and that would be it. That is all fine and dandy, certainly has a certain je ne sais pas to it, but there's a problem here, and it of course is that such a circuit can't in and of itself know when a new minute begins: It would, even if manually timed at startup, not be safe from leap seconds.

My current idea is to combine the two approaches;
  • The Rπ is responsible for knowing when we're in a window of say +/- 400ms from a minute start. It also remembers if it is time for a positive or negative pulse. It will be timed to the NTP server in the Meinberg. It will select polarity and enable the pulse from the Meinberg during the window around the full minute, but not decide further than that.
    (To keep things suitably vintage, part of me wants to use relays to do the enabling)
  • The Meinberg will still have final say over when to trigger, by a combination of opto-couplers and transistors.

So, how far out am I?  Has anyone done something similar? Suggestions? (The argument of diminishing returns is of course relevant, but the process in itself is interesting enough, IMNSHO.)

Offline Doctorandus_P

  • Super Contributor
  • ***
  • Posts: 3322
  • Country: nl
Re: Slightly over the top central clock drive.
« Reply #1 on: August 24, 2020, 10:39:22 pm »
Waot the heck is a rii?

I would use some kind of 50ct microcontroller and combine it with one of the 1000's H-bridge IC's such as used for controlling DC motors.

A chip like the ancient L298 has a terrible efficiency compared to more modern IC's, but it will be plenty for generating pulses for such a clock.
L298 is one of those chips that should have been obsolete long ago, but stubbornly refuses to completely die.

One annoying thing about it is that it looses a few volts when driving anything significant, and will get hot because of that, which needs a chunk of aluminimum, which makes it big.
Another is that it needs relatively many external components such as catch diodes.
But you can get a PCB with all the needed stuff on it for a few EUR.

 

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Re: Slightly over the top central clock drive.
« Reply #2 on: August 25, 2020, 06:14:34 am »
Waot the heck is a rii?

Raspberry Pi. But written like "R" and "π"


I would use some kind of 50ct microcontroller and combine it with one of the 1000's H-bridge IC's such as used for controlling DC motors.


That, while more along the je ne sais pas I was talking about with the logic /60 divider, won't solve the real time clock problem of knowing which second pulse from the Meinberg (which is present and a raison d' ètre for the project as such ) is in fact aligned with a new minute.

I was sort of alluding to it with my example of leap seconds; BIPM inserts those in UTC from time to time which so far makes for a few 61 second minutes having happened. The possibility of a 59 second minute of course also is there, but that has not happened, yet. 

A leap second -- in either direction -- would make the µC drive 1 second off, even with the Meinberg pulses bang on.


Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Slightly over the top central clock drive.
« Reply #3 on: August 25, 2020, 06:45:03 am »
Does your Meinberg receiver offer an DCF77 compatible pulse output? I had long time ago to do with them, and most of the receivers had that either standard or optionally. If so, it'd be a rather easy job to detect the 59th second pulse omission and the next second pulse would be exactly the correct second to generate the minute pulse.
For one particular purpose, I retrofitted such a DCF77 pulse generation to a Meinberg receiver that didn't have that output by reading the serial time code output and encoding this to DCF77. Afair, I used a small 8051 variant (an Atmel ,,,C2051 thingy with 1K or 2K and a D-type FF to achieve this.
Safety devices hinder evolution
 

Offline Berni

  • Super Contributor
  • ***
  • Posts: 4922
  • Country: si
Re: Slightly over the top central clock drive.
« Reply #4 on: August 25, 2020, 06:49:33 am »
Just find some sort of serial interface on your GPS receiver.

All GPS receivers know the exact date and time so it is just a matter of finding how it can output the time and date and run that into an arduino. If you want to retain as much of the precision as possible you could possibly have the arduino generate a gate signal that uses a logic AND to let trough just 1 of those pps pulses every full minute.

If your GPS reciever has no easy way of getting time from it, then you can always add any little cheep 20x20mm GPS reciever module to barf out the GPS time over UART in standard NMEA strings.
 

Offline Circlotron

  • Super Contributor
  • ***
  • Posts: 3168
  • Country: au
Re: Slightly over the top central clock drive.
« Reply #5 on: August 25, 2020, 06:58:14 am »
If so, it'd be a rather easy job to detect the 59th second pulse omission and the next second pulse would be exactly the correct second to generate the minute pulse.
My engineer's mind immediately sees a parallel with this:
https://www.ebay.fr/itm/OEM-NEW-2001-2016-Ford-Crankshaft-Position-Trigger-Wheel-Crank-Sensor-Gear-/271248393018
 

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Re: Slightly over the top central clock drive.
« Reply #6 on: August 25, 2020, 06:59:48 am »
Does your Meinberg receiver offer an DCF77 compatible pulse output?

No, but the serial ports can do IRIG for instance. Or Meinberg Time Telegram.


I had long time ago to do with them, and most of the receivers had that either standard or optionally. If so, it'd be a rather easy job to detect the 59th second pulse omission and the next second pulse would be exactly the correct second to generate the minute pulse.
For one particular purpose, I retrofitted such a DCF77 pulse generation to a Meinberg receiver that didn't have that output by reading the serial time code output and encoding this to DCF77. Afair, I used a small 8051 variant (an Atmel ,,,C2051 thingy with 1K or 2K and a D-type FF to achieve this.

That is more in style, indeed!

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Re: Slightly over the top central clock drive.
« Reply #7 on: August 26, 2020, 08:21:17 pm »
I've started playing with an old Pi that I've got around. Some issues have crept up:

  • There was no proper Dave Mills legacy NTP daemon but instead some crap-shite by a dude called Lennart. It barely implements SNTP. That had to go.
  • A Pi 2 is not fast. Compiling things takes ages. I need to evaluate if the performance is enough, or whether I need to go µC all the way with an IRIG reader implementation. OTOH, once everything is up and running, I think the most problems are with I/O, especially to storage.
  • I'm allergic to languages that treat whitespace as magic, so Python is out.  Free-form line noise is better than indentation fascism. I've successfully blinked LEDs from Perl now, so am good.

Next step is breadboarding the trigger and feeder circuitry. Since the clock displays require 24VDC, I'm going to do a fair bit of relay work here.

Purge instructions:

Code: [Select]
# systemctl stop systemd-timesyncd
# systemctl disable systemd-timesyncd
# apt install ntp
# ed /etc/ntp.conf  # remove the pool servers, insert the local Meinberg and
                    # "ntp.se" which is a much more expensive and precise
                    # NTP server than any of us will ever build. Also, it's free to use.
# reboot # that and nukes from orbit. It's the only way to be sure.

Offline capt bullshot

  • Super Contributor
  • ***
  • Posts: 3033
  • Country: de
    • Mostly useless stuff, but nice to have: wunderkis.de
Re: Slightly over the top central clock drive.
« Reply #8 on: August 27, 2020, 05:58:43 am »
If you need a Pi 3, model B, contact me. I've got a few spares, rescued from the scrap. They don't look new and unused at all, but I've tested them to boot at least.

« Last Edit: August 27, 2020, 06:00:31 am by capt bullshot »
Safety devices hinder evolution
 

Offline notfaded1

  • Frequent Contributor
  • **
  • Posts: 559
  • Country: us
Re: Slightly over the top central clock drive.
« Reply #9 on: August 27, 2020, 07:51:05 pm »
How about feeding your PPS to a divide by 6 and then a divide by 10 to give you PPM with something like two 74LS93.  There's an example here:
http://electronics-course.com/digital-clock

It can give you 1PPM you just then need a circuit to flip the polarity back and forth based on your 1PPM.  Something like this would be few discrete circuits... no Pi needed.

Bill
.ılılı..ılılı.
notfaded1
 

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Re: Slightly over the top central clock drive.
« Reply #10 on: August 27, 2020, 08:17:21 pm »
How about feeding your PPS to a divide by 6 and then a divide by 10 to give you PPM with something like two 74LS93.  There's an example here:
http://electronics-course.com/digital-clock

It can give you 1PPM you just then need a circuit to flip the polarity back and forth based on your 1PPM.  Something like this would be few discrete circuits... no Pi needed.

Bill

And, it would still need to know when there's a minute flip, and when a minute is not 60 seconds. I love the idea, but..

Online Ian.M

  • Super Contributor
  • ***
  • Posts: 12807
Re: Slightly over the top central clock drive.
« Reply #11 on: August 27, 2020, 08:26:17 pm »
A Pi may well be the way to go if network connectivity is required, but IMHO its overkill and this is really a job for a small MCU.  All its got to do is generate the minute pulse,  + pick out the time from a NMEA0183 data stream and trim the minute pulse timing to keep the counter and the GPS time +/- local timezone offset in sync.  A daylight saving time function would be nice to have - on two specified dates per year at a specified time of the night, either stop pulsing for an hour to set the clocks back or pulse at double speed for an hour to set them forward.

The question then becomes what MCU do you already have development tools for?

If the answer is 'None', it could be made to work on an Arduino, (preferably a Pro Mini, as you don't need a USB<>serial bridge squatting on its UART pins that you want for the NMEA0183 interface), but the crappy accuracy of their on-board oscillator that uses a ceramic resonator will make a reliable GPS timing source essential.
 

Offline mansaxelTopic starter

  • Super Contributor
  • ***
  • Posts: 3554
  • Country: se
  • SA0XLR
    • My very static home page
Re: Slightly over the top central clock drive.
« Reply #12 on: August 28, 2020, 05:21:36 am »
A Pi may well be the way to go if network connectivity is required, but IMHO its overkill and this is really a job for a small MCU.  All its got to do is generate the minute pulse,  + pick out the time from a NMEA0183 data stream and trim the minute pulse timing to keep the counter and the GPS time +/- local timezone offset in sync.  A daylight saving time function would be nice to have - on two specified dates per year at a specified time of the night, either stop pulsing for an hour to set the clocks back or pulse at double speed for an hour to set them forward.

The question then becomes what MCU do you already have development tools for?

If the answer is 'None', it could be made to work on an Arduino, (preferably a Pro Mini, as you don't need a USB<>serial bridge squatting on its UART pins that you want for the NMEA0183 interface), but the crappy accuracy of their on-board oscillator that uses a ceramic resonator will make a reliable GPS timing source essential.

This makes sense, and yes, the only IDE I've got is for the Arduino, so...

Thanks!


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf