Phoenix Article in Linux Gazette

3 Comments

I had submitted a slightly modified form of “The Story of Phoenix”, for publication in the Linux Gazette, and it has appeared in the August issue. Read Recent Developments in the Phoenix Project

Advertisements

The Phoenix Contest!

2 Comments

Are you smart enough to think of new experiments which can be carried out with Phoenix?! Try your hand in the Phoenix Experiment Contest and win Rs.10,000 and Phoenix kits!

The experiment submitted should be usable as a 2 to 3 hour lab experiment at Degree / PG level , having some amount of data analysis involved. The cost of sensors etc. to be added to the basic Phoenix box should be reasonable.

Ideas may be submitted before 31-Aug-08

For more details visit http://www.iuac.res.in/~elab/phoenix/prize.html

The Story of Phoenix

18 Comments

Looking back as my stay here at IUAC, Delhi comes to an end, it has been an extremely enriching experience for me, working on the Phoenix project under Ajith sir. He has been working at the Inter University Accelerator Centre for well over twenty years, right since the institue was set up in 1984, and had been actively involved in the setting up of the accelerator research facility during its early years. A few days ago I asked Ajith sir how and when he got the idea to start the Phoenix project. Let me present his reply, along with some other information, in the form of an article.

The Story of Phoenix

Introduction

When you conduct experiments in modern Physics, the equipment involved is often huge and complicated, which is beyond a human being’s ability to control. Also, precise measurement of time and fast and continuous measurement of physical quantities are often required. Consequently, such experiments are automated, and computer interfaced. This means that the scientist carries out the experiment by controlling the equipment using a computer.

Carrying out an experiment consists of different steps. The first step is to activate the equipment, that is, to start the physical phenomenon which is to be studied. For example, in a simple pendulum experiment, this step would be to set the pendulum in motion. Once the physical system is active, we record the observations. This is the second step – data acquisition. And the final step is the analysis of the data obtained. Computers are unique in that they can be used for all these three steps, with the appropriate peripheral equipment.

Why Phoenix?

When a student who has completed her post graduate studies in Physics starts doing research, she inevitably has to carry out computer interfaced experiments. But we do not get such exposure in our education system, even at the post graduate level. As a result, it is likely that the student would find herself in highly unfamiliar territory. Of course, the research facility would provide a friendly interface and adequate help to the student to complete her experiment successfully, but chances are that the student might not have developed a feel for the whole procedure. This affects the quality of research.

So what is the way out? The obvious solution is to introduce computer interfaced experiments right at the undergraduate or even high school level. One of the main obstacles is the cost involved. Though computers have become inexpensive, commercially available data acquisition hardware is too expensive to be affordable for college labs, where teaching/learning and not research, is the main objective. Thus the idea of building a low cost data acquisition hardware, and subsequently “Physics with Home-made Equipment and Innovative Experiments” (Phoenix), evolved. Phoenix is a big step in the right direction. It is easily affordable for colleges and can be interfaced with personal computers through 100% free and open source software.

The Early Days

The first version of Phoenix was completed around September 2004. It communicated with the computer through the parallel port interface, and depended entirely on the computer CPU for control. Time measurements were done using the CPU clock itself, using real time operating system features. The device driver took care of all the control and measurements. It was first implemented using DOS, and later using real time linux.

The first Phoenix workshop was held on 11 November 2004 at the University of Calicut, Kerala. The first workshop hosted by IUAC was conducted from the 3rd to 14th of October 2005. Many such workshops have been held since. Physics teachers from all parts of the country have taken part in these programs. More such workshops will be conducted in the future. You can find a complete list of the Phoenix workshops conducted so far, as well as announcements regarding future workshops at http://iuac.res.in/~elab/phoenix/workshops/index.html.

Thus the parallel port version kicked off the Phoenix activities. As it later became completely based on free and open source software (FOSS), it attracted interest from the FOSS community, most notably from Pramode C E, who continues to be an active developer/promoter of Phoenix. As a result, demonstrations of Phoenix have since been held at some of the prominent FOSS events like FOSS.IN, FOSSMeet@NITC etc.

Need for a Simpler Hardware/Interface

But the parallel port version was never going to be viable in the long run. For one thing, it was bulky. More importantly, for using it on a computer, you had to compile the device driver with the kernel. This would have been too difficult a task for the end user. As a result, it was not very portable, in the sense that you could not just plug Phoenix in and start using it. Some amount of expertise in programing was required for installing the Phoenix driver. It is still a valuable tool for students for learning how to write device drivers, though.

