Krontalk

Chronos => Software Dev => Topic started by: tesla500 on December 15, 2017, 12:52:17 AM

Title: Software V0.3 Beta - Updated Jan 4 2018
Post by: tesla500 on December 15, 2017, 12:52:17 AM
UPDATE: V0.2.5 Beta released, fixes free space computation bug in V0.2.3 Beta. (Once the final version is done, it will be called V0.3)

We're just about finished testing the next software release, here is a beta you can try out. Try it out and let us know if you find any bugs.

You can downgrade to previous versions if there is a problem with this version. Just install the old version as normal.

V0.2.5 Beta Changelog (from V0.2:

Installation instructions:
Title: Re: Software V0.3 Beta
Post by: Fyodor on December 15, 2017, 01:10:25 AM
Thanks!

I'll apply the update this afternoon and give it a try!
Title: Re: Software V0.3 Beta
Post by: John DeLonghi on December 15, 2017, 02:53:46 AM
Woo-Hoo! Me too!
Title: Re: Software V0.3 Beta
Post by: NoDak on December 15, 2017, 10:38:28 AM
I'll have to give this a shot.

A couple questions/comments:

1. Thank you for being able to retain settings between reboots.
2. Stupid question, how fast does it currently save at? Faster save FPS will really help those 17,000 fps shots. I'm always paranoid and put big handles on my saves.
3. Easier trigger delay will be handy. Always hard to judge how long to wait before hitting the trigger. Now I can just hit it when stuff happens and know that I'll have a handle on the end.
4. What ram configurations have been used on cameras shipped thus far? Just wondering if I have  2 8gb or 1 16.
5. RAW saving I presume is uncompressed video? Is there. Information about the differences between the option you listed? Sounds like a great option for retaining maximum detail when you know you will be running the video through an editor.
6. Standalone mode will be interesting to try.

7. I know we are all waiting for this, but how are things going with HDMI support?

Thanks again for all your hard work.
Title: Re: Software V0.3 Beta
Post by: JamesB on December 15, 2017, 01:19:17 PM
Will try it out this weekend, that is some serious feature / bug update.  Can't wait to see the increased save speed and more importantly the drop frame fix which could occur from time to time "this is probably the most important fix"  Will report issues/findings! 

Thanks, Krontech Team!      ;D
Title: Re: Software V0.3 Beta
Post by: Loial on December 15, 2017, 01:55:32 PM
I'll have to give this a shot.

A couple questions/comments:

1. Thank you for being able to retain settings between reboots.
2. Stupid question, how fast does it currently save at? Faster save FPS will really help those 17,000 fps shots. I'm always paranoid and put big handles on my saves.
3. Easier trigger delay will be handy. Always hard to judge how long to wait before hitting the trigger. Now I can just hit it when stuff happens and know that I'll have a handle on the end.
4. What ram configurations have been used on cameras shipped thus far? Just wondering if I have  2 8gb or 1 16.
5. RAW saving I presume is uncompressed video? Is there. Information about the differences between the option you listed? Sounds like a great option for retaining maximum detail when you know you will be running the video through an editor.
6. Standalone mode will be interesting to try.

7. I know we are all waiting for this, but how are things going with HDMI support?

Thanks again for all your hard work.


2. Saving will scale with how quickly it can get data to the SD card or other media. At 1280x1024 it's limited to about 60fps but can go as high as 190fps while saving lower resolution or quality.
4. All 16GB models were shipped with a single 16GB stick
5. RAW is simply a packed raw format. Each image is saved one after another without any wrapping or containers - I.E. it's not a TIFF or anything. This is still a work in progress and the goal will be to save DNG/TIFF image series or some other better supported format.
7. HDMI is one of those more difficult problems. In my testing I've been able to get HDMI working from the command line but only while the application was not running. It's something we're working on but it won't be ready until at least the next update.

--- More info about RAW
There are three raw formats: 16bpp, 16bpp right-justified and 12bpp packed.

Because the data coming off the sensor is 12bpp the smallest raw files will be saved in the last mode but that's also the least supported format for reading/writing.

16bpp and 16bpp right-justified both add 4 bits of 0 to either the most significant or least significant bits.
For 16bpp (left-justified) that means that all values will be from 0-65536 (or just under that) and for the right-justified version it'll be 0-4096. The first of these two formats will be better supported by software.

Right now I've prototyped a python script that can convert the raw format into a series of b/w TIFFs but it's in very early stages of development. From colour sensors you'll get the full bayer pattern in the raw data and right now most software that can normally handle bayer-encoded images is not detecting it due to being a TIFF. Once I have it able to make a DNG image series instead with the proper coding for editing software I'll release it so it can be used.

All of the raw saving is still quite preliminary as the goal will be to get the camera saving directly as a more standardized way such as DNG photo series or CinimaDNG.
Title: Re: Software V0.3 Beta
Post by: GhostRider on December 15, 2017, 11:30:35 PM
Does this mean we can upgrade our 16g camera to a 32g one, just by dropping in a second 16g card?

if yes, do you have any links to where I can purchase said 16g card that will be fully compatible?
Title: Re: Software V0.3 Beta
Post by: gahang on December 18, 2017, 10:58:30 PM
Which interface should be USB stick plug in ? The eSATA interface or the OTG interface ?
Title: Re: Software V0.3 Beta
Post by: Loial on December 19, 2017, 02:23:27 PM
Which interface should be USB stick plug in ? The eSATA interface or the OTG interface ?

The eSATA interface. Make sure the stick is FAT32 (under windows 10 you may have to use 3rd party software to format as this because they've removed the option on drives larger than, IIRC, 64GB)
Title: Re: Software V0.3 Beta
Post by: Loial on December 19, 2017, 02:28:54 PM
Does this mean we can upgrade our 16g camera to a 32g one, just by dropping in a second 16g card?

if yes, do you have any links to where I can purchase said 16g card that will be fully compatible?

Technically yes. The only sticks we really support are the ones supplying but any dual-rank 8 or 16GB DDR3 dimms should work in the camera.
A quick search finds these: https://www.newegg.ca/Product/Product.aspx?Item=9SIADER6682991 (not endorsing, just did a quick search)
Title: Re: Software V0.3 Beta
Post by: gahang on December 19, 2017, 05:17:24 PM
Which interface should be USB stick plug in ? The eSATA interface or the OTG interface ?

The eSATA interface. Make sure the stick is FAT32 (under windows 10 you may have to use 3rd party software to format as this because they've removed the option on drives larger than, IIRC, 64GB)

Thank you very much! I change another USB stick and it works!
Title: Re: Software V0.3 Beta
Post by: gahang on December 19, 2017, 05:18:36 PM
How does the ethernet function work? Is there any specifications?
Title: Re: Software V0.3 Beta
Post by: tesla500 on December 19, 2017, 11:47:40 PM
How does the ethernet function work? Is there any specifications?

That's currently in development, targeting release around end of January. When we have a detailed spec, there will be on this forum.
Title: Re: Software V0.3 Beta
Post by: gahang on December 20, 2017, 01:04:18 AM
How does the ethernet function work? Is there any specifications?

That's currently in development, targeting release around end of January. When we have a detailed spec, there will be on this forum.

So what does the "Partial Ethernet" mean in the change log?
Title: Re: Software V0.3 Beta
Post by: Dan D on December 20, 2017, 07:15:14 AM
Hey guys, thanks for releasing the beta software early! Sorry for long post. Bug reports and tips below.

I'm using the camera in an optics lab at a university. RAW is essential; 12 bit packed mode is great! Our lab has some high end scientific high speed cameras that cost at LEAST 30x more than the Chronos. I've done side by side comparisons and the Chronos is really holding its own - great work Dave & co. Next year, I'll write up and share the data. The only thing that lets the camera down right now is the lack of a remote control API via ethernet and a working HDMI output so we can control & view remotely. I'm sure it will come! :-)

If anyone else is planning to put the Chronos 1.4 to scientific use, perhaps we should start a forum page for sharing code, tips, and example videos of cool stuff. I'm hoping to write an ImageJ/Fiji plugin for reading in the raw data next year. For now, I've got a Python program successfully extracting frames from the 12 bit packed format with no trouble. Once I've optimised the code (it's rather slow and lacking comments), I'll put it on Github. Planning to add support for directly reading gzipped raw files so we can have true lossless compression.

I've done a whole lot of playing about with the 0.2.3 beta in the last few days on my monochrome 8 GB model and I've found some interesting bugs and workarounds. Info will follow for those who care. I'm happy to field-test stuff and follow up on bug fixes if it helps.

Dan D.

WRITE FILES BIGGER THAN 4GB!
When trying to dump the whole RAM to RAW, the fat32 file size limit of 4GB is a REAL pain. And almost as bad, I can't write past the first 8 GB of fat32 media. I'm going to assume NTFS is out of the question, and exFAT is not supported yet. Since the Chronos is running *nix, I thought I'd take a punt and format my flash drive to ext3 - and it works!! I can now save the FULL ram of the camera (8gb) in a single hit to one file, and to boot I can use the whole size of the drive rather than just the first 8GB! The "above 4GB" warning message will still appear - just acknowledge & continue saving. This is super cool, with two drawbacks. One, mounting ext2/3/4 in windows & mac is a pain - and two, the save speed is roughly half that of fat32.

I'm getting best save performance to a high-end USB 3.0 compatible thumb drive formatted fat32, at about 13 MB/s. It's twice as fast as a '30 MB/s' rated SD card, which seems to only give me about 7 MB/s? Maybe it's not a good card.

EXTERNAL SYNC
I've found that if you want to gate the shutter from a TTL signal or at least sync the start of exposure from an external clock, you need to set the internal framerate to be just slightly higher than the incoming signal, otherwise frames can drop. i.e. 1 kHz square wave on BNC cable, camera set at 1000 fps, some frames dropped, but if camera is expecting 1001 fps, no dropped frames.  Setting the internal frame rate too high above the external signal can also sometimes cause unreliable sync though.


BUG REPORTS
i) The eject SD / eject USB in the Util menu are throwing "failed to eject" errors for me every time in v0.2.3.  The "safely eject" button in the Play:Settings screen works.

