File: pramode.html

package info (click to toggle)
lg-issue111 1-1
links: PTS
area: main
in suites: sarge
size: 1,736 kB
ctags: 35
sloc: makefile: 34; sh: 34
file content (439 lines) | stat: -rw-r--r-- 15,521 bytes

<html>
<head>
<link href="../lg.css" rel="stylesheet" type="text/css" media="screen, projection"  />
<link rel="shortcut icon" href="../favicon.ico" />
<title>Experimental Physics with Phoenix and Python LG #111</title>

<style type="text/css" media="screen, projection">
<!--

-->
</style>

<link rel="alternate" type="application/rss+xml" title="LG RSS" href="lg.rss" />
<link rel="alternate" type="application/rdf+xml" title="LG RDF" href="lg.rdf" />
<link rel="alternate" type="application/atom+xml" title="LG Atom" href="lg.atom.xml" />

</head>

<body>


<img src="../gx/2003/newlogo-blank-200-gold2.jpg" id="logo" alt="Linux Gazette"/>
<p id="fun">...making Linux just a little more fun!</p>


<div class="content articlecontent">

<div id="previousnexttop">
<A HREF="oregan.html" >&lt;-- prev</A> | <A HREF="ramankutty.html" >next --&gt;</A>
</div>



<h1>Experimental Physics with Phoenix and Python</h1>
<p id="by"><b>By <A HREF="../authors/pramode.html">Pramode C.E.</A></b></p>

<p>
<p>
Many of us who had our schooling in the distant past
will be having fond memories of time spent in the
science laboratories learning fun and exciting things
about the world around us. I had a fascination for
Chemistry and still recollect doing mildly dangerous
experiments with thoroughly user-unfriendly stuff like
sulfuric acid behind the closed doors of my `private'
home laboratory. Physics was a bit too `intellectual' for
my taste, but I was nonetheless excited when I came 
across the <a href="http://www.nsc.res.in/~elab/phoenix">
Phoenix Project</a> which aims to bring  modern 
techniques of `computer based' experimental physics within
the reach of students and the hobbyist in developing
countries. This article is written with the intention of 
getting teachers and GNU/Linux enthusiasts involved with the 
project thereby initiating a `community building' effort.

