The default power up capture is very green, Setting register 18 (decimal) to 36 and doing a capture gives a typical YCrCb image, then resetting register 18 to the dafault value of 40 gives an image that has proper color balance.
Ok...I just did a few more tests, and the greenish tint is definitely the YCrCb factor that you are talking about. Though I think that explains what is going on, it doesn't explain why its happening. Here is some background info...
The AVRcam, at startup, sets up a few of the registers in the OV6620, one of which is register 0x12 (register 18 (decimal) to the AVRcamVIEW application). This register defaults normally to using the YCrCb color space (a value of 0x24 or 36 decimal), so one of the changes made by the AVRcam is to set it to use the RGB colorspace. See CamConfig.c, and the CamConfig_init() function to check out all the regs that are being set.
So, it appears as though somehow this register is not getting set at startup...which is very bizarre. I am assuming that you haven't updated any of the firmware on the system as well. The firmware actually attempts to write each I2C register on the OV6620 three times before it gives up. Currently, the ACK received after a Set Reigsters command indicates that the AVRcam successfully received the command, and doesn't reflect the success/failure of the action.
If possible, I would first suggest re-building the executable from the source included with the AVRcam System Software Suite. If you don't have an in-system programmer that is compatible with the STK200/300 programming header, then I'd be happy to send you a new mega8 with firmware on it that I will test out in one of my boards before I send it. The only variable left then is the board and the camera itself, which I'd have a hard time believing that it is problematic here since a follow-up write to the register (like you had been doing) makes the colors appear just fine.
Let me know if you don't have the setup to flash the mega8, and I'll send you a new one.
The AVRcam will quite often lock up during a capture, it seems to happen more often immediately after resetting register 18 back to 40
Hmm...this is also a bit strange. Is the image dump drawing any lines in the Bayer color window at all? Can you turn on logging and see if there is any comm with the AVRcam (when it appears to be frozen)? As stated on the website, I have seen two different potential scenarios for this. After taking a number of frame dumps back-to-back (say 15 or 20), I have seen the system stop responding to serial receive interrupts (at least I think this is what is going on, since I had the debug LED blinking to let me know the main loop was still getting hit), which effectively appears like the system is locked up since the user-interface stops working. This doesn't affect tracking objects, which works just fine. In my real-world applications, I never really intended to do a large number of frame-dumps of images while running in the embedded world. This was always a setup and calibrate thing for me. Regardless, I have tried hunting down why this happens, and plan to continue trying to figure it out because it bugs the hell out of me. There is no reason why the frame dumps shouldn't work, whether its 20 or 200. My only constraint right now is slipping in the time on the bench to dig into the issue and resolve it. I'll throw some effort at it this weekend again.
Note: The Set Registers General tab has only Auto White Balance enabled
Yes, this was arbitrarily chosen to be the default values for those radio buttons. They can be modified however you want.
Also what is Passive Tracking
Passive tracking is a feature where you can have the system hooked up to an embedded device where it is controlling it over the TTL interface, but still have the AVRcamVIEW PC application connected into the system listening over the RS232 serial cable to provide a real-time "view" of the tracking packets being sent to the embedded system. Essentially, the AVRcamVIEW will display the tracking window and the corresponding tracking objects, without having to initiate the "Enable Tracking" from the application. And thus passive tracking
![Smile :)](./images/smilies/icon_smile.gif)