SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By KreAture
I can get you traces from my 40 msps digital logger if you like.
They are, however, not very interesting.
It's a shame the cams don't have a full internal readout-buffer so we could have read out data at our leisure via SPI or I2C.

Tell me if you can get some images from it. I still only get mostly garbage from mine...
By Random
Thanks for the offer but I think I've got the I²C all working now, just gotta try and read the data itself!

I've got the '30, which is the smaller 640x480 max one, which Twingy has already got pictures from so I probably can't be of much help in terms of registers etc if I get images from it.
By flybob

I've been watching this thread for quite a while now, since i got one myself. Finally it's time for me to share my own thoughts since i work with this cam on a project. I'm a masters student on embedded systems and don't have a lot of exp in the field but still i have quite a lot of ideas and i'd like to know your thought! My goal is to read data at minimum 640x480 at 1 fps, controlled outside the cmos.

1) an at-tiny initialises an sd-card. A cpld working at ~50mhz collects the parallel data from the cmos to the sd-card by SPI. The data is stored as RAW and read by a special program on a PC.

2) an at-tiny controls a cpld and sd-card. The cpld reads data from the cmos, stores in onto a sram as fifo. The at-tiny makes sure the cpld stops reading from cpld, and then reads from the sdram throught the cpld and outputs the data as fat onto the sd.

3) some reaaaaally fast uC does the reading and writing to an SD which seems impossible at the datarate.
By KreAture
Hehe. All good options in my book.
The reason why I am working so hard on a MCU only solution is because of the circuit size. I really want to put this all together at a low a weight and size as humanly possible.

I am looking for other cam chips though as this onne does not have a readout-buffer. If it had, the mcu could read the data when it wanted instead of having it delivered at the inconvenient rates this cams are supplying.
By buffercam
I'm having some trouble with the JPEG data that is coming off the camera.

I've attached a picture that shows what the JPEG data looks like. After the SOS (Start of Scan) structure, the same data repeats over and over.

The camera sets the error flag register (Addr 0xFA) to 0x80, which corresponds to "FULL_ERRN."

Also, I noticed that if I set the PLL mode to 0x1 instead of 0xF, both error flags become set ("ENC_ERRN" in addition to "FULL_ERRN.")
How is PLLMODE supposed to be set?
The application note says "0:PLL Off" and "1-F:PLL On".
What's the difference between the different "PLL On" settings?

Here are some other things that I've noticed:
In the DQT structure, I received a "length of field" of 0x84. This matches the length of the DQT data that I received, but does not match the length mentioned in the datasheet (pg. 21 says it should be 197bytes=0xC5).

The other structures match what the datasheet says as far as length of field goes (SOF, DHT, and SOS).
(As long as you realize that the datasheet has a typo in the SOF length of field - it should be 0x11 instead of 0xC5 - someone forgot to change it after copying and pasting.)

I have circled the JPEG marker codes in the image generated by the TCM8240MD:
Any ideas as to why the image data repeats and why I'm getting the error code?

Last edited by buffercam on Mon Nov 10, 2008 8:19 pm, edited 1 time in total.
By buffercam
Also, I am uncertain about my setup for the image size.

I'm trying to output JPEG for the "full mega" images, since I'm not sure if it's possible to do JPEG for the smaller images.
I tried setting up the registers for an image size of 1280x1024, since that is the size mentioned on pg. 20 of the datasheet.

Based on the application note, I set the following registers:
Code: Select all
	I2CWrite(0x02,0x00); //Set Camera Active
	I2CWrite(0x03,0xCF); //PLL On (last nibble correct?)
	I2CWrite(0x04,0x50); //JPEG On, DOUT On, PICMODE:1280x1024
	I2CWrite(0x05,0x80); //0x80 = max framerate, 0x00 = 1/4 framerate
	I2CWrite(0xE6,0x08); //0x08 = 4 byte output units (was 0x00)
	I2CWrite(0x0E,0xB0); //Changed b/c of PICSIZ (was 0xAC)
	I2CWrite(0x11,0x6A); //Changed b/c of PICSIZ (was 0x02)
	I2CWrite(0x14,0x33); //Changed b/c of PICSIZ (same as default)
	// Need to change SPCOUNT (on addresses 0x1F and 0x1E) ?
