Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
On Wed, Nov 23, 2016 at 9:54 PM, Srinivas, Raghavendra (IntlAssoc) wrote: >>Back-to-back pulses are troublesome. Is that being used actively? > > As Daniel mentioned, for Ramsey experiments when you're scanning the delay, > when the delay is 0 you'd have two back

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Srinivas, Raghavendra (IntlAssoc)
Just out of curiosity, ttl.pulse(t) is essentially, ttl.on() delay(t) ttl.off() How would ttl.pulse_off(t) be different from ttl.off() delay(t) ttl.on() to avoid the problem when t=0 that back to back pulses have? Sincerely, Raghu -Original Message- From: Robert Jördens

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Slichter, Daniel H. (Fed)
> > As Daniel mentioned, for Ramsey experiments when you're scanning the > > delay, when the delay is 0 you'd have two back to back pi/2 pulses. > > How would that need to be coded differently? Explicitly, > > > > ttl.pulse(t_pi/2) > > delay(t) > > ttl.pulse(t_pi/2) > > > > and we scan t from 0

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Sébastien Bourdeauducq
On Thursday, November 24, 2016 04:54 AM, Srinivas, Raghavendra (IntlAssoc) wrote: Replacing is very channel dependent. It can only happen on certain data and certain state of the channel. Not generally. It needs to be fine tuned for each channel. And it needs to happen at the input side of the

[ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
Hello ARTIQ users, in preparation for DRTIO and DMA we are considering dropping a small feature that -- while being potentially "convenient" to the user -- leads to overhead and is unergonomic/unaesthetic. Currently, we support submitting multiple output events scheduled for the same timestamp

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Slichter, Daniel H. (Fed)
We definitely use zero-length pulses as a regular part of our experiments. The most prominent example is scanning a pulse duration time (e.g. for Rabi flopping, or delay between Ramsey pulses), where the first item in the list of pulse durations to scan is a zero duration pulse (i.e. no Rabi

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Srinivas, Raghavendra (IntlAssoc)
>Back-to-back pulses are troublesome. Is that being used actively? As Daniel mentioned, for Ramsey experiments when you're scanning the delay, when the delay is 0 you'd have two back to back pi/2 pulses. How would that need to be coded differently? Explicitly, ttl.pulse(t_pi/2) delay(t)

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Jonathan Mizrahi
> > leads to overhead and is unergonomic/unaesthetic. > Can you clarify how you find this unaesthetic? From the perspective of an ARTIQ user, having to check for zero pulse lengths everywhere seems to create far more unaesthetic programs. I also second Daniel's point -- we often scan pulse

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
On Wed, Nov 23, 2016 at 8:06 PM, Slichter, Daniel H. (Fed) wrote: > We definitely use zero-length pulses as a regular part of our experiments. > The most prominent example is scanning a pulse duration time (e.g. for Rabi > flopping, or delay between Ramsey pulses),

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Robert Jördens
On Wed, Nov 23, 2016 at 9:16 PM, Jonathan Mizrahi wrote: >> leads to overhead and is unergonomic/unaesthetic. > > Can you clarify how you find this unaesthetic? From the perspective of an > ARTIQ user, having to check for zero pulse lengths everywhere seems to > create far more

Re: [ARTIQ] [RFC] remove output event replacement feature

2016-11-23 Thread Jonathan Mizrahi
Good points; I understand the issue better now. I'm OK with removing this feature. Jonathan Mizrahi Research Scientist Joint Quantum Institute University of Maryland 301-314-1903 On Wed, Nov 23, 2016 at 3:29 PM, Robert Jördens wrote: > On Wed, Nov 23, 2016 at 9:16 PM, Jonathan