ID |
Date |
Author |
Type |
Category |
Subject |
13900
|
Thu May 31 02:04:55 2018 |
johannes | Update | PSL | AUX laser state of mind |
The AUX laser is down to 5.4 mW output power 
What's worse, because we wanted those fast switching times by the AOM for ringdowns, I made the beam really small, which
- came with a severe tradeoff against conversion efficiency. I tried to squeeze the last out of it today, but there's only about 1.3 mW of diffracted light in the first order that reaches the fiber, with higher diffraction orders already visible.
- produced a very elliptical mode which was difficult to match into the fiber. Gautam and I measured 600 uW coming out of the fiber on the AS table. This per se is enough for the SRC spectroscopy demonstration, but with the current setup of the drive electronics there's no amplitude modulation of the deflected beam.
When going though the labs with Koji last week I discovered a stash of modulators in the Crackle lab. Among them there's an 80 MHz AOM with compact driver that had a modulation bandwidth of 30MHz. The fall time with this one should be around 100ns, and since the arm cavities have linewidths of ~10kHz their ringdown times are a few microseconds, so that would be sufficient. I suggest we swap this or a similar one in for the current one, make the beam larger, and redo the fiber modematching. That way we may get ~3mW onto the AS table.
I think I want to use AS110 for the ringdowns, so in the next couple days I'll look into its noise to get a better idea about what power we need for the arm ringdowns. |
Attachment 1: IMG_20180530_220058190.jpg
|
|
13911
|
Sun Jun 3 22:48:59 2018 |
johannes | Update | PSL | aux laser replacement |
I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.
This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.
The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.
In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.
Some more things I wanted to do but didn't get to today are
- Measure intensity noise of aux laser
- Measure rise and fall times of new AOM
- Get PLL back up and running
- Place 90/10 beamsplitter in AS path and couple IFO output into fiber (= couple fiber output into IFO)
I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV. |
13912
|
Mon Jun 4 02:52:52 2018 |
johannes | Update | PSL | aux laser replacement |
> While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted.
NPRO internal power monitor often shows smaller value than the actual due to a broken PD or misalignment. I don't think we need to fix it.
STEVE: Aux Lightwave M126-1064-200, sn259 [July 2009] 1.76A, ADJ 9, 9mW on it's display should not mislead you. It's output 320mW
Quote: |
I brought the NPRO from the Crackle experiment over to the 40m Lab and set it up on the PSL table to replace the slowly dying AUX laser. I also brought along a Faraday isolator, broadband EOM, and an ISOMET AOM with driver electronics from the optics storage in the Crackle Lab.
This laser is a much newer model, made in 2008, and still has all its mojo, but we should probably keep up the practice of turning it off when it's not going to be used for a while. I measured 320 mW leaving the laser, and 299mW of that going through the Faraday isolator, whose Brewster-angle polarizer I had to clean because they were a little dusty. While the laser output is going strong, the controller displays a power output of only 10 mW, which makes me think that the power monitoring PD is busted. This is a completely different failure mode from what we've seen with the other NPROs that we can hopefully get repaired at some point, particularly because the laser is newer, but for now it's installed on the PSL table. This likely means that the noise eater isn't working on this unit either, for different reasons, but at least we have plenty of optical power.
The setup is very similar to before, with the addition of a Faraday isolator and a broadband EOM, in case we decide to get more bandwidth in the PLL. I changed the Crystal Technologies 3200-113 200 MHz AOM for an ISOMET 80 MHz AOM with RF driver from the Crackle lab's optics storage and sized the AUX beam to a diameter of 200 micron. I couldn't locate an appropriate heat sink for the driver, which is still in factory condiction, but since the PSL AOM also runs on 80MHz I used that one instead. The two AOMs saturate at different RF powers, so care must be taken to not drive the AUX AOM too high. At 600 mV input to the driver the deflection into the first order was maximal at 73 % of the input power, with the second order beam and the first order on the other side cleary visible.
In order to speed things up I didn't spend too much time on mode-matching, but the advantage of the fiber setup is that we can always improve later if need be without affecting things downstream. I coupled the first order beam into the fiber to the AS table with 58% efficiency, and restored the beat with the PSL laser on the NewFocus 1611. The contrast there is only about 20%, netting a -20 dBm beat note. This is only a marginal improvement from before, so the PLL will work as usual, but if we get the visibility up a little in the future we won't need to amplify the PD signal for the PLL anymore.
Some more things I wanted to do but didn't get to today are
- Measure intensity noise of aux laser
- Measure rise and fall times of new AOM
- Get PLL back up and running
- Place 90/10 beamsplitter in AS path and couple IFO output into fiber (= couple fiber output into IFO)
I'll resume this work tomorrow. I turned the aux laser and the AOM driver input off. For the PSL beat the AOM drive is not needed, and the power in the optical fiber should not exceed 100 mW, so the offset voltage to the AOM RF driver has to remain below 300 mV.
|
|
13932
|
Fri Jun 8 01:08:22 2018 |
johannes | Update | PSL | First light of AUX at YEND |
Among the things that we hadn't taken care of yesterday before beginning to look for transmission signals were the polarization of the AUX beam on the AS table and optimizing the PLL feedback. The AUX beam is s-polarized on the PSL table (choice due to availablility of mirrors), and I added a half waveplate in front of the fiber to match it's axes. I placed another half-waveplate at the fiber output and send the reflection port of a PBS cube onto a PDA1CS photodetector. By alternatingly turning the waveplates I minimized the reflected light, giving strongly p-polarized light on the AS table for best results when interfering with the IFO beam. I wiggled the fiber and found no strong dependency of the output polarization on fiber bending. Attachment 2 shows the current layout.
The beat signal between AUX and PSL table is at -20dBm, and I adjusted the PLL gain and PI-corner to get reliable locking behavior. I think it's a good idea to keep the AUX beam on the AS table blocked while it's not in use, and only unblock it when it is phaselocked to avoid a rogue beam with no fixed phase relation to the PSL in the IFO.I blocked the beam after completing this work today.
I used the signal chain that Keerthana, Koji, and I set up yesterday to look for mode flashed of the AUX light in the YARM using the RF beat with the PSL carrier in transmission. To align the AUX beam to the arm the following steps were performed:
- Using a spectrum analyzer to look at the RF power at the target frequency between frequency-shifted AUX beam and PSL carrier on AS110, align the beam using the mirror pair closest to the fiber coupler for maximum signal.
- Initiate a sweep of the PLL LO frequency sourced by the Marconi using GPIB scripts over about 1 FSR. A strong peak was visible at ~31.76 MHz offset frequency
- Tune and hold LO frequency (in this case at 48.2526 MHz) such that AUX beam resonates in the arm. Optimize alignment by maximizing RF signal on PD in transmission.
This was followed by a sweep over two full FSRs. Attachment #1 shows the trace recorded by the AG4395 using the max data hold setting during the sweep. Essentially the beat between AUX and PSL carrier traced out the arm's transmission curve. At minimum transmission there was still a ~82dB beat on the transmission PD visible.
The YEND QPD is currently blocked and sees no light. |
Attachment 1: AG4395A_07-06-2018_205019.pdf
|
|
Attachment 2: PSL_AUX_SETUP.pdf
|
|
Attachment 3: AS_AUX_SETUP.pdf
|
|
13958
|
Wed Jun 13 23:23:44 2018 |
johannes | Update | CDS | EX wiring confusion |
It's true.
I went through the wiring of the c1auxex crate today to disentangle the pin assignments. The full detail can be found in attachment #1, #2 has less detail but is more eye candy. The red flagged channels are now marked for removal at the next opportunity. This will free up DAQ channels as follows:
TYPE |
Total |
Available now |
Available after |
ADC |
24 |
2 |
14 |
DAC |
16 |
8 |
12 |
BIO sinking |
16 |
7 |
7 |
BIO sourcing |
8 |
8 |
8 |
This should be enough for temperature sensing, NPRO diagnostics, and even eventual remote PDH control with new servo boxes. |
Attachment 1: c1auxex_channels.pdf
|
|
Attachment 2: XEND_slow_wiring.pdf
|
|
13965
|
Thu Jun 14 15:31:18 2018 |
johannes | Update | CDS | EX wiring confusion |
Bad wording, sorry. Should have been channels in excess of ETMX controls. I'll add the others to the list as well.
Updated channel list and wiring diagram attached. Labels are 'F' for 'Front' and 'R' for - you guessed it - 'Rear', the number identifies the slot panel the breakout is attached to. |
Attachment 1: XEND_slow_wiring.pdf
|
|
Attachment 2: c1auxex_channels.pdf
|
|
13968
|
Thu Jun 14 22:45:05 2018 |
johannes | Update | General | AUX beam SRC alignment |
[Jon, Gautam, Johannes]
Jon spent some time trying to align the AUX beam to the SRC today, I got to the game kind of late so maybe others can add more detail.
The AUX beam that is reflected by the SRM looks terribly misshapen - it is quite elongated in vertical direction. Unfortunately I didn't snap a picture of it - anybody? It seemed at first as if this could be clipping - but after confirming the alignment of the AUX beam with the PSL output beam with aligned SRM, a slow dither of the SRM just moved the ugly pattern on the AS camera with no change to its shape - so clipping is unlikely. I'm now thinking that this is just the output beam of the fiber coupler after propagating ~15 meters to the SRM and back - even though this aspheric lens triplet coupler is supposed to be super-duper. I found that if I loosen the fiber slightly and pull it back just a bit at least the spot on the AS camera becomes nice and round - so maybe the fiber just doesn't sit well in this collimator? Not sure why that would be. I checked the fiber tip with the microscope, and while there was some gunk present, the central region and the core were clear (still cleaned using the fiber cleaning kit, which got rid of the debris). Either way, before switching to a different collimator I think we should give the Guoy phase measurement a shot - after all there was plenty of RF signal present on both AS110 and the PDA10CF placed at the YEND.
Looking for rogue beams on the AS table, I started placing some beam dumps. There was one particularly strong source of stray beams - a lens that was labeled with KPX094AR.33_F100. It became apparent after alignment efforts to the IFO had moved the AUX beam signifcantly off-center on this lens. According to the label it should have an AR coating for 1064nm, however judging by the amount of reflected light, it was certainly NOT AR-coated for 1064nm. I replaced it with a bi-convex f=100mm lens with confirmed AR-behavior.
The AUX laser is currently shuttered.
Per our Wednesday meeting, some items to work on are
- Align the zero-order AUX beam into a second collimator on the PSL table, so we can switch the fiber output and look for RF signals at the offset-phaselock frequency without the additional frequency shift from the AOM. This will simpligy the mode spectroscopy scheme significantly
- Abandon the R10/T90 beamsplitters in favor of R90/T10 beamsplitters. We'll swap the large mirror in front of the AS camera with an R90/T10 BS, and follow it up with a second R90/T10 BS that sends the AUX beam to the IFO. This way we'll have identical power levels on AS110 and AS55, and still 90% of the current AUX light going into the IFO, but without strong secondary beams from R10/T90 optics.
|
13978
|
Mon Jun 18 10:34:45 2018 |
johannes | Update | Computer Scripts / Programs | running comsol job on optimus |
I'm running a comsol job on optimus in a tmux session named cryocavs. Should be done in less than 24 hours, judging by past durations. |
13982
|
Mon Jun 18 15:59:17 2018 |
johannes | Update | PSL | Optics on AS table |
Quote: |
Furthermore, I believe we are losing more than 10% of the light due to this BS. The ASDC (which is derived from AS55 PD) level is down at ~110cts as the Michelson is fringing, while it used to be ~200 cts. I will update with a power measurement shortly. But I think we should move ahead with the plan to combine the beam into the IFO's AS mode as discussed at the meeting last week.
|
Is the 10% specified for P-Pol or for UNP? I contacted CVI about beamsplitters, since their website doesn't list a BS1-1064-90-... option on the website. They say a R=90% beamsplitter would be a custom job. The closest stock item they got is BS1-1064-95-2025-45UNP specified at R=95% for UNPolarized beams. They were kind enough to sent me the measured transmission curves for a recent lot of these, which is attached was uploaded to the wiki [Elog Police K: NO PROPRIETARY DOCUMENTS ON THE ELOG, which is public. Put it on our wiki and put the link here]. The figure is not labeled, but according to the contact Red is S-Pol and Blue is P-Pol, which means that this one actually has R=~90% for P, pretty much what we want. We'll need to buy two of these to make the swap in the setup.
Back to your original point: There's only a BS1-1064-10-2025-45UNP on the website, so unless we got these as custom items, the R for P-Pol is probably NOT actually 10%, just somewhere between 0% and 20% |
13989
|
Wed Jun 20 00:57:04 2018 |
johannes | Update | General | AUX beam alignment issues |
We did swap a lens as discussed in elog 13968, but they both had f=100mm specified, the difference being one was AR-coated for 1064 and bi-convex, while the other one was plano-convex and had a different coating. The reason for the large beam spot was something else: The fiber wasn't sitting in the coupler properly. When reconnecting the fiber after taking it out make sure to align the key on the fiber end with the notch in the coupler before tightening. After discovering this the following was done:
- Fixed fiber mounting situation
- Tested AUX alignment into fiber on PSL table, was still good
- The AUX polarization was aligned to the wrong fiber axis. I fixed this. The coupler on the PSL table has it's noth oriented vertically since we're using s-polarized light. The AS-table coupler is rotated by 90 degrees, such that the notch points to the side. This way we technically don't need any halfwaveplates for rotation. However, there are still current HWPs installed.
- Locked both arms and ran dither alignment until satisfactory
- Misaligned ITMX and ETMX, and further set the ITMX pitch offset to 0.0
- Started overlapping the expectedly misaligned beams by eye. For this I turned the power of the deflected beam down to 50mV bias voltage, which gives the PSL and AUX lasers similar card-brightness on the shared path
- Misaligned SRM more because there was still the strong prompt reflection coming out the AS port.
- Restored phaselock between AUX and PSL, with beat at 30MHz between 1st-order diffracted in fiber and PSL
- Immediately saw STRONG 30MHz RF signal on AG4395. Disappeared when blocking AUX, and optimized alignment brought the signal up to -10dBm, as shown in attachment #1
- Checked YEND PDA10CF and saw a -80dBm RF signal at 30 MHz (#2), compatible with earlier observations.
Before leaving I restored the XARM alignment. SRM remains misaligned, LSC off. Alignment shouldn't change drastically over night, so I suggest when picking this work up tomorrow to directly look for the beats after phaselocking AUX and PSL |
Attachment 1: as110_rf_30MHz.pdf
|
|
Attachment 2: yend_rf_30MHz.pdf
|
|
14013
|
Sun Jun 24 23:13:46 2018 |
johannes | Update | General | AUX beam alignment issues |
At some point we want to change the AUX injection on the AS table to interfere less with the normal interferometer path, and avoid 10/90 beamsplitters which produce a fair amount of ghosting. The plan is to replace the 99/1 BS whose reflection goes to AS110 and AS55, while the transmission goes to the AS camera, with a 90/10 BS as shown in the attachment. This results in ~10% less light on the PDs compared to the pre-AUX era. Between this BS and the AS camera there will be a second 90/10 BS that sends the AUX light into the IFO, so we end up with marginally less AUX power into the IFO and the same PSL power on the AS cam. We're short optics, so this has to wait until two new beamsplitters arrive from CVI. |
Attachment 1: AS_AUX_SETUP.pdf
|
|
14170
|
Mon Aug 20 14:04:53 2018 |
johannes | Bureaucracy | Equipment loan | Two C30642G PDs removed |
EDIT: After discussing with Koji and checking the existing M2ISS PDs I put the two C30642G back and took two C30665GH (active diameter: 3mm) diodes. Only one of this type remains in storage.
I removed two C30642G photodiodes from the stash for the new M2ISS hardware and updated the wiki page accordingly.
|
14172
|
Tue Aug 21 03:09:59 2018 |
johannes | Omnistructure | DAQ | Panels for Acromag DAQ chassis |
I expanded the previous panels to 6U height for the new DAQ chassis we're buying for the upgrade. I figure it's best if we stick to the modular design, so I'm showing a panel for 8 BNC connectors as an example. The front panel has 12 slots, the back has 10 plus power connectors, switches, and the ethernet plug.
I moved the power switch to the rear because it's a waste of space to put it in the front, and it's not like we're power cycling this thing all the time. Note that the unit only requires +24V (for general operation, +20V also does the trick, as is the situation for ETMX) and +15V (excitation field for the binary I/O modules). While these could fit into a single CONEC power connector, it's probably for the better if we don't make a version that supplies a large positive voltage where negative is expected, so I put in two CONEC plugs for +/- 15 and +/- 24.
I want to order 5-6 of these as soon as possible, so if anyone wants anything changed or sees a problem, please do tell! |
Attachment 1: auxdaq_40m_6U_front.pdf
|
|
Attachment 2: auxdaq_40m_6U_rear.pdf
|
|
Attachment 3: auxdaq_40m_6U_BNC.pdf
|
|
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/. |
345
|
Thu Feb 28 16:19:37 2008 |
josephb | Configuration | Computers | Mafalda rewired and multiple cameras running |
1) Mafalda is now connected via an orange Cat5E ethernet cord to the gigabit ethernet switch in rack in the office space. It has been labeled at both ends with "mafalda".
2) Both the GC650M camera (from MIT) and the GC750M are working. I can run the sampleviewer code and get images simultaneously. Unforutnately, the fps on both cameras seems to drop roughly in half (not an exact measurement) when displaying both simultaneously at full resolution.
3)Discovered the Gigabit ethernet card in Mafalda doesn't support jumbo packets (packets of up to 9k bytes), which is what they recommend for optimum speed.
4)However, connecting the cameras through only gigabit switches to Mafalda did seem to increase the data rate anyways, roughly by a factor of 2. (Used to take about 80 seconds to get 1000 frames saved, now takes roughly 40 seconds).
5)Need to determine the bottleneck on the cameras. It may be the ethernet card, although its possible to connect multiple gigabit cards to single computer (depending on the number of PCI slots it has). Given the ethernet cards are cheap ($300 for 20) compared to even a single camera (~$800-1500), it might be worth while outfitting a computer with multiple. |
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
|
|
441
|
Thu Apr 24 11:50:10 2008 |
josephb | Summary | Computer Scripts / Programs | Useful tidbits learned while tracking the network setup |
In process of understanding the network setup I've learned several things:
1) The status lights on C0DAQ_RFMNETWORK.adl are controlled by the fiber network, as opposed to the ethernet network. However, even if everything is working properly on the VME end, you may still need to reboot it in order to be able to contact it via the ethernet (ssh or telnet).
2) After disconnecting the hub out by 1Y9, I was able to telnet into c1vac1, but not c1vac2. I was told that the Turbo pump and Ion pump readbacks on C0VACMONITOR.adl had not been working for awhile (years?). So I went out and rebooted the c1vac2 card. This seemed to restore the epic channels and we now have correct readbacks on the turbo pumps. The ion pumps all are reading no voltage, which is good because they're turned off. However C1:Vac-IPSE_mon is reading "On", although Steve assures me the actual unit is currently off, so there may be a minor channel issue there. |
449
|
Fri Apr 25 13:53:11 2008 |
josephb | Summary | Computers | Network setup |
This is the promised more in detail summary from Andrey's log ID 444.
What we did was go around to each hub, one at a time, unplug the network connection, and figure out which light on which hub went out. We then, went back to the control room, confirmed that we were still able to talk to the devices connected to the hub, and if not, rebooted them. This process was repeated for each hub.
As it stands, the hubs located at the ends of arms (in racks 1X4 and 1Y9) are connected to the really old 24 port 10 Base T hub located in 1Y7. In addition, the 5 port SMC hub is plugged into the 8 port SMC switch in 1Y5 (which actually has enough ports to simply move all the connections over to it, so I'm not sure why there are two...).
All other hubs/switches are connected back to the control room 24 port switch.
Attached is a simple diagram of the network connections for the 40m lab. |
Attachment 1: 40m_network_90.pdf
|
|
463
|
Thu May 1 12:46:02 2008 |
josephb | Configuration | Computers | Nodus gateway is up |
The computer Nodus is now acting as a gateway machine between the GC network and the martian network in the 40m. It has the same passwords as the rana gateway machine.
Its name on the GC side is nodus (ip: 131.215.115.52) and on the martian side is nodus113 (ip: 131.215.113.200). Will need to update the hosts file on the control room machines so you can just use the name nodus113 rather than the full ip.
Software is still being added to the computer, and it will remain in parallel with the rana gateway machine until everything has been working properly for a week or so. |
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. |
473
|
Fri May 9 10:15:36 2008 |
josephb | Update | Computers | Nodus has moved |
Steve and myself moved Nodus from under the table in the control room, to just above the Rana computer in the control room rack. |
479
|
Thu May 15 12:05:49 2008 |
josephb | Configuration | PSL | Path to PSL Position QPD |
The 50/50 beamsplitter that was being used as the last turning mirror to the PSL Position QPD has been replaced with a Y1-1037-45-S plate. This turning mirror was also moved 4" farther along the beam path, so as to produce as small (few microwatts) transmission through the plate. The lensing optics were also shifted so as to maintain a focused beam on the photodiode. Lastly, the rotating ND filter was increased from 1.5 to 2.0 to reduce the incident power on the photodiode, since twice the power is now reaching it.
The small beam on transmission will be used by the digital cameras as a test beam. |
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. |
492
|
Thu May 22 11:25:19 2008 |
josephb | Configuration | Computers | |
One of the new Netgear Prosafe 24 port switches was mounted in the 1X4 rack,, roughly in the middle, away from the top and bottom rack mounted electronics. At the moment, its IP has been set to 131.215.113.250, gateway 131.215.113.2 (which is what I saw as the only listed gateway on linux1 using route -n) and mask 255.255.255.0.
I'm planning to set the next three IP address for the switches as *.251, *.252 and *.253, which don't look to have been used yet. |
501
|
Wed May 28 12:51:32 2008 |
josephb | Configuration | Computers | Two more switches mounted |
Two more Prosafe 24 port switches have been mounted in the racks, one in 1Y9 and one in 1Y6. (The first one was placed in 1X4).
The one in 1Y9 has been set to an IP address of 131.215.113.251, while the one in 1Y6 is set to 131.215.113.252, and these have been labeled as such. |
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. |
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
|
|
682
|
Wed Jul 16 16:28:14 2008 |
josephb | Configuration | Computers | Fixed IP address on Switch |
Realized today that the change I made back on June 30th to the switch was to the wrong switch. I had disabled the DHCP setting and mislabeled the switch in the control room (which seems to not have affected anything).
I've turned DHCP back on and labeled it correctly using the Netgear "Smartwizard discovery" program. |
777
|
Thu Jul 31 16:11:22 2008 |
josephb | Configuration | Computers | Matlab on Megatron |
Matlab now works on megatron.
I did a few things:
1) Added to the PATH environment variable. Did this in .bash_profile in the /home/controls directory by adding the line
PATH=$PATH:/cvs/cds/caltech/apps/linux64/matlab/bin/
export PATH
This probably should be somewhere else up further up the line, but I was too lazy to figure it out.
2)Fixed a gateway mistake I had added earlier so the megatron could use the NAT router and see the outside world so yum worked.
3) Removed the i386 based libXp and openmotif packages.
4) Installed the x86_64 based libXp and openmotif packages.
Edit: Forgot that I also added the following line to the /etc/fstab file in order to mount the shared code. This was stolen directly from Rosalba's /etc/fstab file. This was so that it could see the matlab code.
linux1:/home/cds/ /cvs/cds nfs rw,bg,soft 0 0 |
779
|
Fri Aug 1 10:45:46 2008 |
josephb | Configuration | Computers | Megatron now running tcsh |
At Rana's request, I've remotely switched Megatron over to using tcsh. I had to ssh -X in order ot use the "/sbin/system-config-users" program which is a graphical UI for modifying users. I had to go to preferences and uncheck hide system users, which then allowed me to see the controls user (at the bottom of the list), and edit it.
I also created a .tcshrc file in the /home/controls directory and copied the information from the .bashrc file, and also moved the matlab path definition into the PATH environment variable.
Does anyone know if sourcing /cvs/cds/caltech/cshrc.40m would be usable on a 64 bit machine, or does a new one need to be made for Megatron and/or Rosalba? |
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
|
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). |
815
|
Fri Aug 8 12:21:57 2008 |
josephb | Configuration | Computers | Switched X end ethernet connections over to new switch |
In 1X4, I've switched the ethernet connections from c1iscex and c1auxex over to the new Prosafe 24 port switches. They also use the new cat6 cables, and are labeled.
At the moment, everything seems to be working as normally as it was before. In addition:
I can telnet into c1auxex (and can do the same to c1auxey which I didn't touch).
I can't telnet into c1iscex (but I couldn't do that before, nor can I telnet into c1iscey either, and I think these are computers which once running don't let you in). |
823
|
Mon Aug 11 12:42:04 2008 |
josephb | Configuration | Computers | Continuing saga of c1susvme1 |
Coming back after lunch around 12:30pm, c1susvme1's status was again red. After switching off watchdogs, a reboot (ssh, su, reboot) and restarting startup.cmd, c1susvme1 is still reporting a max sync value (16384), occassionally dropping down to about 16377. The error light cycles between green and red as well.
At this point, I'm under the impression further reboots are not going to solve the problem.
Currently leaving the watchdogs associated with c1susvme1 off for the moment, at least until I get an idea of how to proceed. |
824
|
Mon Aug 11 13:59:23 2008 |
josephb | Configuration | Computers | |
While poking around the crate, I noticed an error light on one of the c1susvme2 related boards was lit, while the corresponding light on the c1susvme1 was not. This confuses me as the c1susvme1 is the one having problems.
As a quick sanity check, I unplugged the ethernet connection from the c1susvme1 labeled board, and confirmed I couldn't log into it, and then plugged it back in, restarted it, and re-ran the startup script. This time c1susvme1 seemed to come up fine. Re-enabling the watchdogs doesn't seem to kick anything, and in fact seems to be bringing everything into line properly.
Although the error light on the c1susvme2 clk drvr board is still on. So I'm not sure what thats trying to tell us. Open to suggestions. |
825
|
Mon Aug 11 15:07:49 2008 |
josephb | Configuration | Computers | Procyon aka fb40m switched to new switch |
I've connected Procyon to the Prosafe 24 port switch with a new, labeled Cat6 cable. Quick tests with dataviewer shows that its working. |