I agree with Random. The TCM8240MD camera is not easy to work with. Definitely not something you want to get involved with.
You could turn the store-bought camera off between shots using the lilypad. I don’t think there would be any problem using a MOSFET as a digital on/off switch controlled by the lilypad, just like you would do with the remote shutter.
You’d want a camera that turns on/off quickly.
-David
Don’t get a camera with autofocus, display or mechanically extended lense. They will use more power on on/off than you use in 16 seconds of on-time.
Other than that, I agree. The TCM8240MD requires way too much processing/data handling power to be practical. I only read SPI before ordering mine and regret it not allowing SPI readout. It should have a internal framebuffer and allow readout at your leisure via SPI. Alas…
bri,
I’m not sure if you’ve heard of this related project, “Purple Pedals,” but it might interest you.
Here’s the link:
I just captured my first few images with the camera.
Using ma4826’s settings for the most part.
The image looks a little funky. I’ll plan on fixing it by iterating through the values of SPCOUNT and Register 0x0E as ma4826 did.
Do you know what could be causing the noise at the top? These pixels come from the data near the end of the transmission from the camera)?
Kreature- You said the bitmap format can handle rgb565? I couldn’t get the picture to be valid and look right. Here was the header I used:
16bit Bitmap Header for CIF (352x288) Image?
42 4D 42 18 03 00 00 00
00 FF 42 00 00 00 28 00
00 00 60 01 00 00 20 01
00 00 01 00 10 00 03 00
00 00 00 18 03 00 15 17
00 00 15 17 00 00 00 00
00 00 00 00 00 00
The image I captured (converted to rgb888 and saved as png):
What framerate are you using?Do you know what could be causing the noise at the top? These pixels come from the data near the end of the transmission from the camera)?
Is the pll on?
I change the red values by the blue values. It is the colour correct?
http://webs.ono.com/ma4826/CIF_Image_RGB_to_BGR.png
If you put the registers values, I test it.
Color looks a lot better. I had the red and blue channels reversed? It might have been in my conversion to rgb888.
PLL was off, but I did increase the frame rate by changing frame speed to max and increasing the EXTCLK to 10Mhz.
The frame rate was still quite slow. I think it was less than 3 fps.
I’m working on increasing the frame rate by decreasing HBLK. (Which requires figuring out the settings for SPCOUNT and 0x0E.) I probably changed some of the settings before taking this picture.
But even using your exact settings, I had the “wrap around” affect. Maybe the settings are camera specific to some extent?
I hope to get some Full Mega JPEG images tomorrow.
-David
EDIT: I also had AWB enabled for the image.
I2CWrite(0x6D,0xA1); // AWB On, AWBLock off, AWBMode:Average
(AWB mode settings are listed in the 8230 datasheet.)
Try this.
ADDR DATA
0X0D 0x01
Best regards,
Miguel.
Here’s my BMP header struct:
struct BMP_HEADER_s {
union {
struct {
unsigned char B; // To contain "BM"
unsigned char M;
unsigned long SIZE; // Size of BMP file in bytes
unsigned int r1; //
unsigned int r2; //
unsigned long DOFFSET; // Offset to start of image data
unsigned long DIB_SIZE; // Size of this header (40)
signed long WIDTH; //
signed long HEIGHT; //
unsigned int COLORPLANES;//
unsigned int BPP; // Bits pr pixel (16 or 32 for bitfield)
unsigned long COMPRESSION;// Compression method. Bitfield=3
unsigned long DATASIZE; // Size of raw image data
signed long HREZ; // Horizontal rez in pixels pr meter
signed long VREZ; // Vertical rez in pixels pr meter
unsigned long PCOLORS; // Number of colors in color palette
unsigned long IMPCOLORS; // Number of important colors used
unsigned long RMASK; // Red bitfield mask
unsigned long GMASK; // Green bitfield mask
unsigned long BMASK; // Blue bitfield mask
};
unsigned char DATA[66]; // Access to all data as a char array for sending...
};
};
Here’s my values being set:
bmp.B = 'B';
bmp.M = 'M';
bmp.SIZE = (unsigned long)BMP_HEADERSIZE + (unsigned long)2*Xrez*Yrez; // BMP_HEADERSIZE = 66 !!!
bmp.DOFFSET = BMP_HEADERSIZE;
bmp.DIB_SIZE = 40; // Use MS header
bmp.WIDTH = Xrez;
bmp.HEIGHT = Yrez;
bmp.COLORPLANES = 1;
bmp.BPP = 16;
bmp.COMPRESSION = BMP_BI_BITFIELD; // BMP_BI_BITFIELD = 3 !!!
bmp.DATASIZE = (unsigned long)2*Xrez*Yrez;
bmp.HREZ = 5909; // Approx 150 dpi
bmp.VREZ = 5909; // Approx 150 dpi
bmp.PCOLORS = 0;
bmp.IMPCOLORS = 0;
bmp.BMASK = 0x1F;
bmp.GMASK = 0x7E0;
bmp.RMASK = 0xF800;
This creates valid BMP’s for me.
This was written for ATmega64 and such so remember you endians!
Thanks! I think I had all of that except the color masks.
Is this the correct endianess for the color mask?
Color Masks (corrected)
1F 00 00 00 E0 07 00 00 00 F8 00 00
Thanks for the tips… I’ll keep plugging away at a solution with a pre-fab camera. And, really cool project with the bikes! I want one!
Thanks,
Bri
Good question.
I think it’s little endian. (as in least significant byte first.)
I store it in mem so that bmp.DATA[0] points to ‘B’ and bmp.DATA[1] is ‘M’.
That would make my stuct little endian and since the struct matches the MCU I think it’s little endian too.
(I hate endianness!)
ma4826,
I just want to confirm something:
With the original settings that you posted, you are getting a frame rate of about 0.5 fps, correct?
That is, the camera takes about 2 seconds to transmit each image?
Thanks,
David
buffercam:
ma4826,I just want to confirm something:
With the original settings that you posted, you are getting a frame rate of about 0.5 fps, correct?
That is, the camera takes about 2 seconds to transmit each image?
Thanks,
David
Yes.
Best regards,
Miguel.
I’m gonna use this camera with a micro-sd-card, and a battery, taking pictures at less then 1 pic per sec. What controllers can handle the imagedata this censor creates, and which one is the smallest possible one?
So far, I don’t think anyone has found a single controller that can do it alone. You will in most cases need extra memory to handle the image data in addition to the storage card to save them permanently.
That means:
1x 48 to 144 pin device as a MCU.
1x 48-200 pin memory chip
1x micro sd socket
1x camera module
and a way to connect it all.
If anyone has found a way to make this smaller, please tell…
At such a slow transfer rate, I think it might be possible to do without a memory chip. The data just needs to be transferred to SD while it is being received from the camera.
I’m trying to go faster, so I’m using the AL440B-12 512K FIFO.
The transfer rates do not add up though.
Camera is supposed to deliver full, half and quarter framerate of 15 fps.
The slowest pll input is supposedly 6 MHz and that should deliver around 8-9 MHz pll rate. According to appnote, a minimum of 17 MHz output clock is required for full output at any framerate but I suspect that means full output at full framerate.
Without the PLL, minimum input is 6 MHz and according to appnote we might reduce the derived output clock by setting R05 [7:6] to 0 for quarter rate output. I have not verified this.
Further, setting the image size small will halve or even quarter the rate.
I think, using a avr32 or similar, it might be possible to receive and save to micro-SD on the fly. This is what I want to try.
It would mean handling the full 17 MHz output rate though, but that might be possible using the image sensor hardware interface. If camera also runns in jpeg mode the data size would be reduced.
Untill I have the image sensor interface working right I won’t know if it is doable though. The sd interface is very fast so this should be no problem. (10 to 25 Mbyte/s with dma handling.)
I don’t remember the number, but the output clock for the settings specified by ma4826 were in the kHz range. If I remember correctly, I think it was around 500kHz. Definitely under 1 MHz.
I agree that JPEG can’t be captured w/o external memory.
You can get 10 Mbyte/s with SD? I don’t think that’s possible with SPI. What interface are you using?
EDIT: Some ARM processors have a MDI interface that can write fast to SD, apparently. Like the NXP LPC2368. I don’t have any experience with that, though.
I have written libraries to handle SD cards correctly. That is, with full querying as well as identification and support for SDHC cards.
Normal cards allow 25 MHz connection speed, 1 ot 4 bit.
For 1-bit mode, theoretical max transfer is 25/8 = 3.125 Mbyte/s.
For 4-bit mode, theoretical max transfer is 25/2 = 12.5 Mbyte/s
The SDHC cards allow 50 MHz connection speed allowing twice the rates.
That’s 6.25 and 25 Mbyte/s.
Since the avr32 series has support for 4-bit mode as well as the ability of being programmed with custom clock frequencys I can get 48 MHz on the SD interface and still have a USB compatible clockrate on the rest of the system. (And 144 MHz on the main cpu.)
Wow. Nice.