Manufacturer-specific PIDs are used to provide manufacturers with a mechanism to implement RDM commands that are not available in the standard RDM command set. The RDM standard says:
“Manufacturer-specific PID‘s shall be created in the range of 0x8000 – 0xFFDF. Uniqueness of PID‘s in this range is accomplished by associating the PID with the Manufacturer ID found as the most significant 16-bits of the UID. PID‘s in the range of 0xFFE0 – 0xFFFF are reserved for future uses of this standard.”
There are generally two categories of use:
1) To implement additional functionality that will be available to all.
2) To implement manufacturing specific commands that will be closed to all but the manufacturer.
The first option is simple to implement. The manufacturer-specific PIDs are defined and published using PIDs such as Supported_Parameters and Parameter_Description. From then on, it is the controller’s responsibility to ensure that it only sends you valid manufacturer-specific Pids.
The second option provides more room for error if the designer does not think through all scenarios. It is quite usual for manufacturers to use a manufacturer-specific Pid for functions such as ‘programme UID’. Clearly these are intended to only be used in the manufacturing process and chaos would ensue if they were activated in the field.
What can manufacturers do to protect against inadvertent activation of their manufacturer-specific Pids:
1) Not public the Pid in Supported-Parameters. This is sensible, but does not give any real protection. For example, network test software way well send un-published manufacturer-specific Pids to see whether the device responds.
2) Ensure that the responder will only accept critical manufacturer-specific Pids when it is in a “special configuration mode”.
3) Include ‘magic-numbers’ in the packet to ensure that manufacturer-specific Pids sent in error do not have unexpected effects.
4) Ensure that the responder will only accept critical manufacturer-specific Pids which have a source-UID containing the manufacturer code. This is the strongest protection.
An index of published manufacturer PIDs can be found at http://rdm.openlighting.org/pid/manufacturer
From time to time, new firmware is released for Jump-Start. The latest version can be downloaded here. It is not necessary to return Jump-Start for upgrade – it can be done in the field. This is achieved by connecting Jump-Start to an Artistic Licence Art-Net node such as artLynx. DMX-Workshop can then be used for the upgrade.
Please follow the following procedure:
- Ensure Jump-Start is set to ‘RDM Standard’ and not ‘DRAFT’. This can be found in the setup menu.
- Put the Jump-Start in firmware upload mode. This is done by pressing the left and right arrow keys at the same time.
- The right-side LED will light to confirm upload mode is active.
- Connect the Jump-Start to the Art-Net node.
- Download the latest firmware (see link above) and copy file to: C:\Program Files (x86)\Artistic Licence\DMX-Workshop\Firmware.
- Select the network list in DMX-Workshop and wait for Jump-Start to be discovered as a node.
- Upload the firmware to the Jump-Start by right-clicking in RDM information area and following the options to upload firmware.