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: [email protected] >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: [email protected] >[mailto:[EMAIL PROTECTED] On Behalf Of Mike Morris WA6ILQ >Sent: Sunday, November 11, 2007 12:29 PM >To: [email protected] >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: [email protected] ><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: 7.5.503 / Virus Database: 269.15.27/1121 - Release Date: >> 11/9/2007 7:29 PM >> >> >>Ron Wright, N9EE >>727-376-6575 >>MICRO COMPUTER CONCEPTS >>Owner 146.64 repeater Tampa Bay, FL >>No tone, all are welcome. >> >> >> >> >> >> >> >>Yahoo! Groups Links >> >> >> > > Ron Wright, N9EE 727-376-6575 MICRO COMPUTER CONCEPTS Owner 146.64 repeater Tampa Bay, FL No tone, all are welcome.
