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

Pages: [1] 2
Chronos User Discussion / Re: Filename time stamp question
« on: May 09, 2019, 08:03:13 PM »
The automatic filename is the time at which the recording was saved to storage medium.

Chronos User Discussion / Re: Chronos 1.4 screen upgrade?
« on: April 16, 2019, 05:50:36 PM »
Our initial tests have shown that the backlight on the new LCD does consume a bit more power than the older unit, but I would expect the difference in runtime to be very small. It's the FPGA and CPU that consumes the lion's share of the power budget. If I had to take a guess, it might reduce your battery life by about 5 minutes or so from a full charge.

Chronos User Discussion / Re: Chronos 1.4 screen upgrade?
« on: April 12, 2019, 01:00:50 PM »
The screen and rear bezel that will be used on the Chronos2.1 can be swapped onto a Chronos1.4 as a drop-in replacement. I don't have any idea of what the pricing for such an upgrade would be.

Chronos User Discussion / Re: Problem saving No storage device found
« on: March 31, 2019, 03:57:43 PM »
You can also try saving the footage to a USB drive as long as it's formatted as FAT32 or Ext2/3, that might provide you with another mechanism to save the footage if something has gone awry with the SD card slot. To know more about why the SD card was not being detected correctly, we would have log into the camera via to SSH (using the micro-USB port) and check into what the kernel thinks of the SD card. If you can manually mount the SD card using the Linux mount command then the UI should still be able to save footage to it.

If you're on one of the 0.3.1 software releases, and you have SSH access to the camera, then you can also use the /opt/camera/cam-recover tool to extract footage from a camera isn't able to save via the normal method (be warned that this option is quite slow).

Awesome, I'm glad to hear that the camera worked out well for you.

- We were shooting with natural light (large outdoor scenes) with many parts of the field of view not being well lit, especially later in the evening.   This resulted in pronounced vertical sensor banding.   I was unable to get rid of the banding despite numerous and frequent black calibrations.   Black cals were done at power-up and at regular intervals throughout the day, but they did not have a noticeable effect on the image.   Topaz denoise worked well for the most part to correct for this in post, though some shots were unsalvageable.

We have spent a bunch of time recently looking over and revising the calibration procedures on the camera lately and we will be rolling out some changes during the transition to Debian that will hopefully improve the vertical banding issue. The cause of the vertical banding is that the ADC calibration of the sensor is temperature-dependent, and as the temperature of the camera drifts away from what it was calibrated at the gain of the ADC channels become slightly mismatched.

- The most difficult part of the workflow was focusing.  The edge highlight function is not reliable enough to depend on in production.  I ended up using trial and error, importing the video to a computer each time to check the focus, then marking the focus ring on the lens when I got it right.  The screen has a lot of noise in lower light, making focusing in those conditions, even using an external monitor, next to impossible.   I also had weird depth of field issues I'd never seen before.   At infinity, with the foreground all the way to objects about a mile distant in focus, the most distant objects were noticeably out of focus (including clouds in the sky and a city skyline backdrop).   I could not fix this problem.   It may be with my lens or possibly a backfocus problem, but I'm not really sure.  Anyone have any ideas?
This does sound like the backfocus has been set incorrectly on your camera and/or lens, and is preventing you from being able to reach infinity focus. If you loosen the set screw on the bottom of the camera you can rotate the CS ring to adjust the backfocus of the camera.

A big request for future firmware would be the ability to pinch and zoom on the screen to enlarge objects to make focusing a little easier, plus maybe a "temporary max exposure" button to brighten the image temporarily for focusing purposes without resetting the resolution/framerate. 
I'd love to see this get implemented too, but it's been on my feature wishlist for a while and unfortunately I just haven't had much time to work on it. As an interim solution, some of our users have recommended setting the image sensor to  a smaller resolution, but leaving the expousre and framerate the same, this will effectively crop the sensor down a smaller area and making it a lot easier to get your focus set right. Once focus is set, you can then switch back to 720p for the real shot. It's a bit of a bandaid, but it does help.

