FReLoN

last modified 23-10-2008 16:25

Introduction
Technical data
Hardware connection
- Figure: Cabling between Frelon 2000 and mufid4
- Figure: Connector panel of a Frelon 2000 camera head
The FRELON Spec application
- Getting started
- Command reference
Parallel saving
Troubleshooting
Data storage
- Saving images to disk
See also...: Related other documents
- BLISS Frelon user guide (BLISS)
- Onze, the image display application (BLISS)
- ID 19 Frelon user guide (ID 19)
- List of available objectives (µ-FID₂₂)
- Visiting Scientists' Info (Computing Services)

Introduction

The FReLoN 1000 and FReLoN 2000 are Fast-Readout, Low-Noise CCD cameras developed by the Analog Transient Electronics Group (ATEG) in the ESRF Instrument Support Group. At ID22, FReLon cameras are used in combination with a microscope optic that projects light from a scintillator screen onto the CCD chip of the camera. The magnification of the optic can easily be switched. Various single-crystal scintillators are available that differ in spatial resolution and efficiency. The standard camera at the beamline is a FReLoN 2000. If for a particular experiment a FReLoN 1000 is preferred due to its higher readout rate, this should be mentioned beforehand in the beamtime application form.

Technical data

FReLoN 1000

FReLoN 2000

Image depth

14-bit

Number of pixels

1024×1024

2048×2048

Physical pixel size

19 µm

14 µm

Electrons per ADC unit

40 (std) or 20 (MPP)

Dark current per pixel

200 e^-/s (std) or 3 e^-/s (MPP)

1 e^-/s

Pixel capacity

600000 e^- (std); 350000 e^- (MPP)

320000 e^-

Readout noise

44 e^- (std) or 31 e^- (MPP)

25 electrons

Readout rate

20 Mpixels/s

Readout time
for full frame

Readout	Binned	Unbinned

serial	200 ms	400 ms
multiplex	50 ms	100 ms

Readout	Binned	Unbinned

serial	450 ms	900 ms
multiplex	110 ms	220 ms

Minimum time between consecutive images⁽¹⁾

not tested

200 ms plus exposure time

Binning

2×2 possible

Hardware ROIs

restricted

Image data size

unbinned	2 MB
binned	0.5 MB

unbinned	8 MB
binned	2 MB

Effective pixel size
(unbinned)
and Field of View⁽²⁾

Objective used	Effective pixel size	Field of View

×20	0.48 µm	0.5 mm
×10	0.95 µm	1 mm
×5	1.9 µm	2 mm
×2.5	3.8 µm	4 mm

Objective used	Effective pixel size	Field of View

×20	0.35 µm	0.7 mm
×10	0.7 µm	1.4 mm
×5	1.4 µm	2.8 mm
×2.5	2.8 µm	5.6 mm

⁽¹⁾This delay is due to the internal handling of the image data in the controlling computer. It is not an intrinsic feature of the camera itself. If data are stored to disk or motors of the experimental setup are moved between exposures, this dead time will increase. For example, in a tomography scan you have to add roughly two seconds to the pure readout time for each image. Plus, of course, the exposure time.

⁽²⁾In normal imaging applications, it does not make sense to choose a field of fiew that is larger than the beam size (approximately 1.5 mm). The 2.5× and 5× objectives are only used for special applications where X-ray optical elements expand the beam.

Hardware connection

Figure: Cabling between Frelon 2000 and mufid4 (28K GIF)

Figure: Connector panel of a Frelon 2000 camera head (6K GIF)

The SPEC application "FRELON"

Getting started

FReLoN cameras used at ID22 are operated from the Sun workstation mufid4. The SPEC application designed for this task is named FRELON. It transfers the image data directly to Onze, a graphical user interface (GUI) used for displaying images and image information. Some experience in working with Unix computer systems is useful both for operating the experiment and for data transfer and processing.

The hands-on guide for operating the camera is under revision. Address questions that you may have to Your Friendly Beamline Staff.

Command reference

The command-reference section is under revision. Address questions that you may have to Your Friendly Beamline Staff.

Parallel saving

Saving a multimillion-pixel image to hard disk takes time on the order of a second or so. During a tomography scan with many hundreds of images, the total data-saving time thus contributes significantly to the scan time if the system is otherwise idle during saving. FRELON therefore offers an option "parallel saving" (author: A. Homs, BLISS group), which causes images in a scan to be saved while the next image is already being acquired. The scheme is sketched in the figure below.

Figure: Parallel saving scheme (10K PNG)

Selection of the parallel-saving option will result in two additional processes named "paralsave".

Troubleshooting

Here you find a list of common problems, their possible reasons and remedies:

