Author Topic: EEVblog #947 - Chronos High Speed Camera Review  (Read 21320 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37664
  • Country: au
    • EEVblog
EEVblog #947 - Chronos High Speed Camera Review
« on: November 23, 2016, 09:38:38 am »
Dave takes a look at the 21,000fps Chonos Kickstarter high speed digital camera prototype.
https://www.kickstarter.com/projects/1714585446/chronos-14-high-speed-camera/
Tesla500 Youtube Channel:
https://www.youtube.com/user/tesla500

 
The following users thanked this post: electrolux

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #1 on: November 23, 2016, 09:48:33 am »
There is some competition - fps1000
https://www.kickstarter.com/projects/1623255426/fps1000-the-low-cost-high-frame-rate-camera
I do have some doubts over flash endurance, and whether it's even possible to do continuous record-until-triggered due to erase time.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline malaire

  • Newbie
  • Posts: 6
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #2 on: November 23, 2016, 10:15:24 am »
There is some competition - fps1000
https://www.kickstarter.com/projects/1623255426/fps1000-the-low-cost-high-frame-rate-camera
I do have some doubts over flash endurance, and whether it's even possible to do continuous record-until-triggered due to erase time.
Flash endurance and erase time are not issues for Chonos, since it doesn't save to SD card during filming - everything is kept in RAM.
« Last Edit: November 23, 2016, 10:28:17 am by malaire »
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #3 on: November 23, 2016, 11:13:03 am »
Not an isssue for Chronos, but potentially is for fps1000. A while ago I looked up the datasheet for the flash they were using and it was of the order of a few thousand cycles.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #4 on: November 23, 2016, 11:44:32 am »
Not an isssue for Chronos, but potentially is for fps1000. A while ago I looked up the datasheet for the flash they were using and it was of the order of a few thousand cycles.

I've had a quick look at the FPS1000. It seems to use DRAM (which they are calling video memory), for initial storage, in a "rolling" 1 minute buffer.

From their website which takes years to open:
Quote
Large 128Gbytes video memory for 1 full minute of recording time.

So it only needs to write the final images, to flash once.

Flash would probably be way too slow (write speed), to be used at such high frame rates, without using complicated techniques to get round it.

Disclaimer: Assuming it is DRams they are using. If it is flash chips (I hope not and doubt it), then I'd be wrong.
« Last Edit: November 23, 2016, 11:46:52 am by MK14 »
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37664
  • Country: au
    • EEVblog
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #5 on: November 23, 2016, 11:48:24 am »
Flash would probably be way too slow (write speed), to be used at such high frame rates, without using complicated techniques to get round it.

Yep, no way they are using Flash as the video buffer memory.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #6 on: November 23, 2016, 12:04:39 pm »
Flash would probably be way too slow (write speed), to be used at such high frame rates, without using complicated techniques to get round it.

Yep, no way they are using Flash as the video buffer memory.
Fps1000 does use nand flash to directly store the data. Nand writes are fast, and chips typically have multiple banks and/or die to acheive fast write throughput for already-erased pages
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: de
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #7 on: November 23, 2016, 12:11:08 pm »
Flash would probably be way too slow (write speed), to be used at such high frame rates, without using complicated techniques to get round it.

Yep, no way they are using Flash as the video buffer memory.
Look at the pcb images: There is an STM32, a Lattice FPGA, 2 flash chips and the sensor and some power supply stuff on the other side. No DRAM!
They use 2x 128GBit flash ics:
https://www.micron.com/parts/nand-flash/mass-storage/mt29f128g08amcabh2-10z?pc=%7BB0761936-6571-4FB2-AAE2-6756F4D7E4E0%7D
It is pretty much a toy compared to the Chronos Camera.
 

Offline jeremy

  • Super Contributor
  • ***
  • Posts: 1079
  • Country: au
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #8 on: November 23, 2016, 12:41:07 pm »
Anyone know if the fpga bits will be open source? I can't afford a camera like this, but I'd be very interested to see how it is actually implemented.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #9 on: November 23, 2016, 12:50:07 pm »
Surely if the FPS1000 was designed by a reasonably competent electronics engineer. It would be using Dram or Sram, for unlimited read/write cycles. (EDIT: That was when I thought the life was only a 1,000 or few, now I know it is >=60,000 it does not seem such a bad decision).

But on the other hand, a quick glance at the Flash, seems to indicate that it has a write life of 100,000 cycles. (SLC Nand)

