Greenish image with power up default settings

[techcare]

My Image from the camera looks greenish, turning on auto white balance doen't seem to help much.

If I load register 12h with a 24h, to switch to YCrCb mode,do a capture, then load register 12h with a 28h to switch back to RGB and do another capture the image colors look much beter.

The greenish image comes back again when I turn the camera off and back on.

I noticed my new AVRcam came with software revision 1.2. Is there a list of what was changed from the previous version?

[Guest]

My Image from the camera looks greenish, turning on auto white balance doen't seem to help much

Hmm...thats curious...I've noticed the overall images come up with a red-tint before, but this is primarily in the case where I have tons of incandescent lighting. I have a couple of AVRcams on my bench, all running 1.2, and I have never seen that. Anyone else out there experiencing this?

Also, 1.2 includes a few new things. Primarily, it supports a much simpler in-circuit programming mechanism (the original procedure required the user to actually remove the OV6620 camera module from the board before programming...this was due to the i/o line conflict where the camera was trying to drive the same lines neeed for re-programming. The solution here is to have the tiny12 tri-state the camera's pixel busses, then allow the mega8 to power up and blink 4 times, followed by un-tri-stating the camera's pixel busses).

Another minor change in 1.2 is that I added some new filtering code into the FrameMgr_processLine() function that goes through periodically and removes objects that are smaller than some pre-set threshold. This is primarily used to reduce noise in the image, which can end up occupying some of the "tracked" objects when it shouldn't. This code could be removed if you were really interested in tracking objects down to just a pixel or two in height/width.

Back to the greenish tint...I'm assuming that this is repeatable, right? Every time at startup it occurs? Changing that register ALWAYS fixes the issue? At least as much as you've tested...post back and let me know.

[techcare]

John,

I have confirmed the symptoms on two computers.

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.

The AVRcam will quite often lock up during a capture, it seems to happen more often immediately after resetting register 18 back to 40

Note: The Set Registers General tab has only Auto White Balance enabled

Any Ideas?

Also what is Passive Tracking?[/img]

[techcare]

It would be helpful to have a read register command to check values in the camera registers, How hard would this be to do?

From looking at the schematic it looks like you are doing nibble reads for the Y and UV buses, but I didn't see a register setting in CamConfig.c to put the camera module into 4 bit nibble mode output (register 3Eh value 90h, I assume) Does this get done somewhere else or am I missing somthing?

[/list]

[sam0737]

From looking at the schematic it looks like you are doing nibble reads for the Y and UV buses, but I didn't see a register setting in CamConfig.c to put the camera module into 4 bit nibble mode output (register 3Eh value 90h, I assume) Does this get done somewhere else or am I missing somthing?

I think the AVRCam just care 4bit color-depth for each channel. Am I right?

[Guest]

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

[Guest]

I think the AVRCam just care 4bit color-depth for each channel. Am I right?

The OV6620 isn't being put into 4-bit nibble mode. This situation is handled by only sampling the high-nibble on each pixel data bus supplied by the camera. The 4-bit nibble mode referenced by register 0x3E allows the system to operate at an increased frame rate, which is the last thing the AVRcam needs So, it lives happily with the normal pixel data busses, except they are running at their normal speed.

[techcare]

John,

Hope you had a nice holiday.

I want to be able to make code changes for my application anyway , so I would like to try to re-flash the Mega 8 and see if it makes any difference like you suggested.


I have an Altera ByteBlasterMV cable, is it compatible with the WINAVR Suite?


Could you post some instructions on how to go about re- programming process for us that are unfamiliar with WINAVR?

[Guest]

Sorry for the late response...getting back after the holiday is always a little tough

I have an Altera ByteBlasterMV cable, is it compatible with the WINAVR Suite?

As far as I know, the ByteBlasterMV cable won't work to program any AVR through the normal STK200/STK300 interface. I believe the ByteBlaster cable bit-bangs a JTAG interface through the parallel port of the PC. Thus, the signals it provides are the normal JTAG signals (like TCK, TMS, TDI, etc). The AVR programming interface on the AVRcam supports their standard 2x5 pin programming header that uses the STK200/STK300 SPI interface (MISO, MOSI, etc).

The AVRcam programming interface is quite simple, and you can find numerous schematics on the web to build a simple one yourself. Here is a very straight forward description (with schematic) for the programmer:

http://www.xs4all.nl/~sbp/projects/stk200/stk200.htm

Also, if you don't want to go through the hassle of making one, I sell a pre-assembled programmer that has all the electronics fit into the DB25 housing of the parallel port connector. Check out:

http://www.jrobot.net/Shop

