Professional Documents
Culture Documents
Pump-Probe Starter
Tobias Staut
Contents
1 Introduction
2.1
Schematic Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
2.3
Setting up myRIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
2.5
Laser Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1
Microsecond Configurations . . . . . . . . . . . . . . . . . . . . . . .
2.5.2
Picosecond Configurations . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1
3.2
3.3
3.4
Picosecond Delayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5
Microsecond Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6
Picosecond Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
18
4.1
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2
The Caller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3
Picosecond Delayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4
Microsecond Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.5
Picosecond Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.6
Realtime Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7
Realtime Microseconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8
Realtime Picoseconds
4.9
FPGA Microseconds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
27
5.1
5.2
5.3
Things left to do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1 Introduction
As a part of my Ph.D. I developed a piece of software that allows us to perform pumpprobe measurements (laser induced fluorescence in an inverted microscope) on multiple
timescales.
In order to fulfil the timing requirements for these experiments, I used a programmable
hardware circuit, a so-called FPGA (Field Programmable Gate Arrray). Several companies
offer a variety of developement boards fitted with one of the many types of FPGAs available, but my choice was the National Instruments myRIO-1900. Its advantages include the
relatively cheap price, an RTOS (Real-Time Operating System) layer, and the (relatively1 )
easy-to-use and powerful LabVIEW developement environment.
The software has two measurement modes, one for the microsecond and one for the nanosecond time range (the latter one will be referred to as picosecond mode as the timing
resolution is 10 ps). Moreover I added tools to align the laser beam path and the fluorescence detection path and to prevent our Toptica FFPro TVIS from creeping to lower
power during run time.
The scope of the next two sections is to communicate the hardware setup, how to use the
compiled piece of software, and describe the format of output data. The fourth section
explains how the software works underneath the front panel.
If compared to the VHDL language I would have had to use otherwise, you may substitute relatively
with ridiculously.
2
This might not be a correct name in the strictest definition of the term.
3/29
Figure 1: Schematic experimental layout for the picosecond mode including control (PC,
myRIO), delay line (EDL), lasers und detection. Other laser setups are possible.
Figure 2: Schematic experimental layout for the microsecond mode with control (PC,
myRIO), delay line (EDL), lasers und detection. Other laser setups are possible.
4/29
These schematics give a brief overview of the required hardware. Fig. 1 is the schematic
for the picosecond mode. Please note that there are several Laser configurations possible
which I will explain in ch. 2.5. Fig. 2 is the schematic for the microsecond mode. Here,
several laser configurations are possible as well.
Figure 3: Photo of the hooked up myRIO. The ribbon cable connects the MXP A to the
breakout box, two more DGNDs are connected via the red cables.
5/29
Figure 4: Photo of the hooked up breakout box. The colour code is given in the text.
3
This is a workaround for immense crosstalk that vanishes when all four cables are connected.
6/29
Explaining synchorisation is not in the scope of this manual. If in doubt, contact Topticas support.
7/29
Figure 5: The sepia laser drivers.5 Green ports are fast gates to enable/disable the diode
output, black ones slow triggers for continuous pulsing.
Figure 6: The LRC module. RF1 and RF2 on the left are for the monitor outputs. The
PID regulator is used to finally lock the oscillators in phase.
5
Note that these drivers are equivalent to those on the Sepia II. We luckily own an intermediate series
model that wasnt produced very long.
8/29
Figure 7: Overview of the Sepia and delayer. Connecting instructions are given in the text.
9/29
10/29
Figure 9: Power Control Tool front panel. Description is given in the text.
11/29
Figure 10: Pop-up when starting the pps Software. Last chance to check the hardware.
In both modes new settings have to be applied by pressing a button called save measurement settings, it will not happen automatically.6 Upon request you can check the settings
before starting the measurement. This is a remnant of the testing phase as well. Which
settings have to be taken care of will be explained in the chapters about the specific measurement mode.
The respective measurement is started with a press on the start measurement button.
The folder in which the data are saved is indicated right below the start button.
After the measurement you get the chance to return to the caller or to exit the program.
6
12/29
Figure 11: Front panel of the Picosecond Delayer software displaying the standard settings.
Edge detection is optimised for the TVIS monitor out.
13/29
Figure 12: Microsecond setup mode of the caller. The value check part is not shown.
The first chooses the laser setup (cf. ch. 2.5), the second determines how long the pump
laser is active to saturate the sample, the third is for the maximum duration of the free
decay between pump and probe, the fourth sets the interval in which the free decay time
is increased, and the fifth determines how long count rates are gathered while the probe
laser is active.
Figure 13: The four timing variables visualised. Different colours symbolise different lasers.
14/29
Pressing the start measurement button loads the microsecond measurement program in a
new window (cf. Fig. 14). You can see the previously described debugging indicators on the
lower left and two chart windows displaying measurement curves from one APD each. The
charts include four curves: the current free decay time, the milliseconds since the current
fluorescence collection started8 , the number of photons in the current millisecond bin, and
the resulting count rate.
ms bin i
counts i
ms bin i+1
counts i+1
where the counts stand for either photons per bin or the count rate. Note that in order to
avoid zero entries the ms bin is not continuous, making mean count rate calculations much
easier.
8
This is because the events are read out in ms-wide bins. More explanation in ch. 4.7.
15/29
Figure 15: Picosecond setup mode of the caller. The value check part is not shown.
The delay interval determines the interval in witch the delay is increased, the max. delay
sets the maximum delay, and the meas. period determines the time in which the fluorescence
for each delay is gathered. Note that in order to cover all possible (positive and negative)
delays, you have to sweep at least twice the period. So at 80 MHz (max. delay - zero delay)
has to be at least 25 ns. If you make sure that at zero delay the lasers actually arrive at
the sample at the same time, you of course only have to sweep over one period.
Pressing the start measurement button loads the picosecond measurement program in
a new window (cf. Fig. 16). The presets tab on top shortly displays the settings passed
from the caller to the measurement program, then switches to the monitoring tab with
the debugging indicators and two chart windows displaying current count rates. Below the
9
The way I chose to save the values from the Picosecond Delayer software is the reason you have to
update new values in the caller by pressing a button.
16/29
tabs is the measurement curve, where mean count rates for each delay are shown. Last but
not least there are the error cluster and a stop button to interrupt excecution.
17/29
Figure 17: Block Diagram of the caller. From left to right there is a initialisation phase
(double film strip), run phase (green box), and a stop phase (film strip and
code outside the box).
Some values are stored in so-called Functional Global Variables (FGV).10 This undermines
the dataflow structure of LabVIEW, as storing and reading of values does not have to be
10
As to every other element within the LabVIEW universe there is extensive documentation and examples
available online.
18/29
connected by wires, but of all the possibilities to pass data around arbitrarily, this is by
far the most reliable choice.
The run phase, the actual program, if you will, is written as a very basic event-driven
producer/consumer. If you press any button on the front panel, some action will be triggered. It is possible to transmit data as well as cases, but as I use FGVs explicit data
transfer is not necessary. Fig. 17 shows what happens when you press the start button of
the picosecond case: The case pspp - start is send to the consumer, where the settings are
read from the FGV and loaded to the measurement program, which then pops up. After
it finished there is an error handling subVI and the possibility to stop the caller or just
perform another measurement.
When the excecution is stopped, the stop phase, which resets all values to standard, is
passed through before the program stops. Note that the black-yellow error wires not only
keep track of errors, but also assure that the functional units are excecuted in order.
Figure 18: In contrast to the last event-driven producer/consumer, data is passed, too.
Instead of a FGV a shift register in the producer is used as storage.
19/29
The block diagram in Fig. 18 is not so different from the callers. The initialisation phase
is hidden in its own case, as the connection to the device is only established upon request,
and the data storage differs, as here an initialised shift register is used instead of a FGV.
A closer look at how to open a serial connection is advisable. After figuring out the serial
connection settings of your hardware, it can be fed to the appropriate subVI (supplied
code, white square at the top left in Fig. 19). Then you can initialise your device to a
specific state by feeding it commands (for loop with the indexed input). The Picosecond
Delayer accepts ASCII code, so it is slow, but comprehensible. The rest is a query to assure
the settings are correct.
Figure 19: Connecting to the Picosecond Delayer consists of the serial connection plus some
standard settings and reading a response.
20/29
measurement. In the displayed case, values are read from two different network streams,
but only if there are any available. Network streams too are a way to pass data between
two distant machines. In this case the communication is lossless, as buffers are involved.
The values fron the stream are then fed to charts on the front panel and FGVs which
save them during excecution. Note that the values are saved to the RAM only during the
measurement as writing data to disc is much to slow to be used during acquisition.
Figure 20: The block diagram for the microsecond measurements contains nested state
machines. Here you see the measurement state of the Measurement state.
21/29
Figure 21: A connection is established to the myRIO and the precompiled program is
loaded and started.
22/29
Figure 23: Main phase of the realtime microsecond VI. It is organised as realtime (RT)
FIFO producer/consumer with a command parser on top.
Every millisecond if the FPGA is in a fluorescence collection state and a multiple of
three elements is in the FIFO the DMA FIFO is read. Each datapoint consists of three
elements, hence the multiple-of-3 condition. The first element is the current delay, the
second and third are number of ticks (200 MHz clock) between two photon events on APD
0 and 1. These points are sent to the RT FIFO including the number of elements and the
milliseconds between this datapoint and the last one.
The lower part, the consumer, calls a subVI that processes the raw data from the RT FIFO.
The datapoints, which contained delay, number of ticks, and as metadata the milliseconds
between this and the last datapoint, are transformed. In the end, datapoints containing the
current delay, milliseconds since the current delays fluorescence collection started, number
of photons in the current millisecond bin, and the current count rate are sent to the network
stream.
After the last delay, the FGVs are reset, the FPGA is stopped and the host is notified via
a network variable that the remote VI finished.
23/29
Figure 24: Logic section of the FPGA VI. The left part grabs the timing settings and stalls.
The right part contains the actual timing logic.
As seen in Fig. 24, the timing logic is a state machine as well. The different states provide
different values for the physical outputs (Rose boxes 2, 3, 4 from the top on the right side
in Fig. 24.), and the two registers for FIFO activation and current delay, respectively.
The case structure inside the state machine provides the necessary value changes when
using different laser setups. Note that this time the state machine is inside a single-cycle
timed loop. This means that the hole code inside the loop is excecuted in a single clock
period. But it takes a signal two clock cycles to propagate through the circuit, because I
added flip-flops (boxes with arrows in the figure). This was necessary to reduce the critical
path length and keep the clock rate as high as possible. The maximum is 160 MHz.
The near-square on the left side of the timed loop is a counter implemented through a DSP
on the FPGA. No more counters are needed, as this one is reset inbetween the actual
24/29
Figure 26: DMA FIFO accessible from the realtime machine located on the right. Also used
in the picosecond mode, only without the registers.
25/29
Fig. 26 shows the part of the FPGA VI, where the single elements from the input FIFOs
and, in this case, the current delay register, are combined to the datapoints read in the
realtime machine. I have to make sure that the datapoints always consist of three elements.
So if one input FIFO times out11 , i.e. no photon event occurred in that channel since the
last iteration, theres a zero written. Also, if no elements are in the input FIFOs or if the
FPGA is not in the collection state (FIFO enable), there is nothing sent at all, as the
writing to the DMA FIFO is disabled.
Figure 27: Only part genuine to the picosecond mode: The loop needed to set outputs when
running the Alignment Tool.
The picosecond mode is more or less the microsecond mode without the timing logic. As
mentioned before the counting logic is the same, and the DMA FIFO works the same
way but lacks the registers. The only code genuine to the picosecond mode is the loop in
Fig. 27, which is only needed in the Alignment Tool to programmatically enable the lasers
(Note again that the APD gates do not work due to limitations of the myRIO, so the
corresponding switches do not work properly).
Which will be the case most of the time, since at 200 MHz sampling rate, photons are not likely to arrive
at the same time.
26/29
5 Concluding Remarks
5.1 About this script and hardware
I hope that this script is helpful. I tried to comment the LabVIEW block diagrams themselves as much as possible, so that the last chapter became only a very brief description
of the main components of the program, requiring a lot of prior knowledge. Additionally
I labeled hardware wherever possible so that with the second chapter it should be easy
to set up the experiments. The front panels themselves are put together with the aim to
guide you through the acquisition process, so that hopefully no problems arise the third
chapter cant solve.
If you acquired the code via the NI myRIO community: The hardware used for this experimental setup easily breaks the 100k e barrier. In principle the APDs and light sources are
replaceable by cheap electronics (LEDs, photodiods), as long as they provide the necessary
inputs and outputs. If there are any sensible demonstration experiments possible is another
question. Replacing the Picosecond Delayer is not so easy as it requires not only finding a
replacement, but also a rewrite of the code.
If after all these changes any meaningful experiments are still possible is another question,
but it would suffice for demonstrations.
Especially the network streams will produce ommittable errors when the endpoints are destroyed.
27/29
The timed loop period for repeated measurements is too long (50 s). In order to capture
only the timespan of triplet decay it should be no longer than 10 s. To circumvent the
problem, make sure that saturation, free decay and collection time add to at least 50 s.
A solution would be to add a waiting state to the FPGA procedure.
28/29
29/29