Assuming 1 minute per complete write.

100,000 60,000 minutes = Approx 10 6 weeks at 24/7.

So 10 weeks of continuous use, is not too bad. But I would still prefer Dram/Sram.

The Micron site wants me to register in order to see the datasheet, so ...
I don't want to do that.

Ok I registered, and got the datasheet.

So the 100,000 60,000 life I gave above (from a site which DOES NOT need registering), could be wrong.
A quick look at the datasheet, seems to say that it is 60,000 program/erase cycles.

Quote
Quality and reliability
– Data retention: JESD47G compliant; see qualification
report
– Endurance: 60,000 PROGRAM/ERASE cycles
« Last Edit: November 23, 2016, 12:54:59 pm by MK14 »
 
The following users thanked this post: thm_w

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1910
  • Country: ca
    • General Repair and Support
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #10 on: November 23, 2016, 12:58:54 pm »
I'd love to see some slow-mo speaker cone dance and drop coalesce, with electronics chemicals like IPA and glycol.
 
 
The following users thanked this post: MT, MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #11 on: November 23, 2016, 01:14:37 pm »
I'd love to see some slow-mo speaker cone dance and drop coalesce, with electronics chemicals like IPA and glycol.

Thanks, that is quite an amazing video.
Especially the space video, later on in it, and the cello.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #12 on: November 23, 2016, 01:23:40 pm »
Flash would probably be way too slow (write speed), to be used at such high frame rates, without using complicated techniques to get round it.

Yep, no way they are using Flash as the video buffer memory.

I still don't understand why they did not just put in some Dram chips. The FPGA could surely cope, and they are reasonably cheap, readily available, in large capacities if needed. They are also very fast, if used correctly.
 

