Novatech synchronous triggering hardware

[David Meyer]

So in our lab we've been triggering our Novatech boards in asynchronous mode (i.e. a single pulseblaster channel to TS/pin 10) and living with the 100us timing jitter. But the time has come to do proper synchronous trigger and I want to know what the best way to set that up.

From the manual we read "Please note that internal to the instrument, this same control signal [IOUD/pin 14] is used to set the default values upon power up or following a customer reset. If held steady by your logic during initialization, no output will be present until there is a positive edge. It is suggested that this pin be used with an “open-collector” type drive, or tri-stated from your logic, to allow initialization. The state of “I e” is stored in EEPROM with the “S”

command." So it isn't as simple as just wiring the pulseblaster channel up to both TS/pin 10 and IOUD/pin 14. 

I know the Monash lab uses a Tri-state buffer to accomplish this, but requires a second 'table enable' line from the pulseblaster that I would prefer to avoid. I've also heard rumors that the Spielman UMD lab uses some sort of delay line, which requires minor modifications to the class. Finally, by the documentation and a tip from Chris I've also heard that using a simple "open-collector" buffer to isolate the two channels would work, basically giving most of the tri-state buffer functionality without needing a second pulseblaster line.

So to the question: before I commit to one of these methods, can anyone speak to what they use in their lab and how well it works?

[Philip Starkey]

I'll help get the ball rolling...

Obviously we use the tri-state buffer in the labs at Monash. We've never had any issue with using this. In fact, I would say the Novatechs (in this configuration) have been the most stable device out of all the hardware we use. 

But i'm sure other systems will work equally well though. From memory, the key point we discovered while developing (as alluded to in the blog post you link to) was that Pin 10 and pin 14 must be isolated from each other or else the Novatech ends up "talking" to itself. For reference, I believe support for delay lines has been included via this pull request although that unfortunately doesn't say how you should wire up the delay line!

--

Phil

[Chris Billington]

Hi David,

JQI's delay line method works, though it requires a workaround to the novatech class, which is in the JQI fork and for which there is a pull request to mainline. You need to also use the "synchronous_first_line_repeat" option which was recently merged into mainline as well.

I'm not familiar with the details of the delay line at JQI, unfortunately, Dimitri in the RbLi lab would be the most familiar with it, having implemented it there. Another JQI lab is also in the process of making a similar setup, and Mingwu is the one implementing that. I'm not sure if they are on the mailing list, but I've CCd them here in case they want to chime in. Mingwu has used what they're describing as an "open collector type driver", which is similar to the RbLi lab's delay line, except it does not require the synchronous_first_line_repeat option for reasons I am not certain about.

For what it's worth, here's an excerpt from Ian Spielman from a recent email conversation with Mingwu about it. I assume the SN7407N must be the buffer they're using in their electronics to make the delay line. "double clutch" is how we refer to the workaround in the pull request.

 

Dear Chris and Mingwu,
First, in reading the monash documentation on the tristate driver I saw the text ' Since pin 14 is usually an output when I e hardware output has not been enabled, it should not be directly connected to pin 10, as this interferes with operation during manual mode (and possibly programming of the table?).’  which justifies the use of a tristate driver.  I am pretty sure that at UMD their delay line is always connected, so perhaps this is what the double clutch is needed there.
Actually the novatech documentation says simply "If held steady by your logic during initialization, no output will be present until there is a positive edge.” So it is not really so bad.
In any case, it look like a circuit that uses SN7407N will work fine, where a PB channel directly connects the the TS pin of the novatech and also into a single input channel of the SN7407N the output of which connects to the IOUD port on the novatech.  This only requires one novatech channel like the delay line solution, but does what novatech wants, which is allow the IOUD port to float when the trigger line is low.

Good luck!

--
You received this message because you are subscribed to the Google Groups "The labscript suite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuite+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Meyer]

Hello all,

So I've finally found some time to do the testing for this and I'm leaning towards the SN7407N solution. However, while testing I came across something odd that I'm not quite sure I understand.

In the past we've been triggering the novatech's by connecting the clockline directly to Pin 10/TS and using asynchronous mode. And unless I'm very much mistaken, that doesn't actually work as desired and apparently we've yet to do precise enough timing to notice until now. In asynchronous mode updates only occur on the falling edge of Pin 10, but labscript still clocks as if triggering is on the rising edge. In order to work properly, the logic needs to be inverted with hardware I guess. Is there any particular reason asynchronous mode does not invert the clockline within labscript? How is asynchronous mode supposed to be use?

To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuit...@googlegroups.com.

[Chris Billington]

Hi David,

Yes, the novatech triggers off the falling edges for asynchronous mode. The method used at JQI has been to use the PulseBlaster with pulse_width=<some_small_time_interval> to ensure that a falling edge always quickly follows a rising edge. That way the Novatech can still share a clockline with other devices without extra electronics to invert the signal. It's not the prettiest solution but since the pulse width can be much shorter than the ~100us the Novatech takes to update its output, it does not affect the timing much. Symmetric (50% duty cycle) clock ticks from the PulseBlaster though (used when pulse_width=None) mean a variable, and possibly quite long delay in updating the Novatech. This could certainly make experiments have incorrect timing, and I apologise that this wasn't documented anywhere. I will have time in the coming months to improve documentation, even if just means turning on bitbucket wiki pages anyone can edit or using sphinx to turn comment strings into web pages (and updating those comment strings).

-Chris

To unsubscribe from this group and stop receiving emails from it, send an email to labscriptsuite+unsubscribe@googlegroups.com.

[David Meyer]

I figured it was something simple like that. I suppose that's good to know finally even if we are going to move away from it immediately.

