amerdsp wrote:
> 
> I have other restrictions inclduing size, the smaller the better.  In
> fact all the restrictions are competing with each other.. power,
> efficiancy, size, battery life.. etc..
> 
> It is great that you can use obsolete equipment for something
> beneficial.

In this particular case it doesn't matter too much, but in general
on usenet you should realize that readers may very well not have
convenient access to previous articles in a thread.  That means
that your reply articles should include adequate context, so that
they stand by themselves.  Google is NOT usenet, it is only a very
poor interface to the real usenet system.  To include proper
context when using google, see my sig. below.  Please be sure to
read the referenced URLs.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

amerdsp wrote:
> How large is your setup?

Just an AT style motherboard, sideway PCI card,
and USB Wifi adapter.  Fanless K6 233 MHz.
SDRAM max out at 48M, so useless for anything else.
No drive other than a 64M IDE-CF.

Linux 2.6.16 (mainly for the SAA7130).

We were using a USB based OV511 (8 bits),
but it's too slow and too low in resolution.

The 12 bits SAA7130 is much better.

>
> I have other restrictions inclduing size, the smaller the better.  In
> fact all the restrictions are competing with each other.. power,
> efficiancy, size, battery life.. etc..

What is your required frame rate?
We need at least 3 per second,
so we can't really run it slower.

In fact, we might need a faster CPU
to track a moving object.

You should work out your requirements for
resources before committing to hardwares.

>
>   It is great that you can use obsolete equipment for something
> beneficial.

Yeap, it was a recycled board that nobody wants.
There are plenty of 100/200MHz CPU w/ 64M around.
They usually cost less than filling up your gas tank.

How large is your setup?

I have other restrictions inclduing size, the smaller the better.  In
fact all the restrictions are competing with each other.. power,
efficiancy, size, battery life.. etc..

  It is great that you can use obsolete equipment for something
beneficial.

amerdsp wrote:
> Thats would be great except that I am unable to sun power to the site,
> it has to run of a battery.

Yes, we can run it off battery, with a 50W solar panel charger.
Our setup takes about 20W, wuth the rest saved for overnight.

>
> I found an epson network camera controller that has ar ARM MCU built in
> with a hardware jpeg encoder.  Has anyone used one of these before?  I
> am waiting until after the weekend to check where I can get a couple
> for prototyping.

Did a quick check on the spec.  It can do 7 fps on VGA, with the
hardware JPEG encoder.  That part is good.  But...

    Epson/Arm7 vs.  Phillips/PC
1. 8 bits LUV vs. 12 bits LUV
2. 640x480 vs. 582x480
3. 50MHz vs. 200MHz to 4G

In fact, we might run it on a faster PC.  We are using the
200MHz PCs because they are useless for anything else.

> 
> Thank you,
> A

Thats would be great except that I am unable to sun power to the site,
it has to run of a battery.

I found an epson network camera controller that has ar ARM MCU built in
with a hardware jpeg encoder.  Has anyone used one of these before?  I
am waiting until after the weekend to check where I can get a couple
for prototyping.

Thank you,
A

Wilco Dijkstra wrote:
> "amerdsp" <amerdsp@hotmail.com> wrote in message
> news:1147484742.253499.180240@j33g2000cwa.googlegroups.com...
> > Thank you for your helpful insight.  I am leaning towards an ARM
> > solution, do you have any preference about which one to choose from?
> > It is so confusing with all the choices available.
>
> Any ARM7tdmi MCU can easily deal with your resolution and
> framerate using only a few MHz to do JPEG compression (a well
> optimised JPEG is extremely fast on ARM). However it will be difficult
> to do this just using on-chip SRAM, and using external SDRAM means
> power consumption may become a problem. It may be good enough if
> you can collect, process and transfer the image in small strips though,
> so you'd want to look for an ARM7 MCU with a lot of on-chip SRAM.
>
> If you want to do JPEG or similar compression and need SDRAM
> then it might be better to go for an ARM9 with cache, for example
> LPC3180, AT91RM9200 or AT91SAM9261. The caches and higher
> performance of ARM9 will significantly lower power consumption.

I would suggest at least 32MB SDRAM,
but depends on your sensor resolutions.

For a secured site, we are using a K6 for
capturing, compressing and wifi-ing
aproximately 4 frames per second
at 592x480 12 bits YUV to JPEG

You can plan your hardware by my example:

K6 233MHz
64MB IDE Compact Flash
48MB SDRAM
SAA7130 NTSC Composite
Linksys WUSB11

> Wilco

Rich Grise wrote:
> On Thu, 11 May 2006 19:41:57 -0700, amerdsp wrote:
>
> > Hello all,
> >   What would you experts do if you want to perform image compression (I
> > am thinking jpeg), on a low power board?  The data is captured from an
> > image sensor and needs to be transmitted elsewhere.  Would you use a
> > MCU bundled with a DSP or would you use two separate MCU and DSP chips?
> >  I was thinking about using a PIC with nano watt technology along with
> > a low power DSP from TI. Or should I use a dsPic? Or anything else?
> >
> > Thank you for your time and help.
> >
>
> How about MP3?

Yes, they all work the same, just differently.
MP3 works in single dimensional voice freqence.
JPEG works in two dimensional color spectrum.
MPEG works in three dimensional color and temporal spaces.
They can all be handle with the same Si + O compound.

> 
> Good Luck!
> Rich

"amerdsp" <amerdsp@hotmail.com> wrote in message 
news:1147484742.253499.180240@j33g2000cwa.googlegroups.com...
> Thank you for your helpful insight.  I am leaning towards an ARM
> solution, do you have any preference about which one to choose from?
> It is so confusing with all the choices available.

Any ARM7tdmi MCU can easily deal with your resolution and
framerate using only a few MHz to do JPEG compression (a well
optimised JPEG is extremely fast on ARM). However it will be difficult
to do this just using on-chip SRAM, and using external SDRAM means
power consumption may become a problem. It may be good enough if
you can collect, process and transfer the image in small strips though,
so you'd want to look for an ARM7 MCU with a lot of on-chip SRAM.

If you want to do JPEG or similar compression and need SDRAM
then it might be better to go for an ARM9 with cache, for example
LPC3180, AT91RM9200 or AT91SAM9261. The caches and higher
performance of ARM9 will significantly lower power consumption.

Wilco

Thank you for your helpful insight.  I am leaning towards an ARM
solution, do you have any preference about which one to choose from?
It is so confusing with all the choices available.

Thank you.

A

On Thu, 11 May 2006 19:41:57 -0700, amerdsp wrote:

> Hello all,
>   What would you experts do if you want to perform image compression (I
> am thinking jpeg), on a low power board?  The data is captured from an
> image sensor and needs to be transmitted elsewhere.  Would you use a
> MCU bundled with a DSP or would you use two separate MCU and DSP chips?
>  I was thinking about using a PIC with nano watt technology along with
> a low power DSP from TI. Or should I use a dsPic? Or anything else?
> 
> Thank you for your time and help.
> 

How about MP3?

Good Luck!
Rich