Camera I/F's

Started by Don Y July 8, 2017
I hacked together my "IP cameras" using some web cams for which I was
able to track down some FOSS i/f implementation documentation.  This
was OK for a proof of concept.  But, I now have to settle on "production"
hardware.

There seem to be a variety of i/f's for cameras:
- RS170 (requires hardware to digitize the signal; inflexible)
- parallel (video is digized, just needs to be captured at pixel rate)
- USB (digitized but packed in proprietary transport protocols over USB)
- CSI (digitized with specialty hardware required in host)
- IP (digitized but packed in protocols over IP)

The USB option is the easiest from the host's *hardware* point of view.
But, seems to limit the devices that could be supported as camera
vendors are loathe to publish details that only *their* driver implementers
should need.

RS170 is... "passe"

Parallel requires lots of signals to/from the host/camera.

CSI seems to be primarily supported on hosts intended to address the
mobile market.

As USB is essentially "free" (hardware-wise), adding support for it as
an *alternative* interface seems prudent.

Relying on CSI seems like it will restrict my choice of processor(s)
going forward (I'd like to standardize on *a* host platform and not
have to support a variety) -- though that's where the volume lies
(think camera in cell phones).  OTOH, it may make getting components
difficult (small fish, etc.)

IP seems to have more costs than USB with little/no gain.

