The Vision DMX Protocol is completely based on DMX 512. The only difference similiar to the Vision RDM Protocol is the transport layer and the first data byte in the data stream . The Vision DMX is received via the SPI Communication.

DMX512 (E1.11 - 2008, USITT DMX512-A) is a standard for digital communication networks that are commonly used to control lighting and effects.

DMX512 Protocol

DMX512 is a digital communication standard that sends control data over a single cable to multiple devices, like dimmers, spotlights, and moving heads, typically used in theatrical, concert, and event lighting. The data is sent in packets with up to 512 separate channels, each controlling a specific aspect of the lighting fixtures.

DMX Personalities

„DMX Personalities“ refer to the different configurations that a DMX-controllable device can have. Each personality represents a different mode of operation, affecting how many channels a device uses and what each channel controls. For example, a lighting fixture might have one personality that uses three channels for red, green, and blue lighting control, and another personality that uses four channels like Master Dimmer, red, green,blue.

DMX Start Address

The start address is the first channel number that a device listens to on the DMX network. It defines where in the sequence of 512 channels a device’s control begins. For instance, if a device is set to a start address of 101, and it operates in a personality using 5 channels, it will use channels 101 to 105. Setting the correct start address is crucial for the proper operation of the lighting system, as it ensures that the correct data is sent to the intended devices.

DMX Footprint

The „footprint“ refers to the number of consecutive DMX channels a device uses based on its current personality. A device with a larger footprint will use more channels, which allows for more granular control over various functions of the device. The footprint size can vary depending on the device’s complexity and the personality selected. For instance, a simple dimmer might have a footprint of 1, while a sophisticated moving head could have a footprint of 20 or more channels.

This means that Vision DMX follows the same principles as standard DMX512 in terms of DMX Personalities, Start Address, and Footprint. However, the key difference lies in the method of data transmission; instead of the typical DMX512 protocol, Vision DMX uses SPI (Serial Peripheral Interface) for receiving data packets. This is a common hardware interface used for short-distance communication, particularly in embedded systems.

The Vision DMX data stream is defined as the following:

Vision Control Behavior = 0 -> DMX Control.

When Vision Control Behavior is set to 0, the fixture shall behave like it is controlled by a normal DMX stream.
The fixture shall use the currently selected DMX settings, including for example:

• DMX mode
• DMX start address
• fixture configuration
• color mixing settings
• other user-selected fixture settings

In this mode, the behavior shall be identical to normal DMX operation.

Vision Control Behavior == 255 -> App Control.

The fixture shall use defined App Control behavior according to the Vision DMX Personality Requirement.
In this mode, the fixture shall ignore user-selected DMX settings for the current Vision DMX data stream and instead use fixed, app-optimized default values.
This includes, for example:

• All fixtures of the same type shall behave consistently during app control
• DMX start address shall be 1
• DMX mode shall match the required Vision DMX personality
• color mixing behavior shall be fixed and predictable
• the fixture shall not switch between RGB, RGBW, RGBL, or similar modes based on fixture settings

This is important because fixtures must not behave differently when controlled through the Vision app.
The fixture shall not modify any internal user settings, display settings, saved DMX settings, or settings used by other protocols.
The App Control defaults are only applied internally for the Vision DMX data stream.
RDM shall still report the user-selected fixture settings, not the temporary App Control defaults.

This function is used that the app can control the fixture in a defined state without manipulating the settings of the fixture.

Example using the Vision SPI Library

• Data[0]: Vision Control Behavior
• Data[1-512]: DMX (DMX Data[0..511])

In the example this is already separated:

Example Fixture Implementation:

Personalities of your fixture:

• 1: Simple (Length 5)
• 2: Advanced (Length 10)
• 3: Single Pixel Control (Length 50)
• App Control Personality: (Not exposed in RDM) -> Single Pixel Control (Length 50)

App Control Settings:

Default App Control Settings: Dimmer Curve Linear, Dimmer Speed fast (snap)

Current Example

Selected DMX Address: 10

Selected DMX Personality: 2

Selected Dimmer Curve: Quadratic , Selected Dimmer Speed slow

Behavior:

1. Vision Control Behavior = 0
   1. DMX Data[9] DMX Personality[2]
   1. Dimmer Curve Quadratic, Dimmer Speed slow
2. Vision Control Behavior = 255 -> App Control with fixed App Control defaults
   1. DMX Data[0] DMX Personality[3]
   1. Dimmer Curve Linear, Dimmer Speed fast (snap)

Vision App Control Requirement

There is a control footprint requirement for controlling the fixture with the Vision Control App. The app uses the reserved Vision Control Behavior 255, called App Control.

React to the Vision Control Behavior from the Vision DMX stream as described in the interface section. Value 255 is reserved for App Control. In this mode, use fixed App Control defaults so all fixtures of the same type behave consistently regardless of any user setting.

Master Dimmer / Shutter is not required. All pixel will controlled individually prefered with 16 bit control.

Default Behavior:

LED Control (Color)

