SIMS Sunil

Project Report
On
24 CHANNEL DATA ACQUISITION SYSTEM (DAS)

USING USB 2.0 & REAL TIME MONITORING
SYSTEM OVER INTRANET FOR SIMS
SUBMITTED IN PARTIAL FULFILLMENT FOR THE

AWARD OF THE DEGREE OF B.E (EC)
OF GUJARAT UNIVERSITY
SESSION: 2009
Submitted by
Sunil Pillai
Department of Electronics & Communications
Government Engineering College, Sector-28,
Gandhinagar
Jan-May’09
Best Project of the Year at PRL (8.25/10)
- Review Panel, 16 Apr ‘09
Project Report
On
24 CHANNEL DATA ACQUISITION SYSTEM (DAS)
USING USB 2.0 & REAL TIME MONITORING
SYSTEM OVER INTRANET FOR SIMS
Project Guide:
Mr. Chandresh Parekh Dr. Kuljeet Kaur Marhas

HOD Mr. M.P. Deomurari
Electronics & Communication Dept Ion Probe Laboratory
Government Engineering College, Planetary Sciences Division
Gandhinagar Physical Research Laboratory
Ahmedabad
Submitted by
Sunil S Pillai
Department of Electronics & Communications
Government Engineering College, Sector-28,
Gandhinagar
Jan-May’09
CERTIFICATE
This is to certify that Shree Pillai Sunil Sasidharan of course
B.E. (EC) SEM 8th Roll No 10540 has satisfactorily
completed his project work at
PHYSICAL RESEARCH LABORATORY, AHMEDABAD
And Submitted the Project Report on
24 CHANNEL DATA ACQUISITION SYSTEM

(DAS) USING USB 2.0 & REAL TIME
MONITORING SYSTEM OVER INTRANET FOR
SIMS
as a partial fulfillment of the requirement for the award of

Bachelor of Engineering (BE) degree in Electronics and
communication by Gujarat University, Ahmedebad, during the
academic year 2008-09
Date of Submission ___________

Examining Faculty Head of Department
_______________ _________________
Physical Research Laboratory
Table of Contents
Abstract … … … … … … … … … iii
Acknowledgement … … … … … … … iv
List of Tables … … … … … … … v
List of Figures … … … … … … … vi
1. About Physical Research Laboratory … … … 1

1.1 About Physical Research Laboratory… … … 2
1.2 About Planetary Science Division … … … 3
1.3 About Ion Probe Laboratory … … … … 4
1.4 About SIMS … … … … … … 4
2. Introduction … … … … … … … 11
2.1 Objectives … … … … … … … 12
2.2 Modular Approach … … … … … 13
2.3 Project Management … … … … … 15
3. System … … … … … … … … 17
3.1 Overview … … … … … … … 18
3.2 Hardware Board … … … … … … 20
3.3 Ion Probe Server … … … … … … 21
4. Hardware … … … … … … … … 27
4.1 Overview … … … … … … … 28
4.2 PIC18F4550 … … … … … … 28
4.3 Circuit Diagram … … … … … … 32
5. Firmware … … … … … … … … 33
5.1 Overview … … … … … … … 34
5.2 File Description … … … … … … 34
5.3 Program Execution … … … … … …
5.4 List of Files … … … … … … … 39
5.5 Conclusion … … … …. … … 39
6. Data Logger … … … … … … … 41
6.1 Overview … … … … … … … 42
6.2 SIMS Monitoring System … … … … 42
6.3 Snapshot … … … … … … … 47
6.4 Conclusion … … … … … … … 48
7. Database … … … … … … … … 49
7.1 Overview … … … … … … … 50
7.2 The Ion Probe Database … … … … 50
GEC, Gandhinagar ii Sunil S Pillai

7.3 Snapshot … … … … … … … 55
7.4 Conclusion … … … … … … … 57
8. Dashboard Web Service … … … … … 58

8.1 Overview … … … … … … … 58
8.2 Dashboard … … … … … … … 58
8.3 Login Page … … … … … … … 63
8.4 Dashboard Page … … … … … … 64
8.5 Snapshoot … … … … … … … 71
8.6 Conclusion … … … … … … … 74
9. Future Work … … … … … … … 75
10. Bibliography … … … … … … 77
11. Appendix A : Firmware Code … … … … … 79
12. Appendix B : Data Logger Code … … … … 92
13. Appendix C : Dashboard Code … … … … 104
14. Appendix D : Datasheet… … … … … … 117
GEC, Gandhinagar iii Sunil S Pillai

ABSTRACT
The project is intended to provide real time monitoring of the status of Secondary
Ion Mass Spectrometer (Cameca’s IMS-4F) at Ion Probe laboratory. 17 Parameters were
identified for obtaining status information of the Instrument viz, Duoplasmatron Primary
Beam ON/OFF, Duoplasmatron Vacuum, Vacuum generated by two Rotary Pumps,
Vacuum generated by two Ion Pumps, Speeds of 4 Turbo Pumps, Chiller Water Level &
Temperature, Water Flow, Coolant Level & Flow and Lab Temperature & Humidity.
A data acquisition Board has been realized for acquiring all the intended
parameters. The system is based on PIC18f4550 microcontroller from Microchip Inc.
Provision has been made for acquiring 8 analog values & 16 digital values. However, this
capacity can further be extended by cascading appropriate multiplexers. The acquired
values are sent to PC through USB.
A data logging application running on the PC receives the data from the USB via
appropriate drivers. After validation, the Data is parsed & displayed for diagnosis
purpose. Simultaneously data is logged into MS Access Database with time stamp. The
PC has been turned into a local Server which hosts the Intranet Service. The Data is
visualized onto a dashboard which is then streamed live over PRL LAN.
So user can log in to SIMS Monitoring Site from any pc on PRL LAN & view the
status data in form of the gauges & indicators displayed on dashboard. The dashboard
also has a chart panel. This can be used to analyze the status data for any given period.
For dashboard Development, Dundas Data Visualization Software has been used.
The web service has been developed using Visual Studio 2005 (ASP.NET) in C#
language. The stand alone Data Logging application has been developed using Visual
Studio 2005 in VB language.
Microchip’s Mplab IDE v8.20 has been used for firmware development. The USB
stack has been implemented using Microchip USB framework MCPFSUSB v2.4. PicKit
v2.40 has been used for loading the microcontroller. The hardware used for loading the
firmware was the Sunrom Technology’s PICEX2000 loader. Experimental work was
done on the PIC18F4550 evaluation board by Sunrom Technology Inc.
This project was implemented at the Ion Probe Laboratory of Planetary Sciences
Division of Physical Research Laboratory, Ahmedabad. The system was accomplished by
me under the supervision of Dr. Kuljeet Kaur Marhas & Mr. M.P.Deomurari in a period
of four months i.e. from Jan’09-Apr’09. The project was adjudged as the “Best Trainee
Project of the Year-2009” with a score of 8.25 / 10 by a 5 member review panel.
GEC, Gandhinagar iv Sunil S Pillai

ACKNOWLEDGEMENT
Before we get into the thick of the thing, I would like to pen down a few words
for the people who made this possible.
First & foremost am thankful to Almighty GOD, for providing me all that I have,
for putting me in a good place & for guiding my efforts.
I would like to begin with Mrs. Neeta Mehta ma’am & Asst. Prof Chandresh R
Parekh of our college for nominating me for a project work at PRL. On similar Lines, am
thankful to Prof. A.K. Singhvi, Dean-Academics, PRL & his team for providing an
opportunity to work at PRL.
My utmost gratitude goes to my guide, Dr. Kuljeet Kaur Marhas. Her affectionate
& conducive nature could be accounted for as one of the major catalyst in the project
achieving its goals. Ma’am, the project owes itself to your vision, for without such a
requirement, it won’t be able to bag the title of “Best Trainee Project of the Year-2009”
at the review.
M.P.Deomurari Sir’s deep knowledge in electronics was quite helpful in the work
related to sensors. His detailed step by step approach is worth appreciation. I would like
to take this platform to express my heart felt gratitude towards Ritesh Mishra (PhD
student at Ion Probe Lab).
I am grateful to my sister Ms. Soumya Pillai (Software Executive-RISL) for

lending her technical expertise to the development of dashboard & web service. T.A.
Rajesh Sir (SPA-SC, PRL)’s experience in front end development came quite handy in
evolving the SIMS Monitoring System’s data logger.
The support lent by Mr. Dipak Panda, Mr. Pranav Adharyu (PGSDN-PRL), Mr.
Mannan & Lakhanji cannot go unmentioned. I would also like to mention Mr. Mathiyas
Crachiolli’s efforts in helping us to locate the points in the SIMS electronics from where
signals could be tapped for monitoring.
I would like to express sincere thanks to all the fellow trainees at PRL and to all
those who had participated in field trials of dashboard web service. Thanking you all for
taking out your valuable time.
Last but not least, I would like to remember all of those who directly or indirectly
made my stay at PRL, a smooth and pleasant affair.
Thanking You All.
Sunil S Pillai
GEC, Gandhinagar v Sunil S Pillai

LIST OF TABLES
Table 5.1 USB Device Stack Files … … … … … … 34

Table 5.2 CDC Device Driver Stack Files … … … … … 35
Table 5.3 USB Stack Functions … … … … … … 36
Table 5.4 USB Device Stack Macros … … … … … 36
Table 5.5 usb_function_cdc.h Functions … … … … … 37
Table 6.1 Parameters & their Associated Tables … … … … 46
Table 7.1 Duodetails Table Structure … … … … … 51

Table 7.2 Duomain Table Structure … … … … … 51
Table 7.3 Galden Flow Table Structure … … … … … 52
Table 7.4 Galden Level Table Structure … … … … … 52
Table 7.5 Lab Humidity Table Structure … … … … … 52
Table 7.6 Lab Temperature Table Structure … … … … 53
Table 7.7 Login Table Structure … … … … … … 53
Table 7.8 Pump Pressure Table Structure … … … … … 53
Table 7.9 Pump Speed Table Structure … … … … … 54
Table 7.10 Water Flow Table Structure … … … … … 54
Table 7.11 Water Level Table Structure … … … … … 54
Table 7.12 Lab Temperature Table Structure … … … … 55
GEC, Gandhinagar vi Sunil S Pillai

LIST OF FIGURES
Fig 1.1 Cameca IMS 4f Geometry … … … … … … 5
Fig 1.2 Duoplasmatron Structure … … … … … … 5
Fig 1.3 Primary Column … … … … … … … 6
Fig 1.4 Sample Chamber … … … … … … … 7
Fig 1.5 Electrostatic sector … … … … … … … 8
Fig 1.6 Entrance & Exit slits… … … … … … … 9
Fig 1.7 Quadrupole Mass Analyzer … … … … … … 10
Fig 1.8 Ion detectors … … … … … … … … 10
Fig 2.1 Modular System Diagram … … … … … … 12
Fig 3.1 Data Flow diagram of the System … … … … … 19
Fig 4.1 Oscillator Block Diagram … … … … … … 29

Fig 4.2 USB Block Diagram … … … … … … 31
Fig 5.1 Program Flow … … … … … … … 38
Fig 6.1 Data flow diagram of Data logger … … … … … 41
GEC, Gandhinagar vii Sunil S Pillai

Chapter 1
About Physical Research Laboratory

Physical Research Laboratory About Physical Research Laboratory
1.1 About Physical Research Laboratory

Known as the cradle of Space Sciences in India, the Physical Research
Laboratory (PRL) was founded in 1947 by Dr. Vikram Sarabhai. As a unit of the
Department of Space, Government of India, PRL carries out fundamental research in
select areas of Physics, Space & Atmospheric Sciences, Astronomy, Astrophysics &
Solar Physics, and Planetary & Geosciences.
The Laboratory was formally established on November 11, 1947, in the M. G.

Science College, Ahmedabad, with support from the Karmkshetra Educational
Foundation and the Ahmedabad Education Society. The initial focus was research on
Cosmic Rays and the properties of the Upper Atmosphere. Research in Theoretical
Physics and Radio Physics were added later with grants from the Atomic Energy
Commission.
The main campus at Navrangpura was inaugurated by Pt. Jawaharlal Nehru in

1954. In 1979 Infrared Telescope become operational at Mt. Abu. Udaipur Solar
Observatory became a part of PRL in 1980. PRL got an extension campus at Thaltej in
1990.
PRL recently conceptualized & implemented India’s first mission to moon,
Chandrayaan-1. Prof. J.N. Goswami was the principal scientist of this 400 crore maiden
mission of Govt. of India. PRL also developed a HEX (High Energy x-ray spectrometer)
payload for this mission
ACADEMIC DIVISIONS
• Astronomy And Astrophysics
• Planetary sciences Division
• Geosciences Division
• Space and Atmospheric Sciences
• Planetary Science & Exploration Program
• Theoretical Physics & Complex Systems
• Udaipur Solar Observatory
Fields of Research:
• Astronomy & Astrophysics • Solar Physics

• Quantum Optics & Quantum Information • Gravitation & Cosmology
• Space & Atmospheric Sciences • Particle Physics
• Nuclear, Atomic & Molecular Physics • Nonlinear Dynamics
• Planetary Sciences & Exploration • Earth Sciences
GEC, Gandhinagar 2 Sunil S Pillai

1.2 About Planetary Science Division

Research Programmes of this Division aim to understand the origin and evolution
of the Solar System, physical and chemical processes occurring on the Earth surface
reservoirs through analysis of isotopic, chemical and luminescence signatures
Research Programmes
1. Pre-Solar and Early Solar system processes;

2. Chemical and Isotopic studies on meteorites;
3. Catastrophic events in Earth's history;
4. Spatial and Temporal evolution of various landforms of India;
5. Paleoclimate, Paleomonsoon and Desertification on various time scales;
6. Chemical Weathering and Climate;
7. Ocean Circulation and Gas Exchange;
8. Aerosol Chemistry and Deposition;
9. Trace gases in the atmosphere;
10. Space based experiments;
11. Planetary Exploration: Chandrayaan-1 and beyond.
Facilities
Existing:
1. Thermal Ionization Mass Spectrometer (TIMS) ;

2. Liquid Scintillation Counter (LSC);
3. Alpha, Beta and Gamma detectors;
4. Secondary Ion Mass Spectrometer;
5. Stable Isotope Mass Spectrometer;
6. Gas Chromatography-Mass Spectrometery (GCMS);
7. Noble Gas Mass Spectrometer;
8. Ion Chromatograph;
9. Inductively Coupled Plasma- Atomic Emission Spectrometry (ICPAES);
10. CN-Analyzer;
11. Thermo-Optical EC-OC Analyzer;
12. SO2 Analyzer;
13. Atomic Absorption Spectrophotometry (Flame & GF).
14. Thermoluminescence (TL) & Optically Stimulated Luminescence (OSL) dating
systems;
New Additions (Along with PLANEX):

1. Multi-collector Noble gas mass spectrometer,
2. Nano SIMS,
3. Electron Probe Mass Analyzer (EPMA,)
4. Inductively Coupled Pulse Mass Spectrometer (ICP-MS )
5. XRF

Current Research
• Study of short-lived nuclides (26Al, 41Ca, 36Cl, 53Mn) in the early Solar System
objects to infer the time scales for the formation of the Sun and some of the first
solar system objects, and what they can tell about the origin of the Solar System.
• Study of radiogenic and stable isotopic anomalies and trace element abundances
in Calcium-Aluminum-Inclusions (CAIs)in meteorites to understand the
formation and evolution of the CAIs that are considered to be some of the first
Solar System solids.
• Study of nitrogen and noble gases in different types of meteorites to delineate the
various nitrogen and noble gas components present in the early Solar System
1.3 About Ion Probe Laboratory
The Ion Probe Laboratory was set up in 1990. The Lab is chaired by Prof J.N.
Goswami who also happens to be the director of PRL. The lab houses the Cameca’s IMS
4f Instrument, popularly referred to as SIMS (Secondary Ion Mass Spectrometer). The
working group comprises of Prof. J. N. Goswami, Dr. Kuljeet Kaur Marhas & M.P.
deomurari. The lab web page can be accessed at www.prl.res.in/~isotope.
1.4 About SIMS
The IMS 4f is an ion mass spectrometer capable of achieving very fine resolutions.
As any other mass spectrometer it gives the ratios of masses of different isotopes in the
sample. At ionprobe, SIMS is used to analyze meteoritic samples. After the sample is
mounted in the sample chamber, a primary ion beam is generated by the Duoplasmatron.
This beam travels through primary column where different lenses & deflectors are used
to control & manipulate the beam. When the beam of ions strikes the sample, it results in
a sputtering. This secondary beam then travels through the secondary column. The
secondary beam is controlled & manipulated with electromagnetic lenses & various slits.
At the end of the secondary column the beam is detected & analyzed with help of
electron multiplier, a Faraday cup, and two ion image detectors.
The detail of following major parts of SIMS is mentioned below.

1. Primary Ion Sources
2. Primary Ion Column
3. Secondary Ion Extraction and Transfer
4. Ion Energy Analyzers
5. Mass Analyzers
6. Secondary Ion Detectors

Fig 1.1 Cameca IMS 4f Geometry
1.4.1 SIMS Primary Ion Sources
The Duoplasmatron can operate with virtually any gas, but oxygen is the most
common because oxygen implantation into the sample surface enhances ionization
efficiency for electropositive elements. Before this oxygen enhancement effect was
discovered, argon was commonly used. The oxygen plasma within the Duoplasmatron
source contains both O- and O2+, and either can be extracted.
Fig 1.2 Duoplasmatron Structure

1.4.2 SIMS Primary Ion Column
Primary ions are extracted from the sources and passed to the sample through the
primary ion column. The column usually contains a primary beam mass filter that
transmits only ions with a specified mass-to-charge (m/z) ratio.
This mass filter eliminates impurity species in the beam. For example, Cr, Fe, and
Ni ions sputter from stainless steel surfaces within a duoplasmatron. Without a primary
beam mass filter, these metal contaminants deposit onto the sample surface, raising the
detection limits for stainless steel elements.
In the figure above, the electromagnetically active components are shown in blue.
The ion beam trajectories (indicated in red) are greatly exaggerated in the lateral
directions. The electrostatic lenses and the apertures control the intensity and width of the
primary ion beam. Several aperture diameters are usually available at each aperture
location.
DUOPLASMATRON
Cathode
Intermediate electrode
CESIUM SOURCE Coil
Anode
Extraction lens
Deflector 2
PBMF
Extraction lens
Deflector 2
Lens 2
Mass selection aperture
Deflector 1
Lens 1
Primary beam aperture
Stigmator
Faraday Cup
Deflector
Lens 3
Sample
Fig 1.3 Primary Column

