| ID |
Date |
Author |
Type |
Category |
Subject |
|
17507
|
Tue Mar 14 11:34:05 2023 |
Alex | HowTo | Computer Scripts / Programs | Summary Pages Restart |
If the summary pages go down, it could be from a break in the script or some small error. The first remedy for fixing this can be to remove the cron jobs in the que and restart the "gw_daily_summary.sub" and "gw_daily_summary_rerun.sub" scripts.
For more information on how to do this, follow instructions found in the wiki.
|
|
16802
|
Fri Apr 22 07:01:58 2022 |
Jc | Update | Coil Drivers | Adding Resistors and Reinstalling |
[Koji, JC]
Coil Drivers LO2, SR2, AS4, and AS1 have been updated a reinstalled into the system.
LO2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100008
LO2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100530
SR2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100614
SR2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100615
AS1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100610
AS1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100611
AS4 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 Unit: S2100612
AS4 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 Unit: S2100613 |
| Attachment 1: IMG_0536.jpeg
|
|
| Attachment 2: IMG_0539.jpeg
|
|
| Attachment 3: IMG_0542.jpeg
|
|
| Attachment 4: IMG_0545.jpeg
|
|
| Attachment 5: IMG_0548.jpeg
|
|
| Attachment 6: IMG_0551.jpeg
|
|
| Attachment 7: IMG_0554.jpeg
|
|
| Attachment 8: IMG_0557.jpeg
|
|
|
16804
|
Fri Apr 22 12:09:51 2022 |
Anchal | Update | Coil Drivers | Please update DCC pages |
Nice. Please put this information on the DCC pages of the coil driver units. You'll find links to all the units in this document tree LIGO-E2100447. For each page, click on "Change Metadata" from the left panel and add the change made to the resistor (including the resistor name on PCB, previous and new value), and add a link to your previous elog post which has more details like photos, to "Notes and Changes", and upload an updated version of the circuit schematic by creating an annotation in the previous circuit schematic pdf. Every unit that has a serial number in the lab has a DCC page (if not, we should create one) where we should track all such hard changes.
|
|
16814
|
Wed Apr 27 10:05:55 2022 |
JC | Update | Coil Drivers | Coil Drivers Update |
18 (9 pairs) Coil Drivers have been modified. Namely ETMX/ITMX/ITMY/BS/PRM/SRM/MC1/MC2/MC3.
ETMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100624 ETMX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100631
ITMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100620 IMTX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100633
ITMY Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100623 ITMY Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100632
BS Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100625 BS Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100649
PRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100627 PRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100650
SRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100626 SRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100648
MC1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100628 MC1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100651
MC2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100629 MC2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100652
MC3 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100630 MC3 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100653
Will be updating this linking each coil driver to the DCC |
|
16823
|
Mon May 2 13:30:52 2022 |
JC | Update | Coil Drivers | Coil Drivers Update |
The DCC has been updated, along with the modified schematic. Links have been attached.
| Quote: |
|
18 (9 pairs) Coil Drivers have been modified. Namely ETMX/ITMX/ITMY/BS/PRM/SRM/MC1/MC2/MC3.
ETMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100624 ETMX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100631
ITMX Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100620 IMTX Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100633
ITMY Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100623 ITMY Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100632
BS Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100625 BS Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100649
PRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100627 PRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100650
SRM Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100626 SRM Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100648
MC1 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100628 MC1 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100651
MC2 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100629 MC2 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100652
MC3 Coil Driver 1 (UL/LL/UR)now has R=100 // 1.2k ~ 92Ohm for CH1/2/3 S2100630 MC3 Coil Driver 2 (LR/SD)now has R=100 // 1.2k ~ 92Ohm for CH3 S2100653
Will be updating this linking each coil driver to the DCC
|
|
|
227
|
Tue Jan 8 15:20:17 2008 |
Pkp | Update | Cameras | GigE update |
[Tobin , Pinkesh]
Finally we got the camera doing something (other than giving out its attributes). The only thing that seems to work so far is a program called AAviewer, which converts the image into an ASCII format and displays it on the screen. If you want to play around with it, log into mafalda (131.215.113.23) via rana.ligo.caltech.edu. Access /cvs/cds/caltech/target/Prosilica/bin-pc/x86/ and there should be a few programs in there, one of which is AAviewer, which requires you to get an IP address (which is 131.215.113.103) for the camera right now. (You can also get the IP information via the ListCameras program). The camera is physically in the 40m near the network rack.
Other programs dont seem to be working and its probably due to the network/packetsize issues. Since linux2 can change its packetsize to a higher number, I will get it to compile on linux2 for now and then give it a shot. |
|
234
|
Thu Jan 10 13:45:52 2008 |
Pkp | Update | Cameras | GLIBC Error |
So, I have tried to compile the camera files which are in /cvs/cds/caltech/target/Prosilica/examples for the past 2 days now and have been unable to get rid of the following error. (specifically ListCameras.cpp, as it doesnt have any other libraries required, which unnecessarily complicates things)
../../bin-pc/x86/libPvAPI.so: undefined reference to `__stack_chk_fail@GLIBC_2.4'
collect2: ld returned 1 exit status
make: *** [sample] Error 1
I used to get this error on mafalda too, but I had fixed it by installing the latest version of the glibc libraries. Inspite of doing so on linux2, the error still persists. I suspect it had something to do with it being a FC3 machine. My own laptop, which also runs Ubuntu works fine too. The problem with these Ubuntu machines is that they dont let me set the packet sizes to 9 kb which is required by the camera. Linux2 does.
If anyone has any idea how to resolve this issue, please let me know.
Thanks
Pinkesh. |
|
236
|
Fri Jan 11 17:01:51 2008 |
pkp | Update | Cameras | GigE again |
So, here I detail all the efforts on the GigE so far
(1) The GiGE camera requires a minimum of 9 kb packet size, which is not available on mafalda or on my laptop ( both of which run Ubuntu and the Camera programs compile there). The programs which require smaller sizes work perfectly fine on these machines. I tried to statically compile the files on these machines so that I could then port them to the other machines. But that fails because the static libraries given by the company dont work.
(2) On Linux2, which lets me set a packet size as high as 9 Kb, it doesnt compile because of a GLIBC error. I tried updating the glibc and it tells me that the version already existing is the latest ( which it clearly is not). So I tried to uninstall GLIBC and reinstall it, but it wont let me uninstall (it == rpm) glibc, since there are a lot of dependencies. A dead end in essence.
Steps being taken
(1) Locally installing the whole library suites on linux2. Essentially install another version of gcc and g++ and see if that helps.
(2) IF this doesnt work, then the only course of action I can take is to cannibalize linux2's GigE card and put it on mafalda. ( I need permission for this  ).
Once again any suggestions welcome. |
|
245
|
Thu Jan 17 15:11:13 2008 |
josephb | Update | Cameras | Working on Malfalda |
1) I can statically compile the ListCamera code (which basically just goes out and finds what cameras are connected to the network) on Malfalda and use that compiled code to run on Linux2 without a problem. Simply needed to add explicit links to libpthread.a and librt.a.
(i.e. -Bstatic -L /usr/lib/ -lpthread -Bstatic -L /usr/lib -lrt)
With appropriate static libraries, it should be possible to port this code to other linux machines even if we can't get it to compile on the target machine itself.
2)I've modified the Snap.cpp file so that it uses a packet size of 1000 or less. This simply involves setting the "PacketSize" attribute with the built in functions they provide in their library. After un-commenting some lines in that code, I was able to save tiff type images from the camera of up to 400x240 pixels on Malfalda. The claimed maximum resolution for the camera is 752x480, but it doesn't seem to work with the current setup. The max number of pixels seems to about 100 times the packet size. I.e. packet size of 1000 will allow up to 400x240 (96000) but not 500x240 (120,000). Not sure if this is an issue just with snap code or the general libraries used.
3)Will be working towards getting video running over the next day or so. |
|
266
|
Fri Jan 25 11:38:16 2008 |
josephb | Configuration | Cameras | Working GiGE video on Linux - sort of |
1)I have been able to compile the SampleViewer program which can stream the video from the Prosilica 750C camera. This was accomplished on my 64-bit laptop running Ubuntu, after about 3 hours of explicitly converting strings to wxStrings and back again within the C++ code. (There was probably an easier way to simply overload the functions that were being called, but I wasn't sure how to go about doing so). By connecting it to the CDS network, I was able to immediately detect the camera and display the images.
Unfortunately, I have not yet been able to get it to compile on Mafalda with the x86 architecture. This may be do the fact that it has wxWidgets version 2.8.7 while my laptop has 2.8.4. Certainly the failure at compile time looks different from the errors earlier, and seem to be within the wxWidget code rather than the SampleViewer code. I may simply need to uninstall 2.8.7 and install 2.8.4 of wxWidgets.
The modified code that will compile on my machine has been copied to /cvs/cds/caltech/target/Prosilica/examples/SampleViewer2b.
2)The Snap program (under /cvs/cds/caltech/target/Prosilica/examples/Snap) also will now take full resolution images even on Mafalda. This was achieved by reducing the packet size to 1000 and also increasing the wait until timeout time up to 400 ms, which originally was at 100. Apparently, it takes on the order of 1 ms per packet as far as I can tell. So full resolution at 752x480 required something of order 360 packets.
To Do:
1) Get sample viewer to compile on Mafalda, and then statically compile it so it can be run from any Linux based machine.
2) Get a user friendly version of Snap up and running, statically compiled, with options for a continuous loop every X seconds and also to set desired parameters (such as height, width, file name to save to, save format, etc).
3) Figure out data analysis with the images in Matlab and an after the fact image viewer.
Attached is an example .tiff image from the Snap program. |
| Attachment 1: snap.tiff
|
|
267
|
Fri Jan 25 13:36:13 2008 |
josephb | Configuration | Cameras | Working GiGE video on Mafalda |
Finally got the GiGE camera sample viewer video running on Mafalda by updating to the latest API (version 1.16 from Dec 16, 2007) from Prosilica and then using the modified Sample Viewer code I had written. The API version previously in cvs was 1.14.
It can currently be run by ssh -X into Mafalda and going to /cvs/cds/caltech/target/Prosilica/bin-pc/x86 and running the SampleViewer executable found there. |
|
289
|
Thu Jan 31 16:53:41 2008 |
josephb | Configuration | Cameras | Improving camera user interface |
There's a new and improved version of Snap program at the moment people are free to play with.
Located in /cvs/cds/caltech/target/Prosilica/40mCode/
The program Snap now has a -h or --help option which describes some basic command line arguments. The height (in pixels), width (in pixels), exposure time (in micro seconds), file name to be saved to (in .tiff format), and packet size can all be set. The format type (i.e. pixel format such as Mono8 or Mono16) doesn't work at the moment.
At the moment, it only runs on mafalda.
Currently in the process of adding a loop option which will take images every X seconds, saving them to a given file name and then appending the time of capture to the file name.
After that need to add the ability to identify and choose the camera you want (as opposed to the first one it finds).
Lastly, I've been finding on occassion that the frame fails to save. However if you try again a few seconds later with the exact same parameters, it generally does save the second time. Not sure whats causing this, whether on the camera or network side of things.
I've attached two images, the first at default exposure time (15,000 microseconds) and the second at 1/5th that time (3,000 microseconds).
The command line used was "./Snap -E 3000 -F 'Camera_exp_3000.tiff' " |
| Attachment 1: Camera_exp_15000.tiff
|
| Attachment 2: Camera_exp_3000.tiff
|
|
292
|
Fri Feb 1 15:04:54 2008 |
josephb | Configuration | Cameras | Snap with looping functionality available |
New GiGE camera code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. Currently only runs on Mafalda.
Snap has expanded functionality to continuously loop infinitely or for a maximum number of images set by the user. File names generated with the loop option have the current Unix time and .tiff appended to them. So -f './test' will produce tiff files with format "test1234567.tiff". The -l option sets the number of seconds between images.
"./Snap -l 5 -i -f './test' " will cause the program to infinitely loop, saving images every 5 seconds. Using "-m 10" instead of "-i" will take a series of 10 images every 5 seconds (so taking a total of 50 seconds to run).
It also now defaults to 16-bit (in reality only 10 bit) output instead of 8 bit output. You can select between the two with -F 'Mono8' or -F 'Mono16'.
Use --help for a full list of options.
Note that if you ctrl-c out of the loop, you may need to run ./ResetCamera 131.215.113.104 (or whatever the IP is - use ./ListCameras to determine IP if necessary) in order to reset the camera because it doesn't close out elegantly at the moment. |
|
297
|
Tue Feb 5 15:32:29 2008 |
josephb | Configuration | Cameras | PMC and the GigE Camera |
The PMC transmission video camera has been removed and replaced with the GigE GC750 camera for the moment.
A ND4.0 filter has been added in the path to that camera to reduce saturation for the moment.
The old camera has been placed on the elevated section inside the enclosure, and the cable for it is still on the table proper.
The Gige camera is currently running the Snap code on Linux3 with the following command line:
./Snap -E 2000 -l 60 -m 1440 -f './pmc_trans/pmc_trans'
So its going to be taking tiff images every minute for the next 24 hours into the cvs/cds/caltech/target/Prosilica/40mCode/pmc_trans/ directory.
Attached is an example image with exposure set to 2000, loaded into matlab and plotted with the surf command. 2500 microseconds looked like it was still saturating, but this seems to be a good level (with a max of 58560 out of 65535). |
| Attachment 1: pmc_trans.jpg
|
|
|
300
|
Wed Feb 6 16:50:47 2008 |
josephb | Configuration | Cameras | Regions of Interest and max frame rate |
The Snap code has once again been modified such that setting the -l option to 0 will take images as fast as possible. Also, the -H and -W options set the height and width, while in principle the -Y and -X options set the position in pixels of the top edge and left edge of the image. It also seems possible to set these values such that the saved image wraps around. I'll be adding some command checking so that the user can't do this in the near future.
Doing some timed runs, using a -H 350 and -W 350 (as opposed to the full 752x480), 100 images can be saved in roughly 8 seconds, and 1000 images took about 73 seconds. This corresponds to a frame rate of about 12-13 frames per second (or a 12-13 Hz display). The size of this area was sufficient to cover the current PMC transmission beam.
The command line I used was
time ./Snap -l 0 -m 1000 -f 'test' -W 350 -H 350 -Y 50 -X 350 -E 2000
Interestingly enough, there would be bursts of failed frame saves if I executed commands in another terminal (such as using ls on the directory where the files were being stored).
As always, this code is available in /cvs/cds/caltech/target/Prosilica/40mCode/. |
|
301
|
Wed Feb 6 19:39:11 2008 |
rana | Configuration | Cameras | Regions of Interest and max frame rate |
| We really need to look into making the 40m CDS network have an all GigE backbone so that we can have cooler cameras as well as collect multiple datastreams... |
|
378
|
Fri Mar 14 12:06:29 2008 |
josephb | Configuration | Cameras | GC750 looking at ETMX while locked |
The GC750 (CMOS) is currently looking at the front of ETMX. Unfortunately, its being routed through a 10Mbit connection (which I will be purchasing a replacement for today), so getting it to send images to Mafalda/Linux 2 or 3 isn't working well, but by using a local gigabit switch and a laptop I can get sufficient speed for full images with the sample viewer.
The attached image is from a full 752x480 reslution with 10,000 microsecond exposure with the X-arm locked. Although it looks like I still need to work on the focusing. Will be switching the GC750 with the GC 650 (CCD) later today and comparing the resulting images. |
| Attachment 1: ETMX_zoom_exp_10000_750.tiff
|
|
379
|
Fri Mar 14 14:59:51 2008 |
josephb | Configuration | Cameras | Comparison between GC650 (CCD) and GC750 (CMOS) looking at ETMX |
Attached are images taken of ETMX while locked.
The first two are 300,000 microsecond exposure time, with approximately the same focusing/zoom. (The 750 is slightly more zoomed in than the 650 in these images). The second are 30,000 microsecond exposures. The la
The CMOS appears to be more sensitive to the 1064 nm reflected light (resulting in bright images for the same exposure time). This may make a difference in applications where images are desired to be taken quickly and repeatedly.
Both seem to be resolving individual specks on the optic reasonably well.
Next test is to place both camera on a Gaussian beam (in a couple different modes say 00, 11, and so forth), probably using the PMC. |
| Attachment 1: ETMX_z2_exp_300000_650.tiff
|
| Attachment 2: ETMX_z2_exp_300000_750.tiff
|
| Attachment 3: ETMX_z2_exp_30000_650.tiff
|
| Attachment 4: ETMX_z2_exp_30000_750.tiff
|
|
434
|
Tue Apr 22 08:34:22 2008 |
josephb | Configuration | Cameras | Current Network Diagram |
| The attached network diagram has also been added to the 40m Wiki at http://lhocds.ligo-wa.caltech.edu:8000/40m/Image_Processing_with_GigE_Cameras |
| Attachment 1: Network.pdf
|
|
|
471
|
Thu May 8 16:40:36 2008 |
josephb | Configuration | Cameras | Gige Camera currently on PSL table |
Andrey and myself were working on the PSL table today, using a pickoff of a pickoff of the main beam (adding a microscope slide to pickoff ~4% of the original pickoff) to the GC750 GigeCam.
At the time we left, we scanned the area with a beam scan and didn't see any new stray beams, and nothing in any useful beam paths should have changed. We also strung a Cat 6 cable from the control room switch out to the PSL table in the cable trays, and then above the PSL table.
Currently, its not as well aligned as it could be, and also requires a very low exposure setting, of -E 50 or so to avoid saturation. |
|
481
|
Thu May 15 16:24:18 2008 |
josephb | Summary | Cameras | |
The GC750 camera is currently looking at a very small pickoff of the PSL output (transmission of a Y1-1037-45-S mirror). The plan is to take images tomorrow with it and the GC650 from the same spot and do comparisons.
For those interested, the camera can be run with two codes, from mafalda. Use ssh -X mafalda to login, to allow the live stream to work with the SampleViewer code. The codes can be found in:
/cvs/cds/caltech/target/Prosilica/40mCode/Snap
and
/cvs/cds/caltech/target/Prosilica/bin-pc/x86/SampleViewer
Type Snap --help for a list of options for that program. Click the circle looking thing in SampleViewer to start the live stream. Note only 1 of the two programs can be running at a time, and the only way to change settings (such as exposure length) is with Snap at the moment. |
|
482
|
Fri May 16 14:38:50 2008 |
josephb | Summary | Cameras | Two cameras setup |
I've changed the pickoff setup from yesterday for the GigE cameras to include a 33% beam splitter (first one I could find). The reflection is going to the GC650 (CCD camera) while the transimission is going to the GC750 CMOS camera. This means the CMOS camera has roughly twice the light incident as the GC650 and should be kept in mind in all comparisons. The distances from the beam splitter are approximately the same both cameras, but some more accurate positioning might be useful.
Its very easy to get the GC650 camera into a bad state where you need to go out and cycle the power (simply unplug and re-plug in the power supply either at the camera or outlet). If the ListCamera program doesn't see it, this is probably necessary.
Andrey added at 6.30PM: Actually the 650 camera keeps crashing constantly. Every time I attempt to capture an image, the camera fails. |
|
506
|
Fri May 30 12:03:08 2008 |
josephb, Andrey | Configuration | Cameras | Head to head comparison of cameras |
Andrey and myself - Joseph B. - have examined the output of the GC650 (CCD) and GC750 (CMOS) prosilica cameras. We did several live motion tests (i.e. rotate the turning mirror, move and rotate the camera, etc) and also used a microscope slide to try to eliminate back reflections and interference.
Both the GC650 and GC750 produce dark lines in the images, some of which look parallel, while others are in much stranger shapes, such as circles and arcs.
Moving the GC750 camera physically, we have the spot moving around, with the dark lines appearing to be fixed to the camera itself, and remain in the same location on the detector. I.e. coming back to the same spot keeps showing a circle. In reasonably well behaved sections, these lines are about 10% dips in power, and could in principle be subtracted out. Its possible that the camera was damaged with too much light incident in the past, although going back to the pmc_trans images that were taken, similar lines are still visible.
Moving the GC650 camera physically seems to change the position of the lines (if one also rotates the turning mirror to get to the same spot on the CCD). It seems as if a slight change in angle has a large effect on these dark bands, which can either be thin, or very large, bordering on the size of the spot size. My guess is (as the vendor suggested) the light is interacting with the electronics behind the surface layer rather than a surface defect producing these lines. Using a microscope slide in between the turning mirror and the GC650, we were able to produce new fringes, but didn't affect the underlying ones.
Placing a microscope slide in between the last turning mirror and the GC750 does not affect the dark lines (although it does seem to add some), nor does turning the final turning mirror, so it seems unlikely to be caused by back reflection in this case.
So it seems the CMOS may be more consistent, although we need to determine if the current line problems are due to exposure to too much light at some point in the past (i.e. I broke it) or they come that way from the factory.
Attached are the results of image-processing of the images from the two our cameras using Andrey's new Matlab script. |
| Attachment 1: Waveform_Reconstruction_May30-2008.pdf
|
|
|
511
|
Mon Jun 2 12:20:35 2008 |
josephb | Bureaucracy | Cameras | Beam scan has moved |
| The beamscan has been moved from the Rana lab back over to the 40m, to be used to calibrate the Prosilica cameras. |
|
512
|
Tue Jun 3 02:15:29 2008 |
Andrey | Summary | Cameras | Fitting results |
There have been a lot of work going on related to the processing of images captured by the cameras GC-650 and GC-750 recently.
In the end of the week of May 30 Joseph and me (Andrey) installed the two cameras capturing the images of the pick-off of the main beam on the PSL optical table. The cameras are located after the picked-off beam going towards the "PSL position QPD", after the 33-66 beamsplitter (33% of reflection and 66% of transmission).
Initially (on May 30) the GC-650 camera was taking the images of reflected beam, while the camera GC-750 was taking images of transmitted beam. On Monday June 2 we switched the positions of the cameras, so GC-650 appeared to be on the path of the transmitted beam and GC-750 on the path of the reflected beam.
I (Andrey Rodionov) was able in the weekend to succeed in writing a Matlab program that performs the two-dimensional Gaussian fitting of the captured images, and I used that program to fit the images from the cameras.
The program fits the camera data by a two-dimensional Gaussian surface:
Z = A * exp[ - 2 * (X - X_Shift)^2 / (Waist_X)^2 ] * exp[ - 2 * (Y - Y_Shift)^2 / (Waist_Y)^2 ] + CONST_Shift,
where A, X_Shift, Waist_X, Y_Shift, Waist_Y, CONST_Shift are 6 parameters of the fit.
Attached are the pdf-files showing the results: images taken with our cameras, the 2-dimensional Gaussian fit for these images and the surfaces of residuals. Residuals are differences between the exact beam profile and the result of fitting. In normalized version of residual graph I normalize it by the first coefficient of fitting A, the factor in front of the exponents. |
| Attachment 1: May30-GC650.pdf
|
|
| Attachment 2: May30-GC750.pdf
|
|
| Attachment 3: June02-GC650.pdf
|
|
| Attachment 4: June02-GC750.pdf
|
|
|
515
|
Tue Jun 3 12:33:36 2008 |
Andrey | Update | Cameras | Andrey, Josephb |
Continuing our work with cameras,
1) we removed both cameras from their places on Monday afternoon, and were taking the beam-scans with a special equipment (see elog-entry 511) from Bridge bld.,
2) and on Tuesday morning we putted back the GC-750 camera into the transmitted beam path, camera GC-650 into the reflected beam path. We plan to compare the images from the "reflection camera" for several different angles of tilt of the camera. |
|
517
|
Wed Jun 4 13:46:42 2008 |
josephb | Configuration | Cameras | Changing incident angle images |
Attached are images from the GC650 and GC750 when the incident angle was varied from 0 tilt (normal incidence) to 5,10, and 20 degrees. Each time the beam was realigned via the last turning mirror to be on roughly the same spot. This light was a pickoff of the PSL table light just before it leaves the table.
Images include the raw data, fit to the data, residual normalized by peak power "w(1)", and normalized by the individual bin power.
The first pdf includes 0 degrees (normal) and ~5 degrees of tilt for the GC650 (CCD) camera.
The second pdf includes ~10 and ~20 degrees of tilt images for the GC650 (CCD) camera.
The third pdf includes 0 and ~5 degrees of tilt for the GC750 (CMOS) camera.
The fourth pdf includes ~10 and ~20 degrees of tilt for the GC750 (CMOS) camera.
Things to note:
1) GC750 camera seems to have a structure on the camera itself, somewhat circular in nature. One possible explanation is the camera was damage at a previous juncture due to too much light. Need to check earlier images for this problem.
2) GC650 has "bands" which change direction and thickness with angle. Also at higher incidence angle, the sensitivity seems to drop (unlike the GC750 where overall power level seems to stay constant with increasing angle of incidence).
3) GC650 seems to have a higher noise floor,seen from the last plot of each pdf (where each pixel of the residual is normalized by the power in the corresponding pixel of the fit). |
| Attachment 1: GC650_0dg_5dg.pdf
|
|
| Attachment 2: GC650_10dg_20dg.pdf
|
|
| Attachment 3: GC750_0dg_5dg.pdf
|
|
| Attachment 4: GC750_10dg_20dg.pdf
|
|
|
519
|
Wed Jun 4 16:57:12 2008 |
josephb | Configuration | Cameras | Dark images from cameras (electronics noise measurement) |
The attached pdfs are 1 second and 1 millisecond long integrations from the GC650 and GC750 cameras with a cap in place - i.e. no light.
They include the mean and standard deviation values.
The single bright pixel in the 1 second long exposure image for the GC650 seems to be a real effect. Multiple images taken show the same bright pixel (although with slightly varying amplitudes).
The last pdf is a zoom in on the z-axis of the first pdf (i.e. GC650 /w 1 sec exposure time).
I'm not really sure what to make of the mean remaining virtually fixed for the different integration times for both cameras. I guess 0 is simply offset, but doesn't result in any runaway integrations in general. Although there are certainly some stronger pixels in the long exposures when compared to the short exposures.
Its interesting to note the standard deviation actually drops from the long exposure to the short exposure, possibly influenced by certain pixels which seem to grow with time.
The one with the least variation from its "zero" was the 1 millisecond GC750 dark image. |
| Attachment 1: GC650_1sec_dark.pdf
|
|
| Attachment 2: GC650_1msec_dark.pdf
|
|
| Attachment 3: GC750_1sec_dark.pdf
|
|
| Attachment 4: GC750_1msec_dark.pdf
|
|
| Attachment 5: GC650_1sec_dark_zoom.pdf
|
|
|
520
|
Thu Jun 5 10:46:26 2008 |
josephb | Configuration | Cameras | Approximately uniform reflected white light |
In an attempt to investigate the structures seen in previous images for the GC750, I aimed it at a relatively clean section of gray table top roughly a cm or two from the surface and took images (without a lens). As I was holding this with my hand, the angle wasn't completely even with the table, and thus there's a gradient of light in the pictures. However, one should in principle be able to pick out features (such as a circular spot with less sensitivity), but these do not show up.
In my mind, these images seem to indicate the electronics are fine, and suggest that the CMOS or CCD detectors themselves are undamaged (at least in regards to white light, as opposed to 1064nm). An issue with the plastic cap (protective piece) may be the culprit, or perhaps a tiny bit of dust, which the incoherent light from all angles goes around efficiently?
Will try blowing the cameras with clean nitrogen today and see if that removes or changes the circular structure we have seen. |
| Attachment 1: GC650_white_light.pdf
|
|
| Attachment 2: GC750_white_light.pdf
|
|
|
521
|
Thu Jun 5 13:35:23 2008 |
josephb | Configuration | Cameras | GC750 looking at 1064nm scattered light |
I've taken 200 images of the GC750 (CMOS) camera while holding it by hand up to a beam card (also held by hand) in the path of ~5mW of beam power. I then averaged the images to produce the fourth attached plot.
Rob has pointed out the image looks a lot like PCB traces. So perhaps we're seeing the electronics behind the CMOS sensor?
I repeated the same experiment with HeNe laser light (again scattered off a card). These show none of the detailed structure (just what looks to be a large reflection from the card moving around depending on how steady my hand was). These are the first 3 attached plots. So only 1064nm light so far sees these features.
As a possible solution, I did a quick and dirty calibration by dividing a previous PSL output beam by the 1064 average scatter light values. These produce the last attached pdf (with multiple images). The original uncalibrated image is on top, while the very simply calibrated image is on the bottom of each plot.
It seems as the effect may be power dependent (which could still be calibrated properly, but would take a bit more effort than simply dividing), as determined by looking at the edges of the calibrated plot. |
| Attachment 1: GC750_HeNe_scatter_avg.pdf
|
|
| Attachment 2: GC750_HeNe_scatter_avg2.pdf
|
|
| Attachment 3: GC750_HeNe_scatter_avg3.pdf
|
|
| Attachment 4: GC750_scatter_avg.pdf
|
|
| Attachment 5: GC750_nitrogen_white.pdf
|
|
|
525
|
Fri Jun 6 16:47:04 2008 |
josephb | Configuration | Cameras | GC650 scatter images of 1064nm light |
Took images similar to the scattered light images from earlier, except with the CCD GC650 camera. The first three attached plots are an average of all 200 images, an average of the first 100 and then an average of the last 100 images.
They show no definite structure. The big red blob which changes with time may be a brighter reflection, although it virtually the same type of setup as the GC750 images.
To do this properly, I should grab a short focal length lens and simply blow up the beam to a size greater than the detector area and simply fix both cameras looking into.
The last set of plots are mean and standard deviation plots from a previous set of runs on 5/29/08 with the GC750 and GC650 running at the same time. The GC650 was receiving approximately 33% of the total power and GC750 was receiving 66% (in otherwords a factor of 2 more). |
| Attachment 1: GC650_scatter_200.pdf
|
|
| Attachment 2: GC650_scatter_100a.pdf
|
|
| Attachment 3: GC650_scatter_100b.pdf
|
|
|
530
|
Wed Jun 11 15:30:55 2008 |
josephb | Configuration | Cameras | GC1280 |
The trial use GC1280 has arrived. This is a higher resolution CMOS camera (similar to the GC750). Other than higher resolution, it has a piece of glass covering and protecting the sensor as opposed to a plastic piece as used in the GC750. This may explain the reduced sensitivity to 1064nm light that the camera seems to exhibit. For example, the image averages presented here required a 60,000 microsecond exposure time, compared to 1000-3000 microseconds for similar images from the GC750. This is an inexact comparison, and the actual sensitivity difference will be determined once we have identical beams on both cameras.
The attached pdfs (same image, different angles of view) are from 200 averaged images looking at 1064nm laser light scattering from a piece of paper. The important thing to note is there doesn't seem to be any definite structure, as was seen in the GC750 scatter images.
One possibility is that too much power is reaching the CMOS detector, penetrating, and then reflecting back to the back side of the detector. Lower power and higher exposure times may avoid this problem, and the glass of the GC1280 is simply cutting down on the amount passing through.
This theory will be tested either this evening or tomorrow morning, by reducing the power on the GC750 to the point at which it needs to be exposed for 60,000 microseconds to get a decent image.
The other possibility is that the GC750 was damaged at some point by too much incident power, although its unclear what kind of failure mode would generate the images we have seen recently from the GC750. |
| Attachment 1: GC1280_60000E_scatter_2d.pdf
|
|
| Attachment 2: GC1280_60000E_scatter_3d.pdf
|
|
|
558
|
Tue Jun 24 17:12:10 2008 |
josephb, Eric | Configuration | Cameras | GC750 setup, 1X4 Hub connected, ETMX images |
The GC750 camera has been setup to look at ETMX. In addition, the new 1X4 rack mounted switch (131.215.113.200) has been connected via new cat6 cable to the control room hub (131.215.113.1?), thanks to Eric. The camera is now plugged into 1X4 rack switch and now has a gigabit connection to the control room computers as well as Mafalda (131.215.113.23).
By using ssh -X mafalda or ssh -X 131.215.113.23, then typing:
target
cd Prosilica/bin-pc/x86/
./Sampleviewer
A viewer will be brought up. By clicking on the 3rd icon from the left (looks like an eye) will bring up a live view.
Closing the view, and then cd ../../40mCode, and then running ./Snap --help will tell you how to use a simple code for taking .tiff images as well as setting things such as exposure length and size of image (in pixels) to send.
When the interferometer was set to an X-arm only configuration, we took two series of 200 images each, with two different exposure lengths.
Attached are three pdf images. The first is just a black and white single image, the second is an average of 100 images, and the third is the standard deviation of the 100 images. |
| Attachment 1: GC750_ETMX_E30000_single.pdf
|
|
| Attachment 2: GC750_ETMX_E30000_avg.pdf
|
|
| Attachment 3: GC750_ETMX_E30000_std.pdf
|
|
|
566
|
Wed Jun 25 12:25:28 2008 |
Eric | Summary | Cameras | 2D Gaussian Fitting Code |
I initially wrote a script in MATLAB that takes pictures of the laser beam's profile and fits them to a two dimensional gaussian in order to determine the position and width of the beam. This code is now (mostly) ported to C so that it can be imbedded in the camera software package that Joe is writing. The fitting works fairly well for pictures with the beam directly incident on the camera, and less well for pictures of scatter off the end mirrors of the arms, since scatter from defects in the mirror have intensities much greater than the intensity of the beam's gaussian profile.
The next steps are to finish up porting the fitting code to C, and then modify it so it can better handle the images off the end mirror. Some thoughts on how to do this are to use a fourier transform and a low pass filter, or to simply use a center-of-mass calculation (with the defect peaks reduced in intensity), since position is more important than beam width in this calculation. The eventual goal is to include the edge of the optic in the picture and use the fit of the beam position in comparison to the optic's position to find the beam's location on the mirror. |
|
622
|
Wed Jul 2 10:35:02 2008 |
Eric | Summary | Cameras | General Summary |
I finished up the 2D Gaussian fitting code, and, along with Joe, integrated into the Snap software so that it automatically does a fit to every 100th image. While the fitting works, it is too slow for use in any feedback to the servos. I put together a center of mass calculation to use instead that is somewhat less accurate but much faster (almost instantaneous versus 5-10 seconds). This has yet to be added to the Snap software, but doing so would not be difficult.
I put together a different fitting function for fitting the multiple lorentzian resonance peaks in a power spectrum that would result from sweeping the length of any of the mode cleaners. This simply doesn't work. I tested it on some of Josh Weiner's data collected on the OMC last year, and the data fits poorly. Attempting to fit it all at once requires fitting 80000 data points with 37 free parameters (12 peaks at 3 parameters per peak and 1 offset parameter), which cannot be done in any reasonable time period. Attempting to fit to one specific peak doesn't work due to the corruption of the other nearby peaks, even though they are comparatively small. The fit places the offset incorrectly if given the opportunity (green line in attemptedSinglePeakFitWithoutOffset.tiff and attemptedSinglePeakFitWithoutOffsetZoomed.tiff). Removing this as a parameter causes the fit to do a much better job (red line in these two graphs). The fit still places the peak 0.01 to the right of the actual peak, which worse than could simply be obtained by looking at the maximum point value. Additionally, this slight shift means that attempting to subtract out the peak so that the other peaks are accessible doesn't work -- the peaks are so steep that the error of 0.01 is enough to cause significant problems (red in attemptedPeakSubtraction.tiff is the attempted subtraction). Part of the problem is that the peaks are far from perfect lorentzians, as seen by cropping to any particular peak (OMCSweepSinglePeak.tiff ). This might be corrected in part by correcting for the conversion from PZT voltage to position, which isn't perfectly linear; though I doubt it would remove all the irregularities. At the moment, the best approach seems to be simply using a center of mass calculation cropped to the particular peak, though I have yet to try this.
Changing Josh's code to work for the digital cameras and the PMC or MC shouldn't be difficult. Changing to the MC or PMC should simply involve changing the EPICs tags for the OMC photodiodes and PZTs to those of the PMC or MC. Making the code work for the digital cameras should be as simple as redirecting the call to the framegrabber software to the Snap software. |
| Attachment 1: attemptedSinglePeakFitWithoutOffset.tiff
|
| Attachment 2: attemptedSinglePeakFitWithoutOffsetZoomed.tiff
|
| Attachment 3: attemptedPeakSubtraction.tiff
|
| Attachment 4: OMCSweepSinglePeak.tiff
|
|
657
|
Thu Jul 10 23:27:57 2008 |
John | Metaphysics | Cameras | Secret handshakes |
Rob and I have joined the ranks of the illuminati and exercised our power.
| Quote: | Osamu showed me the secret way to change the video labels for the quads and
so we fixed them. He made me swear not to divulge this art.
- Rana Adhikari |
|
|
660
|
Fri Jul 11 20:16:01 2008 |
Eric | DAQ | Cameras | Taking data from the GC 750 Camera |
Mafalda has been set up with a background process to constantly take data from the GC 750 camera (at the end of the x-arm) for the weekend. This camera will otherwise be inoperable until then.
In the small chance that this slows either Mafalda or the network to a crawl, the process to kill should have PID 26265. |
|
671
|
Tue Jul 15 10:09:42 2008 |
Eric | DAQ | Cameras | Did anyone kill the picture taking process on Mafalda? |
| Did anyone kill the process on Mafalda that was taking pictures of the end mirror of the x-arm last Friday? I need to know whether or not it crashed of its own accord. |
|
678
|
Wed Jul 16 10:50:55 2008 |
Eric | Summary | Cameras | Weekly Summary |
Finished unwrapping, cleaning, baking, wrapping, wrapping again, packing, and shipping the baffles.
Attempted to set up the Snap software so that it could talk directly to EPICS channels. This is not currently working due to a series of very strange bugs in compiling and linking the channel access libraries. Alex Ivanov directed Joe and me to a script and makefile that are similar to what we're trying to do and it may solve our problem, but at the moment this still doesn't work. We're currently using a workaround that involves making unix system calls to ezca command line tools, but this is too hacky to leave in the final program.
Attempted to fit Josh's PZT voltage vs power plot of the OMC (from about a year ago) to lorentzians in order to try to develop fitting tools for more recent data. This isn't working, due to systematic error distorting the shapes of the peaks. Good fits can be obtained by cutting the number of points to a very small number around the peak of resonance, but this leads to such a small percentage of the peak being used that I don't trust these results either. (In the graph (shows the very top of the tallest peak): blue is Josh's original data, green is a fit to this peak using the top 66% of the peak and arbitrary, equal values for the error on each point, red is Josh's data averaged over bins of size 0.005, teal is a fit to these bins where the error on each point is the standard deviation of each bin, and magenta is a fit to these same bins, except cropped to the top ~10% of the peak, x-axis is voltage, y-axis is transmission power). Rana suggested that I take my own sweeps of the PMC using scripts that are already written: I'm currently figuring out where these scripts are and how to use them without accidently breaking something.
We've begun running the Snap software for long periods of time to see how stable it is. Currently, its only problem appears to be that it memory leaks somewhat: it was up 78% memory usage after a little over an hour. It doesn't put much strain on the computer, using only ~20% CPU. Stress put on the network from the constant transfer of images from the camera to the computer is not yet known. |
| Attachment 1: AttemptedPeakFit3.tiff
|
|
681
|
Wed Jul 16 15:59:04 2008 |
josephb, Eric | Configuration | Cameras | PMC trans camera path |
In order to reduce saturation, we placed a Y1 plate (spare from the SP table) in transmission just before the GC650 camera looking at the PMC transmision. The reflection (most of the light) was dumped to a convient razor blade dump. We also removed the 0.3 and 0.5 ND filters and placed them in the 24 hour loan ND filter box.
Good exposure values to view are now around 3000 for that camera. |
|
693
|
Fri Jul 18 12:24:15 2008 |
josephb, Eric | Configuration | Cameras | Changed Lenses on GC750 at ETMX |
We removed the giant TV zoom lens and replaced it with a much smaller fixed zoom lens. Currently it views the entire optic. We have another (also small) zoom lens which focuses much better on the spot itself. With how far back the camera is currently placed, neither of these fixed zoom lenses can touch or hit the view port or the chamber while still attached to camera and mount, even using all of the mount's motion range. So this should be less of a safety issue.
Ideally, we'd like to get some images of the full optic (including osems and so forth) with the X-arm locked, and then use the higher zoom lens while still locked, to get images we can use to calibrate the x and y length scales. |
|
722
|
Wed Jul 23 12:42:23 2008 |
Eric | Summary | Cameras | Weekly Summary |
I finally got the ezcaPut command working. The camera code can now talk directly to the EPICS channels. However, after repeated calls of the ezcaPut function, the function begins claim to time out, even though it continues to write values to the channel successfully (EPICS is successfully getting the new value for the channel, but failing to reply back to the program in time, I think). It has seg-faulted once as well, so the stability cannot yet be trusted for running long term. For now, however, it works well enough to test a servo in the short term. The current approach simply uses a terminal running ezcaservo with the pitch and yaw offset channels of the ETMX, as well as the channels that the camera code output to. This hasn't actually been tested since we haven't had enough time with the x-arm locked.
Tested various fixed zoom lens on the camera, since the one we were previously using was too heavy for its mount and likely more expensive than necessary. The 16mm lens gets a good picture of the beam and the optic together, though the beam is a little too small in the picture to reliably fit a gaussian to. The 24mm lens zooms too much to see the whole optic, but the beam profile itself is much clearer. The 24mm lens is currently on the camera.
Scanned the PZT voltage of the PMC across its full offset range to gain a plot of voltage vs intensity. I used DTT's triggered time series response system to measure the outputs of the slow PZT voltage and transmission intensity channels, and used the script triangle wave to drive the PZT ramp channel slowly over its full range (I couldn't get DTT to output to the channel). Clear resonances did appear (PMCScanWide.tif), but the number of data points per peak was far too small reliably fit a lorentzian to (PMCScanSinglePeak.tif). When I decreased the scanning range and increased the time in order to collect a large number of points on a few peaks, the resulting data was too messy to fit to a lorentzian (PMCSlowSinglePeak.tif). |
| Attachment 1: PMCScanSinglePeak.tif
|
|
| Attachment 2: PMCScanWide.tif
|
|
| Attachment 3: PMCSlowSinglePeak.tif
|
|
|
769
|
Wed Jul 30 13:52:41 2008 |
Eric | Summary | Cameras | Weekly Summary |
I tracked the tendency for ezcaPut to fail and sometimes seg-fault in the camera code to a conflict between the camera API and ezca, either on the
network level or the thread level. Since neither are sophisticated enough to provide controls over how they handle these two things, I instead
separated the call to ezcaPut out into a small, separate script (a stripped down ezcawrite), which the camera code calls at the system level. This is a
bit hacky of a solution, but its the only thing that seems to work.
I've developed a transformation based on Euler angles that should be able to take the 4 OSEMs in a picture of the end mirror and use their relative
positions to determine the angle of the camera to the optic. This would allow the position data determined by the fitting software to be converted
from pixels to meaningful lengths, and should aid any servo-ing done on the beams position. I've yet to actually test if the equations work, though.
The servo code needs to have slew rate limiters and maximums/minimums to protect the mirrors written in to it before it can be tested again, but I
have no idea what reasonable values for these limits are.
Joe and I recently scanned the PMC by driving C1:PSL-PMC_RAMP with the trianglewave script over a range of -3.5 to -1.25 (around 50 to 150 volts
to the PZT) and read out C1:PSL-ISS_INMONPD to measure the transmission intensity. This included slightly under 2 FSRs. For slow scans (covering
the range in 150 to 300 s), the peaks were very messy (even with the laser power at 1/6 its normal value), and it was difficult to place where the
actual peak center occurred. For faster sans (covering the range in 30 seconds or so), the peaks were very clean and nearly symmetric, but were
not placed logically (the same peak showed up at two very different values for the PZT voltage in two separate runs). I don't have time to put
together graphs of the scans at the moment; I'll have that up sometime this afternoon. |
|
809
|
Thu Aug 7 11:54:26 2008 |
josephb | Configuration | Cameras | New code + gstreamer allows for easy saving and compression of images |
Modified the CamSnap code to output the image data stream to standard out. This can then be piped into a gstreamer plugin and then be used to save, encode, transmit, receive, slice, dice and or mangle video (or virtually any type of data stream).
The gstreamer webpage can be found at: http://www.gstreamer.net/
Under documentation you can find a list off all available plug-ins. Some good, some bad, some ugly.
Running the following command on Mafalda (via ssh -X mafalda) or Rosalba while in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/
CamSnap -F 'Mono8' -c 44058 -E 15000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 1000 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=1/1 ! ffmpegcolorspace ! ximagesink
This command will create a window which displays what the camera with UID 44058 is looking at. It will display 1000 images, then quit. (You can switch the -m 100 to -i to just have it continue until the process is stopped).
You can also encode the data into compressed format and save it in a media file. The following command line will encode the images into an ogg media file (.ogm), which can be played with the totem viewer (available on Rosalba or almost any machine running Ubuntu or Centos) or any other viewer capable of handling ogm files. By switching the plugins you can generate other formats as well.
The compression is good, putting 300 images normally about 500K individually uncompressed to about 580K as a single file.
The following command line was used to generate the attached video file:
CamSnap -F 'Mono8' -c 44058 -E 5000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"
Currently looking into plugins which allow you to pull individual frames out of a video file and display or save them in a variety of formats. This would allow us to save long term images in compressed video format, and then pull out individual frames as needed.
Also need to look into how to "T" the streams, so one can be displaying while another encodes and saves. |
| Attachment 1: testVideo.ogm
|
|
812
|
Fri Aug 8 09:54:10 2008 |
rana | Update | Cameras | New code + gstreamer allows for easy saving and compression of images |
| Quote: | | Modified the CamSnap code to output the image data stream to standard out. This can then be piped into a gstreamer plugin and then be used |
Didn't work; Prosilica has only 1 "l". Even so, sshing from op440m to mafalda, I got this:
mafalda:SnapCode>CamSnap -F 'Mono8' -c 44058 -E 5000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw
-gray, height=480, width=752, bpp=8,depth=8,framerate=30/1 ! ffmpegcolorspace ! theoraenc ! oggmux ! filesink location="./testVideo.ogm"
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
** (gst-launch-0.10:27121): WARNING **: Size 60 is not a multiple of unit size 360960
Caught SIGSEGV accessing address 0x487c
ERROR: from element /pipeline0/ffmpegcsp0: subclass did not specify output size
Additional debug info:
gstbasetransform.c(1495): gst_base_transform_handle_buffer (): /pipeline0/ffmpegcsp0:
subclass did not specify output size
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7deddae in __lll_mutex_lock_wait ()
#2 0xb7de9aac in _L_mutex_lock_51 () from /lib/tls/i686/cmov/libpthread.so.0
#3 0xb7de949d in pthread_mutex_lock ()
#4 0xb7e452e0 in g_static_rec_mutex_lock () from /usr/lib/libglib-2.0.so.0
#5 0xb7f1fa08 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#6 0x080c1220 in ?? ()
#7 0x00000001 in ?? ()
#8 0x0809586c in ?? ()
#9 0x00000001 in ?? ()
#10 0x08095868 in ?? ()
#11 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#12 0xb7e8da80 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#14 0xb7f7a2a8 in ?? () from /usr/lib/libgstreamer-0.10.so.0
#15 0x00000000 in ?? ()
Spinning. Please run 'gdb gst-launch 27121' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core.
Caught interrupt --
|
|
813
|
Fri Aug 8 10:58:05 2008 |
josephb | Configuration | Cameras | Cameras and gstreamer |
In regards to camera failure:
1) I forgot to reconnect that particular camera to the network (my fault) so thats why it was failing.
2) Even with the correct camera connected, I've realized at full frame rate, op440m is going to get a few frames and then fail, as I don't think it has a fast enough ethernet card. It will work on Rosalba, and will also work ssh-ing from Rosalba because it is using a new ethernet card. It also works on my laptop, which is where I originally tested the command. One way to get around this is to increase the time between pictures, by changing -l 0 to -l 1 (or higher), where the number after the "ell" is the number of seconds to wait between frame captures.
3) What I should do is figure out the UDP transmission plugins for gstreamers and compress first (using the theoraenc since it gets compression ratios of better than 100:1) and transmit that over the network.
I have since reconnected the camera, so it should work on Rosalba and any sufficiently well connected computer. For other machines like linux2 or op440, try the following line:
Running the following command on Mafalda (via ssh -X mafalda) or Rosalba while in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/
CamSnap -F 'Mono8' -c 44058 -E 10000 -X 0 -Y 0 -H 480 -W 752 -l 1 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=1/1 ! ffmpegcolorspace ! ximagesink
This will be at a much slower frame rate (1 per second) but should work on any of the machines. (Tested on linux2). |
|
828
|
Tue Aug 12 12:21:13 2008 |
josephb | Configuration | Cameras | Variation in fit over 140 images for GC650 and GC750 |
Used matlab to calculate Gaussian fits on 145 GC650 images and 142 GC750 images. These were individual images (no averaging) looking at the PSL output from May 29th 2008. The GC650 and GC750 were looking at a split, but had different exposure values, slightly different distances to the nominal waist of the beam, and were not centered on the beam identically. Mostly this is a test of the fluctuations in the fit from image to image.
Note the mm refer to the size or position on the CCD or CMOS detector itself.
GC650
Mean
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.3743 1.7378 2.6220 0.7901 0.8650 0.0047
Standard Deviation
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.0024 0.0006 0.0005 0.0005 0.0003 0.00001
Std/Mean x100 (percent)
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.6% 0.03% 0.02% 0.06% 0.04% 0.29%
GC750
Mean
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.2024 2.5967 1.4458 0.8245 0.9194 0.0418
Standard Deviation
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.0011 0.0005 0.0005 0.0003 0.0005 0.00003
Std/Mean x100 (percent)
Amplitude X center Y center X waist Y waist Background offset from zero
position (mm) position (mm) (mm) (mm)
0.6% 0.02% 0.04% 0.04% 0.05% 0.07%
|
|
835
|
Thu Aug 14 15:51:35 2008 |
josephb | Summary | Cameras | FOUND! The Missing Standoff! |
| We used a zoom lens on the GC750 to take this picture of the standoff while inside a plastic rubber-glove bag. The standoff with bag is currently scotch-taped to the periodic table of the elements. |
| Attachment 1: standoff.png
|
|
|
839
|
Fri Aug 15 11:52:32 2008 |
josephb | Configuration | Cameras | Multi-computer display and recording of digital camera output |
Through the magic of gstreamer, I've been able to live play on one machine, compress the image, send it to another machine via udp, and also display it there. The "tee" function also allows one to save at the same images at time as well.
The command line used on the "server", say Rosalba or Mafalda is:
CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 100 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! tee name=t1 t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! ximagesink t1. ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host="131.215.113.103" port=5000
This both displays the image and sends it to the host 131.215.113.103 in this case.
I've written a primitive shell script that does most of this.
It requires at the minimum an IP address. You can also give it a number of images (the -m number) and also the exposure value (-E 20000).
Currently in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode/ there is a script called CameraServerScript.
Typing in "CameraServerScript 131.215.113.107" would send it to that IP address.
Typing in "CameraServerScript 131.215.113.107 500 40000" would run for 500 images at an exposure value of 40000.
To actually receive, you need gstreamer installed and run the following command:
gst-launch udpsrc port=5000 ! smokedec ! queue ! ffmpegcolorspace ! ximagesink sync=false
Make sure you have the right IP address to send to.
Still working on multicasting (basically a server is constantly sending out images, and the client subscribes to the multicast). |
|
847
|
Mon Aug 18 15:32:18 2008 |
josephb | Configuration | Cameras | How to multicast with gstreamer and Gige Cameras |
In order to get multicasting to work, one simply needs to understand the address scheme.
In general, the address range 224.0.0.0 - 239.255.255.255 are reserved for multicasting. Within in this address space, there are some base level operations in the 224.0.0.x range which shouldn't be interfered with.
For a single site, the address range between 239.252.0.0 and 239.255.255.255 is probably best.
Gstreamer and the current 40m network hubs are designed to handle this kind of communication already, so one merely needs to point them at the correct addresses.
While in /cvs/cds/caltech/target/Prosilica/40mCode/SnapCode type:
CamServe -F 'Mono8' -c 44058 -E 20000 -X 0 -Y 0 -H 480 -W 752 -l 0 -m 300 | gst-launch-0.10 fdsrc fd=0 blocksize=360960 ! video/x-raw-gray, height=480, width=752, bpp=8,depth=8,framerate=60/1 ! ffmpegcolorspace ! queue ! smokeenc keyframe=8 qmax=40 ! udpsink host=239.255.1.1 port=5000
This will multicast to the 239.255.1.1 address, using port 5000.
On the machine you wish to subscribe type:
gst-launch udpsrc multicast-group=239.255.1.1 port=5000 ! smokedec ! ffmpegcolorspace ! ximagesink sync=false |