Shades of the late 1960s PARC "serial time code generator". At the top of the hour you would hear a real wooden cuckoo clock...
The clock had a mic cartridge from a Motrac base mic positioned next to the clock's voice box. There was a microswitch on the hour cam for PTT, therefore the time code was only on the hour. A Paragon time clock opened the PTT lead from 10:30pm to 5:30AM (the last ID of the day was 10pm, the first was 6AM) The transmitter was a 1/4w Moto exciter fed to a small beam with only a couple of element. The signal was just barely full quieting, but a 10w mobile anywhere in the coverage area could capture it. Initially it was cute, and the regular users got to the point where they could predict the keyup.... You'd hear a conversation going on and someone on the repeater would say "oh - and now a word from our sponsor <unkey squelch tail> <keyup>cuckoo cuckoo cuckoo <20 wpm Morse ID><unkey squelch tail> and the conversation would continue... ...but after a while it got annoying and evaporated. Mike WA6ILQ At 06:14 PM 11/11/07, you wrote: >Don, > >The "on-the-hour" tone is an 800 ms burst of 1500 Hz. I have built a PLL >1500 Hz tone detector into a Hamtronics WWV receiver, and it works fine- >giving me a relay contact closure exactly on the hour. Unfortunately, that >would only allow me to jam-set the minutes and seconds to zero, and would >not correct an hour error- such as when DST starts and stops. > >I considered dispensing with the voice time announcement completely, and >just broadcast an hourly beep. The problem is that transmitters don't come >up instantly, and most or all of the beep will be missed. My solution to >that problem is to use the on-the-hour pulse to reset a simple countdown >timer that closes a PTT relay at the end of a 59 minute 57 second delay. >The countdown timer will key the transmitter shortly before the hour, >ensuring that it is ready to pass the 1500 Hz beep exactly on the hour. As >soon as the beep detector relay relaxes, PTT goes away, and the repeater >will issue its identity message and return to idle mode. I'm still >tinkering with this idea. The downside is that WWV reception varies with >the time of day and propagation factors, and a decent antenna is required. > >73, Eric Lemmon WB6FLY > > >-----Original Message----- >From: [email protected] >[mailto:[EMAIL PROTECTED] On Behalf Of Don Kupferschmidt >Sent: Sunday, November 11, 2007 5:43 PM >To: [email protected] >Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was >RC-96 Controller Problem) > >Eric, > >I've been toying around with this idea for a couple of years - set the SCOM >7K clock to atomic standards. As you know, the 7K's are prone to drifting >with their time of day clock. > >The idea is to have a stable WWV signal that "listen" to the top of the hour > >signal. I'm thinking that is a 1000 kHZ tone, but I could be wrong about >that. > >If someone could build a circuit to decode the top of the hour signal from >WWV, you could command the controller, through macros, to reset the clock. >Shouldn't be all that difficult. > >The designers of the new SCOM controller recognized that problem earlier, >and as I am told, have placed a new crystal / circuit in the time of day >clock to address that problem in the 7330 line. > >With all of the 7K's out in the field, if a simple circuit could be made it >would eliminate the drifting problem. > >Don, KD9PT > >----- Original Message ----- >From: "Eric Lemmon" <[EMAIL PROTECTED] <mailto:wb6fly%40verizon.net> > >To: <[email protected] ><mailto:Repeater-Builder%40yahoogroups.com> > >Sent: Sunday, November 11, 2007 3:27 PM >Subject: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 >Controller Problem) > > > Mike and others, > > > > The Dallas Semiconductor "Nonvolatile Timekeeping RAM" found in many > > popular > > controllers, including the Link RLC-1 Plus, is Part Number DS1643-150. > > The > > 11-page datasheet can be downloaded here: > > > > <www.datasheetarchive.com/pdf/1235806.pdf> > > > > Notice that the "-150" indicates 150 ns access time. The replacement > > device > > offered by Dallas/Maxim has either 70 ns or 100 ns access time, and I have > > no idea if the newer device will work properly where a 150 ns device was > > used. > > > > On page 5 of the datasheet is a paragraph entitled "Internal Battery > > Longevity" which states that the device can operate for 10 years in the > > absence of VCC power. When powered as it would normally be in a typical > > application, the note states that the lifetime can be as long as 20 years. > > The battery is not accessible for replacement. > > > > I see that the guaranteed accuracy of the DS1643 clock is within +/- 1 > > minute per month, and there is no capability to tweak the crystal to get > > better accuracy. One of the Hams in my area is experimenting with a > > scheme > > to use a so-called atomic clock to jam-set the correct time once per day. > > With regular synchronism to WWVB, the time announcements will normally be > > no > > more than a second off. Once he gets this idea working, perhaps I can get > > him to write an article about it. I and many other "time-and-frequency > > geeks" think that time announcements should be correct. > > > > 73, Eric Lemmon WB6FLY
