(Pre-2003)
Technical Documents and Related Web Pages
Work on the Digital Optical
Module (DOM):
Technical Documents for
the Icecube Detector (Web page):
- A Preliminary Proposal
for the IceCube DAQ System Architecture, by C. McParland, J. Jacobsen, G.
Przybylski, D. Nygren, PDF Format
- Simulations of Data
Flow in the LBNL IceCube DAQ Design, by J. Jacobsen, MS
Word or PDF format.
- Historical Interest:
The Icecube Electronics System Design, MS
Word or PDF format.
A first version by J. Ludvig et. al.
AMANDA Data Handling at
LBNL
(Web Page)
Other Topics
- Consequences of a
Local Coincidence for a Large Array in Ice; III: Monte Carlo Simulations,
by J. Jacobsen and R.G. Stokstad (Postscript
file or PDF document)
- An Overview of Offline
Software for AMANDA, by J. Jacobsen and C. Wiebusch (PDF
Document)
- J. Jacobsen, Ph.D. Thesis,
Simulating the Detection of Muons and Neutrinos in Deep Antarctic Ice
(PDF Document)
- J. Jacobsen's Curricumum
Vitae (PDF Document, last updated 1999).
Co-author of over 20 papers in refereed journals, and over 50 papers in conference
proceedings. Please contact me for updated information.
Summary
of Work Done at LBNL, 1999-2001
Physics
and Software Engineering for Neutrino Astronomy
 |
| Layout
of a printed circuit board used for the detection of light from neutrino
interactions. The electronics captures analog signals from a photomultiplier
tube and transmits the signals digitally to electronics on the surface
of the ice, two kilometers above. |
|
In the broadest terms, my work has focused on technologies relating to the
detection of cosmic neutrinos. I have been involved with the AMANDA
experiment since its earliest days. AMANDA is located near the geographic South
Pole and has successfully detected high energy neutrinos. LBNL has played a
key role in the analysis of data from this experiment, and in the design and
prototyping of sensors to be used in the IceCube
detector, which will be a greatly enlarged successor to AMANDA.
Work on the Digital Optical Module
In early 2000, the AMANDA collaboration deployed a string of 51 Digital Optical
Modules (DOMs). Typical optical sensors in AMANDA transmit the signal from the
photomultipliers along 2 km of cable before acquisition in the surface electronics.
The DOM represents a shift in detector philosophy, where signals from photomultiplier
tubes are digitized before transmission through the 2 kilometer cables. The
digital signal is much less susceptable to noise, crosstalk and distortion due
to cable effects. This allows for a much cleaner photoelectron signal with greater
dynamic range.
I have worked on several aspects of the DOM development, including the following
projects:
- DOM Test Board Control in Perl and C using TCP sockets and a PC-104
bus
I developed a system to control custom hardware ("test boards")
used for sending and receiving time calibration signals down the two-kilometer-long
cables to the DOMs. The system consists of a single board computer running
Linux which communicates to the hardware using a PC-104 (ISA) bus. This PC
runs a TCP/IP server application called "syncserver." Perl applications
use a front-end API (DOMTBControl.pm) to connect to syncserver and
send it commands. Syncserver, in turn, uses memory-mapped port I/O on the
PC-104 bus to exchange data with an FPGA on the board. For example, to send
a timing signal down the cable, a Perl application like domtest calls a DOMTBControl.pm
function, which sends a message on a socket to syncserver, which sets a bit
in a memory-mapped FPGA register. The FPGA then causes the communications
DAC on the test board to send a signal down the cable. This project took a
few months to implement and is now being tested at the South Pole. A PDF document
describing this work is available.
I have recently (Oct., 2001) written a reloadable, kernel-level char device
driver to buffer communications to and from the Test Boards. The module is
described in this document.
- DOM Communications API in Perl
In order for a surface application to communicate with the DOMs, it is necessary
to communicate serially over 2 km of cable. This can be done either with a
direct serial connection, or via sockets to a terminal server. To this end,
Chuck McParland and I implemented "domio," a suite of Perl
packages / objects which allowed one to communicate with the DOMs from either
Linux or Windows NT workstations, either directly via a COM port or remotely
via a terminal server. The scheme implemented several layers of abstraction,
the lowest layer being the direct serial I/O, followed by a packet layer,
a message layer, and, at the highest layer, a set of methods which allowed
one to exercise functions of the DOM directly from an application. This work
is described further in some detail in a document which is available on request.
- DOM Test Applications in Perl
I wrote two programs in Perl using the domio objects. A low level
program called domtalk communicates directly with the DOM's boot code.
This allows one to interact directly with the boot code by typing commands
which are sent down the serial link, the results appearing on the user's display.
The program is like terminal programs such as Teraterm (Windows) or minicom
(Linux) but allowed for the automation of particular tasks and for the transfer
of files with 32-bit cyclic reduncancy checks (CRC32) imposed. The other program,
domtest, works at a higher level, using domio to send messages to the
DOM application and to decode the responses. Both programs were instrumental
in the development, debugging, testing and characterization of the DOMs deployed
at the South Pole.
- DOM Data Taking Application in Perl
After the DOMs deployed in the ice at the South Pole, we needed to collect
data from them regularly. I wrote DOMLogger at the South Pole to continuously
monitor all the available DOMs and collect data for transmission to Berkeley.
DOMLogger uses the domio objects to access the functions of the DOMs in the
same way that domtest does. The program has been running continuously and
stably on a Linux PC at South Pole since the station closed in February, 2000.
The data is transmitted to Berkeley via satellite, is archived on disk and
is analysed with the help of additional Perl scripts.
- DOM Slow control hardware API in C
This is a set of C routines and macros which allows one to set digital-to-analog
converter (DAC) values and read analog-to-digital converter (ADC) values.
The code runs on an ARM chip and references memory addresses as mapped by
the DOM's PLD. The routines were used inside the DOM both for the boot code
and for the embedded application, for all slow control operations such as
setting and measuring high voltages, measuring temperature, etc. The API is
described in some detail in a document which is available on request.
Additional work not relating to the Digital Optical Module
- Massively-parallel data acquisition simulation using Perl and TCP
sockets
In June of 2000 the LBNL group proposed a complete, integrated electronics
system design for a next-generation neutrino detector, named Icecube. Part
of the proposed system includes a CPU farm for the acquisition of data and
the assembly of data packets to form "events." The rates and sizes
of data to be transferred was understood; in order to determine if "off-the-shelf"
networking (e.g., switched 100BaseT) would be adequate, I created a simulation
in Perl of the system in order to show that the bandwidth requirements would
be met. The simulation ran on 29 Linux PCs connected by switched 100BaseT,
and showed that the available bandwidth would be adequate. The work is further
described
here (PDF file).
Details on the following projects available by request:
- Filtering and data processing in C and Perl (1998)
- API in C for input and output of AMANDA data (1997)
- Simulation of the AMANDA Detector in FORTRAN (1993-1996,
Subject of Ph.D.
Thesis)