RGBxx 16 bit linear control over all pixels is recommended. On single pixel controlled fixtures every pixel should be controllable. RGBxx control should not be faded / delayed, because we use these channels also for our synchronized strobes. For smoothing the dimming, please use our example code.

LED Control (White)

White 16 bit linear control over all pixels is recommended. On single pixel controlled fixtures every pixel should be controllable. Control should not be faded / delayed. For smoothing the dimming use our code template.

Pan & Tilt

Pan & Tilt Rotation Speed

Value 0 or 128:
Rotation is disabled. The fixture's Pan and Tilt position is defined exclusively by the standard Pan and Tilt control channels.

Values 1-127 and 129-255:
Rotation is enabled. The fixture performs a continuous rotation at a speed according to the applied value.

Transition behavior (Rotation -> Position):
When the value changes from a rotation range (1-127 or 129-255) to 0 or 128, the fixture shall smoothly transition back to the standard Pan and Tilt position defined by the Pan and Tilt control channels. The movement should continue in the current direction of rotation (if possible) and should not stop abruptly before moving to the standard Pan and Tilt position.

Focus

Zoom

Fog

Fan

More components required? Please contact us. We will add the necessary components.

1. After enabling the Test Mode and connecting to the fixture it should look like this. To test DMX click on „DMX“:

2. Choose the "Vision Control Behavior" and set "DMX Values" via the sliders. Test DMX Control with different "DMX start addresses" and "DMX Personalities" (sometimes also called "DMX Modes") to make sure everything works as expected. The "Change Personality" function changes the temporary DMX Personality used for the current Vision DMX stream.

Test the DMX Personality 0, 1-x and 255 as described in the Table and the DMX Chapter.

After enabling the Test Mode and connecting to the fixture it should look like this. To create an App Control Configuration, click on "App Control Configuration":

Legacy naming: App Control Configuration was previously called Creative Configuration or Creative Config. Older screenshots, app versions, file names, or URLs may still use the old name.

If everything works so far, the fixture can be prepared for App Control. Here you can create, load, or write an App Control Configuration. Each fixture type needs an App Control Configuration to be controlled through App Control. The App Control Configuration consists for example of the number of pixels, their position, and related fixture control data.

Start by creating an App Control Configuration. Press Create App Control Configuration.

Click on the buttons to set the desired values. Select and configure each required component (like Pan, Tilt Color, White, Zooms, Focus, Smoke etc). Tapping on the whole frame selects the component. Select only components your fixture actually supports. By clicking on edit pencil on the right the configuration can be edited. A green checkmark indicates that the configuration for this component have been done.

Use the orange info „i“ buttons to get more information to the regarding topic.

After finishing the configuration you should save it as a .json file and write it to the fixture via the buttons on the top.

Color Component

The Color Component can be quite challenging to configure. So there are some more detailed information explained here. After pressing the edit button of the Color Component a new window appear which looks like this:

Here you have to define the pixel count of the fixture. Just the pixel which are controllable through DMX. Then put in the DMX information on how to control the LED’s. After configuring have to test and Position your pixels using the tabs in the top. Click on Calculate to get to the Color Settings.

Now we come to the difficult part. The Color Settings:

Select the Color Count of the fixture. RGB for example has 3 colors. For the next steps we need the Color Information:

Therefore we need the spectral output of each Color at full in brightness relative to each other. For this kind of measurement you could use any spectrometer which has a resolution of 1nm over the Range from 380nm to 780nm. For Example the UPRTEK MK350N Premium.

Therefore place the fixture in a appropriate distance to the spectrometer. Make sure the mixing of the colors from the fixture on the detector is as good as possible. Also measure the colors with an appropriate cooler temperature when there is no temperature compensation on the fixture side. Measure each Color independent as you can see in the following picture. In this example it is done via a RGBW LED Source. We support up to 6 Color LED Sources.

The following example is with the UPRTEK MK350N Premium:

After measure you should get the spectral response of the color relative to the others. Like this:

The results of the UPRTEK MK350N Premium will be saved in an Excel file. Refer to the provided document for an example format:

Example Red Spectrum

The necessary illuminance value is LUX (lx), in our example, it is approximately 1515.47 lx.

In the next step, extract the required spectral data from 380 nm to 780 nm (mW/m^2). Refer to the image for an example:

Copy the values displayed within the blue square:

Insert the values into a new .txt file while ensuring the required format is met. For better understanding, refer to the example file.

Format requirements:

• The decimal seperator must be a „.“ (dot). Values must be separated by a „,“ (comma). All values should be arranged in a single line without line breaks.

This can be achieved for example in Notepad++ using Find and Replace function:

• Replace „,“ with „.“
• Replace „\r\n“ with „,“ (Ensure Search Mode is set to Regular expressions).

In the picture below it is a configuration for 3 Colors, for example RGB. From the available options, select „Custom“, then you will be prompted to upload the .txt file containing the spectral data:

You can enter either the illuminance in lux (lx) or the luminous flux in lumens (lm) for each color.:

Repeat and upload the spectral data and enter the illuminance value for all LED colors.