I've finished testing the SN7407N buffer method and it appears to work well. I've even configured it so it used the same power supply as the novatech which is an added bonus.

Interestingly, I only need the synchronous_first_line_repeat option for the first buffered run after turning on the Novatech. After that it must be off for correct operation. I also don't appear to need the double clutch either. I wonder if the double clutch might be dependent on the PB being used? I know some models blank their digital outputs while programming (due to the pb_stop() command) which could be causing the spurious edges. Once I build a few more triggering boxes I'll test across all of our hardware and see if there is any difference.

-David

--
You received this message because you are subscribed to a topic in the Google Groups "The labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/Bf4UJMgmky0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to labscriptsuite+unsubscribe@googlegroups.com.

[Chris Billington]

I do suspect that the double clutch is dependent on which PulseBlaster is in use, but also dependent on the order things occur during transition_to_buffered. When we were debugging the issue initially it was non-deterministic, so it is always possible that you are just lucky so far and that the problem might rear its head later. In any case the current pull request is to have the double-clutch trick performed unconditionally, since there is no apparent downside other than a wasted millisecond or so, so people hopefully won't have to worry about whether they need it once it's merged.

As for needing synchronous_first_line_repeat after a power cycle, that's unfortunate, but I cant' think of any way to handle this in software since BLACS can't know whether the novatech has been power cycled or not. I think anyone in this situation will just have to know that the first shot after a power cycle is a dud, and again this is the sort of lore that belongs in a wiki or other documentation, so I'll refer back to this thread when I get around to it. In the meantime it's good that this discussion is in the public record!

[Daniel Barker]

I know this thread is dead, but it seems like the best place to post this.

I imagine that few new labs are deploying novatechs, but I've developed my own hardware solution for synchronous triggering (without needing 2 clock lines). The eagle files for my control board can be found at https://github.com/JQIamo/DDS9m-Controller.

My controller does not require 'synchronous_first_line_repeat' either for normal operation or after a power cycle (it's main advantage over the solutions mentioned previously). The price is that the novatech's clock line has to have a pulse width >= 1.5 us. The controller is also optoisolated and uses open-drain (rather than open-collector) logic, so the chips are less likely to be discontinued.

On Thursday, April 26, 2018 at 9:10:58 PM UTC-4, Chris Billington wrote:

I do suspect that the double clutch is dependent on which PulseBlaster is in use, but also dependent on the order things occur during transition_to_buffered. When we were debugging the issue initially it was non-deterministic, so it is always possible that you are just lucky so far and that the problem might rear its head later. In any case the current pull request is to have the double-clutch trick performed unconditionally, since there is no apparent downside other than a wasted millisecond or so, so people hopefully won't have to worry about whether they need it once it's merged.

As for needing synchronous_first_line_repeat after a power cycle, that's unfortunate, but I cant' think of any way to handle this in software since BLACS can't know whether the novatech has been power cycled or not. I think anyone in this situation will just have to know that the first shot after a power cycle is a dud, and again this is the sort of lore that belongs in a wiki or other documentation, so I'll refer back to this thread when I get around to it. In the meantime it's good that this discussion is in the public record!

On Thu, Apr 26, 2018 at 11:28 PM, David Meyer <dihm...@gmail.com> wrote:

I figured it was something simple like that. I suppose that's good to know finally even if we are going to move away from it immediately.

I've finished testing the SN7407N buffer method and it appears to work well. I've even configured it so it used the same power supply as the novatech which is an added bonus.

Interestingly, I only need the synchronous_first_line_repeat option for the first buffered run after turning on the Novatech. After that it must be off for correct operation. I also don't appear to need the double clutch either. I wonder if the double clutch might be dependent on the PB being used? I know some models blank their digital outputs while programming (due to the pb_stop() command) which could be causing the spurious edges. Once I build a few more triggering boxes I'll test across all of our hardware and see if there is any difference.

-David

On Wed, Apr 25, 2018 at 10:30 PM, Chris Billington <chrisjbi...@gmail.com> wrote:

Hi David,

Yes, the novatech triggers off the falling edges for asynchronous mode. The method used at JQI has been to use the PulseBlaster with pulse_width=<some_small_time_interval> to ensure that a falling edge always quickly follows a rising edge. That way the Novatech can still share a clockline with other devices without extra electronics to invert the signal. It's not the prettiest solution but since the pulse width can be much shorter than the ~100us the Novatech takes to update its output, it does not affect the timing much. Symmetric (50% duty cycle) clock ticks from the PulseBlaster though (used when pulse_width=None) mean a variable, and possibly quite long delay in updating the Novatech. This could certainly make experiments have incorrect timing, and I apologise that this wasn't documented anywhere. I will have time in the coming months to improve documentation, even if just means turning on bitbucket wiki pages anyone can edit or using sphinx to turn comment strings into web pages (and updating those comment strings).

-Chris

To unsubscribe from this group and stop receiving emails from it, send an email to labscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "The labscript suite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/labscriptsuite/Bf4UJMgmky0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to labscri...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "The labscript suite" group.

To unsubscribe from this group and stop receiving emails from it, send an email to labscri...@googlegroups.com.

[David Meyer]

Looks cool Dan! Nice to have these things out in the open. 

In that spirit, I'm attaching our ExpressPCB files for using the very simple SN7404 buffers that we put inside the cases of our 409B-AC variety boards. Basically just stuff the board with the buffer chip, a 470Ohm resistor, and a terminal block (filter caps optional, but recommended); power from the Novatech 5V input; and cut both TS and IOUD wires and put both ends into the appropriate terminal block connection.