SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By noptical
#117217
ohmeega wrote:How do I use my webcam to remotely view my puppies from work? I have my webcam set up at home. When I get to work I would like to use it to view my puppies. At one time I had a free program I logged in to to do this but have lost it in a crash. Any ideas how I can do this?
wrong forum. wrong site

try google :)
By juan7dres
#120471
I'm starting to handle the camera TCM8230MD and I think this worked well, but I could see the data, someone can help me?
By heka
#122216
Hello,

I'm having a problem with the TCM8230MD, I've read everything there's to read, but still I'm not able to receive a whole frame, just 1/4 of a frame, this is my initialization based on the datasheet and some replies:

i2c_write(0x02, 0x80); /*FPS = 15*/
i2c_write(0x1E, 0x48); /*CODESW off*/
i2c_write(0x03, 0x22); /*DOUT, subQCIF(8), RGB, COLOR*/

I noticed that if I send
i2c_write(0x2E, 0x01);

I can almost see the whole frame but the colors then look really funny.

Can anyone help please ?

Thank.
By maxwell86
#124947
Hi together,

at the moment, i am trying to start the camera via an Arduino-Board. Here's the code i am sending:
Code: Select all
    Wire.beginTransmission(0x3C);  // address 0b1111000 = 60 = 0x3C
    Wire.send(0x03);                // sends one byte  
    Wire.send(0x00);                // sends one byte  
    Wire.endTransmission();      // stop transmitting
But the cam does not seem to change its state at all. Should i be able to watch a change in the current consumption? Usually, i should be able to see an alternating signal on the HD/VD-lines?! I guess there might be a problem in the I²C-communication. Do you know if the cam wants to have repeated starts?

Thank you for your help,
Max

:edit: just noticed that the endTransimission-function returns some error-codes, and now i've seen, that my error-code seems to be the "3" all the time, which means "received NACK on transmit of data".. so the addressing of the camera should work, but it is not able to send the data ?!

:edit2: using another i2c-Library, i noticed that the addressing functions are working, but not the write-functions!?

:edit3: woohooo!!! after hours and hours, i noticed, that the cam is using I²C-fast mode and the standard Wire.h library of the Arduino is using standard mode. So i had to change the library as follows:
Code: Select all
#define TWI_FREQ 400000L
Now it is working, awesom! The processing of the images will follow the next weeks, i will show images as soon as i got one!
By yakuzaa
#127975
Dmitri, what format do you use to capture video? Do you obtaning JPEG from camera and saving pictures to SD or you use software encoding?
By calgaryconehead
#128185
Hi,

I'm trying to buy/build an ultra-light camera board for a near-space balloon project. I have not seen a camera board, other than in this thread, that is as small & light as I believe possible.

Since it doesn't look like I can buy one, I am looking to build a TCM8240md based camera board. I've seen that aerospace combined this camera with an AL440B FIFO. I'm having trouble sourcing this part in small numbers ... I figure 5 is enough to get me to a working example.

I'd like pointers to parts suppliers that can source small numbers of this part. Digikey/Mouser/Jameco don't appear to have it.

Thanks
John
By Dmitri
#128344
yakuzaa wrote:Dmitri, what format do you use to capture video? Do you obtaning JPEG from camera and saving pictures to SD or you use software encoding?
TCM8230md has no JPEG encoding. Raw video data is stored directly to the SD card as YUV411.
By rodjownsu
#128941
Hey guys I have read through this entire thread as I looking to get one of these cameras.... I thought I would just give you the a heads up on a different type of camera OV9650 they are available on eb**.com for like 18 bucks and have a great datash**t and come with a breakout board as well!! they are made for the strongarm s3c2440 developement kit.. I think I will end up persuing coding using this camera... any way congrats to all the guys who got the sparkfun cameras working!! what a mission.... :)
By doddy1985
#130671
@maxwell86