The application note says that after you select the image size, you have to change the registers 0x0E, 0x11, and 0x14. However, looking at the default values for those registers, they don't match what the application note says they should be for the default image size. Does anyone know why?

By KreAture
I am also having issues getting the camera to capture proper data but so far I am running it in raw (rgb 565) mode.
As you see from my images, the data transfer is correct and I can enter/exit testmodes correctly. It appears that the imaging parameters and/or framing settings are wrong causing me to fetch data from wrong area of sensor/memory or capturing garbage...
By buffercam

A few questions for you:
-- Are you getting any error flags (Register 0xFA)?
-- How are you initializing the camera registers? (for your current tests with RGB mode)
----- What image size were you going for?
----- How did you calculate SPCOUNT?
-- Have you tried YUV?

By KreAture
I will look at error flags tonight.

The SPCOUNT was done according to datasheets, but with little results.
I've been trying to run the lowest rez just to see if it worked.
I have 5 cams, currently using 2 for dev. Both give exact same "images".

I've only used rgb as I can output that serially as a file to the computer. (BMP supports RGB 565 format if you set up the header with data type bitfield!)
By buffercam
How are you calculating SPCOUNT, exactly?
I don't quite understand how HCOUNT and VCOUNT are determined.

Based on the default register values (Initial Hex from the Datasheet), I obtained the following:
Datasheet wrote: H_COUNT = 0x2B3 = 691
V_COUNT = 0x21B = 539
SP_COUNT = 0x400 = 1024
However, the Application Note quotes different numbers:
Application Note wrote: HCOUNT = H_COUNT (default:713) + 677 = 1390
VCOUNT = V_COUNT (default:539) + 513 = 1052
SPCOUNT = 2 x (H_COUNT + 183)
SPCOUNT = ... (slightly different formula for different sizes)
The application note doesn't say it, but plugging in their H_COUNT into their formula gives 2x(713+183)=1792. This is very different than the number programmed into SP_COUNT=1024. What's going on here?

Needless to say, the only Application Note number that matches the initial register value is V_COUNT.

Here are my calculations, based on what I can piece together...
There are 960H+92H(blank)=1052H in one VBLK.
This is equal to VCOUNT, so V_COUNT=539 (the default value)

It seems that the HCOUNT calculation is based on counting the clocks in a single row of image data at 1/2 the DSP clock frequency.
So for the Full Mega size, note that the data output is output at 1 x DSP frequency. This means you divide the number of clocks by two when calculating HCOUNT.
Smaller images are output at 1/4 the DSP clock rate, so you need to *multiply* the number of clocks by 2.
The result is that for every picture size, HCOUNT comes out to be approximately the default value of 713 (after you subtract the offset of 677). (I actually calculate 715.)

Also, is there a difference between:
My understanding is that "No Underscore" means the actual value that corresponds to some physical phenomena (like the number of clock periods in a certain region of the image). This is in contrast to "With Underscore," which is the way the value is stored in the register after subtracting some arbitrary offset.
Is this remotely correct?

Last edited by buffercam on Sun Nov 16, 2008 1:01 pm, edited 2 times in total.
By rgbphil
good to see some data coming out of these cameras.

This question may have been asked before, but has anyone thought of using a DOSonCHIP chip to write the camera data to an SD card?

We'd need a discrete logic shift register circuit running at eight times the camera clock speed to produce an SPI stream. Don't know if there are discrete parrallel to SPI circuits out there...but it doesn't seem a difficult idea.

The idea would be the micro would setup the file creating commands to the DosOnChip then unleash the camera which would squirt out parrallel data which would be converted to an SPI stream. At the end of the frame the micro would take over and finish up. The DosOnChip would handle the FAT management and SD card stuff.