When finished press Calculate and wait until the calculation is finished. Depending on the ColorCount this may take some time.

Save and Write App Control Configuration

Now you have finished the App Control Configuration and we are back on the first editing page. In the top right, save the configuration as a file or send it directly to the fixture for testing:

In order to upload it later to the web-service you need to save the file. The next chapter test controlling requires this to be written on the fixture.

After enabling the Test Mode and connecting to the fixture it should look like this. To test App Control, click on "App Control Test":

Your fixture should display only the supported components at the top. If you are able to control your fixture here, the App Control Configuration was set up correctly. If not, return to the App Control Configuration to resolve the issue.

DFU stands for „Device Firmware Update“ and is a technology used to upgrade the firmware of embedded devices like lighting fixtures, sensors, or controllers. This process is crucial for fixing bugs, improving functionality, adding new features, and patching security vulnerabilities after the devices have been deployed.

The Vision DFU (Device Firmware Update) process involves just sending a variable sized datastream to the device. This raw datastream does not have a defined structure, which means it can work with all previous fixture DFUs. This flexibility allows any type of DFU file to be used, making it easier to update devices without needing to change the file format. To get the update data to the app a simple „.bin“ file is used. It is recommended that error checks are implemented in the data stream.

A DFU file („.bin“ file / datastream) contains the data necessary to update the firmware of an embedded device. The structure of a DFU file is designed to ensure that the firmware can be safely and effectively updated. An important aspect of this structure is the inclusion of a header, which carries specific information that helps in managing the update process. Here's how the components typically work together:

Components of a DFU Binary File with Header:

1. Header: The header is a crucial part of the DFU file as it contains metadata about the firmware update. This metadata typically includes:
   • Version number: Indicates the version of the firmware, helping to determine if the update is newer than the current firmware on the device.
   • Device identifier: Specifies the types of devices that are compatible with the firmware, ensuring that the update is applied only to appropriate devices.
   • Checksum or hash: A cryptographic hash of the firmware data, used to verify the integrity of the file after it has been downloaded or transferred, to ensure it has not been tampered with or corrupted.
2. Firmware Data: This is the actual binary data that will be written to the device’s memory. It replaces the existing firmware or modifies parts of it to enhance functionality or fix issues.

Handling a software update is done through READ_DFU and WRITE_DFU function.

The following Interrupt lines must be used to derive the state:

• DFU_START_IRQ
• DFU_PACKET_IRQ
• DFU_STOP_IRQ

Whenever a software update is triggered, the DFU_START_IRQ goes high.

Then the fixture must get ready for receiving firmware. One of the following responses of the Fixture is required:

• 0x0: DFU_ACCEPT
• 0x1 – 0xFF: DFU_ABORT

A fixture responds by using WRITE_DFU function. The Timeout for the response is set to 20 seconds. Writing a response will disable the DFU_START_IRQ flag.

After accepting the DFU, the Vision Controller starts to send firmware packets. Each packet has a unique id which is counted upwards. Length is variable up to 200Byte. Default length is 128 Byte. packetNr is stored in Big Endian not Little Endian!

After reading the packet, the next packet will be transfered automatically. No extra response necessary.

If there occurs an error it is possible to abort the DFU early by writing a response greater than 0 (0x1 – 0xFF).

DFU is aborted if no packet is read for 30 seconds. It can take up to 30 seconds before the first packet arrives. Please make sure not to abort before this timeout.

After receiving the last packet, DFU_STOP_IRQ flag will go high in order to signal that all packets are transfered and DFU transmission is finished.

Now a last response from the fixture is required. The response should be one of the following:

• 0x0: DFU_SUCCESS
• 0x1: DFU_ERROR_FLASH_ERASE
• 0x2: DFU_ERROR_NOT_IN_PROGRESS
• 0x3: DFU_ERROR_CORRUPTED_HEADER
• 0x4: DFU_ERROR_CORRUPTED_IMAGE
• 0x5: DFU_ERROR_INVALID_IMAGE_VERSION
• 0x6: DFU_ERROR_NO_PREAMBLE
• 0x7: DFU_ERROR_INVALID_FIXTURE_ID
• 0x8: DFU_ERROR_UNKNOWN
• 0x9: DFU_ERROR_SIGNATURE_NECESSARY_NOT_FOUND
• 0x0A: DFU_ERROR_PACKET_TIMEOUT
• 0x0B – 0xFF: Reserved

Here is an pseudo code example for receiving the data via the application firmware instead of using a boot-loader to receive the data as the example provides it:

#define DFU_BOOT_DELAY_MS     1000
#define MAX_FIRMWARE_SIZE     (256 * 1024u) // example

typedef enum
{
    DFU_STATE_IDLE = 0,
    DFU_STATE_RECEIVING,
    DFU_STATE_ERROR,
    DFU_STATE_BOOT_PENDING
} dfu_state_t;

static dfu_state_t dfuState = DFU_STATE_IDLE;
static uint32_t dfuDataCounter = 0;
static uint16_t dfuPacketCounter = 0;