This led to a complete redesign of Phoenix in early 2006. The new design was based on the Atmel ATMega16 microcontroller, which shifted the control tasks from the real time kernel, to the firmware (written in C and compiled using the AVR-GCC cross compiler) running on the microcontroller. This made things a lot simpler. Now once you burnt the firmware onto the microcontroller flash memory, all you needed was a code library to communicate with it from the PC (through the RS232 serial port interface). No more complicated device drivers! Also, this made the hardware schematic simpler and easier to debug. The new version of Phoenix was named the Phoenix-Mini, or Phoenix-M for short. It was also much more compact (13cm x 10.5cm x 2.5 xm) and cheaper (it costs only around Rs.1500) than its predecessor.

Ready for the Market!

Phoenix-M was ready by the end of May 2006, and started being produced commercially by three different vendors in different parts of India. You can find information about these vendors at http://iuac.res.in/~elab/phoenix/vendor.html. Since the cost of research and development is funded by the IUAC and the schematics are made freely available, the vendors are able to provide the hardware at a low price, based on the cost of raw material and the labour involved.

Phoenix Live CD

By this time, workshops were being held in different parts of the country, and the need for a portable suite of the Phoenix software libraries arose. This resulted in the development of the Phoenix Live CD, which is a complete customized GNU/Linux operating system (based on the Slax live CD) which you can boot from the CD without needing to install anything to the hard disk. It contains, apart from all the software needed to use Phoenix, a collection of free and open source scientific/educational software tools. You can download the Phoenix live CD from http://iuac.res.in/~elab/livecd_images/index.html. A new version based on Debian GNU/Linux is also being developed.

Recent Developments

Laptop computers have become popular, and many of them do not provide the RS232 interface. So, a new USB version of Phoenix-M was developed in late 2007. It communicates with the computer, using a USB to RS232 converter implemented by firmware running on a dedicated on-board controller. Apart from this, the Phoenix Microcontroller Development Kit (PMDK) has also been developed to provide a low cost, easy to use microcontroller development system, mainly for engineering students and electronics enthusiasts. Several add-on boards have also been designed for use with PMDK. This modular structure is useful for application in the projects of engineering students.

Future Direction and Challenges

The Phoenix project has matured since its beginning in 2004. We now have a reliable, cost-effective product which is ready for mass deployment. Some academic institutions have already started using Phoenix. For example, the West Bengal University of Technology(WBUT) has included it in their refresher course for Physics teachers. The Department of Education, Kerala, has initiated a project to use Phoenix as a tool for IT enabled education at the high school level.

But there are many challenges that lie ahead, before Phoenix can become a regular part of the curriculum. First of all, computer interfacing of scientific experiments is an entirely new concept, to most of the Physics teachers and students in India. This hurdle can be overcome only through a series of Phoenix workshops. But for its effect to be far-reaching, we need to build a community of enthusiasts from different parts of the country, who can help in conducting workshops. Only with a stong community and user base, can we be assured that Phoenix will realize its potential to revolutionize science education in our country.

Suggested Reading

1. A Report on Phoenix, by B.P. Ajith Kumar.

2. Experimental Physics with Phoenix and Python, by Pramode.C.E

License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.

Download the PDF version of this article.

FFT with Phoenix

Leave a comment

A companion analog box for Phoenix, is being developed here at IAUC, with which you can study AM, FM etc. It’s still in the process of development, but I had observed AM and FM signals generated by it, and studied their frequency spectra using the fft() in SciPy. We felt that it would be convenient to add these functions to the Python library of Phoenix, as given below. You can use these functions by adding this code segment to the file /usr/lib/python2.4/site-packages/phm.py

