Pineapples, pineapples!

On my way back from NY last Sunday, I played with my Python SCExAO simulator to get a feeling for how a phase map on the deformable mirror (DM) gets remapped by the PIAA. The grayscale picture shows the focal plane image resulting from a double cross sinusoid on top of a flat DM. Without the PIAA, you expect to see your usual PSF surrounded by a regular grid of speckles whose separation depends on the number of sine waves you can generate across the DM and whose brightness depend on the amplitude of the sine wave. If the guys from SEEDS read this post, this may remind them of what the grid mask they want to put in HiCIAO will do...

With the PIAA, things of course get really different and your regular grid gets turned into a nice display... of pineapples! I just showed this morning the corresponding picture to a friend who was staying at our house. The laptop was on the kitchen table, and half joking, he pointed out that the picture looks just like the Hawaiian quilt pattern that's printed on the the kitchen tablecloth asking me whether I had done it on purpose... what do you think?

Modeling of SCExAO

Building the actual thing is not enough: a numerical model of any experiment is also essential to understanding what's going on inside... SCExAO doesn't escape this general rule and we are working on this model these days!

Doing this is always very interesting and really makes you think about the minute details of all of the optics that currently lie on the bench. And SCExAO involves some pretty tricky components: pupil remapping devices like the SRP, the PIAA and the inverse PIAA are really peculiar optics, and the deformable mirror is a surprisingly complex little thing... but we're getting there!

Just like with the experiment control GUI, we've decided to program this model in Python. It's just been a couple months since we started playing with this, but the deeper we dig, the more we find! Numpy, Scipy, Matplotlib and Pyfits form together a great scientific programming environment that, once you get used to it, does just as well as IDL, which I have been using for the last couple of years.

The picture shows the kind of things this simulation produces: point spread functions (PSF) for different off-axis sources (1,5,10 and 20 lambda/D). Although not finely tuned yet, the model nicely reproduces the pineapple-shaped PSFs that SCExAO generates for off-axis sources with the PIAA only, as published by Lozi et al. (2009).

Software for two Xenics cameras!

Yep, you've read right: we now have two of the Xenics IR cameras. The first we purchased will be dedicated to the low-order wavefront sensor, the second will have the privilege of being our "science" detector for the commissioning of SCExAO, before we try and add HiCIAO, and might even be able to do some science itself!

Today, we finally managed to control both cameras from the same computer... hurray! This server/client architecture we've developed is actually proving very handy: one server per camera, each one awaiting for connections (via the local network or directly from the SCExAO control computer) listening to their special port number.

The client can now ask either of the cameras (or both) to take images, query for or update the camera configuration (exposure time, subarray mode, gain), or tell it to shutdown. Now that these detectors are both working, we can turn off the visible laser diode: this new year will be bright in the infrared for SCExAO!

Software for the Xenics IR camera

A couple of weeks ago, I blogged about the Xenics camera, which we finally were able to take images with. Since then, I have kept playing with the SDK to build an application that is better suited to our needs for SCExAO.

While it may not be the best file format in the world, all the astronomical instruments I have encountered so far produce FITS files as their final data product. The first thing to do was therefore to change the program the camera came with to make saving the data in the FITS format possible, which is fairly easy thanks to the cfitsio library.

Incidentally, that also improves the image quality. Indeed, the original program would produce what looked like 24-bit color bitmaps... but were in fact 8-bit greyscale only. That is very unfortunate since the camera uses 14-bit ADC... 6 bits of dynamic were simply lost in an elegant bitwise data shift. The image (also bias-substracted) looks somewhat better now that we make use of the entire dynamic range!

That also helped to neaten the code that originally had to be compiled with the wxWidget library, just because of the need to save bitmaps and read configuration files. While there is nothing wrong with wxWidget which is an attempt at providing a cross-platform widget library, it is just a little overkill to link it just to save bitmaps.

So what's next? We're still trying to figure out what is the best way to interface the camera with our already complex programming environment. At this point, I think it would be best to make it as standalone as possible, and one approach is to create a server program that would keep the camera up and running, and have other client programs connect to it via sockets to tell it to take pictures when needed. I just want to make sure that this socket communication system will not slow down the data acquisition... for one should not forget that one important use of this camera will be in the low-order wavefront sensor, which will be running at over 100 Hz for extended periods of time.

Python-based GUI version 2!!

I have to say I am pretty proud of this new version of the GUI! Still written in Python, with the Tkinter module, it makes extensive use of graphic elements (the Canvas class), and shows a schematic, but somewhat accurate, outline of the instrument... much more intuitive than the array of buttons of version 1 (see previous post). The GUI design is actually inspired from the one that controls the PHARO camera at the 200" Hale Telescope of Palomar Observatory, which I have used multiple times.

This time, driving optics in and out of the beam also moves boxes in the interface, which gives a good idea of where we're at, without having to think too much about the "guts" of the experiment. If one chooses one of the internal sources (visible or IR laser diode) instead of the tip tilt mirror, the left side focusing beam disappears and the color of the beam changes according to the wavelength.

The possibility of adjusting each of the IN/OUT position is left out of the main window (in an ideal world, the need for adjustment should really be minimal). To adjust, each element, one needs to access the TWEAK menu. On the picture, two were pulled out: depending on the degrees of freedom the mechanics offers (which can be up to five!), the TWEAK menu offers a variable number of controls.

Python-based GUI for motors and actuators

I am fairly new to Python, but heard so many people in astronomy telling how great it is that I had to try it out. This is my first shot at a Python-based GUI, using the TkInter package that appears to be delivered with most Python distributions.

The IR coronagraph on SCExAO consists of several devices whose purpose is described on the project webpage: SRP, PIAA, binary mask, focal plane mask, inverse PIAA and of course, a camera. Each device is mounted on a motorized translation stage that can move the device in and out of the beam, depending on what's on the SCExAO user's mind. We use electronic drivers for stepper motors made and sold by AllMotion, connected to a DIGI serial port server.

It is amazing that in less than 300 lines of well "aerated" code, I managed to cram the definition of an interface, its callbacks, the reading of a configuration file as well as the socket connection to talk to the motors through the local network. The source code is posted here...

This is however just a prelude: SCExAO not only uses stepper motors but also linear actuators which also need to be integrated to this GUI. Design for this Python interface v 2.0 is ongoing.