static uint8_t firmwareData[MAX_FIRMWARE_SIZE]; // Just dummy, use flash to write here
 
static void Dfu_Reset(void)
{
    dfuState = DFU_STATE_IDLE;
    dfuDataCounter = 0;
    dfuPacketCounter = 0;
}

static void Dfu_Abort(uint8_t errorCode)
{
    vision_writeDfu(errorCode);
    Dfu_Reset();
}

static bool Dfu_StoragePrepare(void)
{
    // Erase temporary DFU flash area here.
    // Return false if erase failed.
    return true;
}

static bool Dfu_StorageWrite(uint32_t offset, const uint8_t *data, uint16_t length)
{
    // Write data to temporary DFU flash area.
    // Handle flash alignment here.
    // Return false if flash write failed.
    (void)offset;
    (void)data;
    (void)length;

    return true;
}

static bool Dfu_CheckFirmwareDataValid(uint32_t imageSize)
{
    if (imageSize == 0)
    {
        return false;
    }

    if (imageSize > MAX_FIRMWARE_SIZE)
    {
        return false;
    }

    // Recommended checks:
    // - image header valid
    // - target device / hardware ID valid
    // - firmware size valid
    // - CRC/hash valid
    // - version valid
    //
    // Final signature/security validation should also be done by bootloader.

    return true;
}

static void Dfu_StartBootloaderTimer(void)
{
    // Start one-shot timer, for example 100 ms.
    // After timeout call Dfu_BootloaderTimerElapsed().
}

static void Dfu_SetBootloaderPendingFlag(void)
{
    // Store persistent bootloader request.
    // Options:
    // - backup register
    // - retained RAM magic value
    // - flash flag
    //
    // Bootloader must check this after reset.
}


static void Dfu_BootloaderTimerElapsed(void)
{
    if (dfuState != DFU_STATE_BOOT_PENDING)
    {
        return;
    }

    Dfu_SetBootloaderPendingFlag();

    __disable_irq();

    // Optional:
    // deinit peripherals
    // flush logs
    // stop radio/SPI/UART cleanly

    NVIC_SystemReset();
}


  // Callback Implementation SPI Library ---------------------------------------------------------------------
 
 static void DfuFlagReceivedCallback(vision_dfu_flag_t flag)
{

	if(flag == VISION_DFUFLAG_STOP)
	{
		if (dfuState != DFU_STATE_RECEIVING)
		{
			Dfu_Abort(DFU_ERROR_NOT_IN_PROGRESS);
			return;
		}

		if (!Dfu_CheckFirmwareDataValid(dfuDataCounter))
		{
			Dfu_Abort(DFU_ERROR_CORRUPTED_IMAGE);
			return;
		}

		dfuState = DFU_STATE_BOOT_PENDING;

		// Tell sender that application-side receive/validation was okay.
		vision_writeDfu(DFU_SUCCESS);

		// Do not reset state here.
		// Wait until the response had enough time to leave the device.
		Dfu_StartBootloaderTimer();
		return;
	} 
	else if(flag == VISION_DFUFLAG_START)
	{
		Dfu_Reset();

		if (!Dfu_StoragePrepare())
		{
			Dfu_Abort(DFU_ERROR_FLASH);
			return;
		}

		dfuState = DFU_STATE_RECEIVING;

		// State is valid before response is sent.
		vision_writeDfu(DFU_SUCCESS);
		return;
	}
}
static void DfuDataReceivedCallback(uint16_t packetNr,const uint8_t* buf, uint16_t length)
{
	 if (dfuState != DFU_STATE_RECEIVING)
    {
        vision_writeDfu(DFU_ERROR_NOT_IN_PROGRESS);
        return;
    }

    if (buf == NULL || length == 0)
    {
        Dfu_Abort(DFU_ERROR_INVALID_PACKET);
        return;
    }

    if (packetNr != dfuPacketCounter)
    {
        Dfu_Abort(DFU_ERROR_WRONG_PACKETNR);
        return;
    }

    if ((uint32_t)length > (MAX_FIRMWARE_SIZE - dfuDataCounter))
    {
        Dfu_Abort(DFU_ERROR_IMAGE_TOO_LARGE);
        return;
    }

    if (!Dfu_StorageWrite(dfuDataCounter, buf, length))
    {
        Dfu_Abort(DFU_ERROR_FLASH);
        return;
    }

    dfuDataCounter += length;
    dfuPacketCounter++;

}

Here we will explain how to get a .Bin file which can be used to update your fixture via the Vision APP. if you have followed the Custom Firmware instructions it is possible to generate this file using the following instructions:

First open the Vision App on Windows. If you are not familiar with this step please check out the following site first:
#source-66_Test_Preparations
Set the application into "Test Mode" using the following procedure. This allows to use and see development fixtures which are not registered:

• Go to "Settings" by clicking on the gear in the top:
• Click on App Settings:
• Tab on the App Software Version label (0.0.5.0) two times. After that a prompt shows up. Type in the PIN "7248". Then the Test Mode will be activated.