ii) Aborting save of RAW can cause the camera to crash on occasion (it goes to a shutting down screen and hangs)

iii) 12 bit packed RAW files are often truncated a couple frames short of the requested mark out point. Sometimes the files end halfway through a pixel! i.e. record 1000 frames, save all of it to 12 bit packed RAW, saving UI counts up to 1000 and done, and I end up with 991 frames and a bit of the next frame in my file. This is not a file size limit issue as far as I can tell.

iv) When saving, the counter over-runs the mark out point by 5-6 frames. If mark out is at the end of the memory, it will overflow and count back up to 5 or 6. Maybe connected to (iii) or could be aesthetic.

v) Warning about file size being too large for fat32 storage (above 4GB) is wrong when using 12 bit packed format - it shows the error once the file gets above about 3 GB. I think the calculation for the warning is assuming that the file being saved will be 16 bpp?

vi) When the total data saved to a fat32 drive reaches 8 GB, a save error occurs (sure...) but then the playback & live framebuffer displays go green and distorted on the left, and black on the right side, as if the software suddenly thinks my mono camera is a color model and is misinterpreting the data. Putting in a new empty media and redoing the Save causes the problem to go away.

vii) Sometimes when I boot, the camera has suddenly gone into Gated mode (1 frame!). I think this is related to the next bug.

