No subject
Sat Aug 28 08:32:08 UTC 2021
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.
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?
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
> ******************************************
>
More information about the Time-nuts_lists.febo.com
mailing list