The primary beam intensity can be reduced by defocusing the ion beam onto the
back of the first aperture (nearest the magnet). A narrow beam (at the sample) results
from defocusing the ion beam (with the middle lens) onto the back of the second
aperture, and then adjusting the last lens to transfer the image of the cross-over from
behind the aperture onto the sample.
Electrostatic deflectors steer the primary beam in a raster pattern onto the sample.
A finely focused and rastered primary ion beam delivers uniform primary beam intensity
to an area on the sample. This leads to flat bottom sputter craters. The best depth
resolution in a depth profile results when the secondary ions are sampled from the flat
bottom of such a crater without contributions from the crater edges. Other deflectors (not
shown) are located near the apertures. They help tune the primary beam through the
middle of the electrostatic lenses.
1.4.3 Secondary Ion Extraction and Transfer
Secondary ions are extracted from the sample as they are produced. If large mass
spectrometer components are held at ground potential, the sample must be held at high
voltage, the accelerating potential. The secondary ions accelerate toward the ground plate
of an electrostatic lens. This first lens is called the immersion or ion extraction lens. The
second (transfer lens) focuses the ion beam onto the mass spectrometer entrance slits or
aperture. This two lens system constitutes an ion microscope. The secondary ions could
be projected onto an image detector for viewing the sample surface. Different transfer
lenses produce different magnifications.
In the figure above, the electromagnetically active components are shown in blue.
The ion beam trajectories (indicated in red) are greatly exaggerated in the lateral
directions.
The field aperture is located

approximately at the point where the ion
beam image comes into focus. The
entrance aperture is sometimes called a
contrast diaphragm. Smaller aperture
diameters intercept ions with off-axis
energy components. This reduces image
aberrations but unfortunately it also
reduces secondary ion intensity.
Ions that arise from off the

secondary ion optical axis contribute to
lower mass resolution. These off-axis
ions arise because the primary beam
raster pattern sputters an area rather than
Fig 1.4 Sample Chamber

the single point where the axis intercepts the sample. The dynamic emittance deflectors
adjust the secondary ion beam back on-axis. The deflectors operate in synchrony with the
primary beam raster generator to provide continuous adjustment.
1.4.4 Ion Energy Analyzers
Electrostatic energy analyzers bend lower energy ions more strongly than higher
energy ions. The sputtering process produces a range of ion energies. An energy slit can
be set to intercept the high energy ions (shown in green).
Fig 1.5 Electrostatic sector
In the figure above, the electromagnetically active components are shown in blue. The
ion beam trajectories (indicated in red) are greatly exaggerated in the lateral directions.
Voltage offset is a strategy for enhancing monatomic ions over multiatomic. The
monoatomic ions have higher energy distributions. If the accelerating voltage is lowered
(offset), more of the atomic ions still have enough energy to pass through the energy slits.
In a typical SIMS experiment, the accelerating voltage is 4.5 kV, and the offset is 50 V.
The inner jaw of the slits intercepts most (low energy) multiatomic ions. Both monatomic
and multiatomic ion intensities are reduced in a voltage offset measurement, but
multiatomic ions relatively more than monoatomic.
The inner and outer sector electrodes have voltages of opposite polarity. Their
magnitude is about 10% of the ion accelerating voltage. The ion image comes into focus,
producing a virtual image inside the electrostatic sector behind the field aperture. The
active surfaces of the electrostatic sector are spherical. This geometry transfers the image
to the mass analyzer with minimal distortion. The spectrometer lens adjusts the ion beam
focus (cross over) to meet the input requirements of the mass analyzer.
1.4.5 Mass Analyzers
Dynamic SIMS instruments use two kinds of mass analyzers, magnetic sector and
quadrupole. Magnetic sector instruments are most common. As the ion beam passes
through the magnetic field, the particles are acted on by a force at right angles, both to the
direction of motion and to the direction of the magnetic field.

The following equation shows the relationship between the magnetic field (B), the ion
accerating voltage (V), the mass-to-charge ratio (m/q), and the radius of ion curvature (r)
in the magnetic field. In atomic units, m/q becomes m/z where z is the number of charges
on the ion.
Magnetic sector mass analyzer is shown in blue. The ion beam trajectories
(indicated in red) are greatly exaggerated in the lateral directions.
Modern mass spectrometers use non-normal pole faces for entrance and exit of
the ion beam to the magnetic sector. The fringings fields in this configuration compress
the ion beam in the vertical direction (in and out of the screen) as it passes through the
sector. Fewer ions strike metal surfaces and the ion beam focuses better at the exit slit
with non-normal pole faces. The entrance and exit slits can be arranged at ion beam
crossovers for the cleanest separation (highest mass resolution) between ions with similar
m/z values. The green part of the beam represents ions with higher m/z values that do not
pass through the spectrometer.
Fig 1.6 Entrance & Exit slits

The combination of a magnetic and an electrostatic sector produces a double
focusing instrument. A magnetic analyzer, by itself, introduces chromatic aberrations into
an ion beam with dispersed ion energies. These aberrations reduce mass resolution. In a
series arrangement of one electrostatic and one magnetic sector, the energy dispersion of
the electrostatic sector can just compensate the energy dispersion of the magnet. The
system will have the mass dispersive properties of the magnet, except that it will produce
higher mass resolution. The spectrometer lens adjusts the cross-over from the
electrostatic sector to the location required for the magnetic sector.
Quadrupole mass analyzers were invented in 1953. Many kinds of analysis,

including SIMS, employ quadrupoles. Ideally, the rods have hyperbolic shapes, but this
geometry can be approximated with closely spaced circular rods. In a typical quadrupole

spectrometer, the rods are 1 cm in diameter and 20 cm long. In the diagram, ions enter
from the left at a relatively low energy (~25 eV). Since SIMS ions can have a wider
energy range than 25 eV, electrostatic sectors usually precede the quadrupole.
Fig 1.7 Quadrupole Mass Analyzer
Alternating and direct voltages on the rods cause the ions to oscillate after
entering the quadrupole. For a given set of voltages, Ions with a single mass-to-charge
ratio undergo stable oscillation and traverse through the rods. All other ions have unstable
oscillations and strike the rods. The alternating frequency and the ratio between the
alternating and direct voltages remain constant. Scanning the voltages scans the mass
spectrum.
1.4.6 Secondary Ion Detectors
The most widely used SIMS instruments have as many as four detectors. These
include an ion counting electron multiplier, a Faraday cup, and two ion image detectors.
The following figure shows the arrangement of detectors. The ion counting electron
multipliers are the most sensitive detectors. They must be protected from intense ion
beams. The Faraday cup detector moves on a solenoid to cover the electron multiplier
when the incoming ion signal is too high. High energy neutral species form by charge
exchange when an ion beam strikes a surface.
These neutrals contribute noise to the ion signal.
If an electrostatic sector precedes the electron
multiplier, the neutrals can be eliminated from the
ion signal. Quadruple mass analyzers also use
electrostatic sectors or deflectors to minimize the
contributions of high energy neutral species to the
ion signal. The ion beam passes through a small
hole in the electrostatic sector when the sector is
deactivated. This path leads to dual micro channel
plate and resistive anode encoder image detectors.
The projector lenses bring an image of the sample
into focus on the image detectors. Fig 1.8 Ion detectors
Electromagnetically active components are shown in blue. The ion beam

trajectories (indicated in red) are greatly exaggerated in the lateral directions. In
particular, the image detectors are smaller and the path through the electrostatic analyzer
is narrower. The ions pass through a much smaller hole in the sector.

Chapter 2
INTRODUCTION
Physical Research Laboratory Introduction
2.1 OBJECTIVES
• To provide an integrated station to monitor all the Parameters of IMS 4f at a

single place.
• To monitor various Sub Systems of Mass Spectrometer and provide an Audio-

Visual Alarm.
• To remotely record various parameters & store them for later retrieval &
processing.
• To present the data in a User Friendly manner so as to improve the Operational

Efficiency of the unit and help in Fast Troubleshooting in times of Subsystem
failures.
The Following 17 parameters spread across 5 subsystems were required to be

monitored
Sub Systems
1. Duoplasmatron
a. To monitor the status of Arc (On/Off)
b. To monitor and record the Beam current.
2. Galden
a. To monitor the flow of Galden
b. To monitor the level of Galden in the Sump
3. Pumps
a. To monitor the pressure(Vacuum) of rotary pump
b. To monitor the rpm of four Turbo Pumps catering to:
i. Duoplasmatron
ii. Primary Column
iii. Sample Chamber
iv. Sample Changing Chamber
c. To monitor the pressure of two Ion Pumps.
4. Water Chiller
a. To monitor water flow through the system
b. To monitor water level in the chiller unit.
c. To monitor water temperature in the chiller unit
5. Lab
a. To monitor the temperature of Lab
b. To monitor the Humidity of the Lab.

2.2 MODULAR APPROACH

The approach was to develop a highly modular System to achieve the fore stated
objectives. The desired system was divided into four modules
1) Transducer & Transmitter Module
2) Data Collection Module
3) Data Storage Module
4) Display & Alerter Module
Display
Transducers Data Data
&
& Collection Storage
Alerter
Transmitters System Solution
Systems
Fig 2.1 Modular System Diagram
A modular system had imminent advantage of allowing simultaneous

development, effective troubleshooting & minimal interdependence. This also allowed
each module to be developed using different technology platforms. For effective
integration of the system all that was required was to build effective interfaces between
the modules. This led to an increase in overall efficiency of the system.
To monitor the target parameters a standard master slave approach was chosen.
Hereby a central data acquisition board was to be built. All the sensors & transducers
would be on the respective slave boards at an optimum location with respect to their
target parameters. The central DAQ board would have the responsibility to collate the
data from these boards.
2.2.1 Transducer & Transmitter Module
• This module comprises of different slave sensor boards designed to measure one
or many of the target parameters.
• The slave sensor boards would be located as close as possible or at an optimum

distance from the target parameter.
• The measuring principle applied should be such so as to cause minimum

interference with the SIMS viz electric, magnetic or noise fields. Also it should
not impact, degrade or change the parameter being measured
• The slave sensor boards should include signal processing so as to maintain the
desired characteristics of signal till it reaches the Central DAQ collector board.

• The slave sensor boards should transmit data continuously or when requested by
the DAQ collector board with minimum latency.
• The slave sensor boards should provide power to all its on board electronics &
should not draw any power (or minimal power (current) if absolutely required)
from the SIMS machine.
• The slave sensor boards should ensure adequate isolation between:

1) itself & the SIMS machine
2) itself & the DAQ board
2.2.2 Data Collection Module
• This module consists of a central DAQ board.
• It has the responsibility to periodically gather the data from the slave boards.
• It should provide for attaching more number of slave boards as may be required in
the future i.e. port expansion capability.
• It should do the required processing like A-to-D conversion & present the data in
a format acceptable to the storage solution
• It should provide for a low BER, low latency, high speed, high bandwidth method
of transmission to data storage system
• It should (if required) provide for adequate isolation between:
1) itself & the slave boards (input ports)

2) itself & the data storage system (output port)
• A microcontroller based platform was chosen to develop a custom DAQ board.
• USB 2.0 was chosen as the interface between DAQ & data storage system due to
its several advantages like plug & play, high compatibility, high bandwidth, high
speed, low BER et al.
2.2.3 Data Storage Module
• It should provide for adequate storage space.
• The data should be easily accessible.

• It should be easy to retrieve the data & transport it to other physical systems.
• Data storing should not be interrupted while the data is being accessed.
• Considering the huge space requirement & the easy availability of computers,
data storage solution is usually implemented on a pc.
• This provides for several advantages like no need to physically replace the
EEPROMS /chips, storage space in excess of GBs, all standard data transport
mechanisms available et al.
• Advanced data management softwares could be utilized on PCs for efficient &
orderly maintenance of data.
• PC based data storage systems are highly user friendly.
2.2.4 Display & Alerter Module
• It should display the data in a meaningful & easy to interpret.
• It should provide for charts & other analytic tools to aid in speedy & complete
extraction of information.
• It should display data in real time.
• It should provide for remote viewing of the data.
• Use of data visualization package was deemed to be required for a graphical

display of data.
• For remote viewing it was decided to utilize the services offered by state-of-art
LAN network of PRL.
2.3 PROJECT MANAGEMENT
Detailed deliberations with departmental Engineers led to a conclusion that the

project was too big to be realized in a five month span. Hence it was decided to divide the
project into phases & implement at least one of the phase, the remaining to be completed
at a later schedule.

An important factor in deciding the phasing of project was the SIMS. The SIMS machine
is operated continuously day & night. Even when it is not analyzing the pumps and most
of other subsystems have to be kept running to maintain the operating conditions. For
e.g. Sims operates at close to 10-9 torr. Once the vacuum is lost it takes close to two days
for the pumps to reclaim the vacuum. This meant that SIMS electronics was not available
for analysis & sensor development. The SIMS has the state-of-the-art electronics of the
90’s. It comprises of over 140 boards housed in four panels spanning 5 meters. This led
to division of the project into two phases.
1) Phase-1 Development of Backbone System.
2) Phase-2 Development of Sensor Systems.
2.3.1 BACKBONE SYSTEM
• It comprises of the three modules of the system: Data Collection, data storage &
data display.
• It involved the entire data flow from the DAQ board to USB interface to data
Storage on the PC & thereafter to the Display service over the LAN.
• It was expected to be completed in the five months duration.
• It is meant to provide interfaces for integration of the slave board as & when they
are developed.
2.3.1 SENSOR SYSTEMS
• It comprises of the transducer & transmitter module.
• It is to be developed when SIMS could be made available for development work.
• All sensor systems are expected to be completed in 2 years time.
• As & when a sensor board is developed it is to be connected to the DAQ board &
integrated with the whole system.

Chapter 3
SYSTEM
Physical Research Laboratory System
3.1 OVERVIEW
This chapter provides a bird’s eye view of the complete system. Physically the
system consists of three components:
1) The sensor boards (to be implemented in 2nd phase)
2) The DAQ board (referred to herein as the hardware board)
3) The server PC with applications running on it.
The target parameters are sensed by the mechanisms on the Sensor boards. The
data from all sensor boards is collected by the central hardware board. This data could be
in form of analog or digital TTL signals. The central board provides for 8 analog
channels & 16 Digital channels.
The PIC 18f4550 on the Central DAQ Board does all the processing work. It also
implements the USB Protocol framework. The packetised data is now ready to be sent to
the server PC via USB cable. At PC device drivers take care of interfacing with the
board.
Hereafter a Front end Logging Application, The SIMS Monitoring System takes
on. It validates the received data, decodes it and logs it into a MS ACCESS database. It
also applies a Smart sense for effective data logging.
The ionprobe.mdb database stores the received data. It is organized in form of 12

tables. Each table is dedicated to a single or a group of parameters. The datasets are
appended in form of rows at the end of tables.
A dashboard website has been developed for allowing remote viewing of the data.
Being an Intranet application, user can log into this SIMS Monitoring Site using any
system connected to the PRL LAN. A PC at the ionprobe lab has been turned into a local
server for hosting this web application. The current URL of the SIMS Monitoring Site is
http://172.16.13.153/dashboard_prl/login.aspx.
User authentication is done in the login page. The dashboard page displays the
current status data with the help of gauges & charts. The site automatically refreshes
every 40 seconds
The Site also provides a chart panel. The data can be analyzed remotely using the
charts. Graphs can be generated of any parameter for any given time interval. Three
charts can be viewed simultaneously.
The hardware, firmware, data logger, database & dashboard website are discussed
in comprehensive detail in separate chapters.

PC, ION PROBE LAB LOCAL SERVER
Data Logger Database Data Visualization

VB.NET MS Access Dundas
USB 2.0 Web Service

MCHPCDC IIS
Driver ASP.NET
USB SIE Orcad

Hardware Board
PRL
•MPLAB IDE 8 Analog
LAN
•MCHPFSUSBv2.4 Channels Sensor
•MCCC18 Boards
16 Digital
•PICKIT2 Channels IMS 4F
PIC 18f4550 User

Browser
Fig 3.1 Data Flow diagram of the System
Note: 1) Italics denote the software platforms used

2) Sensor boards on IMS 4f will be implemented in the next phase of the project.

3.2 HARDWARE BOARD
The hardware board is a 24 channel data Acquisition board based around the PIC
18f4550 microcontroller from Microchip Inc. The PIC 18f4550 is a 40 pin DIP package.
The PIC 18f4550 collects data one by one from all 24 channels, processes them &
converts them in a format suitable for transmission over the USB cable to the PC.
The board provides for 8 analog input channels & 16 digital input channels. To
conserve microcontroller pins, multiplexers have been used. 74LS150 is a 16-to-1 digital
multiplexer catering to the digital input channels. Analog channels are obtained by using
DG408 8-to-1 Analog multiplexer. PIC 18f4550 has an onchip 10-bit ADC. The
microcontroller also sports a 5 pin ICSP port for programming. A mini USB port is
provided for connecting the USB cable.
The PIC has to first poll through the 16 digital channels acquiring the state of
each digital channel. Thereafter it polls through the 8 analog channels performing an
ADC conversion on each channel using the internal ADC engine. Then a suitable format
is decided upon to transmit the data via the USB.
The PIC 18f4550 provides a Serial Interface Engine (SIE) for serial transmission
of data. It also features an inbuilt USB transceiver capable of full speed USB
transmission. The USB framework is coded into the microcontroller.
A 1.5m USB cable connects the board to the PC. USB is operated in
Communications Device Class (CDC) mode at a full speed of 12Mbps. The CDC driver
MCHPCDC is provided by Microchip. The USB provides true Plug & Play capabilities in
that it can be attached or detached without rebooting the server. The use of USB lends
several other advantages to the system detailed in Chapter 4 on Hardware.
The onchip USB engine then takes the data from its input buffer & dumps them
on to PC as soon as the protocol allows for it. The data can also be explicitly sent to the
USB using the custom functions available in the Microchip Application libraries. At PC
the data is then decoded, processed & stored for further operations. Since USB is a
bidirectional bus, the PIC Microcontroller can also receive data & commands from the
PC
The PIC also allows for an external USB transceiver to be used. However using
external transceiver option requires 6 pins of the microcontroller to be dedicated for USB
Transmission. The use of Internal Transceiver dictates dedicating only two pins for
transmission purposes. The external transceiver option is handy when application
demands isolation between PC & hardware board.
The board houses a 20MHz crystal. However full speed USB operation requires a
stable clock of 48MHz. This is obtained from the 20MHz input using pre & post scalers
with a PLL. The microcontroller runs at a frequency of 20MHz.