viii) I use the external shutter gate option a lot. If I try and change resolutions and frame rates when this is enabled, bad things happen, which can be any of the following:
This did not happen with software v0.2 and is a new bug.
Workaround: turn off external shutter gating before changing frame rates and resolutions. Once settings are good, then switch back to external gating.
When the bad things above happen, turn off external gating and hard reset the camera. I had to actually pull the power cord and battery and hard reboot for the problem to resolve.


FEATURE REQUESTS
Title: Re: Software V0.3 Beta
Post by: jasonfish on December 20, 2017, 11:30:48 AM
I'm getting best save performance to a high-end USB 3.0 compatible thumb drive formatted fat32, at about 13 MB/s. It's twice as fast as a '30 MB/s' rated SD card, which seems to only give me about 7 MB/s? Maybe it's not a good card.

...

Partitioned memory mode is cool. I don't see support for being able to switch memory segments yet though, did I miss something?

I get about 10% faster saves when using a USB>SD adapter vs the same card in the SD slot. I think the USB interface is just slightly faster, for one.

---

Same question here.
Title: Re: Software V0.3 Beta
Post by: Loial on December 20, 2017, 03:59:28 PM
First of all; Thanks for the fantastic feedback. This is a huge help!

Hey guys, thanks for releasing the beta software early! Sorry for long post. Bug reports and tips below.

I'm using the camera in an optics lab at a university. RAW is essential; 12 bit packed mode is great! Our lab has some high end scientific high speed cameras that cost at LEAST 30x more than the Chronos. I've done side by side comparisons and the Chronos is really holding its own - great work Dave & co. Next year, I'll write up and share the data. The only thing that lets the camera down right now is the lack of a remote control API via ethernet and a working HDMI output so we can control & view remotely. I'm sure it will come! :-)

If anyone else is planning to put the Chronos 1.4 to scientific use, perhaps we should start a forum page for sharing code, tips, and example videos of cool stuff. I'm hoping to write an ImageJ/Fiji plugin for reading in the raw data next year. For now, I've got a Python program successfully extracting frames from the 12 bit packed format with no trouble. Once I've optimised the code (it's rather slow and lacking comments), I'll put it on Github. Planning to add support for directly reading gzipped raw files so we can have true lossless compression.

I've done a whole lot of playing about with the 0.2.3 beta in the last few days on my monochrome 8 GB model and I've found some interesting bugs and workarounds. Info will follow for those who care. I'm happy to field-test stuff and follow up on bug fixes if it helps.

Awesome to hear you got that working. I only just made the 16bpp translation and was going to tackle the 12bpp packed format in the next bit.

Dan D.