But since this bit of code has not really been tested, it’s better to avoid mixing these functions with the original phm.py . Instead, you can save this file to your home directory, and import it along with phm. It can be used just like phm, and you can initialize an object by typing “s=phsig.phsig()”.

    def fft(self, data):
        """
        Returns the Fourier transform of the signal represented by the samples
        in 'data' which is obtained by a read_block() call.
        Usage example:
        x = p.read_block(200,10,1)
        y = p.fft(x) 
        """
        from scipy import fft       
        np = len(data)
        delay = data[1][0] - data[0][0]

        v = []
        for i in range(np):
            v.append(data[i][1])

        ft = fft(v)

        #corrections in the frequency axis
        fmax = 1/(delay*1.0e-6)
        incf = fmax/np
        freq = []
        for i in range(np/2):
            freq.append(i*incf - fmax/2)
        for i in range(np/2,np):
            freq.append((i-np/2)*incf)

        ft_freq = []

        for i in range(np/2):
            x = [freq[i], abs(ft[i+np/2])/np]
            ft_freq.append(x)    

        for i in range(np/2,np):
            x = [freq[i], abs(ft[i-np/2])/np]
            ft_freq.append(x)
        return ft_freq                

    def plot_fft(self, data):              
        """
        Plots the Fourier transform of the signal represented by the samples in
        'data'. Calls self.fft() for obtaining the Fourier Transform
        Usage example:
        x = p.read_block(200,10,1)
        p.plot_fft(x)
        """
        ft_freq = self.fft(data)
        np = len(data)
        delay = data[1][0] - data[0][0]
        fmax = 1/(delay*1.0e-6)

        y = 0.0
        for i in range(np):
            if ft_freq[i][1] > y:
                y = ft_freq[i][1]

        if self.root == None:
            self.window(400,300,None)
        self.remove_lines()
        self.set_scale(-fmax/2, 0, fmax/2, y*1.1)
        self.line(ft_freq)

    def freq_comp(self, data):
        """
        Returns and displays the frequency components with the greatest
        spectral density. Calls self.fft() for obtaining the Fourier transform
        Usage example:
        x = p.read_block(200,10,1)
        p.freq_comp(x)    #Only prints the components
        y = p.freq_comp(x) #Prints and stores the components in a variable
                           #as an array of [strength, component]     
        """
        ft_freq = self.fft(data)
        np = len(data)
        delay = data[1][0] - data[0][0]

        peaks = []
        for n in range(1,np-1):
            a = ft_freq[n-1][1]
            b = ft_freq[n][1]
            c = ft_freq[n+1][1]           
            if (b>50) & (b>a) & (b>c):
                peaks.append([ft_freq[n][1],ft_freq[n][0]])

        peaks.sort()
        peaks.reverse()
        print 'Dominant frequency components are:'
        for i in range(len(peaks)):
            print '%6.3f Hz, %5.3f mV'%(peaks[i][1],peaks[i][0])
        return peaks

Relearning Physics

Leave a comment

I remember the clarity and rigour with which I used to explore (theoretical) Physics, when I was in the Eleventh and Twelfth standards, thanks to the inspirational teaching of Gopinathan sir. But after that, I have really been struggling to make sense of what I am learning at college. Working here under Ajith sir, has been a breath of fresh air.

Documenting the experiments properly, has proved to be a challenging job, because you have to verify everything once again before making the report. I don’t know how much I’d be able to complete, but it’s been a good experience.

There is an experiment which you usually do at school, in which you measure the time period so as to calculate the value of acceleration due to gravity from it. But the whole equation is valid for only small amplitudes of oscillation, because the sin(theta)=theta approximation is used. For large amplitudes, this equation is to be used. It must have been mentioned back then, but it sure didn’t stick. There’s no way you can actually verify that in a school lab.

But with Phoenix, you can! We experimented with a combination pendulum, which is nothing but a metal ball fixed on a thin metal rod. It’s similar to the simple pendulum, except that it has a rigid rod, which makes it stable, and that you have to consider the moments of inertia of the rod and the ball. A very thin needle (whose effect can be neglected) was attached to the pendulum, to measure the approximate value of amplitude, as shown in the picture.

We got beautiful results from this setup, and could fit the data onto the large amplitude equation almost perfectly. Measuring the amplitude was the tricky part. Time period can be measured with microsecond accuracy using Phoenix. For each value of amplitude, ten readings were noted. On extrapolating the graph, you can get the time period as the amplitude tends to zero. It was a fascinating result, because you never really carry out experiments from such angles, in our schools/colleges. Hopefully Phoenix can change that!

How to make a Phoenix live CD from a Debian installation

Leave a comment

See this page to learn how to make a Phoenix live CD from a Debian installation.

Phoenix Debian live CD v0.0.9 ready

2 Comments

I had been busy with making the Phoenix Debian live CD, for the past four days. It was a job that totally absorbed you. Just when you think that everything is alright, and you are ready to make version 0.1.0 (to be named “version 1” it requires the kernel driver for the parallel port version of Phoenix), some issue would pop up. When most of the problems which required immediate attention were solved, Ajith sir said we would start again on a fresh Debian installation, so that we could verify and note down all the steps involved. The second time, we made a script to run all the steps, mainly installing the packages required. There again, we found some steps we had forgotted to document, and corrected some of them, and for the time being, made a Phoenix Debian version 0.0.9. It was installed to one of the machines and I’m doing the experiments to be documented, from it.

Since I was so busy with the live CD work, the experiment documentation work had come to a complete standstill. Yesterday, Ajith sir and I stayed till 9 at night, to try and complete the live CD work, because if we didn’t finish it off, we’d be working on it forever. I resumed the experiments today afternoon. Will write more about that when we finish documenting it.

The highlight of today’s events was that Ajith sir introduced me to Prof. G.K.Mehta, who is a retired former director of IUAC, and continues to work here. He came to see the gravity experiment being done, and gave his invaluable suggestions. He even offered to go through the documentation when it is ready!

Older Entries