Now you have got the necessary functions available in the App. Go again to the settings tab.

Now Developer Tools should be visible.

Click then on DFU File Generator:

Now you are at the DFU File generator. Here you can put in your Application .Bin file, Your RDM Manufacturer Model and the RDM Device Model ID. Both in decimal and not hexadecimal.

Attention:
The DFU is secured using RDM Manufacturer and Device model id.
When you create a product you use this unique information to secure the firmware. This makes sure it is just able to be uploaded on this kind of fixture.
This is important that fixtures cannot be bricked with the wrong firmware. So make sure this is always correct.

Also put in the Firmware Version of the Application. The Vision app requires a standardized Versioning format x.x.x.x

The first is called Major. –> Indicates incompatible function to previous firmware
The second is called Minor –> Indicates added feature to previous firmware
The third is called Patch –> Indicates a bugfix to previous firmware
The forth is called Release –> Marks an Release for a public firmware verision. Always keep this 255 for public versions.

This is called Semantic Versioning https://semver.org/

If you have followed the instructions from „Project Artery IC“ or „Project STM32 IC“ you can open Keil and build the Application Project in „ReleaseBL“ target configuration.

For Keil you have to add the following in the Target User Settings:
Add the following content in "User" command column:
fromelf.exe –bin –output .\Listings\@L.bin !L
Attention: Copying this line may is corrupted. make sure this are double hyphen.

It should look like this if you have filled the data:
The Manufacturer 61450 and RDM Device Model ID 2 are only our example Values and should not be used in your product.

Now press „Generate DFU File“ to retrieve your file.

This file can now be used to either upload it in our webservice or manually select in the APP for update process:

For more information about the upload process have a look at:
#source-82_Create_App_Library_Create_Fixture under Software Upload.

1. After enabling the Test Mode and connecting to the fixture it should look like this. To test DFU click on „DFU“:

2. Simply choose a .bin file via the "Load File" button and start the DFU with "Run DFU". A progress bar and the status label will show the progress:

Sleep Mode

Purpose: Allows users to minimize power of fixture with wakeup possiblity from the app.

How it works:

• Users can activate sleep mode in the app
• The fixture then disables everything to minimze power like drivers, display, motors usw.
• Users can then wakeup fixture via app again. Fixtures should also wakeUp when device is reset.

Sleep Mode should last at minimum 1 Week.

Feature Battery Runtime Selection

Purpose: Allow users to optimize between brightness and battery duration.

How it works:

• The user picks how long the fixture should run (for example 2, 4 or 8 hours). The selected runtime is reached when the battery is fully charged. If the battery is only at 50%, the fixture will run for half of the selected time. This is simple and easy to understand, and does not need complex calculations. You can also show the remaining runtime to the user, so they can decide if they want to switch to a longer runtime without having to calculate it themselves.
• To reach the selected runtime, the fixture should lower its output power (brightness) based on the available battery capacity. The simplest way is to set a fixed maximum brightness that makes sure the runtime is reached.
• This is useful for events or portable use, where the light needs to last a known amount of time.

Battery Runtime Selection can be turned on and off. The setting must be saved, so the fixture remembers it after a power loss.

The runtime always refers to a fully charged battery (100%).

A good implementation limits the maximum power output of the fixture. Use the battery capacity and the current power consumption to dim the light just enough to reach the selected runtime.

How to implement it:

• Know the battery capacity, for example in Wh. If the fixture has a battery gauge, you can update this value over time as the battery ages, to keep the runtime accurate.
  Example: BATTERY_CAPACITY = 100Wh
• Know the power consumption of each LED. If you can measure the power live, you can use the real values instead of fixed ones.
  Example:
  POWER_RED = 5W
  POWER_GREEN = 5W
  POWER_BLUE = 5W
• Calculate the maximum allowed power for the selected runtime.
  MAXPOWER = BATTERY_CAPACITY / RUNTIME
  Example: MAXPOWER = 100Wh / 10h = 10W
• Calculate the current power used by the LEDs.
  Example: ACTPOWER = POWER_RED * DIMMER_RED + POWER_GREEN * DIMMER_GREEN + POWER_BLUE * DIMMER_BLUE
• Check if the power needs to be reduced:
  if (MAXPOWER < ACTPOWER)
  {
  DIMMERCUT = MAXPOWER / ACTPOWER
  }
• Apply the new dimmer values to the LEDs.
  NEW_DIMMER_RED = DIMMER_RED * DIMMERCUT
• To show the minimum remaining runtime to the user you can just calculate:
  REMAINING_RUNTIME = RUNTIME * CURRENT_BATTERY_LEVEL

For an implementation help you can refer to our runtime library which can be implemented free of charge:
./51_Battery_Runtime_Library.html

Feature Emergency Mode

Purpose: Ensure lighting is available during power outages or system failures.

How it works:

• When AC power is lost, the fixture automatically switches to battery power.
• It activates a predefined emergency lighting profile, often at reduced brightness to extend runtime.
• This mode typically complies with safety regulations (e.g., EN 60598-2-22) and may run for a minimum guaranteed duration (e.g., 1 or 3 hours).