As far as the reprogramming process goes, there is a document included in the current version of the AVRcam System Software Suite that goes into detail about setting up WinAVR, as well as downloading new apps. Here is the link to the original doc (thanks Colin and Eric for an excellent step-by-step document!):

http://winavr.sourceforge.net/download/ ... WinAVR.pdf

The only thing to remember here is that the AVRcam MUST be reprogrammed while the yellow LED is blinking at startup. This provides about a four second window where the re-programming needs to be initiated. During this time, the system guarantees that the requisite programming lines are tri-stated, thus allowing programming to take place. After the yellow LED stops blinking, those lines are used for other things. You won't actually damage anything by trying to program the chip after the blinking stops (I have done this numerous times), but the programming may fail.

Good luck, and let me know if you have other questions.

[techcare]

John

I still get the same green image problem with the new chip. I was able to upgrade to AVRcam 1.4 with the programmer cable , I still have the green image problem but the capture lockups are gone, I Had some problems with the makefile and the avrdude on my Windows 2000 system , the -i option wasn't recognized as a valid avrdude option so I had to replace it with a -u flash:w: and -u eeprom:w: to get it to write the program. If anyone has similar problems I can post my modified makefile. I am going to attempt a modification of the code to automatically write the config register value sequence to correct the green image problem, I will let you know how it works out. Let me know if you have any more ideas.

[techcare]

I was able to modify the Main and CamConfig files to improve my power up image on the camera, I added two additional functions that set register 12 to the CamConfig file as shown below

/***********************************************************
Function Name: CamConfig_init2
Function Description: This function is responsible for
performing the initial configuration of the camera.
Inputs: none
Outputs: none
***********************************************************/
void CamConfig_init2(void)
{
CamConfig_setCamReg(0x12,0x24); /* set YUV mode, with AWB */

/* send the first four cmds in the I2C fifo */
CamConfig_sendFifoCmds();
}

/***********************************************************
Function Name: CamConfig_init3
Function Description: This function is responsible for
performing the initial configuration of the camera.
Inputs: none
Outputs: none
***********************************************************/
void CamConfig_init3(void)
{
CamConfig_setCamReg(0x12,0x28); /* set RGB mode, with no AWB */

/* send the first four cmds in the I2C fifo */
CamConfig_sendFifoCmds();
}

and modified the Main.C initialization routine as follows

/* initialize the remaining modules that will process
data...interrupts need to be on for these */
ENABLE_INTS();
CamConfig_init();
UIMgr_init();
FrameMgr_init();
CamConfig_init2();

/* provide a short delay for the camera to stabilize before
we let the executive start up */
Utility_delay(1000);
CamConfig_init3();

/* the rest of the application will be under the
control of the Executive. */
Exec_run();

I now get the proper color balance when dumping images from the camera.

PS the Version 1.4 fixes work great!

[Guest]

Wow...this is really interesting. So, before I sent you the replacement mega8, I tested it out on a board that I had built with stock 1.2 code. The images, at power-up, didn't have the green tint (i.e., register 0x12 should have been set properly in the OV6620 for RGB). So I was thinking that this should work fine for you...

But you reported back that it was still a problem. Further, modifying the code to first set register 0x12 to enable YUV, followed by setting it to enable RGB, allows the system to provide the correct coloring for the images (i.e., RGB instead of YUV). But without that initial "setting" of YUV mode, the initial change to RGB mode (that is part of CamConfig_init() function in CamConfig.c) doesn't seem to have any effect. That is whacked-out...

I'll ask again: has anyone else seen this behavior? I haven't ever seen it on the ~8 boards I have built and tested. Earlier today I was thinking that maybe it is tied to the OV6620, but since you can set the regs just fine as long as you first "enable" YUV as the color mode seems to rule out this....I'm dumbfounded...

I'd be open to anyone out there with an idea as to what is going on here...

Glad to hear the v1.4 code is working better for you. Those stupid lock-ups were nagging at me for a while (I originally was thinking that it may have to do with the 115.2 kbps baud rate being "borderline" when running the AVRcam at 17.7 MHz...potentially causing the lockups. Its actually only 1.2% off from the ideal 115.2 kbps, which is within normal RS232 spec. I finally sat down with an oscilloscope this past weekend, and could monitor enough of the system activity with the two debug lines to determine what was going on...)

Keep toying with the code, and post back any other additions you make.

[techcare]

It seems to me that the OV6620 camera module I have doesn't white balance properly when in the RGB mode. When I set it to the YUV mode it does a better white balance. When I modified the code I discovered that there has to be a time delay between setting the two modes or the white balance doesn't get corrected. setting them immediately after one another leaves me with the same green image.

I would like to try my AVRcam with a different camera module to verify this.

How much for a C3088 only?