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.

Messages - schoenitz

Pages: [1]
Chronos User Discussion / timing of external trigger
« on: September 06, 2023, 08:16:42 AM »

I'm seeing an unexpected delay when triggering externally via the BNC connector. In a test I'm recording a LED that flashes at 150 Hz for 100 ms. When it stops, I supply a trigger signal. This timing is more or less exact, I checked this with an oscilloscope.

Here's the signal I'm sending (the time axis is in expected camera frames):

The camera is set to record 2000 frames at 8245 fps. However, it doesn't seem to trigger at the time of the trigger signal but ~44 ms (~360 frames) later. The trigger timing in the camera is set to default - all 2000 frames are pre-trigger, and there are no post-trigger frames.

Here's what the camera is actually recording:

Is this expected? What to do about it? What I actually want to do is record 500 frames, and there I can't really tolerate a 360 frame mismatch.


Are you aware / have you read that discussion over there?:
 Would something like that Solution we talked about there work? Meaning Capturing a lot of very short Clips all the Time instead of a very long continous one...?

Interesting read, thanks for pointing it out. Will have to think about how to process more but shorter videos.

Hey thanks for taking a look. I figured that the color matrix wasn't going to be helpful because the video still stores RGB.

If it would be Possible to save Monochrome Files from a Color Camera, that would have probably need to be done on Firmware Level, tricking the Camera into thinking it has A Monochrome Sensor instead of Color.
 Try to Contact Krontech Regards that, best to get into Contact with them about Stuff like that is usually to just Call them from my Experience.

Will do that, thanks. I expected that it would have to do with the firmware.
Best way to Reduce Filesize for H.264 is in my opinion to reduce the Bit per Pixel Setting. Lowest possible setting is 0.50 Bits Per Pixel, and Should Cut The Size of the Resulting File more than in Half. How much that however affects the Time Needed to save / Transfer the File via The Network on the Camera, I dont know if the Encoder itself is the Bottleneck here, or the Network Speed; you would need to have to test that for your self.

That's a good suggestion. Maybe we have enough signal to reduce the bit depth, will try a few settings.
Regards Reducing The Time for your whole Workflow, i dont know if i quite understand what you are doing / Trying to do with the Camera, but would it be an Option to Capture the HDMI Output of the Camera, to use for Long-Term Analysis, and just Actually Save the Highspeed whenever something Important Happens? Could speed up things way more than any Improvements in Save Speed just from Settings or Changing Media you save to...?

We're already capturing the low fps output via the web interface for long term monitoring, and it works pretty well. The most interesting property of our object though is a resonance frequency of several 100s Hz, so a 60 fps signal won't capture that.

We have a Chronos 1.4 camera, connected to a SMB share. As of now, saving an entire video file (H.264) takes close to 10 minutes. Saving to a SD card is not faster, and adds the overhead of then transferring the file. Saving in other formats (TIFF, DNG) is much slower.

I'm imagining that if the video encoding would produce monochrome data, the file could be considerably smaller, and saving would be faster. Does this make sense? Is it possible to do? I think one could change the color matrix to effectively produce monochrome output, but as long as the video format carries RGB, the file size would not be affected.

The context is that we're watching an object and would like to make decisions based on a video recording while the object exists. The object exists for maybe up to 20 min, sometimes much less.  Right now we can act on the video information once every 10+ minutes (not even counting the time needed to evaluate the video).  It'd be great if this time could be cut in half , or shortened even more.

Pages: [1]