Re: [Balloon] Add ons and expansion mechanical layout

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: Paul Carpenter
Date:  
To: Steve Wiseman, balloon
Subject: Re: [Balloon] Add ons and expansion mechanical layout
In message <5YSEA3VC0WVOIGAESRIHA74WA52U09.405ad824@beth>
Steve Wiseman writes:
>19/03/2004 08:54:44, Paul Carpenter
><> wrote:
>
>>I noticed the site from the recent Electronics Weekly write up on
>Aleph and
>>the Balloon board...
>
>Woo! Fame!
>
>>Looked around the site and see some interesting things, noted
>that someone
>>was interested in video grabber boards, one of my fortes...
>
>Ah, that'll be me, then... Not least because I seem to have 300-
>odd Sony CCD & lens blocks cluttering my house.
>http://pub.se7ens.net/lists/cam7/EVI-101_side_on_a.jpg


From what I can see of the Sony information they must be old! They claimed
to have stopped shipping in 93...

>They're PAL output, and when they work, they're rather spiffy.
>Nice optics, decent CCD. When they don't (about 95% of the time
>they just won't boot right, and data to drive them is sparse /
>nonexistent), they're useless. (Auto-iris goes bezerk, as does AF)


The horrible Sony communications 'protocol'... It was a bit of a nightmare
last time I lloked at it.

>If they could be persuaded to work, either by cunning or by
>replacing the entire electronics with something a little more
>modern (the glassware can justify a substantially better resolution
>than PAL, and imaging chips are cheap these days), they, coupled
>to a Balloon, would make an exceptionally nice webcam.


For Webcam the last thing you need is resolution, most webcams give a quarter
VGA resolution at best, anyway the data transmission becomes the bottleneck.
One design I have done, has dedicated hardware doing 2GIPs processing
continuous on byte wide data of real time video.

For different and simpler electronics I would look at CMOS sensors like
Omnivision, all the processing on chip and some versions have digital o/ps.

>>Are people interested in video grabber addons?
>>If so what type(s) of input?
>> e.g. PAL/NTSC, composite, SVHS, RGB, or other?
>
>Does it matter? Don't most capture chips support all of these
>(except maybe RGB)?


If you want a high end camera block, you will need better than a
'multi-media' capture chip to see any benefit. With RGB you need
a triple ADC and possibly some processing, all need good genlocking
to incoming SYNC for accurate pixel locking. Most of them have some
nasty habits of dropping pixels and other vagueries.

>>Number of inputs?
>
>Tricky... Depends what you imagine it doing - random stills,
>streaming, or something else.


Multiple inputs allows for multiple cameras like security surveillance, other
analytical work on multiple views, or even automation of inspection from
multiple views.

>>Direct memory interface, or DMA type interface?
>
>Again, tricky. The SA1110 doesn't expose any DMAs, so capturing
>into a chunk of external memory is probably the best you can do,
>with interrupts for new frame / field.


Hmmmm... large chunk of memory for a stream then, as 768x576 25 times a
second is a lot of data to hand off. Probably with flags for frames
available etc..

>PXA does seem to support external DMA sources, but I'm not sure
>it gains you anything except being able to run smaller external
>buffers.


The actual overhead of moving large amounts of data, potentially upto
11059200 bytes/second for a MONO and 33177600 bytes/second for COLOUR
is not insignificant. Delays can be significant even for a webcam if
you are skipping frames in the first place, grabbing a frame, moving
it, processing it, then saving it. Grabbing direct to internal RAM
even for a field or frame can significantly reduce the board space
and overhead required.

For single field/frame grab software PIO transfer becomes possible.

However frame buffers then have to be dual (sometimes triple) ported, by
using internal memory, and only transferring when grabbing the ADC(s) can be
directly connected to DAC(s) to reconstitute the signal for seeing what
exactly the camera is seeing in real time for at least setup of focus.

>>Of course to do this requires mechanical format details and the
>like, which
>>I could not find easily on the site.
>
>Should be in the gerbers. I've just prepared a drawing for 2.06,
>but that's not on the web yet, since we've not confirmed that it
>works. If you want a risky early set of gerbers, let me know.


I will double check the Gerbers.

>Mounting Balloon is currently a hot topic. V2.06 and later have a
>usable bare ring around the edge of the board, to allow it to be
>slid into machined mounting blocks. This avoids any need to waste
>real-estate on mounting holes which will inevitably be in the wrong
>place for many users.
>(That said, 2.06 does have 2 mounting holes. They're a massive
>compromise, though, and their position is not promised to be
>stable for future versions. Clamping the edge of the board is my
>favoured solution into the future. (The ring around the edge is
>grounded, both sides, and is appropriate for solder-tacking the
>Balloon into a formed tin can, if you feel the need.))
>I expect tin cans & plastic mounting blocks will be offered in due
>course - probably by the first person / company to need them :)


Well I will have a think about it.

-- 
Paul Carpenter        | 
<http://www.pcserv.demon.co.uk/>        Main Site
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.readingsme.org.uk/>         Reading SME Business Club info
<http://www.badweb.org.uk/>             For those web sites you hate