Software Dev / Re: Saved file's owner/group/permissions.
« on: March 18, 2019, 05:07:15 PM »
Hey Nick,

We also ran into this issue a short while ago and we already have a fix for it in our development builds, the underlying problem is that the directories for DNG and TIFF recordings were created without execute permission, which prevents anyone from being able to browse the directories even though they may have read permission on the contents. To repair a directory that was saved with this bug, you can simply use the chmod tool to add the execute bit to the directory (eg: chmod +x directoryname) at which point you should be able to browse its contents.

If you would like to apply a slightly more permanent fix to your camera, you can grab the latest and greatest development builds from our chronos-updates repository and follow the README to build a release package that can be applied to your camera. This particular issue affects the /opt/camera/cam-pipeline program, so you can also apply the update by overwriting that particular file on your SD card with one downloaded from our github.

Note that files will still be created with the UID and GID of the root user, meaning that you will need root permissions to modify them once moving the disk to another PC for viewing, but all users should be able to browse and open the files.

Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9
« on: February 12, 2019, 10:03:10 AM »
Hey Dan,

This is a known issue with the beta-9 release, we recommend that you try out the release candidate software instead (see this thread). If that doesn't work, please let us know if there are issues with the 0.3.1-rc1 update.

Just rolled my camera back to software 0.3.1 beta4 and the Frame Sync Out works again. Can confirm this is definitely a firmware bug and not a hardware issue.

I'm trying out the 0.3.1 Beta-9 software and I've found a major bug. Since I updated, I can't choose any IO mode other than "Record End Trigger". If I select "Frame Sync Output", "Shutter Gating" or "Exposure Trigger" modes for either IO1 or IO2 and press "OK", the UI immediately reverts to "None"

Chronos User Discussion / Re: Fixing corrupt files
« on: January 04, 2019, 03:43:47 PM »
After testing things out a bit, it looks like there is a bug in h.264 file saving that will lead to a crash and file corruption if the MP4 file gets longer than 2GB. This should only be possible when saving very long recordings at very high bitrates, and it should only affect h.264 files. To work around the problem, make sure that the number of frames being saved, divided by the framerate and multiplied by the h.264 bitrate is below 2GB in size.

For example, if you wanted to save 18000 frames at 60fps using the maximum bitrate of 60Mbps would give 18000 frames / 60 fps * 60Mbps = 18Gbits = 2.25GB and would cause the crash to occur.

However, reducing the bitrate to 50Mbps would be fine: 18000 frames / 60fps * 50Mbps = 15Mbit = 1.875GB, and would save without issue.

Chronos User Discussion / Re: Workflow - Time
« on: January 03, 2019, 05:15:24 PM »
Thanks Martin for the excellent post.  Just to share a couple technical details on the Camera's software, It's based on the TI Davinci DM8148 processor, and all of the storage needs to go through that CPU in order to get saved to media. On the storage end of things it supports 3Gbps SATA, SDHC, and, in the future, Gigabit Ethernet.

The maximum theoretical throughput via SDHC should be 25MB/s but in practice that is limited by the performance of your SD cards (the newer UHS standards are not supported by this CPU, but will operate at reduced speeds). SDXC cards can be made to work in the camera, but will probably need to be reformatted as FAT32 or EXT2/3/4 to work with the camera due to the lack of exFAT support on Linux.

The eSATA port is currently the fastest method for saving data, and despite the 3Gbps link, it is limited by the ability of the CPU to update the filesystem, and will hit 100% CPU utilization at around 60MB/s, so most high-performance SSDs are wasted on the Chronos, in fact most spindle drives will be able to keep up with this speed. I do recommend buying a reputable brand though - the kernel on the camera is a little too old for good TRIM support and may suffer after a couple of write cycles. The 120GB Kingston SSDs that have in our lab stock are especially bad in this regard.