3.3 ION PROBE LOCAL SERVER
A PC has been earmarked for this system. It runs the Internet Information Server
(IIS) along with all the software applications of this system. Mainly three pieces of
system software are residing on the PC:
1) Data Logger (Windows Console Application)
2) Database (MS ACCESS)
3) Dashboard Web Service (Visual Studio 2005 –ASP.NET)
The data from the hardware board is received via the USB. Microsoft Windows
has built in support for the USB. On attaching the USB cable from hardware board to the
pc, Windows automatically tries to find the appropriate driver, MCHPCDC in our case, &
installs it. The MCHPCDC driver provides for an Application Programming Interface
(API). It emulates a virtual com port & pools all USB data to this Virtual Serial Port. The
data logger application then accesses this com port to obtain the data.
3.3.1 DATALOGGER
Once the data has been sent to the PC, we need a utility on the PC to receive this
data. Usually a device driver takes care of the lower level details of the protocol. The
front end application has to interface with the driver API. The MCHPCDC driver creates
a Virtual Com port for the Front end Applications
Visual Studio provides for a MSCOMM class that makes working with Com ports
easy. The SIMS Monitoring System data logger is a Windows Console application
created with Visual Studio 2005 in VB language. Set in Black background, the data
logger has a user friendly interface.
It has a drop down listbox containing the list of available com ports. Once the
appropriate com port has been chosen, clicking on the Connect button takes the program
to the main loop.
The data logger tries to open the selected Com Port. On successful connection the
application reads from the Serial Port Buffer. Now this speed with which the Front end
Application reads the buffer determines the Actual rate of data transmission. This is so
because the buffer has a limited capacity, hence until the last data is read, new data is not
loaded into buffer. To avoid any loss of data, the microcontroller always waits for the last
transaction to be complete before sending in new data.
The received data string is displayed in a text box at the bottom. The data is then
checked for validation. On validation, the received string is decoded to extract
meaningful information. The parameter values so extracted are then displayed in

appropriate textboxes. Simultaneously they are logged with a timestamp into their
respective tables in the database.
The speed of data logger is influenced by the capacity of the system on which it is
running. On a P4 system running at 2.4GHz with 1GB RAM, with no other process
active, the SIMS monitoring System could log 12 records every second. However at
normal load on PC, the logging rate was found to be averaging at 6 insertions per second.
3.3.2 MICROSOFT ACCESS DATABASE
The database implemented in MS ACCESS stores the acquired values. These

values are retrieved by the Dashboard Web service. The ionprobe.mdb located in the
dashboard_prl folder is the database file of the system.
The database is arranged in form of tables. Each new dataset is appended as a new
row at the end of the table. As such ACCESS does not put on a limit on the number of
rows in a table. In practice using a long integer as a primary key puts a limit of 232 rows.
With an average logging speed of 6 rows per second, it would take 11.5 years (or 139
months) to exhaust a table of 232 rows.
The database has the following 12 tables.
1) DuoDetails : stores the on/off details of particular Duoplasmatron.
2) Duomain : stores the records of all Duoplasmatrons used
3) Galden Flow : stores the status of flow of Galden through the instrument.
4) Galden Level : stores the level of Galden in the sump.
5) Lab Humidity : stores the humidity levels of the lab
6) Lab Temperature : stores the temperature levels of the lab.
7) Login : stores userids, passwords & usernames for login purposes.
8) Pump Pressure : stores the pressure values of various pumps
9) Pump Speed : stores the speed values of various pumps.
10) Water Flow : stores the status of flow of water through the instrument
11) Water Level : stores the level of water in the Chiller.
12) Water Temp : stores the temperature of the water

The details of the fields of the tables & their formats are covered in
comprehensive detail in Chapter 7 on Database.
3.3.3 DASHBOARD WEB SERVICE
To allow for remote viewing of data, a web service has been created. A pc in the
ion probe lab has been deemed as a local server running the Internet Information Server
(IIS). The SIMS Monitoring Site (http://172.16.13.153/dashboard_prl/login.aspx) has
been custom developed for the purpose of displaying Data Acquisition results. The site
uses xhtml & is developed using Visual Studio.NET 2005 (ASP.NET) in C# (C Sharp)
language.
The site has been developed as a dashboard website. A Dashboard Website offers
a central access to all the Data in one Single Pane. Dundas Data Visualization Inc’s
Dundas Gauge & Chart Controls for ASP.NET have been used to provide data
visualization.
The SIMS monitoring site has only two pages:

1) Login page
2) Dashboard page.
The login page is the startup page. It provides for authentication of the user. It
prompts the user to enter the Employee ID & password. This is then matched with entries
in login table of the ionprobe database. On successful authentication the login page is
closed & dashboard page is opened in a new window in full screen mode. This is to
maximize the screen size available for the dashboard.
The dashboard page has two panels, a Gauge Panel & a Chart panel. The page
automatically refreshes after a predefined time interval. Currently the refresh interval is
set to 40 seconds.
These panels can be accessed by two tabs at the top:

1) Main tab for Gauge panel
2) Details tab for Chart Panel
The main tab displays the current status of the machine. It displays in real time the
values of 17 parameters. To do so, it utilizes a number of Gauges & other numeric &
state indicators. The page has two text rows at the top followed by two rows of gauges.
The name of the logged-in user is displayed at the right end in the first row (for
e.g. “Welcome Dr. Kuljeet Kaur”). The second row is meant to provide one line status of
the whole machine. It will indicate if any of the subsystems require attention. If
everything is ok it will declare SIMS to be in good health.

The details of the different gauges on the main tab of dashboard page are as
follows.
1) Duoplasmatron Vacuum Gauge
It displays the vacuum at Duoplasmatron in units of torr in form of a
circular gauge with numeric indicator displaying the value up to two decimal
digits.
2) Tc1 Rotary Vacuum Gauge

It displays the vacuum generated by rotary pump in primary column in
form of a circular gauge in units of torr with numeric indicator displaying the
value up to two decimal digits.
3) Tc2 Sample Chamber Vacuum Gauge

It displays the vacuum generated by rotary pump at the sample chamber in
form of a circular gauge in units of torr with numeric indicator displaying the
value up to two decimal digits.
4) Entry Slit Arm Ion Pump Pressure Gauge

It displays the vacuum generated by ion pump at the entry slit arm in form
of a circular gauge in units of torr with numeric indicator displaying the value
up to two decimal digits.
5) Exit Slit Ion Pump Pressure Gauge

It displays the vacuum generated by ion pump at the exit slit arm in form
of a circular gauge in units of torr with numeric indicator displaying the value
up to two decimal digits.
6) Galden Flow Gauge

It displays the flow of Galden in the instrument in form of a linear gauge
with a numeric Indicator displaying the text ‘LOW’ or ‘OK’ as per the case.
7) Galden Level Gauge

It displays the level of Galden in the Sump in form of a linear gauge with a
numeric Indicator displaying the text ‘LOW’ or ‘OK’ as per the case
8) Duoplasmatron Hour Gauge.

It displays the number of the hours Duoplasmatron has been put on in
form of a circular gauge with a 3 digit numeric indicator displaying the exact
value.

9) Duoplasmatron Turbo Pump Speed Gauge

It displays the speed of turbo pump serving the Duoplasmatron in units of
rpm in form of a circular gauge with a 5 digit numeric indicator displaying the
exact value.
10) Primary Column Turbo Pump Speed Gauge

It displays the speed of turbo pump serving the Primary Column in units
of rpm in form of a circular gauge with a 5 digit numeric indicator displaying
the exact value.
11) Sample Chamber Turbo Pump Speed Gauge

It displays the speed of turbo pump serving the Sample Chamber in units
of rpm in form of a circular gauge with a 5 digit numeric indicator displaying
the exact value.
12) Sample Changing Chamber Turbo Pump Speed Gauge

It displays the speed of turbo pump serving the Sample Changing
Chamber in units of rpm in form of a circular gauge with a 5 digit numeric
indicator displaying the exact value.
13) Water Temperature Gauge

It displays the temperature of Water in the chiller in units of oC in form of
a linear gauge with a 3 digit numeric indicator displaying the exact value up to
1 decimal place.
14) Lab Temperature Gauge

It displays the temperature of Lab in the chiller in units of oC in form of a
linear gauge with a 3 digit numeric indicator displaying the exact value up to 1
decimal place.
15) Lab Humidity Gauge

It displays the relative humidity of lab in the chiller in units of percentage
in form of a linear gauge with a 3 digit numeric indicator displaying the exact
value up to 1 decimal place.
16) Water Flow Gauge

It displays the flow of Water in the instrument in form of a linear gauge
with a numeric indicator displaying the text ‘LOW’ or ‘OK’ as per the case
17) Water Level Gauge

It displays the level of water in the Chiller in form of a linear gauge with a
numeric indicator displaying the text ‘LOW’ or ‘OK’ as per the case

The details tab provides for 3 integrated chart containers. These can be used to
analyze the data of any parameter for any given time interval.
Since each chart can display more than one parameter, a drop down box has been
provided for parameter selection. Upon selecting a parameter, the page automatically
reloads to display the selected parameter data. The parameters available in each Chart
container are as shown below:
1) Pump Chart Container

• Rotary1
• Rotary2
• Turbo1
• Turbo2
• Turbo3
• Turbo4
• Ion1
• Ion2
2) Duoplasmatron Chart Container

• All the Duoplasmatrons used so far
3) Temperature/ Humidity Chart Container

• Water Temperature
• Lab temperature
• Lab humidity
The values are plotted against the timestamp. The y-axis automatically takes a
range suitable to accommodate all the data points to be displayed. The X-axis (date &
Time) can be zoomed in or out by selecting appropriate time interval.
Using Java Script a calendar has been built providing the facility of date picker.
The User can select the Start date & End date using this date picker. All the charts on the
page will then display the data for the selected period. The default end date is the current
date & default start date is one month in the past from the current date.
More information on the exact implementation of dashboard is available in the
chapter 6 on dashboard.

Chapter 4
HARDWARE
Physical research Laboratory Hardware
4.1 OVERVIEW
The implemented hardware portion is the DAQ board. The ICs used in developing
this board are:
i. PIC 18f4550
ii. 74LS150
iii. DG408
The use of optoisolators should be considered for isolating the input channels
from the board. It provides for 16 channels to be connected. It has a 5 pin ICSP port for
programming. It carries an AB type USB port for connecting to PC. The input channels
are implemented using multiplexers. The 74LS150 is a 16-to-1 Digital multiplexer. The
four select lines are connected to Pins 19-22. The input from 74ls150 is received at Pin
33(Port B.0). The DG408 is a 8-to-1 Analog Multiplexer. The three select lines are
connected to Pins 27-29. The analog input from DG408 is connected to ADC channel 0,
(pin 2).
4.2 PIC 18F4550

The PIC 18f4550 is a 8-bit microcontroller from Microchip Inc packaged in a
40pin DIP.
Universal Serial Bus Features:
• USB V2.0 Compliant
• Low Speed (1.5 Mb/s) and Full Speed (12 Mb/s)
• Supports up to 32 Endpoints (16 bidirectional)
• 1-Kbyte Dual Access RAM for USB
• On-Chip USB Transceiver with On-Chip Voltage Regulator
Regular Features:
• Operating Frequency DC – 48 MHz
• Program Memory (Bytes) 32768;
• Program Memory (Instructions): 16384
• Data SRAM Memory (Bytes) 2048:
• Data EEPROM Memory (Bytes) 256
• Instruction Set: 75 Instructions; 83 with Extended Instruction Set
• 20 Interrupt Sources
• I/O Ports :Ports A, B, C, D, E
• 4 Timers
• 10-Bit Analog-to-Digital Module :13 Input Channels
• 2 Capture/Compare/PWM Modules
• Serial Communications: MSSP, Enhanced USART
• Streaming Parallel Port (SPP)
• 2 Comparators

4.2.1 Oscillator Settings
Full speed USB operation requires a stable clock of 48 MHz. A 20 MHz crystal is
connected to pins 13 & 14 of the PIC 18F4550. This input is given to the on chip PLL via
a Prescaler. The PLL requires an input of 4 MHz & gives an OUTPUT of 96 MHz. hence
the prescaler is used to divide the 20 MHz input by 5. A postscaler then divides the PLL
output by two to give 48 MHz to USB engine.
Fig 4.1 Oscillator Block Diagram

The microcontroller core can be driven at desired frequency using any of the following
sources:
• The Primary Oscillator, Connected to pins 13 & 14
• The PLL output,
• The Secondary Oscillator, Connected to pins 15& 16.
• The Internal RC oscillator.
The microcontroller core runs at 20MHz, while the USB module runs at 48MHz.
4.2.2 ADC Settings
The 18F4550 has 13 channel 10bit ADC. The module has five registers:
• A/D Result High Register (ADRESH)
• A/D Result Low Register (ADRESL)
• A/D Control Register 0 (ADCON0): controls the operation of the A/D module.
• A/D Control Register 1 (ADCON1): configures the functions of the port pins.
• A/D Control Register 2 (ADCON2): configures the A/D clock source,
programmed acquisition time and justification.
The analog reference voltage is software selectable to either the device’s positive and
negative supply voltage (VDD and VSS) or the voltage level on the RA3/AN3/VREF+
and RA2/AN2/VREF-/CVREF pins.
The following steps should be followed to perform an A/D conversion:
1. Configure the A/D module:
• Configure analog pins, voltage reference and digital I/O (ADCON1)
• Select A/D input channel (ADCON0)
• Select A/D acquisition time (ADCON2)
• Select A/D conversion clock (ADCON2)
• Turn on A/D module (ADCON0)
2. Configure A/D interrupt (if desired):
• Clear ADIF bit
• Set ADIE bit
• Set GIE bit
3. Wait the required acquisition time (if required).
4. Start conversion:
• Set GO/DONE bit (ADCON0 register)
5. Wait for A/D conversion to complete, by either:
• Polling for the GO/DONE bit to be cleared
OR
• Waiting for the A/D interrupt
6. Read A/D Result registers (ADRESH:ADRESL);clear bit ADIF, if required.
7. For next conversion, go to step 1 or step 2, as required. The A/D conversion time per
bit is defined as TAD. A minimum wait of 3 TAD is required before the next acquisition
starts.

4.2.3 USB Settings

The SIE can be interfaced directly to the USB, utilizing the internal transceiver, or
it can be connected through an external transceiver. An internal 3.3V regulator is also
available to power the internal transceiver in 5V applications.
The operation of the USB module is configured and managed through three
control registers. In addition, a total of 22 registers are used to manage the actual USB
transactions. The registers are:
• USB Control register (UCON): controls the module behavior during transfers.
• USB Configuration register (UCFG): configures the module’s associated internal
and/or external hardware
• USB Transfer Status register (USTAT): reports the transaction status within the
SIE
• USB Device Address register (UADDR): contains the unique USB address that
the peripheral will decode when active.
• Frame Number registers (UFRMH:UFRML): contain the 11-bit frame number.
• Endpoint Enable registers 0 through 15 (UEPn) independent control register for
each endpoint
Fig 4.2 USB Block Diagram

4.3 Circuit Diagram

Chapter 5
FIRMWARE
Physical Research Laboratory Firmware
5.1 OVERVIEW
The firmware has been developed using Microchip’s MPLAB IDE v8.20. The
coding has been done in C language. Microchip’s C18 Compiler was used for compiling
the project. The USB framework has been coded onto the microcontroller. The
Microchip’s USB Framework v2.4 – MCHPFSUSBv2.4 has been utilized for this
purpose. Microchip’s latest Application Libraries came handy in developing the code.
MPLAB produces two main files:
1) The Microchip Workspace File(.mcw)
2) The Microchip Project File (.mcp)
This section lists the files required for use with the device stack. These files
should be included in any project using the USB device stack
Name Description
Uusb_device.c This file contains functions, macros, definitions, variables, datatypes,
etc. that are required for usage with the MCHPFSUSB device stack.
This file should be included in projects that use the device stack.
This file is located in the "<Install Directory>\Microchip\USB"
directory.
usb.h This is file usb.h.
usb_ch9.h This file defines data structures, constants, and macros that are used to
to support the USB Device Framework protocol described in Chapter
9 of the USB 2.0 specification.
usb_common.h This file defines data types, constants, and macros that are common to
multiple layers of the Microchip USB Firmware Stack.
usb_device.h This file, with its associated C source file, provides the main
substance of the USB device side stack. These files will receive,
transmit, and process various USB commands as well as take action
when required for various events that occur on the bus.
usb_hal.h This file abstracts the hardware interface.
usb_hal_pic18.h This file abstracts the hardware interface. The USB stack firmware
can be compiled to work on different USB microcontrollers, such as
PIC18 and PIC24. The USB related special function registers and bit
names are generally very similar between the device families, but
small differences in naming exist.
usb_config.h usb_config.h is a file used to configure the MCHPFSUSB stack. This
file provides compile time selection of options provided by the stack.
This file defines constants needed by the stack and various function
drivers.
HardwareProfile.h HardwareProfile.h is a file used to define hardware specific
definitions that are required by the MCHPFSUSB stack. This file
should be modified to match the application hardware.
Table 5.1 USB Device Stack Files

This section lists the files required for use with the CDC Device Driver stack.
Name Description
usb_function_cdc.h This file contains all of functions, macros, definitions, variables,
datatypes, etc. that are required for usage with the CDC function
driver. This file should be included in projects that use the CDC
function driver. This file should also be included into the
usb_descriptors.c file and any other user file that requires access to
the CDC interface.
This file is located in the "<Install

Directory>\Microchip\Include\USB" directory.
usb_function_cdc.c This file contains all of functions, macros, definitions, variables,
datatypes, etc. that are required for usage with the CDC function
driver. This file should be included in projects that use the CDC
function driver.
This file is located in the "<Install Directory>\Microchip\USB\CDC

Device Driver" directory.
Table 5.2 CDC Device Driver Stack Files
The table below describes the various Functions from the USB Stack files.
Name Description
USBDeviceInit This function initializes the device stack it in the default
state. The USB module will be completely reset including
all of the internal variables, registers, and interrupt flags.
USBDeviceTasks This function is the main state machine of the USB device
side stack. This function should be called periodically to
receive and transmit packets through the stack. This function
should be called preferably once every 100us during the
enumeration process. After the enumeration process this
function still needs to be called periodically to respond to
various situations on the bus but is more relaxed in its time
requirements. This function should also be called at least as
fast as the OUT data expected from the PC.
USBEnableEndpoint This function will enable the specified endpoint with the
specified options
USBCBInitEP This function is called whenever the device receives a
SET_CONFIGURATION request.
USBCBSuspend Call back that is invoked when a USB suspend is detected.
USBCBWakeFromSuspend This call back is invoked when a wakeup from USB suspend
is detected.
USBCBCheckOtherReq This function is called whenever a request comes over
endpoint 0 (the control endpoint) that the stack does not

know how to handle.