Emergency Mode can be enabled and disabled. This setting should be saved, so if the fixture looses power it remembers its state.

If gridpower (AC) is available then it should behave as in normal operation.

Feature Anti-Theft-Mode

Purpose: Prevent unauthorized use or theft of the device.

Anti-Theft-Mode can be enabled, disabled and triggered. While Anti-Theft-Mode is enabled it should not be possible to turn off the fixture or using a user interface like a display. When Anti-Theft-Mode is triggered the fixture should signal an alarm using visual effects and or sound effects.

This feature can be fully implemented only if the fixture is battery powered. If this feature is active, all user interfaces should be locked. ( Menu locked, Button locked,..) The Vision IC has information about the current acceleration of the fixture. If that fixture is moved while in anti-theft-mode an alarm will be triggered.

• Use your internal speaker as siren (optional)

Feature Shipping Mode

Shipping Mode can only be enabled.

If the shipping mode is enabled, the fixture should turn off and cuts off battery power. The fixture can only started again through gridpower (AC), to ensure a seamless transport experince.

Fixture Name:

Firmware Version:

DMX/RDM Test

• Factory Default to ensure fixture is in default settings
• Open Vision Control App and go into Test Mode
• Use a RDM test tool or our Vision DMX Adapter for testing

RDM

Custom RDM

VISION Test

• Factory Default to ensure fixture is in default settings
• Open Vision Control App and go into Test Mode
• Set Fixture to VISION

RDM

Custom RDM

Firmware Update

DMX Control

Display Menu Test

NFC Test

App Control Configuration Test

Optional Tests

Button Test

Battery Test

Motion Test

IR Test

This chapter explains how to create the fixture data for the Vision Control App. This includes the company account, OEM or branding decision, fixture entry, firmware, App Control Configuration, images, and resources.

Do this before production. Production is the later step where physical modules are flashed, updated, and licensed.

What this chapter covers

• Create or request the company account on the Vision Web Service.
• Decide whether the fixture is your own product, an OEM sample, or a branded customer product.
• Create the fixture entry with the correct RDM Manufacturer ID and RDM Device Model ID.
• Upload the firmware, App Control Configuration, product images, icon, and documents.
• Request the fixture release when the implementation and uploaded data are final.

Important

The RDM Manufacturer ID and RDM Device Model ID identify the fixture type. Do not change these values after release. If these values change later, fixtures in the field may no longer be recognized as the same product.

The uploaded App Control Configuration must match the final firmware. If the firmware behavior changes, check the App Control Configuration again before release or production.

Create or request your company account before creating fixtures in the Vision App Library. The same login is used for the Vision Control App and the Vision Web Service.

Open the Vision Web Service

Open https://server.kk-t.eu/ and log in with your Vision account.

If you do not have an account yet, install the Vision Control App first and create the account there:

Go to Windows Store

Go to Google Play Store

Go to Apple App Store

Use the demo company first

After login, open MY COMPANY (DEMO). The demo company shows the pages you will later use for your own company, for example Dashboard, Company, My Fixtures, and My Licenses.

Request your company

From one of the demo pages, follow the Demo! Create Company here link. Fill in the company request carefully and use a valid company email address.

Vision Control checks the request before the company is activated. If information is missing, or if the company cannot be verified, we will contact you by email. Verification can take 2-3 business days.

After verification, you receive an email and can create fixtures, manage release data, and buy production licenses for your company.

If one account must manage several companies, contact Vision Control or write to info@vision-cs.de.

This page explains the recommended OEM and branded fixture workflow. Read this before creating the final fixture entry on the Vision Web Service.

The RDM Manufacturer ID together with the RDM Device Model ID identifies the exact fixture type. These two values cannot be changed after a fixture is released. Changing them would mean that fixtures already in the field may no longer be recognized. Descriptions, images, website URLs, resources, and names can still be changed later.

Recommended workflow

1. Development sample

Create a fixture in your company and use your own naming scheme, your RDM Manufacturer ID, and your RDM Device Model ID. This fixture is used for internal development, demonstrations, and customer samples. It does not need to be visible publicly in the app.

RDM Manufacturer: your company Manufacturer ID
RDM Device Model ID: your fixture-specific Device Model ID

Example with the Vision Core Module:

When the sample is finished and verified, request a release on the fixture page. Until release, the fixture remains internal and only authorized accounts can access it.

2. Customer sample

After the sample is released, ship it to the customer for testing. If the customer wants a branded fixture, continue with the branded production fixture. If no branding is required, you can continue directly with production.

3. Branded production fixture

For a branded product, adapt the firmware and product data to the customer's requirements. The released product should use the brand's final RDM information if the brand needs to own the fixture identity.

RDM Manufacturer: brand's Manufacturer ID
RDM Device Model ID: brand's fixture-specific Device Model ID

Create a separate fixture on the server with the brand's final product information.

After the branded fixture entry is ready, you can share access to the fixture with the brand so they can maintain product data or release information if required.