Everything gets very slow.

There is a number of possible reasons for this. Here are some of them:

If you display a large image (e.g., 2048 by 2048 pixels) at 50 or 100 % image size, the GUI has to allocate so much memory that this will slow the machine down considerably. Remedy: Choose smaller display factor in the GUI.
Other processes are using too much of mufid4's memory or CPU time. Remedy: Make sure mufid4 runs no other applications than FRELON and Onze.
High load on the beamline ethernet network may under certain circumstances make things slow or cause timeouts when FRELON polls devices like GPIBs. Remedy: Do not transfer or compress files on NICE filesystems using the CPU of a beamline computer. Use the NICE machines instead.
Some zombie processes and previously allocated shared memory may be left from previous instances of FRELON. Remedy (for experts):
1. Quit Frelon.
2. Quit Onze.
3. Kill remaining GUI processes (if any).
4. Kill remaining "paralsave" processes (if any).
5. Cleanup shared memory with command cleanup.shared.memory. List of allocated shared memory is available by ipcs -m. Number of entries should be on the order of five or so.

Image acquisition causes Spec to hang

The first attempt to fix this is: abort the acquisition or scan by pressing Control-C, and then try again. If this does not work, try quitting and restarting the applications in this way:

Quit FRELON:
FRELON> quit
Quit the GUI by clicking "Exit".
Restart FRELON:
mufid4{opid22}99: frelon
Reconfigure camera:
FRELON> tomosetup Preset the camera with count time? NO Start camera aquisition on external signal? YES Save images after counting? NO Use channel 1,2,3,4,12,13,24,34 (0 == all)? 0 Simulates ROIs by Software? YES

Image looks entirely black or entirely white or seems under- or overexposed.

Color scaling in the GUI is not set correctly. Play around with the colormap, accessible via the ``Commands'' entry in the GUI's title menu.
Image is under- or overexposed. Change exposure time. If image remains the same, check if camera is actually exposing the given time: see if ct and ccdtake give the same results.
If image is dark: (1) Is there beam in the hutch? (2) Is the X-ray shutter open during acquisition? (3) Is camera still aligned? (4) Does anything block the camera's view?

Saturation value is strange (i.e., differs from 16383) or image size is strange or image looks messed up in some other way that looks as if something has gone wrong during transfer between camera and computer or the FRELON application cannot communicate with the camera.

SDV card of the computer is malconfigured. Re-configure it:

Quit FRELON.
Execute /opt/EDTsdv/fastmux.
Restart FRELON.

SPEC error: "Error moving multiple motors. Error on "id22/maxe222_3/1" sending DevMoveMultiple [...] Giving Up."

SPEC tries to move motors, and for one or more of them the motor controller (in the blue racks behind the large control room) is switched off. The solution is usually to switch it back on, but the same error message may occur should a motor controller be defective.

Dark current is unusually high, and on the camera power supply in the hutch the red "DISABLED" LED is on. Otherwise the camera works.

The Peltier cooling has been switched off automatically. This happens when the CCD temperature does not drop fast enough after the camera has been switched on. The reason is usually low water flow. Remedy: If water level in chiller is below or near the "Min" position, refill it. Then switch power supply off and on again. Do not set the water temperature to any temperature below 15 °C since this may result in serious hardware damage.

General approach to solving hardware problems

If the software is working properly, but the camera gives absolutely unexpected results, consider the following points in addition to those above:

Is there beam in the hutch?
Is there anything in the hutch blocking or degrading the beam?
Is the X-ray shutter open during acquisition, closed at all other times, and does the beam pass through its aperture?
Does the beam hit the camera aperture?
Are you using the correct microscope objective?

Data storage

Saving images to disk

There are three ways of saving images to disk:

If you want to save every image that is acquired, use the ccdnewfile command to tell Spec that you do and where you want the data to be put.
If you want to save only few of the images that are actually acquired, the graphical user interface (GUI) can be used.
When recording fast image series where saving to disk may decrease speed critically, you may temporarily store images in the workstation's memory and write them to disk after all data have been acquired. If you are interested in this option, consult Your friendly beamline staff.

In any case, the images are saved in the ESRF data format. The GUI also allows you to save them in Ascii format. Data in ESRF format can be converted to other image formats like TIFF, PNG and JPEG using IDL.

A filesystem on the central ESRF unix cluster NICE is mounted on mufid4 where you can store your data. Data on this filesystem will be kept for 30 days (user experiments) or 100 days (inhouse experiments). Temporarily, images can be stored locally on mufid4 if this is required for velocity reasons. Those data will only be kept until the end of the experiment.

File transfer to your home institute

This section has been transferred to the document "Preparing your imaging experiment at ID 22".