High-speed camera - First video!
tesla500, Mon Feb 11 2008, 07:10AMEver since seeing high-speed shots on Mythbusters, I just had to have a high-speed camera. However, base models start at about $12,000, obviously way too expensive. So, I decided to make my own. Mike's high-speed camera controller over at electricstuff.co.uk gave me a lot of inspiration to try this. This is my first significant project in programmable logic devices, I did a little bit of work with PAL chips when I was at BCIT. This whole project has been a tremendous learning experience.
The image sensor I used is made by Cypress semiconductor. For this relatively cheap camera I chose the LUPA-300. This sensor is capable of 640x480 @ 250fps, and increased speed at lower resolution, eg. 320x240 @ 940fps. For more info, see the datasheet. It has internal ADCs, and outputs data as 10-bit words at 80MHz. Cypress also makes a much larger sensor, 1280x1024 @ 450fps, but the FPGA dev board I have can't support the 160 bit data bus that would come off the 16 ADCs. I may try that sensor in a later project.
This camera is based on a Xilinx Spartan-3A FPGA development board. It has a 700K gate equiv. FPGA, as well as lots of nice hardware, such as 64MB of DDR2 RAM, a 10/100 ethernet PHY, VGA and serial ports. The sensor is mounted on a small board that plugs into the expansion port. The image sensor digital IO runs at 2.5V, and the FPGA IO runs at 3.3V on this board. Some high-speed level translators are used for signals going from FPGA to sensor, and sensor outputs are connected directly to the FPGA. The IO pins on the FPGA can be programmed to take virtually any logic level in, regardless of IO bank supply voltage.
I'm currently relatively far along in this project, I recently reached a major milestone, the first image displayed.
Parts completed include:
- VGA timing generator
- Display hardware to buffer data out of RAM and display it on the VGA output
- DDR2 controller and access arbiter (gives multiple systems prioritized access to RAM)
- Embedded Microblaze CPU for control
- Microblaze to DDR2 Ram access hardware
- Basic Ethernet MAC (no CSMA/CD, so direct link or switched networks only, no hubs)
- Hardware to read data from the sensor and write it to RAM
I'll go through the basic operation of each piece of hardware, if you want specifics, don't hesitate to ask.
VGA timing generator:
Simple set of counters and value comparators that generate H and V sync signals and X and Y position outputs.
VGA display hardware:
This has two functions, to get image data out of RAM for display, and to give a text display for status information. Registers are available to set where to pull image data out of ram, what size of frame the data should be interpreted as, where it should be displayed, and what zoom level. Zooms of 1x to 4x are supported.
The text display provides a RAM to write ASCII text into, and the hardware takes care of displaying the characters.
DDR2 Controller:
This is simply code generated by the Memory Interface Generator provided by Xilinx. It converts the double data rate interface of the RAM into a single data rate one for ease of use in the FPGA, and takes care of refreshing the memory. The RAM is 16 bits wide, running at its minimum rated clock speed of 125MHz. Considering the DDR nature of the data, this give about 500MB/sec read or write speed.
DDR2 Arbiter:
Allows the various systems to all have access to ram, in a prioritized manner. For example, accesses from the display hardware have a higher priority than accesses from the CPU, to ensure the line buffer always gets loaded in time.
Embedded CPU:
Microblaze CPU core that comes with the Embedded Development Kit. It's RISC CPU running at 80MHz, with a rather small 28k of internal memory available. It will basically run the show, controlling all the hardware.
Ethernet MAC:
A simple Ethernet media access controller, which communicates with the physical layer chip, and provides buffers for transmit and receive data. I haven't implemented CSMA/CD yet, so it cannot be used on hub based networks.
Sensor image data write:
Buffers data off the sensor in a FIFO and periodically empties the FIFO into the main RAM. Destination address in RAM is set by a register accessible from the CPU. Data comes off the sensor at just under 80MB/sec at full speed.
There's still lots of work to do before I can take any video, but it's getting closer. The hardware is nearing completion, most of the work left is software for the Microblaze CPU. I need to write code for the Ethernet interface to download video off the camera, and code to set image sensor modes, start and stop recording, etc. I also have parts on order to make a lens mount, to hold standard C-mount lenses.
Here are some pictures of the hardware setup:
FPGA board
Sensor Board front. Due to a problem with the file I sent the PCB manufacturer, the ground plane wasn't produced, so I had to run wires around to all the ground connections.
Sensor board back. Lots of bypass caps for various supplies. Probably way overkill, but it couldn't hurt.
First image. A bug in the sensor data write hardware is causing some lines to be written to the wrong address in RAM. The lens also flips the image upside down, I need to set a register in the sensor to reverse Y readout.
Bug fixed after about 8 hours debugging
Stay tuned for updates.
#--------------------------------------- ------------------------------------
Update: Feb 14th, 2008
Quite a bit of progress in the last few days. I got the SPI hooked up to the image sensor, and am finally able to change registers in the sensor.
I'm currently working on a tough problem with the interrupts for VGA V-blank start and image sensor end of frame. The interrupt status and enable registers are not being read properly for some reason, so I can't tell what interrupt has occurred when the ISR is executed.
I also added 4 bits to each resistor DAC for the VGA port, the FPGA board only had 4 bits per color.
#----------------------------------------- ----------------------------------
Update: Feb 20th, 2008
Fixed the problem with the interrupts, it had to do with leaving data on the data bus when a read wasn't requested.
Fixed pattern noise (FPN) correction is now implemented in hardware, offsets for each pixel are subtracted in real-time as the data comes off the image sensor. I also did a software implementation to test how well it would work, that took about 8 seconds per frame, the hardware does it at 250fps.
I'm beginning to have problems getting everything to fit on this FPGA and meet timing. As the chip gets full, routing gets less and less optimal, increasing delays and reducing the maximum clock speed.
The software is far enough along to make recordings, but there's no way to download video off the camera yet.
#------------------------------------------- --------------------------------
Update: Feb 23rd, 2008
Major milestone - the first recording downloaded off the camera:
Spinning up a top and dropping it
Video 1 (1.5MB, XviD)
Record mode: 320x240 940fps, 457uS exposure time, playback rate 30fps
Lighting: 2 * 100W Halogen ~40cm away
I've got a very basic command line program working that allows the PC to query the camera for what video it has in memory, download frames off and save them as an uncompressed AVI. It's still buggy, if a packet is dropped it gets stuck it has to be restarted, but I couldn't resist making a recording.
The next priority will be a proper lens mount, the lens system currently consists of a 15mm f/3.2 lens out of a microfiche, taped to the top of a Lego motor. The main part for the proper lens mount finally came in today: an M42 to C-mount adapter. It's basically a flat plate with a 1" female C-mount thread inside and a 42mm dia. male thread on the outside. I'm going to drill and tap holes in it and screw it to an aluminum plate that will be mounted in front of the sensor board. I'm still waiting for the lens to come in, though.
#---------------------------------------- -----------------------------------
Update: March 6th, 2008
Got the lens mount done, so the camera is now practical to use. See the videos thread here.
Lens and dev board mount attached to a tripod
David
Re: High-speed camera - First video!
Wolfram, Mon Feb 11 2008, 08:44AM
Very impressive. I'll definitely keep an eye out on this thread.
Where did you buy the image sensor?
Anders M.
Wolfram, Mon Feb 11 2008, 08:44AM
Very impressive. I'll definitely keep an eye out on this thread.
Where did you buy the image sensor?
Anders M.
Re: High-speed camera - First video!
tesla500, Mon Feb 11 2008, 10:32PM
Thanks Anders!
I got the sensor from Avnet, they just recently began stocking it. Cost was about $300.
David
tesla500, Mon Feb 11 2008, 10:32PM
Thanks Anders!
I got the sensor from Avnet, they just recently began stocking it. Cost was about $300.
David
Re: High-speed camera - First video!
WaveRider, Tue Feb 12 2008, 08:52AM
Impressive indeed! Did you get your images without any lenses in front of your sensor?
WaveRider, Tue Feb 12 2008, 08:52AM
Impressive indeed! Did you get your images without any lenses in front of your sensor?
Re: High-speed camera - First video!
tesla500, Tue Feb 12 2008, 07:44PM
I was using an old lens off a 16mm film projector for those test images, just sitting it in front of the sensor. The focal length of that lens is 50mm, so it was zoomed in way too far. An object 10cm wide about 1m away filled the whole frame.
David
tesla500, Tue Feb 12 2008, 07:44PM
I was using an old lens off a 16mm film projector for those test images, just sitting it in front of the sensor. The focal length of that lens is 50mm, so it was zoomed in way too far. An object 10cm wide about 1m away filled the whole frame.
David
Re: High-speed camera - First video!
Dago, Thu Feb 14 2008, 06:35PM
Very impressive, great work.
Dago, Thu Feb 14 2008, 06:35PM
Very impressive, great work.
Re: High-speed camera - First video!
tesla500, Sat Feb 23 2008, 09:31AM
Major milestone, the first video. See the bottom of the first post.
tesla500, Sat Feb 23 2008, 09:31AM
Major milestone, the first video. See the bottom of the first post.
Re: High-speed camera - First video!
Dalus, Sat Feb 23 2008, 10:22AM
Do they come in kits
Congrats on your first high speed camera.
Dalus, Sat Feb 23 2008, 10:22AM
Do they come in kits
Congrats on your first high speed camera.Re: High-speed camera - First video!
Wolfram, Sat Feb 23 2008, 12:45PM
Wow, the video quality is excellent for 940FPS. I'm very impressed at how far you have gotten in this short time. Are you going to publish board layouts, code and HDL when the project is finished?
Anders M.
Wolfram, Sat Feb 23 2008, 12:45PM
Wow, the video quality is excellent for 940FPS. I'm very impressed at how far you have gotten in this short time. Are you going to publish board layouts, code and HDL when the project is finished?
Anders M.
Re: High-speed camera - First video!
..., Sat Feb 23 2008, 05:30PM
That is very impressive! 1kpfs camers for probably $500 in parts is no easy feat :o
Congrats on the video!
..., Sat Feb 23 2008, 05:30PM
That is very impressive! 1kpfs camers for probably $500 in parts is no easy feat :o
Congrats on the video!
Re: High-speed camera - First video!
tesla500, Sun Feb 24 2008, 07:41AM
Thanks guys!
Once I get the project to a more completed state I'll post all the design info.
Progress has been fast lately as I've just gotten out of school, and have been looking for a job. I recently found one, I start this Monday actually, so progress probably won't be quite as fast anymore. I started on this project about a year ago, and I slowly got most of the subsystems built, like the RAM controller, Ethernet, and the embedded CPU. So most of the stuff required was already done when I posted here about the project.
David
tesla500, Sun Feb 24 2008, 07:41AM
Thanks guys!
Once I get the project to a more completed state I'll post all the design info.
Progress has been fast lately as I've just gotten out of school, and have been looking for a job. I recently found one, I start this Monday actually, so progress probably won't be quite as fast anymore. I started on this project about a year ago, and I slowly got most of the subsystems built, like the RAM controller, Ethernet, and the embedded CPU. So most of the stuff required was already done when I posted here about the project.
David
Re: High-speed camera - First video!
Bjørn, Sun Feb 24 2008, 03:58PM
This is a very good project, well done.
There is some slight flickering in the video, I assume it is caused by the light source.
Would you consider adding some outputs that goes high in sequence, changing with every frame? My idea is to slightly modulate the colour of the light source between frames, That way it is possible to make a "colour" movie without any loss of framerate or increase in data size.
Bjørn, Sun Feb 24 2008, 03:58PM
This is a very good project, well done.
There is some slight flickering in the video, I assume it is caused by the light source.
Would you consider adding some outputs that goes high in sequence, changing with every frame? My idea is to slightly modulate the colour of the light source between frames, That way it is possible to make a "colour" movie without any loss of framerate or increase in data size.
Re: High-speed camera - First video!
tesla500, Sun Feb 24 2008, 06:49PM
Yes, the flickering was due to the lights. The halogen lamps I used must have very thin filaments, so they change temperature significantly throughout the AC cycle.
Your idea of cycling through colored lights is interesting. In fact, one standard that was in competition with NTSC proposed such a system, but with rotating color filters in front of the camera and CRT display. Reconstructing the color would be easy for static sections of the image, but would require some sort of motion vector compensation to translate pixels over to keep up with fast moving objects.
The easier way to to color is to get the color version of the image sensor I used. It has a Bayer color pattern, which almost all color image sensors use. Basically, half the pixels are green, 1/4 red and 1/4 blue, arranged in the following format:
RGRG . . .
GBGB . . .
RGRG . . .
GBGB . . .
. . . .
. . . .
. . . .
This way, the data rate and resolution are the same as with the monochrome sensor. With an interpolation algorithm, you can recover RGB values for each pixel, with very good quality. I would have gone for a color sensor, but this FPGA isn't big enough to do the interpolation real-time for the live preview, and doing it in software would be very slow.
David
tesla500, Sun Feb 24 2008, 06:49PM
Yes, the flickering was due to the lights. The halogen lamps I used must have very thin filaments, so they change temperature significantly throughout the AC cycle.
Your idea of cycling through colored lights is interesting. In fact, one standard that was in competition with NTSC proposed such a system, but with rotating color filters in front of the camera and CRT display. Reconstructing the color would be easy for static sections of the image, but would require some sort of motion vector compensation to translate pixels over to keep up with fast moving objects.
The easier way to to color is to get the color version of the image sensor I used. It has a Bayer color pattern, which almost all color image sensors use. Basically, half the pixels are green, 1/4 red and 1/4 blue, arranged in the following format:
RGRG . . .
GBGB . . .
RGRG . . .
GBGB . . .
. . . .
. . . .
. . . .
This way, the data rate and resolution are the same as with the monochrome sensor. With an interpolation algorithm, you can recover RGB values for each pixel, with very good quality. I would have gone for a color sensor, but this FPGA isn't big enough to do the interpolation real-time for the live preview, and doing it in software would be very slow.
David
Re: High-speed camera - First video!
Dalus, Sun Feb 24 2008, 07:01PM
Why can't you keep the preview image in greyscale and let your pc do the interpolation.
Dalus, Sun Feb 24 2008, 07:01PM
Why can't you keep the preview image in greyscale and let your pc do the interpolation.
Re: High-speed camera - First video!
Bjørn, Sun Feb 24 2008, 07:22PM
I like monochrome sensors. The colour filters must filter away most of the light so they will reduce sensitivity significantly both in visible and invisible wavelengths. And if I was going to use monochrome red light for some reason the resolution would be reduced significantly.
I don't agree completely that a PC is slow, in many cases it is faster than even quite large FPGAs. My CPU alone is capable of up to 40 GFLOPS, and the graphics card another 320 GFLOPS on top of that. A CPU can also use "trick" algorithms that needs far less computations than what is required with hardwired algorithms.
That is 625 floating point operations (on the CPU alone) for each pixel when running at 320x200 1000Hz. Unless the PC is really old there is hardly anything in the line of picture processing that will take any noticable time at this resolution.
Bjørn, Sun Feb 24 2008, 07:22PM
I like monochrome sensors. The colour filters must filter away most of the light so they will reduce sensitivity significantly both in visible and invisible wavelengths. And if I was going to use monochrome red light for some reason the resolution would be reduced significantly.
I don't agree completely that a PC is slow, in many cases it is faster than even quite large FPGAs. My CPU alone is capable of up to 40 GFLOPS, and the graphics card another 320 GFLOPS on top of that. A CPU can also use "trick" algorithms that needs far less computations than what is required with hardwired algorithms.
That is 625 floating point operations (on the CPU alone) for each pixel when running at 320x200 1000Hz. Unless the PC is really old there is hardly anything in the line of picture processing that will take any noticable time at this resolution.
Re: High-speed camera - First video!
tesla500, Sun Feb 24 2008, 09:03PM
You're right, color filters let through less than one third of the light. Monochrome sensors are definitely nice for high sensitivity. There will always be a trade-off somewhere when you want to capture color images, the best option is to have the a choice of either a monochrome or Bayer pattern sensor, depending on what you want to do with the camera.
The PC definitely is fast, I was referring to the 50MHz embedded CPU in the camera. Getting a live preview on the camera's monitor with in-camera software processing would be rather slow.
David
tesla500, Sun Feb 24 2008, 09:03PM
You're right, color filters let through less than one third of the light. Monochrome sensors are definitely nice for high sensitivity. There will always be a trade-off somewhere when you want to capture color images, the best option is to have the a choice of either a monochrome or Bayer pattern sensor, depending on what you want to do with the camera.
The PC definitely is fast, I was referring to the 50MHz embedded CPU in the camera. Getting a live preview on the camera's monitor with in-camera software processing would be rather slow.
David
Re: High-speed camera - First video!
Bjørn, Sun Feb 24 2008, 10:02PM
Yes, the Microblaze at 50 MHz would be slow for that sort of thing.
One other thing, what software are you using for the FPGA, Webpack ISE?
Bjørn, Sun Feb 24 2008, 10:02PM
Yes, the Microblaze at 50 MHz would be slow for that sort of thing.
One other thing, what software are you using for the FPGA, Webpack ISE?
Re: High-speed camera - First video!
tesla500, Mon Feb 25 2008, 06:13AM
I'm using the regular version of ISE, along with Synplify for synthesis, Chipscope for hardware debugging, and XPS for Microblaze. The Xilinx synthesizer is not all that good, it's slow, and produces worse logic compared to most 3rd party synthesizers. Chipscope is invaluable for debugging the hardware.
David
tesla500, Mon Feb 25 2008, 06:13AM
I'm using the regular version of ISE, along with Synplify for synthesis, Chipscope for hardware debugging, and XPS for Microblaze. The Xilinx synthesizer is not all that good, it's slow, and produces worse logic compared to most 3rd party synthesizers. Chipscope is invaluable for debugging the hardware.
David
Re: High-speed camera - First video!
mikeselectricstuff, Fri Mar 07 2008, 10:36PM
Nice project - as it is mostly based on a standard devboard, it would almost certainly be worthwhile for you to get some sensor PCBs made to sell - I'm sure there would be plenty of takers. The 64MB is a significant limitation though - it's really nice to have enough buffer to cope with human reaction time when something interesting happens..! Maybe look at using an alternative FPGA board with more RAM, or do a complete PCB with the RAM on as well...
Something else that may be worth thinking about - as HS material often has lots of 'nothing' outside the area of interest ( spacially or temporally speaking), I wonder of some sort of realtime compression might be viable - something simple like runlength or frame-to-frame deltas (although memory bandwidth may be an issue for the latter - maybe line-to-line?).
If FPGA space is getting tight I'd be inclined to ditch the microblaze out of the FPGA and use an extarnal MCU - the bandwidth to the MCU is going to be relatively minimal, so a simple SPI interface to something like an AVR or ARM should be more than adequate. It would also make it easier for others wanting to build their own & play with the software - Is it still the case that Xilinx charge for the Microblaze EDK? Even if you have to supply the FPGA stuff ready-made if the synth tools needed aren't readily availble, the software is probably what most people will want to play with..
Totally agree about colour - lighting high-speed stuff is hard enough without losing 2/3+ of it through the filters.
If anything, with a sensor as cheap (relatively..) as this, I'd be more tempted to build a dual-sensor system to get stereoscopic & multiple viewpoints. (how about a HS camera array for Matrix-style effects of fast events - this would be truly spectacular, and possibly something that nobody has done, even commercially..!)
Just wondering - did this project help you get the job? This is the sort of thing that ought to really impress an employer as it shows a wide variety of useful practical skills that are rare in the avarage college-leaver...
Take a look at the Micron MT9M413C36STM - same res, faster, on-chip ADCs, and cheaper. Stocked by Digikey.
mikeselectricstuff, Fri Mar 07 2008, 10:36PM
Nice project - as it is mostly based on a standard devboard, it would almost certainly be worthwhile for you to get some sensor PCBs made to sell - I'm sure there would be plenty of takers. The 64MB is a significant limitation though - it's really nice to have enough buffer to cope with human reaction time when something interesting happens..! Maybe look at using an alternative FPGA board with more RAM, or do a complete PCB with the RAM on as well...
Something else that may be worth thinking about - as HS material often has lots of 'nothing' outside the area of interest ( spacially or temporally speaking), I wonder of some sort of realtime compression might be viable - something simple like runlength or frame-to-frame deltas (although memory bandwidth may be an issue for the latter - maybe line-to-line?).
If FPGA space is getting tight I'd be inclined to ditch the microblaze out of the FPGA and use an extarnal MCU - the bandwidth to the MCU is going to be relatively minimal, so a simple SPI interface to something like an AVR or ARM should be more than adequate. It would also make it easier for others wanting to build their own & play with the software - Is it still the case that Xilinx charge for the Microblaze EDK? Even if you have to supply the FPGA stuff ready-made if the synth tools needed aren't readily availble, the software is probably what most people will want to play with..
Totally agree about colour - lighting high-speed stuff is hard enough without losing 2/3+ of it through the filters.
If anything, with a sensor as cheap (relatively..) as this, I'd be more tempted to build a dual-sensor system to get stereoscopic & multiple viewpoints. (how about a HS camera array for Matrix-style effects of fast events - this would be truly spectacular, and possibly something that nobody has done, even commercially..!)
Just wondering - did this project help you get the job? This is the sort of thing that ought to really impress an employer as it shows a wide variety of useful practical skills that are rare in the avarage college-leaver...
Just looked at the data for this - looks a pig to drive - it has no onboard ADCs so you'd need to hook 16 40msps ADCs to the outputs, and the O/P impedance is quite high so this would be an insane PCB layout task.
Cypress also makes a much larger sensor, 1280x1024 @ 450fps, but the FPGA dev board I have can't support the 160 bit data bus that would come off the 16 ADCs. I may try that sensor in a later project.
Take a look at the Micron MT9M413C36STM - same res, faster, on-chip ADCs, and cheaper. Stocked by Digikey.
Re: High-speed camera - First video!
tesla500, Sat Mar 08 2008, 07:47AM
Hi Mike, thanks!
I will definitely make some more sensor PCBs. Several people have asked for them, and it would be nice to have a couple or three of these cameras to get different frame rates and angles on events. I looked at various development boards, but anything that had more RAM than this, or better yet a standard RAM slot, cost about $2k. It would probably be best to just make a PCB with everything on it, with a proper RAM slot.
Real-time compression may be practical with a big enough FPGA, either with a simple algorithm, or full fledged MPEG. The data rate on this is similar to that of HDTV, so it seems reasonable that it could be done. 720P HDTV is about 60 megapixels per second, this sensor does about 80 megapixels per second. Although, given how cheap RAM is nowadays, compression seems less and less necessary.
The Microblaze is definitely way overkill for this application. During record all it really does is advance the frame write pointer when the sensor is done writing a frame. I tested implementing the design with the Microblaze commented out, and it took up about 20% instead of 76% of the FPGA. Xilinx still does charge for EDK, but the compiler is open source, so it may be possible to program it without having EDK.
The 8 bit Picoblaze would be more appropriate, but it lacks proper dev tools, I believe you need to reprogram the entire FPGA to change the code. The Picoblaze dev tools are free, including the C complier.
For stereoscopic/matrix effects, it would probably be best to make provisions to sync multiple cameras together, maybe with variable phasing. That would definitely lead to some very interesting shots, being able to "move" the camera around at otherwise impossible speeds.
This project may have helped me get the job, but I think it was mainly knowing some employees in the company through the local electric vehicle club. I have a friend who graduated about the same time as me, and he builds hobby projects at only a slightly lower level than this. He searched for six months and didn't find a related job, so it seems that employers really want a degree or job experience, rather than a diploma or hobby experience.
I have looked at the Micron MT9M413C36STM, but a major limitation is that you can only reduce the Y resolution to increase frame rate, because it has one ADC on each column. You can reduce both X and Y resolution on the Cypress sensors. For example, if you want 7,000fps, on the Micron sensor you'd have to run about 1280x72, while on the Cypress one you could run 320x240.
I recently saw a news release from Cypress saying they're going to release an upgraded version of the LUPA-1300 that will have internal ADCs and 12 LVDS outputs. I would defiantly wait for that one before attempting anything with the higher resolution sensors.
I was wondering, with your Kodak camera, is there significant fixed-pattern noise? Correcting the noise isn't difficult in a modern system, but it would have been extremely difficult on one that recorded directly to analog tape.
David
tesla500, Sat Mar 08 2008, 07:47AM
Hi Mike, thanks!
I will definitely make some more sensor PCBs. Several people have asked for them, and it would be nice to have a couple or three of these cameras to get different frame rates and angles on events. I looked at various development boards, but anything that had more RAM than this, or better yet a standard RAM slot, cost about $2k. It would probably be best to just make a PCB with everything on it, with a proper RAM slot.
Real-time compression may be practical with a big enough FPGA, either with a simple algorithm, or full fledged MPEG. The data rate on this is similar to that of HDTV, so it seems reasonable that it could be done. 720P HDTV is about 60 megapixels per second, this sensor does about 80 megapixels per second. Although, given how cheap RAM is nowadays, compression seems less and less necessary.
The Microblaze is definitely way overkill for this application. During record all it really does is advance the frame write pointer when the sensor is done writing a frame. I tested implementing the design with the Microblaze commented out, and it took up about 20% instead of 76% of the FPGA. Xilinx still does charge for EDK, but the compiler is open source, so it may be possible to program it without having EDK.
The 8 bit Picoblaze would be more appropriate, but it lacks proper dev tools, I believe you need to reprogram the entire FPGA to change the code. The Picoblaze dev tools are free, including the C complier.
For stereoscopic/matrix effects, it would probably be best to make provisions to sync multiple cameras together, maybe with variable phasing. That would definitely lead to some very interesting shots, being able to "move" the camera around at otherwise impossible speeds.
This project may have helped me get the job, but I think it was mainly knowing some employees in the company through the local electric vehicle club. I have a friend who graduated about the same time as me, and he builds hobby projects at only a slightly lower level than this. He searched for six months and didn't find a related job, so it seems that employers really want a degree or job experience, rather than a diploma or hobby experience.
I have looked at the Micron MT9M413C36STM, but a major limitation is that you can only reduce the Y resolution to increase frame rate, because it has one ADC on each column. You can reduce both X and Y resolution on the Cypress sensors. For example, if you want 7,000fps, on the Micron sensor you'd have to run about 1280x72, while on the Cypress one you could run 320x240.
I recently saw a news release from Cypress saying they're going to release an upgraded version of the LUPA-1300 that will have internal ADCs and 12 LVDS outputs. I would defiantly wait for that one before attempting anything with the higher resolution sensors.
I was wondering, with your Kodak camera, is there significant fixed-pattern noise? Correcting the noise isn't difficult in a modern system, but it would have been extremely difficult on one that recorded directly to analog tape.
David
Re: High-speed camera - First video!
Bjørn, Sat Mar 08 2008, 09:40AM
I would like to see a cheap version of this with the sensor and a small FPGA on the same PCB that can do realtime streaming to a PC for unlimited recording time.
I think most people would want only one unit and unlimited recording time and low price would be far more interesting than a stand alone unit.
With 20 MB/s over Hi-Speed USB only 4:1 compression is needed.
Bjørn, Sat Mar 08 2008, 09:40AM
I would like to see a cheap version of this with the sensor and a small FPGA on the same PCB that can do realtime streaming to a PC for unlimited recording time.
I think most people would want only one unit and unlimited recording time and low price would be far more interesting than a stand alone unit.
With 20 MB/s over Hi-Speed USB only 4:1 compression is needed.
Re: High-speed camera - First video!
mikeselectricstuff, Sat Mar 08 2008, 09:58AM
I think Picoblaze only uses a single memory port, so it shouldn't be hard to use the other port to send new code to it. However if you're doing a PCB for the sensor, putting something like an AVR on it would probably be worthwhile as it would only need a small handful of pins (SPI & a interrupt or two).
The new Cypress certainly one looks very interesting from what little info is available, but I'd guess we're talking pricetags in the $2K region. Let;s hope they stick to a PGA packaging - I really wouldn't fancy toaster-ovenning a $2K BGA....!
The nice thing about the one you used is that a complete system can be built for hobbyist prices. If I were you I'd definitely go for a complete PCB with a socket for a laptop DIMM module - I think there could be some serious money to be made once the software is in decent shape - if you open source the software then you'd likely get some free help on this side of things. Using an AVR for control would also make it more accessible for others to contribute, as well as freeing up FPGA resources.
If you don't fancy getting into the hardware business, I'm sure someone like Sparkfun would be interested in getting involved, however if you stick to PCB level, the up-front costs of getting PCBs assembled isn't a great deal & you should certainly be able to be into profit on a batch as small as 25 or so.
Would be good to keep the sensor on a small seperate PCB (unless you could find a suitable chip socket) to allow mono/colour sensors to be interchanged.
Might also be worth a chat with your Local Friendly Cypress Guy of you can find one - they may be interested in your design as a reference design/devboard, and once you're 'in the door' it might help in getting a sample of the new LUPA chip
.
Incidentally, Kodak used to do a low-res 500fps 128x101 sensor that was stupidly cheap ( abot $10!), but now appears to be discontinued.
Can't say I've noticed much FPN amongst the general noise, but I tend to use the intensified imager a lot of the time which is very noisy to start with, and has some of its own fixed patterning as it is fibre coupled. The Kodak camera has adjustments for each of the 16 analogue channels but I can't see any obvious correction facility for anything else in the hardware. The price these things originally sold for, I suppose they could have hand laser-trimmed (or just selected) the sensors...!
Is the FPN on the Cypress chip random across the whole array, or just in one dimension? As you say that FPN offsets are added, is it the case that FPN is mostly offset, or is there any noticeable gain patterning as well?
mikeselectricstuff, Sat Mar 08 2008, 09:58AM
wrote ...
Although, given how cheap RAM is nowadays, compression seems less and less necessary.
Totally agree - this comment was just in the context of what you can do with the existing FPGA board. Although, given how cheap RAM is nowadays, compression seems less and less necessary.
wrote ...
The 8 bit Picoblaze would be more appropriate, but it lacks proper dev tools, I believe you need to reprogram the entire FPGA to change the code. The Picoblaze dev tools are free, including the C complier.
I believe there are some 3rd-party tools, and an enhanced 3rd-party version called pacoblaze. As the code is stored in BRAM, I think that only the constant initialisation data changes, so it should be possible to make the compiler realise that no logic has changed. The 8 bit Picoblaze would be more appropriate, but it lacks proper dev tools, I believe you need to reprogram the entire FPGA to change the code. The Picoblaze dev tools are free, including the C complier.
I think Picoblaze only uses a single memory port, so it shouldn't be hard to use the other port to send new code to it. However if you're doing a PCB for the sensor, putting something like an AVR on it would probably be worthwhile as it would only need a small handful of pins (SPI & a interrupt or two).
wrote ...
I have looked at the Micron MT9M413C36STM, but a major limitation is that you can only reduce the Y resolution to increase frame rate, because it has one ADC on each column. You can reduce both X and Y resolution on the Cypress sensors. For example, if you want 7,000fps, on the Micron sensor you'd have to run about 1280x72, while on the Cypress one you could run 320x240
I recently saw a news release from Cypress saying they're going to release an upgraded version of the LUPA-1300 that will have internal ADCs and 12 LVDS outputs. I would defiantly wait for that one before attempting anything with the higher resolution sensors..
Yes, this is a significant limitation of the Micron chip - when I was originally looking at it I wasn't aware of the Cypress parts - may have been before they were available. I have looked at the Micron MT9M413C36STM, but a major limitation is that you can only reduce the Y resolution to increase frame rate, because it has one ADC on each column. You can reduce both X and Y resolution on the Cypress sensors. For example, if you want 7,000fps, on the Micron sensor you'd have to run about 1280x72, while on the Cypress one you could run 320x240
I recently saw a news release from Cypress saying they're going to release an upgraded version of the LUPA-1300 that will have internal ADCs and 12 LVDS outputs. I would defiantly wait for that one before attempting anything with the higher resolution sensors..
The new Cypress certainly one looks very interesting from what little info is available, but I'd guess we're talking pricetags in the $2K region. Let;s hope they stick to a PGA packaging - I really wouldn't fancy toaster-ovenning a $2K BGA....!
The nice thing about the one you used is that a complete system can be built for hobbyist prices. If I were you I'd definitely go for a complete PCB with a socket for a laptop DIMM module - I think there could be some serious money to be made once the software is in decent shape - if you open source the software then you'd likely get some free help on this side of things. Using an AVR for control would also make it more accessible for others to contribute, as well as freeing up FPGA resources.
If you don't fancy getting into the hardware business, I'm sure someone like Sparkfun would be interested in getting involved, however if you stick to PCB level, the up-front costs of getting PCBs assembled isn't a great deal & you should certainly be able to be into profit on a batch as small as 25 or so.
Would be good to keep the sensor on a small seperate PCB (unless you could find a suitable chip socket) to allow mono/colour sensors to be interchanged.
Might also be worth a chat with your Local Friendly Cypress Guy of you can find one - they may be interested in your design as a reference design/devboard, and once you're 'in the door' it might help in getting a sample of the new LUPA chip
.Incidentally, Kodak used to do a low-res 500fps 128x101 sensor that was stupidly cheap ( abot $10!), but now appears to be discontinued.
wrote ...
I was wondering, with your Kodak camera, is there significant fixed-pattern noise? Correcting the noise isn't difficult in a modern system, but it would have been extremely difficult on one that recorded directly to analog tape.
I was wondering, with your Kodak camera, is there significant fixed-pattern noise? Correcting the noise isn't difficult in a modern system, but it would have been extremely difficult on one that recorded directly to analog tape.
Can't say I've noticed much FPN amongst the general noise, but I tend to use the intensified imager a lot of the time which is very noisy to start with, and has some of its own fixed patterning as it is fibre coupled. The Kodak camera has adjustments for each of the 16 analogue channels but I can't see any obvious correction facility for anything else in the hardware. The price these things originally sold for, I suppose they could have hand laser-trimmed (or just selected) the sensors...!
Is the FPN on the Cypress chip random across the whole array, or just in one dimension? As you say that FPN offsets are added, is it the case that FPN is mostly offset, or is there any noticeable gain patterning as well?
Re: High-speed camera - First video!
Marko, Sat Mar 08 2008, 07:04PM
I should really be around and post more, things like these are not often seen here.
My first impression is probably, ''you need to have one hell of balls to airwire a ground plane around this darn-expensive IC, and never get wrong''!
I can't even think how it is to design and build a circuit like that and don't fear a second about blowing the expensive image sensor up.
Apart from admiration I can't really do much of useful comments, I'm completely ran over. Keep this work up sir! :O
Marko
Marko, Sat Mar 08 2008, 07:04PM
I should really be around and post more, things like these are not often seen here.
My first impression is probably, ''you need to have one hell of balls to airwire a ground plane around this darn-expensive IC, and never get wrong''!
I can't even think how it is to design and build a circuit like that and don't fear a second about blowing the expensive image sensor up.
Apart from admiration I can't really do much of useful comments, I'm completely ran over. Keep this work up sir! :O
Marko
Re: High-speed camera - First video!
mikeselectricstuff, Sat Mar 08 2008, 07:35PM
How realistic is streaming 20mbytes/sec to a PC without dropping frames? Or getting 4:1 compression within the resources of a cheap FPGA? If nothing else it would impose constraints on the performance level required of the PC. High-speed cams may often be used in outdoor and/or messy environments, so the ability to use any cheap old laptop etc. would be an advantage.
I'm not sure that the cost saving would worthwhile compared to the disadvantages of trying to ensure reliable high-speed streaming to a PC. The biggest cost is the sensor, and you need an FPGA and some sort of PC interface (USB2 or ethernet) anyway, so pretty much the only additional cost is the memory itself, which is pretty trivial these days.
For high-speed stuff, record time isn't often a major issue once you get over about 10 -20 seconds as you can use pre/post triggers to capture the time period of interest - a couple of GB RAM would usually be plenty - easily worth the $30-odd cost.
Not having to guarantee a particular streaming speed allows more flexibility in choice of interface, as the I/F speed becomes relatively unimportant.
If you wanted to cut things down to a minimum, you could maybe lose the VGA interface as you will never be able to display frames in real time, so the bandwidth limitation to a PC isn't a big deal, and even if it was a slow link, it would only affect preview/playback quality and not the quality of a sequence worth keeping.
Having local memory also means it is much more easily scalable for multiple cameras.
mikeselectricstuff, Sat Mar 08 2008, 07:35PM
Bjørn Bæverfjord wrote ...
I would like to see a cheap version of this with the sensor and a small FPGA on the same PCB that can do realtime streaming to a PC for unlimited recording time.
I think most people would want only one unit and unlimited recording time and low price would be far more interesting than a stand alone unit.
With 20 MB/s over Hi-Speed USB only 4:1 compression is needed.
I would like to see a cheap version of this with the sensor and a small FPGA on the same PCB that can do realtime streaming to a PC for unlimited recording time.
I think most people would want only one unit and unlimited recording time and low price would be far more interesting than a stand alone unit.
With 20 MB/s over Hi-Speed USB only 4:1 compression is needed.
How realistic is streaming 20mbytes/sec to a PC without dropping frames? Or getting 4:1 compression within the resources of a cheap FPGA? If nothing else it would impose constraints on the performance level required of the PC. High-speed cams may often be used in outdoor and/or messy environments, so the ability to use any cheap old laptop etc. would be an advantage.
I'm not sure that the cost saving would worthwhile compared to the disadvantages of trying to ensure reliable high-speed streaming to a PC. The biggest cost is the sensor, and you need an FPGA and some sort of PC interface (USB2 or ethernet) anyway, so pretty much the only additional cost is the memory itself, which is pretty trivial these days.
For high-speed stuff, record time isn't often a major issue once you get over about 10 -20 seconds as you can use pre/post triggers to capture the time period of interest - a couple of GB RAM would usually be plenty - easily worth the $30-odd cost.
Not having to guarantee a particular streaming speed allows more flexibility in choice of interface, as the I/F speed becomes relatively unimportant.
If you wanted to cut things down to a minimum, you could maybe lose the VGA interface as you will never be able to display frames in real time, so the bandwidth limitation to a PC isn't a big deal, and even if it was a slow link, it would only affect preview/playback quality and not the quality of a sequence worth keeping.
Having local memory also means it is much more easily scalable for multiple cameras.
Re: High-speed camera - First video!
Bjørn, Sat Mar 08 2008, 11:05PM
When it comes to cost saving you need one tiny PCB instead of one large one and one small one, probably with fewer layers too. You can use a far smaller FPGA with far fewer pins. It can run from USB power so no PSU. No connectors except the USB one (or ethernet).
Compared to where this project is heading I would say it would be half the price. If the sensors can be found cheaper somewhere the price would drop to a fraction of the stand alone unit.
Bjørn, Sat Mar 08 2008, 11:05PM
How realistic is streaming 20mbytes/sec to a PC without dropping frames?That is an interesting question that depends on a lot of factors. It depends on how much RAM there is in the FPGA , it will depend on the interface itself and the size of the FIFO, some have 64kB which would hold about 4 frames. And finally it depends on the driver and the PC. If there is a problem, a single RAM chip can be added to the board at very low cost.
Or getting 4:1 compression within the resources of a cheap FPGA?This should be simple even with a tiny FPGA. A wavelet transformation can be done with less than 3 addition pr pixel, that can be done with two adders. Then you need a quantization unit and a run-length encoder. It should use just a few percent of a medium size FPGA and should fit comfortably on a small one.
When it comes to cost saving you need one tiny PCB instead of one large one and one small one, probably with fewer layers too. You can use a far smaller FPGA with far fewer pins. It can run from USB power so no PSU. No connectors except the USB one (or ethernet).
Compared to where this project is heading I would say it would be half the price. If the sensors can be found cheaper somewhere the price would drop to a fraction of the stand alone unit.
Re: High-speed camera - First video!
mikeselectricstuff, Sat Mar 08 2008, 11:52PM
I doubt the sensors can be got much cheaper unless maybe a quantity deal (group buy) could be done or Cypress take an interest - this is a specialist device with little competition in a limited market.
PCB size is not particularly expensive, even with 6 layers - we're still only talking a few square inches. A SODIMM would be the way to go to allow easy upgrade and take advantage of PC market pricing.
The difference in cost of a FPGA with enough pins to run a DDR2 module is single digit dollars (and you may be able to offset some or all by using one with smaller gate/RAM count as it would need minimal buffering). RAM is so cheap it wouldn't be a major deal if you had to waste half of the data bus width to keep the pin count sensible.
I can't see the difference being more than $50 including the RAM, on something that would likely be in the $500 area by the time 1-off costs are included, so it doesn't really seem worth cutting corners & potentially inviting all sorts of PC compatibility issues and/or compromising the quality of the captured images.
mikeselectricstuff, Sat Mar 08 2008, 11:52PM
Bjørn Bæverfjord wrote ...
When it comes to cost saving you need one tiny PCB instead of one large one and one small one, probably with fewer layers too. You can use a far smaller FPGA with far fewer pins. It can run from USB power so no PSU. No connectors except the USB one (or ethernet).
Compared to where this project is heading I would say it would be half the price. If the sensors can be found cheaper somewhere the price would drop to a fraction of the stand alone unit.
I think it is a little premature to be predicting where this project is heading...!When it comes to cost saving you need one tiny PCB instead of one large one and one small one, probably with fewer layers too. You can use a far smaller FPGA with far fewer pins. It can run from USB power so no PSU. No connectors except the USB one (or ethernet).
Compared to where this project is heading I would say it would be half the price. If the sensors can be found cheaper somewhere the price would drop to a fraction of the stand alone unit.
I doubt the sensors can be got much cheaper unless maybe a quantity deal (group buy) could be done or Cypress take an interest - this is a specialist device with little competition in a limited market.
PCB size is not particularly expensive, even with 6 layers - we're still only talking a few square inches. A SODIMM would be the way to go to allow easy upgrade and take advantage of PC market pricing.
The difference in cost of a FPGA with enough pins to run a DDR2 module is single digit dollars (and you may be able to offset some or all by using one with smaller gate/RAM count as it would need minimal buffering). RAM is so cheap it wouldn't be a major deal if you had to waste half of the data bus width to keep the pin count sensible.
I can't see the difference being more than $50 including the RAM, on something that would likely be in the $500 area by the time 1-off costs are included, so it doesn't really seem worth cutting corners & potentially inviting all sorts of PC compatibility issues and/or compromising the quality of the captured images.
Re: High-speed camera - First video!
tesla500, Sun Mar 09 2008, 03:28AM
I think it would be best not to comprise functionality for relatively minimal cost savings. With an external microcontroller, a much smaller FPGA than the one on the dev board could be used.
An interface to a SODIMM looks like it would take 113 pins on the FPGA. An FPGA big enough to handle the sensor interface hardware, ethernet, and USB would be available in package with enough pins to interface with a SODIMM.
I came across the datasheet for the LUPA-1300-2. It's in a PGA package, albeit with 1.27mm pitch. The LVDS outputs run at 620Mbps, which may be a bit hairy.
Here's a comparison with and without FPN correction:
No FPN correction:
With FPN correction:
There does seem to be a slight gain discrepancy between pixels, but it's very minor and hard to notice. Offset correction seems to be sufficient.
David
tesla500, Sun Mar 09 2008, 03:28AM
I think it would be best not to comprise functionality for relatively minimal cost savings. With an external microcontroller, a much smaller FPGA than the one on the dev board could be used.
An interface to a SODIMM looks like it would take 113 pins on the FPGA. An FPGA big enough to handle the sensor interface hardware, ethernet, and USB would be available in package with enough pins to interface with a SODIMM.
I came across the datasheet for the LUPA-1300-2. It's in a PGA package, albeit with 1.27mm pitch. The LVDS outputs run at 620Mbps, which may be a bit hairy.
Is the FPN on the Cypress chip random across the whole array, or just in one dimension? As you say that FPN offsets are added, is it the case that FPN is mostly offset, or is there any noticeable gain patterning as well?The FPN seems to be have two parts, a component that is the same for each column, and a component that is completely random.
Here's a comparison with and without FPN correction:
No FPN correction:
With FPN correction:
There does seem to be a slight gain discrepancy between pixels, but it's very minor and hard to notice. Offset correction seems to be sufficient.
David
Re: High-speed camera - First video!
mikeselectricstuff, Sun Mar 09 2008, 01:21PM
Yes - this chip looks like being a lot more work to deal with. I'm not too familiar with LVDS capabilities on FPGAs, but I suspect that you'd be into Virtex territory to get something with sufficient LVDS deserialiser capability. The memory bus would probably need to get pretty wide to handle the bandwidth, especially if you wanted to make use of the multi-slope capabilities. And of course the PCB requirements would be an order of magnitude harder - BGAs, controlled impedance etc.
I think doing a LUPA-300 based system that could be built for $500 would be a far more satisfying (and possibly more profitable) achievement than a higher-res one for $5000 - a lot more people would be prepared to spend $500 on what for most people would be a fun 'toy' to play with...
One thought I had re. providing a cheap local display would be to have an interface for a PSP LCD - although you wouldn't get the full image resolution, if you ran in mono (maybe have seperate IOs for just the R,G,B MS bits to enable some colour for menus etc. - this is what I did on my system) it would only need a dozen or so pins, the memory bandwidth shouldn't impact much, and it's a nice size to integrate into a camera-shaped box - might be a nice compromise between full VGA and nothing. (Of course if there were sufficent pins, it would be nice to have the option of full colour to allow use with the colour version of the sensor.)
The option for a local LCD for aiming,focussing and playback review is a really nice feature to have, and having it on the camera itself would add a significant extra 'coolness' factor - add a battery and something like a VNC1L USB host interface you have a compact 'go-anywhere' HS camcorder - how cool would that be...!.
As these LCDs are readily available, assuming you have the IOs available, the only additional cost would be it would just be putting a suitable connector on the PCB.
I just had another thought on something that might be interesting to try - get the optics from an old 3CCD camera and fit 3 sensors in place of the CCDs. Full-res colour, or higher res at a given framerate for mono (compensating for different effective gain of r,g,b), or 3x the framerate by staggering the exposure timings between the sensors.
Just spotted this relatively low-cost FPGA board with a SODIMM socket - might be useful as a prototyping platform for a dedicated PCB.
mikeselectricstuff, Sun Mar 09 2008, 01:21PM
tesla500 wrote ...
I came across the datasheet for the LUPA-1300-2. It's in a PGA package, albeit with 1.27mm pitch. The LVDS outputs run at 620Mbps, which may be a bit hairy.
I came across the datasheet for the LUPA-1300-2. It's in a PGA package, albeit with 1.27mm pitch. The LVDS outputs run at 620Mbps, which may be a bit hairy.
Yes - this chip looks like being a lot more work to deal with. I'm not too familiar with LVDS capabilities on FPGAs, but I suspect that you'd be into Virtex territory to get something with sufficient LVDS deserialiser capability. The memory bus would probably need to get pretty wide to handle the bandwidth, especially if you wanted to make use of the multi-slope capabilities. And of course the PCB requirements would be an order of magnitude harder - BGAs, controlled impedance etc.
I think doing a LUPA-300 based system that could be built for $500 would be a far more satisfying (and possibly more profitable) achievement than a higher-res one for $5000 - a lot more people would be prepared to spend $500 on what for most people would be a fun 'toy' to play with...
One thought I had re. providing a cheap local display would be to have an interface for a PSP LCD - although you wouldn't get the full image resolution, if you ran in mono (maybe have seperate IOs for just the R,G,B MS bits to enable some colour for menus etc. - this is what I did on my system) it would only need a dozen or so pins, the memory bandwidth shouldn't impact much, and it's a nice size to integrate into a camera-shaped box - might be a nice compromise between full VGA and nothing. (Of course if there were sufficent pins, it would be nice to have the option of full colour to allow use with the colour version of the sensor.)
The option for a local LCD for aiming,focussing and playback review is a really nice feature to have, and having it on the camera itself would add a significant extra 'coolness' factor - add a battery and something like a VNC1L USB host interface you have a compact 'go-anywhere' HS camcorder - how cool would that be...!.
As these LCDs are readily available, assuming you have the IOs available, the only additional cost would be it would just be putting a suitable connector on the PCB.
I just had another thought on something that might be interesting to try - get the optics from an old 3CCD camera and fit 3 sensors in place of the CCDs. Full-res colour, or higher res at a given framerate for mono (compensating for different effective gain of r,g,b), or 3x the framerate by staggering the exposure timings between the sensors.
Just spotted this relatively low-cost FPGA board with a SODIMM socket - might be useful as a prototyping platform for a dedicated PCB.
Re: High-speed camera - First video!
MOT_man, Mon Mar 10 2008, 08:11AM
I was going to build one for capturing movies for ballistics testing. I have some home loaded 7.62X39 mm saber tip bullets that will be firing at ballistic gel, reactive targets and armor plate. Such a system would VERY VERY useful.
MOT_man, Mon Mar 10 2008, 08:11AM
I was going to build one for capturing movies for ballistics testing. I have some home loaded 7.62X39 mm saber tip bullets that will be firing at ballistic gel, reactive targets and armor plate. Such a system would VERY VERY useful.
Re: High-speed camera - First video!
mikeselectricstuff, Tue Mar 11 2008, 01:16AM
), this sort of camera is probably at the low end of the sort of speeds you need for ballistics work.
However as bullets travel in pretty straight & predictable paths, you can sometimes make do with a short but wide image frame, so you could trade off speed vs. resolution.
mikeselectricstuff, Tue Mar 11 2008, 01:16AM
MOT_man wrote ...
I was going to build one for capturing movies for ballistics testing. I have some home loaded 7.62X39 mm saber tip bullets that will be firing at ballistic gel, reactive targets and armor plate. Such a system would VERY VERY useful.
Judging from what I've seen on Mythbusters (when not drooling over Kari I was going to build one for capturing movies for ballistics testing. I have some home loaded 7.62X39 mm saber tip bullets that will be firing at ballistic gel, reactive targets and armor plate. Such a system would VERY VERY useful.
), this sort of camera is probably at the low end of the sort of speeds you need for ballistics work. However as bullets travel in pretty straight & predictable paths, you can sometimes make do with a short but wide image frame, so you could trade off speed vs. resolution.
Re: High-speed camera - First video!
tesla500, Tue Mar 11 2008, 01:57AM
I'd agree that this system is on the slow end for ballistics, but if you can accept very low resolutions and you know the exact area you want to watch, it would work.
I would definitely want to build a full, self-contained camera based on the LUPA-300 before attempting anything with the LUPA-1300-2. I'm sure there's tons of experience to be gained from a small project.
I do like the PSP LCD idea a lot, it's annoying dragging that big external monitor around with the camera. A self-contained HS camcorder that could save video to a USB flash drive or external hard drive would be very cool.
That's an interesting idea, although the cost and complexity may not be worth it compared to using a LUPA-1300-2.
That looks nice, thanks for pointing that out.
David
tesla500, Tue Mar 11 2008, 01:57AM
I'd agree that this system is on the slow end for ballistics, but if you can accept very low resolutions and you know the exact area you want to watch, it would work.
Yes - this chip looks like being a lot more work to deal with.
I would definitely want to build a full, self-contained camera based on the LUPA-300 before attempting anything with the LUPA-1300-2. I'm sure there's tons of experience to be gained from a small project.
One thought I had re. providing a cheap local display would be to have an interface for a PSP LCD
I do like the PSP LCD idea a lot, it's annoying dragging that big external monitor around with the camera. A self-contained HS camcorder that could save video to a USB flash drive or external hard drive would be very cool.
I just had another thought on something that might be interesting to try - get the optics from an old 3CCD camera and fit 3 sensors in place of the CCDs.
That's an interesting idea, although the cost and complexity may not be worth it compared to using a LUPA-1300-2.
Just spotted this relatively low-cost FPGA board with a SODIMM socket - might be useful as a prototyping platform for a dedicated PCB.
That looks nice, thanks for pointing that out.
David
Re: High-speed camera - First video!
mikeselectricstuff, Tue Mar 11 2008, 09:31AM
[quote]
That looks nice, thanks for pointing that out.
David
[/quote1205227725]
I noticed that the page says they currently 'only support the SODIMM socket for I/O' - if planning to use this board for prototyping, I'd check whether this is simply because they've not done the code, or if theer are signal integrity/pinout issues on the PCB. John Adair at Enterpoint regularly posts on the comp.arch.fpga newsgroup and seems like a helpful chap.
mikeselectricstuff, Tue Mar 11 2008, 09:31AM
[quote]
Just spotted this relatively low-cost FPGA board with a SODIMM socket - might be useful as a prototyping platform for a dedicated PCB.
That looks nice, thanks for pointing that out.
David
[/quote1205227725]
I noticed that the page says they currently 'only support the SODIMM socket for I/O' - if planning to use this board for prototyping, I'd check whether this is simply because they've not done the code, or if theer are signal integrity/pinout issues on the PCB. John Adair at Enterpoint regularly posts on the comp.arch.fpga newsgroup and seems like a helpful chap.
Print this page