did you get your code working for Arduino? I am trying to configure my device but am also getting the response code '3' from endTransmission().. I changed my library to account for Fast I2C bus at 400k. Interestingly enough, I get response code '0' for success when I send the instructions to camera for setting active and reset. Here is a sample of my code:

int end_RTN; //debug for Wire.endTransmission()
Wire.begin();//All slave devices to listen
delay (100);

Wire.beginTransmission(cam_address);//Select slave device
Wire.send(0x02); //0x02 register_address
Wire.send(0x00); //0x02 <- 0x00 Set Camera Active
end_RTN = Wire.endTransmission();
delay(100);
Serial.println(end_RTN, DEC);//debug

Wire.beginTransmission(cam_address);//Select slave device
Wire.send(0x02); //0x02 register_address
Wire.send(0x40); //0x02 <- 0x40 Set Camera Reset
end_RTN = Wire.endTransmission();
delay(100);
Serial.println(end_RTN, DEC);//debug

Wire.beginTransmission(cam_address);//Select slave device
Wire.send(0x02); //0x02 register_address
Wire.send(0x00); //0x02 <- 0x00 Set Camera Active
end_RTN = Wire.endTransmission();
delay(100);
Serial.println(end_RTN, DEC);//debug

Note that the above gives success response on serial line ('0' is output). The next sample just gives '3' though for NACK..

Wire.beginTransmission(cam_address);//Select slave device
Wire.send(0x0B); //0x0B register_address
Wire.send(0x00); //0x0B <- 0x00 White Line OFF
end_RTN = Wire.endTransmission();
delay(100);
Serial.println(end_RTN, DEC);//debug


Any suggestions??

edit1: I should note that cam_address has already been defined as '61' as per the specs of camera.
edit2: Uh oh.. i think you are using 230 and I am using 240.. that prob the issue.. maybe I'll switch to 230 also. heh
By doddy1985
#133435
Well it has been some time since my first post. Issue was with my clock signal's duty cycle. That is fixed up so my I2C is configuring the camera without any problems.. Moving onto actually getting data to PC via arduino. Hopefully will post something soon with some successes.
By FET_Destoyer
#136328
Hi, this post seems quite dead nowdays.
There is good info in this post about this camera, but who put the camera work just use only the datasheet on the sparkfun website? That is not much information, is there any user guide or implementation guide?
"Twingy" and "Kreature" is there any library with some configuration codes?
That could help me to inicialize this camera?

Best Regards
By WickedMinds
#136406
rgbphil wrote:Hi,
I'm tossing some ideas around for a circuit, eventually I'll post it or if anyone knows of a site where a collaborative effort can be done it'll be added there for comment and improvement.

Just need some sanity checking. Can anyone check their interpretation of the datasheet on my assumptions please?

1) The device clock is via the EXTCLK pin, and the internal clock rate can be set with the PLL to various settings via I2C commands

2) When the device outputs a JPEG file (or other image formats) data is presented to the D0..D7 pins and is valid on the rising edge of the DCLK pin which is an output of the device. A data frame or jpeg frame is indicated by a high on the VBLK pin. The HBLK pin indicates the device pausing while it is doing JPEG compression.

3) The DCLK pin is actively clocking along, even when the device isn't doing anything, data is only valid when the VBLK pin is high.

4) We can just take the JPEG output of the imager chip as a valid JPEG file without further processing (assuming we can get the data to a memory card).

So from these assumptions we could build a circuit that takes the VBLK pin and enables a SRAM chip. The DCLK pin can then be used to perform a write enable operation and also clock a binary counter chip (or chips depending on the address space needed). This would automatically clock the data into the ram chip for later retrieval by the micro.

To complete the circuit we need a way to disengage output operations from the imaging chip so the micro can look at the ram. The micro could control the reset of the binary counter chip to reset to the start of the frame, then take over (possibly by a little extra logic) the clocking of the counter, reading it and writing to the SD card as needed.

