[time-nuts] Re: Stanford Research SR620 GBIB
djl
djl at montana.com
Sat Aug 28 15:20:26 UTC 2021
Perhaps use the rs232 interface with a USB adapter?
On 2021-08-28 04:29, Julien Goodwin wrote:
> On 28/8/21 5:33 pm, Volker Esper wrote:
>> Julien,
>> Can you please tell us wich GPIB-adapter you are using?
>> Thanks
>> Volker
>
> Didn't have that info to hand when I wrote the mail, one of these:
> http://www.galvant.ca/#!/store/gpibusb
> (possibly an earlier rev, but there's nothing on the PCB to indicate,
> other than a year of 2014)
>
> I should have an alternative *somewhere* around here, but I doubt my
> luck finding it, and it's a similar sort of device, just a different
> implementation.
>
>
> On 28/8/21 5:50 pm, Dave Baxter via time-nuts wrote:
>> I'd be inclined to check the SR620's exact needs re command/query
>> terminators, and also how exactly it terminates its responses.
>>
>> From your description, it sounds like that sort of issue.
>>
>> It may be, your GPIB device or its handler code is not recognising the
>> end
>> of the instruments response, and also buffers are not being flushed
>> before
>> starting another query transaction.
>>
>> So youre software get "out of step" between what it sends to the
>> instrument
>> and what it sees coming back.
>>
>> The eventual lockup, is also indicating potential buffer problems.
>
> I absolutely agree, except that it's not quite consistent behavior, and
> it's just the SR620 that does it.
>
> If I was consistently getting a reading delayed every time I'd assume
> one of the commands is responding that I don't expect, but that's not
> what it seems to be.
>
> Possibly adding a few extra sleep calls into my init code will help.
>
>> You need to see "exactly" what data is happening on the GPIB itself,
>> does
>> your device/support code have any sort of bus analyzer capability?
>
> Nope, I could rig up an adapter on my MSO scope, or possibly pick up an
> old HP one, but the cost in almost any of these options (especially by
> the time you include shipping to Australia) is getting up there with
> just buying a newer HPAK counter.
>
> Given that such a logic analyser adapter is easy enough to design that
> I
> might as well do that, putting the PCBs and connectors on my next
> orders
> with those suppliers.
>
>> 73.
>>
>> Dave G8KBV.
>>
>>
>> Message: 4
>> Date: Sat, 28 Aug 2021 17:03:09 +1000
>> From: Julien Goodwin <time-nuts at studio442.com.au>
>> Subject: [time-nuts] Stanford Research SR620 GBIB
>> To: Discussion of precise time and frequency measurement
>> <time-nuts at lists.febo.com>
>> Message-ID: <4e137f33-67e5-c00c-0293-16276e591806 at studio442.com.au>
>> Content-Type: text/plain; charset=utf-8
>>
>> For an upcoming (very time-nutty, and hopefully to be shared soon)
>> project I need to finally do some frequency datalogging.
>>
>> I've had a Stanford SR620 sitting around, and plugged it in to a handy
>> GPIB adapter (*not* a major commercial one, one of the community
>> ones).
>>
>> While I can get it to talk GPIB there seems to be some reliability
>> issues, with what looks to be some form of read buffering happening,
>> with measurement results coming in as the answer to some later
>> command.
>>
>> A few times I've even restarted it as it stopped responding (luckily
>> that hasn't happened once measurements had started).
>>
>> Since I'm hoping to actually use measurements as part of a control
>> loop
>> this is obviously a bad thing.
>>
>> Does anyone have any experience with the SR620 & GPIB as to why this
>> might be happening?
>>
>> I've not experienced this with other instruments (ancient HP, modern
>> Keysight, recent Keithley, 90s Anritsu) I've used with the same GPIB
>> adapter.
>>
>> The SR620 has version 1.48 firmware.
>>
>> ------------------------------
>>
>> On Sat, 28 Aug 2021 08:31 , <time-nuts-request at lists.febo.com> wrote:
>>
>>> Send time-nuts mailing list submissions to
>>> time-nuts at lists.febo.com
>>>
>>> To subscribe or unsubscribe via email, send a message with subject or
>>> body 'help' to
>>> time-nuts-request at lists.febo.com
>>>
>>> You can reach the person managing the list at
>>> time-nuts-owner at lists.febo.com
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of time-nuts digest..."
>>>
>>> Today's Topics:
>>>
>>> 1. Re: Leviton VTP24 Is this Time Accurate enough? (Dana Whitlow)
>>> 2. Re: Leviton VTP24 Is this Time Accurate enough? (Lux, Jim)
>>> 3. Re: uncertainty/SNR of IQ measurements (Joseph Gwinn)
>>> 4. Stanford Research SR620 GBIB (Julien Goodwin)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Fri, 27 Aug 2021 05:30:14 -0500
>>> From: Dana Whitlow <k8yumdoober at gmail.com>
>>> Subject: [time-nuts] Re: Leviton VTP24 Is this Time Accurate enough?
>>> To: Discussion of precise time and frequency measurement
>>> <time-nuts at lists.febo.com>
>>> Message-ID:
>>> <CADHrwpcec+LWq8hE1nWeW=5MmZJL8cUAf0AuFEYpLff==
>>> uQ2mw at mail.gmail.com>
>>> Content-Type: text/plain; charset="UTF-8"
>>>
>>> If my watch were that bad, I'd toss it out and go shopping for a new
>>> one.
>>> I wonder if Leviton offers a version with an external ref input.
>>>
>>> Dana
>>>
>>>
>>> On Fri, Aug 27, 2021 at 12:12 AM D. Resor <organlists1 at sonic.net>
>>> wrote:
>>>
>>>> I inquired with Leviton as to the accuracy of the VTP24 24 Hour
>>>> Programmable
>>>> Timer with DST.
>>>>
>>>> https://www.leviton.com/en/products/vpt24-1pz
>>>>
>>>> Don Resor
>>>>
>>>> Here is the reply I received:
>>>>
>>>> Hello,
>>>>
>>>> Thank you for contacting Leviton technical support. According to the
>>>> code
>>>> it
>>>> meets, it is required to have time keeping accuracy within 5 minutes
>>> every
>>>> year.
>>>>
>>>> It also uses a crystal to keep time, as it must maintain the time
>>>> even
>>>> during power outages.
>>>>
>>>> Regards,
>>>>
>>>> Virgilio Dominguez
>>>> Technical Services Representative II
>>>> Leviton Manufacturing Co., Inc.
>>>> 201 North Service Road., Melville, NY 11747
>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
>>> send
>>>> an email to time-nuts-leave at lists.febo.com
>>>> To unsubscribe, go to and follow the instructions there.
>>>>
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Fri, 27 Aug 2021 06:25:06 -0700
>>> From: "Lux, Jim" <jim at luxfamily.com>
>>> Subject: [time-nuts] Re: Leviton VTP24 Is this Time Accurate enough?
>>> To: time-nuts at lists.febo.com
>>> Message-ID: <d4c921a7-126f-d599-b042-f98e4746bfb3 at luxfamily.com>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>
>>> On 8/27/21 3:30 AM, Dana Whitlow wrote:
>>>> If my watch were that bad, I'd toss it out and go shopping for a new
>>>> one.
>>>> I wonder if Leviton offers a version with an external ref input.
>>>>
>>>> Dana
>>>
>>> When your requirement is "turn the lights on and off with the sun" 5
>>> min/year is pretty good.
>>>
>>> OTOH, Perhaps there's an aftermarket for a modified version. Maybe
>>> you've got a niche business opportunity there, Dana.
>>>
>>> "Now, with improved accuracy!
>>>
>>> Ovenized for better performance!
>>>
>>> 30 millsecond error in one year!
>>> "
>>>
>>> You might need to gradually change the frequency you feed it, though,
>>> because I'll bet their sunrise/sunset algorithm doesn't implement the
>>> equation of time. But if you're doing milliseconds, you'll need it.
>>>
>>>
>>>
>>>>
>>>>
>>>> On Fri, Aug 27, 2021 at 12:12 AM D. Resor <organlists1 at sonic.net>
>>>> wrote:
>>>>
>>>>> I inquired with Leviton as to the accuracy of the VTP24 24 Hour
>>>>> Programmable
>>>>> Timer with DST.
>>>>>
>>>>> https://www.leviton.com/en/products/vpt24-1pz
>>>>>
>>>>> Don Resor
>>>>>
>>>>> Here is the reply I received:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Thank you for contacting Leviton technical support. According to
>>>>> the
>>> code
>>>>> it
>>>>> meets, it is required to have time keeping accuracy within 5
>>>>> minutes
>>> every
>>>>> year.
>>>>>
>>>>> It also uses a crystal to keep time, as it must maintain the time
>>>>> even
>>>>> during power outages.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Virgilio Dominguez
>>>>> Technical Services Representative II
>>>>> Leviton Manufacturing Co., Inc.
>>>>> 201 North Service Road., Melville, NY 11747
>>>>>
>>>>> _______________________________________________
>>>>> time-nuts mailing list -- time-nuts at lists.febo.com -- To
>>>>> unsubscribe
>>> send
>>>>> an email to time-nuts-leave at lists.febo.com
>>>>> To unsubscribe, go to and follow the instructions there.
>>>>>
>>>> _______________________________________________
>>>> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
>>> send an email to time-nuts-leave at lists.febo.com
>>>> To unsubscribe, go to and follow the instructions there.
>>>>
>>>
>>> ------------------------------
>>>
>>> Message: 3
>>> Date: Fri, 27 Aug 2021 12:02:02 -0400
>>> From: Joseph Gwinn <joegwinn at comcast.net>
>>> Subject: [time-nuts] Re: uncertainty/SNR of IQ measurements
>>> To: time-nuts at lists.febo.com
>>> Message-ID: <20210827120202402955.e8b2babb at comcast.net>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> On Fri, 27 Aug 2021 03:30:28 -0400, time-nuts-request at lists.febo.com
>>> wrote:
>>>> Send time-nuts mailing list submissions to
>>>> time-nuts at lists.febo.com
>>> time-nuts Digest, Vol 208, Issue 20
>>>> ----------------------------------------------------------------------
>>>>
>>>> Message: 1
>>>> Date: Thu, 26 Aug 2021 10:36:46 -0700
>>>> From: "Lux, Jim" <jim at luxfamily.com>
>>>> Subject: [time-nuts] uncertainty/SNR of IQ measurements
>>>> To: Discussion of precise time and frequency measurement
>>>> <time-nuts at lists.febo.com>
>>>> Message-ID: <f8252b36-d0d8-e197-a57a-e21922f9dc64 at luxfamily.com>
>>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>>>
>>>> This is sort of tangential to measuring time, really more about
>>>> measuring phase.
>>>>
>>>> I'm looking for a simplified treatment of the uncertainty of I/Q
>>>> measurements. Say you've got some input signal with a given SNR and
>>>> you
>>>> run it into a I/Q demodulator - you get a series of I and Q
>>>> measurements
>>>> (which might, later, be turned into mag and phase).
>>>>
>>>> If the phase of the input happens to be 45 degrees relative to the
>>>> LO
>>>> (and at the same frequency), then you get equal I and Q values, with
>>>> (presumably) equal SNRs.
>>>>
>>>> But if the phase is 0 degrees, is the SNR of the I term the same as
>>>> the
>>>> input (or perhaps, even, better), but what's the SNR of the Q term
>>>> (or
>>>> alternately, the sd or variance) - Does the noise power in the input
>>>> divide evenly between the branches? Is the contribution of the
>>>> noise
>>>> from the LO equally divided? So the I is "input + noise/2" and Q is
>>>> "zero + noise/2"
>>>>
>>>> If one looks at it as an ideal multiplier, you're multiplying some
>>>> "cos
>>>> (omega t) + input noise" times "cos (omega t) + LO noise" - so the
>>>> noise
>>>> in the output is input noise * LO + LO noise *input and a noise *
>>>> noise
>>>> term.
>>>>
>>>> I'm looking for a sort of not super quantitative and analytical
>>>> treatment that I can point folks to.
>>>
>>> There are many treatments of phase-detector noise available outside
>>> of the time world. The following may help.
>>>
>>> .<https://en.wikipedia.org/wiki/Rice_distribution>
>>>
>>> .<http://www.seas.ucla.edu/brweb/papers/Journals/HRTCASMar13.pdf>
>>>
>>> By and large, these sources assume that the I and Q noise components
>>> are statistically independent, which may be only partially true in
>>> time-nut service. A phase detector implements the pointwise multiply
>>> operation, yielding sum and difference terms. The sought-for phase
>>> is in the difference term, in which noise in common will cancel out
>>> (in the voltage domain), while the noise not in common will add as
>>> power.
>>>
>>> The easiest analytical approach to sorting this out is to draw the
>>> block diagram, and trace AM and PM phase noise expressed as
>>> band-limited zero-mean random functions of time through the block
>>> diagram.
>>>
>>> Joe Gwinn
>>>
>>>
>>> ------------------------------
>>>
>>> Message: 4
>>> Date: Sat, 28 Aug 2021 17:03:09 +1000
>>> From: Julien Goodwin <time-nuts at studio442.com.au>
>>> Subject: [time-nuts] Stanford Research SR620 GBIB
>>> To: Discussion of precise time and frequency measurement
>>> <time-nuts at lists.febo.com>
>>> Message-ID: <4e137f33-67e5-c00c-0293-16276e591806 at studio442.com.au>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> For an upcoming (very time-nutty, and hopefully to be shared soon)
>>> project I need to finally do some frequency datalogging.
>>>
>>> I've had a Stanford SR620 sitting around, and plugged it in to a
>>> handy
>>> GPIB adapter (*not* a major commercial one, one of the community
>>> ones).
>>>
>>> While I can get it to talk GPIB there seems to be some reliability
>>> issues, with what looks to be some form of read buffering happening,
>>> with measurement results coming in as the answer to some later
>>> command.
>>>
>>> A few times I've even restarted it as it stopped responding (luckily
>>> that hasn't happened once measurements had started).
>>>
>>> Since I'm hoping to actually use measurements as part of a control
>>> loop
>>> this is obviously a bad thing.
>>>
>>> Does anyone have any experience with the SR620 & GPIB as to why this
>>> might be happening?
>>>
>>> I've not experienced this with other instruments (ancient HP, modern
>>> Keysight, recent Keithley, 90s Anritsu) I've used with the same GPIB
>>> adapter.
>>>
>>> The SR620 has version 1.48 firmware.
>>>
>>> ------------------------------
>>>
>>> Subject: Digest Footer
>>>
>>> _______________________________________________
>>> time-nuts mailing list -- time-nuts at lists.febo.com
>>> To unsubscribe send an email to time-nuts-leave at lists.febo.com
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>> ------------------------------
>>>
>>> End of time-nuts Digest, Vol 208, Issue 21
>>> ******************************************
>>>
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
>> send an email to time-nuts-leave at lists.febo.com
>> To unsubscribe, go to and follow the instructions there.
>>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe
> send an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.
------------
The whole world is a straight man.
----------------------
Dr. Don Latham AJ7LL
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304
More information about the Time-nuts_lists.febo.com
mailing list