Sep 242015

We’ve recently discovered that the latest version of the ChipKIT MPIDE (used to compile and flash the PineBlaster code) is no longer compatible with the original PineBlaster code that we have made available.

We have updated our code to be compatible with the latest version of MPIDE (v0150-20150820), however this has resulted in a reduction of available PineBlaster instructions to 7450 (down from 15000) and a slower response to hardware triggers. As such, it is our recommendation to continue using the original code (which currently resides in the default branch of our repository) to maintain the original specifications. However, this code can only be compiled by MPIDE v0023-20120903 with all compiler optimisations disabled as per the readme file in the bitbucket repository.

If you have any issues compiling the PineBlaster code, or acquiring a copy of the correct version of MPIDE, please contact us via our mailing list.

Note: If your PineBlaster is currently functioning correctly, you do not need to do anything! This post only relates to flashing the PineBlaster code onto the ChipKIT board before using it with the labscript suite software.

Aug 142014

The Monash BEC labs use several rf sources, including the Novatech DDS9m.

The DDS9m has four outputs, the first two of which can be stepped through a pre-programmed table, with the remaining two only controllable by software commands (and hence static during buffered runs). We use a revision 1.3 board, which supports external timing of the table mode, as detailed in AN002.

The clocking of the DDS9m through the table entries is non-trivial, however we have converged on an implementation which reliably updates the output on rising clock edges. Here I will detail the hardware involved, along with the software commands sent from the BLACS tab, and the resulting behaviour of the device.


We have installed each DDS9m board in a box with a power supply, rf switches and rf amplifiers, creating what we refer to as a Supernova. Each channel of the DDS9m is fed into a switch, with one output port going to the amplifier, and the other going directly to the front panel for debugging (though this isn’t necessary, we don’t use this feature often). The direction of the output (amp. vs test) is determined by a toggle switch for each channel. The on/off state of each switch is then determined by a second toggle switch for each channel, which can switch between on, off and TTL modes. In TTL mode the state of the switch is determined by the high/low state of a TTL line connected to a BNC port on the front panel. We use these TTL lines to switch our rf during the experiment, since it saves on lines in the DDS9m’s table, and allows some control of the static channels.

To step through the table, we use a TTL clocking line, along with a “table enable” TTL line, to drive a tri-state driver chip, which in turn drives pins 10 and 14 of the DDS9m. The roles of the pins (for the rev. 1.3 boards and later) when in table mode, with hardware output enabled, are as follows: falling edges on pin 10 cause the next table entry to be loaded into the buffer, and rising edges on pin 14 cause the values in the buffer to be output. 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?). For this same reason, you should not hold pin 14 high or low when not in hardware table mode, hence the use of a tri-state buffer.

We use an M74HC125B1R quad tri-state driver in the following configuration:

The clock line used to step through the table is sent to two channels of the buffer, which are connected to pins 10 and 14 of the DDS9m. Our table enable line passes through another channel of the buffer and has its output inverted by a transistor before feeding the disable lines of the other channels of the buffer. The result is that when the enable line is low, the buffer is disabled, meaning that the DDS9m pins see a high impedance, and importantly, are isolated from each other since they are on their own channels. When the enable pin is high, the buffer is enabled, and the signal from the clock line is sent to both pins.

Since the one clock line feeds both pins, when it goes high the output is updated, and when it goes low the next value is loaded into the buffer in preparation for the next clock tick.

Software implementation

Manual/static mode

When the Novatech BLACS tab is in static mode, the device operates in “automatic update” mode, having had the I a command called. When front panel values are changed, the appropriate Fn, Vn, or Pn command is sent, and the output updates without the need for any extra hardware trigger.

Table/buffered mode

When the Novatech BLACS tab transitions to buffered mode, it executes commands in a very specific order. Firstly, the “static” channels (2 & 3) are programmed using the same method as manual mode, then the values for the buffered channels (0 & 1) are programmed in. Since it takes a considerable amount of time to program a full table over the slow RS232 connection, we have implemented “smart programming”, where the table to be programmed is compared with the last table programmed into the device. Only the lines which have changed are reprogrammed, overwriting those values in the DDS9m’s table, but keeping all other previous values as they are. If you suspect that your table has become corrupt you can always force a “fresh program” where BLACS‘ “smart cache” is cleared and the whole table is programmed.

Once the table has been written, we sent the mt command to the board, which places it in table mode. Since we are still in I a auto update mode at this point, the first entry of the table is not only loaded into the buffer, but output too. At this point, all channels on the board are outputting the instruction set at their initial output time for the experiment to be run. We now send the I e command to switch to hardware updating, and wait for the experiment to begin.

As the experiment starts, the table enable line must be set to go high at the board’s initial output time, and the clocking line will go high too. This initial rising edge will do nothing, since the device is already outputting the values in its buffer. The first falling edge will then load the second line of the table into the buffer, ready for the second rising edge to trigger the output of the second value, and so on.

On transition to manual, at the end of the experiment, m 0 is sent to put the board back into manual mode, and I a is sent to turn automatic updating of the outputs again. The last values of the experiment are then programmed in via the normal manual update mode to keep the front panel consistent with the output.

Future improvements

External referencing

At the moment, we rely on the internal reference crystal. The DDS9m does support external referencing, however it is non-trivial, as you have to play with the PLL settings yourself, and scale frequency commands accordingly. In principle, there is nothing stopping us from implementing this, however we haven’t had the need for an absolute calibration in our labs, since we mostly use the boards for controlling acousto-optic modulators or doing simple frequency sweeps for rf-induced evaporation.

Asymmetric clocking

Currently, labscript‘s clocking signals are symmetric, meaning the line is high for as long as it is low. This actually limits the rate at which we can clock the DDS9m to approximately half its maximum rate. The manual specifies that after the falling edge which triggers the update of the buffer, you must allow up to 100 microseconds for the request to be processed. This means that the low time of the clock must be at least 100 microseconds, before the rising edge which triggers the output to update. This rising edge, however, only has to be held high for 10 nanoseconds. With asymmetric clocking we could achieve an update rate of 9999 Hz, compared with the symmetric clock limit of 5000 Hz.

Implementing this would require all devices on a peseudoclock to report their minimum low and minimum high times, and careful calculations to ensure that all devices receiving the clock have their requirements met at all times (and should be discussed further elsewhere!).