The camera also supports a Gigabit Ethernet port that we hope to use for saving to network storage in a future update, but with the extra overhead of network protocols, checksums and the like we don't anticipate it to be much different from saving via eSATA to a decent SSD.

From the RAM to the Camera exists another possible bottleneck; the video port from the FPGA to the CPU operates at a 133MHz pixel clock (or 100MHz before 0.3.1-rc1). After overhead this works out to around 90fps from RAM into the CPU at 1280x1024 (or 60fps before 0.3.1-rc1). At smaller resolutions this can go as high as 250fps before the h.264 video encoder starts to drop frames, so the the software limits the video port to 230fps at all resolutions when saving.

DNG files are encoded in uncompressed RAW format, and will add a 4kB header to each frame. TIFF files are almost identical to DNG, but the pixels will be gamma-encoded 24-bit RGB on color cameras, or 8-bit greyscale on monochrome cameras.

Software Dev / Re: Building Qt-creator
« on: November 22, 2018, 11:41:40 AM »
usr/lib/ should actually just be a symlink to usr/lib/

I am beginning to think that the problem we might have been experiencing all along is that your copy of the targetfs is missing all of its symlinks. It is traditional for a Linux system to name a shared library with its full version in the filename (eg:, and create a symlink from the unversioned library to the versioned one (eg is linked to If your targetfs was missing all its symlinks, then Qt would have a very difficult time trying to find any of its dependencies.

Software Dev / Re: Chronos V0.3.1-RC1
« on: November 20, 2018, 01:02:28 PM »
There is an option to turn upside down, only it swaps the interface, it does not swap the stream and also not the HDMI output, do you confirm?
Yes, we confirm that this is how the option should work. We feel that the orientation of the video as displayed on the LCD should match the orientation of the camera and it becomes confusing if video on the back of the camera is rotated.

I agree that it would make sense to rotate the video being output over the HDMI port when using the camera is upside down, but that is not presently implemented.

Software Dev / Re: Building Qt-creator
« on: November 19, 2018, 12:59:03 PM »
Hey Matom,
  /usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lOMX_Core
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgmodule-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgobject-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgthread-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lglib-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgstapp-0.10

I am wondering if this is a sign that there is something completely wrong with my libraries or if there is an easy way to get all of them?

I agree, it looks like there is something wrong with your configuration of Qt creator and it's unable to find the libraries from the targetfs. They should all be present in the <path to targetfs>/usr/lib directory. Did you set the Sysroot when configuring the Kit in Qt Creator?

Software Dev / Re: Building Qt-creator
« on: November 14, 2018, 06:22:44 PM »
You might be able to find out a little more info by navigating into the "~/Work/chronos-sdk/qt4-install/config.tests/unix/tslib" folder and running "make", this should attempt to compile a test program to verify the CFLAGS and LDFLAGS necessary for building the tslib components. For example, on my Ubuntu 16.04 virtual machine, and following the v0.3.0 build instructions, I get the following output by running make:

Code: [Select]
osk@virtualbox:~/Work/chronos-sdk/qt4-build/config.tests/unix/tslib$ make
arm-linux-gnueabi-g++ -c -pipe --sysroot=/home/osk/Work/chronos-sdk/targetfs -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-Wall -W  -I../../../../qt-everywhere-opensource-src-4.8.7/mkspecs/qws/linux-omap2-g++ -I../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib
-I../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib -I. -o tslib.o ../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib/tslib.cpp
arm-linux-gnueabi-g++ -Wl,-O1 -o tslib tslib.o     --sysroot=/home/osk/Work/chronos-sdk/targetfs -lts

And my targetfs was created from a v0.3.0 camera, and extracting the update.tgz from the beta-9 update ontop of it. Searching for tslib in the targetfs should give the following hits:
Code: [Select]
osk@virtualbox:~/Work/chronos-sdk/qt4-build/config.tests/unix/tslib$ find /home/osk/Work/chronos-sdk/targetfs/usr | grep tslib

In order to pass the tslib functionality test, Qt needs to be able to be able to find <path to sysroot>/usr/include/tslib.h and <path to sysroot>/usr/lib/

Software Dev / Re: Building Qt-creator
« on: November 12, 2018, 05:29:15 PM »
You have not explicitly asked to use pkg-config and are cross-compiling.
pkg-config will not be used to automatically query cflag/lib parameters for
You can safely ignore this warning, since Qt creator is just letting us know that our target operating system is too simple to make use of the pkg-config tool, and we need to figure out the compiler and linker flags ourselves.

The QtDBus module cannot be enabled because libdbus-1 version 0.93 was not found.

 Turn on verbose messaging (-v) to /home/majtom/Work/chronos-sdk/qt-everywhere-opensource-src-4.8.7/configure to see the final report.
 If you believe this message is in error you may use the continue
 switch (-continue) to /home/majtom/Work/chronos-sdk/qt-everywhere-opensource-src-4.8.7/configure to continue.
This issue seems a lot more serious, and suggests that the Qt configuration tool isn't able to find our libdbus-1 libraries, and that we are likely to fail when running make. I  am also able to get this message from whenever the targetfs is lacking the v0.3.1 update.

And when I try to make from ~/Work/chronos-sdk/qt4-install/qmake I get the following error message:
make: Nothing to be done for 'first'.
If succeeded, there should be a Makefile in the qt4-build directory, and that is where you should be running "make && make install" from. The qmake subdirectory is internal to Qt and you shouldn't need to do anything from there.

I do get a bunch of dbus header files in my targetfs after extracting the update.tgz.

In <path to targetfs>/usr/include/dbus-1.0/dbus I have 22 different header files and in <path to targetfs>/usr/lib/dbus-1.0/include/dbus I only get one: dbus-arch-deps.h. The folder that is referred to in the end of the script ( <path to targetfs>/usr/lib/arm-linux-gnueabi/dbus-1.0/include) does not exist. Could this have something to do with it? Or something about the pkg-config?
Wonderful, that sounds like you have successfully applied the v0.3.1 update to your targetfs. You will probably need to run again after that to make sure that Qt is setup correctly.
The <path to targetfs>/usr/lib/arm-linux-gnueabi/dbus-1.0/include path was added to build on Debian targets, since they structure their include paths a little differently, Qt should simply ignore include paths that don't exist.

Otherwise, is there a way to deploy the camApp V0.2.5 on a camera with FPGA version 3.6?
If you want build software for FPGA version 3.6, then you will just need to check out an earlier version of the chronos-cam-app repository (I would suggest creating a branch starting from the v0.3.0 release tag as v0.2.5 is relatively old and there are some known bugs). The Qt configuration and build process should be very similar, but you won't need the extra tweaks added in v0.3.1 for libdbus. You can find the Qt setup instructions for v0.3.0 here, however, once Qt has been configured for the v0.3.1 it can also build older release of the software too.

Software Dev / Re: Building Qt-creator
« on: November 09, 2018, 12:41:19 PM »
The Qt build instructions have been going through a bit of churn lately as we've been preparing for the v0.3.1 release (which introduced the D-Bus video control API), and as we are preparing to migrate to Debian for future releases. In order for Qt to build successfully with D-Bus support, you will need to use a targetfs that includes the v0.3.1-beta update, this was due to some missing D-Bus libraries and headers that weren't present in the original Arago release.

Suggested resolutions (pick one):
  • Apply the v0.3.1-beta update to your camera, power down the camera and remove the uSD card from the bottom of the camera, then copy the contents of the ROOTFS partition to your targetfs
  • Download the v0.3.1-beta update package, and locate the update.tgz file from the camUpdate folder. Extract the contents of update.tgz onto your targetfs (eg: tar -C <path to targetfs> -xzf <path to update.tgz>)

After that, your targetfs should now  have a bunch of header files in <path to targetfs>/usr/include/dbus-1.0/dbus and <path to targetfs>/usr/lib/dbus-1.0/include/dbus/

Pages: [1] 2