USBCBSendResume This function should be called to initiate a remote wakeup.
(optional)
USBCBErrorHandler This callback is called whenever a USB error occurs.
(optional)
USBCBStdSetDscHandler This callback is called when a SET_DESCRIPTOR request
is received (optional)
USBCB_SOF_Handler This callback is called when a SOF packet is received by the
host. (optional)
USBCBEP0DataReceived This function is called whenever a EP0 data packet is
received. (optional)
Table 5.3 USB Stack Functions
The Table below describes the various Macros available from the USB Device
Stack Files.
Name Description
USBGetDeviceState This function will return the current state of the device on
the USB. This function should return
CONFIGURED_STATE before an application tries to
send information on the bus.
USBGetRemoteWakeupStatus This function indicates if remote wakeup has been
enabled by the host. Devices that support remote wakeup
should use this function to determine if it should send a
remote wakeup.
USBIsDeviceSuspended This function indicates if this device is currently
suspended. When a device is suspended it will not be able
to transfer data over the bus.
USBHandleBusy Checks to see if the input handle is busy
USBHandleGetAddr Retrieves the address of the destination buffer of the input
handle
USBHandleGetLength Retrieves the length of the destination buffer of the input
handle
Table 5.4 USB Device Stack Macros
These are the functions used for sending & receiving data defined in the
usb_function_cdc.h File
Name Description
CDCInitEP This function initializes the CDC function driver. This function
should be called after the SET_CONFIGURATION command.
CDCTxService CDCTxService handles device-to-host transaction(s). This function
should be called once per Main Program loop after the device reaches
the configured state.

getsUSBUSART getsUSBUSART copies a string of BYTEs received through USB

CDC Bulk OUT endpoint to a user's specified location. It is a non-
blocking function. It does not wait for data if there is no data
available. Instead it returns '0' to notify the caller that there is no data
available.
putrsUSBUSART putrsUSBUSART writes a string of data to the USB including the
null character. Use this version, 'putrs', to transfer data literals and
data located in program memory.
putsUSBUSART putsUSBUSART writes a string of data to the USB including the null
character. Use this version, 'puts', to transfer data from a RAM
buffer.
putUSBUSART putUSBUSART writes an array of data to the USB. Use this version,
is capable of transfering 0x00 (what is typically a NULL character in
any of the string transfer functions).
Table 5.5 usb_function_cdc.h Functions
5.3 PROGRAM EXECUTION
The C18 compiler starts off at C018i.c File. The entry point being void_entry
(void) function. This makes a call to _startup function coded in asm. This Initializes the
stack pointer & loads the table pointers. Then it calls the _init function. If user defined
__init is not found, the one in clib.lib will be used
Now the execution jumps to void main (void) function in Main.c. It is the main
Program loop. It does all the work by calling three functions.
1. InitializeSystem()
2. UsbDeviceAttach()
3. ProcessIO()
Application Specific Tasks can be added here or in ProcessIO() function. The first
function encountered in main() is InitializeSystem(). This function initializes the whole
system. It has two functions:
1. Userinit:
User can put in here the initialization code. It calls mInitAllLed()
which initializes the leds.
2. UsbDeviceInit
Usb device initialization code resides here. It does the following :
1 Clears all USB error flags & USB interrupts.
2 Resets all of the Ping Pong buffers
3 Clears all of the endpoint control registers: for this jump is
made to memset.asm file.
4 Clears all of the BDT entries
5 Initializes EP0 as a Ctrl EP
6 Flushes any pending transactions
7 Clears all of the internal pipe information

8 Makes sure packet processing is enabled

9 Gets ready for the first packet
The UsbDeviceAttach() Function takes care of device attach & detach procedures.
It does the following
1 Masks all USB interrupts
2 Enables module & attach to bus
3 Enables/sets things like: pull ups, full/low-speed mode, set the
ping pong mode, and set internal transceiver
_entry()
c018i.c
_startup()
c018i.c
_init() Main()
clib.libc main.c
InitialiseSystem() UsbDeviceAttach() ProcessIO()

main.c Usb_device.c main.c
UserInit() USBDeviceInit()
main.c Usb_device.c BlinkUsbStatus()
main.c
mInitAllLEDs() Memset()
main.c memset.asm
Fig 5.1 Program Flow

The ProcessIO processes the input –output. It sends data to the USB as well as
includes the code for receiving data. Application specific user tasks are also included in
this function. It includes code for polling through the channels, Code for ADC, code for
forming the packet to be sent & finally the code for sending the data.
5.4 LIST OF FILES
The following list mentions the library files required for this project.
5.4.1 SOURCE FILES

1. c018i.c (/MCC18/src/traditional/startup/c018i.c)
2. memset.asm (/MCC18/src/traditional/stdclib/memset.asm)
3. main.c (Project Directory)
4. usb_descriptors.c (Project Directory)
5. usb_device.c (/Microchip/USB)
6. usb_function_cdc.c (/Microchip/USB/CDC Device Driver)
5.4.2HEADER FILES
1. GenericTypeDefs.h (/Microchip/Include)
2. Compiler.h (/Microchip/Include)
3. usb_config.h (Project Directory)
4. usb_device.h (/Microchip/Include/USB)
5. usb.h (/Microchip/Include/USB)
6. usb_function_cdc.h (/Microchip/Include/USB)
7. HardwareProfile.h (Project Directory)
8. HardwareProfile-p18f4550.h (Project Directory)
9. usb_ch9.h (/Microchip/Include/USB)
10. usb_common.h (/Microchip/Include/USB)
11. usb_hal.h (/Microchip/Include/USB)
12. usb_hal_pic18.h (/Microchip/Include/USB)
13. adc.h (/MCC18/h)
14. p18f4550.h (/MCC18/h)
5.5 CONCLUSION
The Firmware with implementation of USB Device Stack is a significant
achievement of this project. The understanding of USB protocol was crucial in this work.
The USB 2.0 specification & CDC specification was worked out in the framework. The
Microchip’s Demos & other Software support have been very crucial in the development.
The project now offers a standard transmission interface. Other functionalities can
now be added to the firmware.

Chapter 6
DATALOGGER
Physical Research Laboratory Data Logger
6.1 OVERVIEW
Any microcontroller-PC interface system requires a Front End at PC for receiving

the data. The problem of developing a front end for a USB interface is a grave one. This
is so because the front end has to deal with driver level details & there is not much
expertise easily available in this field. Customizing a driver to meet the front end needs is
a clumsy process often requiring months of development work. So the onus is on the
front end to get things done out of the driver API. However the CDC driver turns the
USB interface into a COM port Interface thereby making this front end development a bit
easier a bit easier.
This chapter deals with the implementation details of the SIMS Monitoring
System’s Front end cum data logging application. A snapshot of the user interface is
provided in section 6.3 of this chapter for reference.
6.2 SIMS MONITORING SYSTEM

Sims Monitoring System is the front end Data logger custom developed for this
application. It is a windows Console application developed using Visual Studio 2005 in
VB language. The entire code Sims.vb is included at the end as Appendix B. It is
developed as a Front end cum data Logging application. The flow of data through the
application can be graphically described as below.
MCHPCDC
API Data Reader Data Validater
Data Processor Packet Splitter
Data Displayer Smart Sense Data Logger
6.1 Data flow diagram of Data logger

For understanding the functioning of the application, it can be divided into six sequential
functional modules:
1) Data Reader
2) Data Validater
3) Packet Splitter
4) Data Processor
5) Data Displayer
6) Smart Sense
7) Data Logger
This modular approach provides for a highly efficient system. Each module interacts
with its immediate neighbors only. This helps in tracking & debugging of errors. The user
interface of SIMS Monitoring System is shown as a snapshot at the end of this chapter.
6.2.1 Data Reader
The user interface provides for a list of com ports available with the system. The
function to update this list is called every millisecond with help of timer. The user has to
select the com port with which our DAQ hardware is associated. This can be known from
the device manager. Once the desired com port has been selected, clicking on the connect
button will start the whole process.
The data is read from the serial port buffer. The read data is then stored in a text
box with id txtdatareceived. The read data can be seen in the multi line textbox at the
bottom of the user interface. Hereafter, all code access only this text box & all
manipulation are done on the text of this textbox.
While accessing the serial port, a Catch expression is always used. This is so
because the device may be disconnected at any time. Reading a port with no connected
device could result in an exception. In such a case, the connection to serial port is closed.
6.2.2 Data Validater
It is necessary to ensure that correct & complete data as been received. Sometimes
due to certain uncontrolled factors, some abnormalities may be introduced in the system.
To protect the data from such corruption some sort of the validation is necessary
Validation is implemented by fixing a data format for the data being transmitted.
This is done in the form of predefined length of data string that is to be sent, unique start-
of-frame & end-of-frame indicators.
For developing phase-1, a length of 214 was fixed. The ‘<’ symbol was used for
start-of-frame identifier & ‘>’ was used for the end-of-frame indicator. Any arbitrary

protocol could be developed on similar lines. The basic idea is fixing a format at the
sending end & telling the receiving end what to expect.
Firstly, the length of the string received in the txtdatareceived textbox is extracted.
If this value matches the predefined data length, then complete string is received & next
validation test will now be performed. The txtdatastatus textbox is updated with a
message “Packet Size Verified” to indicate this. If there is a mismatch in the size values
then “Packet Size Corrupted” is displayed in the status box. The validation process is
stopped at the first violation; the data is then discarded without performing any further
operations.
On successful packet size validation the start-of-frame is checked. The first

character of the string is extracted using the Substring function. It is then compared with
the assigned start-of-frame symbol. On positive match, status text box is updated with
“Start of Frame Verified” else “Start of Frame Corrupted” is displayed & data discarded.
Same process is repeated with end-of-frame symbol. If required the process can
be repeated for the data delimiters embedded in the frame at known intervals. If a data
string successfully completes all validation tests it is then processed further.
6.2.3 Packet splitter
The data string sent from the hardware board carries status data of all the
parameters, in our case of 24 parameters. At the front end this data has to be extracted &
separated for further processing.
At the transmission end we know the exact space given to each parameter in the
frame to be transmitted. This information is used at the front end for extraction. For
development purpose the string formed at the microcontroller for transmission was of the
following format.
<D16:1010101010101010, ADC01:0000001010101010, ADC02:0000001010101010,
ADC03:0000001010101010, ADC04:0000001010101010, ADC05:0000001010101010,
ADC06:0000001010101010, ADC07:0000001010101010, ADC08:0000001010101010>
The 16 characters after the ‘D16:’ are the status indicators of the 16 digital
channels. The data of each channel is extracted using substring function. The extracted
data could be directly used for processing or saved to a variable. Similarly the 16
characters preceded by ‘ADC1’ represent the 16 bit ADC result of Analog Channel 1.
This is followed by the data of channel 2 & so on till the 8th Analog channel.
The full implementation of this functionality is only possible after the

implementation of Phase-2. As only then it will be known which encoding is used at
transmission end. accordingly changes should be made in this module.

6.2.4 Data Processor
To get the most out of the system the data is transmitted in most efficient way.
For e.g. to transmit the status of Duoplasmatron, instead of sending “ON” & “OFF”,
sending a 1 or 0 would be more efficient. This applies to all digital channels. Similarly
analog channels would be transmitted as their binary or hex values.
However after data has been received, they have to be decoded back to their
original state. Sometimes they have to be changed to a format suitable for displaying or to
a format that matches the table structure of the database into which they are to be logged.
For all digital channels after the status character is extracted, an if-else statement
is employed to generate the appropriate value. For analog channels appropriate decoding
code should be added. The desired value is generally of the form required to be
displayed.
The full implementation of this functionality is only possible after the

implementation of Phase-2. As only then it will be known which encoding is used at
transmission end.
6.2.5 Data Displayer
The data processor renders the parameter values which are ready to be displayed.
This display feature can serve as an aid in troubleshooting. The user interface provides
for 18 text boxes to display the parameter values. The text boxes are arranged into 6
Group boxes as shown below:
1) Duoplasmatron
• Vacuum
• Primary beam on off
• Last changed on
2) Vacuum
• Ion Pump
• Entry Slit arm
• Exit Slit arm
• Rotary pump
• Rotary
• Sample Chamber
3) Turbo Pump Speed

• Duoplasmatron
• Primary column
• Sample chamber
• Sample changing chamber

4) Coolant
• Galden Flow
• Galden Level
5) Lab
• Lab Temperature
• Lab Humidity
6) Water Chiller
• Water Level
• Water Temperature
• Water Flow
In addition to these, the front end also displays the current system time. This is
very important for troubleshooting as System time is the time with which the timestamp
is made. It also has a status textbox which displays the status of the current process.
These text boxes are read only so the user cannot inadvertently type on it & corrupt the
data. It provides a text box for typing in the commands which could be send back to the
microcontroller.
The displayed data is then used for data logging purposes. Such an approach
provides for a highly modular system
6.2.6 Smart Sense
The system has displayed an average logging speed of 6 records per second.
Maintaining such high speed can be justified for sake of better resolution. However many
parameters do not change so fast & after acquiring a state maintain their state for several
minutes. For e.g. the Duoplasmatron could remain switched on for hours. All the while
logging 6 times per second that Duoplasmatron is on is a waste of resource.
Hence smart sense feature was developed. Here the value of parameter is
compared with its last known value. The database is updated only if there has been a
change in the value, else it is discarded. This allows for judicious use of memory resource
& also provides for manageable database size.
The smart sense feature is not employed for all parameters. This is so because
many of the acquired parameters continue to operate in optimum condition. Any change
in their value would be an abnormality.
The exact implementation of smart sense can only be done after implementation
of phase-2. However smart sense is suggested for use with Duoplasmatron ON/OFF.

6.2.7 Data Logger
It does the actual work of inserting the acquired values into the ionprobe database.
This feature utilizes the System.OleDb class. The ion probe database is stored in the
dashboard_prl folder. Each target parameter has a table associated to it. The new data is
appended as a record at the end of table. The following table shows the association of
parameters to the tables.
Sr. No. Parameter Table Name

1 Duoplasmatron hours duodetails
2 Duoplasmatron vacuum Pump Pressure
3 Rotary pump pressure Pump Pressure
4 Sample chamber pump Pressure Pump Pressure
5 Entry Slit Ion pump Pressure Pump Pressure
6 Exit Slit Ion pump Pressure Pump Pressure
7 Duoplasmatron Turbo Pump Speed Pump Speed
8 Primary column Turbo Pump Speed Pump Speed
9 Sample Chamber Turbo Pump Speed Pump Speed
10 Sample Changing Chamber Turbo Pump Speed Pump Speed
11 Water Flow Water Flow
12 Water Level Water Level
13 Water Temperature Water Temp
14 Galden Flow Galden Flow
15 Galden Level Galden Level
16 Lab Temperature Lab Temperature
17 Lab Humidity Lab Humidity
Table 6.1 Parameters & their Associated Tables
A connection is made to the database. The connection string specifies all the
required values for making this connection. The connection is opened. Then INSERT
INTO statements is used to insert the parameter values to their associated tables.
A value must be specified for all the required columns. The format of data being
logged must match with table structure of table into which it is being inserted otherwise
an exception will occur.
The data to be inserted is retrieved from the text boxes used to display the parameter
values. The required additional values are generated to match the table structure. The
timestamp is generated using the system date & time.

During experiments, a maximum data logging rate of 12 logs per second was
achieved. The average logging rate hovers around 6 insertions per second.
6.3 SNAPSHOT of SIMS MONITORING SYSTEM

6.4 CONCLUSION
Overall, the SIMS Monitoring System is successful in achieving all its objectives.
It is also versatile enough to be adapted for future requirements. The technology platform
used, Visual studio 2005, has a lot many tools that can be utilized for making this
application more user friendly, efficient & feature rich. Before we wind up the chapter, a
few key concerns deserve attention.
The SIMS Monitoring System application has to be kept running continuously for
the period for which data logging is required else the data is lost. The application needs to
be added to the start up folder so that it stats every time the system boots. However, if
due to some reason the application exits, then it must alert the system administrator. A
small data backup of few hours could also be provided at the hardware board.
The speed of data logger puts an upper limit on speed of data acquisition. This is
so because the microcontroller waits for the last transaction to be complete before
sending in new data. Once a data string is read, the SIMS Monitoring System will
validate it, split it, process it, display it & then finally log it. Only after this it will go &
read the next data from the Serial port Buffer. To avoid loss of data during this period,
the microcontroller is kept waiting & sends in new data only after the previous data has
been read. Hence the SIMS Monitoring System’s code needs to be optimized for fast
execution.
The speed of the application is influenced by a number of external factors. One

among them is the health of the PC system on which it is running. Currently the system
used is a 2.4 GHz P4 with 1 GB of RAM. If the load on the PC increases, the application
thread may get slowed down. This will affect the logging rate hence the actual acquired
rate.

Chapter 7
DATABASE
Physical Research Laboratory Database
7.1 OVERVIEW
Data Acquisition applications usually have data logging feature. There is not
much use of a state-of-art data acquisition system, if the acquired data cannot be made
available at a later time. Data logging provides for further processing & analyses of the
data. Depending on the speed of data acquisition & nature & number of the parameters
being acquired, the volume of data could be enormous. This becomes even more involved
as most data acquisition systems log data continuously & they have to be designed to
keep doing so for years. This calls in for effective data management.
The desired characteristics of a data storage system to be used in conjunction with

a data acquisition system are:
1) It should have a minimal impact on the speed of data acquisition. In other words,
it should be able to save data at the acquired rate or at the closest fastest speed
possible.
2) The data format should be such that it is portable among the standard data
processing platforms or efficient utilities should be available to do the required
conversion for exporting.
3) It should have minimum possible space requirement.
4) It should be able to provide fast retrieval of required data.
5) It should support all standard features like sorting, copying, encryption,

compression etc
6) It should be able to provide data backup capabilities.
7) It should have a user friendly interface with minimum amount of learning/

training needed by the user.
Several state-of-art database management systems are available today like Oracle,
SQL, Sybase et al. After qualitative considerations, MS ACCESS was found to be the
best candidate. It was also compatible with the data logger built on .Net platform. The
web service which used Dundas controls for displaying data could also retrieve data from
ACCESS using the System.OleDB class.
7.2 THE IONPROBE DATABASE
The ionprobe.mdb located in the dashboard_prl folder is the database file of the
system. The database is arranged in form of tables. Each table is dedicated to either a
single or a group of similar parameters. The data is appended in the form of a new row at
the end of the table. The incoming data should match the number & data type of columns
in the table otherwise data will not be inserted. This has to be ensured by the data Logger.
Physical Research Laboratory 50 Sunil S Pillai

The details of the tables & the format in which they store data are described below. The
database has the following 12 tables.
Duodetails Login
DuoMain Pump Pressure
Galden Flow Pump Speed
Galden Level Water Flow
Lab Humidity Water Level
Lab Temperature Water Temperature
7.2.1 DUODETAILS
 It stores the details of the on/off of particular Duoplasmatron.
 It has four columns:
