SUB2r camera is built on a Cypress FX3 chipset that facilitates the Super-Speed USB 3.0+ communication between the device and a host system. Every component of the camera, be it an FPGA or an image sensor, receives user commands via that Cypress FX3.

On Windows the device is registered with a GUID {36FC9E60-C465-11CF-8056-444553540000} and if you are not planning on using the SUB2r-lib for your development - that would be the GUID to search for to properly connect to the command channel.

Whether you use SUB2r-lib or not you need to install the provided driver for the OS to properly configure the device in order to be able to connect to its control endpoints.

Here's a sample code that shows how to send commands to both the FX3 Host and to FPGA I²C bridge. The code lacks error checking (for clarity) and this should go without saying that if you copy-paste it into your code you must add error handling :)

// set a new auto-functions' update interval to 2x the default
// just issue the command directly to FX3's vendor request interface
void setAUInterval(){
    S2R::I2C fx3;
    fx3.open(0);
    fx3.vrCmd(S2R::FX3::af_au_period, S2R::FX3::write, 6000, 0);
}
 
// run DPC calibration - also just a straight-up vendor request command to FX3
void runDPC(UCHAR _threshold = 240){
    S2R::I2C fx3;
    fx3.open(0);
    fx3.vrCmd(S2R::FX3::calibrate_dpc, S2R::FX3::write, _threshold, 0);
}
 
// increase LED's green brightness by 25%
// utilize the FPGA's I²C bridge
void lightUpTheGreen()
{
    using Cmd = S2R::FX3::Fx3Cmd;
    using OpType = S2R::FX3::VrCmdOpType;
 
    S2R::FX3 fx3;   // `S2R::I2C fx3;` works as well
    fx3.open(0);
    uint8_t        buf[1]{0};
    const uint16_t clrChannel{0x0A};    // LED green
    fx3.vrCmd(Cmd::i2c_bridge, OpType::read, 0, clrChannel, buf, 1);
    buf[0] += buf[0] / 4;  // yes, this can totally overflow
    fx3.vrCmd(Cmd::i2c_bridge, OpType::write, buf[0], clrChannel);
}

The following tables provide information on how to access the camera's functionality for FX3 Host Vendor Command Interface. The address space is split into smaller chunks, grouped by common functionality:

See Color correction matrix article in this Wiki's ISP section for more details.

Name	Offset	wIndex	wValue	Access type	Byte length	Return buffer bits	Notes
Color correction matrix (needs actual implementation in FX3)	0xB2	0	0x0303	R/W	32	packed C-array float[3][3]	That data buffer could also be defined as float[9] or as byte* for the same exact memory layout on LE systems

The SPI flash memory (either 128MB or 256MB) is partitioned into 65KB sectors, each comprised of 256 pages. Each page is 256 bytes long.

List of commands supported by this API:

As of FX3 version 58 the following internal structures are supported:

The following tables provide information on how to access the camera's functionality for an FPGA I²C bridge.

Here's a sample code (skipping all error checking) that sets the LED to bright-yellow color:

S2R::FX3 dev; // auto-open device #0
using S2R::FX3;
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 255, 0x08); // red
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 255, 0x0A); // green
dev.vrCmd(FX3Cmd::i2c_bridge, VrCmdOpType::write, 0, 0x0C);   // blue

The address space is broken down into smaller chunks, grouped by common functionality:

A combination of data in 0x49[1:0] (pixel bit depth) and 0x48[6:3] (video format) is mapped into standard FOURCC codes as summarized in the following table:

“Green screen”, a.k.a. “Chroma Key” on-board optimization is designed to replace a range of colors with a single solid one

If enabled these setting take precedence over other 3 bands

Color substitution (if enabled) takes place after the first band had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by a paragraph and occupying address block 0x90-0x9F

Color substitution (if enabled) takes place after the first and second bands had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by 2 paragraphs and occupying address block 0xA0-0xAF

Color substitution (if enabled) takes place after other bands had a chance to process the pixels

The layout of the settings is identical to that of band #0 just shifted down by 3 paragraphs and occupying address block 0xB0-0xBF

See Color correction matrix article in this Wiki's ISP section for more details. The 16-bit (MSB-LSB) value is defined as 7+9 bits, where MSB[7:1] are the integer part and MSB[0]LSB[7:0] is the fractional part (effectively that value is 512 times larger than the original fractional part).

The version id is also encoded into the firmware image file name as:

<VendorID>_<HardwareID>_<ProductID>_<ReleaseType>_<BuildNumber>

The version id is also encoded into the firmware image file name as:

<VendorID>_<HardwareID>_<ProductID>_<ReleaseType>_<BuildNumber>