WRITE FILES BIGGER THAN 4GB!
When trying to dump the whole RAM to RAW, the fat32 file size limit of 4GB is a REAL pain. And almost as bad, I can't write past the first 8 GB of fat32 media. I'm going to assume NTFS is out of the question, and exFAT is not supported yet. Since the Chronos is running *nix, I thought I'd take a punt and format my flash drive to ext3 - and it works!! I can now save the FULL ram of the camera (8gb) in a single hit to one file, and to boot I can use the whole size of the drive rather than just the first 8GB! The "above 4GB" warning message will still appear - just acknowledge & continue saving. This is super cool, with two drawbacks. One, mounting ext2/3/4 in windows & mac is a pain - and two, the save speed is roughly half that of fat32.

I'm getting best save performance to a high-end USB 3.0 compatible thumb drive formatted fat32, at about 13 MB/s. It's twice as fast as a '30 MB/s' rated SD card, which seems to only give me about 7 MB/s? Maybe it's not a good card.

The save performance should improve in the future - we've found a rather annoying "feature" of the video pipeline in use in that it does a memcpy to move the frame into kernel space from OMX. This is where all the extra speed that saving to USB or eSATA should be given is being eaten up; the CPU can only move so much data.

It's in the pipeline of things that need to be fixed but probably won't be fixed before the network control features are at least somewhat working.

EXTERNAL SYNC
I've found that if you want to gate the shutter from a TTL signal or at least sync the start of exposure from an external clock, you need to set the internal framerate to be just slightly higher than the incoming signal, otherwise frames can drop. i.e. 1 kHz square wave on BNC cable, camera set at 1000 fps, some frames dropped, but if camera is expecting 1001 fps, no dropped frames.  Setting the internal frame rate too high above the external signal can also sometimes cause unreliable sync though.

Good to know detail. We generally use the gating from another camera for testing and of course the timing would always be close enough that it won't cause problems. Another side of this is it's generally a very good idea to change the frame time down on a slave camera before changing the master timing - this would also be true for external signals as we've seen the application crash once every now and then and haven't tracked down why yet - something timing-wise in the FPGA.


BUG REPORTS
i) The eject SD / eject USB in the Util menu are throwing "failed to eject" errors for me every time in v0.2.3.  The "safely eject" button in the Play:Settings screen works.

ii) Aborting save of RAW can cause the camera to crash on occasion (it goes to a shutting down screen and hangs)

iii) 12 bit packed RAW files are often truncated a couple frames short of the requested mark out point. Sometimes the files end halfway through a pixel! i.e. record 1000 frames, save all of it to 12 bit packed RAW, saving UI counts up to 1000 and done, and I end up with 991 frames and a bit of the next frame in my file. This is not a file size limit issue as far as I can tell.

iv) When saving, the counter over-runs the mark out point by 5-6 frames. If mark out is at the end of the memory, it will overflow and count back up to 5 or 6. Maybe connected to (iii) or could be aesthetic.

v) Warning about file size being too large for fat32 storage (above 4GB) is wrong when using 12 bit packed format - it shows the error once the file gets above about 3 GB. I think the calculation for the warning is assuming that the file being saved will be 16 bpp?

vi) When the total data saved to a fat32 drive reaches 8 GB, a save error occurs (sure...) but then the playback & live framebuffer displays go green and distorted on the left, and black on the right side, as if the software suddenly thinks my mono camera is a color model and is misinterpreting the data. Putting in a new empty media and redoing the Save causes the problem to go away.

vii) Sometimes when I boot, the camera has suddenly gone into Gated mode (1 frame!). I think this is related to the next bug.

viii) I use the external shutter gate option a lot. If I try and change resolutions and frame rates when this is enabled, bad things happen, which can be any of the following:
  • the display stops updating or becomes partially obscured by a block of static
  • the camera goes into Gated mode (1 frame) and refuses to accept a change of setting
  • camera can get stuck in a permanent recording loop (red led stuck on, record button does nothing)
  • camera can refuse to shut down and will still be misbehaving when rebooted!
This did not happen with software v0.2 and is a new bug.
Workaround: turn off external shutter gating before changing frame rates and resolutions. Once settings are good, then switch back to external gating.
When the bad things above happen, turn off external gating and hard reset the camera. I had to actually pull the power cord and battery and hard reboot for the problem to resolve.

Thanks - will check into these details. I'll make note on any that are specific.

iii) I haven't been able to read 12bpp data yet so didn't catch this. Will test and figure out what's causing that. For now it would be a good idea to always record a dozen extra frames. Please let me know if there are any frames missing from what you can tell. One of the other features in the pipe is overlay text and/or embedded data so it'll be easier to catch dropped frames. There should be none at this time based on the tests we've done of the other save modes.

iv) cosmetic if it's not dropping frames - the pipeline is async so may play a few more frames into the cpu-side buffer before everything's shut down. I'll note that to make a quick fix to hold the frame number and position if it's past the end but for now it's useful for seeing if there are dropped frames.