Create the fixture entry after the company account exists and the final fixture identity is clear. The fixture entry is the App Library record used by the Vision Control App to recognize the product and load the correct app data.

Before you start

• Final RDM Manufacturer ID.
• Final RDM Device Model ID.
• Fixture name, brand name, product description, website, and support information.
• Serial number format used by the fixture.
• Final or release-candidate firmware file.
• Final App Control Configuration that matches the firmware.
• Fixture image, app icon, and optional documents such as manual, DMX chart, or technical data sheet.

Important: the RDM Manufacturer ID and RDM Device Model ID must stay stable after release. These two values are how Vision identifies the fixture type.

Open My Fixtures

Log in to the Vision Web Service, open your company, and go to My Fixtures.

Create the fixture

Click the plus button to create a new fixture. Fill in the product identity carefully.

• RDM ESTA Manufacturer ID: enter the decimal value. If your value is written in hexadecimal, convert it to decimal first. If you are not an RDM manufacturer, use your assigned Vision replacement ID.
• RDM Device Model ID: enter the decimal value of the fixture model ID.
• Serial number validation: enter the regular expression used to validate fixture serial numbers. If there are no special requirements, use the simple numeric format already recommended by Vision Control.
• Product information: add the user-facing name, brand, description, website, and support information.

After saving, the fixture appears on the My Fixtures page. New fixtures are created as draft and are not released to normal users yet.

Add image and icon

The fixture image and icon are shown in the app. They should make the product easy to recognize.

• Image: upload a clear product image.
• Icon: use a transparent 200 x 150 px icon without active light output.
• App Control icon: mark the controllable light area. Older pages or screenshots may call this Icon Creative.

Upload firmware

Open the Software section and upload the firmware file for the fixture. Add clear release notes so the customer can understand what changed.

• Use the versioning format expected by the Vision Web Service.
• Only release firmware that was tested on the real fixture.
• Keep draft firmware internal until it is ready for release.

When the firmware is ready for users, change it from draft to release.

Upload resources

Upload customer-facing documents in the resources area. Typical resources are the user manual, DMX sheet, safety information, technical specification, or service documents.

Upload App Control Configuration

Upload the final App Control Configuration created and tested during implementation. This configuration must match the final firmware behavior. If the firmware behavior changes, check whether the App Control Configuration must also be updated.

Legacy naming: App Control Configuration was previously called Creative Configuration or Creative Config in older app versions, screenshots, URLs, and filenames.

If several firmware versions use the same configuration, they can reference the same App Control Configuration. If a new firmware changes the DMX layout or App Control behavior, upload a new configuration and assign it to the matching firmware version.

Check release information

Before requesting the release, check all information that will be visible or used by the Vision Control App.

• Fixture name, brand, description, website, and support contact.
• RDM Manufacturer ID and RDM Device Model ID.
• Firmware version and release notes.
• App Control Configuration assigned to the correct firmware version.
• Fixture image, icon, and App Control icon.
• Resources such as manual, DMX chart, technical data sheet, or safety information.

The RDM Manufacturer ID and RDM Device Model ID cannot be changed after release. Other product information can be updated later, but it should still be checked carefully before release.

Request release

Request the fixture release only after the real fixture was tested with the final firmware, final App Control Configuration, and final product data. Upload the requested verification information and, if required, a video that demonstrates the fixture functionality.

After release approval, continue with the production chapter: purchase production licenses, flash or update Vision modules, license modules, and verify the first production sample.

Share fixture access

If you manufacture the fixture as an OEM and another company owns the brand, share fixture access with that company after the fixture entry is ready. The brand can then maintain product data or release information according to the agreed workflow.

Production starts after the fixture implementation is verified and the App Library data is prepared. In production, every physical fixture must receive the correct Vision firmware/data, the correct App Control Configuration, and a valid production license.

Before production

• The fixture firmware is final or production-approved.
• The App Control Configuration matches the final firmware.
• The fixture entry exists in the Vision App Library.
• The fixture was verified with the implementation verification tool.
• Production licenses are available for the company.
• The production station can flash, update, and test the Vision module.

Production flow

1. Purchase production licenses: make sure enough licenses are available before building a batch.
2. Flash the Vision module: program the Vision module with the correct bootloader or production flash file for the selected hardware module.
3. Update the Vision module: if the production flash file does not already contain the final app data, update the module with the final App Control Configuration in the Vision Control App.
4. License the Vision module: activate the production license for each fixture through the License Manager.
5. Verify the first production samples: check discovery, connection, App Control, DMX Control, RDM data, firmware version, and optional features.
6. Finish market preparation: apply required Vision logo or sticker information and complete certification-related tasks.

Flash file or app update

For small batches or development samples, it is often fine to update App Control Configuration through the app. For larger production runs, a production flash file can reduce manual steps because the required Vision data is already included during flashing.

If the product uses custom hardware or a custom firmware workflow, also check the custom production flash file documentation.

Production sample check

Always test at least the first units of a production batch with the final app release data. A sample that was only tested with development data is not enough for production approval.

