image/sensor data routing and saving?

Started by solarst April 3, 2009
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!


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
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
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 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, 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.
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.