vi) raw recording still uses the 24bit interface by encoding two pixels side by side. In verilog this would be Pixel1={Blue[7:0],Green[7:4]}, Pixel2 = {Green[3:0],Red[7:0]}... Already fixed for next beta update, will get that out when there are a few more bugs fixed.

vii/viii) Gated mode, as noted above with the changing of resolution, has some edge cases in the FPGA side that can cause crashing of the pipeline in there. If you find anything that can reproduce this easily Please let us know, this has been a tricky one to track down.

Would it be acceptable to turn off live preview if not currently recording when in gated mode?


FEATURE REQUESTS
  • Partitioned memory mode is cool. I don't see support for being able to switch memory segments yet though, did I miss something?
  • Saving the whole RAM to RAW can be a slow affair. It would be super cool to have an option to turn on an auditory alert or screen flash when saving is done so I know to look up from my laptop!
  • I connected IO2 with frame sync output to an oscilloscope at 1Meg impedance and the signal was very funky until I pulled it down to 50 Ohms. In a future version of the camera, can you include a 50R pulldown resistor option for either IO2 or IO3?
  • Does the hardware support binning mode? i.e. read out each block of 2x2 pixels as a single virtual pixel with 4x the effective sensitivity, image is now 1/4 the size.
  • Can you modify the RAW formats to add a few bytes of header data? Ie pixels width and height, bits per pixel (for discriminating RGB and mono data files), and may be camera serial no? Most scientific cameras write data out this way. ImageJ / FIJI RAW reader by default assumes the first 1024 bytes of scientific camera RAW are header anyway.
  • I see the specs list two 1 MS/s ADCs. Is there any way we could use these for recording an arbitrary signal like a pressure or temperature sensor in sync with the movie? Are they wired to the mic jack?
  • Is Krontech willing to share who they buy their CMOS arrays from? I'm not going to go into competition  ;D , but often these details need to go into the methods sections of scientific journal papers.

Will work on those. The indicator when save complete is really good. As soon as audio is working I'll make sure that's one of the options.

The sensor does include a binning mode but we haven't set it up or tested it yet.

The ADC inputs are on the terminal connector along with trigger 2 and 3. Once we overlay or embedded data we can save the analog values there. It will be a bit as we haven't started implementing this part.

We are using Luxima sensors.
Title: Re: Software V0.3 Beta
Post by: Dan D on December 21, 2017, 12:12:24 AM
Cheers!

Dan
Title: Re: Software V0.3 Beta
Post by: Fyodor on December 21, 2017, 12:15:10 AM
@ Dan D:
I'm really missing a "like" button in this forum!
Title: Re: Software V0.3 Beta
Post by: NiNeff on December 21, 2017, 11:37:30 AM
Hey!
I just tried to update my camera and it did not seem to work, however I'm not sure what failed. As far as I can tell I'm still on the old 0.2. Version because I cant find any of the new features and the version dialog still claims to be 0.2 (and not 0.2.3 or 0.3 or whatever)

The upgrade process itself went exactly like described in the first post, no errors appeared. I'm using an 8GB USBstick, maybe it's too big? But the update was recognized by the camera and it did find and apply the update on the stick.

I know this is a really bad "bug" report as it contains virtually no info, so please tell me what to try and which information you need so I can report back. If needed, i will record the whole upgrade process using another camera ;)
Title: Re: Software V0.3 Beta
Post by: BiduleOhm on December 21, 2017, 11:41:54 AM
You've probably already tried but did you try to reboot the camera?
Title: Re: Software V0.3 Beta
Post by: NiNeff on December 21, 2017, 02:04:15 PM
You've probably already tried but did you try to reboot the camera?
yes, it had no effect. I'm still on the old version.
Title: Re: Software V0.3 Beta
Post by: patrickrebstock on December 21, 2017, 06:10:43 PM
i am on the new firmware and the automaticly record and auto save after trigger are working!  stoked
i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Feature request, is there a way to set WB with Kelvin temperature rather than hitting a WB button with it facing at a white card
i would love to set it at 5,500 kelvin, there are so manny times that i shoot where i cant get a WB card to work, i shoot on very telephoto lenses 300mm and 800mm and its not practical to find something white 50 yards away, also the similar problem with my fisheye lens hard to get a WB

question does it save black balance settings across reboots?
Title: Re: Software V0.3 Beta
Post by: Dan D on December 21, 2017, 06:23:04 PM
i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Yeah, I've had the same issue with losing access to the SD card slot after an out of space error until I reboot. I think the SD drive fails to be properly unmounted so inserting a new SD card won't work because the mountpoint is 'busy'. The USB ports don't seem to have this problem - if you use an SD card reader in the USB port you may have better luck.