Anyone been down this road who can share experiences?  Probably
only looking at 10K/yr...
On 08.7.2017 г. 21:05, Don Y wrote:
> I hacked together my "IP cameras" using some web cams for which I was > able to track down some FOSS i/f implementation documentation. This > was OK for a proof of concept. But, I now have to settle on "production" > hardware. > > There seem to be a variety of i/f's for cameras: > - RS170 (requires hardware to digitize the signal; inflexible) > - parallel (video is digized, just needs to be captured at pixel rate) > - USB (digitized but packed in proprietary transport protocols over USB) > - CSI (digitized with specialty hardware required in host) > - IP (digitized but packed in protocols over IP) > > The USB option is the easiest from the host's *hardware* point of view. > But, seems to limit the devices that could be supported as camera > vendors are loathe to publish details that only *their* driver implementers > should need. > > RS170 is... "passe" > > Parallel requires lots of signals to/from the host/camera. > > CSI seems to be primarily supported on hosts intended to address the > mobile market. > > As USB is essentially "free" (hardware-wise), adding support for it as > an *alternative* interface seems prudent. > > Relying on CSI seems like it will restrict my choice of processor(s) > going forward (I'd like to standardize on *a* host platform and not > have to support a variety) -- though that's where the volume lies > (think camera in cell phones). OTOH, it may make getting components > difficult (small fish, etc.) > > IP seems to have more costs than USB with little/no gain. > > Anyone been down this road who can share experiences? Probably > only looking at 10K/yr...
The obvious choice would be the MIPI cameras - like in every phone. A few years ago I looked into that; I found out they (MIPI) had some special (politburo) membership fee if you were a "small enterprise", "small" meant if you had < $100M annual revenue IIRC... It is getting all but impossible to be a small maker of tech gadgets, everything is becoming accessible only for politburo members. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Hi Dimiter,

[Still 40+C every day.  18 consecutive days with a high temperature
above 40C.  Those huge icicles sure would be nice right about now!  :> ]

On 7/8/2017 11:30 AM, Dimiter_Popoff wrote:
> On 08.7.2017 &#1075;. 21:05, Don Y wrote: >> I hacked together my "IP cameras" using some web cams for which I was >> able to track down some FOSS i/f implementation documentation. This >> was OK for a proof of concept. But, I now have to settle on "production" >> hardware. >> >> There seem to be a variety of i/f's for cameras: >> - RS170 (requires hardware to digitize the signal; inflexible) >> - parallel (video is digized, just needs to be captured at pixel rate) >> - USB (digitized but packed in proprietary transport protocols over USB) >> - CSI (digitized with specialty hardware required in host) >> - IP (digitized but packed in protocols over IP) >> >> The USB option is the easiest from the host's *hardware* point of view. >> But, seems to limit the devices that could be supported as camera >> vendors are loathe to publish details that only *their* driver implementers >> should need. >> >> RS170 is... "passe" >> >> Parallel requires lots of signals to/from the host/camera. >> >> CSI seems to be primarily supported on hosts intended to address the >> mobile market. >> >> As USB is essentially "free" (hardware-wise), adding support for it as >> an *alternative* interface seems prudent. >> >> Relying on CSI seems like it will restrict my choice of processor(s) >> going forward (I'd like to standardize on *a* host platform and not >> have to support a variety) -- though that's where the volume lies >> (think camera in cell phones). OTOH, it may make getting components >> difficult (small fish, etc.) >> >> IP seems to have more costs than USB with little/no gain. >> >> Anyone been down this road who can share experiences? Probably >> only looking at 10K/yr... > > The obvious choice would be the MIPI cameras - like in every phone.
Yes, MIPI being the backers of the CSI approach. Its great appeal is so few conductors to the camera and megapixel support!
> A few years ago I looked into that; I found out they (MIPI) had some > special (politburo) membership fee if you were a "small enterprise", > "small" meant if you had < $100M annual revenue IIRC...
I'd be more worried about actually getting *parts* than "specs" (which is what the "membership fee" provides). There's a point (sales volume) below which folks addressing markets with HUGE customers simply don't want to be bothered. Or, you worry about the part being "on allocation", etc.
> It is getting all but impossible to be a small maker of tech gadgets, > everything is becoming accessible only for politburo members.
Its been that way for a long time. *Timely* access being the issue (you can easily buy parts that have "lost their shine"). I think a prudent course will be to start gutting existing products just to see what other manufacturers have "decided" (by way of their designs) is the best way forward.
On Sat, 08 Jul 2017 11:05:26 -0700, Don Y wrote:

> I hacked together my "IP cameras" using some web cams for which I was > able to track down some FOSS i/f implementation documentation. This > was OK for a proof of concept. But, I now have to settle on "production" > hardware. > > There seem to be a variety of i/f's for cameras: > - RS170 (requires hardware to digitize the signal; inflexible) > - parallel (video is digized, just needs to be captured at pixel rate) > - USB (digitized but packed in proprietary transport protocols over USB) > - CSI (digitized with specialty hardware required in host) > - IP (digitized but packed in protocols over IP) > > The USB option is the easiest from the host's *hardware* point of view. > But, seems to limit the devices that could be supported as camera > vendors are loathe to publish details that only *their* driver implementers > should need. > > RS170 is... "passe" > > Parallel requires lots of signals to/from the host/camera. > > CSI seems to be primarily supported on hosts intended to address the > mobile market. > > As USB is essentially "free" (hardware-wise), adding support for it as > an *alternative* interface seems prudent. > > Relying on CSI seems like it will restrict my choice of processor(s) > going forward (I'd like to standardize on *a* host platform and not > have to support a variety) -- though that's where the volume lies > (think camera in cell phones). OTOH, it may make getting components > difficult (small fish, etc.) > > IP seems to have more costs than USB with little/no gain. > > Anyone been down this road who can share experiences? Probably > only looking at 10K/yr...
I've been looking for a 2MP 30fps solution. For 10K units the China guys will probably give you a deal and customize if you want to go that way. Alibaba as a boat load of pages of people making IP cameras based on the HiSilicon Hi3516C chip and different image sensors. Lot of options for the CSI route. Cypress has a CSI->USB chip. A PI zero for 10 bucks and a camera is also a easy way to get to USB A PI zero and a USB->Enet will get you a IP camera. A PI 3 and a camera will get you a netcam but at that price you might as well just buy a IP camera. TI has a CSI-2 FPD-Link III Serializer which I really need but it's still showing pre-production. With that you could plug a CSI camera in one end, use a twisted pair and get CSI or LVDS out the other end with one of their deserializers. Finally there are several articles about interfacing the CSI physical layer to a FPGA and some open source VHDL to deal with the link interface. I'd really like to shove the CSI,H.264 and Ethernet in a FPGA. But the price of the PI Zero starts eating your lunch. I need something smaller but might have to live with it for now. Price wise it seems the PI zero and a camera module is the least expensive. I got one of the China IP camera modules and it sucked. Ran REAL HOT. Severe video lag when moving the camera. Interesting if you telnet to the unit the prompt is "ak47 login:" -- Chisolm Republic of Texas
On 08.7.2017 &#1075;. 23:41, Don Y wrote:
> Hi Dimiter, > > [Still 40+C every day. 18 consecutive days with a high temperature > above 40C. Those huge icicles sure would be nice right about now! :> ]
We had 2-3 hot days (up to 38C) and then a cold wave came, now we are below 30. Pretty good during the day but the nights get below 20C, pretty unusual for July here. All that with the very long winter we had, average annual temperatures will likely be way below the norm.
> > On 7/8/2017 11:30 AM, Dimiter_Popoff wrote: >> On 08.7.2017 &#1075;. 21:05, Don Y wrote: >>> I hacked together my "IP cameras" using some web cams for which I was >>> able to track down some FOSS i/f implementation documentation. This >>> was OK for a proof of concept. But, I now have to settle on >>> "production" >>> hardware. >>> >>> There seem to be a variety of i/f's for cameras: >>> - RS170 (requires hardware to digitize the signal; inflexible) >>> - parallel (video is digized, just needs to be captured at pixel rate) >>> - USB (digitized but packed in proprietary transport protocols over USB) >>> - CSI (digitized with specialty hardware required in host) >>> - IP (digitized but packed in protocols over IP) >>> >>> The USB option is the easiest from the host's *hardware* point of view. >>> But, seems to limit the devices that could be supported as camera >>> vendors are loathe to publish details that only *their* driver >>> implementers >>> should need. >>> >>> RS170 is... "passe" >>> >>> Parallel requires lots of signals to/from the host/camera. >>> >>> CSI seems to be primarily supported on hosts intended to address the >>> mobile market. >>> >>> As USB is essentially "free" (hardware-wise), adding support for it as >>> an *alternative* interface seems prudent. >>> >>> Relying on CSI seems like it will restrict my choice of processor(s) >>> going forward (I'd like to standardize on *a* host platform and not >>> have to support a variety) -- though that's where the volume lies >>> (think camera in cell phones). OTOH, it may make getting components >>> difficult (small fish, etc.) >>> >>> IP seems to have more costs than USB with little/no gain. >>> >>> Anyone been down this road who can share experiences? Probably >>> only looking at 10K/yr... >> >> The obvious choice would be the MIPI cameras - like in every phone. > > Yes, MIPI being the backers of the CSI approach. Its great appeal > is so few conductors to the camera and megapixel support! > >> A few years ago I looked into that; I found out they (MIPI) had some >> special (politburo) membership fee if you were a "small enterprise", >> "small" meant if you had < $100M annual revenue IIRC... > > I'd be more worried about actually getting *parts* than "specs" > (which is what the "membership fee" provides). There's a point > (sales volume) below which folks addressing markets with HUGE > customers simply don't want to be bothered. > > Or, you worry about the part being "on allocation", etc.
I don't see how I can get to these worries. The CSI specification is "members only". Then this market is so huge there will always be some stock unless you are after the latest versions. Or if you want to go into the volumes of say Samsung but in this case you'd have allocation issues whatever type you go for, probably worse than with mipi. Dimiter
In article <ojr6lv$188$1@dont-email.me>, blockedofcourse@foo.invalid 
says...
> > I hacked together my "IP cameras" using some web cams for which I was > able to track down some FOSS i/f implementation documentation. This > was OK for a proof of concept. But, I now have to settle on "production" > hardware. > > There seem to be a variety of i/f's for cameras: > - RS170 (requires hardware to digitize the signal; inflexible) > - parallel (video is digized, just needs to be captured at pixel rate) > - USB (digitized but packed in proprietary transport protocols over USB) > - CSI (digitized with specialty hardware required in host) > - IP (digitized but packed in protocols over IP) > > The USB option is the easiest from the host's *hardware* point of view. > But, seems to limit the devices that could be supported as camera > vendors are loathe to publish details that only *their* driver implementers > should need. > > RS170 is... "passe" > > Parallel requires lots of signals to/from the host/camera. > > CSI seems to be primarily supported on hosts intended to address the > mobile market. > > As USB is essentially "free" (hardware-wise), adding support for it as > an *alternative* interface seems prudent. > > Relying on CSI seems like it will restrict my choice of processor(s) > going forward (I'd like to standardize on *a* host platform and not > have to support a variety) -- though that's where the volume lies > (think camera in cell phones). OTOH, it may make getting components > difficult (small fish, etc.) > > IP seems to have more costs than USB with little/no gain. > > Anyone been down this road who can share experiences? Probably > only looking at 10K/yr...
My problem is without knowing what type of data flow (what will happen to the viideo still or stream), rates you are requiring and for how many sources it is difficult to suggest anything. If you want an I/F to take almost any resolution from multiple cameras to then do something with, even as HDMI or LVDS then you could look at Averlogic AL360 and AL361 devices, all relatively new and they send samples around the world. See http://www.averlogic.com/AL362.asp and http://www.averlogic.com/AL361.asp Inthe past I have used various devices from people like Conexant when I was building something with my own sensors and lenses. Aptina can be easier to get small supplies of sensors than others. -- Paul Carpenter | paul@pcserviceselectronics.co.uk <http://www.pcserviceselectronics.co.uk/> PC Services <http://www.pcserviceselectronics.co.uk/LogicCell/> Logic Gate Education <http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font <http://www.badweb.org.uk/> For those web sites you hate
>> [Still 40+C every day. 18 consecutive days with a high temperature >> above 40C. Those huge icicles sure would be nice right about now! :> ] > > We had 2-3 hot days (up to 38C) and then a cold wave came, now we are > below 30. Pretty good during the day but the nights get below 20C, > pretty unusual for July here. All that with the very long winter we had, > average annual temperatures will likely be way below the norm.
Our *nights* just barely fall below 30C. Average 24 hour temperature is often 30C+. Rains will start (hopefully) soon to moderate these temperatures a bit (maybe 5-7C) -- at the expense of humidity.
>> On 7/8/2017 11:30 AM, Dimiter_Popoff wrote: >>> On 08.7.2017 &#1075;. 21:05, Don Y wrote:
>>>> Relying on CSI seems like it will restrict my choice of processor(s) >>>> going forward (I'd like to standardize on *a* host platform and not >>>> have to support a variety) -- though that's where the volume lies >>>> (think camera in cell phones). OTOH, it may make getting components >>>> difficult (small fish, etc.) >>>> >>>> IP seems to have more costs than USB with little/no gain. >>>> >>>> Anyone been down this road who can share experiences? Probably >>>> only looking at 10K/yr... >>> >>> The obvious choice would be the MIPI cameras - like in every phone. >> >> Yes, MIPI being the backers of the CSI approach. Its great appeal >> is so few conductors to the camera and megapixel support! >> >>> A few years ago I looked into that; I found out they (MIPI) had some >>> special (politburo) membership fee if you were a "small enterprise", >>> "small" meant if you had < $100M annual revenue IIRC... >> >> I'd be more worried about actually getting *parts* than "specs" >> (which is what the "membership fee" provides). There's a point >> (sales volume) below which folks addressing markets with HUGE >> customers simply don't want to be bothered. >> >> Or, you worry about the part being "on allocation", etc. > > I don't see how I can get to these worries. The CSI specification is > "members only".
Yes. But paying for membership can be a one-time thing (to access specs). Or, accessed by "other means"... :>
> Then this market is so huge there will always be some stock unless > you are after the latest versions. Or if you want to go into the > volumes of say Samsung but in this case you'd have allocation > issues whatever type you go for, probably worse than with mipi.
It's often an issue of finding someone willing to *talk* to you for orders that are considered "tiny". You'd be dealing direct with the manufacturer so wouldn't really have any leverage with a local disti (you might be a "big customer" to a local disti but small-fry to the manufacturer). Dunno. It's always a crap shoot trying to guess where the *practical* market is headed so you don't design in the "right" device for the application only to discover its the *wrong* device for the "product".
Hi Joe,

On 7/8/2017 3:06 PM, Joe Chisolm wrote:
> On Sat, 08 Jul 2017 11:05:26 -0700, Don Y wrote: > >> I hacked together my "IP cameras" using some web cams for which I was >> able to track down some FOSS i/f implementation documentation. This >> was OK for a proof of concept. But, I now have to settle on "production" >> hardware. >> >> There seem to be a variety of i/f's for cameras: >> - RS170 (requires hardware to digitize the signal; inflexible) >> - parallel (video is digized, just needs to be captured at pixel rate) >> - USB (digitized but packed in proprietary transport protocols over USB) >> - CSI (digitized with specialty hardware required in host) >> - IP (digitized but packed in protocols over IP)
> I've been looking for a 2MP 30fps solution. For 10K units the China > guys will probably give you a deal and customize if you want to go > that way.
But, they're likely to customize a *camera*, not "my application" (camera is just one of many "peripherals" in this device).
> Alibaba as a boat load of pages of people making IP cameras based on the > HiSilicon Hi3516C chip and different image sensors.
That would, essentially, be the "buy a custom camera PRODUCT" -- typ USB I/O. I'd still talk to it as a USB peripheral (the 3516 would be a bad match for the other needs that I have; it's deigned with "I'm a camera" in mind)
> Lot of options for the CSI route. Cypress has a CSI->USB chip. > A PI zero for 10 bucks and a camera is also a easy way to get to USB > A PI zero and a USB->Enet will get you a IP camera. A PI 3 and a > camera will get you a netcam but at that price you might as well just > buy a IP camera.
Yes, its easy to QUICKLY end up at the "high level interface" approach to the "camera component".
> TI has a CSI-2 FPD-Link III Serializer which I really need but it's > still showing pre-production. With that you could plug a CSI camera > in one end, use a twisted pair and get CSI or LVDS out the other end > with one of their deserializers.
In my case, the twisted pair would just be a few inches long. But, the "camera conditioning" (SERDES) would necessitate making the "camera PCB" larger (than just the bare sensor with *its* I/O connections).
> Finally there are several articles about interfacing the CSI physical > layer to a FPGA and some open source VHDL to deal with the > link interface. I'd really like to shove the CSI,H.264 and Ethernet > in a FPGA. But the price of the PI Zero starts eating your lunch. > I need something smaller but might have to live with it for now.
In my case, I want the "local processor" to actually *deal* with the imagery, not just pull it off the camera, encode and encrypt it for "remote handling". And, the needs of one camera instance will be different than others (e.g., surveilling outdoor areas is different than recognizing faces). So, choice of camera sensor as well as code behind it will vary from one "camera" to the next.
> Price wise it seems the PI zero and a camera module is the least > expensive. I got one of the China IP camera modules and it sucked. > Ran REAL HOT. Severe video lag when moving the camera. > Interesting if you telnet to the unit the prompt is > "ak47 login:"
I'd like to be able to trade dollars for performance (as above). But, don't want to have to design different "host hardware" for each possible "video price/performance point". It seems like USB is the "safe" bet in that I can always play "big customer" by approaching a COTS camera supplier with a big buy and a request for protocol details (under NDA). Then, just worry about a four conductor cable traveling to the "sensor". The downside is there is a lot of overhead in the USB stack. So, maybe prune it down to something that KNOWS the camera is its only peripheral?
On 7/9/2017 3:58 AM, Paul wrote:
> In article <ojr6lv$188$1@dont-email.me>, blockedofcourse@foo.invalid > says... >> >> I hacked together my "IP cameras" using some web cams for which I was >> able to track down some FOSS i/f implementation documentation. This >> was OK for a proof of concept. But, I now have to settle on "production" >> hardware. >> >> There seem to be a variety of i/f's for cameras: >> - RS170 (requires hardware to digitize the signal; inflexible) >> - parallel (video is digized, just needs to be captured at pixel rate) >> - USB (digitized but packed in proprietary transport protocols over USB) >> - CSI (digitized with specialty hardware required in host) >> - IP (digitized but packed in protocols over IP) >> >> The USB option is the easiest from the host's *hardware* point of view. >> But, seems to limit the devices that could be supported as camera >> vendors are loathe to publish details that only *their* driver implementers >> should need. >> >> RS170 is... "passe" >> >> Parallel requires lots of signals to/from the host/camera. >> >> CSI seems to be primarily supported on hosts intended to address the >> mobile market. >> >> As USB is essentially "free" (hardware-wise), adding support for it as >> an *alternative* interface seems prudent. >> >> Relying on CSI seems like it will restrict my choice of processor(s) >> going forward (I'd like to standardize on *a* host platform and not >> have to support a variety) -- though that's where the volume lies >> (think camera in cell phones). OTOH, it may make getting components >> difficult (small fish, etc.) >> >> IP seems to have more costs than USB with little/no gain. >> >> Anyone been down this road who can share experiences? Probably >> only looking at 10K/yr... > > My problem is without knowing what type of data flow (what will happen > to the viideo still or stream), rates you are requiring and for how many > sources it is difficult to suggest anything.
*One* camera paired to *one* processor. The demands made of the camera can vary, though -- and the processor does other things besides just conditioning video for delivery to a "remote". In some cases, I might want high frame rates at the expense of detail. In other cases, the exact opposite. Most of the frames may get discarded to concentrate on "areas of interest" -- based on an analysis of the *entire* frame (at a slower rate). I use cameras to access a variety of "field conditions" that are otherwise hard to instrument. Tweaking the software or optics (or even the choice of image sensor) is easier than having to move to a different processor (family) to meet a different application.
> If you want an I/F to take almost any resolution from multiple cameras > to then do something with, even as HDMI or LVDS then you could look at > > Averlogic AL360 and AL361 devices, all relatively new and they send > samples around the world. > > See > http://www.averlogic.com/AL362.asp > and > http://www.averlogic.com/AL361.asp
<frown> First glance looks like intended for a different market. I'll have to spend some more time looking at them, though. Thanks!
> Inthe past I have used various devices from people like Conexant when I > was building something with my own sensors and lenses. Aptina can be > easier to get small supplies of sensors than others.
I recall an 8 camera RS170 interface that they made some years ago. But, I think that's an obsolescent (if not already obsolete!) path for designs going forward. There (currently) seems to be a disconnect between the consumer (video/surveillance) camera market and the "cell phone" camera market. Will this persist? Or, will we start seeing 4MP (and higher) as the new normal for consumer camera kit of all types? (i.e., because the cell phone volumes end up driving ALL sensor production)
Don Y <blockedofcourse@foo.invalid> wrote:
> In some cases, I might want high frame rates at the expense of detail. > In other cases, the exact opposite. Most of the frames may get discarded > to concentrate on "areas of interest" -- based on an analysis of the > *entire* frame (at a slower rate). > > I use cameras to access a variety of "field conditions" that are otherwise > hard to instrument. Tweaking the software or optics (or even the choice > of image sensor) is easier than having to move to a different processor > (family) to meet a different application.
One thing worth pointing out is that talking to a camera in CSI or other native format gives you essentially unprocessed RAW data. On a smartphone the ISP processor does (quite a lot of) image processing to turn the pixels into an acceptable JPEG image. This includes all of the vendor tricks like dual cameras, HDR, white balance, etc. If you just want JPEGs you can slap down a network connection, you might want a chip that does all the image processing for you, which is what you get in USB/etc land. If you want to attach to a raw sensor then be prepared to budget for some compute (and software) to tidy up the images for you. Theo