Rich Webb wrote:
> "solarst" <greatjester@hotmail.com> wrote:
> 
>> I'm looking for some help in designing a system that can take
>> data from an image sensor and store it in some sort of MMC/flash
>> memory.  It will be part of a wearable device for monitoring
>> diet/activity constantly during the day.
>
> [snip...snip...]
>
>> How is file formatting usually done with these sorts of devices?
> 
> Almost always as FAT, since most operating systems can use that
> file system. A web search along the lines of "sd mmc fat file
> system" will turn up a cubic butt-ton of links with how-to pages
> and source code.

I have no real idea about your system, but here is what I came up
with about 20 years ago.  The application was a nuclear
spectrometer, and the result was a plot.  The plot was logarithmic,
to handle various amplitudes easily, and still allow extraction of
original data (to reasonable accuracy).  The transmission was
limited to a 2400 baud link.

I scanned the actual data and resolved a minimum (below which
everything was noise) and a minimum energy (below which we couldn't
resolve things properly).  These two numbers were transmitted.  The
remaining data was converted to a log, and the minimum removed.  So
the resultant plot was effectively:

  |     .    . .
  |     .   .   .     . .  <- the actual plot transmitted
  |     . .      .   .   .
  | ........................... minimum value
  |     . <-minimum energy
   ----------------------------

The resultant data had many zeroes, so very simple data compression
served to cut the transmissions roughly in half.  The net effect
was roughly equivalent to upping the data rate from 2400 to 9600
baud.  Note that all points below 'minimum value' were transmitted
as zeroes, compressed.  Better compression was possible, but took
too much time.

The point is that the overall process is fairly complex, but it is
made of of simple things whose implementations run quickly.  The
one place that needs saving is the actual transmission time.  The
remotes were Z80 powered.  The reason was that the DMA access was
faster than the V25, and that was one limit on the overall system.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.

On Apr 3, 3:27=A0pm, "solarst" <greatjes...@hotmail.com> wrote:

> It will work autonomously as a clinical research/evaluation device. =A0Th=
e
> user shouldn't have to think much at all about using the device on a dail=
y

Okay. Take a look at the LOGOmatic <http://www.sparkfun.com/commerce/
product_info.php?products_id=3D8627>.

I think this product is 95% of your hardware requirements, though the
power supply section isn't optimized for the application. If you added
the image sensor to this board, and a little glue to attach a
rechargeable battery, I think it would fulfil the requirements. And
it's in more or less a credit card form factor.

>On Apr 3, 6:31=A0am, "solarst" <greatjes...@hotmail.com> wrote:
>
>> more geared towards applications such as this. =A0We want the system to
b=
>e
>> somewhat expandable so that we can include extra sensor data (e.g.
>> temperature sensors, accelerometers, ECG monitoring) in the next phase
of
>> the project. =A0That increases complexity of the system tremendously,
sin=
>ce
>
>Is this one of those "life recorder" projects that is supposed to be
>strapped to the user and work autonomously, or is it something they
>will interact with manually, e.g. to take pictures of their lunch?

It will work autonomously as a clinical research/evaluation device.  The
user shouldn't have to think much at all about using the device on a daily
basis, and ideally would forget s/he's wearing it over the course of a day.
 A base station would download the data and recharge the device overnight.

Thanks to all for the suggestions!  Our lab has expertise in the image
processing, privacy protection, and analog design areas, but we need a
jumping point for the embedded design aspect until we get more experience
with it.

On Apr 3, 6:31=A0am, "solarst" <greatjes...@hotmail.com> wrote:

> more geared towards applications such as this. =A0We want the system to b=
e
> somewhat expandable so that we can include extra sensor data (e.g.
> temperature sensors, accelerometers, ECG monitoring) in the next phase of
> the project. =A0That increases complexity of the system tremendously, sin=
ce

Is this one of those "life recorder" projects that is supposed to be
strapped to the user and work autonomously, or is it something they
will interact with manually, e.g. to take pictures of their lunch?

If the latter, do not waste time designing yet another mousetrap. Use
an existing cellphone platform, which will have many of your desired
sensors built in, can attach to your other sensors using Bluetooth,
and can store its data on the network.

On Fri, 03 Apr 2009 05:31:56 -0500, "solarst" <greatjester@hotmail.com>
wrote:

>Lots of questions, I hope someone can guide me in the right direction!
>
>I'm looking for some help in designing a system that can take data from an
>image sensor and store it in some sort of MMC/flash memory.  It will be
>part of a wearable device for monitoring diet/activity constantly during
>the day.
[snip...snip...]
>How is file formatting usually done with these sorts of devices?