Production licenses must be available before fixtures can be licensed for normal customer use. Buy licenses from the company account that owns the fixture production.

Open My Licenses

Log in to the Vision Web Service at https://server.kk-t.eu/, open your company, and go to My Licenses. The page shows free and already used licenses. Click the shopping cart to buy more licenses.

Choose license type and quantity

Select the required license type and enter the quantity. The price is calculated automatically according to the current pricing scheme. For contract pricing or larger quantities, contact the Vision Control team before ordering.

Checkout

Enter the company and payment information. Use a clear address format, for example:

Example Company Inc
Street and house number
ZIP code and city
Country

If anything is unclear, contact Vision Control before submitting the order.

After ordering

After the order is successful, the company page shows the order overview. You can view and download invoices there. The purchased licenses can then be used in the production licensing step.

This page describes the production flashing step for the Vision module. In the standard production flow, flashing writes the required Vision bootloader to the Vision IC.

The fixture application firmware is normally not flashed in this step. The fixture firmware should be installed or updated through the firmware update procedure so that the bootloader and update process are verified correctly.

For faster production, it is optional to generate a fixture-specific bootloader flash file that contains the Vision bootloader together with the final App Control Configuration. This reduces manual app steps later in production.

If the Vision module already contains the correct bootloader and the final App Control Configuration, continue with the licensing step instead.

Flash bootloader

Download the correct Vision bootloader from the Vision Firmware page. Choose the file that matches the Vision hardware module used in the fixture.

1. Select the correct bootloader file for the Vision module.
2. Erase the Vision IC before flashing so the MBR is erased correctly.
3. Flash the bootloader with the corresponding flash tool for the module.
4. Power the fixture and confirm that the Vision module can be discovered by the Vision Control App.

Optional bootloader + App Control Configuration

A production flash file can include the Vision bootloader data and the final App Control Configuration. This can reduce manual app steps during production. The exact file depends on the Vision hardware module and the final fixture configuration.

The Vision Control App includes a developer tool for generating a Vision bootloader flash file. This is optional and mainly useful when production should preload the App Control Configuration into the Vision module.

1. Enable developer tools in the app settings.
2. Open Developer Tools.
3. Open VISION Bootloader Flash File Generator.
4. Select the Vision IC or module type used in the fixture.
5. Select the fixture from the App Library.
6. Check optional settings only if they are required for the product.
7. Generate the Vision bootloader flash file.
8. Flash the generated file to the Vision IC with the approved production programmer, for example J-Link.

After flashing

Power the fixture and scan it with the Vision Control App. The fixture should appear as Vision Bootloader and be ready to receive the firmware.

This page describes how to update a Vision module with the final App Control Configuration. Use this step when the fixture was flashed without the final app data, or when the App Control Configuration was changed after the module was programmed.

When this is required

• The production flash file did not include the final App Control Configuration.
• The App Control Configuration was updated after flashing.
• A development module must be converted to the final released fixture data.
• The app shows that the fixture requires an App Control Configuration update.

The App Control Configuration must match the final firmware. If firmware and App Control Configuration do not belong together, App Control can behave incorrectly.

Update with the Vision Control App

1. Power the fixture and open the Vision Control App.
2. Scan for fixtures.
3. Open the tools icon with the red badge.
4. Open App Control Configuration Manager.
5. Select the fixture or use Update all for all detected fixtures that need the update.
6. Wait until the update is finished.
7. Restart the fixture if the app or fixture behavior requires it.
8. Scan again and confirm that no App Control Configuration update is pending.

After the update

Test the fixture directly in App Control. Check that the shown controls match the product and that every configured function reacts correctly. After this check, continue with production licensing.

This page describes the production licensing step. Licensing activates a production license for each physical fixture. Do this after the fixture is implemented, verified, registered in the Vision App Library, and prepared with the correct Vision data.

Check license availability

Open https://server.kk-t.eu/, log in, open your company, and go to My Licenses.

• Free External Licenses: purchased External Vision licenses that are not used yet. This value must be greater than 0 before licensing a new External Vision fixture.
• Free Core Licenses: purchased Core licenses that are not used yet.
• Used External Licenses: External Vision licenses already activated for fixtures.
• Used Core Licenses: Core licenses already activated for fixtures.
• License Count: number of licenses used by a specific fixture type.

Find unlicensed fixtures in the app

Open the Vision Control App and scan for fixtures. An unlicensed production fixture can be shown with a warning. The warning means the fixture is detected, but it cannot be used normally until a license is activated.

License the fixtures

1. Open the tools area in the Vision Control App.
2. Open License Manager. A red badge can indicate fixtures waiting for licensing.
3. Check that the fixture is shown as licensable.
4. Use License all if all listed fixtures should be licensed.
5. Wait until the app confirms the licensing result.

Verify the license

After licensing, the fixture should no longer show the unlicensed warning and can be controlled with the Vision Control App. On the Vision Web Service, the free license count is reduced and the used license count is increased.

Open the fixture license details to see the licensed fixtures with serial number, RDM ID, and related information.