I think the out of space error is happening because (a) the software can't seem to write past the first 8 gb of a fat32 partition and (b) fat32 has a 4gb file size limit - you can hit that easily when saving RAW. I found a temporary workaround to be to format your drive for Linux ie. ext3.  You just have to install some 3rd party software on mac/windows to read the files off. Another way around might be to partition to the drive into lots of 8gb fat32 segments, which would probably give faster saving, although you'll still get hit with the 4gb file size limit and it'll be a pain to use.  Devs can correct this if I am mistaken.
Title: Re: Software V0.3 Beta
Post by: patrickrebstock on December 22, 2017, 04:30:45 AM
i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Yeah, I've had the same issue with losing access to the SD card slot after an out of space error until I reboot. I think the SD drive fails to be properly unmounted so inserting a new SD card won't work because the mountpoint is 'busy'. The USB ports don't seem to have this problem - if you use an SD card reader in the USB port you may have better luck.
hmm im not saving raw just h264

I think the out of space error is happening because (a) the software can't seem to write past the first 8 gb of a fat32 partition and (b) fat32 has a 4gb file size limit - you can hit that easily when saving RAW. I found a temporary workaround to be to format your drive for Linux ie. ext3.  You just have to install some 3rd party software on mac/windows to read the files off. Another way around might be to partition to the drive into lots of 8gb fat32 segments, which would probably give faster saving, although you'll still get hit with the 4gb file size limit and it'll be a pain to use.  Devs can correct this if I am mistaken.
Title: Re: Software V0.3 Beta
Post by: tesla500 on December 23, 2017, 01:31:51 AM
So what does the "Partial Ethernet" mean in the change log?

That just means you can connect the camera to a network, and with some scripts, you can scp saved videos over the network to a remote server. Far from full Ethernet control but it's something for now.
Title: Re: Software V0.3 Beta
Post by: John DeLonghi on December 23, 2017, 08:38:41 AM
I've had the out of space error when using the same SD card I usually put in the slot but put in a card reader in the USB interface. One reboot didn't fix it but a second did.
Title: Re: Software V0.3 Beta
Post by: gahang on December 23, 2017, 11:41:01 PM
So what does the "Partial Ethernet" mean in the change log?

That just means you can connect the camera to a network, and with some scripts, you can scp saved videos over the network to a remote server. Far from full Ethernet control but it's something for now.

That's still a usefull function. We have to control the camera remotely due to the X-ray radiation in our workshop. So can you please send me the scripts that is already in use?
Title: Re: Software V0.3 Beta
Post by: gyppor on December 24, 2017, 03:43:11 PM
I'm having a minor issue after the update - when I use very low resolutions, especially 336x96, I get one flashing horizontal brown line near the top of the frame and one flashing blue line near the middle. These show after a black calibration. I'm assuming this has to do with the RAM temperature - I sometimes had the flashing line issue in the past running previous firmware versions but it was always resolved by performing a black calibration. Now black cal doesn't eliminate the lines.

My camera is serial #18 running software version 0.3. I do have an edited resolutions file, I'm not sure if this would cause any issues?
Title: Re: Software V0.3 Beta
Post by: Loial on December 24, 2017, 11:10:24 PM
Due to forum problems please remove all spaces after slashes in the following before use.

Right now you can connect a usb-mini cable to the OTG port and connect it to a computer. It'll show up as a network device and offer DHCP for 192.168.12.x. It'll be at 192.168.12.1. You can then ssh into the camera with root and any password.

If you kill the camera app "killall camApp" you can then edit the settings file "/ Settings/ KronTech/ amApp.conf" and restart the camera application "/ etc/ init.d/ camera start".

By using Auto Record and Auto Save modes you can get the camera to automatically save a buffer to the SD card using an external trigger signal. When combined with the methods above you can get very rudimentary control and operation of the camera. Any settings that are not possible will default to another value so it's better to configure the camera in advance. Also there is no provision for blackcal or other functions which means that if you're on an arbitrary resolution that has not been calibrated yet, image quality will be poor.

The saved files will be under "/ media/ mmcblk1p1/ " and timestamps or file naming can be used to determine which one is the latest.

I don't have any scripts that do this directly, just one that can manipulate the files and download the latest and the like (we use this for final calibration, filesystem and os testing). When I'm back from Christmas I can get some of the source up.
Title: Re: Software V0.3 Beta
Post by: Loial on December 24, 2017, 11:13:11 PM
I'm having a minor issue after the update - when I use very low resolutions, especially 336x96, I get one flashing horizontal brown line near the top of the frame and one flashing blue line near the middle. These show after a black calibration. I'm assuming this has to do with the RAM temperature - I sometimes had the flashing line issue in the past running previous firmware versions but it was always resolved by performing a black calibration. Now black cal doesn't eliminate the lines.

