1. Home
  2. Embedded Programming
  3. image/sensor data routing and saving?

image/sensor data routing and saving?

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!

Reply to
solarst
Loading thread data ...

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.

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

Not to my knowledge.

Yes

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.

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
    PC Services
 Timing Diagram Font
  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
 For those web sites you hate
Reply to
Paul Carpenter

[snip...snip...]

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.

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.

No OS required.

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
Reply to
Rich Webb

e

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.

Reply to
zwsdotcom

b=

of

sin=

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.

Reply to
solarst

e
y

Okay. Take a look at the LOGOmatic .

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.

Reply to
zwsdotcom

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:

| . . . | . . . . .

Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.