16
Software Dev / Re: Chronos Cam App open source build discussion
« on: November 21, 2017, 01:43:13 AM »
Great news! I have S/N 34 so will wait for the USB/ETH fix before I dive in.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: 1 [2]
17
Software Dev / Re: raw video data
« on: September 26, 2017, 05:17:54 AM »
The buffered and slowly downloaded is expected and exactly what I am looking for.
Some kind of API over ETH to control the camera would be great as well.
In my case I need to start/stop recording continuously. It's only in some rare cases that I want the raw video.
The way it works now were I have to press the "OK" button on the "unsaved warning" for every start makes sense for most I guess but it's very annoying for my use case.
Hopefully that will be doable over the ETH as well.
Some kind of API over ETH to control the camera would be great as well.
In my case I need to start/stop recording continuously. It's only in some rare cases that I want the raw video.
The way it works now were I have to press the "OK" button on the "unsaved warning" for every start makes sense for most I guess but it's very annoying for my use case.
Hopefully that will be doable over the ETH as well.
18
Software Dev / raw video data
« on: August 31, 2017, 06:10:47 AM »
Now that the reminder of the Kickstarter cameras are shipped. Do you have an approximate estimate when we will be able to retrieve raw data from the camera? Not via SD card but some connection to a PC. Preferably Ethernet.
If the SDK is released I don't mind writing the function myself. Any rough estimate on the SDK? No commitment expected but an indication like 3, 6 or 18 months?
If the SDK is released I don't mind writing the function myself. Any rough estimate on the SDK? No commitment expected but an indication like 3, 6 or 18 months?
19
Chronos User Discussion / Re: external high speed trigg
« on: July 17, 2017, 12:46:07 PM »
Thanks!
20
Chronos User Discussion / external high speed trigg
« on: July 16, 2017, 02:31:01 AM »
Hi,
Juts wanted to check if this use case is possible now or if it could be with a new firmware update?
(e.g. the hardware could do it but it's currently not supported)
I want to feed the exposure signal externally. The frame rate will be lower than the max frame rate for that resolution.
If the exposure duration is taken from the signal or set in the menu is not important. Both will work.
If there is a delay between the ext. trig signal and the actual sensor exposure. I would need a signal out from the camera to drive a synchronized flash.
Alternatively and even better. The delay is fixed and can be calculated upfront for any given setting.
The background is this.
I have designed a Xenon flash that I can control in many different ways with a built in MCU. I would like to take a sequence of images (20 or so at 2k fps) with an exposure time of 6us.
I can't drive the Xenon flash continuously. It can withstand 20 flashes or so but needs to cool down before the next sequence.
I also have a LED based flash for the same purpose. To produce the same amount of light the LED flash needs to be much bigger. Since I am driving it very hard it also has a similar limitation of 40 or so flashes in sequence before it needs to be cooled down.
Juts wanted to check if this use case is possible now or if it could be with a new firmware update?
(e.g. the hardware could do it but it's currently not supported)
I want to feed the exposure signal externally. The frame rate will be lower than the max frame rate for that resolution.
If the exposure duration is taken from the signal or set in the menu is not important. Both will work.
If there is a delay between the ext. trig signal and the actual sensor exposure. I would need a signal out from the camera to drive a synchronized flash.
Alternatively and even better. The delay is fixed and can be calculated upfront for any given setting.
The background is this.
I have designed a Xenon flash that I can control in many different ways with a built in MCU. I would like to take a sequence of images (20 or so at 2k fps) with an exposure time of 6us.
I can't drive the Xenon flash continuously. It can withstand 20 flashes or so but needs to cool down before the next sequence.
I also have a LED based flash for the same purpose. To produce the same amount of light the LED flash needs to be much bigger. Since I am driving it very hard it also has a similar limitation of 40 or so flashes in sequence before it needs to be cooled down.
Pages: 1 [2]