My camera is serial #18 running software version 0.3. I do have an edited resolutions file, I'm not sure if this would cause any issues?

Do these show up in the final video as well? I'll see if I can reproduce it here. Is the shutter at maximum or at some other value?
Title: Re: Software V0.3 Beta
Post by: gyppor on December 25, 2017, 03:45:53 PM
I'm trying to reproduce the issue right now but no deal. The camera was cold (10 degrees) at the time I originally had the issue. I was just messing with the camera so I didn't get any footage. I'll try to put it in the garage for a while and let it cool down, and see if it does the same thing when cold.

On another note, is reducing minimum vertical resolution below 96 pixels on the docket for the next update?
Title: Re: Software V0.3 Beta
Post by: CR0M3 on December 29, 2017, 04:25:48 AM
Today i upgraded my 8GB Cam to 32GB by using amazon.de/gp/product/B01LFQH95Q/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 (http://amazon.de/gp/product/B01LFQH95Q/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1)
and after changing the record time to max. everything works perfect.
Title: Re: Software V0.3 Beta
Post by: patrickrebstock on December 31, 2017, 06:48:45 AM
Hmm I had never run into this problem before this firmware and had shot tons of footage on one card , the same card intact. So we can only use 8gb? I think this needs to be solved because what seemed to work before now kinda make the camera unusable for me. I need to br able to keep shooting
i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Yeah, I've had the same issue with losing access to the SD card slot after an out of space error until I reboot. I think the SD drive fails to be properly unmounted so inserting a new SD card won't work because the mountpoint is 'busy'. The USB ports don't seem to have this problem - if you use an SD card reader in the USB port you may have better luck.
hmm im not saving raw just h264

I think the out of space error is happening because (a) the software can't seem to write past the first 8 gb of a fat32 partition and (b) fat32 has a 4gb file size limit - you can hit that easily when saving RAW. I found a temporary workaround to be to format your drive for Linux ie. ext3.  You just have to install some 3rd party software on mac/windows to read the files off. Another way around might be to partition to the drive into lots of 8gb fat32 segments, which would probably give faster saving, although you'll still get hit with the 4gb file size limit and it'll be a pain to use.  Devs can correct this if I am mistaken.
Title: Re: Software V0.3 Beta
Post by: CR0M3 on December 31, 2017, 04:04:00 PM
Same here today. I use a 64GB SD-Card fat32 and after 3,39GB of PixelStuff the  Camera said nope. Enough is enough.
But i got all my Firework-Stuff on Video so i dont really care c:
Title: Re: Software V0.3 Beta
Post by: Dan D on January 01, 2018, 03:26:36 AM
Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.
Title: Re: Software V0.3 Beta
Post by: NoDak on January 01, 2018, 07:36:35 PM
Same here today. I use a 64GB SD-Card fat32 and after 3,39GB of PixelStuff the  Camera said nope. Enough is enough.
But i got all my Firework-Stuff on Video so i dont really care c:
Yea, finally got around to updating my camera.

New version works great, but on h264 the files now take 700 MB each. That is not a problem, always good to have max quality and edit down in post, except for the fact that I am running into the same 4GB save limit, on a 64 gb card, that others are having
Title: Re: Software V0.3 Beta
Post by: tesla500 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.
Title: Re: Software V0.3 Beta
Post by: Dan D on January 02, 2018, 02:55:16 AM
Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.

I did a bit of playing around with the 12-bit packed RAW format data, and I found a bug in the way the files are written out when the resolution is reduced. The data is in the file, it's just surrounded by what looks like junk bytes -it appears a buffer is overflowing during save. The images appear properly on the display so the copy in RAM is ok.

There seem to be 2 issues. The first is that the scanlines seem to be written out rounded up to the nearest 16 bytes, obviously this doesn't always play well given that the scanline is 1.5N bytes long. Depending on the size of the image there can be a couple of junk bytes between lines. The other issue, which I've not yet been able to solve, is that there can be a huge amount of junk data between frames, which looks to me like a buffer overflow. For example if I reduce down to 336 x 96 pixels images for the max possible frame rate, then I can easily have half a frames' worth of nonsense bytes between each frame. I have no idea how to figure out where each frame is about to start in the binary stream, as the length of this junk region varies from file to file, making decoding pretty much impossible. Happy to help on fixing this bug as it's a show stopper for me until we can figure it out!

Cheers
Dan.
Title: Re: Software V0.3 Beta
Post by: NoDak on January 02, 2018, 05:13:31 AM
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.
Thanks for the update.

Overall this is a very good update. Just one minor bug for everyone.  ;D
Title: Re: Software V0.3 Beta
Post by: Loial on January 02, 2018, 03:15:37 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.
Thanks for the update.

Overall this is a very good update. Just one minor bug for everyone.  ;D

The packed format is the least tested one out of the new raw formats. It also uses some weird configuration to make it work correctly which is probably why the data is being messed up on the saving side. Specifically the FPGA is configured to give an image which is half the horizontal resolution. The pipeline should be correctly handling this but there's a chance it's not.

Another important thing of note is that the architecture is 32-bit and the data is 24-bit. This means it'll probably align the data either at frame boundaries or possibly line boundaries and can potentially mess up the data.
Title: Re: Software V0.3 Beta
Post by: Dan D on January 04, 2018, 04:05:53 AM
Thanks, good to know. I'm sure there's a way to unpack the files, all the data is in there somehow! :-)
Title: Re: Software V0.3 Beta
Post by: tesla500 on January 04, 2018, 05:06:04 PM
V0.2.5 Beta posted, see the first post.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: NiNeff on January 05, 2018, 01:59:10 AM
With 0.2.5 I was now able to update my camera without issues. But I used a different USB stick, which might also have helped. On towards testing the new features ;D
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: patrickrebstock on January 05, 2018, 08:09:25 PM
got the could not save no space bug again today, came back to my computer and saw you had the update and updated the camera and it seems to be working! thanks
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: nik282000 on January 07, 2018, 06:15:11 PM
Installed the .5 update with no issues, last time it didn't seem to like my USB stick, this time everything worked on the first try. I have another 16gb of ram ready to install, hopefully I will be able to try it out later this week.

