Fwd: CoolLed and Hamamatsu Orca camera
Locked
Fwd: CoolLed and Hamamatsu Orca camera
 
|
Hello,
I'm imaging a sample with a CoolLed system and have an Hamamatsu Orca-ER firewire camera. As we discussed it before, I'm using a hardware trigger from the LED to the camera to synchronize the acquisition. Unfortunately,I still have some issues with the stability of the signal. For sort (<20 ms) and long exposures (>500 ms) everything is fine. However around 100 ms I see some fluctuations (25%) in the intensity of the signal. I have tried to play a bit with the delay for the CoolLed device. If I see a clear improvement if I set it to 5 or 10 ms but I need 50 ms to eliminate completely all the fluctuations. Since the short exposure acquistions are reliable my impression was that there was a mismatch between the switching off of the LED and the CCD exposure time. Is this possible? My understanding was that the delay would change the time when the CCD is fired compared to the "opening" of the LED, but does it also apply for the switch off phase of the shutter? Best, Serge Serge Pelet ETH-Zurich Institute of Biochemistry CH-8093 Zurich Phone: +41 44 633 44 17 Fax: +41 44 632 12 98 Begin forwarded message:
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
Re: Fwd: CoolLed and Hamamatsu Orca camera
|
Hi Serge,
> I'm imaging a sample with a CoolLed system and have an Hamamatsu > Orca-ER firewire camera. As we discussed it before, I'm using a > hardware trigger from the LED to the camera to synchronize the > acquisition. Unfortunately,I still have some issues with the > stability of the signal. For sort (<20 ms) and long exposures (>500 > ms) everything is fine. However around 100 ms I see some > fluctuations (25%) in the intensity of the signal. I have tried to > play a bit with the delay for the CoolLed device. If I see a clear > improvement if I set it to 5 or 10 ms but I need 50 ms to eliminate > completely all the fluctuations. I think that the logic in your setup is as follows when you do a SnapImage: - Micro-Manager opens the CoolLED shutter - The CoolLED sends a TTL to your camera. - The camera (set in Edge Trigger mode) starts exposing a fixed period after receiving the TTL. This is camera dependent, check your manual for the time delay. For the C9100-13 I have here it is 0.78 msec. - The camera will expose for the exposure time that you have previously set. - In the mean time, Micro-Manager will call the camera function "SnapImage" (after waiting for the delay that you have given to the shutter). - The Hamamatsu Snapimage function in your case will simply wait for the duration of the exposure time. - The camera will start readout of the image once the exposure is done. - Micro-Manager will close the shutter and wait for the image to be delivered by the camera I am not sure how your observations fit into this scheme. When you increase the delay for the shutter, Micro-Manager will first open the shutter and then wait for the delay time before calling SnapImage. The net effect is that the shutter will be open longer, but the timing between shutter and camera should be unaffected (i.e., the camera still starts exposing after a fixed delay after the LED goes on). I am afraid that you would need to hook up an oscilloscope to the TTL coming from the LED, and preferably also to a TTL on the camera that indicates whether the camera is exposing (if your camera has one) to get to the cause of the problem. You would also be helped by hooking up a very fast light probe and display at the same time on the oscilloscope. Not an easy experiment... Best, Nico ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
Re: Fwd: CoolLed and Hamamatsu Orca camera
|
|
Hi Nico,
Thanks for the explanation. > I think that the logic in your setup is as follows when you do a > SnapImage: > - Micro-Manager opens the CoolLED shutter > - The CoolLED sends a TTL to your camera. > - The camera (set in Edge Trigger mode) starts exposing a fixed period > after receiving the TTL. This is camera dependent, check your manual > for the time delay. For the C9100-13 I have here it is 0.78 msec. > - The camera will expose for the exposure time that you have > previously set. > - In the mean time, Micro-Manager will call the camera function > "SnapImage" (after waiting for the delay that you have given to the > shutter). > - The Hamamatsu Snapimage function in your case will simply wait for > the duration of the exposure time. > - The camera will start readout of the image once the exposure is > done. > - Micro-Manager will close the shutter and wait for the image to be > delivered by the camera If I understand correctly, Micro-Manager does not recieve a signal from the CCD saying that the image acquisition is finished before closing the shutter. If this is the case, assuming I set a 0 ms delay for the LED shutter, but the LED has a variable delay which can go up to 30 ms I could close the LED 30 ms before the acuisition of the image is finished by the CCD. This could generate the fluctuations I observe in the images. I don't understand why the switching of the LED is so slow and variable. I think you mentionned that in one of your previous post that it is inherent to the way you talk to the LED. One solution I can see would be to use a TTL from the parallel port to activate the LED. Do you think the temporal resolution would be increased? Best regards, Serge ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
Re: Fwd: CoolLed and Hamamatsu Orca camera
|
Hi Serge,
I can answer those. The LED delays via USB or TCP are due to a 10ms granularity in processing within the pE. We are considering ways to improve that, but it will likely never get very fast due to the way we have to handle the comms. USB is probably slightly slower than TCP as unfortunately we have to poll the USB chip and can't use an IRQ. The TTL inputs work in the tens of microseconds region. The sync output also goes high during every On and responds within a few microseconds, so could be used for slaving. Kind regards, Gordon. -- Gordon Scott Design Engineering Custom Interconnect Ltd. http://www.cil-uk.co.uk CoolLED http://www.coolled.com Phone +44-1264-321321 CIL House, Charlton Road, Andover SP10 3JL, UK > -----Original Message----- > From: Serge Pelet [mailto:[hidden email]] > Sent: 15 September 2009 15:16 > To: Micro-Manager General > Subject: Re: [micro-manager-general] Fwd: CoolLed and > Hamamatsu Orca camera > > Hi Nico, > Thanks for the explanation. > > > I think that the logic in your setup is as follows when you do a > > SnapImage: > > - Micro-Manager opens the CoolLED shutter > > - The CoolLED sends a TTL to your camera. > > - The camera (set in Edge Trigger mode) starts exposing a > fixed period > > after receiving the TTL. This is camera dependent, check > your manual > > for the time delay. For the C9100-13 I have here it is 0.78 msec. > > - The camera will expose for the exposure time that you have > > previously set. > > - In the mean time, Micro-Manager will call the camera function > > "SnapImage" (after waiting for the delay that you have given to the > > shutter). > > - The Hamamatsu Snapimage function in your case will simply wait for > > the duration of the exposure time. > > - The camera will start readout of the image once the exposure is > > done. > > - Micro-Manager will close the shutter and wait for the image to be > > delivered by the camera > > If I understand correctly, Micro-Manager does not recieve a signal > from the CCD saying that the image acquisition is finished before > closing the shutter. If this is the case, assuming I set a 0 > ms delay > for the LED shutter, but the LED has a variable delay which > can go up > to 30 ms I could close the LED 30 ms before the acuisition of the > image is finished by the CCD. This could generate the fluctuations I > observe in the images. > > I don't understand why the switching of the LED is so slow and > variable. I think you mentionned that in one of your previous post > that it is inherent to the way you talk to the LED. One > solution I can > see would be to use a TTL from the parallel port to activate > the LED. > Do you think the temporal resolution would be increased? > > Best regards, > Serge > > > -------------------------------------------------------------- > ---------------- > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. > Jumpstart your > developing skills, take BlackBerry mobile applications to > market and stay > ahead of the curve. Join us from November 9-12, 2009. > Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > micro-manager-general mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/micro-manager-general > > > > > This message has been scanned by MailController - > www.MailController.altohiway.com > This message has been scanned by MailController - www.MailController.altohiway.com This message and any attachments are strictly confidential and intended solely for the addressee. Any unauthorized use or disclosure, in whole or in part, is prohibited. E-mails are subject to possible alteration. Custom Interconnect Ltd and the sender decline any liability if this message and/or any attachments have been altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender immediately. Custom Interconnect Limited is a limited company registered in England and Wales. Registered number: 2026753. Registered office: CIL House 48 Charlton road Andover, Hampshire United Kingdom SP103JL. ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
Re: Fwd: CoolLed and Hamamatsu Orca camera
|
|
Hi Gordon,
Thanks for your answer. I made a few unsuccessfull preliminary tests with the TTL triggering of the CoolLED. So maybe you can answer a few quick questions. I'm planning to use the USB port to set the active channel and the intensity of the LED and the parallel port of the computer to generate the TTL signal. Is that actually possible or do I have to use only a single communication interface (USB vs. TTL)? Can I send only the TTL triggering signal between pin 9 and 2 or do I also need to define wich LED should be turned on with pins 10-13? Best, Serge Serge Pelet ETH-Zurich Institute of Biochemistry CH-8093 Zurich Phone: +41 44 633 44 17 Fax: +41 44 632 12 98 On 15 sept. 09, at 16:27, Gordon Scott wrote:
------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
Re: Fwd: CoolLed and Hamamatsu Orca camera
|
|
Hi Serge,
The TTL On/Off lines, USB and TCP should all coexist reasonable sanely. TTL takes On/Off precedence, but level adjustments and so on should work just fine. The TTL Trigger input can be a little different. The Pod controls are disabled because it's unrealistic for us to keep them closely enough synchronised that the user can be sure they're controlling the right thing. I'm still not wholly sure that's the right strategy, but it seemed reasonably sensible when we did it. There can sometimes be some confusion within the pE software as the Trigger input and TTL On/Off inputs have to share a single IRQ pin on the CPU. The behaviour of the pE is dependent on the software making the right understanding of the five input lines. If you have funny behaviour, please describe it and I'll try to work out what's going on. Kind regards, Gordon. -- Gordon Scott Design Engineering Custom Interconnect Ltd. http://www.cil-uk.co.uk CoolLED http://www.coolled.com Phone +44-1264-321321 CIL House, Charlton Road, Andover SP10 3JL, UK > -----Original Message----- > From: Serge Pelet [mailto:[hidden email]] > Sent: 21 September 2009 10:21 > To: Micro-Manager General > Subject: Re: [micro-manager-general] Fwd: CoolLed and > Hamamatsu Orca camera > > Hi Gordon, > Thanks for your answer. I made a few unsuccessfull > preliminary tests with the TTL triggering of the CoolLED. So > maybe you can answer a few quick questions. I'm planning to > use the USB port to set the active channel and the intensity > of the LED and the parallel port of the computer to generate > the TTL signal. Is that actually possible or do I have to use > only a single communication interface (USB vs. TTL)? Can I > send only the TTL triggering signal between pin 9 and 2 or do > I also need to define wich LED should be turned on with pins 10-13? > Best, > Serge > > > > Serge Pelet > ETH-Zurich > Institute of Biochemistry > Schafmattstr. 18 HPM G7 > CH-8093 Zurich > > [hidden email] > Phone: +41 44 633 44 17 > Fax: +41 44 632 12 98 > > > > On 15 sept. 09, at 16:27, Gordon Scott wrote: > > > Hi Serge, > > I can answer those. > > The LED delays via USB or TCP are due to a 10ms granularity in > processing within the pE. We are considering ways to > improve that, but > it will likely never get very fast due to the way we > have to handle the > comms. USB is probably slightly slower than TCP as > unfortunately we have > to poll the USB chip and can't use an IRQ. > > The TTL inputs work in the tens of microseconds region. > The sync output > also goes high during every On and responds within a > few microseconds, > so could be used for slaving. > > Kind regards, > Gordon. > -- > Gordon Scott Design Engineering > Custom Interconnect Ltd. http://www.cil-uk.co.uk > CoolLED http://www.coolled.com > Phone +44-1264-321321 > CIL House, Charlton Road, Andover SP10 3JL, UK > > > > > > -----Original Message----- > > > From: Serge Pelet [mailto:[hidden email]] > > > Sent: 15 September 2009 15:16 > > > To: Micro-Manager General > > > Subject: Re: [micro-manager-general] Fwd: CoolLed and > > > Hamamatsu Orca camera > > > > Hi Nico, > > > Thanks for the explanation. > > > > I think that the logic in your setup is > as follows when you do a > > > SnapImage: > > > - Micro-Manager opens the CoolLED shutter > > > - The CoolLED sends a TTL to your camera. > > > - The camera (set in Edge Trigger mode) > starts exposing a > > > fixed period > > > after receiving the TTL. This is > camera dependent, check > > > your manual > > > for the time delay. For the C9100-13 I > have here it is 0.78 msec. > > > - The camera will expose for the > exposure time that you have > > > previously set. > > > - In the mean time, Micro-Manager will > call the camera function > > > "SnapImage" (after waiting for the > delay that you have given to the > > > shutter). > > > - The Hamamatsu Snapimage function in > your case will simply wait for > > > the duration of the exposure time. > > > - The camera will start readout of the > image once the exposure is > > > done. > > > - Micro-Manager will close the shutter > and wait for the image to be > > > delivered by the camera > > > > If I understand correctly, Micro-Manager does > not recieve a signal > > > from the CCD saying that the image acquisition > is finished before > > > closing the shutter. If this is the case, > assuming I set a 0 > > > ms delay > > > for the LED shutter, but the LED has a variable > delay which > > > can go up > > > to 30 ms I could close the LED 30 ms before the > acuisition of the > > > image is finished by the CCD. This could > generate the fluctuations I > > > observe in the images. > > > > I don't understand why the switching of the LED > is so slow and > > > variable. I think you mentionned that in one of > your previous post > > > that it is inherent to the way you talk to the LED. One > > > solution I can > > > see would be to use a TTL from the parallel > port to activate > > > the LED. > > > Do you think the temporal resolution would be increased? > > > > Best regards, > > > Serge > > > > > > -------------------------------------------------------------- > > > ---------------- > > > Come build with us! The BlackBerry® > Developer Conference in SF, CA > > > is the only developer event you need to attend > this year. > > > Jumpstart your > > > developing skills, take BlackBerry mobile > applications to > > > market and stay > > > ahead of the curve. Join us from November > 9-12, 2009. > > > Register now! > > > http://p.sf.net/sfu/devconf > > > _______________________________________________ > > > micro-manager-general mailing list > > > [hidden email] > > > > https://lists.sourceforge.net/lists/listinfo/micro-manager-general > > > > > > > This message has been scanned by MailController - > > > www.MailController.altohiway.com > > > > > > This message has been scanned by MailController - > www.MailController.altohiway.com > > This message and any attachments are strictly > confidential and intended solely for the addressee. Any > unauthorized use or disclosure, in whole or in part, is > prohibited. E-mails are subject to possible alteration. > Custom Interconnect Ltd and the sender decline any liability > if this message and/or any attachments have been altered, > changed or falsified. If you are not the intended recipient > of this message, please delete it and notify the sender immediately. > > Custom Interconnect Limited is a limited company > registered in England and Wales. Registered number: 2026753. > Registered office: CIL House 48 Charlton road Andover, > Hampshire United Kingdom SP103JL. > > > -------------------------------------------------------------- > ---------------- > Come build with us! The BlackBerry® Developer > Conference in SF, CA > is the only developer event you need to attend this > year. Jumpstart your > developing skills, take BlackBerry mobile applications > to market and stay > ahead of the curve. Join us from November 9-12, > 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > micro-manager-general mailing list > [hidden email] > > https://lists.sourceforge.net/lists/listinfo/micro-manager-general > > > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ micro-manager-general mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/micro-manager-general |
«
Return to Micro-Manager
|
1 view|%1 views
Loading...
| Powered by Nabble | See how NAML generates this page |