Offline bktemp

  • Super Contributor
  • ***
  • Posts: 1616
  • Country: de
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #13 on: November 23, 2016, 01:40:50 pm »
I still don't understand why they did not just put in some Dram chips. The FPGA could surely cope, and they are reasonably cheap, readily available, in large capacities if needed. They are also very fast, if used correctly.
Because it is more expensive: DRAM needs refreshs. You also need to read the data from DRAM and copy it to flash at some point, so you need DRAM + flash.
The fps1000 camera is build down to a price. Just compare the main components used in Chronos and fps1000: TI SoC running linux vs. STM32, Lattice FPGA (I don't know the exact part number of hand, but it is a larger one) vs. Lattice MachXO2 (low end FPGA).
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 4527
  • Country: gb
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #14 on: November 23, 2016, 02:05:56 pm »
I still don't understand why they did not just put in some Dram chips. The FPGA could surely cope, and they are reasonably cheap, readily available, in large capacities if needed. They are also very fast, if used correctly.
Because it is more expensive: DRAM needs refreshs. You also need to read the data from DRAM and copy it to flash at some point, so you need DRAM + flash.
The fps1000 camera is build down to a price. Just compare the main components used in Chronos and fps1000: TI SoC running linux vs. STM32, Lattice FPGA (I don't know the exact part number of hand, but it is a larger one) vs. Lattice MachXO2 (low end FPGA).

They seem to be a VERY expensive type of Flash chip, that they have used, and there are two of them (apparently).
They are not the cheap flash pen type of flash chip. They seem to be the type used in high endurance, very high performance server type SSD drives/PCI devices. Which are very expensive.

The refresh was NOT mentioned by me, because I assumed that the writing to it, was continuous (normally), and serially linear. Which should not need refreshing, since it is continually cycling between the various address rows/columns.
Just make sure that the least significant address bits, are the ones which are used for the refresh (rows probably, else columns).
When not in use, the FPGA or micro, could keep the refresh going.

As long as the FPGA that they used (fps1000) is up to the task, it should be ok.

But I do agree with you. Very large capacities of Drams, can be expensive, bigger FPGAs can be more useful and Dram refresh is a pain (but not too difficult to handle, if you are reasonably competent at electronics/software).

I got a bit confused with the Drams, because I am so use to the types used in PCs, being readily available at reasonable prices. But that is because it is used in such huge quantities, which keeps the prices down.

Small scale production, can't buy Drams at such huge quantities, so the price goes up, and they can't get any special deals or get the ones, which are only sold to big users of drams (speculation).

Compared to cheap flash types, I agree Dram is probably a fair bit more expensive.
 

Offline boffin

  • Supporter
  • ****
  • Posts: 1027
  • Country: ca
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #15 on: November 23, 2016, 03:58:11 pm »
Awesome product; I want one even thought I have zero need for it.

Bonus, looks like the guy lives really close to me (I instantly recognized streets when he was doing his electric car drive) - I wonder if he needs any help
 

Offline BobC

  • Supporter
  • ****
  • Posts: 119
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #16 on: November 23, 2016, 09:42:19 pm »
Just after the turn of the millennium I was involved in creating the Redlake HG-100K camera (Google it if you are curious), a super high-end camera capable of taking video at up to 100K FPS while being subjected to repeated 100G impacts.  It too used C-mount lenses, which generally tore right off during extremely violent events, with no damage to the camera.

It was designed to serve two main markets: Being inside cars during crash tests (it had to survive being crushed), and being very, very close to weapons tests (it had to survive being literally blown away).

While none of the alpha builds could capture at full speed, the second beta camera could, and we found ourselves running around the lab trying to find something we could shoot at 100K FPS.  We needed a small extremely fast moving target with tons of light.

We tried the conventional "pop the water balloon" test, but that gets boring at 2K FPS, and we couldn't come close to getting enough light past 10K FPS.  We shot directly at a fluorescent bulb, but that got boring at 5K FPS, though we did get useful captures at 30K FPS.

But fully illuminated 100K captures eluded us.  We considered aiming it straight at the sun, but elected to not melt our first working camera.  We held a meeting to work through the issue, with a powerpoint presentation to review all we had tried so far.  At the second slide we all looked at each other, then grabbed the projector and ran into the lab, where we took it apart to expose the bulb.

We slapped on a tele-macro lens and immediately got absolutely gorgeous video of the arc wandering within the bulb.  I ran it through some video analysis software to quantize how the arc volume, position and velocity changed with time, generated a quick data overlay, then posted the video on our website.

The next morning we got a call from Japan asking for an on-site visit.  The manufacturer of the projector we used was having optical path issues they had traced to the arc behavior, and they wanted to bring some prototype bulbs for us to image.  Of course we said yes, and their larger than expected team arrived two days later.  The Japanese scientists and executives were so impressed that they offered us an obscene amount of money to let them take one of the beta units home.  I mean really obscene.  Of course we said yes!  Our very first production unit went to them so we could get the beta unit back.

One of the things we had learned with prior high-speed digital cameras was the importance of good IR filtering.  We didn't have bright and cool LED lighting at the time, so we were using arc lamps, which generate a ton of IR.  Most lenses are more than willing to focus IR right onto your sensor, which will promptly overheat and melt.  We didn't let that happen, of course, since we had the foresight to build temperature sensors into our custom imager die.

Yes, we had to design custom silicon for this beast, and we went to the top pixel designers on the planet (at the time) to handle our needs.  Until then, all cameras above 1K FPS (including our own) used CCDs.  We wanted to go with CMOS for several reasons, but we needed to confront many issues to do so, the most important being pixel noise, shutter control, and readout issues.  The sensor had many more readout channels than any other CMOS sensor of the day.  It also had multiple shutter modes (including rolling and global).

The most critical decision was what foundry and feature size to use.  We intentionally went with a prior-generation feature size at a foundry that had truly mastered it, which not only reduced our risks, but also gave us a far better sensor in the end.

We also had to consider what to put on top of the silicon.  We needed microlenses to improve light gathering, and we wanted the option of a Bayer mask for color imaging (we got triple resolution and quadruple sensitivity in monochrome, but almost everyone wanted color).

Once the overall system design was finalized, my job became the design and implementation of the software control interfaces within the camera: The outward-facing interface (protocol/API) for our GUI control app and the customer's industrial automation software to access, and the inward-facing interfaces to the imaging pipeline control FPGAs and other hardware subsystems such as the Ethernet controller, video encoder, and so on.

The GUI team was working extremely hard to find ways to intelligently provide access to the huge number of camera features.  The external camera interface evolved at a rapid pace to support them.  Many camera settings had useful ranges that varied based on the values of other settings. The overall state machine was a true nightmare, far beyond what the GUI folks could support in a reasonable amount of time (and impossible, truth be told, since the camera FPGAs were still being tweaked).

We needed the camera to provide an "always valid" operational state, which meant returning errors when the user tried to change a parameter to a value that would cause an invalid configuration.  But this made the configuration process extremely delicate and error-prone.  We needed a way to interactively "evolve" the configuration past/through temporarily invalid intermediate configuration states.

So I abstracted the external API to permit it to virtualize itself and provide a "What if?" configuration mode that the GUI could use to provide error-free interactive feedback to the user.  This required minor FPGA changes to support a "try but don't die" configuration mode, which later turned out to have extremely valuable uses beyond the initial camera configuration.

I also wrote the software for the production test gigs, which was a total blast.  We needed to keep things simple for the assemblers and testers while collecting a ton of data for QA and QC purposes, the initial goal being to rapidly evolve our design during the first production run to make it easier and cheaper to manufacture.

Unfortunately, the flood of pre-orders we expected (and were counting upon) failed to materialize, and the company had to sell itself to get the funds needed to push the HG-100K into production.  After which the entire engineering department was laid off, since the new owner wanted only the existing products, not the development team.

I did make one big mistake a month after the layoff: I was offered a lucrative short-term consulting contract, which I turned down out of spite.  Silly and stupid, for multiple reasons.  It would have taken the pressure off my job search while letting me once again work on a product I loved, neither of which had anything to do with the new owners. Who weren't bad folks: They did offer jobs with relocation benefits to our entire production team and to most of the customer support / field engineering team.

I suppose I should take a look at the Chronos hardware and software...
 
The following users thanked this post: tesla500, firewalker, jeremy, fpliuzzi, amirm, lukier, albert22, laneboysrc, MT, kalleboo, newbrain, MK14

Online Bud

  • Super Contributor
  • ***
  • Posts: 6877
  • Country: ca
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #17 on: November 24, 2016, 12:09:29 am »
I'd love to see some slow-mo speaker cone dance and drop coalesce, with electronics chemicals like IPA and glycol.


i hope this guy will rot in Hell for injecting the stupid color table every few  seconds into the video. Good example how one should not make videos  :rant:
Facebook-free life and Rigol-free shack.
 

Offline tesla500

  • Regular Contributor
  • *
  • Posts: 149
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #18 on: November 24, 2016, 03:27:56 am »
Just after the turn of the millennium I was involved in creating the Redlake HG-100K camera (Google it if you are curious), a super high-end camera capable of taking video at up to 100K FPS while being subjected to repeated 100G impacts.  It too used C-mount lenses, which generally tore right off during extremely violent events, with no damage to the camera.
....

Wow! I absolutely love industry behind the scenes stories like this! Thanks very much!

This was before Vision Research had really taken off, wasn't it?

1504 x 1128 1000fps was really good for that time. How many readout channels did you end up using? I'm surprised you didn't get many orders. Too expensive?

David
 

Offline joeqsmith

  • Super Contributor
  • ***
  • Posts: 11632
  • Country: us
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #19 on: November 24, 2016, 04:16:30 am »
Dave, I watched your review (along with most of the videos I could find on youtube for it).  I am interested in this camera as a lab tool but I am not sure if it would be much better than your Sony for what I want to do with it.    I would be very interested in seeing some clips of it compared with the Sony looking at some arcs. 

https://www.youtube.com/watch?v=cC6fMnjqY8o&feature=youtu.be

Offline BobC

  • Supporter
  • ****
  • Posts: 119
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #20 on: November 24, 2016, 05:40:36 am »
This was before Vision Research had really taken off, wasn't it?

1504 x 1128 1000fps was really good for that time. How many readout channels did you end up using? I'm surprised you didn't get many orders. Too expensive?

Well, what killed us was Photon.  Turned out they used the same sensor designers we did.  Their resulting camera was inferior to the HG-100K, but it covered 90% of our market with 80% of our specs for 50% of the price.  Plus they had a much larger distributor infrastructure and better funded marketing.  We simply weren't far enough ahead in technology to warrant a premium price, and revenue projections showed it.

The line was eventually profitable in the ruggedized and high-G markets, since we never lied about our environmental specs, and pretty much everyone else did.  The HG-100K was built to military standards, and it had the best warranty by far.

If the HG-100K had any functional issues, it was simply that it was heavy.  In an early car crash test one was ripped from its mount.  The customer had to design new mounts, which was already on their to-do list.  Seeing the camera come loose at 50 MPH and fly across the lab certainly caused some hearts to stop, but the camera was good to go after a lens swap.  Our cables were designed to separate outside the camera, so the connectors had no damage.

And no video was lost!  The camera stopped recording when the cables separated, but a small internal battery kept the DRAM alive for up to 24 hours, so they had lots of time to go get the camera, dust it off, hook it up and then download the video.

Crash tests are extremely expensive: Losing data is NOT an option, no matter what, and I believe the HG-100K was the only camera that delivered 100% in that area.
 
The following users thanked this post: tesla500, kalleboo, newbrain, zrq

Offline edy

  • Super Contributor
  • ***
  • Posts: 2385
  • Country: ca
    • DevHackMod Channel
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #21 on: November 25, 2016, 04:37:54 am »
Awesome camera! I was wondering what you thought of this idea. Parallax issues aside, would it be feasible to take say get an array of 20 cameras recording the same scene at 60 fps but have them each start at a delayed time from the next by 1/20th of a 1/60th of a second... so basically they are recording the same scene but out of sync by 1/180th of a second from each other.

So camera 1 takes frame 1 at time 0/180 seconds, camera 2 takes frame 1 at time 1/180, camera 3 at 2/180, etc.... until camera 20 is at time 19/180 of the first second. Then camera 1 takes it's 2nd frame at 20/180 (or 1/60), camera 2 takes frame 2 at time 21/180, etc.... So you are parallel capturing at 1/60th of a second but using slightly out of sync cameras so in effect you are getting 180 fps. It's not much, but may be a technique to ramp up speed of capture with cheaper components.
YouTube: www.devhackmod.com LBRY: https://lbry.tv/@winegaming:b Bandcamp Music Link
"Ye cannae change the laws of physics, captain" - Scotty
 

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1910
  • Country: ca
    • General Repair and Support
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #22 on: November 25, 2016, 08:23:45 pm »
Awesome camera! I was wondering what you thought of this idea. Parallax issues aside, would it be feasible to take say get an array of 20 cameras recording the same scene at 60 fps but have them each start at a delayed time from the next by 1/20th of a 1/60th of a second... so basically they are recording the same scene but out of sync by 1/180th of a second from each other.

So camera 1 takes frame 1 at time 0/180 seconds, camera 2 takes frame 1 at time 1/180, camera 3 at 2/180, etc.... until camera 20 is at time 19/180 of the first second. Then camera 1 takes it's 2nd frame at 20/180 (or 1/60), camera 2 takes frame 2 at time 21/180, etc.... So you are parallel capturing at 1/60th of a second but using slightly out of sync cameras so in effect you are getting 180 fps. It's not much, but may be a technique to ramp up speed of capture with cheaper components.
Appears futile. Reassembly from compressed would likely be a processing nightmare, as would white balance symmetry, and cheaper consumo-grade cams lack the oomph to save raw format. Parallax and shutter sync are issues that just can't be brushed aside. Where would one get that many cams and tripods so easily? The resultant production might look cool though.. or jittery like a silent film?
 

Offline amirm

  • Regular Contributor
  • *
  • Posts: 122
  • Country: us
    • Audio Science Review
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #23 on: November 25, 2016, 10:24:29 pm »
Where would one get that many cams and tripods so easily? The resultant production might look cool though.. or jittery like a silent film?
That is routinely done in professional world for "matrix like" effects.  Here is an example:



De-warping would mostly work for what he is proposing but this many cameras will still be quite expensive and major hassle to set up for typical youtube like videos.
 
The following users thanked this post: Cliff Matthews

Offline Cliff Matthews

  • Supporter
  • ****
  • Posts: 1910
  • Country: ca
    • General Repair and Support
Re: EEVblog #947 - Chronos High Speed Camera Review
« Reply #24 on: November 26, 2016, 01:49:36 am »
Where would one get that many cams and tripods so easily? The resultant production might look cool though.. or jittery like a silent film?
That is routinely done in professional world for "matrix like" effects. 
De-warping would mostly work for what he is proposing but this many cameras will still be quite expensive and major hassle to set up for typical youtube like videos.
Well I stand corrected..  :palm: Searches on "Pluraleyes vs DreamSync" bring up vids on nifty specialist camera arrays and such. I suppose one could make a plexiglass 24" cylindrical blast container with 8 HS cams looking down on bursting TO-220's and rocketing el-caps.. after a while though, it may get old. Also, Dave might develop grey hair waiting for GB's of sync-age to happen.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf