No one would answer my post on Project Considerations, so I went ahead and started anyway. IdleHands and all!
I've started on a board that offloads the periphials to Microchip DSP engines leaving most off the Props I/O untouched. Right now I'm about 40% done with the Circuit Supervisor which will handle Outside Comm Ports and Control the On/Off Switches for the regulators.
I can't start on the PropCam component yet as the new 32bit Processor is Backordered. But when it gets here I plan to use it as a Serial Back Pack to a 128x16k NV SRAM chip from Dallas Simiconductor that I have Laying around doing nothing. With it I hope to use it as a video buffer and run the left over SPI channel to the prop so it can post or preview images as needed. The DSP will still have enough I/O left over to run a DAQ for VGA using a DMA channel that's available on these chips. You said 4 data lines and 4 control lines? Darn I didn't even have to ask that one! Thanks!
I've been thinking along these same lines. My approach would probably use a CPLD instead of discrete ripple counters for maximum flexibility.
To answer your other questions:
1. The PropCAM module uses eight of the Propeller's I/O pins: four for data, and four for control.
2. A better approach might be to parallel the PropCAM's data pins with the external RAM's data pins. That way no cog-to-cog — or even pin-to-pin — transfer is necessary, and fewer pins are used up. I'm still working out the details of how this might be implemented. The acquisition routines are busy enough that two tag-teamed cogs are necessary to keep up.
3. White chicken recognition will be left as an exercize for the user.
-Phil
I don't even know how to spell CPLD! I guess I need to learn some more.
#2. You mean have the data pins from the camera that are input into the prop, also be paralleled to the inputs to the ram chip? That could be interesting. No need to transfer. since the camera is 4 bit/pixel, does that mean I am wasting 4 bits/byte? Not that I care too much, the ram is cheap.
#3. Come on, I'm sure that a white chicken recognition routine would be demanded by every user. You never know when it might come in handy!
2. Yes, paralleled. The data would be packed using a holding register on writes and unpacked using a multiplexer on reads, so no nybbles are wasted. Every two Propeller accesses would result in a single RAM access. It does add complication — and maybe too much cost — to the design. Wasting half the memory could be more cost effective, all things considered.
Just had an idea on how to fit color images into memory.· It's very similar to PhiPi's suggestion of just storing the raw sensor output to memory·without any de-mosaicing.·
Ok, let me take this slow.· A normal color camera color filter pattern looks like this.
Fig. 1
| R | G |
· etc....
| G | B |
but when it's processed into a final image that same area comes out as.
Fig. 2
|rgb|rgb|
|rgb|rgb|
This naturally consumes a LOT more memory and really doesn't have any more information in it than Fig 1.· So how about storing Fig. 1 like this?
Fig. 3
|······· |
|· RGB |
| ······· |
This would drop image resolution from 128x96 for this sensor·to 64x48 BUT would hold almost as much information as the raw sensor output with the color-filter pattern.· (of course any color space could be used for storage. RGB is used because it's easy to understand, other color spaces·may be·better suited to processing)
Assuming 16bit color and coding Per Fig. 3 a full frame buffer should consume only 6,144Bytes of hub ram.· (heh, thats small enough for a 2-3 frame buffer!)
I'm not sure, when an image sensor is covered with Bayer RGB filters, if its stated resolution gets diminished as a result. I suspect not, even though it would be more honest to do so. A "red" value based on a pixel's two red neightbors isn't the same as if it were a red pixel.
I think your idea is correct and would likely work with the PropCAM if it used a color sensor. But the PropCAM is B/W only.
Yep, PropCAM is a B/W only device now [noparse]:)[/noparse] but what about who knows about PropCAM V2?
Also, this is the biggest Thread on this forum on Video capture with the Propeller so while my idea isn't immedatly usefull it won't go to waste. (a man can hope :P )
I do wonder what exactly the video periferal on each Cog does. I guess it shoves a "Long" of data out some pins 3-4 bits at a time? I wonder if it could be made to operate in reverse? seems to me that that'd be rather usefull for making Cog-Cog and Prop-Prop data busses.
2. Yes, paralleled. The data would be packed using a holding register on writes and unpacked using a multiplexer on reads, so no nybbles are wasted. Every two Propeller accesses would result in a single RAM access. It does add complication — and maybe too much cost — to the design. Wasting half the memory could be more cost effective, all things considered.
-Phil
Phil,
I'm starting to understand a bit I think. Still all mental theory at this time though.
What do you think about using 2 (sets) of ripple counters.
Counter 1 is the 'frame' counter, and supplies the top 9 bits of address. (so I can store 512 frames) 5 seconds @ 60fps = 300 rounded up to 512
Counter 2 is the 'pixel' counter, and supplies the lower 14 bits. If I figured rightly, your camera has 128 * 96 pixels, for a total of 12288 pixels. Rounding up to 16384
If I store your 4 bits in a whole byte, I will waste ram, but not mips, and the cog's shouldnt 'bog' down when recording. (and upgrading to 8bit/pixel would be free!)
Using this method, I can page thru the frames rapidly, and then loop thru the pixels.
I could also further segment the lower pixel counter into rows and columns, but I don't know if that would be too usefull. This general method should work with multiple camera types.
I think the pixel counter would need to use cascaded counters. The CD4020 is a 14 stage, but I don't understand the schematic. It seems to be missing 2 bits.
If I used seperate row and column counters, I wouldn't need to cascade, but would need an extra prop port.
Still need to find the proper SRAM too.
Does this make sense?
If I understand your design correctly, I could then have the camera 'record' video and then reprocess the video as if it were coming in from the camera, since I would be using your parallel pin idea. (the code would of course have to skip some camera operations)
The video peripheral operates on longs, alright. But each long can hold up to 32 1-bit pixels or 16 2-bit pixels. The pixel values are used to index into a color table, which holds encoded color and intensity data. The grayscale data from the PropCAM is actually piggy-backed onto a black video baseline generated in another cog by it's video peripheral. It uses the DUTY mode of one of the counters to display 16 gray levels, instead of the video circuitry.
Something like the video peripheral running "in reverse" for obtaining and packing data in real time is certainly an intriguing notion. The PropCAM's acquisition routines would be a lot simpler!
What you're proposing could work. I haven't used CD4000-series logic in a long time, though, so I don't know if it would be up to the job speed-wise, especially at 3.3V. The data rate from the camera is 10MHz, so you might want to look at the 74HC series of logic chips.
Also, at this rate you would have to use the clock that drives the camera as a combination data strobe and counter clock. There just isn't time to do anything in software. Therefore, some kind of global disable bit will also be necessary to still the counters when you're not streaming data into or out of RAM.
This is why I'm looking more at programmable logic. It could be done with discrete logic, certainly, but starts to get complicated pretty quick.
... The data rate from the camera is 10MHz, so you might want to look at the 74HC series of logic chips.
Also, at this rate you would have to use the clock that drives the camera as a combination data strobe and counter clock. There just isn't time to do anything in software. Therefore, some kind of global disable bit will also be necessary to still the counters when you're not streaming data into or out of RAM.
This is why I'm looking more at programmable logic. It could be done with discrete logic, certainly, but starts to get complicated pretty quick.
-Phil
Gotcha, I come for a pure software world, where routines will work, but not scale. I am learning that in H/W, it wouldn't work to start with if the speed isn't there.
We are getting a bit off topic, but do you have any suggested CPLD devices I can look into? I don't quite know what to look for in a CPLD.
Hmm, the customers are getting restless! It appears I've got some 'splainin' to do. So here's what's been happening:
1. I did a new set of protos with the following changes:
Included on the board a set of pads for enabling/disabling the SDA pullup.
Removed the SCL pullup. It's not needed.
Added an expander board that converts the two-row 2mm connector to a one-row x 12 SIP. The two boards can be connected by a cable if necessary to separate them. The expander board will plug right into the Propeller Demo Board and is compatible with the PropSTICK.
Added pads on the PropCAM board for a future LED strobe daughtercard.
Modified the data bus pinout to make it compatible with a future receiver card.
Specified that the lens-mount holes be pre-drilled with a smaller drill in hopes that they will be more accurately located and register with the sensor pads better. This seems to have helped an earlier misalignment issue. If precise registration can't be achieved in production, either the sensors will have to be hand-soldered with a fixture keyed to the lens-mount holes, or the lens mount holes will have to be enlarged and a template sandwiched between the lens mount and the board to fix alignment with the sensor. Hopefully neither will be necessary.
2. Last week, I sent two sets of the new boards to Parallax to preview, along with driver, display, and image-processing software. These had 2.8mm wide-angle lenses, which I'm not planning to use.
3. I've sent more inquiries to Chinese and Korean lens companies. The search for the right lens has been expanded to include lenses designed for webcams and digital still cameras. This is still the major hangup. Most so-called CCTV "board lenses" are designed for 1/3" sensors. I'm using a 1/5" sensor. So my options among the commonly available 1/3"-compatible lenses are all wide-angle, have pronounced barrel distortion, and include way too many (expensive) lens elements for the intended application. This can be ameleorated by moving to a slightly longer focal length. But the only such sample I've received so far was poorly contructed and suffered considerable optical misalignment. (Imagine rotating the lens to focus it and seeing the image shift around in circles, and you'll get the idea.) I could just throw up my hands and buy pre-vetted lenses from a domestic supplier (e.g. Edmund, Mrashall, Universe, or Sunnex). But that could double the final price of the PropCAM, and nobody wants that! So the search continues...
And that's where things stand right now: toes curled over the precipice, nearly ready to make the leap with a new product, waiting for the right wind from my suppliers...
Thanks for the update. You are right about "restless customers". Are you taking advanced orders yet????
The anticipation is killing me. I have been glued to this thread since it first surfaced and have been pleasently
suprised at each new turn you have taken during the development.....
I could just throw up my hands and buy pre-vetted lenses from a domestic supplier (e.g. Edmund, Mrashall, Universe, or Sunnex). But that could double the final price of the PropCAM, and nobody wants that! So the search continues...
-Phil
Thanks for the update Phil. Will we be able to easily change the lenses once we get our hands on the boards? I need a 100x+ 'lens'.
Any lens I end up using will have a standard 12mm x 0.5mm thread. So you should have no trouble substituting something else or finding an adapter for it at least.
BTW, just last night I got a promising lead on a lens from China. If the quality is up to snuff, the price is certainly right. I hope to get samples soon...
I'm currently working on a project that could use vision.....but the current project requires color. But the next project I'm planning would require a· B/W camera for vision. Would it be possible to interface a higher resolution camera to your design.
I don't know much about video.....so you'll have to ignore my lack of knowledge in the vision area.
I found some digital board cameras on the net that use USB.......
I've found yet another application that could use your product.
A lab would like to automate a test by having a machine determine how long a product burns in a test chamber. I see know reason why the propcam couldn't verify flame-out? Or even the length of the burn for that matter!
Some "color" applications can use a B/W camera with a suitable filter. To illustrate, the following photo of M&Ms was taken in full color, then "filtered" in PhotoPaint to show the effects of taking the same photo using a B/W camera with different color filters:
As you can see, if your objective were to locate the blue M&Ms, a blue filter would serve quite admirably. On the other hand, if you had to separate red ones from yellow ones using a red filter, it wouldn't work. But if there were no green ones in the mix, you could do it with a green filter.
What this shows is that filters can be used with a B/W imager to punch up the contrast between hues, but a single filter is inadequate to tell you what color something is in a field of all possible colors.
Resolution and color depth are effectively limited by the Propeller's available RAM. The PropCAM, with 128x96 B/W 4-bit pixels, uses 6144 bytes. (This small a memory footprint also makes double-buffering possible for a flicker-free display of processed images.) A full-color version with the same resolution and depth would require 18432 bytes, or over half the Propeller's RAM. A CIF-resolution (352x288) color image with 4-bit depth would require 152Kbytes — more than four times the Propeller's RAM capacity!
There are lots of cheap USB "webcams" out there. To use one with the Propeller would require it to act as USB host and to have a driver compatible with the camera being interfaced. Not impossible, maybe, but certainly not easy.
The PropCAM could very likely do what you want it to do in the "flame-out" app. But it would be overkill, I think. A simple IR detector might be a more cost-effective option.
In this test though, flame lenght at various increments in the burn are measured visually through a glass window, with rough results. Especially when different people's eyesight would give an error of +/- 3 mm at say 45 cm distances. Your propcam mounted parrellel to the burn could provide constant updates of how far the flame travels.
Some customers also pay to view there sample burn on line and a camera is already mounted for this purpose. Replaceing it would be mute considering the ellimination of human error. Not that one person can't give constant accuracy of some calibrated degee, but the error comes in when he takes a day off and some one else's eyes take the measurements.
I know I've pestered you for color, but in this app the color camera gives a better picture when its filtered to B/W due to the flame flicker.
I was considering using this camera until the propeller came out, and I saw this project.
The AVRCam is color though. I had had the thought of 'porting' that design to a propeller. But that might be too much to bite off for a 1st electronics project.
Today I received another set of lens samples from China. I'm happy to report that these look like they'll be more than adequate to include with the PropCAM and sufficient for most non-critical measurement applications. These lenses have a focal length of 3.6mm and an f2.0 aperture. Since they're constructed as wide-angle lenses for a 1/3" sensor, they still display some barrel distortion — but about half what I was experiencing with the 2.8mm lenses I tried earlier. They also display a small optical/physical misalignment, which means focussing them will entail a slight image shift. But it's much less pronounced than with the 3.6mm lenses I tried earlier from a different supplier.
One thing I like about the lenses and holders from this supplier are that they fit together snugly. This can make them a bit difficult to focus at times, but the main thing is that they won't rattle loose. This is important in environments where vibration is a factor. And finally, the price is right: the lens won't be the tail that wags the PropCAM dog!
The lenses worked out fine, and I'll be ordering a batch soon.
I'm now in the process of panelizing the boards so they can be assembled by a pick-and-place machine, whereupon I'll submit the Gerbers to several fab houses for quotes.
I'm also obtaining some dummy sensor chips, so the assembly house can calibrate their reflow ovens with lead-free solder. These chips are ceramic, with a lot of thermal mass, and I had NO luck soldering them in my infrared toaster oven. So the calibration effort will be a worthwhile exercise.
I'm also waiting for a quote from China for the cable assembly. DigiKey could make them, but they're too expensive. Ultimately the PropCAM will plug into its own processor board (proto photo attached), and the cable won't be necessary. But for current Demo Board and PropSTICK users, the cable will be convenient for interfacing to the PropCAM's 2mm header.
Right now, I'm having to split my time among PropCAM stuff, documentation of other products, and milling jig molds for a fishing tackle company — plus dealing with a pent-up desire to make the best of summer's waning days! But rest assured, progress is being made!
Comments
No one would answer my post on Project Considerations, so I went ahead and started anyway. IdleHands and all!
I've started on a board that offloads the periphials to Microchip DSP engines leaving most off the Props I/O untouched. Right now I'm about 40% done with the Circuit Supervisor which will handle Outside Comm Ports and Control the On/Off Switches for the regulators.
I can't start on the PropCam component yet as the new 32bit Processor is Backordered. But when it gets here I plan to use it as a Serial Back Pack to a 128x16k NV SRAM chip from Dallas Simiconductor that I have Laying around doing nothing. With it I hope to use it as a video buffer and run the left over SPI channel to the prop so it can post or preview images as needed. The DSP will still have enough I/O left over to run a DAQ for VGA using a DMA channel that's available on these chips. You said 4 data lines and 4 control lines? Darn I didn't even have to ask that one! Thanks!
I don't even know how to spell CPLD! I guess I need to learn some more.
#2. You mean have the data pins from the camera that are input into the prop, also be paralleled to the inputs to the ram chip? That could be interesting. No need to transfer. since the camera is 4 bit/pixel, does that mean I am wasting 4 bits/byte? Not that I care too much, the ram is cheap.
#3. Come on, I'm sure that a white chicken recognition routine would be demanded by every user. You never know when it might come in handy!
Thanks for the CPLD pointer.
Seth
2. Yes, paralleled. The data would be packed using a holding register on writes and unpacked using a multiplexer on reads, so no nybbles are wasted. Every two Propeller accesses would result in a single RAM access. It does add complication — and maybe too much cost — to the design. Wasting half the memory could be more cost effective, all things considered.
-Phil
Ok, let me take this slow.· A normal color camera color filter pattern looks like this.
Fig. 1
| R | G |
· etc....
| G | B |
but when it's processed into a final image that same area comes out as.
Fig. 2
|rgb|rgb|
|rgb|rgb|
This naturally consumes a LOT more memory and really doesn't have any more information in it than Fig 1.· So how about storing Fig. 1 like this?
Fig. 3
|·· ····· |
|· RGB |
| ······· |
This would drop image resolution from 128x96 for this sensor·to 64x48 BUT would hold almost as much information as the raw sensor output with the color-filter pattern.· (of course any color space could be used for storage. RGB is used because it's easy to understand, other color spaces·may be·better suited to processing)
Assuming 16bit color and coding Per Fig. 3 a full frame buffer should consume only 6,144Bytes of hub ram.· (heh, thats small enough for a 2-3 frame buffer!)
Tell me if I'm crazy,
Marty
·
I'm not sure, when an image sensor is covered with Bayer RGB filters, if its stated resolution gets diminished as a result. I suspect not, even though it would be more honest to do so. A "red" value based on a pixel's two red neightbors isn't the same as if it were a red pixel.
I think your idea is correct and would likely work with the PropCAM if it used a color sensor. But the PropCAM is B/W only.
-Phil
Also, this is the biggest Thread on this forum on Video capture with the Propeller so while my idea isn't immedatly usefull it won't go to waste. (a man can hope :P )
I do wonder what exactly the video periferal on each Cog does. I guess it shoves a "Long" of data out some pins 3-4 bits at a time? I wonder if it could be made to operate in reverse? seems to me that that'd be rather usefull for making Cog-Cog and Prop-Prop data busses.
Propeller-less for now,
Marty
Phil,
I'm starting to understand a bit I think. Still all mental theory at this time though.
What do you think about using 2 (sets) of ripple counters.
Counter 1 is the 'frame' counter, and supplies the top 9 bits of address. (so I can store 512 frames) 5 seconds @ 60fps = 300 rounded up to 512
Counter 2 is the 'pixel' counter, and supplies the lower 14 bits. If I figured rightly, your camera has 128 * 96 pixels, for a total of 12288 pixels. Rounding up to 16384
If I store your 4 bits in a whole byte, I will waste ram, but not mips, and the cog's shouldnt 'bog' down when recording. (and upgrading to 8bit/pixel would be free!)
Using this method, I can page thru the frames rapidly, and then loop thru the pixels.
I could also further segment the lower pixel counter into rows and columns, but I don't know if that would be too usefull. This general method should work with multiple camera types.
I think the pixel counter would need to use cascaded counters. The CD4020 is a 14 stage, but I don't understand the schematic. It seems to be missing 2 bits.
If I used seperate row and column counters, I wouldn't need to cascade, but would need an extra prop port.
Still need to find the proper SRAM too.
Does this make sense?
If I understand your design correctly, I could then have the camera 'record' video and then reprocess the video as if it were coming in from the camera, since I would be using your parallel pin idea. (the code would of course have to skip some camera operations)
Thanks for the ear.
Seth
The video peripheral operates on longs, alright. But each long can hold up to 32 1-bit pixels or 16 2-bit pixels. The pixel values are used to index into a color table, which holds encoded color and intensity data. The grayscale data from the PropCAM is actually piggy-backed onto a black video baseline generated in another cog by it's video peripheral. It uses the DUTY mode of one of the counters to display 16 gray levels, instead of the video circuitry.
Something like the video peripheral running "in reverse" for obtaining and packing data in real time is certainly an intriguing notion. The PropCAM's acquisition routines would be a lot simpler!
-Phil
What you're proposing could work. I haven't used CD4000-series logic in a long time, though, so I don't know if it would be up to the job speed-wise, especially at 3.3V. The data rate from the camera is 10MHz, so you might want to look at the 74HC series of logic chips.
Also, at this rate you would have to use the clock that drives the camera as a combination data strobe and counter clock. There just isn't time to do anything in software. Therefore, some kind of global disable bit will also be necessary to still the counters when you're not streaming data into or out of RAM.
This is why I'm looking more at programmable logic. It could be done with discrete logic, certainly, but starts to get complicated pretty quick.
-Phil
Gotcha, I come for a pure software world, where routines will work, but not scale. I am learning that in H/W, it wouldn't work to start with if the speed isn't there.
We are getting a bit off topic, but do you have any suggested CPLD devices I can look into? I don't quite know what to look for in a CPLD.
Thanks
Seth
Take a look at Altera's MAX3000 devices. DigiKey carries them.
-Phil
Any recent recent news? The thread is getting stale, and I got money burning a hole in my pocket!
Seth
1. I did a new set of protos with the following changes:
- Included on the board a set of pads for enabling/disabling the SDA pullup.
- Removed the SCL pullup. It's not needed.
- Added an expander board that converts the two-row 2mm connector to a one-row x 12 SIP. The two boards can be connected by a cable if necessary to separate them. The expander board will plug right into the Propeller Demo Board and is compatible with the PropSTICK.
- Added pads on the PropCAM board for a future LED strobe daughtercard.
- Modified the data bus pinout to make it compatible with a future receiver card.
- Specified that the lens-mount holes be pre-drilled with a smaller drill in hopes that they will be more accurately located and register with the sensor pads better. This seems to have helped an earlier misalignment issue. If precise registration can't be achieved in production, either the sensors will have to be hand-soldered with a fixture keyed to the lens-mount holes, or the lens mount holes will have to be enlarged and a template sandwiched between the lens mount and the board to fix alignment with the sensor. Hopefully neither will be necessary.
2. Last week, I sent two sets of the new boards to Parallax to preview, along with driver, display, and image-processing software. These had 2.8mm wide-angle lenses, which I'm not planning to use.3. I've sent more inquiries to Chinese and Korean lens companies. The search for the right lens has been expanded to include lenses designed for webcams and digital still cameras. This is still the major hangup. Most so-called CCTV "board lenses" are designed for 1/3" sensors. I'm using a 1/5" sensor. So my options among the commonly available 1/3"-compatible lenses are all wide-angle, have pronounced barrel distortion, and include way too many (expensive) lens elements for the intended application. This can be ameleorated by moving to a slightly longer focal length. But the only such sample I've received so far was poorly contructed and suffered considerable optical misalignment. (Imagine rotating the lens to focus it and seeing the image shift around in circles, and you'll get the idea.) I could just throw up my hands and buy pre-vetted lenses from a domestic supplier (e.g. Edmund, Mrashall, Universe, or Sunnex). But that could double the final price of the PropCAM, and nobody wants that! So the search continues...
And that's where things stand right now: toes curled over the precipice, nearly ready to make the leap with a new product, waiting for the right wind from my suppliers...
-Phil
Thanks for the update. You are right about "restless customers". Are you taking advanced orders yet????
The anticipation is killing me. I have been glued to this thread since it first surfaced and have been pleasently
suprised at each new turn you have taken during the development.....
AuburnSky
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
Thanks for the update Phil. Will we be able to easily change the lenses once we get our hands on the boards? I need a 100x+ 'lens'.
Seth
Any lens I end up using will have a standard 12mm x 0.5mm thread. So you should have no trouble substituting something else or finding an adapter for it at least.
BTW, just last night I got a promising lead on a lens from China. If the quality is up to snuff, the price is certainly right. I hope to get samples soon...
-Phil
I'm currently working on a project that could use vision.....but the current project requires color. But the next project I'm planning would require a· B/W camera for vision. Would it be possible to interface a higher resolution camera to your design.
I don't know much about video.....so you'll have to ignore my lack of knowledge in the vision area.
I found some digital board cameras on the net that use USB.......
Just trying to find out what I'm up against.
James
Post Edited (James) : 8/16/2006 4:36:06 PM GMT
I've found yet another application that could use your product.
A lab would like to automate a test by having a machine determine how long a product burns in a test chamber. I see know reason why the propcam couldn't verify flame-out? Or even the length of the burn for that matter!
PS. Thanks for the update.
Some "color" applications can use a B/W camera with a suitable filter. To illustrate, the following photo of M&Ms was taken in full color, then "filtered" in PhotoPaint to show the effects of taking the same photo using a B/W camera with different color filters:
As you can see, if your objective were to locate the blue M&Ms, a blue filter would serve quite admirably. On the other hand, if you had to separate red ones from yellow ones using a red filter, it wouldn't work. But if there were no green ones in the mix, you could do it with a green filter.
What this shows is that filters can be used with a B/W imager to punch up the contrast between hues, but a single filter is inadequate to tell you what color something is in a field of all possible colors.
Resolution and color depth are effectively limited by the Propeller's available RAM. The PropCAM, with 128x96 B/W 4-bit pixels, uses 6144 bytes. (This small a memory footprint also makes double-buffering possible for a flicker-free display of processed images.) A full-color version with the same resolution and depth would require 18432 bytes, or over half the Propeller's RAM. A CIF-resolution (352x288) color image with 4-bit depth would require 152Kbytes — more than four times the Propeller's RAM capacity!
There are lots of cheap USB "webcams" out there. To use one with the Propeller would require it to act as USB host and to have a driver compatible with the camera being interfaced. Not impossible, maybe, but certainly not easy.
-Phil
The PropCAM could very likely do what you want it to do in the "flame-out" app. But it would be overkill, I think. A simple IR detector might be a more cost-effective option.
-Phil
Thanks for the reply..
So a high res color is not an option right now.
What about a higher res B/W?
I haven't read the details on the camera you are using......so I'm a little lost on how the interface actually works.
Thanks for the work you are doing.
James
In this test though, flame lenght at various increments in the burn are measured visually through a glass window, with rough results. Especially when different people's eyesight would give an error of +/- 3 mm at say 45 cm distances. Your propcam mounted parrellel to the burn could provide constant updates of how far the flame travels.
Some customers also pay to view there sample burn on line and a camera is already mounted for this purpose. Replaceing it would be mute considering the ellimination of human error. Not that one person can't give constant accuracy of some calibrated degee, but the error comes in when he takes a day off and some one else's eyes take the measurements.
I know I've pestered you for color, but in this app the color camera gives a better picture when its filtered to B/W due to the flame flicker.
Hope the moderators don't mind outside links.......so you guys check this out!!!!
http://www.acroname.com/robotics/parts/R245-CMUCAM2-PLUS.html
Just helping out the video guys,
James
http://www.jrobot.net/
I was considering using this camera until the propeller came out, and I saw this project.
The AVRCam is color though. I had had the thought of 'porting' that design to a propeller. But that might be too much to bite off for a 1st electronics project.
Seth
Today I received another set of lens samples from China. I'm happy to report that these look like they'll be more than adequate to include with the PropCAM and sufficient for most non-critical measurement applications. These lenses have a focal length of 3.6mm and an f2.0 aperture. Since they're constructed as wide-angle lenses for a 1/3" sensor, they still display some barrel distortion — but about half what I was experiencing with the 2.8mm lenses I tried earlier. They also display a small optical/physical misalignment, which means focussing them will entail a slight image shift. But it's much less pronounced than with the 3.6mm lenses I tried earlier from a different supplier.
One thing I like about the lenses and holders from this supplier are that they fit together snugly. This can make them a bit difficult to focus at times, but the main thing is that they won't rattle loose. This is important in environments where vibration is a factor. And finally, the price is right: the lens won't be the tail that wags the PropCAM dog!
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
Phil,
I'm gettin restless again. How did those new lenses work out?
Seth
The lenses worked out fine, and I'll be ordering a batch soon.
I'm now in the process of panelizing the boards so they can be assembled by a pick-and-place machine, whereupon I'll submit the Gerbers to several fab houses for quotes.
I'm also obtaining some dummy sensor chips, so the assembly house can calibrate their reflow ovens with lead-free solder. These chips are ceramic, with a lot of thermal mass, and I had NO luck soldering them in my infrared toaster oven. So the calibration effort will be a worthwhile exercise.
I'm also waiting for a quote from China for the cable assembly. DigiKey could make them, but they're too expensive. Ultimately the PropCAM will plug into its own processor board (proto photo attached), and the cable won't be necessary. But for current Demo Board and PropSTICK users, the cable will be convenient for interfacing to the PropCAM's 2mm header.
Right now, I'm having to split my time among PropCAM stuff, documentation of other products, and milling jig molds for a fishing tackle company — plus dealing with a pent-up desire to make the best of summer's waning days! But rest assured, progress is being made!
Cheers!
Phil
We're all so excited your getting close on this new product!
Keep up the good work!
Enjoy the rest of the summer!
Andrew
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