o ID: It stores the Id of Duoplasmatron
o Start Date: It holds the timestamp at which current observation started.
o End Date: It holds the timestamp at which current observation stopped.
o Status: It stores the status of flow of Galden
o 0: if OFF
o 1 : If ON
Table 7.1 DUODETAILS TABLE STRUCTURE

Sr. no. Field Name Data Type Format
1 ID Text Valid Values: duo1, duo2…
2 Start Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 End Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
4 Status Number Valid values: ‘0’ or ‘1’
7.2.2 DUOMAIN
 It stores the details of all Duoplasmatrons.
 It has four columns:
o ID: It stores the Id of Duoplasmatron.
o Start Date: It holds the timestamp at which current observation started.
o End Date: It holds the timestamp at which current observation stopped.
o Total Time: It holds the total number of hours the Duoplasmatron was
on.
Table 7.2 DUOMAIN TABLE STRUCTURE

1 ID Text Valid Values: duo1, duo2…
2 Start Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 End Date Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
4 Total time Number

7.2.3 GALDEN FLOW

 It stores the data related to the flow of Galden (coolant) through the instrument.
 It has two columns:
o Date_Time: It holds the timestamp of the moment of data entry.
o Galden_Flow: It stores the status of flow of Galden
o LOW: If below predetermined flow rate
o OK : If equal to or above predetermined flow rate
Table 7.3 GALDEN FLOW TABLE STRUCTURE

1 Date_Time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
2 Galden_Flow Text Valid values: ‘LOW’ or ‘OK’
7.2.4 GALDEN LEVEL

 It stores the data related to the level of Galden (coolant) in the sump.
o Galden_level: It stores the status of level of Galden
o LOW: If below predetermined level
o OK : If equal to or above predetermined level
Table 7.4 GALDEN LEVEL TABLE STRUCTURE

2 Galden_Level Text Valid values: ‘LOW’ or ‘OK’
7.2.5 LAB HUMIDITY

 It stores the data related to the relative humidity in the lab.
o Lab_humidity: It stores the relative humidity in the lab.
o Valid Values: 0-100.
Table 7.5 LAB HUMIDITY TABLE STRUCTURE

2 Lab_humidity Number Long Integer. Valid values 0~100

7.2.6 LAB TEMPERATURE

 It stores the temperature in the lab.
o Lab_ temperature: It stores the temperature in the lab.
Table 7.6 LAB TEMPERATURE TABLE STRUCTURE

2 Lab_temperature Number Long Integer. Valid values 0~100
7.2.7 LOGIN
 It stores the authentication details to be verified at the time of Login.
 It has three columns:
o UserID: It stores the Employee ID.
o Password: It stores the password.
o Name: It stores the user name to be displayed on dashboard page
Table 7.7 LOGIN TABLE STRUCTURE

Sr. no. Field Name Data Type Remarks
1 UserID Text Used for login
2 Password Text Used for login
3 Name Text Displayed on the dashboard page
7.2.8 PUMP PRESSURE

 It stores the data related to the pressure of the 5 pumps.
o PumpId: It stores the pump ID.
 Valid Values: Ion1. Ion2, rotary1, rotary2, duo
o Date_time: It holds the timestamp of the moment of data entry.
o Pressure: It stores pressure of the pump.
Table 7.8 PUMP PRESSURE TABLE STRUCTURE

1 PumpId Text Valid Values: Ion1. Ion2, rotary1, rotary2, duo
2 Date_time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 Pressure Number Long Integer.

7.2.9 PUMP SPEED

 It stores the data related to the speed of the 4 Turbo pumps.
o PumpId: It stores the pump ID.
 Valid Values: turbo1, turbo2, turbo3, turbo4.
o Date_time: It holds the timestamp of the moment of data entry.
o Pressure: It stores the speed of the pump.
Table 7.9 PUMP SPEED TABLE STRUCTURE

1 PumpId Text Valid Values: turbo1, turbo2, turbo3, turbo4
2 Date_time Date/Time General Date (mm/dd/yyyy hh:mm:ss AM/PM)
3 Speed Number Long Integer.
7.2.10 WATER FLOW

 It stores the data related to the flow of water (coolant) through the instrument.
o Water_Flow: It stores the status of flow of water
o LOW: If below predetermined flow rate
o OK : If equal to or above predetermined flow rate
Table 7.10 WATER FLOW TABLE STRUCTURE

2 Water_Flow Text Valid values: ‘LOW’ or ‘OK’
7.2.11 WATER LEVEL

 It stores the data related to the level of water in the chiller.
o Water_level: It stores the status of level of water
o LOW: If below predetermined level
o OK : If equal to or above predetermined level
Table 7.11 WATER LEVEL TABLE STRUCTURE

2 Water_Level Text Valid values: ‘LOW’ or ‘OK’

7.2.12 WATER TEMPERATURE

 It stores the temperature of water in the lab.
o Water _ temperature: It stores the temperature in the lab.
Table 7.12 LAB TEMPERATURE TABLE STRUCTURE

2 Water _temperature Number Long Integer. Valid values 0~100
7.3 SNAPSHOTS
7.3.1 ION PROBE DATABASE

7.3.2 GALDEN FLOW TABLE

7.4 Conclusion
Overall, the ionprobe.mdb database satisfies all of its required specifications.
Being implemented on a standard Microsoft Office platform, it provides for all the
standard features as well as the portability. The tables can be sorted, queried and reports
be generated. The data can also be exported to Microsoft Excel for advanced
mathematical manipulation or generation of charts. As we wind up this chapter, lets
discuss some key points to be kept in mind while operating the database.
The login table is used for authentication at the time of startup. If the database is
opened at the server machine, then login table becomes inaccessible to the web service. If
a user tries to login at this time at a remote browser, an exception will occur. However
after login the database can be viewed at the server. This will not interfere with the
logging activity or the refresh of the webpage at the remote browser.
The limit on the number of rows in a table comes from the use of long integer as a
primary key. In such a case a maximum of 231 rows can be accommodated. With an
insertion rate of 6 rows per second, it would require11.5 years of continuous logging to
exhaust such a table. However it is not advisable to build up such a huge table. A backup
policy should be devised to prevent building up of data in a single file.
The ionprobe.mdb is located in the dashboard_prl folder. If the database is

relocated then the new path should be updated at all places that access the database. This
could be a cumbersome process as database is accessed by data logger & dashboard web
service on quite a large number of occasions. If absolutely required, it is suggested to
make a copy of the database at desired location.

Chapter 8
DASHBOARD WEB SERVICE

Physical Research Laboratory Dashboard Web Service
8.1 Sims Monitoring Site Overview
A website has been developed in xhtml for allowing for remote viewing of status data
over the Intranet. The site has been developed using Visual Studio 2005 in C# language.
The site has two pages: (a) login page & (b) dashboard page. On startup it displays
the Login Page. It does the job of authenticating the user. After successful login the
window is closed & dashboard page is opened in a new window in Full screen mode. The
dashboard page displays the current status of SIMS with the help of various gauges.
8.2 DASHBOARD
To provide an effective display & interpretation of data, the concept of dashboard was
used. Dashboard web sites analogous to the dashboards on automotive vehicles provide
the information about complete state of system on a single screen. In one look, a fair idea
about the current state of the system can be obtained. Dashboards don’t carry a large
number of links nor do they have multiple pages, however they may provide links to
external websites. They have drill down feature to carry the extra data which could not be
accommodated on a single page.
Several dashboard generating tools are available in the market. However I chose
to create a custom dashboard so as to have full control over all its features without any
limitation. To display data in an easy to interpret form, the need of data visualization
software was realized. I selected the best data visualization service available for Visual
Studio, the Dundas Gauge & Chart Control from Dundas Data Visualization Inc.
Dundas Gauge for ASP.NET is a fully managed ASP.NET control that lets
developers add Gauges to their applications, and attain a new level of data
visualization with a minimal amount of effort.
Dundas Gauge for ASP.NET includes a full assortment of Gauge types, including
circular gauges, linear gauges, angular gauges, and thermometer gauges all of which have
been designed to help you add a new dimension of data visualization, and analysis to
your ASP.NET applications. With customization abilities, and full integration into Visual
Studio 2005, one can get the exact look and feel one needs for all applications.
Dundas Gauge for ASP.NET includes more than just incredibly attractive
Gauges. Advanced data manipulation abilities let you get the most out of your data, with
a minimum amount of effort. For example, historical data which is easily stored enables
both playback and display of calculated values such as minimums, maximums,
and averages. You can display your data in real-time, and customize the scales, needles,
alarms, labels, and markers you use to get the exact Gauge you want for your specific
visual analysis.
Dundas Chart for ASP.NET is the perfect solution for developers looking to add
advanced, feature rich, visually appealing charts to their ASP.NET applications. It

consists of the charting web control, numerous sample applications and solutions, and
extensive documentation to guide you every step of the way.
The Chart control is an easy to use ASP.NET web-server control that lets you add
robust charting abilities to your applications with a minimum amount of effort. The
control has been created using C#, which means that it is a fully-managed .NET
component, and it has been specifically designed for use with Microsoft's Visual Studio
.NET.
Dundas Chart for ASP.NET is available in two editions including the Professional
edition, and Enterprise edition. Both editions are feature rich and easy to use.
The following is a list of features for Dundas Gauge for ASP.NET. This feature
list is organized by its major components, starting with the root Gauge Container object,
and proceeding through all of its functional elements.
Features of the Gauge Container
The Gauge container is the root object used to contain and display any number of
Gauges, or indicators. This root object can support each Gauge having one or more
Pointers (e.g. a Needle), Scales, and Ranges. The Gauge container is as powerful, as it is
flexible. These are the features of this component, and its elements:
• Full Visual Studio 2005 Integration.

• Full Smart-Tag capability.
• Improved data binding using an object, web service, or database.
• Design-time cloning of Gauge elements.
• Selection of any Gauge element using a new Selected property.
• Multiple gauges, state indicators, and numeric indicators.
• Linear and circular gauges are both supported.
• Supports numerous rendering image types (e.g. Bmp, Jpeg, Png, Emf, Svg,
Flash).
• Can be displayed as a Windows Forms control using Internet Explorer's Smart
Client functionality.
• Custom images can be displayed.
• Data playback is possible via the data history mechanism.
• Pre-defined frames, with various styles are available.
• Serialization support for the saving and loading of appearance properties, values,
and historical data.
• Ability to save image snapshots.

• Ability to manipulate and synchronize data playback for all scales.

• Statistical functions, via calculated values.
Gauges
• Linear and circular gauges are both supported.

• Angular gauges are available as a variant of circular gauges.
• Pre-defined frames, with various styles are available.
• Multiple pointers, scales and ranges are supported.
• Shadows and gradient colors.
• Automatic positioning within the Gauge container.
• Circular gauges have an adjustable pivot point.
• Linear gauges can have vertical, horizontal, or automatically calculated
orientation.
• Statistical functions are available via calculated values.
Scales
• Ability to specify a range of values.

• Supports both linear and circular axes.
• Circular scales include:
o Clockwise and counter-clockwise rotation.
o The ability to specify start angle and end angle.
o The ability to set center coordinates and radius of scale.
o The ability to have a circular scale projected onto a straight horizontal, or
vertical line.
• Logarithmic scales, with customizable base.
• Multiple pointers.
• Custom markers.
• Maximum and minimum pins.
Pointers
• Can be shown as needles, markers, or bars.

• Multiple pointers per scale can be used.
• Optional dampening of movement.

• Snapping to values supported.

• Customized images can be used as Pointers.
Knobs
• Primarily associated with interactivity to create intuitive controls.

• Similar features as the pointer.
• Used for circular Gauges.
• Can be used to complement, or replace pointers.
Ranges
• Associated with scales, and used to highlight a specific area of a scale's range.
• Various color and styles are available.
Numeric Indicators
• Several styles to choose from including mechanical, 7-segment, and 14-segment

indicators.
• Format values with ease.
• Can be automatically sized.
• Can have associated ranges.
• Optional snapping and dampening behaviors.
• Automatically fitted text.
State Indicators
• Several styles to choose from including circular or rectangular LED.

• Can have multiple states, each with a start and end value. This helps to
determine if the indicator is On or Off.
• Can be automatically sized.
• Automatically fitted text.
Frames
• Pre-defined assortment of attractive frames, which can be used for both the
Gauge container and all of its gauges.
• Frames can be either circular or rectangular.

Miscellaneous
• Gradient color support.

• Hatching supported.
• Images
o Can be associated with various Gauge components (e.g. container,
Gauge objects, etc.).
o Transparency support (0-100%).
o Can be positioned anywhere within a container.
• Labels
o Can be associated with various Gauge components (e.g. container,
Gauge objects, etc.).
o Text can be automatically fitted.
o Can be positioned anywhere within a container.
8.3 Login Page
The login.aspx page has been displayed in the snapshot section of this chapter. It
is a classic PRL style webpage with blue background. It carries the photographs of the
ionprobe lab & the IMS 4f Instrument. It also mentions the working group of the lab. It
asks the user to enter the Employee ID & Password. These two textboxes are then
matched with the records of login table in ionprobe database.
The ionprobe database is located in dashboard_prl folder. The login table has
three fields: User id, Password & User name. Upon having a positive match, the
associated user name is retrieved. The current window/tab is then closed & dashboard
page is called. While calling the page, the retrieved user name is also passed on.
The dashboard page queries its header to obtain the user name. The retrieved user
name is displayed at the top right corner of dashboard page. The login has to be done
only once, at every refresh the session information is maintained. A user can logout by
simply closing the window.
If authentication fails then the login page is reloaded with an “Invalid user id”
message. The user can retry any number of times. The login.aspx.cs file is included in the
Appendix C.
Authentication details can be managed by adding, deleting or updating the records

of the login table of ionprobe database.

8.4 Dashboard Page

The dashboard page always opens in a full screen mode. The screen area houses
two rows at the top followed by a panel window. The top row is akin to a title bar. At the
right end it displays the user name with which current session was logged into. The user
name is supplied by the login page after retrieving it from the login table of database on
successful authentication.
The Dashboard page has two panels:

1) Gauge panel accessed through ‘Main’ tab
2) Chart panel accessed through ‘Details’ tab
By default, the gauge panel is displayed at the startup as well as at subsequent page
refreshes.
8.4.1 GAUGE PANEL
The gauge panel displays 17 gauges. These are encapsulated in 8 Gauge

containers. The gauge panel has arranged the Gauge Containers in two rows. The
brackets indicate the container id with which they are referred to in the code.
The first row houses:

1) Duoplasmatron Vacuum Gauge Container (dgcduovacuum)
2) Rotary & Sample Chamber Vacuum Gauge Container (dgcrotarysample)
3) Ion Pump Vacuum Gauge Container (dgcIon)
4) Galden Gauge Container (dgcgalden)
The second row incorporates:

1) Duoplasmatron Hour Gauge Container (dgcPlasmatron)
2) Turbo Pump Gauge Container (dgcturbo)
3) Temperature & Humidity Gauge Container (dgcchillerlabTemphumid)
4) Chiller gauge Container (dgcchiller)
8.4.1.1 Duoplasmatron Vacuum Gauge Container (dgcduovacuum)
This gauge container houses the Duoplasmatron vacuum gauge. It displays the
current vacuum maintained at the Duoplasmatron in the units of torr.
o Gauge Name : duovacuum

o Gauge type : Circular
o Sweep Angle : 240o
o Pointer : needle
o Numeric Indicator : 4 digit with 2 decimal places
: 1 digit without decimal place
o Numeric Indicator Style : 14 Segment
o Ranges : 2. Red, Green
o State Indicator : Rounded Rectangular Led

8.4.1.2 Rotary & Sample Chamber Vacuum Gauge Container (dgcrotarysample)
This gauge container houses two circular gauges. They display the current
vacuum maintained by the rotary pumps in the units of torr.
Rotary Pump Pressure Gauge

o Gauge Name : Rotary1
o Pointer : needle
o Ranges : 3. Red, Green, Yellow
o State Indicator : Rounded Led
Sample Chamber Pressure Gauge

o Gauge Name : Rotary2
o Pointer : needle
8.4.1.3 Ion Pump Vacuum Gauge Container (dgcIon)
This gauge container houses two circular gauges. They display the current
vacuum maintained by the ion pumps in the units of torr. The second gauge is stacked
just below the first one.
Entry Slit Arm Ion Pump Pressure Gauge

o Gauge Name : Ion1
o Pointer : needle

Exit Slit Arm Ion Pump Pressure Gauge

o Gauge Name : Ion2
o Pointer : needle
8.4.1.4 Galden Gauge Container (dgcgalden)
This gauge container houses two linear gauges. The first one displays the level of
Galden in the sump. The second one displays the flow of Galden through the instrument.
Galden level Gauge

o Gauge Name : galdenlevel
o Gauge type : Linear
o Pointer : Bar
o Numeric Indicator : 2 digit without decimal places
o Numeric Indicator Style : Mechanical
Galden Flow Gauge

o Gauge Name : galdenflow
o Pointer : Bar
8.4.1.5 Duoplasmatron Vacuum Gauge Container (dgcduovacuum)
This gauge container houses the Duoplasmatron Hour gauge. It displays the
number of hours Duoplasmatron has been on. The circular scale shows a range of 0-450
hours. After the 350 hours the range is marked as red, also the state indicator text displays
an alert.
o Gauge Name : duohours
o Pointer : needle
o Ranges : 2. Lime, Red
o State Indicator : Text

8.4.1.6 Turbo Pump Gauge Container (dgcturbo)
This gauge container houses four circular gauges. They display the speed of the
turbo pumps in units of rpm. They are arranged in two rows at four corners. Their
prominent numeric indicators fall in a column of four rows at the center. The big state
indicators are housed adjacent to pointer cap. Each gauge carries its label just below
itself.
Duoplasmatron Turbo Pump Gauge

o Gauge Name : turbo1
o Sweep Angle : 90o
o Pointer : needle
o Numeric Indicator : 5 digit without decimal place
Primary Column Turbo Pump Gauge

o Sweep Angle : 90o
o Pointer : needle
Sample Chamber Turbo Pump Gauge

o Sweep Angle : 90o
o Pointer : needle
Sample Changing Chamber Turbo Pump Gauge

o Sweep Angle : 90o
o Pointer : needle

8.4.1.4 Temperature & Humidity Gauge Container (dgcchillerlabTemphumid)
This gauge container houses three linear gauges. The first one displays the
temperature of water flowing through the instrument in units of oC. The second one
displays the temperature of lab in units of oC. The third gauge displays the relative
humidity present in the lab in units of percentage. The three gauges are stacked side by
side in vertical orientation.
Water Temperature Gauge

o Gauge Name : Chiller
o Pointer : Thermometer
o Numeric Indicator : 3 digit with 1 decimal place
o Ranges : 4. White, Lime, Orange, Red
o State indicator : 2, Rounded Led
o o
The scale ranges from 5 C to 45 C. The ranges have been distributed as
o Too Cold (White) : 0 oC to 10 oC
o Ok (Lime) : 10 oC to 20 oC
o Warning (Orange) : 20 oC to 30 oC
o High (Red) : 30 oC to 45 oC
Lab Temperature Gauge

o Gauge Name : labtemp
o Pointer : Thermometer
o Ranges : 4. White, Lime, Orange, Red
o State indicator : 2, Rounded Led
The scale ranges from 5 oC to 45 oC. The ranges have been distributed as
o Too Cold (White) : 0 oC to 10 oC
o Ok (Lime) : 10 oC to 25 oC
o Warning (Orange) : 25 oC to 35 oC
o High (Red) : 35 oC to 45 oC
Lab Humidity Gauge

o Gauge Name : labhumid
o Pointer : Bar

8.4.1.8 Chiller gauge Container (dgcchiller)
This gauge container houses two linear gauges. The first one displays the level of
water in the chiller. The second one displays the flow of water through the instrument.
Water level Gauge

o Gauge Name : waterlevel
o Pointer : Bar
Water Flow Gauge

o Gauge Name : waterflow
o Pointer : Bar
8.4.2 CHART PANEL
The chart panel provides for generation of chart based on the logged data. In a
way it provides for remote analyses of the data. The charts are drawn with time on x-axis
& status data on y-axis. Graphs can be generated for any of the parameter for any given
time interval. Dundas Chart control for ASP.NET 2005 is utilized for providing this
capability.
The panel provides for 3 chart containers:
1) Pump Chart Container
2) Duoplasmatron Chart Container
3) Temperature/Humidity Chart Container
Each chart container has a drop down box for selecting the parameter to be
plotted. As soon as the selected index of the drop down box, the plot is updated.
8.4.2.1 Pump Chart Container

It allows following parameters to be plotted.
• Rotary1
It plots the pressure (Vacuum) maintained by the rotary pump in units of
torr against time.
• Rotary2
It plots the pressure (Vacuum) maintained by the pump at sample chamber
in units of torr against time.

• Turbo1
It plots the speed of the turbo pump serving the duoplasmatron in units of
rpm against time.
• Turbo2
It plots the speed of the turbo pump serving the primary column in units of
rpm against time.
• Turbo3
It plots the speed of the turbo pump serving the sample chamber in units of
rpm against time.
• Turbo4
It plots the speed of the turbo pump serving the sample changing chamber
in units of rpm against time.
• Ion1
It plots the pressure (Vacuum) maintained by the ion pump at entry slit
arm in units of torr against time.
• Ion2
It plots the pressure (Vacuum) maintained by the ion pump at exit slit arm
in units of torr against time.
8.4.2.2 Duoplasmatron Chart Container

It allows the on/off duration of the duoplasmatrons to be plotted against the time.
The ids of all the duoplasmatrons used so far are displayed in the drop down box.
8.4.2.3 Temperature/Humidity Chart Container

It allows following parameters to be plotted
• Water temperature
It plots the temperature of water in the chiller in the units of oC against time.
• Lab temperature
It plots the temperature of lab in the chiller in the units of oC against time.
• Lab humidity
It plots the relative humidity of the lab in the units of percentage against time.
The y-axis ranges automatically to include all the data points of the selected
interval. The x-axis range is customizable. The time interval on the x-axis is controlled by
the two text boxes with labels Start date & End Date. A Java Script based date picker is
provided for date selection. Clicking on fetch button will update all the plots to the new
interval. This feature can be intuitively used for having a Zoom feature along the x-axis.

8.5 Snapshots
8.5.1 Login Page

8.5.2 Dashboard Page – Gauge Panel

8.5.3 Dashboard Page – Chart Panel

8.6 Conclusion
The dashboard site has been online since mid February. It has been through 3
design cycles. Each time the number & features of the gauges were increased. The SIMS
Monitoring site has successfully met all objectives & is now ready for phase 2 to be
completed when the whole system will become live.
During the four month period, the site has been logged into from various different
systems using different browsers. The site was found to be giving best performance with
internet explorer 6.0 or higher. There were some problems with Mozilla’s Firefox
browser while displaying the dashboard page. Pop-up blockers should be turned off to
enable opening of dashboard page. Since almost all browsers allow for customizing of
pop-up settings for individual sites, this is not much of a problem.
The site being quite graphic heavy takes some time to load in heavy traffic
networks. But normally the latency is not annoying. The C# code of both login &
dashboard page are included at the end in Appendix C.

Chapter 9
FUTURE WORK
Physical Research Laboratory Future Work
The most prominent work would be the completion of phase 2 & integration of
the whole system so as to meet all the stated objectives. However while working on the
Phase-1 of the system, following enhancements were desired.
9.1 HARDWARE
 Isolation between the hardware & the PC by use of external transceiver could be
thought of.
 Backup of few hours for data storage in form of On Board memory chips could be
added. This backup can be used at times when PC is shutdown or in maintenance
mode.
 The hardware should be able to sense the PC state through the bus activity on the
USB & should switch to the local memory backup when the PC is powered down
or USB cable is disconnected. On reconnection it should dump the backup
memory on to pc.
9.2 FIRMWARE
 USB boot loader code can be added. This will allow reprogramming of the chip
without using ICSP.
9.2 DATA LOGGER
 A provision to take backup of data with configurable settings (like time of

backup, auto scheduler, location & name of the backup file et al) could be added.
 Auto reconnection capability to com port could be provided. Currently if due to

an exception the connection to the serial port is reset/lost, the connect button has
to be manually clicked to restart the logging process.
9.4 DASHBOARD
 A utility to save the generated charts can be added.
 A utility to fire e-mails & SMS to predefined configurable authorities in case of

predefined configurable events can be added.

Physical Research Laboratory Bibliography
Chapter 10
BIBILOGRAPHY

Physical Research Laboratory Bibliography
Following Documents were referred to during the project
 UNIVERSAL SERIAL BUS SPECIFICATION REVISION 2.0
 UNIVERSAL SERIAL BUS CLASS DEFINITIONS FOR

COMMUNICATIONS DEVICES REVISION 1.2
 MPLAB® C18 C COMPILER LIBRARIES
 PIC 18F4550 DATASHEET
 THE PIC MICROCONTROLLER, YOUR PERSONAL INTRODUCTORY

COURSE, 3RD ED.
 USB COMPLETE
 MAKING PIC MICROCONTROLLER- INSTRUMENTS &

CONTROLLERS
The following websites have come in handy during development

 www.microchip.com
 www.microchipc.com
 www.pic18f.com
 www.embedded.com
 www.lvr.com/hidpage.htm
 www.ccsinfo.com
 www.microsoft.com/msdn
 www.support.dundas.com

APPENDIX- A
FIRMWARE CODE
Physical Research Laboratory Firmware Code
/********************************************************************
FileName: main.c
Dependencies: See INCLUDES section
Complier: Microchip C18 (for PIC18) or C30 (for PIC24)
Company: Microchip Technology, Inc.
**************************************************************************/
/** INCLUDES *******************************************************/

#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "usb_config.h"
#include "./USB/usb_device.h"
#include "./USB/usb.h"
#include "./USB/usb_function_cdc.h"
#include "HardwareProfile.h"
/** CONFIGURATION **************************************************/
#pragma config PLLDIV = 5 // (20 MHz crystal)

#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2 // Clock source from 96MHz PLL/2
#pragma config FOSC = HSPLL_HS
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = OFF
#pragma config BOR = ON
#pragma config BORV = 3
#pragma config VREGEN = ON //USB Voltage Regulator
#pragma config WDT = OFF
#pragma config WDTPS = 32768
#pragma config MCLRE = ON
#pragma config LPT1OSC = OFF
#pragma config PBADEN = OFF
#pragma config STVREN = ON
#pragma config LVP = OFF
#pragma config XINST = OFF // Extended Instruction Set
#pragma config CP0 = OFF
#pragma config CP1 = OFF
#pragma config CPB = OFF
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
#pragma config WRTB = OFF // Boot Block Write Protection
#pragma config WRTC = OFF
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
#pragma config EBTRB = OFF
/** I N C L U D E S ********************************************************/
#include "GenericTypeDefs.h"
#include "Compiler.h"
#include "usb_config.h"
#include "USB\usb_device.h"

#include "USB\usb.h"
#include "adc.h"
#include "delays.h"
#include "HardwareProfile.h"
/** V A R I A B L E S ******************************************************/
#pragma udata
char USB_In_Buffer[64];
char USB_Out_Buffer[64];
BOOL stringPrinted;
/** P R I V A T E P R O T O T Y P E S ***************************************/
static void InitializeSystem(void);
void ProcessIO(void);
void USBDeviceTasks(void);
void YourHighPriorityISRCode();
void YourLowPriorityISRCode();
void BlinkUSBStatus(void);
void UserInit(void);
/** DECLARATIONS ***************************************************/