Thanks, David!
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: NoDak on January 08, 2018, 06:53:24 PM
My Chronos has locked up while testing to see if the issues with .3 have been solved.

I was had my camera plugged in on my desk and I was having it simply auto save the whole buffer at the default 1,000 FPS. Once I saw it had finished I would hit record and save the whole buffer after enough time had passed for it to fill.

I left the camera running overnight, recording a few more buffers worth of video as I got ready for work. I leave the camera running during the day on my desk, then come home and start recording more.

After one such save, the camera gives me a grey screen. I try to record, but it fails. I go into the settings and I cannot change the resolutions. I go out to the main screen and the camera gives the "Shutting down" message, but locks up on this screen until I hard power it down.

The card is 64gb and saved video until it was 29.8gb filled of 59.4gb (Don't know if this is relevant.)

(https://i.imgur.com/drvFznQl.jpg)

(https://i.imgur.com/9vkY7pdl.jpg)

(https://i.imgur.com/jnkz08Dl.jpg)

Camera works fine after the hard reset.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: NoDak on January 08, 2018, 07:03:34 PM
Splitting this up into another post since this is unrelated to the last issue.

When "Auto Save" is selected, pressing "Stop" on the touch screen causes the camera to begin auto saving. The problem is that there is no way, that I can see, to disarm the camera when auto save is enabled. You will have to let the camera start saving and then abort the save, which is both inconvenient and puts lots of files on the memory card you never wanted to put there in the first place.

Don't know what the best solution would be, but figured I should mention it.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: nik282000 on January 12, 2018, 10:09:32 PM
I was playing with the segmented memory mode and I'm not sure if I am using it wrong, my trigger switch is bad or I have a legitimate bug.

-I set to Segmented mode with 3 segments
-Start recording
-Press the external trigger after the events I want to catch
-Stop recording after triggering 3 times

The recording I get is mix of short and long out of order clips, some times from all 3 segments in rapid succession, sometimes from different places inside one segment. The total length seems to be correct and everything that I wanted to record seems to be there but I am not 100% sure. I might try recording a stop watch to see if it gets everything.

My trigger is not the greatest mechanical switch, but the results are the same with de-bounce both enabled and disabled. If this is a 'layer 8' problem please let me know, otherwise 0.2.5 has been working well for me. I installed another 16gb of ram and the camera sees and uses the new memory.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: Loial on January 13, 2018, 01:42:14 PM
Splitting this up into another post since this is unrelated to the last issue.

When "Auto Save" is selected, pressing "Stop" on the touch screen causes the camera to begin auto saving. The problem is that there is no way, that I can see, to disarm the camera when auto save is enabled. You will have to let the camera start saving and then abort the save, which is both inconvenient and puts lots of files on the memory card you never wanted to put there in the first place.

Don't know what the best solution would be, but figured I should mention it.

There's a rather undocumented method - If you go into any setting menu (io, recording, etc.) it'll give you a warning that it'll stop record and then it should go to the menu without saving.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: nik282000 on January 16, 2018, 06:05:24 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.

(https://i.imgur.com/V0vFdGr.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?
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: tesla500 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.
Title: Re: Software V0.3 Beta - Updated Jan 4 2018
Post by: nik282000 on January 17, 2018, 11:35:21 PM
>_< Thank you, that make my results make more sense. Good luck with round two of production!