Hello everyone,
I am building a linear scanning raman system based on the open raman platform (breadboard edition), where the sample is moved in between each measurement. This would also be suitable for an automatisation of raman sampling where a robot swap sample after each acquisition.
We previously discussed activating the capture via gpio from the camera, this was not practical, however a simple arduino keyboard emulator can send a f5 command and trigger acquisition this way.
It work great!
I am now wondering if it would be possible to activate the gpio in output, exposure active mode?
This would be useful as I could set the controller to wait for the end of the exposure to trigger a mouvement of the sample and a new acquisition.
This way the exposure length wouldn't need to be synchronized in between the software and the microcontroller in charge of moving the sample.
I had a look through the open source code to no avail.
Is anyone familiar with the code could tell me if this is feasible and how to proceed?
GPIO output
Re: GPIO output
Before writing any code you could prototype the system using the camera manufacturer software to record batches of images (using the triggering to delay acquisition) and use our Matlab script to convert the images into spectra (or spectral cube/image).
That's the *lean* way of doing
it's the best approach I can recommend!
That's the *lean* way of doing
it's the best approach I can recommend!Re: GPIO output
Hi Luc,
I did consider this already, I am sure it would work.
However I need to make my system idiot proof if possible, the simpler the better as it is part of a bigger system which might be used by non scientist.
The spectrum analyser software look like a nice platform for this.
An other option is to have a timer on the machine side to dial in the exposure length (including multiple exposure averaging). this would also work and be fairly straight forward.
But if it is at ll possible It would be great to have this functionality activated by default, as I doubt it would interfere with any of the other process.
I am not a programer, so my understanding of c++ is very limited, but I imagine a command is send to erase previous configuration and then a new one is uploaded right?
could you pinpoint where it happen or at the very least on which script it happen?
Perhaps I can try my luck at editing it or at least get some insight on to this interface.
I did consider this already, I am sure it would work.
However I need to make my system idiot proof if possible, the simpler the better as it is part of a bigger system which might be used by non scientist.
The spectrum analyser software look like a nice platform for this.
An other option is to have a timer on the machine side to dial in the exposure length (including multiple exposure averaging). this would also work and be fairly straight forward.
But if it is at ll possible It would be great to have this functionality activated by default, as I doubt it would interfere with any of the other process.
I am not a programer, so my understanding of c++ is very limited, but I imagine a command is send to erase previous configuration and then a new one is uploaded right?
could you pinpoint where it happen or at the very least on which script it happen?
Perhaps I can try my luck at editing it or at least get some insight on to this interface.
Re: GPIO output
I'd say you need to turn the single acquisition button into a toggle button (like the live view button) and run the acquisition in loop as long as the button is pressed.
The camera bridge library must also be modified to change the software trigger to external trigger.
Beware to stop the acquisition before you run out of trigger pulses or the program will stay stuck waiting indefinitely for an acquisition!
The camera bridge library must also be modified to change the software trigger to external trigger.
Beware to stop the acquisition before you run out of trigger pulses or the program will stay stuck waiting indefinitely for an acquisition!
Re: GPIO output
Hi Luc,
Activating input trigger via gpio could also be useful to some peoples, but I am happy with the keyboard emulator solution.. it work.
My understanding is that the exposure active gpio output is a function of the camera.
Once enabled, it simply provide a "high" on line 1 gpio 4 (once it's hooked up with external resistor and bias voltage)as long as the exposure is taking place, then a "low" when the exposure is finished..
That's how it work when I use the camera with other app, so long that it was configured this way in spinview.but when I switch to spectrum analyser, the setting is gone..
I imagine the camera library must contain the instruction set to set the gpio in output exposure active mode. if it's the case I suppose it's just about placing a line of code at the right place to configure the camera for this fonction.
Then the "robot" can listen to this pin and know when the acquisition is finished, move the sample and send a F5 command to trigger the next acquisition.
The only problem I foresee is that it wouldn't work like this with averaging through multiple exposure, I would have to add a binary encoder input on the robot side to tell it how many iteration I it need to wait before moving the sample, But that's not very difficult.
Assuming I find which command to send to the camera, where in the code shall I place it?
Activating input trigger via gpio could also be useful to some peoples, but I am happy with the keyboard emulator solution.. it work.
My understanding is that the exposure active gpio output is a function of the camera.
Once enabled, it simply provide a "high" on line 1 gpio 4 (once it's hooked up with external resistor and bias voltage)as long as the exposure is taking place, then a "low" when the exposure is finished..
That's how it work when I use the camera with other app, so long that it was configured this way in spinview.but when I switch to spectrum analyser, the setting is gone..
I imagine the camera library must contain the instruction set to set the gpio in output exposure active mode. if it's the case I suppose it's just about placing a line of code at the right place to configure the camera for this fonction.
Then the "robot" can listen to this pin and know when the acquisition is finished, move the sample and send a F5 command to trigger the next acquisition.
The only problem I foresee is that it wouldn't work like this with averaging through multiple exposure, I would have to add a binary encoder input on the robot side to tell it how many iteration I it need to wait before moving the sample, But that's not very difficult.
Assuming I find which command to send to the camera, where in the code shall I place it?