PulseBlasterESR

[Matthew Peters]

Hi,

Our lab is currently switching to labscript from Labrad. We are using a PulseBlasterESR 250 (not a PulseBlasterESRPro) and having an issue with programming it. I am using the labscript_devices PulseBlasterESRPro200 class to control our PB with the clock frequencies changed such that

clock_limit = 250.0e6

core_clock_freq = 250

For reference, my connection table is:

PulseBlasterESRPro200(name='pulseblaster_0', board_number=0) # I have modified directly the PulseBlasterESRPro200 class such that the frequencies match our board

Trigger(name='pb_trigger', parent_device=pulseblaster_0.direct_outputs, connection='flag 0')

To track down the problem, I've created a simple sequence that triggers the PulseBlaster 'flag 0' at time t=0 for a variable duration. If I do "pb_trigger.trigger(0, duration=0.02)", I get a trigger duration of ~67 us. If I do pb_trigger.trigger(0, duration=0.01), I get a trigger duration of ~550 us. From this test it seems the instructions sent to the PB are not being interpreted correctly. 

Control over the PB works fine in Blacs, i.e. it goes high when I press "flag 0" in the GUI.

Does anyone have a suggestion for what could be going wrong with the with the programming sequence? I've looked at the transition_to_buffered method in the PulseBlaster_No_DDS.py file, but I'm not sure how to approach modifying it to work for our PB.

[dihm....@gmail.com]

Hi Matt,

Sorry for such a slow response. For some reason this post slipped through the listserve cracks and we just noticed it. Hopefully you aren't still dealing with this issue.

If you are, a couple thoughts to get started:

1) Do you actually need to use Trigger? If you are looking for generic digital pulses, I typically just use go_high, go_low commands. The Trigger command is designed to be used for triggering other devices and I'm only used to seeing it used internally by other devices. All that said, it should still work as expected since Trigger is a pretty thin descendent of the typical DigitalOut.

2) When it comes to debugging timings of pulseblasters, you are probably best off opening up the compiled shot file and inspecting the generated instructions. They are a bit hard to read, but they follow the basic structure of the timing instructions detailed in the pulseblaster manual. It's good to make sure the programmed values correspond to what you intended. You can also take those instructions and put them into the pulseblaster interpreter, which can check that programming is happening correctly.

3) When you change the clock_limit, you should also change the clock_resolution correspondingly.

4) My knee-jerk intuition, assuming one of the steps above doesn't reveal anything, is that you are encountering some kind of clock timing limitation, and labscript is modifying durations under the hood to respect those limitations.

-David