Linux OV511 Driver:
Technical Notes Vol. 4
Subject:  OV518+ Mode Control
2001/01/21, driver version 1.31 (experimental)

The OV518+ uses a drastically different method for setting up different resolutions and frame rates. Since the registers are not documented anywhere, these notes transcribe the register values used by the Windows driver.

Mode Registers:

(All values are in hexadecimal)
 
Reg (hex)
160x120
176x144
320x240
352x288
640x480
28 & 0f 85 85 80 80 80
29 0a 0b 14 16 14
2a 1e 24 3c 48 3c
2b 00 00 00 00 00
2c 08 00 10 00 10
2d 00 00 00 00 00
2e 0c 00 18 00 18
38 & 0f 85 85  80 80 80
39 0a 0b 14 16 14
3a 1e 24 3c 48 3c
3b 00 00 00 00 00
3c 08 00 10 00 10
3d 00 00 00 00 00
3e 0c 00 18 00 18
24 ff ff 9f 9f 9f
25 f0 f0 90 90 90
2f 80 80 80 80 80

Notes:

  1. Registers 28 - 2e and 38 - 3e always match. Perhaps there is a separate set for snapshot mode (like the OV511).
  2. 640x480 is really just 320x240. The driver probably just doubles the pixels in software. I don't know why they didn't scale it from 352x288; perhaps this causes aliasing.
  3. These settings are the same for both GBR422 and YUV420 modes.
  4. Registers 28 and 38 are sent with a mask of 0f.
Frame Rate Registers:

This is where things get tricky. There is too much data to list it all here, so only two of the six frame rates will be listed. 640x480 is omitted as well, since the above table proves that it is not a real mode. These values are for YUV420, but BGR422 values are not too different.
 
Reg 160x120
30 FPS		 160x120
15 FPS		 176x144
30 FPS		 176x144
15 FPS		 320x240
30 FPS		 320x240
15 FPS		 352x288
30 FPS		 352x288
15 FPS
51 04 08 04 08 04 08 04 08
22 18 18 18 18 18 18 18 18
23 ff ff ff ff ff ff ff ff
71 17 19 17 19 17 19 17 19
2f 80 80 80 80 80 80 80 80
30 80,02 80,01 80,02 80,01 80,03 80,02 80,03 80,02
c4 c8,00 c8,00 c8,00 c8,00 90,01 90,01 90,01 90,01
c6 10,01 40,01 10,01 40,01 7d,01 f4,01 7d,01 f4,01
c7 10,01 40,01 10,01 40,01 7d,01 f4,01 7d,01 f4,01
c8 51,00 60,00 51,00 60,00 80,00 8e,00 80,00 8e,00
ca 1a,00,02 0f,33,01 1a,00,02 0f,33,01 23,cc,02 1a,00,02 23,cc,02 1a,00,02
cb 14,02 40,01 14,02 40,01 ea,02 14,02 ea,02 14,02
cc 27,04 ec,04 27,04 ec,04 d6,06 d0,07 d6,06 d0,07
cd 20,00 13,00 20,00 13,00 2d,00 20,00 2d,00 20,00
ce 60,02 6d,01 60,02 6d,01 53,03 60,02 53,03 60,02
2f 80 80 80 80 80 80 80 80
sensor 54 23 03 23 03 23 03 23 03

Notes:

  1. 15 FPS is achieved by changing the clock divisor, according to the windows driver.
  2. The registers with multiple settings are programmed by sending them in a larger-than-normal control transfer buffer. I don't know the significance of using multiple values. Perhaps OVT realized they were running out of registers. I'm also not sure why reg 0xca has three values, and why the second value of the rest is always so small.
  3. At least for these values, YUV420 and GBR422 were the same.
  4. It looks like the first five registers only change with the frame rate. This should reduce the amount of possible combinations of settings by a lot.
  5. Register 0x2f appears in both tables a total of three times. It is probably has some reset-like function. According to the Windows driver, it is used in conjunction with the reset register to start the stream.
Summary:

Implementing these modes is going to be a nightmare. The amount of data that will have to be hard coded into the driver is enormous, unless an algorithmic method for setting these values can be found. With the mode registers, this should not be any more complicated than the OV511. Setting the frame rate, on the other hand, is going to be a total pain in the ass.

The OV518 is the proverbial WinModem of USB camera bridge chips. It looks like OVT expects the driver to do way more work than it should have to, so that the chips can be made for 5 cents less.


Copyright © 2001 Mark McClelland

Version History:
 
Date Version Change
2001/01/21 1.0 Initial Release