#pragma code
/*************************************************************************
* Function: void main(void)
*
* PreCondition: None
*
* Input: None
*
* Output: None
*
* Side Effects: None
*
* Overview: Main program entry point.
**************************************************************************/
void main(void)
{
InitializeSystem();
#if defined(USB_INTERRUPT)
USBDeviceAttach();
#endif
while(1)
{
#if defined(USB_POLLING)
// Check bus status and service USB interrupts.
USBDeviceTasks();
/*
Interrupt or polling method. If using polling, must call this function periodically. This
function will take care of processing and responding to SETUP transactions (such as during
the enumeration process when you first plug in). USB hosts require that USB devices
should accept and process SETUP packets in a timely fashion. Therefore, when using

polling, this function should be called frequently (such as once about every 100
microseconds) at anytime that a SETUP packet might reasonably be expected to be sent by
the host to your device. In most cases, them USBDeviceTasks() function does not take very
long to execute (~50 instruction cycles) before it returns.
*/
#endif
// Application-specific tasks.
// Application related code may be added here, or in the ProcessIO() function.
ProcessIO();
}//end while
}//end main
/********************************************************************
* Function: static void InitializeSystem(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: InitializeSystem is a centralize initialization routine. All required USB initialization
routines are called from here. User application initialization routine should also be called from
here.
*******************************************************************/
static void InitializeSystem(void)
{
ADCON1 |= 0x0F; // Default all pins to digital
#if defined(USE_USB_BUS_SENSE_IO)
tris_usb_bus_sense = INPUT_PIN; // See HardwareProfile.h
#endif
#if defined(USE_SELF_POWER_SENSE_IO)
tris_self_power = INPUT_PIN; // See HardwareProfile.h
#endif
UserInit();
USBDeviceInit(); //usb_device.c. Initializes USB module SFRs and firmware

//variables to known states.
} //end InitializeSystem
/***************************************************************************

* Function: void UserInit(void)

*
*
* Input: None
*
* Output: None
*
*
* Overview: This routine should take care of all of the demo code initialization that is
required.
**************************************************************************/
void UserInit(void)
{
//Initialize all of the LED pins
mInitAllLEDs();
} //end UserInit
/********************************************************************
* Function: void ProcessIO(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: This function is a place holder for other user routines. It is a mixture of both USB
and non-USB tasks.
*******************************************************************/
void ProcessIO(void)
{
BYTE numBytesRead;
//Blink the LEDs according to the USB device status
BlinkUSBStatus();
// User Application USB tasks
/*
Put in code here for adc conversion & reading the channels. Sample ADC handling code for
channel 0 (AD0) is shown here.
OpenADC(ADC_FOSC_32 & ADC_RIGHT_JUST & ADC_12_TAD, ADC_CH0 &

ADC_INT_OFF, 14);
int res;
Delay10TCYx( 5 ); // Delay for 50TCY
ConvertADC(); // Start conversion
while( BusyADC() ); // Wait for completion
res = ReadADC(); // Read result

CloseADC(); // Disable A/D converter
After obtaining the values of all digital & analog channels, a packet is to be formed for
transmission by combining them all.
The packet should begin and end with a ‘<’ sign. A ‘,’ should be used for delimiting the fields. The
sample packet was used for testing purpose.
*/
if((USBDeviceState < CONFIGURED_STATE)||(USBSuspendControl==1)) return;
if(mUSBUSARTIsTxTrfReady())
{
putrsUSBUSART("<D16:1010101010101010, ADC01:0000001010101010,
ADC02:0000001010101010, ADC03:0000001010101010, ADC04:0000001010101010,
ADC05:0000001010101010, ADC06:0000001010101010, ADC07:0000001010101010,
ADC08:0000001010101010>");
}
if(mUSBUSARTIsTxTrfReady())
{
numBytesRead = getsUSBUSART(USB_Out_Buffer,64);
if(numBytesRead != 0)
{
BYTE i;
for(i=0;i<numBytesRead;i++)
{
/* Put in here code for manipulating the output from pc.
The output from pc is received in USB_Out_Buffer.
The use of a switch statement can be made to respond to predefined
commands. For e.g.
switch(USB_Out_Buffer[i])
{
case 0x0A:
case 0x0D:
USB_In_Buffer[i] = USB_Out_Buffer[i];
break;
default:
USB_In_Buffer[i] = USB_Out_Buffer[i] + 1;
break;
}
*/
}
putUSBUSART(USB_In_Buffer,numBytesRead);
}
}
CDCTxService();
} //end ProcessIO
/********************************************************************
* Function: void BlinkUSBStatus(void)
*
*

* Input: None
*
* Output: None
*
*
* Overview: BlinkUSBStatus turns on and off LEDs corresponding to the USB device state.
*
* Note: mLED macros can be found in HardwareProfile.h USBDeviceState is declared and
updated in usb_device.c.
*******************************************************************/
void BlinkUSBStatus(void)
{
static WORD led_count=0;
if(led_count == 0)led_count = 10000U;

led_count--;
#define mLED_Both_Off() {mLED_1_Off();mLED_2_Off();}

#define mLED_Both_On() {mLED_1_On();mLED_2_On();}
#define mLED_Only_1_On() {mLED_1_On();mLED_2_Off();}
#define mLED_Only_2_On() {mLED_1_Off();mLED_2_On();}
if(USBSuspendControl == 1)
{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_On();
}
else
{
mLED_2_Off();
}
} //end if
}
else
{
if(USBDeviceState == DETACHED_STATE)
{
mLED_Both_Off();
}
else if(USBDeviceState == ATTACHED_STATE)
{
mLED_Both_On();
}
else if(USBDeviceState == POWERED_STATE)
{
mLED_Only_1_On();
}
else if(USBDeviceState == DEFAULT_STATE)
{
mLED_Only_2_On();
}
else if(USBDeviceState == ADDRESS_STATE)

{
if(led_count == 0)
{
mLED_1_Toggle();
mLED_2_Off();
} //end if
}
else if(USBDeviceState == CONFIGURED_STATE)
{
if(led_count==0)
{
mLED_1_Toggle();
if(mGetLED_1())
{
mLED_2_Off();
}
else
{
mLED_2_On();
}
} //end if
} //end if(...)
} //end if(UCONbits.SUSPND...)
} //end BlinkUSBStatus
// *************************************************************************
// ************** USB Callback Functions ***********************************
// ************************************************************************
/*
The USB firmware stack will call the callback functions USBCBxxx() in response to certain USB
related events. For example, if the host PC is powering down, it will stop sending out Start of
Frame (SOF) packets to your device. In response to this, all USB devices are supposed to decrease
their power consumption from the USB Vbus to <2.5mA each. The USB module detects this
condition (which according to the USB specifications is 3+ms of no bus activity/SOF packets) and
then calls the USBCBSuspend() function. You should modify these callback functions to take
appropriate actions for each of these conditions. For example, in the USBCBSuspend(), you may
wish to add code that will decrease power consumption from Vbus to <2.5mA (such as by clock
switching, turning off LEDs, putting the microcontroller to sleep, etc.). Then, in the
USBCBWakeFromSuspend() function, you may then wish to add code that undoes the power
saving things done in the USBCBSuspend() function.
The USBCBSendResume() function is special, in that the USB stack will not function. This
function is meant to be called from the application firmware instead. See the additional
comments near the function.
*/
/***************************************************************************
* Function: void USBCBSuspend(void)
*
*
* Input: None
*
* Output: None
*


*
* Overview: Call back that is invoked when a USB suspend is detected
**************************************************************************/
void USBCBSuspend(void)
{
// Example power saving code. Insert appropriate code here for the desired application behavior.
// If the microcontroller will be put to sleep, a process similar to that shown below may be used:
//ConfigureIOPinsForLowPower();
//SaveStateOfAllInterruptEnableBits();
//DisableAllInterruptEnableBits();
//EnableOnlyTheInterruptsWhichWillBeUsedToWakeTheMicro();
//should enable at least USBActivityIF as a wake source
//Sleep();
//RestoreStateOfAllPreviouslySavedInterruptEnableBits();
//Preferrably, this should be done in the USBCBWakeFromSuspend() function
//RestoreIOPinsToNormal();
//Preferrably, this should be done in the USBCBWakeFromSuspend() function
//IMPORTANT NOTE: Do not clear the USBActivityIF (ACTVIF) bit here. This bit is cleared
//inside the usb_device.c file. Clearing USBActivityIF here will cause things to not work as
//intended.
/***************************************************************************
* Function: void _USB1Interrupt(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: This function is called when the USB interrupt bit is set. In this example the
interrupt is only used when the device goes to sleep when it receives a USB suspend command
**************************************************************************/
#if 0
void __attribute__ ((interrupt)) _USB1Interrupt(void)
{
#if !defined(self_powered)
if(U1OTGIRbits.ACTVIF)
{
IEC5bits.USB1IE = 0;
U1OTGIEbits.ACTVIE = 0;
IFS5bits.USB1IF = 0;
//USBClearInterruptFlag(USBActivityIFReg,USBActivityIFBitNum);
USBClearInterruptFlag(USBIdleIFReg,USBIdleIFBitNum);
//USBSuspendControl = 0;
}
#endif
}
#endif

/***************************************************************************
* Function: void USBCBWakeFromSuspend(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: The host may put USB peripheral devices in low power suspend mode (by
"sending" 3+ms of idle). Once in suspend mode, the host may wake the device back up by
sending non-idle state signalling.
*
* This call back is invoked when a wakeup from USB suspend is detected.
*****************************************************************************/
void USBCBWakeFromSuspend(void)
{
// If clock switching or other power savings measures were taken when executing the
//USBCBSuspend() function, now would be a good time to switch back to normal full
//power run mode conditions. The host allows a few milliseconds of wakeup time, after
//which the device must be fully back to normal, and capable of receiving and processing
//USB packets. In order to do this, the USB module must receive proper clocking (IE:
//48MHz clock must be available to SIE for full speed USB operation).
}
/********************************************************************
* Function: void USBCB_SOF_Handler(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: The USB host sends out a SOF packet to full-speed devices every 1 ms. This
interrupt may be useful for isochronous pipes. End designers should implement callback routine
as necessary.
********************************************************************/
void USBCB_SOF_Handler(void)
{
// No need to clear UIRbits.SOFIF to 0 here.
// Callback caller is already doing that.
}
/*******************************************************************
* Function: void USBCBErrorHandler(void)
*
*
* Input: None
*
* Output: None
*


*
* Overview: The purpose of this callback is mainly for debugging during development. Check
UEIR to see which error causes the interrupt.
*******************************************************************/
void USBCBErrorHandler(void)
{
// No need to clear UEIR to 0 here.
// Callback caller is already doing that.
// Typically, user firmware does not need to do anything special. if a USB error occurs.
//For example, if the host sends an OUT packet to your device, but the packet gets
//corrupted (ex: because of a bad connection, or the user unplugs the USB cable during
//the transmission) this will typically set one or more USB error interrupt flags. Nothing
//specific needs to be done however, since the SIE will automatically send a "NAK"
//packet to the host. In response to this, the host will normally retry to send the packet
//again, and no data loss occurs. The system will typically recover automatically, without
//the need for application firmware intervention.
// Nevertheless, this callback function is provided, such as for debugging purposes.
}
/*******************************************************************
* Function: void USBCBCheckOtherReq(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: When SETUP packets arrive from the host, some firmware must process the
request and respond appropriately to fulfill the request. Some of the SETUP packets will be for
standard USB "chapter 9" (as in, fulfilling chapter 9 of the official USB specifications) requests,
while others may be specific to the USB device class that is being implemented. For example, a
HID class device needs to be able to respond to "GET REPORT" type of requests. This is not a
standard USB chapter 9 request, and therefore not handled by usb_device.c. Instead this request
should be handled by class specific firmware, such as that contained in usb_function_hid.c.
*******************************************************************/
void USBCBCheckOtherReq(void)
{
USBCheckCDCRequest();
}//end
/*******************************************************************
* Function: void USBCBStdSetDscHandler(void)
*
*
* Input: None
*
* Output: None
*
*

* Overview: The USBCBStdSetDscHandler() callback function is called when a SETUP,

bRequest: SET_DESCRIPTOR request arrives. Typically SET_DESCRIPTOR requests are not
used in most applications, and it is optional to support this type of request.
* *******************************************************************/
void USBCBStdSetDscHandler(void)
{
// Must claim session ownership if supporting this request
} //end
/*******************************************************************
* Function: void USBCBInitEP(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: This function is called when the device becomes initialized, which occurs after
the host sends a SET_CONFIGURATION (wValue not = 0) request. This callback function should
initialize the endpoints for the device's usage according to the current configuration.
*******************************************************************/
void USBCBInitEP(void)
{
CDCInitEP();
}
/********************************************************************
* Function: void USBCBSendResume(void)
*
*
* Input: None
*
* Output: None
*
*
* Overview: The USB specifications allow some types of USB peripheral devices to wake up a
host PC (such as if it is in a low power suspend to RAM state). This can be a very useful feature in
some USB applications, such as an Infrared remote control receiver. If a user presses the "power"
button on a remote control, it is nice that the IR receiver can detect this signalling, and then send
a USB "command" to the PC to wake up.
*
The USBCBSendResume() "callback" function is used to send this special USB signalling which
wakes up the PC. This function may be called by application firmware to wake up the PC. This
function should only be called when:
1. The USB driver used on the host PC supports the remote wakeup capability.
2. The USB configuration descriptor indicates the device is remote wakeup capable in the
bmAttributes field.
3. The USB host PC is currently sleeping and has previously sent your device a SET FEATURE
setup packet which "armed" the remote wakeup capability.
*
*This callback should send a RESUME signal that has the period of 1-15ms.

********************************************************************/
void USBCBSendResume(void)
{
static WORD delay_count;
USBResumeControl = 1; // Start RESUME signaling
delay_count = 1800U; // Set RESUME line for 1-13 ms

do
{
delay_count--;
}while(delay_count);
USBResumeControl = 0;
}
/*******************************************************************
* Function: void USBCBEP0DataReceived(void)
*
* PreCondition: ENABLE_EP0_DATA_RECEIVED_CALLBACK must be defined already (in
usb_config.h)
*
* Input: None
*
* Output: None
*
*
* Overview: This function is called whenever a EP0 data packet is received. This gives the
user (and thus the various class examples a way to get data that is received via the control
endpoint. This function needs to be used in conjunction with the USBCBCheckOtherReq()
function since the USBCBCheckOtherReq() function is the apps method for getting the initial
control transfer before the data arrives.
*******************************************************************/
#if defined(ENABLE_EP0_DATA_RECEIVED_CALLBACK)
void USBCBEP0DataReceived(void)
{
}
#endif
/*******************************************************************
* Function: BOOL USER_USB_CALLBACK_EVENT_HANDLER(
* USB_EVENT event, void *pdata, WORD size)
*
* Precondition: None
*
* Input: USB_EVENT event - the type of event
* void *pdata - pointer to the event data
* WORD size - size of the event data
*
* Output: None
*
*
* Overview: This function is called from the USB stack to notify a user application that a USB
event occurred. This callback is in interrupt context when the USB_INTERRUPT option is
selected.

*******************************************************************/
BOOL USER_USB_CALLBACK_EVENT_HANDLER(USB_EVENT event, void *pdata, WORD
size)
{
switch(event)
{
case EVENT_CONFIGURED:
USBCBInitEP();
break;
case EVENT_SET_DESCRIPTOR:
USBCBStdSetDscHandler();
break;
case EVENT_EP0_REQUEST:
USBCBCheckOtherReq();
break;
case EVENT_SOF:
USBCB_SOF_Handler();
break;
case EVENT_SUSPEND:
USBCBSuspend();
break;
case EVENT_RESUME:
USBCBWakeFromSuspend();
break;
case EVENT_BUS_ERROR:
USBCBErrorHandler();
break;
case EVENT_TRANSFER:
Nop();
break;
default:
break;
}
return TRUE;
}
/** EOF main.c *************************************************/

Physical Research Laboratory Data Logger Code
APPENDIX B
DATA LOGGER

SIMS.VB
'Here are some useful articles when creating new PC applications for
COM ports:
'(links valid as of April 1, 2009)
'
'"SerialPort Class"
'http://msdn.microsoft.com/en-
us/library/system.io.ports.serialport.aspx
'
'"SerialPort Members"
us/library/system.io.ports.serialport_members.aspx
'
'"SerialPort.DataReceived Event"
us/library/system.io.ports.serialport.datareceived.aspx
'
'"How to: Make Thread-Safe Calls to Windows Forms Controls"
'http://msdn.microsoft.com/en-us/library/ms171728(VS.80).aspx
'
'"Visual Basic Developer Center"
'http://msdn.microsoft.com/en-us/vbasic/default.aspx?pull=/library/en-
us/vbcon/html/vboriintroductiontovisualbasic70forvisualbasicveterans.as
p
Imports System.IO.Ports
Imports System.Data.OleDb
Public Class Form1
'Create a delegate function for this thread that will take

' in a string and will write it to the txtDataReceived textbox
Delegate Sub SetTextCallback(ByVal [text] As String)
'**********************************************************************
' Function:
' private void UpdateCOMPortList()
'
' Summary:
' This function updates the COM ports listbox.
'
' Description:
' This function updates the COM ports listbox.This function
is launched periodically based on its Interval attribute (set in the
form editor under the properties window).
'
' Precondition:
' None
'
' Parameters:
' None
'
' Return Values
' None
'
' Remarks:

' None
'*********************************************************************
Private Sub UpdateCOMPortList()
Dim s As String
Dim i As Integer
Dim foundDifference As Boolean
i = 0
foundDifference = False
'If the number of COM ports is different than the last time we
' checked, then we know that the COM ports have changed and we
' don't need to verify each entry.
If lstCOMPorts.Items.Count = SerialPort.GetPortNames().Length
Then
'Search the entire SerialPort object. Look at COM port name
' returned and see if it already exists in the list.
For Each s In SerialPort.GetPortNames()
'If any of the names have changed then we needto update list
If lstCOMPorts.Items(i).Equals(s) = False Then
foundDifference = True
End If
i = i + 1
Next s
Else
foundDifference = True
End If
'If nothing has changed, exit the function.

If foundDifference = False Then
Exit Sub
End If
'If something has changed, then clear the list

lstCOMPorts.Items.Clear()
'Add all of the current COM ports to the list

For Each s In SerialPort.GetPortNames()
lstCOMPorts.Items.Add(s)
Next s
'Set the listbox to point to the first entry in the list
lstCOMPorts.SelectedIndex = 0
End Sub
'**********************************************************************
' Function:
' private void DataSplitter()
'
' Summary:
' This function breaks up the incoming data, validates it &
logs it into the appropriate textboxes.
'
' Description:
'
' Precondition:

It has been assumed that Data will be transmitted in the

following format. If there is achange in this format then appropriate
change should be made in the code here.
'Data Packet<D16:1010101010101010,ADC01:0000001010101010,
ADC02:0000001010101010, ADC03:0000001010101010,
ADC04:0000001010101010, ADC05:0000001010101010,
ADC06:0000001010101010, ADC07:0000001010101010,
ADC08:0000001010101010>
'Length 214
'
' Parameters:
' None
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************
Private Sub DataSplitter()

Dim DataValidated As Boolean
If (txtDataReceived.Text.Length = 214) Then

DataValidated = True
txtdatastatus.AppendText("Packet Size Verified")
Else
txtdatastatus.Text = "Packet Size Corrupted"
DataValidated = False
Return
End If
If (txtDataReceived.Text.Substring(1, 1).Equals("<") = True)

Then
txtdatastatus.AppendText("Start of packet Verified")
Else
txtdatastatus.Text = "Start of packet Corrupted"
Return
End If
If (txtDataReceived.Text.Substring(214, 1).Equals(">") = True)

Then
txtdatastatus.AppendText("End of packet Verified")
Else
txtdatastatus.Text = "End of packet Corrupted"
Return
End If
If (DataValidated = True) Then

txtduovacuum.Text = "9.25"

' Include the data processing code here. A example of processing a

Digital channel is shown below.
If (txtDataReceived.Text.Substring(1, 1).Equals("1") =
True) Then
txtduoprim.Text = "ON"
ElseIf (txtDataReceived.Text.Substring(1, 1).Equals("0") =
True) Then
txtduoprim.Text = "OFF"
Else
txtduoprim.Text = "Err"
End If
txtDataReceived.Text.Substring(12, 10)
= "6.23" 'txtDataReceived.Text.Substring(23, 10)
= "4.45" 'txtDataReceived.Text.Substring(34, 10)
= "15"
' Similarly add code for processing other channels . analog channels
can also be taken care of by providing appropriate conversion code.
This will depend on the format in which the data is transmitted hence
is left to be decided in the Phase-2.
The processsed value could be stored in a variable or directly entered

to their respective text boxes.
txtion1.Text txtrotrot.Text
txtion2.Text txtrotsc.Text
txtwatertemp.Text txtturboduo.Text
txtlabtemp.Text txtturboprim.Text
txtlabhum.Text txtturbosc.Text
txtduochngd.Text txtturboscr.Text
txtgaldenlevel.Text txtgaldenflow.Text
txtwaterflow.Text txtwaterlevel.Text
Call data logging function to log these values to the database.
DataLogging()
End If '(DataValidated = True)

End Sub
'**********************************************************************
' Function:
' private void Datalogging()
'
' Summary:
' This function logs the data from the textboxes to their
appropriate tables in the MS ACCESS database.
'
' Description:
'
' Precondition:
' None
' Parameters:
' None
'
' Return Values
' None
'

' Remarks:
' None
'*********************************************************************
Private Sub DataLogging()

Dim cn As OleDbConnection
Dim ds As DataSet
Dim da As OleDbDataAdapter
cn = New OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=D:\\Dashboard_prl\\Database\\ionprobe.mdb; Persist Security
Info=False;")
cn.Open()
txtdatastatus.Text = "Database Opened"
da = New OleDbDataAdapter("INSERT INTO GaldenFlow

(date_time,Galden_Flow) VALUES(#" & System.DateTime.Now & "# ,'" &
txtgaldenflow.Text & "')", cn)
ds = New DataSet()
da.Fill(ds, "galdenf")
'On Similar basis data can be inserted of the remaining parameter

values.
txtdatastatus.Text = "Data Inserted"
cn.Close()
End Sub
'**********************************************************************
' Function:
' private void timer1_Tick(object sender, EventArgs e)
'
' Summary:
' This function updates the COM ports listbox.
'
' Description:
' This function updates the COM ports listbox. This function
is launched periodically based on its Interval attribute (set in the
form editor under the properties window).
'
' Precondition:
' None
'
' Parameters:
' object sender - Sender of the event (this form)
' EventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Timer1.Tick
'Update the COM ports list so that we can detect

' new COM ports that have been added.

UpdateCOMPortList()
txtsystime.Text = Convert.ToString(System.DateTime.Now())
End Sub
'*********************************************************************
' Function:
' private void btnConnect_Click(object sender, EventArgs e)
'
' Summary:
' This function opens the COM port.
'
' Description:
' This function opens the COM port. This function is
launched when the btnConnect button is clicked. In addition to opening
the COM port, this function will also change the Enable attribute of
several of the form objects to disable the user from opening a new COM
port.
'
' Precondition:
' None
'
' Parameters:
'
' Return Values
' None
'
' Remarks:
' None
'********************************************************************/
Private Sub btnConnect_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnConnect.Click
Try
'Get the port name from the application list box.
' the PortName attribute is a string name of the COM
' port (e.g. - "COM1").
SerialPort1.PortName =
lstCOMPorts.Items(lstCOMPorts.SelectedIndex).ToString()
'Open the COM port.

SerialPort1.Open()
'Change the state of the application objects

btnConnect.Enabled = False
lstCOMPorts.Enabled = False
btnClose.Enabled = True
'Clear the textbox and print that we are connected.

' txtDataReceived.Clear()
' txtDataReceived.AppendText("Connected." + vbCrLf)
txtdatastatus().Clear()
txtdatastatus.AppendText("Connected." + vbCrLf)
Catch ex As Exception
'If there was an exception, then close the handle to

' the device and assume that the device was removed
btnClose_Click(Me, e)
End Try
End Sub
'**********************************************************************
' Function:
' private void btnClose_Click(object sender, EventArgs e)
'
' Summary:
' This function closes the COM port.
'
' Description:
' This function closes the COM port. This function is
launched when the btnClose button is clicked. This function can also
be called directly from other functions. In addition to closing the
COM port, this function will also change the Enable attribute of
several of the form objects to enable the user to open a new COM port.
'
' Precondition:
' None
'
' Parameters:
'
' Return Values
' None
'
' Remarks:
' None
'********************************************************************/
Private Sub btnClose_Click(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles btnClose.Click
'Reset the state of the application objects
btnClose.Enabled = False
btnConnect.Enabled = True
lstCOMPorts.Enabled = True
'This section of code will try to close the COM port.

' Please note that it is important to use a try/catch
' statement when closing the COM port. If a USB virtual
' COM port is removed and the PC software tries to close
' the COM port before it detects its removal then
' an exeception is thrown. If the execption is not in a
' try/catch statement this could result in the application
' crashing.
Try
'Dispose the In and Out buffers;

SerialPort1.DiscardOutBuffer()
'txtdatastatus.Text = "OUT Buffer Discarded"
SerialPort1.DiscardInBuffer()
'txtdatastatus.Text = "In Buffer Discarded"
'Close the COM port

SerialPort1.Close()
'If there was an exeception then there isn't much we can
' do. The port is no longer available.
End Try
End Sub
'*********************************************************************
' Function:
' private void serialPort1_DataReceived( object sender,
'
SerialDataReceivedEventArgs e)
'
' Summary:
' This function prints any data received on the COM port.
'
' Description:
' This function is called when the data is received on the
COM port. This function attempts to write that data to the
txtDataReceived textbox. If an exception occurs the btnClose_Click()
function is called in order to close the COM port that caused the
exception.
'
' Precondition:
' None
'
' Parameters:
' SerialDataReceivedEventArgs e - The event arguments
'
' Return Values
' None
'
' Remarks:
' None
'*****************************************************************/
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object,
ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles
SerialPort1.DataReceived
'The ReadExisting() function will read all of the data that
' is currently available in the COM port buffer. In this
' example we are sending all of the available COM port data
' to the SetText() function.
'
' NOTE: the <SerialPort>_DataReceived() function is launched
' in a seperate thread from the rest of the application. A
' delegate function is required in order to properly access
' any managed objects inside of the other thread. Since we
' will be writing to a textBox (a managed object) the delegate
' function is required. Please see the SetText() function for
'more information about delegate functions and how to use them.
Try
SetText(SerialPort1.ReadExisting())


End Try
End Sub
'*********************************************************************
' Function:
' private void SetText(string text)
'
' Summary:
'This function prints the input text to the txtDataReceived
textbox.
'
' Description:
' This function prints the input text to the txtDataReceived
textbox. If the calling thread is the same as the thread that owns the
textbox, then the AppendText() method is called directly. If a thread
other than the main thread calls this function, then an instance of the
delegate function is created so that the function runs again in the
main thread.
'
' Precondition:
' None
'
' Parameters:
' string text - Text that needs to be printed to the textbox
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub SetText(ByVal [text] As String)
'InvokeRequired required compares the thread ID of the
' calling thread to the thread ID of the creating thread.
' If these threads are different, it returns true. We can
' use this attribute to determine if we can append text
' directly to the textbox or if we must launch an a delegate
' function instance to write to the textbox.
If txtDataReceived.InvokeRequired Then
'InvokeRequired returned TRUE meaning that this function
' was called from a thread different than the current
' thread. We must launch a deleage function.
'Create an instance of the SetTextCallback delegate and

' assign the delegate function to be this function. This
' effectively causes this same SetText() function to be
' called within the main thread instead of the second
' thread.
Dim d As New SetTextCallback(AddressOf SetText)
'Invoke the new delegate sending the same text to the

' delegate that was passed into this function from the
' other thread.
Invoke(d, New Object() {[text]})

Else
'If this function was called from the same thread that
' holds the required objects then just add the text.
txtDataReceived.AppendText(text)
DataLogging()
DataSplitter()
End If
End Sub
'**********************************************************************
' Function:
' private void btnSendData_Click(object sender, EventArgs e)
'
' Summary:
' This function will attempt to send the contents of txtData
over the COM port
'
' Description:
' This function is called when the btnSendData button is
clicked. It will attempt to send the contents of txtData over the COM
port. If the attempt is unsuccessful this function will call the
btnClose_Click() in order to
' close the COM port that just failed.
'
' Precondition:
' None
'
' Parameters:
'
' Return Values
' None
'
' Remarks:
' None
'*********************************************************************/
Private Sub btnSendData_Click(ByVal sender As System.Object, ByVal
e As System.EventArgs) Handles btnSendData.Click
Try
'Write the data in the text box to the open serial port
SerialPort1.Write(txtData.Text)
End Try
End Sub

APPENDIX C
DASHBOARD
Physical Research Laboratory Dashboard Code
LOGIN.ASPX.CS
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using System.Data.OleDb;
public partial class login : System.Web.UI.Page

{
OleDbConnection cn;
OleDbCommand cmd;
OleDbDataAdapter da;
DataSet ds;
protected void Page_Load(object sender, EventArgs e)
{
this.btnSubmit.Click += new EventHandler(btnSubmit_Click);
}
void btnSubmit_Click(object sender, EventArgs e)
{
if (this.TextBox1.Text.ToString() != "" &&
this.TextBox2.Text.ToString() != "")
{
cn = new
OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" +
Server.MapPath("Database\\ionprobe.mdb" ) +";Persist Security
Info=False");
da = new OleDbDataAdapter("select name from login where
userid='" + this.TextBox1.Text.ToString() +"' and password='" +
this.TextBox2.Text.ToString() +"'",cn);
ds = new DataSet();
da.Fill(ds,"test");
if (ds.Tables["test"].Rows.Count != 0)
{
string strScript;
strScript = "<script language=javascript>";
strScript += "OpenNewWindow('dashboard.aspx?user_name="
+ ds.Tables["test"].Rows[0][0].ToString()
+"','PRLDashboard','status=1,scroll=no,location=no,resizable=1');";
strScript += "</script>\n";
ClientScript.RegisterClientScriptBlock(typeof(Page),
"new_window", strScript);
//Response.Redirect("dashboard.aspx");
}
else
{
Response.Write("invalid user id");
}
}
}
}

DASHBOARD.ASPX.CS
using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
using Dundas.Charting.WebControl;
using Dundas.Gauges.WebControl;
using System.Data.OleDb;
public partial class dashboard : System.Web.UI.Page

{
OleDbConnection cn;
OleDbCommand cmd;
OleDbDataAdapter da;
DataSet ds;
protected void Page_Load(object sender, EventArgs e)

{
this.btnMain.Click += new EventHandler(btnMain_Click);
this.btnDetail.Click += new EventHandler(btnDetail_Click);
this.ddlPump.SelectedIndexChanged += new
EventHandler(ddlPump_SelectedIndexChanged);
this.ddlTemp.SelectedIndexChanged += new
EventHandler(ddlTemp_SelectedIndexChanged);
this.ddlPlasma.SelectedIndexChanged += new
EventHandler(ddlPlasma_SelectedIndexChanged);
this.btnFetch.Click += new EventHandler(btnFetch_Click);
this.pnl1.Style.Clear();
this.pnl1.Style.Add("Display", "None");
if (!this.IsPostBack)
{
this.loginid.Text
=Request.QueryString["user_name"].ToString();
this.btnMain_Click(null, null);
}
}
void btnFetch_Click(object sender, EventArgs e)

{
this.pump();
this.duo();
this.temp();
}
void ddlPlasma_SelectedIndexChanged(object sender, EventArgs e)

{
this.duo();
}

void ddlTemp_SelectedIndexChanged(object sender, EventArgs e)

{
this.temp();
}
void ddlPump_SelectedIndexChanged(object sender, EventArgs e)

{
this.pump();
}
private void last_level()

{
cn = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" + Server.MapPath("Database\\ionprobe.mdb") + ";Persist
Security Info=False");
cn.Open();
da = new OleDbDataAdapter("select max(date_time) from

Galdenlevel where Galden_level='Low'", cn);
ds = new DataSet();
da.Fill(ds, "galden");
if (ds.Tables["galden"].Rows.Count != 0)
{
this.lblFreonlast.Text =
ds.Tables["Galden"].Rows[0][0].ToString().Trim();
}
da = new OleDbDataAdapter("select max(date_time) from

waterlevel where water_level='Low'", cn);
ds = new DataSet();
da.Fill(ds, "waterl");
if (ds.Tables["waterl"].Rows.Count != 0)
{
this.lblWaterllast.Text =
ds.Tables["waterl"].Rows[0][0].ToString().Trim();
}
da = new OleDbDataAdapter("select max(date_time) from waterflow

where water_flow='Low'", cn);
ds = new DataSet();
da.Fill(ds, "waterf");
if (ds.Tables["waterf"].Rows.Count != 0)
{
this.lblWaterflast.Text =
ds.Tables["waterf"].Rows[0][0].ToString().Trim();
}
cn.Close();
}
private void pump()

{
cn.Open();

da = new OleDbDataAdapter("select date,pressure from

pumppressure where pumpid='" +
this.ddlPump.SelectedItem.Value.ToString().Trim() + "' and (date
between #" + this.txtFrom.Text.ToString().Trim() + "# and #" +
this.txtTo.Text.ToString().Trim() + "#)", cn);
ds = new DataSet();
da.Fill(ds, "pump");
if (ds.Tables["pump"].Rows.Count != 0)
{
dcPump.Series[0].ValueMemberX =
ds.Tables["pump"].Columns["date"].ColumnName;
dcPump.Series[0].ValueMembersY =
ds.Tables["pump"].Columns["pressure"].ColumnName;
dcPump.DataSource = ds.Tables["pump"];
dcPump.DataBind();
}
cn.Close();
}
private void duo()

{
cn.Open();
da = new OleDbDataAdapter("select startdate,status from
duodetails where id='" +
this.ddlPlasma.SelectedItem.Value.ToString().Trim() + "' and (startdate
between #" + this.txtFrom.Text.ToString().Trim() + "# and #" +
ds = new DataSet();
da.Fill(ds, "duo1");
if (ds.Tables["duo1"].Rows.Count != 0)
{
dcPlasma.Series[0].ValueMemberX =
ds.Tables["duo1"].Columns["startdate"].ColumnName;
dcPlasma.Series[0].ValueMembersY =
ds.Tables["duo1"].Columns["status"].ColumnName;
dcPlasma.DataSource = ds.Tables["duo1"];
dcPlasma.DataBind();
}
cn.Close();
}
private void temp()

{
cn.Open();
if (this.ddlTemp.SelectedItem.Value == "WaterTemp")
{
da = new OleDbDataAdapter("select
date_time,water_temperature from watertemp where (date_time between #"
+ this.txtFrom.Text.ToString().Trim() + "# and #" +
}

else if (this.ddlTemp.SelectedItem.Value == "LabTemp")

{
da = new OleDbDataAdapter("select date_time,lab_temperature
from labtemp where (date_time between #" +
this.txtFrom.Text.ToString().Trim() + "# and #" +
}
else if (this.ddlTemp.SelectedItem.Value == "LabHumidity")
{
da = new OleDbDataAdapter("select date_time,lab_humidity
from labhumidity where (date_time between #" +
this.txtFrom.Text.ToString().Trim() + "# and #" +
}
ds = new DataSet();
da.Fill(ds, "temp_humid");
if (ds.Tables["temp_humid"].Rows.Count != 0)
{
dcTemp.Series[0].ValueMemberX =
ds.Tables["temp_humid"].Columns[0].ColumnName;
dcTemp.Series[0].ValueMembersY =
ds.Tables["temp_humid"].Columns[1].ColumnName;
dcTemp.DataSource = ds.Tables["temp_humid"];
dcTemp.DataBind();
}
cn.Close();
}
void btnDetail_Click(object sender, EventArgs e)

{
this.DirSearch();
this.pnlDetail.Visible = true;
this.pnlGeneral.Visible = false;
this.btnMain.CssClass = "TableHeaderClick";
this.btnDetail.CssClass = "ButtonHeader";
this.txtFrom.Text=
Convert.ToDateTime(System.DateTime.Now.AddDays(-30)).ToString("dd MMM
yyyy");
this.txtTo.Text=
Convert.ToDateTime(System.DateTime.Now).ToString("dd MMM yyyy");
cn.Open();
da = new OleDbDataAdapter("select distinct id from duomain",
cn);
ds = new DataSet();
da.Fill(ds, "plasma");
if (ds.Tables["plasma"].Rows.Count != 0)
{
this.ddlPlasma.Items.Clear();
this.ddlPlasma.DataSource = ds.Tables["plasma"];
this.ddlPlasma.DataValueField = "id";
this.ddlPlasma.DataTextField = "id";
this.ddlPlasma.DataBind();

}
da = new OleDbDataAdapter("select id from duomain where enddate
is null", cn);
ds = new DataSet();
da.Fill(ds, "plasmac");
if (ds.Tables["plasmac"].Rows.Count != 0)
{
this.ddlPlasma.SelectedIndex = -1;
this.ddlPlasma.Items.FindByValue(ds.Tables["plasmac"].Rows[0][0].ToStri
ng().Trim()).Selected = true;
}
cn.Close();
this.pump();
this.duo();
this.temp();
this.last_level();
void btnMain_Click(object sender, EventArgs e)

{
this.DirSearch();
this.pnlDetail.Visible = false;
this.pnlGeneral.Visible = true;
this.btnMain.CssClass = "ButtonHeader";
this.btnDetail.CssClass = "TableHeaderClick";
cn.Open();
da = new OleDbDataAdapter("select total_time from duomain where
enddate is null", cn);
ds = new DataSet();
da.Fill(ds, "plasma");
if (ds.Tables["plasma"].Rows.Count != 0)
{
dgcPlamatron.CircularGauges["duohours"].Pointers["Default"].Value =
Convert.ToDouble(ds.Tables["plasma"].Rows[0][0].ToString());
dgcPlamatron.NumericIndicators["NumericIndicator1"].Value =
dgcPlamatron.CircularGauges["duohours"].Pointers["Default"].Value;
}
da = new OleDbDataAdapter("select max(date),pumpid,pressure

from pumppressure group by date,pumpid,pressure", cn);
ds = new DataSet();
da.Fill(ds, "pump1");
if (ds.Tables["pump1"].Rows.Count != 0)
{
for (int i = 0; i < ds.Tables["pump1"].Rows.Count; i++)
{
if (ds.Tables["pump1"].Rows[i][1].ToString() == "ion1")
{
dgcIon.CircularGauges["Ion1"].Pointers["Default"].Value =
Convert.ToDouble(ds.Tables["pump1"].Rows[i][2].ToString());

dgcIon.NumericIndicators["NumericIndicator1"].Value =
dgcIon.CircularGauges["Ion1"].Pointers["Default"].Value;
}
if (ds.Tables["pump1"].Rows[i][1].ToString() == "ion2")
{
dgcIon.CircularGauges["Ion2"].Pointers["Default"].Value =
dgcIon.NumericIndicators["NumericIndicator2"].Value =
dgcIon.CircularGauges["Ion2"].Pointers["Default"].Value;
}
if (ds.Tables["pump1"].Rows[i][1].ToString() ==
"rotary1")
{
dgcrotarysample.CircularGauges["Rotary1"].Pointers["Default"].Value =
dgcrotarysample.NumericIndicators["NumericIndicator1"].Value =
dgcrotarysample.CircularGauges["Rotary1"].Pointers["Default"].Value;
}
"rotary2")
{
dgcrotarysample.CircularGauges["Rotary2"].Pointers["Default"].Value =
dgcrotarysample.NumericIndicators["NumericIndicator2"].Value =
dgcrotarysample.CircularGauges["Rotary2"].Pointers["Default"].Value;
}
if (ds.Tables["pump1"].Rows[i][1].ToString() == "duo")
{
dgcduovacuum.CircularGauges["duovacuum"].Pointers["Default"].Value =
dgcduovacuum.NumericIndicators["duovacuum1"].Value =
dgcduovacuum.CircularGauges["duovacuum"].Pointers["Default"].Value;
}
}
}
da = new OleDbDataAdapter("select max(date),pumpid,speed from

pumpspeed group by date,pumpid,speed", cn);
ds = new DataSet();
da.Fill(ds, "pump2");
if (ds.Tables["pump2"].Rows.Count != 0)
{
for (int i = 0; i < ds.Tables["pump2"].Rows.Count; i++)
{
"turbo1")
{
dgcturbo.CircularGauges["Turbo1"].Pointers["Default"].Value =

dgcturbo.NumericIndicators["C DUO"].Value =
dgcturbo.CircularGauges["Turbo1"].Pointers["Default"].Value;
}
"turbo2")
{
dgcturbo.NumericIndicators["C Prim"].Value =
}
"turbo3")
{
dgcturbo.NumericIndicators["C SC"].Value =
}
"turbo4")
{
dgcturbo.NumericIndicators["C SCR"].Value =
}
}
}
max(date_time),water_temperature from watertemp group by
date_time,water_temperature", cn);
ds = new DataSet();
da.Fill(ds, "water_temp");
if (ds.Tables["water_temp"].Rows.Count != 0)
{
dgcchillerlabTemphumid.LinearGauges["Chiller"].Pointers["Default"].Valu
e = Convert.ToDouble(ds.Tables["water_temp"].Rows[0][1].ToString());
dgcchillerlabTemphumid.NumericIndicators["NumericIndicator1"].Value =
dgcchillerlabTemphumid.LinearGauges["Chiller"].Pointers["Default"].Valu
e;
}
max(date_time),lab_temperature from labtemp group by
date_time,lab_temperature", cn);
ds = new DataSet();

da.Fill(ds, "lab_temp");
if (ds.Tables["lab_temp"].Rows.Count != 0)
{
dgcchillerlabTemphumid.LinearGauges["labtemp"].Pointers["Default"].Valu
e = Convert.ToDouble(ds.Tables["lab_temp"].Rows[0][1].ToString());
dgcchillerlabTemphumid.LinearGauges["labtemp"].Pointers["Default"].Valu
e;
}
//--------------- Lab Humidity------------------ Lab Humidity--------
da = new OleDbDataAdapter("select max(date_time),lab_humidity
from labhumidity group by date_time,lab_humidity", cn);
ds = new DataSet();
da.Fill(ds, "lab_humid");
if (ds.Tables["lab_humid"].Rows.Count != 0)
{
dgcchillerlabTemphumid.LinearGauges["labhumid"].Pointers["Default"].Val
ue = Convert.ToDouble(ds.Tables["lab_humid"].Rows[0][1].ToString());
dgcchillerlabTemphumid.LinearGauges["labhumid"].Pointers["Default"].Val
ue;
}
//------------------ Water Level------------------ Water Level--------
da = new OleDbDataAdapter("select max(date_time),water_level_value

from waterlevel group by date_time,water_level_value", cn);
ds = new DataSet();
da.Fill(ds, "waterl");
if (ds.Tables["waterl"].Rows.Count != 0)
{
dgcchiller.LinearGauges["waterlevel"].Pointers["Default"].Value =
Convert.ToDouble(ds.Tables["waterl"].Rows[0][1].ToString());
dgcchiller.NumericIndicators["waterlevel"].Style =
NumericIndicatorStyle.Mechanical;
if ((ds.Tables["waterl"].Rows[0][1].ToString()) == "1")
{
dgcchiller.NumericIndicators["waterlevel"].FormatString
= "LOW";
}
else
{
dgcchiller.NumericIndicators["waterlevel"].FormatString
= "OK";
}
}
cn.Close();
}

Physical Research Laboratory Datasheetts
APPENDIX D
DATASHEETS

APPENDIX D
DATASHEETS













SIMS Sunil

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SIMS Sunil

Hochgeladen von

Copyright:

Verfügbare Formate

Project Report

24 CHANNEL DATA ACQUISITION SYSTEM (DAS)

SUBMITTED IN PARTIAL FULFILLMENT FOR THE

Mr. Chandresh Parekh Dr. Kuljeet Kaur Marhas

And Submitted the Project Report on

24 CHANNEL DATA ACQUISITION SYSTEM

as a partial fulfillment of the requirement for the award of

Date of Submission ___________

1. About Physical Research Laboratory … … … 1

GEC, Gandhinagar ii Sunil S Pillai

8. Dashboard Web Service … … … … … 58

11. Appendix A : Firmware Code … … … … … 79

12. Appendix B : Data Logger Code … … … … 92

13. Appendix C : Dashboard Code … … … … 104

14. Appendix D : Datasheet… … … … … … 117

GEC, Gandhinagar iii Sunil S Pillai

GEC, Gandhinagar iv Sunil S Pillai

I am grateful to my sister Ms. Soumya Pillai (Software Executive-RISL) for

Thanking You All.

GEC, Gandhinagar v Sunil S Pillai

Table 5.1 USB Device Stack Files … … … … … … 34

Table 6.1 Parameters & their Associated Tables … … … … 46

Table 7.1 Duodetails Table Structure … … … … … 51

GEC, Gandhinagar vi Sunil S Pillai

Fig 2.1 Modular System Diagram … … … … … … 12

Fig 3.1 Data Flow diagram of the System … … … … … 19

Fig 4.1 Oscillator Block Diagram … … … … … … 29

Fig 6.1 Data flow diagram of Data logger … … … … … 41

GEC, Gandhinagar vii Sunil S Pillai

About Physical Research Laboratory

1.1 About Physical Research Laboratory

The Laboratory was formally established on November 11, 1947, in the M. G.

The main campus at Navrangpura was inaugurated by Pt. Jawaharlal Nehru in

• Astronomy & Astrophysics • Solar Physics

GEC, Gandhinagar 2 Sunil S Pillai

1.2 About Planetary Science Division

1. Pre-Solar and Early Solar system processes;

1. Thermal Ionization Mass Spectrometer (TIMS) ;

New Additions (Along with PLANEX):

GEC, Gandhinagar 3 Sunil S Pillai

1.3 About Ion Probe Laboratory

1.4 About SIMS

The detail of following major parts of SIMS is mentioned below.

GEC, Gandhinagar 4 Sunil S Pillai

Fig 1.1 Cameca IMS 4f Geometry

1.4.1 SIMS Primary Ion Sources

Fig 1.2 Duoplasmatron Structure

GEC, Gandhinagar 5 Sunil S Pillai

1.4.2 SIMS Primary Ion Column

Fig 1.3 Primary Column

GEC, Gandhinagar 6 Sunil S Pillai

1.4.3 Secondary Ion Extraction and Transfer

The field aperture is located

Ions that arise from off the

GEC, Gandhinagar 7 Sunil S Pillai

1.4.4 Ion Energy Analyzers

Fig 1.5 Electrostatic sector

1.4.5 Mass Analyzers

GEC, Gandhinagar 8 Sunil S Pillai

Fig 1.6 Entrance & Exit slits

Quadrupole mass analyzers were invented in 1953. Many kinds of analysis,

GEC, Gandhinagar 9 Sunil S Pillai

Fig 1.7 Quadrupole Mass Analyzer