Re: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Contr
Keith, I think few hams have the know how on doing this and it will take work. Using a PC might be much easier. There are many sources for this. 73, ron, n9ee/r From: Keith McQueen [EMAIL PROTECTED] Date: 2007/11/12 Mon PM 11:32:02 CST To: Repeater-Builder@yahoogroups.com Subject: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) You can purchase a GPS receiver for less than $100 that outputs an acurate time signal in NMEA serial format. Here's one: http://www.byonics.com/tinytrak/gps.php It wouldn't take much of a micro controller to convert that into the signal you need. If you can't find a way to interface with the repeater controller, you could probably roll something that would key up a radio and generate appropriate DTMF codes to set the clock. Keith [EMAIL PROTECTED] -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Eric Lemmon Sent: Monday, November 12, 2007 10:15 PM To: Repeater-Builder@yahoogroups.com Subject: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Nate, I appreciate your suggestions and comments, even though we have differing opinions about accuracy. In my area, starting an ARES or MARS net a minute or two early or late is not acceptable. We pride ourselves at beginning the net exactly on the second. After all, we're Hams, and we have access to WWV, don't we? I realize that some folks on this forum may be rolling their eyes at that statement, but hey- if sloppy operating is okay with them, let them do their thing! My obsession (yes, that's probably what it is!) with time accuracy began when I was Chief Engineer at WLRW, an FM station in Champaign-Urbana, Illinois, back in the late 60's. There was an IGM (International Good Music) automation machine that played music and ran commercials and IDs during the periods when live talent wasn't on the mike. The machine was designed to join the ABC Network News feed every hour on the hour, and being a minute early or late was not an option. The problem was that the AC power was locally generated, and was not synchronized to the national power grid as it is today. Even though the timer in the IGM controller made preparations to join the ABC Network exactly on the hour, the small variations in the AC power frequency caused the connection to be made several seconds off, either early or late, and the station owner was on my case constantly. He didn't want to spring for a Favag or Western Union precision time service, so I cooked up a crystal-controlled power oscillator to drive the IGM schedule timer with a TCXO-stabilized power source. It used a Hewlett-Packard oven time base at 10 MHz as a standard, making it easy to synch to WWV. It was a kluge, to be sure, but it worked. With this background information, perhaps you can understand that all I really need is some signal that occurs at exactly some point in time, every day, that can be used to synchronize a repeater controller automatically. Most real-time clock chips, including those made by Dallas Semiconductor, have sufficient short-term accuracy to flywheel through one day without getting more than a second off. If I can tweak such a clock once a day to bring it to the exact time, that is enough. I really don't want to add phone lines, IRLP links, wireless networks, or anything else to make this happen. It would be great if the next-generation repeater controllers had a BNC or TNC connector on the back labeled GPS antenna or WWVB antenna and all I needed to do was install one simple antenna, and the controller would know the time! 73, Eric Lemmon WB6FLY -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Nate Duehr Sent: Monday, November 12, 2007 11:57 AM To: Repeater-Builder@yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Eric Lemmon 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. Eric, There are a number of easy WWV and GPS projects to drive things like Nixie clocks, etc... from simple microcontrollers like the Microchip PIC and Atmel AVR. Those are a good starting point for a project to set a controller's time remotely. Adding code to the microcontroller to then drive a DTMF encoder (or even an R2R ladder for sine-wave output from multiple digital outputs if your micro is fast enough) to set a controller's time, is fairly simple. One
Re: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Contr
Eric, You sound as if you are really serious about the time, but then when it comes to getting it you want someone else to do it. Not a very good ARES approach, hi. It would be easy for some controller to have a logic input that says when I go low set the seconds to zero I guess. Might not be good for clock that looses time where it might read 59 seconds when the logic signal is activated. If starting a net at exactly the second is most important I would think someone would take the time to insure this, not a machine. I guess I see such time concerns tend to get in the way of the work to be done...worrying about the little things instead of the big picture. Found this in the Military so much...when you get your rank insignia on proper you can worry about the downed helicopter. 73, ron, n9ee/r From: Eric Lemmon [EMAIL PROTECTED] Date: 2007/11/12 Mon PM 11:14:39 CST To: Repeater-Builder@yahoogroups.com Subject: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Nate, I appreciate your suggestions and comments, even though we have differing opinions about accuracy. In my area, starting an ARES or MARS net a minute or two early or late is not acceptable. We pride ourselves at beginning the net exactly on the second. After all, we're Hams, and we have access to WWV, don't we? I realize that some folks on this forum may be rolling their eyes at that statement, but hey- if sloppy operating is okay with them, let them do their thing! My obsession (yes, that's probably what it is!) with time accuracy began when I was Chief Engineer at WLRW, an FM station in Champaign-Urbana, Illinois, back in the late 60's. There was an IGM (International Good Music) automation machine that played music and ran commercials and IDs during the periods when live talent wasn't on the mike. The machine was designed to join the ABC Network News feed every hour on the hour, and being a minute early or late was not an option. The problem was that the AC power was locally generated, and was not synchronized to the national power grid as it is today. Even though the timer in the IGM controller made preparations to join the ABC Network exactly on the hour, the small variations in the AC power frequency caused the connection to be made several seconds off, either early or late, and the station owner was on my case constantly. He didn't want to spring for a Favag or Western Union precision time service, so I cooked up a crystal-controlled power oscillator to drive the IGM schedule timer with a TCXO-stabilized power source. It used a Hewlett-Packard oven time base at 10 MHz as a standard, making it easy to synch to WWV. It was a kluge, to be sure, but it worked. With this background information, perhaps you can understand that all I really need is some signal that occurs at exactly some point in time, every day, that can be used to synchronize a repeater controller automatically. Most real-time clock chips, including those made by Dallas Semiconductor, have sufficient short-term accuracy to flywheel through one day without getting more than a second off. If I can tweak such a clock once a day to bring it to the exact time, that is enough. I really don't want to add phone lines, IRLP links, wireless networks, or anything else to make this happen. It would be great if the next-generation repeater controllers had a BNC or TNC connector on the back labeled GPS antenna or WWVB antenna and all I needed to do was install one simple antenna, and the controller would know the time! 73, Eric Lemmon WB6FLY -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Nate Duehr Sent: Monday, November 12, 2007 11:57 AM To: Repeater-Builder@yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Eric Lemmon 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. Eric, There are a number of easy WWV and GPS projects to drive things like Nixie clocks, etc... from simple microcontrollers like the Microchip PIC and Atmel AVR. Those are a good starting point for a project to set a controller's time remotely. Adding code to the microcontroller to then drive a DTMF encoder (or even an R2R ladder for sine-wave output from multiple digital outputs if your micro is fast enough) to set a controller's time, is fairly simple. One of the local clubs here in town has had such a system for a long time, but hasn't published anything about it. From talking with their techs, they receive WWV at a ham's house, set the clock in the Atmel
Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
Eric Lemmon 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. Eric, There are a number of easy WWV and GPS projects to drive things like Nixie clocks, etc... from simple microcontrollers like the Microchip PIC and Atmel AVR. Those are a good starting point for a project to set a controller's time remotely. Adding code to the microcontroller to then drive a DTMF encoder (or even an R2R ladder for sine-wave output from multiple digital outputs if your micro is fast enough) to set a controller's time, is fairly simple. One of the local clubs here in town has had such a system for a long time, but hasn't published anything about it. From talking with their techs, they receive WWV at a ham's house, set the clock in the Atmel, and then it has a transmitter on a common control receiver frequency for all of their machines. They had DST hard-coded to specific weeks of the year in their microcontroller code, and had to modify their code during the great DST mess that Congress created (with little to zero impact on energy use, which was supposedly their goal) the last couple of years. My club never built such a gadget, we just go in and bump the time around as necessary and don't get too wigged out if it's off by a minute or two. Everyone has network-synced cell phones in their pockets these days, and worrying about the repeater time just doesn't seem worth it at this point. We get it close and then have to deal with DST. We also got rid of the hourly chimes/announcements/etc. The only time you hear the time announced is after an autopatch, and that's really just in case we had a need to record the autopatch calls for abuse, etc. Building an auto-time set device and having another transmitter just seems like it breaks the KISS principle. As someone else mentioned, an IRLP node that is properly NTP synchronized can also handle sending DTMF time-set commands easily. Nate WY0X
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
Nate, I appreciate your suggestions and comments, even though we have differing opinions about accuracy. In my area, starting an ARES or MARS net a minute or two early or late is not acceptable. We pride ourselves at beginning the net exactly on the second. After all, we're Hams, and we have access to WWV, don't we? I realize that some folks on this forum may be rolling their eyes at that statement, but hey- if sloppy operating is okay with them, let them do their thing! My obsession (yes, that's probably what it is!) with time accuracy began when I was Chief Engineer at WLRW, an FM station in Champaign-Urbana, Illinois, back in the late 60's. There was an IGM (International Good Music) automation machine that played music and ran commercials and IDs during the periods when live talent wasn't on the mike. The machine was designed to join the ABC Network News feed every hour on the hour, and being a minute early or late was not an option. The problem was that the AC power was locally generated, and was not synchronized to the national power grid as it is today. Even though the timer in the IGM controller made preparations to join the ABC Network exactly on the hour, the small variations in the AC power frequency caused the connection to be made several seconds off, either early or late, and the station owner was on my case constantly. He didn't want to spring for a Favag or Western Union precision time service, so I cooked up a crystal-controlled power oscillator to drive the IGM schedule timer with a TCXO-stabilized power source. It used a Hewlett-Packard oven time base at 10 MHz as a standard, making it easy to synch to WWV. It was a kluge, to be sure, but it worked. With this background information, perhaps you can understand that all I really need is some signal that occurs at exactly some point in time, every day, that can be used to synchronize a repeater controller automatically. Most real-time clock chips, including those made by Dallas Semiconductor, have sufficient short-term accuracy to flywheel through one day without getting more than a second off. If I can tweak such a clock once a day to bring it to the exact time, that is enough. I really don't want to add phone lines, IRLP links, wireless networks, or anything else to make this happen. It would be great if the next-generation repeater controllers had a BNC or TNC connector on the back labeled GPS antenna or WWVB antenna and all I needed to do was install one simple antenna, and the controller would know the time! 73, Eric Lemmon WB6FLY -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Nate Duehr Sent: Monday, November 12, 2007 11:57 AM To: Repeater-Builder@yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Eric Lemmon 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. Eric, There are a number of easy WWV and GPS projects to drive things like Nixie clocks, etc... from simple microcontrollers like the Microchip PIC and Atmel AVR. Those are a good starting point for a project to set a controller's time remotely. Adding code to the microcontroller to then drive a DTMF encoder (or even an R2R ladder for sine-wave output from multiple digital outputs if your micro is fast enough) to set a controller's time, is fairly simple. One of the local clubs here in town has had such a system for a long time, but hasn't published anything about it. From talking with their techs, they receive WWV at a ham's house, set the clock in the Atmel, and then it has a transmitter on a common control receiver frequency for all of their machines. They had DST hard-coded to specific weeks of the year in their microcontroller code, and had to modify their code during the great DST mess that Congress created (with little to zero impact on energy use, which was supposedly their goal) the last couple of years. My club never built such a gadget, we just go in and bump the time around as necessary and don't get too wigged out if it's off by a minute or two. Everyone has network-synced cell phones in their pockets these days, and worrying about the repeater time just doesn't seem worth it at this point. We get it close and then have to deal with DST. We also got rid of the hourly chimes/announcements/etc. The only time you hear the time announced is after an autopatch, and that's really just in case we had a need to record the autopatch calls for abuse, etc. Building an auto-time set device and having another transmitter just seems like it breaks the KISS principle. As someone else mentioned
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
You can purchase a GPS receiver for less than $100 that outputs an acurate time signal in NMEA serial format. Here's one: http://www.byonics.com/tinytrak/gps.php It wouldn't take much of a micro controller to convert that into the signal you need. If you can't find a way to interface with the repeater controller, you could probably roll something that would key up a radio and generate appropriate DTMF codes to set the clock. Keith McQueen 801-224-9460 [EMAIL PROTECTED] -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Eric Lemmon Sent: Monday, November 12, 2007 10:15 PM To: Repeater-Builder@yahoogroups.com Subject: RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Nate, I appreciate your suggestions and comments, even though we have differing opinions about accuracy. In my area, starting an ARES or MARS net a minute or two early or late is not acceptable. We pride ourselves at beginning the net exactly on the second. After all, we're Hams, and we have access to WWV, don't we? I realize that some folks on this forum may be rolling their eyes at that statement, but hey- if sloppy operating is okay with them, let them do their thing! My obsession (yes, that's probably what it is!) with time accuracy began when I was Chief Engineer at WLRW, an FM station in Champaign-Urbana, Illinois, back in the late 60's. There was an IGM (International Good Music) automation machine that played music and ran commercials and IDs during the periods when live talent wasn't on the mike. The machine was designed to join the ABC Network News feed every hour on the hour, and being a minute early or late was not an option. The problem was that the AC power was locally generated, and was not synchronized to the national power grid as it is today. Even though the timer in the IGM controller made preparations to join the ABC Network exactly on the hour, the small variations in the AC power frequency caused the connection to be made several seconds off, either early or late, and the station owner was on my case constantly. He didn't want to spring for a Favag or Western Union precision time service, so I cooked up a crystal-controlled power oscillator to drive the IGM schedule timer with a TCXO-stabilized power source. It used a Hewlett-Packard oven time base at 10 MHz as a standard, making it easy to synch to WWV. It was a kluge, to be sure, but it worked. With this background information, perhaps you can understand that all I really need is some signal that occurs at exactly some point in time, every day, that can be used to synchronize a repeater controller automatically. Most real-time clock chips, including those made by Dallas Semiconductor, have sufficient short-term accuracy to flywheel through one day without getting more than a second off. If I can tweak such a clock once a day to bring it to the exact time, that is enough. I really don't want to add phone lines, IRLP links, wireless networks, or anything else to make this happen. It would be great if the next-generation repeater controllers had a BNC or TNC connector on the back labeled GPS antenna or WWVB antenna and all I needed to do was install one simple antenna, and the controller would know the time! 73, Eric Lemmon WB6FLY -Original Message- From: Repeater-Builder@ mailto:Repeater-Builder%40yahoogroups.com yahoogroups.com [mailto:Repeater-Builder@ mailto:Repeater-Builder%40yahoogroups.com yahoogroups.com] On Behalf Of Nate Duehr Sent: Monday, November 12, 2007 11:57 AM To: Repeater-Builder@ mailto:Repeater-Builder%40yahoogroups.com yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Eric Lemmon 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. Eric, There are a number of easy WWV and GPS projects to drive things like Nixie clocks, etc... from simple microcontrollers like the Microchip PIC and Atmel AVR. Those are a good starting point for a project to set a controller's time remotely. Adding code to the microcontroller to then drive a DTMF encoder (or even an R2R ladder for sine-wave output from multiple digital outputs if your micro is fast enough) to set a controller's time, is fairly simple. One of the local clubs here in town has had such a system for a long time, but hasn't published anything about it. From talking with their techs, they receive WWV at a ham's house, set the clock in the Atmel, and then it has a transmitter on a common control receiver frequency for all of their machines. They had DST hard-coded to specific weeks of the year
Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
On Nov 12, 2007, at 10:14 PM, Eric Lemmon wrote: Nate, I appreciate your suggestions and comments, even though we have differing opinions about accuracy. In my area, starting an ARES or MARS net a minute or two early or late is not acceptable. We pride ourselves at beginning the net exactly on the second. After all, we're Hams, and we have access to WWV, don't we? I realize that some folks on this forum may be rolling their eyes at that statement, but hey- if sloppy operating is okay with them, let them do their thing! But you don't need the controller involved in that. Just punch a few digits to put the controller in Net mode (if that's why the controller needs to be accurate), and call the Net on-time! :-) *BIG GRIN* My obsession (yes, that's probably what it is!) with time accuracy began [snipped story for space..] Very cool. I also like that type of thing. I've been looking into how to modify existing OXCO's into an accurate GPS-locked 10 MHz source for the test gear in the ham shack. There's LOTS of information about how to do that out there, I'm still just in the browsing stage of the project... something to do this winter, I suppose. There have been good articles in QEX, and there's a number of others online. Some of these folks are pretty hard-core, when they're measuring the accuracy of the GPS system itself, and showing when it's nano-seconds off on a particular day... a whole hobby unto itself, really. (An inordinate number of hams involved in those projects, too. Kinda neat.) With this background information, perhaps you can understand that all I really need is some signal that occurs at exactly some point in time, every day, that can be used to synchronize a repeater controller automatically. Most real-time clock chips, including those made by Dallas Semiconductor, have sufficient short-term accuracy to flywheel through one day without getting more than a second off. If I can tweak such a clock once a day to bring it to the exact time, that is enough. I really don't want to add phone lines, IRLP links, wireless networks, or anything else to make this happen. Yep. I think the once-a-day or once-a-week thing with a transmitter and a central WWV-based solution with a microcontroller would be a piece of cake, for the type of accuracy (one second) you're looking for. Again, lots of projects out there that already drive real clock displays... you just need to teach the micro to kick off a routine however-often-you-like that sets the controller remotely via DTMF. In fact, now that I think about it, you don't need the transmitter at all... just stuff the audio output of the board into a receiver port on the controller at the site. To be honest, it's probably easier to do it with a GPS and NMEA output these days, and less chance that you won't be hearing WWV on a particular day. It would be great if the next-generation repeater controllers had a BNC or TNC connector on the back labeled GPS antenna or WWVB antenna and all I needed to do was install one simple antenna, and the controller would know the time! Yeah, Ken mentioned that he's adding that to his controllers today here on the list, and I bet others who have serial ports on their controllers are reading along... not too difficult to find code already written that will read 4800 baud or 9600 baud NMEA strings going by and pick off the time-stamp. That's all the little clock projects done by lots of electronics hobbyists out there have done... Here's an Atmel clock, complete with schematics and code, to start with... http://www.rentron.com/at89c205.htm (It even uses a Dallas chipset freewheeling as you mentioned, which is why it caught my eye.) Then mix in portions of something like this, the Atmel DTMF dialer: http://www.circuitcellar.com/avr2004/wabstracts/A3713abstract.pdf Get the code running on a single AVR, and once you have the prototype working, draw it up as a board in Eagle, or even something proprietary like PCB123, send off for a $20 board, solder your toys on, and you've got your daily clock setter board! :-) That was just stuff I found with a quick Google. There's better designs out there for the clocks... Of course, the same things can be done with a Microchip PIC Microcontroller. Or the TI MCP430 type controllers... or... the list goes on. The Atmel and PIC are probably the most commonly seen in hobbyist electronics. http://www.avrfreaks.net http://www.piclist.com They're actually quite a bit of fun... if you remember programming 8- bit computers in any way years ago, it's virtually the same thing -- the only difference being, you have to design the interfaces to the real world (transistor switches, or stay within the limits of the chip's ability to sink or source current on the pins) yourself, and the whole thing fits on a single
[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 -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Morris WA6ILQ Sent: Sunday, November 11, 2007 12:29 PM To: Repeater-Builder@yahoogroups.com Subject: Re: Re: [Repeater-Builder] RC-96 Controller Problem I don't have my Dallas Semi book handy, but if I remember correctly the 10 years spec was 10 unpowered years - if the Smartwatch was in a device that was powered up the battery was not being drained. But you still had to factor in the shelf life of the internal coin cell. At 03:44 AM 11/10/07, you wrote: Eric, As Kevin said if your 96 has one of the Dallas Smartwatch the battery in some of them had a life of 10 years. It was basically the shelf life of the battery. Most of the Smartwatch's I've seen used a RAM as the memory rather than a EPROM. The battery maintained the memory when power was lost. The battery could power and maintain memory for the life of the battery which again was spec'd for 10 years although most often lasted 12-14 years. Kinda gets into the area of some rigs having their OS in battery backed RAM. The Smartwatch was made by Dallas Semiconductor. 73, ron, n9ee/r From: Kevin Berlen, K9HX [EMAIL PROTECTED] mailto:k9hx%40arrl.net Date: 2007/11/10 Sat AM 02:42:39 CST To: Repeater-Builder@yahoogroups.com mailto:Repeater-Builder%40yahoogroups.com Subject: Re: [Repeater-Builder] RC-96 Controller Problem What version of software is in your controller? With rev 5 of thesoftware, a Dallas Smartwatch was added to the RC-96 to provide a real-time clock. As Irecall, the smartwatch occupied one of the eprom sockets, and the affected eprom wasplugged into a socket on top of the device. If yours has the smartwatch, it maybe the culprit. 73. Kevin, K9HX At 10:10 PM 11/9/2007, you wrote: One of the repeaters I maintainhas been working perfectly for almost a year since its last checkup. It is a 6m repeater that has a link toseveral other 6m repeaters, and is controlled by an ACC RC-96 controller. Itis powered from a very large commercial UPS that ensures no-breakpower. One evening, the controller went berserk, for no apparent reason. It started transmitting a string of Morse characters on both the primaryand secondary ports: dit dah dit ... dah dah dah dah dah dah dah dahdah dah ... for about two minutes. It would then be quiet on both ports forabout 30 seconds, and would then repeat. During the brief silent periods,the repeater would operate as a repeater, but the Morse string muted anyother audio, once it began. The controller would not respond to my DTMFcommands on either the primary or secondary ports. To make matters worse, the telephone line that gives me backup control to knock down the repeaterwas dead at the hilltop end! I had to make a hasty trip to the mountaintopsite to take the beast off the air. As a result of this experience, I am adding a dedicated UHF control linkto give me positive control of the repeater. Has anyone else had a similar problem with the RC-96 controller? Notethat there is no lithium or similar memory battery inside the box that mightgo bad. Oddball malfunctions like this can add more gray hairs than Iwant! Any ideas, case histories, or suggestions will be appreciated. 73, Eric Lemmon WB6FLY No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.26/1119 - Release Date:11/8/2007 5:55 PM No virus found in this outgoing message. Checked by AVG Free Edition. Version:
Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controlle
A 70 or 100 ns device is faster than the 150 ns. This is the access time min required to read/write to it. So if writing say at 500 ns still the 70-100 ns devices will still work. The device will now also work with faster computers. 73, ron, n9ee/r From: Eric Lemmon [EMAIL PROTECTED] Date: 2007/11/11 Sun PM 03:27:08 CST To: Repeater-Builder@yahoogroups.com 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 -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Morris WA6ILQ Sent: Sunday, November 11, 2007 12:29 PM To: Repeater-Builder@yahoogroups.com Subject: Re: Re: [Repeater-Builder] RC-96 Controller Problem I don't have my Dallas Semi book handy, but if I remember correctly the 10 years spec was 10 unpowered years - if the Smartwatch was in a device that was powered up the battery was not being drained. But you still had to factor in the shelf life of the internal coin cell. At 03:44 AM 11/10/07, you wrote: Eric, As Kevin said if your 96 has one of the Dallas Smartwatch the battery in some of them had a life of 10 years. It was basically the shelf life of the battery. Most of the Smartwatch's I've seen used a RAM as the memory rather than a EPROM. The battery maintained the memory when power was lost. The battery could power and maintain memory for the life of the battery which again was spec'd for 10 years although most often lasted 12-14 years. Kinda gets into the area of some rigs having their OS in battery backed RAM. The Smartwatch was made by Dallas Semiconductor. 73, ron, n9ee/r From: Kevin Berlen, K9HX [EMAIL PROTECTED] mailto:k9hx%40arrl.net Date: 2007/11/10 Sat AM 02:42:39 CST To: Repeater-Builder@yahoogroups.com mailto:Repeater-Builder%40yahoogroups.com Subject: Re: [Repeater-Builder] RC-96 Controller Problem What version of software is in your controller? With rev 5 of thesoftware, a Dallas Smartwatch was added to the RC-96 to provide a real-time clock. As Irecall, the smartwatch occupied one of the eprom sockets, and the affected eprom wasplugged into a socket on top of the device. If yours has the smartwatch, it maybe the culprit. 73. Kevin, K9HX At 10:10 PM 11/9/2007, you wrote: One of the repeaters I maintainhas been working perfectly for almost a year since its last checkup. It is a 6m repeater that has a link toseveral other 6m repeaters, and is controlled by an ACC RC-96 controller. Itis powered from a very large commercial UPS that ensures no-breakpower. One evening, the controller went berserk, for no apparent reason. It started transmitting a string of Morse characters on both the primaryand secondary ports: dit dah dit ... dah dah dah dah dah dah dah dahdah dah ... for about two minutes. It would then be quiet on both ports forabout 30 seconds, and would then repeat. During the brief silent periods,the repeater would operate as a repeater, but the Morse string muted anyother audio, once it began. The controller would not respond to my DTMFcommands on either the primary or secondary ports. To make matters worse, the telephone line that gives me backup control to knock down the repeaterwas dead at the hilltop end! I had to make a hasty trip to the mountaintopsite to take the beast off the air. As a result of this experience, I am adding a dedicated UHF control linkto give me positive control of the repeater. Has anyone else had a similar problem with the RC-96 controller? Notethat
Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
At 01:27 PM 11/11/2007, you wrote: 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. If one runs an IRLP node, there is a really simple way to set the clock of your controller every X hours to insure accuracy. I have posted the scripts needed to do this (quite simple to implement) in the files section of our yahoogroups mailing list (I probably should post them to our website as well). Running NTP on your IRLP node insures great accuracy. Alternately, we will be adding support to our products to use NEMA data from a cheap GPS for clock accuracy in the near future as well. Ken -- President and CTO - Arcom Communications Makers of repeater controllers and accessories. http://www.arcomcontrollers.com/ Authorized Dealers for Kenwood and Telewave and we offer complete repeater packages! AH6LE/R - IRLP Node 3000 http://www.irlp.net We don't just make 'em. We use 'em!
Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock
Hi Eric, The Dallas Semiconductor Nonvolatile Timekeeping RAM found in many popular controllers, including the Link RLC-1 Plus, is Part Number DS1643-150. We have a lot of experience with the DS1643 and its bigger brother, the DS1644. The S-COM 5K uses the DS1643 (8K RAM), and the 6K and 7K use the DS1644 (32K RAM). A second source for the DS1643 is the STMicro M48T18-100PC1. For the DS1644, a second source is the STMicro M48T35Y-70PC1. 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. As a rule, a faster memory is okay. Slower isn't. 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. That's right. We've been using these parts for many years and the reports from the field range from excellent to mediocre timekeeping. The controllers have clock tweak commands that add or subtract seconds and can be called from the scheduler program. If one knows how many seconds the clock is gaining or losing in a day, then automatically resetting the clock daily (or more often) makes for a pretty accurate clock. Dallas/Maxim now has a series of timekeeping ICs and temperature compensated crystal oscillators. We're using the DS32KHZ TCXO in the new 7330 with good results, so perhaps the temperature at the repeater site has a lot to do with the accuracy of the controller's clock and calendar. 73, Bob Bob Schmid, WA9FBO, Member S-COM, LLC PO Box 1546 LaPorte CO 80535-1546 970-416-6505 voice 970-419-3222 fax www.scomcontrollers.com ** See what's new at http://www.aol.com
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock
Bob, Thanks for the response. Since the CPU that queries the clock chip is part of the controller, I wasn't sure that the shorter access time of the newer chips would make a difference or not. Now, about time correction- I am looking at making this as simple as possible. I don't have an IRLP node at the site, so using any kind of network connection is not an option. Requiring a computer to be running at the controller location is not an option. I also don't want to play around with adding or subtracting seconds to get the clock close- that's too much human involvement. I don't want to be tasked with manually changing the time when Daylight Saving Time starts or stops. Since the WWVB time broadcasts automatically adjust for DST, any method of synchronizing a controller at a remote site to WWVB seems to be the best way to go. Here's one possible solution, offered by a friend of mine: Obtain a simple and relatively inexpensive atomic digital clock that has an alarm function. Tap into the alarm beeper circuitry so that a logic level is detected when the alarm goes off. Set the alarm so that it triggers at, say, 0400 hours local time every morning. Install a macro in the controller that, when triggered, will reset the controller's clock to 04:00:00. Voila! Every day, courtesy of the NIST, my controller is always on time. If the DS1643 clock chip is at one extreme of its accuracy tolerance, say two seconds per day, the error could be minimized by jam-setting 03:59:59 or 04:00:01, if needed, to keep the clock within one second of exact. Since the execution of a macro takes time, the jam-set time needs to be offset to compensate for the delay. Perhaps the next generation of repeater controllers will have WWVB or GPS time synchronization built in? (hint hint) 73, Eric Lemmon WB6FLY -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, November 11, 2007 2:33 PM To: Repeater-Builder@yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock Hi Eric, The Dallas Semiconductor Nonvolatile Timekeeping RAM found in many popular controllers, including the Link RLC-1 Plus, is Part Number DS1643-150. We have a lot of experience with the DS1643 and its bigger brother, the DS1644. The S-COM 5K uses the DS1643 (8K RAM), and the 6K and 7K use the DS1644 (32K RAM). A second source for the DS1643 is the STMicro M48T18-100PC1. For the DS1644, a second source is the STMicro M48T35Y-70PC1. 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. As a rule, a faster memory is okay. Slower isn't. 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. That's right. We've been using these parts for many years and the reports from the field range from excellent to mediocre timekeeping. The controllers have clock tweak commands that add or subtract seconds and can be called from the scheduler program. If one knows how many seconds the clock is gaining or losing in a day, then automatically resetting the clock daily (or more often) makes for a pretty accurate clock. Dallas/Maxim now has a series of timekeeping ICs and temperature compensated crystal oscillators. We're using the DS32KHZ TCXO in the new 7330 with good results, so perhaps the temperature at the repeater site has a lot to do with the accuracy of the controller's clock and calendar. 73, Bob Bob Schmid, WA9FBO, Member S-COM, LLC PO Box 1546 LaPorte CO 80535-1546 970-416-6505 voice 970-419-3222 fax www.scomcontrollers.com
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] To: Repeater-Builder@yahoogroups.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 -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Mike Morris WA6ILQ Sent: Sunday, November 11, 2007 12:29 PM To: Repeater-Builder@yahoogroups.com Subject: Re: Re: [Repeater-Builder] RC-96 Controller Problem I don't have my Dallas Semi book handy, but if I remember correctly the 10 years spec was 10 unpowered years - if the Smartwatch was in a device that was powered up the battery was not being drained. But you still had to factor in the shelf life of the internal coin cell. At 03:44 AM 11/10/07, you wrote: Eric, As Kevin said if your 96 has one of the Dallas Smartwatch the battery in some of them had a life of 10 years. It was basically the shelf life of the battery. Most of the Smartwatch's I've seen used a RAM as the memory rather than a EPROM. The battery maintained the memory when power was lost. The battery could power and maintain memory for the life of the battery which again was spec'd for 10 years although most often lasted 12-14 years. Kinda gets into the area of some rigs having their OS in battery backed RAM. The Smartwatch was made by Dallas Semiconductor. 73, ron, n9ee/r From: Kevin Berlen, K9HX [EMAIL PROTECTED] mailto:k9hx%40arrl.net Date: 2007/11/10 Sat AM 02:42:39 CST To: Repeater-Builder@yahoogroups.com mailto:Repeater-Builder%40yahoogroups.com Subject: Re: [Repeater-Builder] RC-96 Controller Problem What version of software is in your controller? With rev 5 of thesoftware, a Dallas Smartwatch was added to the RC-96 to provide a real-time clock. As Irecall, the smartwatch occupied one of the eprom sockets, and the affected eprom wasplugged into a socket on top of the device. If yours has the smartwatch, it maybe the culprit. 73. Kevin, K9HX At 10:10 PM 11/9/2007, you wrote: One of the repeaters I maintainhas been working perfectly for almost a year since its last checkup. It is a 6m repeater that has a link toseveral other 6m repeaters, and is controlled by an ACC RC-96 controller. Itis powered from a very large commercial UPS that ensures no-breakpower. One evening, the controller went berserk, for no apparent reason. It started transmitting a string of Morse characters on both the primaryand secondary ports: dit dah dit ... dah dah dah dah dah dah dah dahdah dah ... for about two minutes. It would then be quiet on both ports forabout 30 seconds, and would
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
YES! YES! YES! Thank you Ken! -Original Message- From: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Ken Arck Sent: Sunday, November 11, 2007 3:16 PM To: Repeater-Builder@yahoogroups.com Subject: Re: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem) Alternately, we will be adding support to our products to use NEMA data from a cheap GPS for clock accuracy in the near future as well.
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
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: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Don Kupferschmidt Sent: Sunday, November 11, 2007 5:43 PM To: Repeater-Builder@yahoogroups.com 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: Repeater-Builder@yahoogroups.com 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
RE: [Repeater-Builder] Dallas Semiconductor Real-Time Clock (Was RC-96 Controller Problem)
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 keyupcuckoo cuckoo cuckoo 20 wpm Morse IDunkey 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: Repeater-Builder@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Don Kupferschmidt Sent: Sunday, November 11, 2007 5:43 PM To: Repeater-Builder@yahoogroups.com 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: Repeater-Builder@yahoogroups.com 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
