Hi all, New to the list, but have known of its existence for a while as I know others that have been subscribers. My question pertains to a timebase used in a Schulmerich carillon bell tower system from the 1990’s. The Seiko Epson RTC-72421 Real Time Clock Module (4-bit) is used, but the clock ends up walking to a noticeable degree (minutes) over a period of months. Is this expected for the device in question, or could it possibly have a defect? Datasheet available here: https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en <https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en> From what I can tell it uses an internal oscillator, so it sounds like I would need to find a drop-in replacement or build a module that will replace it with a significantly better time standard. Any advice is appreciated as to whether could be accomplished without too much trouble. I’ve repaired a few of these systems over time and there are enough of them still in the wild that it might be worth me fabricating a module for them. Also, on the off chance someone is versed in EPROM data recovery or knows of a resource for it, I would appreciate that information as well. Regards, Corey N9WIV

On Thu, October 3, 2019 12:00 am, Corey Sukalich wrote: > My question pertains to a timebase used in a Schulmerich carillon bell > tower system from the 1990’s. > > The Seiko Epson RTC-72421 Real Time Clock Module (4-bit) is used, but the > clock ends up walking to a noticeable degree (minutes) over a period of > months. Is this expected for the device in question, or could it possibly > have a defect? The datasheet you linked shows 5ppm max aging in the first year, but no aging curves after the first year. Using the worst case value just for a rough estimate, mid-90's would mean some devices could be 25 years old: 5ppm * 25 yrs -> 125ppm off nominal Note that nominal starts at anywhere from +/-10 to +/- 50 ppm depending on what model you have, and aging could be in the same direction as initial offset, opposite direction as initial offset, or could change direction at some point during the device lifetime. Given all those caveats, 125/1,000,000 * 30 days/month * 24hrs/day * 60min/hour -> 5.4 min/month So if the clocks are losing or gaining anything less than 5 minutes per month, then I would say they are probably beating the worst case value guaranteed in the datasheet. > From what I can tell it uses an internal oscillator, so it sounds like I > would need to find a drop-in replacement or build a module that will > replace it with a significantly better time standard. Or build an interface which will push in the correct time at some time that is unlikely to be noticed (e.g. 2:42AM, some time not right on an hour or half hour). > Also, on the off chance someone is versed in EPROM data recovery or knows > of a resource for it, I would appreciate that information as well. There are a lot of devices which can read data from an EEPROM, that aspect will be nearly trivial, the trouble is usually interpreting the raw data, or filling in any data which has degraded over time and can no longer be read. -- Chris Caudle

Looking at the datasheet I'd expect finding a drop-in replacement is likely problematic. A rather involved RTC module providing seconds out to 100 years. (Although it looks a lot like a Seiko RTC chip I used in the late 70s.) Emulation would probably require an FPGA approach, or one using a 2-port memory, either driven from a more stable clock that, ideally, is GPS disciplined. But a full emulation is an involved design, and all you really need to do is sync the seconds, so what's simpler? One possible approach is to try to do a "jam" correction on the fly. With a little study on how the module interacts with the rest of the carillon there is likely dead time when another controller can take over access to the RTC module. Read the seconds, compare to UTC (or GPS) seconds, adjust if needed by blipping the 30 second adjust bit (D3 in register CD, see full datasheet link below). If GPS is not present, do nothing, assuming GPS will come back before the RTC module skews a full 30 seconds. Depending on how the STD.P pin is used there may be no need for read access, as it may provide pulse per second or minute that could be used for comparison against GPS. In any case register access would require an intercept board that multiplexes all the control lines such that your added controller can get to the necessary registers. Unless I'm wrong (always a possibility) there is no need to access most of the registers in the part, simplifying the design. Or maybe the chip core matches that external crystal RTC I used years ago (sorry, don't remember the Seiko part number offhand). You could then build a module replacement without jam logic but with a GPS disciplined 32.768kHz oscillator. That would be a much simpler approach for minimal drift. Bob LaJeunesse Found a full datasheet at https://www.manualslib.com/download/47987/Epson-Rtc-72421-A.html > Sent: Thursday, October 03, 2019 at 1:00 AM > From: "Corey Sukalich" <zappy@xzapx.com> > To: time-nuts@lists.febo.com > Subject: [time-nuts] Timebase Replacement - Seiko Epson RTC-72421 > > Hi all, > > New to the list, but have known of its existence for a while as I know others that have been subscribers. > > My question pertains to a timebase used in a Schulmerich carillon bell tower system from the 1990’s. > > The Seiko Epson RTC-72421 Real Time Clock Module (4-bit) is used, but the clock ends up walking to a noticeable degree (minutes) over a period of months. Is this expected for the device in question, or could it possibly have a defect? > > Datasheet available here: > https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en <https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en> > > From what I can tell it uses an internal oscillator, so it sounds like I would need to find a drop-in replacement or build a module that will replace it with a significantly better time standard. Any advice is appreciated as to whether could be accomplished without too much trouble. I’ve repaired a few of these systems over time and there are enough of them still in the wild that it might be worth me fabricating a module for them. > > Also, on the off chance someone is versed in EPROM data recovery or knows of a resource for it, I would appreciate that information as well. > > Regards, > Corey > N9WIV > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >

Corey welcome to the group. As i recall those clocks absolutely drifted like that. Regards Paul. On Thu, Oct 3, 2019 at 1:02 AM Corey Sukalich <zappy@xzapx.com> wrote: > Hi all, > > New to the list, but have known of its existence for a while as I know > others that have been subscribers. > > My question pertains to a timebase used in a Schulmerich carillon bell > tower system from the 1990’s. > > The Seiko Epson RTC-72421 Real Time Clock Module (4-bit) is used, but the > clock ends up walking to a noticeable degree (minutes) over a period of > months. Is this expected for the device in question, or could it possibly > have a defect? > > Datasheet available here: > https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en > <https://support.epson.biz/td/api/doc_check.php?dl=brief_RTC-72421&lang=en> > > > From what I can tell it uses an internal oscillator, so it sounds like I > would need to find a drop-in replacement or build a module that will > replace it with a significantly better time standard. Any advice is > appreciated as to whether could be accomplished without too much trouble. > I’ve repaired a few of these systems over time and there are enough of them > still in the wild that it might be worth me fabricating a module for them. > > Also, on the off chance someone is versed in EPROM data recovery or knows > of a resource for it, I would appreciate that information as well. > > Regards, > Corey > N9WIV > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. >