Almost always as FAT, since most operating systems can use that file
system. A web search along the lines of "sd mmc fat file system" will
turn up a cubic butt-ton of links with how-to pages and source code.

>  Are
>there dedicated chips for packing data into certain file formats

For one-off and low production rate devices, you can make a build/buy
decision to use a module, typically UART- or SPI-interfaced, that
offloads the filesystem handling from your chip. DiskOnChip used to make
one but that seems to have gone away since SanDisk acquired them.

> or do we
>need a rudimentary OS on a microcontroller?

No OS required.

>  I'm familiar with the simpler
>family of Microchip PICs (8F and 16F), but there have to be others that are
>more geared towards applications such as this.

Now might be a good time to investigate the ARM family. There are
multiple manufacturers that implement an ARM7, ARM9, or Cortex core with
their own peripheral set. The NXP (nee Philips) LPC2xxx chips are pretty
popular but there are offerings from Atmel, ST, many others.

-- 
Rich Webb     Norfolk, VA

In article <YO-dndSWeP8BeEjUnZ2dnUVZ_gKdnZ2d@giganews.com>, 
greatjester@hotmail.com says...
> Lots of questions, I hope someone can guide me in the right direction!
> 
> I'm looking for some help in designing a system that can take data from an
> image sensor and store it in some sort of MMC/flash memory.  It will be
> part of a wearable device for monitoring diet/activity constantly during
> the day.
> 
> We're looking into using an image sensor from OmniVision that has built-in
> JPEG compression (e.g. OV03640).  We'd like the resolution to be as high as
> possible (2 or 3 Megapixels?) to make later off-line processing results
> more precise, but obviously lower resolutions would be easier to handle in
> terms of power and time, and might not require the compression.  Our
> highest frame rate currently only has to be 1 fps (again, saving power and
> processing time), but we'd like the option of lower resolution video for
> future applications.

You will probably end up with smaller frame size, as the requirements for 
memory and processing even saving time of larger image , will be a bigger
batery drain. Battery wieght is the biggest part of such a device and 
often dictates, what everything else can do.

Remember that at 1fps, a 2 or 3 Megapixel imager (colour as part number 
suggests), means even if compressed, means you are likely to have approx 
1 MB to save every second.

> How is file formatting usually done with these sorts of devices?  Are

It is not the imager just provides a stream of data.

> there dedicated chips for packing data into certain file formats, or do we

Not to my knowledge.

> need a rudimentary OS on a microcontroller?  I'm familiar with the simpler

Yes

> family of Microchip PICs (8F and 16F), but there have to be others that are
> more geared towards applications such as this.  We want the system to be
> somewhat expandable so that we can include extra sensor data (e.g.
> temperature sensors, accelerometers, ECG monitoring) in the next phase of
> the project.  That increases complexity of the system tremendously, since
> we'll have to time stamp data somehow and really multi-task with the
> controller to synchronize the different types of data and get everything on
> the MMC in a timely fashion.

You need to look at low power microcontrollers, possibly also external 
RAM to buffer data to be sent to storage device, as imagers tend to 
produce a non-stoppable stream of data.
 
> Any and all suggestions, directions, and corrections are much
> appreciated!

Work out your max battery weight and size to maintain wearable.

Then work out how long the device has to be powered for and what
power density can be achieved.

From this power budget start working out what can be achieved
along with how much data is flying around at what update rates.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

Lots of questions, I hope someone can guide me in the right direction!

I'm looking for some help in designing a system that can take data from an
image sensor and store it in some sort of MMC/flash memory.  It will be
part of a wearable device for monitoring diet/activity constantly during
the day.

We're looking into using an image sensor from OmniVision that has built-in
JPEG compression (e.g. OV03640).  We'd like the resolution to be as high as
possible (2 or 3 Megapixels?) to make later off-line processing results
more precise, but obviously lower resolutions would be easier to handle in
terms of power and time, and might not require the compression.  Our
highest frame rate currently only has to be 1 fps (again, saving power and
processing time), but we'd like the option of lower resolution video for
future applications.

How is file formatting usually done with these sorts of devices?  Are
there dedicated chips for packing data into certain file formats, or do we
need a rudimentary OS on a microcontroller?  I'm familiar with the simpler
family of Microchip PICs (8F and 16F), but there have to be others that are
more geared towards applications such as this.  We want the system to be
somewhat expandable so that we can include extra sensor data (e.g.
temperature sensors, accelerometers, ECG monitoring) in the next phase of
the project.  That increases complexity of the system tremendously, since
we'll have to time stamp data somehow and really multi-task with the
controller to synchronize the different types of data and get everything on
the MMC in a timely fashion.

Any and all suggestions, directions, and corrections are much
appreciated!