If you need assistance, please send an email to forum at 4hv dot org. To ensure your email is not marked as spam, please include the phrase "4hv help" in the subject line. You can also find assistance via IRC, at irc.shadowworld.net, room #hvcomm.
Support 4hv.org!
Donate:
4hv.org is hosted on a dedicated server. Unfortunately, this server costs and we rely on the help of site members to keep 4hv.org running. Please consider donating. We will place your name on the thanks list and you'll be helping to keep 4hv.org alive and free for everyone. Members whose names appear in red bold have donated recently. Green bold denotes those who have recently donated to keep the server carbon neutral.
Special Thanks To:
Aaron Holmes
Aaron Wheeler
Adam Horden
Alan Scrimgeour
Andre
Andrew Haynes
Anonymous000
asabase
Austin Weil
barney
Barry
Bert Hickman
Bill Kukowski
Blitzorn
Brandon Paradelas
Bruce Bowling
BubeeMike
Byong Park
Cesiumsponge
Chris F.
Chris Hooper
Corey Worthington
Derek Woodroffe
Dalus
Dan Strother
Daniel Davis
Daniel Uhrenholt
datasheetarchive
Dave Billington
Dave Marshall
David F.
Dennis Rogers
drelectrix
Dr. John Gudenas
Dr. Spark
E.TexasTesla
eastvoltresearch
Eirik Taylor
Erik Dyakov
Erlend^SE
Finn Hammer
Firebug24k
GalliumMan
Gary Peterson
George Slade
GhostNull
Gordon Mcknight
Graham Armitage
Grant
GreySoul
Henry H
IamSmooth
In memory of Leo Powning
Jacob Cash
James Howells
James Pawson
Jeff Greenfield
Jeff Thomas
Jesse Frost
Jim Mitchell
jlr134
Joe Mastroianni
John Forcina
John Oberg
John Willcutt
Jon Newcomb
klugesmith
Leslie Wright
Lutz Hoffman
Mads Barnkob
Martin King
Mats Karlsson
Matt Gibson
Matthew Guidry
mbd
Michael D'Angelo
Mikkel
mileswaldron
mister_rf
Neil Foster
Nick de Smith
Nick Soroka
nicklenorp
Nik
Norman Stanley
Patrick Coleman
Paul Brodie
Paul Jordan
Paul Montgomery
Ped
Peter Krogen
Peter Terren
PhilGood
Richard Feldman
Robert Bush
Royce Bailey
Scott Fusare
Scott Newman
smiffy
Stella
Steven Busic
Steve Conner
Steve Jones
Steve Ward
Sulaiman
Thomas Coyle
Thomas A. Wallace
Thomas W
Timo
Torch
Ulf Jonsson
vasil
Vaxian
vladi mazzilli
wastehl
Weston
William Kim
William N.
William Stehl
Wesley Venis
The aforementioned have contributed financially to the continuing triumph of 4hv.org. They are deserving of my most heartfelt thanks.
Registered Member #27
Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058
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.
Registered Member #311
Joined: Sun Mar 12 2006, 08:28PM
Location:
Posts: 253
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.
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. 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. 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.
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?
Registered Member #311
Joined: Sun Mar 12 2006, 08:28PM
Location:
Posts: 253
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.
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.
Registered Member #27
Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058
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.
Registered Member #311
Joined: Sun Mar 12 2006, 08:28PM
Location:
Posts: 253
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...! 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.
Registered Member #347
Joined: Sat Mar 25 2006, 08:26AM
Location: Vancouver, Canada
Posts: 106
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.
Registered Member #311
Joined: Sun Mar 12 2006, 08:28PM
Location:
Posts: 253
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.
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.
Registered Member #1127
Joined: Mon Nov 19 2007, 12:08AM
Location:
Posts: 139
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.
Registered Member #311
Joined: Sun Mar 12 2006, 08:28PM
Location:
Posts: 253
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 ), 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.
This site is powered by e107, which is released under the GNU GPL License. All work on this site, except where otherwise noted, is licensed under a Creative Commons Attribution-ShareAlike 2.5 License. By submitting any information to this site, you agree that anything submitted will be so licensed. Please read our Disclaimer and Policies page for information on your rights and responsibilities regarding this site.
High-speed camera - First video!
.
), this sort of camera is probably at the low end of the sort of speeds you need for ballistics work.