Anyway, just my two thoughts about getting closer to a micro controlled camera without exotic CPLD or FPGAs. I doubt we'd get maximum clock speed, but surely something reasonable.

By buffercam

I hadn't heard of the DOSonCHIP module. It's pretty cool.

But it's maximum SPI frequency is 2.4Mhz.
CD17B10 Datasheet

It takes about 10 serial bits to send a byte of data using SPI.
So the limit is about 0.24 MB/s.

I'm working on a single image buffer using a 256KB SRAM chip. As the data is captured into SRAM, a PIC32 microcontroller pulls it off and stores it to flash memory (USB, SD card, or CF card).

To be more specific, it will use a counter to address the RAM.
(Need 18 bits to address all 256K x 8bits - this can be made by cascading smaller counters.)
It also requires some simple logic (AND gates, possibly a NOT gate).
Some tristate buffers are needed to prevent the camera from driving the SRAM I/O pins while the PIC is reading data from memory.
Altogether, you'll need a custom PCB to make this work, especially since the SRAM is surface mount and we're dealing with high frequencies.
By rgbphil
you know I looked and looked for a maximum speed for this device....and it was staring at me all the time.
2.4MHz...oh well, that scratches that idea.

The SRAM buffer idea looks the best. You probably won't need a PIC32 micro then, unless you want higher frame rates. Not sure you'd get that much of a frame rate increase compared to a 16Bit micro like a PIC18F4550.

When you've got the logic figured out, the PCB design should be no problem, I can help there if need any though you sound like you know your stuff.

I wonder how fast a micro can stuff data into an SD card? That'd be a limiting factor.

Once the not inconsiderable task of getting a frame out of the camera is worked out, we probably need to think of some sort of user interface.

For my application, I'm after a circuit I can stuff into a head mounted arrangement like a LED headlight, so I was thinking of doing configuration etc on a PC and only having a single button or two. Particularly if motion JPEG can be achieved (maybe with a PIC32). Not thinking of any LCD displays or such for frame counts or whatever....with a big enough card this wouldn't be necessary anyway.

The circuit should probably have some other triggers for other applications like a PIR input for security systems or capturing wildlife etc. If the media is removable then a USB FAT client probably won't be necessary but a USB client for configuration would be handy, perhaps a USB charger cct. Got that under my hat when the frame capturing is ready.

By buffercam

We are definitely on the same page...even on the details.

The PIC32 will handle the FAT file system. It can read from the SRAM using the parallel master port (PMP). It can even do it in the background using DMA. Then it can write to a SD card over SPI (also using DMA).
rgbphil wrote:I'm after a circuit I can stuff into a head mounted arrangement like a LED headlight
Funny you should say that. I'm planning on putting it in an LED flashlight as well.
The battery I picked out was a rechargeable CR123A (lithium ion). However, the choice of battery will probably depend on how much current the final device draws. The charger is a Maxim MAX1555 (for single cell lithium ion). The MAX1555 charges the battery off the USB port and the PIC32 can serve as the USB client. :)

The device I'm working on is called the "buffercam" since it continuously records video and preserves the 30 seconds before and after an "trigger" occurs. It's designed to be mounted on bicycles, motorcycles, and cars to record vehicle accidents. The video footage can be used to determine who was at fault for the accident. (The device is triggered by an accelerometer or by manually pressing a button.)

Now, if I could only get some valid data off the camera...

By rgbphil
Its been previously mentioned before (in this ever expanding thread!).....a FIFO RAM might be of more use than a SRAM. ... duct=10565
I've had no experience in using RAMs though.

I imagine getting the data out of the FIFO/SRAM to SD card would still be the bottleneck for this project.

A couple of questions to others....
Is there a more comprehensive list of commands to various registers than the sparse datasheet on Sparkfun?
Is a motionJPEG file simply a conglomerated bunch of jpeg frames put together? This would affect the processing needs of the micro if there were additional information needed.

  • 1
  • 10
  • 11
  • 12
  • 13
  • 14
  • 31