Not yet, but thanks for inquiring. I already had drivers written for the PropCAM. I'm just trying to get some examples cleaned up using those so I can release the product. ('Working on the Spinneret webcam example at the moment.)
The Spinneret webcam demo that I had written earlier used a rather complicated wrapper for the Spinneret's W5100_indirect_driver that I didn't want to have to explain. So I wrote a simpler version (called http_helper) and a webcam demo that uses it. I think I'm pretty much done with demo programs now. What remains is to produce the main documentation using Parallax's Word template and get thie PropCAM out the door.
Once that's done and sales commence, I can go back and document my grayscale image-processing object -- assuming I can remember how it works.
I've completed the three driver objects, two demo programs, and the documentation, which can be downloaded below. I'm looking for a couple U.S.-located testers (one with strong Spinneret experience, the other with strong Propeller Backpack experience). Testers will each receive a free PropCAM and will be invited to offer a review of the product in this thread. If you feel that you qualify for either position, please send me an email detailing your experience.
Congratualations! It looks like a well done little package and a nice addition to the family.
I feel I should start saving up for one just to own a piece of Propeller history!! It will have to come off my bulletin board with the pictures of Bigfoot, Nessie, a Cubs World Series a Brown's Superbowl and the Lost Continent of Atlantis!
I've drawn up a simple mezzanine using WS2812B leds - that would let us alternately illuminate with red/green/blue for photographing close objects, and perhaps provide some kind of very basic structured light.
What I need to know is the offset to the 2mm mezzanine connector, and if known the diameter of the mounting screw heads.
Wow! That was quick! Here are the coordinates for the lower-left mezzanine pin, releative to the lower-left corner of the board:
x = 0.40315"
y = 1.16063"
Pin spacing is 2mm.
I'm not sure how you plan to clock these, though, with the signals that are available. You may need to add a small micro to the bottom of the board to accept data via sda and scl for the color, and then the st pin to strobe the LEDs.
Also, I would recommend using an "elevator" header between the mezzanine board and main board. This will bring the LEDs far enough forward so they are not shadowed by the lens barrel.
Phil,
WS2812B LEDs have a little chip built in. They use a 1 wire serial setup to set the colors, and they chain, so you only need one data pin to drive them all.
Yeah, I understand that, Roy. But there are only three data lines available on the mezzanine connector: sda, scl, and vsync. They're all shared with the sensor chip, so you have to be careful about how and when they get toggled. My idea for a mezzanine card was to use the I2C lines with an I2C slave chip of some sort for control purposes, and vsync as a strobe. However, I think the WS2812B could be used with some simple logic, as follows:
Use sda as the LED's data line, but allow transitions to appear at the LED's input only when scl is high. This will create a bunch of I2C start and stop conditions on the bus, which the sensor chip should ignore, as long as it ends with a stop condition.
Unfortunately, purely combinatorial logic will not do the job, since scl can be high during communication with the sensor. So edge-triggered logic will be required. But the key is that no transitions on sda occur when it is high during I2C data transfer, except during start and stop conditions on the bus. That might pose a problem for this scheme, and I have not thought the implications through enough to say for sure.
From a cost and board real-estate standpoint, a small micro may be more efficient.
Oops should have checked the forums before racing ahead, but to be honest I don't have time to work this out right now, so I've already shot a board off to oshpark. There will *definitely* be a second revision
I've shared it in case anyone else would like to build it up. I'm happy to send ws2812b's out to anyone who needs them http://oshpark.com/shared_projects/BcnN8MX8
Fortunately I added a "servo" set of 3 pads under the board. This was done because I haven't checked whether 600mA 5v supply will go through the prop backpack happily.
I took the data in from the STrobe signal but this track would be easy to cut, and then bring the DIN from the servo header from wherever there is a spare gpio pin.
I'm not against adding a small sot23-6 micro is this was for more than a few boards. I guess I'm not sufficiently enthused to add an extra layer of intelligence, flying lead data in will have to do unless someone wants to take the lead on the micro.
Tubular, you may well get by with your original idea of using vsync (strobe). I took another look at the KAC9630 datasheet. Here's what it says:
Vertical Synchronisation Pin in Snapshot Mode (vsync)
The vertical synchronisation pin, vsync, in snapshot mode is an input and is used as an external trigger to start the capture of a single frame.
The vsync pin must be forced high for at least two “mclk” cycles during the idle state of the sensor to trigger a single frame as shown in figure 23. The sensor can only be externally triggered when it is in the idle state. [emphasis mine]
The sensor exits the idle state at the first falling edge it sees on vsync. From then on, until it enters idle again, any edges on vsync should be ignored.
So, IMO, it's worth a try! (BTW, this could be done without modifying any of the driver objects. Just monitor vsync for a falling edge, then impose your signal immediately thereafter. The Prop's implicit OR on outa will take care of the rest.)
As to 600mA on the 5V trace: that might be pushing the boundaries a bit.
If you're going to need to run wire up to the LEDs anyway, you might want to consider using one of AdaFruit's NeoPixel Rings. They have several sizes.
I've used their 16-pixel rings and made my own version which tightens up the spacing between pixels a bit. The round layout might aid in a more uniform light coverage. One could use foam board or other easy to cut material to hold the ring in place in the desired location.
Duane that's some brilliant work right there. I like the way you got the caps in between the led wedges, and the other designs are nice too. Well done. I need to spend more time in forums other than P2
Phil, yes sounds like it might be persuaded to work. I'll check the voltage drop along the +5v trace and a lower current (20% brightness?) and we'll go from there.
I might be tempted to wire the WS2812B's data inputs in parallel, rather than dasiy-chaining them, assuming that they will all be dispalying the same color. That will decrease the setup time considerably.
Also, I'm not certain what the datasheet means by "reset." Does it just latch the data to the LEDs? Or do all the LEDs turn themselves off after the input pin has been low for more than 50 us? Or ... does it just reset the communications circuitry to ready it for the next batch of data?
They work by "absorbing" the first 24 bits of serial data into an internal register (that doesn't immediately get sent to the led drivers).
After absorbing 24 bits they become a pass-through buffer (sending remaining data to remaining leds), but are still looking for that 50uS "reset" condition. If they see the reset condition, they transfers that register to the led driver (allowing a long line of these to sync nicely). Then the cycle repeats over. That way you can sync a long line of them with without much overhead.
I think its worth preserving the case of "directional" lighting, where you can turn on one side at a time.
There's 3 or 4 code bases for driving these from the prop1, and I've got them going with the P2 nicely. I think this sensor will also be a good match for the P2 because it will be able to hold quite a few frames in hub ram, or an extended sequence in SDRAM. And exposure times as short as 200uS... should be fun
I too have been spending too much time lurking the P2 forum. I just came across the news last night and spent an hour our so looking at the specs and code.
Nice work Phil!!!
It looks like two or more cameras could be sync'd?
Yes, you can sync two cameras. You will have to use one of the serial drivers, though, since the parallel driver requires data on P3..P0. Just use the same pins for both cameras' MCLK and VSYNC. Each driver instance requires two cogs (and one more if you use CONTINUOUS mode), so the "or more" part is necessarily limited. Also, output from the two cameras will have to go into separate buffers, and the grayscale NTSC overlay object will have to be modified to display both of them side-by-side.
As an alternative, you could have one camera write to the even lines of a buffer and the other write to the odd lines. Then, assuming TV.spin is interlaced (and I don't honestly remember whether it is), you can use shutter glasses for the stereo effect. Be sure to have some aspirin on hand, though!
Going to try and implement the camera with a ADC08100 and try to itegrate it with Viewport Open CSV.
It seems like using an ADC08100 would be an alternative to using the PropCAM rather and an accessory to the PropCAM. I think any NTSC video camera would work with the ADC08100. What's the benefit of using the PropCAM with it?
I haven't purchased a PropCAM myself but I can't imagine I'll hold out for much longer. There are just a lot more machine vision options for the Propeller than there used to be so I don't feel as strong of a need for the PropCAM as I used to (though I still feel the need).
There are just a lot more machine vision options for the Propeller than there used to be so I don't feel as strong of a need for the PropCAM as I used to (though I still feel the need).
At the risk of sounding too commercial, the PropCAM enjoys at least one significant advantage over the other offerings: a "global shutter.". What this means is that all pixels are exposed at the same time. This eliminates the "rolling-shutter" artifacts that other image sensors suffer. I'm sure you've seen them, but some examples are shown here:
In sensors with a rolling shuuter, such as the OmniVision offerings ubiquitous in other imaging modules, including the CMUCam and Parallax laser range finder, the exposure time for each pixel begins and ends when its row is read out. In the Kodak KAC9630 sensor used in the PropCAM, the exposure time for every pixel in the entire frame begins and ends at the same instant. For casual video recording, this is not a huge deal. But for machine vision applications, it's an essential benefit.
I also wanted to back Phil for all to work he has put into the product.
Thanks much for that! I hope you will find that the performance of the PropCAM itself is equally worthy of your interest and support!
BTW, I do have a grayscale image analysis object that's debugged but awaiting documentation. After the holidays, I intend to get that done and loosed onto the public. Stay tuned!
At the risk of sounding too commercial, the PropCAM enjoys at least one significant advantage over the other offerings: a "global shutter.". What this means is that all pixels are exposed at the same time. This eliminates the "rolling-shutter" artifacts that other image sensors suffer. I'm sure you've seen them
Please, by all means sound commercial.
I'm sure I'll get a PropCAM but I'm very interested in any sales pitches you care to share.
I have several Wii Mote camera's which have been freed from their original housing, a Laser Range Finder, CMUcam 4, a couple of ADC08100 chips to use with NTSC cameras and a CMUcam 5 (Pixy) yet to arrive. I'll of course need a PropCAM to add to my collection but it would be great to know which applications the PropCAM would be the best tool for the job.
By all means please brag, boast and bamboozle bedazzle all you like.
I learned a lot from the Scribbler 2 software you wrote and I figure I'll likely learn a lot from the PropCAM software too. Having the hardware to use with the software you've written is a very large incentive for purchasing the PropCAM.
... it would be great to know which applications the PropCAM would be the best tool for the job.
I would say that anytime the subject is in motion, a camera -- like the PropCAM -- with a global shutter will produce more consistent results than one with a rolling shutter. This is particularly critical when measurements or shape information need to be acquired from the subject for sorting and/or quality-control purposes. A rolling shutter will tend to distort, lengthen, or foreshorten moving subjects (depending upon its orientation relative to the direction of motion), leading to image recognition or measurement errors.
Comments
Did my CMUcam4 code prove helpful?
Not yet, but thanks for inquiring. I already had drivers written for the PropCAM. I'm just trying to get some examples cleaned up using those so I can release the product. ('Working on the Spinneret webcam example at the moment.)
-Phil
Once that's done and sales commence, I can go back and document my grayscale image-processing object -- assuming I can remember how it works.
-Phil
Thanks,
-Phil
And a glamor shot (Parallax has a GREAT photographer!):
Thanks, Parallax!
-Phil
I feel I should start saving up for one just to own a piece of Propeller history!! It will have to come off my bulletin board with the pictures of Bigfoot, Nessie, a Cubs World Series a Brown's Superbowl and the Lost Continent of Atlantis!
I've drawn up a simple mezzanine using WS2812B leds - that would let us alternately illuminate with red/green/blue for photographing close objects, and perhaps provide some kind of very basic structured light.
What I need to know is the offset to the 2mm mezzanine connector, and if known the diameter of the mounting screw heads.
Wow! That was quick! Here are the coordinates for the lower-left mezzanine pin, releative to the lower-left corner of the board:
y = 1.16063"
Pin spacing is 2mm.
I'm not sure how you plan to clock these, though, with the signals that are available. You may need to add a small micro to the bottom of the board to accept data via sda and scl for the color, and then the st pin to strobe the LEDs.
Also, I would recommend using an "elevator" header between the mezzanine board and main board. This will bring the LEDs far enough forward so they are not shadowed by the lens barrel.
'Looks like a cool project! Keep us posted!
-Phil
WS2812B LEDs have a little chip built in. They use a 1 wire serial setup to set the colors, and they chain, so you only need one data pin to drive them all.
Unfortunately, purely combinatorial logic will not do the job, since scl can be high during communication with the sensor. So edge-triggered logic will be required. But the key is that no transitions on sda occur when it is high during I2C data transfer, except during start and stop conditions on the bus. That might pose a problem for this scheme, and I have not thought the implications through enough to say for sure.
From a cost and board real-estate standpoint, a small micro may be more efficient.
-Phil
I've shared it in case anyone else would like to build it up. I'm happy to send ws2812b's out to anyone who needs them
http://oshpark.com/shared_projects/BcnN8MX8
Fortunately I added a "servo" set of 3 pads under the board. This was done because I haven't checked whether 600mA 5v supply will go through the prop backpack happily.
I took the data in from the STrobe signal but this track would be easy to cut, and then bring the DIN from the servo header from wherever there is a spare gpio pin.
I'm not against adding a small sot23-6 micro is this was for more than a few boards. I guess I'm not sufficiently enthused to add an extra layer of intelligence, flying lead data in will have to do unless someone wants to take the lead on the micro.
The vertical synchronisation pin, vsync, in snapshot mode is an input and is used as an external trigger to start the capture of a single frame.
The vsync pin must be forced high for at least two “mclk” cycles during the idle state of the sensor to trigger a single frame as shown in figure 23.
The sensor can only be externally triggered when it is in the idle state. [emphasis mine]
The sensor exits the idle state at the first falling edge it sees on vsync. From then on, until it enters idle again, any edges on vsync should be ignored.
So, IMO, it's worth a try! (BTW, this could be done without modifying any of the driver objects. Just monitor vsync for a falling edge, then impose your signal immediately thereafter. The Prop's implicit OR on outa will take care of the rest.)
As to 600mA on the 5V trace: that might be pushing the boundaries a bit.
-Phil
I've used their 16-pixel rings and made my own version which tightens up the spacing between pixels a bit. The round layout might aid in a more uniform light coverage. One could use foam board or other easy to cut material to hold the ring in place in the desired location.
Phil, yes sounds like it might be persuaded to work. I'll check the voltage drop along the +5v trace and a lower current (20% brightness?) and we'll go from there.
I might be tempted to wire the WS2812B's data inputs in parallel, rather than dasiy-chaining them, assuming that they will all be dispalying the same color. That will decrease the setup time considerably.
Also, I'm not certain what the datasheet means by "reset." Does it just latch the data to the LEDs? Or do all the LEDs turn themselves off after the input pin has been low for more than 50 us? Or ... does it just reset the communications circuitry to ready it for the next batch of data?
-Phil
After absorbing 24 bits they become a pass-through buffer (sending remaining data to remaining leds), but are still looking for that 50uS "reset" condition. If they see the reset condition, they transfers that register to the led driver (allowing a long line of these to sync nicely). Then the cycle repeats over. That way you can sync a long line of them with without much overhead.
I think its worth preserving the case of "directional" lighting, where you can turn on one side at a time.
There's 3 or 4 code bases for driving these from the prop1, and I've got them going with the P2 nicely. I think this sensor will also be a good match for the P2 because it will be able to hold quite a few frames in hub ram, or an extended sequence in SDRAM. And exposure times as short as 200uS... should be fun
Nice work Phil!!!
It looks like two or more cameras could be sync'd?
Thanks
Rich
Yes, you can sync two cameras. You will have to use one of the serial drivers, though, since the parallel driver requires data on P3..P0. Just use the same pins for both cameras' MCLK and VSYNC. Each driver instance requires two cogs (and one more if you use CONTINUOUS mode), so the "or more" part is necessarily limited. Also, output from the two cameras will have to go into separate buffers, and the grayscale NTSC overlay object will have to be modified to display both of them side-by-side.
As an alternative, you could have one camera write to the even lines of a buffer and the other write to the odd lines. Then, assuming TV.spin is interlaced (and I don't honestly remember whether it is), you can use shutter glasses for the stereo effect. Be sure to have some aspirin on hand, though!
-Phil
Absolutely fabulous. Your code is gorgeous and the documentation is superb. It belongs in a book about PASM.
I'm not sure how many I am going to order… I don't see a volume discount, yet:)
Rich
the or more part requires more props:) or prop2/3's
My first image:
dgately
-Phil
Just got the PropCam and a BackPack. Pretty neat! Only got a few grey hairs waiting for it
Going to try and implement the camera with a ADC08100 and try to itegrate it with Viewport Open CSV.
It seems like using an ADC08100 would be an alternative to using the PropCAM rather and an accessory to the PropCAM. I think any NTSC video camera would work with the ADC08100. What's the benefit of using the PropCAM with it?
I haven't purchased a PropCAM myself but I can't imagine I'll hold out for much longer. There are just a lot more machine vision options for the Propeller than there used to be so I don't feel as strong of a need for the PropCAM as I used to (though I still feel the need).
It was an excuse to buy the the Propeller Backpack.
I also wanted to back Phil for all to work he has put into the product.
I wanted instant gratification, and I knew the two would work together.
In sensors with a rolling shuuter, such as the OmniVision offerings ubiquitous in other imaging modules, including the CMUCam and Parallax laser range finder, the exposure time for each pixel begins and ends when its row is read out. In the Kodak KAC9630 sensor used in the PropCAM, the exposure time for every pixel in the entire frame begins and ends at the same instant. For casual video recording, this is not a huge deal. But for machine vision applications, it's an essential benefit.
Thanks much for that!
BTW, I do have a grayscale image analysis object that's debugged but awaiting documentation. After the holidays, I intend to get that done and loosed onto the public. Stay tuned!
-Phil
Please, by all means sound commercial.
I'm sure I'll get a PropCAM but I'm very interested in any sales pitches you care to share.
I have several Wii Mote camera's which have been freed from their original housing, a Laser Range Finder, CMUcam 4, a couple of ADC08100 chips to use with NTSC cameras and a CMUcam 5 (Pixy) yet to arrive. I'll of course need a PropCAM to add to my collection but it would be great to know which applications the PropCAM would be the best tool for the job.
By all means please brag, boast and bamboozle bedazzle all you like.
I learned a lot from the Scribbler 2 software you wrote and I figure I'll likely learn a lot from the PropCAM software too. Having the hardware to use with the software you've written is a very large incentive for purchasing the PropCAM.
-Phil
I've ordered a couple of these modules Phil, and am looking forward to trying them out.
-Phil