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 - tesla500

Pages: [1] 2 3 ... 9
1
We're focusing on remote Etherent control right now, HDMI will be priority after that is done. Hoping to have the remote API done around the end of this month or so.

2
Software Dev / Re: Software V0.3 Beta - Updated Jan 4 2018
« on: January 17, 2018, 08:47:28 PM »
Did some more fiddling with the the segmented memory mode and still had no luck. For the sake of having a small video file I set the record frame-rate to 30fps, set the "Record Lenght" to 300 frames and set 2 segments of 150 frames each. I filmed at timer and pressed the external trigger at 10s and 20s then stopped the recording at 30s. I added frame numbers to the result and made the following gif.

...

The recording ended up only being 157 frame long and contained mostly the video that occurred after the second external shutter press. Some of the jumpiness can also be seen. Any idea?

Apologies, segmented memory is implemented in a slightly counter intuitive way. Segmented memory is basically a ring buffer of segments, each segment being a ring buffer of frames. The camera continuously records into the current segment, overwriting any old frames. So, if you set it to two segments and cause two triggers, you've filled all the memory, but because the segments are a ring buffer themselves, the earliest segment is overwritten, awaiting a new trigger, which in this case never comes because you stopped recording. Therefore, your earliest segment in RAM (frames 1-150) is the second trigger (the one you did at 20s), and frames 151-300 (or possibly fewer frames) are whatever happened just before you stopped recording.

There was going to be a "disable ring buffer" mode in this release, which would terminate record automatically after your second trigger, avoiding the above problem. There's a bug present in the FPGA right now that prevents the required record termination at end of memory from working, that's on the todo to fix but we're just starting up production on the next batch so it will be a week or two until I can get around to it.

As a workaround, always select one more segment than needed.

3
Chronos User Discussion / Re: 2nd battery
« on: January 14, 2018, 11:38:55 PM »
I have ordered two of these:
https://www.amazon.de/gp/aw/d/B015FXR6EY/ref=yo_ii_img?ie=UTF8&psc=1

Look for batteries that have a gloss finish case,

Look for batteries with a connector portion that is lighter grey rather than black. There seems to be two different versions that you'll find (apart from the very expensive legitimate Nikon ones), a good one is shown here, and the bad one is shown here. Notice how the connector is grey on the former, look for that when buying batteries. It seems there are two Chinese factories making these, one much better than the other.

We got two batteries in for testing that are of the type Fyodor ordered, and found the same thing, they are tight, the connector is poor quality, they don't meet their capacity specs, and the cells physically rattled around inside the case. The other type are much better quality.


4
Software Dev / Re: Very ugly artifacts after upgrade to 0.2.5
« on: January 05, 2018, 04:06:02 PM »
It would be a good idea to try reflashing the SD card first to see if that fixes the problem, follow the procedure on the software updates page under "Restoring a camera that won't boot". Make sure to back up your calibration data before starting, and don't do step 16.

Let us know if that fixes it.

5
Software Dev / Re: Very ugly artifacts after upgrade to 0.2.5
« on: January 05, 2018, 04:17:47 AM »
I agree, that appears to be unrelated to the software update and is likely a hardware issue. That's covered under warranty, contact info@krontech.ca and we'll get that fixed for you.

6
Software Dev / Re: Very ugly artifacts after upgrade to 0.2.5
« on: January 05, 2018, 03:41:39 AM »
Did you try V0.2.3 previously, and if so, did it work fine? ie. is this a new bug introduced between 0.2.3 and 0.2.5?

7
Software Dev / Re: Software V0.3 Beta
« on: January 04, 2018, 05:06:04 PM »
V0.2.5 Beta posted, see the first post.

8
Chronos User Discussion / Re: external battery charger?
« on: January 02, 2018, 11:51:11 AM »
There are many on Aliexpress, just search "EN-EL4A charger"

One like this should work, but as always with low-cost Chinese products, I would suggest finding your own AC adapter that's known to be safe.


9
Chronos User Discussion / Re: Chronos 1.4 Footage Thread
« on: January 01, 2018, 11:39:31 PM »
I have wanted to get a clip that would be along the lines of the one Taofledermaus has on the main page that would be suitable to potentially use as an example of what the camera is capable of on the main page.



I think I might have done so with this one of my Taurus 445, 44 Special.



If someone is better at making GIF files, I can provide the raw video.

Oh nice! If you have the original file, that would be great.

10
Chronos User Discussion / Re: Chronos 1.4 Footage Thread
« on: January 01, 2018, 11:34:54 PM »
Looking at a Phonograph stylus under a microscope lens, and a discussion on the challenges of getting these shots:

https://www.youtube.com/watch?v=mYE67fVny4c

11
Software Dev / Re: Software V0.3 Beta
« on: January 01, 2018, 11:20:30 PM »
We've experienced the same issue over the Christmas break, with the camera saying there's no free space when there clearly is enough. We'll be fixing that first thing when we go back to work tomorrow. I'll post here when we have a fix.

12
Chronos User Discussion / Re: How to achieve fastest save times.
« on: January 01, 2018, 05:00:23 AM »
Will the USB speed increase as well as eSATA?

Somewhat, but not as much as SATA. It would max out around the same speed as you get from your PC to the drive, perhaps 30-40MB/s

13
Chronos User Discussion / Re: How to achieve fastest save times.
« on: December 28, 2017, 12:39:35 PM »
You're correct, on 0.2.3 beta you'll get about 35MB/s max. This is limited by code provided by the CPU vendor TI, we'll be working on speeding it up, but Etherent is priority right now for development. It should be possible to get much faster save speeds, perhaps up to 200-250MB/s over eSATA, once things are optimized.

14
Software Dev / Re: Chronos Cam App open source build discussion
« on: December 27, 2017, 09:58:17 PM »
Code deep dive is up next. Need to figure out how to grab the preview video data and push that via Ethernet so I can view it on a PC and control the camera from there.

Once it's working I will be happy to show what I have and share if anybody is interested.   

We're also working on this, in fact pretty much all our effort now is devoted to getting Ethernet remote control and video download working. It's a very nontrivial task to just get the video into a RAM buffer, which is one of the reasons why it's taking so long.

The video system is built on a framework called OpenMax (OMX). Most of OMX is run internally by a separate M3 core in the CPU. This runs a binary blob provided by TI, the source is available from TI under an NDA, ask for the "DM8148 EZSDK Overlay Package". This handles pretty much everything related to video input, processing, and output to the display. There's another M3 running a different binary blob which operates the H264 encoder. We've modified the former M3 code somewhat to add features like the video save throttling.

In the camApp, OMX is used directly for live display, and saving is done using gstreamer. Internally, gstreamer uses OMX as OMX is the only way to do anything with the hardware accelerated video pipeline. There is currently a problem with the gstreamer component that allows you to get frames into a RAM buffer, foobar or Loial could comment further, but we believe that the component that provides RAM buffers doesn't properly handle shutting down the pipeline, which crashes the M3. This issue needs to be solved before we can get RAW saving over Etherent working.

gstreamer currently supports streaming compressed video via RTSP, if you just want live display that should be significantly easier than getting RAW.

Take a look at videoRecord.c to see how the gstreamer pipeline is set up. There's also a way to run gstreamer pipelines from the command line, Loial has some examples of doing this.

15
Software Dev / Re: Chronos Cam App open source build discussion
« on: December 27, 2017, 03:37:07 PM »
Try removing the Check for Free Space before deployment, I recall that not working. See screenshot of my Run configuration, see if yours is the same.

Pages: [1] 2 3 ... 9