I can't see a pin to disable output from the imager....so I presume there is an I2C command to do it...does anyone have an idea where the command set for the chip is? I can see a list of registers, but no list of what the register values should be for different operations.

Also any suggestions on a suitable oscillator frequency to clock the imaging chip with?

If the assumptions are wrong, please indicate this and any suggestions you might have.

Phil
I have this cam writing frames directly into an SRAM chip I pulled off an old hard drive. Which I then read with an ATMega.

I currently have the cameras EXT CLK line connected to a 12MHz crystal clock. Higher clock rates are possible it will depend on the write time for the SRAM. I just happened to have some 5V 12MHz modules laying around. At 12MHz I am capturing 14.65 fps.

The SRAM address lines are connected to 74HC161 binary counters which are clocked by the cameras DCLK line.

The counters active low reset lines are connected to the cameras VD so that each new frame resets the SRAM back to address 0.

The counters Count Enable is connected to the cameras HD so that the counters only advance during a valid line. The counters will pause during horizontal/vertical blanking.

DCLK is also fed to the SRAM Write Enable line which is active low.

The 8 bit camera data bus is connected to the SRAM data bus via a 74HCT574 latch. Using an HCT here acts as an a bit logic level converter. The latch is active on a rising edge clock so the cameras DCLK is used to drive the latch clock.

The counters control lines are fed into the A bus of a 74HC157 1 of 2 4-bit data switch. The B bus is connected to the ATMega. The bus selection line is connected to the ATMega which allows it to control if the clocks and SRAM are driven automatically or by the ATMega.

When the SRAM is being driven automatically the following happens:

- VD resets all counters to 0 which in turn sets the SRAM to address 0.
- HD rises when the first byte of pixel data is available on the cameras data bus enabling DCLK to advance the counters.
- DCLK rises and the first pixel is latched via the 74HC574 onto the SRAM data bus.
- DCLK falls and the SRAM Write Enable is active which writes the byte latched by the 74HC574 into the first SRAM memory location.

Bytes are successively written into SRAM until HD falls at the end of the line at which time the counters pause until HD rises signaling the start of the next line.

After a complete frame is written into SRAM, VD will fall causing the timers to reset and the whole process repeats itself at a nice high frame rate.

An 8 bit I/O port on the ATMega is connected to an 74HC245 8-bit bus tranciever. The enable is connected to the 74HC157 select line and to the 74HC574 enable via a 74HC04 inverter so that only the camera or the ATMega is connected to the SRAM data bus at one time.

Changing the select line of the 74HC157 from "SAMPLE" to "HOLD" gives control of the counters reset and clock lines over to the ATMega. My dump frame function then just resets the counters, reads a byte from SRAM, sends it out the serial port, clocks the counters to the next address and repeats for the length of the frame.

This allows me to capture frames at a high frame rate and then use a low speed mcu to read/analyze the frame at it's own pace without worrying about trying to keep up with DCLK in some tightly woven assembly function.

I have been able to dump frames to my pc from all modes from 320x240 down. As long as you have enough counters and SRAM to cover the resolution you want to run in it works pretty good so far. I happen to be using a CYM1464, 512k x 8bit SRAM with 25ns r/w but you could scale down to a 32k x 8bit SRAM if you stay in the low resolutions.

I'm also thinking of dividing the VD in half so that two sequential frames are written to the SRAM making it easy to compare frames. There is also the possibility of connecting the counter presets to the ATMegas external SRAM interface so that it can randomly access frame data instead of sequentially, however all the stuff I want to do with the data involves reading the data sequentially so I'm not sure how much advantage this would hold.

Using surface mount versions of the mentioned chips would make this a fairly small package.

A lot of fun for a $10 camera and a hand full of dime-a-dozen parts from all those past grab bags :)

All registers at default values except AWB disabled under a 40w incandescent light

Image
  • 1
  • 25
  • 26
  • 27
  • 28
  • 29
  • 31