<h2>What is Phoenix?</h2>
<p>
The Phoenix project is the brainchild of <b>B. P. Ajith Kumar</b>,
a researcher working with the <a href="http://www.nsc.res.in/">
Nuclear Science Centre</a> of India. Ajith describes Phoenix as
<b>Physics with Homemade Equipments and Innovative Experiments</b>.
Modern experimental physics makes use of a vast array of complex
equipments interfaced with general purpose computers. The data
gathered by these equipments is fed into the machine using 
expensive `Data Acquisition Hardware' (mostly high speed Analog-to-Digital
converters) where it is analyzed by sophisticated mathematical tools.
The current practice of undergraduate Physics education (at least in the
part of the world I live) pays only lip service to this
important aspect of the training of a Physicist by incorporating
a paper on `C programming' and/or `Microprocessors' in the 
syllabus. The objective
of the Phoenix project is to change the situation for the better
by giving school/college students an opportunity to use the computer
for observing and analyzing real-world phenomena. 
<p>
Let me  present two simple examples. Measuring time is
something which is central to many experiments. Say you wish
to measure time of flight of an object under gravity. You note
the exact time at which it is dropped; you also measure the time at which
it hits the ground. A small steel ball can be easily gripped by
an electromagnet which is activated by the PC parallel port. The
ball can be dropped by deactivating the coil (just a simple `out'
instruction to the parallel port). When the ball hits the `ground',
it can be made to close/open some kind of `contact' connected to
an input pin of the parallel port. A few lines of code which measures
the time at which a parallel port output pin deactivates the coil and
the time at which an input pin changes state should be sufficient to
verify an important physics principle 
(<a href="http://www.nsc.res.in/~elab/phoenix/expt/gravity/index.html">Check this out
</a>).

<p>
What are the major stumbling blocks behind presenting such an
experiment? 
<ul>
<li>The time/effort involved in building additional hardware
(in this case, buffer the parallel port pins to make it capable
of driving relay coils).
<li>The effort involved in writing low-level code. Parallel port
I/O and time measurements are trivial to the experienced programmer,
but may overwhelm students who have had very little previous 
exposure to both programming and electronics.
</ul>

<p>
As another example, in basic circuit theory, we learn about the
way resistor-capacitor networks behave. A low-cost 8-bit analog
to digital converter connected to the parallel port and sampling the
voltage on the capacitor periodically will yield lots of numbers
which can be analyzed to get a better feel of the way RC networks
behave. Again, the major constraints involved here are setting up
the ADC circuit and writing measurement programs. There is a solution
- purchase commercially available data acquisition hardware and
software; this may not be attractive because of the expenses involved.

<h2>The Phoenix Approach</h2>
<p>
For computer based physics experiments to be a reality in our
school laboratories, we need:

<ul>
<li>Inexpensive hardware built with components available in the
local market. The design should be freely available and should be
simple enough for students to understand in full, if they wish to.
<li>A set of experiments which the students can try out
without building additional electronic circuits. Too much friction
in the beginning may discourage some of the target audience
(while some others might relish it as a challenge!).
<li>A set of software tools which offers a smooth learning curve;
the source code must be freely available and motivated students encouraged to
read and tinker with it. The platform of choice is undoubtedly GNU/Linux
and the programming languages will be C/Python.
</ul>

<h2>Phoenix Hardware</h2>
<p>
Here is a picture of the fully assembled kit:
<p>
<img src="misc/pramode/panelphoto.jpg">
<p>
The hardware consists of:
<ul>
<li>Eight digital output pins.
<li>Four digital input pins.
<li>Four stepper motor driver pins. They can be used
for driving relay coils also.
<li>An 8 bit, 8 channel analog-to-digital converter.
<li>A programmable voltage supply, capable of generating
voltages in the +5V to -5V range.
</ul>
Besides these `programmable' elements, the device also
contains the following units which makes interfacing
simpler:
<ul>
<li>Amplifier blocks 
<li>A constant current supply
<li>Low frequency function generator (sine, triangular, square)
</ul>

<p>
A block diagram is available 
<a href="http://www.nsc.res.in/~elab/phoenix/phblock.png">here</a>.
You can follow <a href="http://www.nsc.res.in/~elab/phoenix/imap.html">
this link</a> to read a detailed description of the working of
each of the functional units. Full circuit schematics, with ready
to use PCB layout, are also available from the project 
<a href="http://www.nsc.res.in/~elab/phoenix/">home page</a>.
The design is almost stable; a few boxes have been fabricated
and distributed for testing purposes.

<h2>Phoenix Software</h2>
<p>
All the programmable units of the Phoenix kit can be 
manipulated by doing a few in/out instructions on the
parallel port. Two of the issues to be handled were:

<ul>
<li>Users shouldn't need any special privilege to access
the hardware.
<li>It should be possible to do reasonably precise time 
measurements at the sub-millisecond level.
</ul>

<p>
Three approaches were identified:

<ul>
<li>Do everything in user-space, non real-time.
<li>Do everything in user-space, but in real-time (say RTAI LXRT)
<li>Put the code in the kernel, as a proper `driver'
</ul>

<p>
The third approach was found to be relatively better.
Users won't need any special privileges, and kernel code
is guaranteed not to be disturbed by other processes (busy
timing loops in the kernel will freeze the system, but in
almost all cases, we need very short sub-second loops; so
this is not a big problem).

<p>
A sample driver program (still in the experimental 
phase!) can be downloaded from
<a href="http://pramode.net/phoenix/ph24.c.txt">here</a>.
You will observe that most of the code is one giant
`ioctl' which does things like setting the digital output
pins, reading the value on the input pins, setting the
voltage on the programmable voltage supply, reading the
ADC, measuring the time between a rising edge and a falling
edge on a digital I/O pin etc.

<h2>Phoenix and Python</h2>
<p>
One of the advantages of putting the timing-sensitive 
driver code in the kernel is that it now becomes possible
for us to interact with the hardware through a language like
Python, which can't be normally used for real-time work. 
Being a Python fan, one of the first things I did with the
Phoenix box was to try and write a simple Python library 
for talking with the hardware. My intention was to be able to
do things like:
<pre>

&gt;&gt;&gt; from phoenix import *
&gt;&gt;&gt; p = Phoenix() # We have a `phoenix object'
&gt;&gt;&gt; p.set_voltage(2000) # set the DAC output to 2000 mV
&gt;&gt;&gt; p.select_adc(0) # select ADC channel 0
&gt;&gt;&gt; p.zero_to_5000() # Digitize voltage on channel 0 and return value between 0 and 5000 mV.

</pre>

Such an interaction, which gives immediate feedback, might
be the beginning student's best introduction to the device.

<p>
As an aside, it's interesting to see how easily (and naturally)
Python can be used for doing sophisticated CS stuff (functional
programming, lambda calculus, closures... ) and regular, down
to earth, OS interaction as shown in the snippet above. The source
code for the (experimental!) Python module can be obtained from
<a href="http://pramode.net/phoenix/phoenix.py.txt">here</a>. Readers
might be interested in the use of the `fcntl' module and the
`struct' and `array' modules for performing the `ioctl' operations
required to control the device.

<h2>Experiments!</h2>
<p>
The Phoenix hardware as well as software provides a general
framework for easy interfacing and experimentation. I 
shall describe two very simple experiments I did with the 
box. The project
home page describes some more - one of which is an interesting simple
pendulum experiment; check it out 
<a href="http://www.nsc.res.in/~elab/phoenix/expt/pendulum/index.html">here</a>.
Designing more experiments is one area where a
community of teachers and developers can contribute a lot.

<h3>Time of flight</h3>
<p>
An electromagnet (a disassembled relay coil) is connected to
one of the stepper motor driver pins of the Phoenix box and is
used to hold a small iron ball tightly. The kernel driver code
contains a routine which de-energizes the relay coil, notes 
down the time and sits in a tight loop till an input pins goes
from low to high, noting down the time  when this happens.
The two timestamps are transmitted back to userland where a
Python program captures them and returns the difference.
<p>
The iron ball drops down when the relay coil is de-energized
and hits the table with a bang. A speaker is placed face down
on the table; it picks up the vibrations and converts them to
electrical signals. The weak electrical signals are amplified
by the amplifier blocks on the Phoenix box and fed to a digital
input pin which registers a transition from low to high. The
kernel driver code can very easily compute the difference in
time between the ball being released and the instance it hits
the table, giving rise to an electrical transition on the input
pin. This time difference can be plugged into a simple equation
and the distance travelled can be computed.
<p>
Here is a picture of the setup which I used for conducting
this experiment:
<p>
<img src="misc/pramode/flight.jpg">
<p>
And here is the Python code:
<pre>

from phoenix import *
p = Phoenix()
p.write_motors(0xf) # Energize stepper motor driver pins
t = p.get_drop_time() # Drop the ball and time it!
print t

</pre>

<h3>Discharging capacitor</h3>
<p>
The Phoenix kernel driver contains code to take repeated
samples from the ADC (with an optional delay in between).
It is possible to start taking samples when a particular
trigger is received - the trigger is in the form of a 
`falling edge' on digital input pin 0. This feature can
be used to plot the voltage across a discharging capacitor
(I used a 10K resistor and 100uF capacitor). Let's look
at the Python code segment:

<pre>

from phoenix import *

p = Phoenix()
p.select_adc(0)
# 1000 points, 2 ms delay between reads
r = p.trig_read_block(1000, 2000)
for val in r:
	print val[0], val[1]

</pre>
<p>
The trig_read_block function collects 1000 samples from the
ADC with an in-between delay of 2000 micro seconds. The
sample collection starts only when the trigger is received,
the trigger being a falling edge on digital input pin 0.
The value returned by the function is a list, each element of
which is a tuple of the form (timestamp, adval) where `timestamp'
is the instant of time when the sample was taken. The `for'
loop simply prints these numbers onto the screen; the output
can be redirected to a file and plotted using the powerful `gnuplot'
utility (a simple command at the gnuplot prompt of the
form <b>plot "a.dat"</b>). Here is the graph which I obtained:

<p>
<img src="misc/pramode/capacitor.jpg">


<h2>Future Direction</h2>
<p>
The Phoenix project has just come out of the lab. To 
become a success, like any Free Software/Hardware project, it 
must be able to attract a community of enthusiasts -
science teachers and students, electronics hobbyists, Linux
geeks, hardware hackers... Plenty of software has to be
written and new experiments designed. I hope that this article
will go a small way toward bringing in community
involvement. Please feel free to get in touch with me 
if you are interested in knowing more about the project or
wish to arrange a workshop/demonstration. Follow 
<a href="http://www.nsc.res.in/~elab/phoenix/distribution.html">
this link</a> to get in touch with the Phoenix developer and
learn more about getting the hardware/software.



</p>


<!-- *** BEGIN author bio *** -->
<P>&nbsp;
<P>
<!-- *** BEGIN bio *** -->
<hr>
<P>
<img ALIGN="LEFT" ALT="[BIO]" SRC="../gx/2002/note.png" class="bio">
<em>
I am an instructor working for IC Software in Kerala, India. I would have loved
becoming an organic chemist, but I do the second best thing possible, which is
play with Linux and teach programming!
</em>
<br CLEAR="all">
<!-- *** END bio *** -->

<!-- *** END author bio *** -->

<div id="articlefooter">

<p>
Copyright &copy; 2005, Pramode C.E.. Released under the
<a href="http://linuxgazette.net/copying.html">Open Publication
license</a>. Linux Gazette is not produced, sponsored, or endorsed by
its prior host, SSC, Inc.
</p>

<p>
Published in Issue 111 of Linux Gazette, February 2005
</p>

</div>


<div id="previousnextbottom">
<A HREF="oregan.html" >&lt;-- prev</A> | <A HREF="ramankutty.html" >next --&gt;</A>
</div>


</div>






<div id="navigation">

<a href="../index.html">Home</a>
<a href="../faq/index.html">FAQ</a>
<a href="../lg_index.html">Site Map</a>
<a href="../mirrors.html">Mirrors</a>
<a href="../mirrors.html">Translations</a>
<a href="../search.html">Search</a>
<a href="../archives.html">Archives</a>
<a href="../authors/index.html">Authors</a>
<a href="../contact.html">Contact Us</a>

</div>



<div id="breadcrumbs">

<a href="../index.html">Home</a> &gt; 
<a href="index.html">February 2005 (#111)</a> &gt; 
Article

</div>





<img src="../gx/2003/sit3-shine.7-2.gif" id="tux" alt="Tux"/>




</body>
</html>