Hi All. I have an SR620 that is misbehaving. I am working my way through the manual and schematics, but one consistent behavior has arisen: At a period of around 4-6s when measuring frequency, I get a "wrong number" that is consistent in scale across 10MHz and 1kHz (the REF frequency). I.e. when I measure a 10MHz signal, occasionally the display shows 9946187.4... Hz and when measuring REF (1kHz) the display occasionally shows 994.618757 Hz. This is independent of termination, and the A & B front-ends have passed their tests. Has anyone encountered the same issue, or have a suggestion as to where to look for the root cause? [image: 20221104_SR620_SN356_Frequency_error-1-small.jpg] [image: 20221104_SR620_SN356_Frequency_error-2-small.jpg] [image: 20221104_SR620_SN356_Frequency_error-3-small.jpg] --Andrew -------------------------------- Andrew E. Kalman, Ph.D.

Hi Andrew, On 11/4/22 19:44, Andrew Kalman via time-nuts wrote: > Hi All. > > I have an SR620 that is misbehaving. I am working my way through the manual > and schematics, but one consistent behavior has arisen: At a period of > around 4-6s when measuring frequency, I get a "wrong number" that is > consistent in scale across 10MHz and 1kHz (the REF frequency). > > I.e. when I measure a 10MHz signal, occasionally the display shows > 9946187.4... Hz and when measuring REF (1kHz) the display occasionally > shows 994.618757 Hz. This is independent of termination, and the A & B > front-ends have passed their tests. > > Has anyone encountered the same issue, or have a suggestion as to where to > look for the root cause? > > [image: 20221104_SR620_SN356_Frequency_error-1-small.jpg] > > [image: 20221104_SR620_SN356_Frequency_error-2-small.jpg] > [image: 20221104_SR620_SN356_Frequency_error-3-small.jpg] Since f = cycles / time, these two latest is actually about the same time. time = cycles / f and cycles is nominal frequency times nominal time-base, so t1 = 1E5 / 9946187.4882 = .0100541036 s t2 = 1E1 / 994.618757 = .01005410357 s So, both are really taking about the same time, just above the 10 ms the time-base is set for, 54.1 us or so. I would guess that there is an issue with the stop-counter side, so it somehow keeps running. The difference you see is probably in the different start-time-stamps. The time as used in above formula is really stop-time minus start-time to get the elapsed time, and the time-base triggers how far after the start-time that an attempt at a stop-time is taken. So, it's not unreasonable that we are just above 10 ms, it's the intended behavior, but the actual values is consistent with some issue to it. I hope this gives you a good clue of what part of the good old SR620 troubling you. Sometimes I find that tweaking the trigger-points avoid these issues. That is part of the working that turns into part of a skill. However, when your trigger is in auto for normal good signals, you should not experience this. If messing with your trigger-point help you, it could be that you need to work on the trigger side of things to get stable operation as default properly. The 1 kHz output on loopback should always operate safely in auto-mode, yet you illustrate it's failure. I seem to recall calibration details about it. Cheers, Magnus

Magnus: Thank you, I will go down that path. Your explanation makes sense, and I figured it was probably something with the start and stop times, but didn't see the math behind it. FWIW, on this unit: 1. It had a shorted dipped tantalum cap (C917), that was forcing the -15V regulator (U910, an LM337) into and out of thermal overload (measured around +135C). 2. I replaced all the tantalum caps (around 25 of them), and U910 for good measure, and that problem appears to have gone away. 3. There is a 3x220 Ohm resistor network (N404, N405, N406) that spans 30V on the front-end (one on each of three channels) that gets really hot (>100C). I'm not sure why SRS did that, but I suspect this is normal operation. 4. The rest of all the ECL chps seem to run at around 50-60C. I'm revisiting ECL, it's not a logic family I ever worked with extensively. I designed the SRS SR560 (everything but the front-end, that was founder John Willison's design) as my first task at SRS. My buddies Scott and Adam did the PCB and enclosure of the SR620 (and many other models), respectively, and then we all went off together in 1988 to start a pro audio company. So, I have a certain place in my heart for the SRS instruments of that era. I will report back (sporadically?) as I work my way through this. --Andrew -------------------------------- Andrew E. Kalman, Ph.D. On Fri, Nov 4, 2022 at 3:22 PM Magnus Danielson via time-nuts < time-nuts@lists.febo.com> wrote: > Hi Andrew, > > On 11/4/22 19:44, Andrew Kalman via time-nuts wrote: > > Hi All. > > > > I have an SR620 that is misbehaving. I am working my way through the > manual > > and schematics, but one consistent behavior has arisen: At a period of > > around 4-6s when measuring frequency, I get a "wrong number" that is > > consistent in scale across 10MHz and 1kHz (the REF frequency). > > > > I.e. when I measure a 10MHz signal, occasionally the display shows > > 9946187.4... Hz and when measuring REF (1kHz) the display occasionally > > shows 994.618757 Hz. This is independent of termination, and the A & B > > front-ends have passed their tests. > > > > Has anyone encountered the same issue, or have a suggestion as to where > to > > look for the root cause? > > > > [image: 20221104_SR620_SN356_Frequency_error-1-small.jpg] > > > > [image: 20221104_SR620_SN356_Frequency_error-2-small.jpg] > > [image: 20221104_SR620_SN356_Frequency_error-3-small.jpg] > > Since f = cycles / time, these two latest is actually about the same time. > > time = cycles / f and cycles is nominal frequency times nominal > time-base, so > > t1 = 1E5 / 9946187.4882 = .0100541036 s > > t2 = 1E1 / 994.618757 = .01005410357 s > > So, both are really taking about the same time, just above the 10 ms the > time-base is set for, 54.1 us or so. > > I would guess that there is an issue with the stop-counter side, so it > somehow keeps running. The difference you see is probably in the > different start-time-stamps. > > The time as used in above formula is really stop-time minus start-time > to get the elapsed time, and the time-base triggers how far after the > start-time that an attempt at a stop-time is taken. So, it's not > unreasonable that we are just above 10 ms, it's the intended behavior, > but the actual values is consistent with some issue to it. > > I hope this gives you a good clue of what part of the good old SR620 > troubling you. > > Sometimes I find that tweaking the trigger-points avoid these issues. > That is part of the working that turns into part of a skill. However, > when your trigger is in auto for normal good signals, you should not > experience this. If messing with your trigger-point help you, it could > be that you need to work on the trigger side of things to get stable > operation as default properly. The 1 kHz output on loopback should > always operate safely in auto-mode, yet you illustrate it's failure. I > seem to recall calibration details about it. > > Cheers, > Magnus > _______________________________________________ > time-nuts mailing list -- time-nuts@lists.febo.com > To unsubscribe send an email to time-nuts-leave@lists.febo.com >