firmware or file upload control -...

© 2018 by ESTA all rights reserved CP/2017-1024

ESTA

DRAFT

BSR E1.37-4, Entertainment Technology -

RDM

Remote Device Management over DMX512 Networks

File Transfer Control with Firmware Upload capabilities.

Task Group Draft Revision 2.6

CP/2017-1024

Copyright © 2018 by Entertainment Services and Technology Association 630 Ninth Avenue, Suite 609 New York, NY 10036 USA

All rights reserved.

This is an unapproved draft of a proposed ESTA Standard, subject to change. Permission is hereby granted to participants in ESTA’s Technical Standards Program to reproduce this

document for purposes of standardization activities. If this document is to be submitted to ISO or IEC, notification shall be given to the ESTA Technical Standards Manager. Permission is also

granted for member bodies and technical committees of ISO and IEC to reproduce this document for the purpose of developing a national position. Other entities seeking permission to reproduce

portions of this document for these or other uses must contact the ESTA Technical Standards Manager for the appropriate licence. Use of information contained in the unapproved draft is at

your own risk.

ESTA 'Work in Progress' documents are copyrighted and only may be copied for the purpose of developing the Standard within the Task Group or Working Group the project is assigned to. It is the policy of the Technical Standards Program that publishing of such preliminary information, such as in this document, in any form, including on Web Pages, is not allowed.

Draft Standard, BSR E1.37-4 File Transfer Control with Firmware Upload capabilities


Table of Contents

1. Introduction ........................................................................................................................... 7

1.1 Adoption as a standard ................................................................................. 7

1.2 Terminology ................................................................................................... 7

2. Scope ..................................................................................................................................... 7

3. Overview ................................................................................................................................ 7

3.1 Use of Broadcast Message Transfers .......................................................... 8

3.2 Use of Proxy Devices .................................................................................... 8

3.3 Master Control ............................................................................................... 9

3.4 Transfer times ................................................................................................ 9

4. File Requirements ................................................................................................................. 9

4.1 Source Media ................................................................................................. 9

4.2 File Structure .................................................................................................. 9 4.2.1 Firmware File Structure.............................................................................................. 9

4.3 File Compatibility ........................................................................................... 9

4.4 Data Integrity .................................................................................................. 9

5. Controller Requirements .................................................................................................... 10

5.1 [RDM] Support Requirements ..................................................................... 10

5.2 Functional Requirements ............................................................................ 10

6. Responder Requirements .................................................................................................. 11

6.1 Hardware Design ......................................................................................... 11

6.2 Responder Firmware ................................................................................... 11

6.3 Responder Limited Behaviour .................................................................... 11

6.4 Responder Declarations .............................................................................. 11 6.4.1 Max Block Size (8 bit) .............................................................................................. 12 6.4.2 Initial Delay Time (16 bit) ......................................................................................... 12 6.4.3 Inter-packet Delay Time (8 bit) ................................................................................ 12 6.4.4 Accumulated Packet Count (16 bit) ......................................................................... 13 6.4.5 Accumulated Packet Delay Time (16 bit)................................................................. 13 6.4.6 Commit Delay Time (16 bit) ..................................................................................... 14 6.4.7 Responder Capabilities (16 bit ) .............................................................................. 14

7. Message Structure .............................................................................................................. 14

8. Operational Overview ......................................................................................................... 15

8.1 Negotiate Transfer ....................................................................................... 15



8.2 Transfer File Data......................................................................................... 15

8.3 Validate File Data ......................................................................................... 16

8.4 Commit File Data ......................................................................................... 16

8.5 Resuming Communications ........................................................................ 16

9. Use of FileCRC .................................................................................................................... 17

Table 9-1 CRC Byte Order ....................................................................................... 17

10. Use of CRC ...................................................................................................................... 17

11. Use of SessionID ............................................................................................................ 17

12. Use of FileID .................................................................................................................... 18

13. Replies from Responders .............................................................................................. 18

13.1 Good response ............................................................................................ 19

13.2 Good response – more time required ......................................................... 19

13.3 Bad Response – attempt recovery ............................................................. 19

13.4 Fatal Errors .................................................................................................. 19

14. Limitations ....................................................................................................................... 19

15. PID Use and Definition ................................................................................................... 20

15.1 Obtain Transfer Details and Status (uses GET:FTC_NEGOTIATE) .......... 20 15.1.1 Controller Request Obtain Transfer Details and Status ...................................... 21 15.1.2 Responder : Reply to Obtain Transfer Details and Status .................................. 22

15.2 Negotiate and Initiate Transfer (uses SET:FTC_NEGOTIATE) .................. 24 15.2.1 Controller : SET Request to Negotiate File Transfer: .......................................... 25 15.2.2 Responder : Generic response ........................................................................... 27

15.2.2.1 Responder : Negotiate OK : Provide Transfer Requirements ......................... 27 15.2.2.2 Responder : Negotiate Fail : Error in Packet CRC.......................................... 29 15.2.2.3 Responder : Negotiate Fail : Reject FileID ...................................................... 30 15.2.2.4 Responder : Negotiate Fail : Reject due to E1.37 Lock Mechanism. ............. 30 15.2.2.5 Responder : Negotiate Fail : Reject due to Other Lock Mechanism. .............. 31 15.2.2.6 Responder : Negotiate Fail : Reject File Content............................................ 31 15.2.2.7 Responder : Negotiate Fail : Any other reason ............................................... 32

15.3 Abandon a Transfer (uses SET:FTC_CANCEL) ......................................... 33 15.3.1 Controller : SET Request to Cancel: ................................................................... 33 15.3.2 Responder : Generic SET Response .................................................................. 34

15.3.2.1 Responder : Cancel request : Accept ............................................................. 34 15.3.2.2 Responder : Cancel request : Error in PacketCRC......................................... 34 15.3.2.3 Responder : Cancel request : Error in SessionID ........................................... 34 15.3.2.4 Responder : Cancel request : Error in FileID .................................................. 35

15.4 Validate File Data (uses SET/GET FTC_VALIDATE) .................................. 35 15.4.1 Controller : SET Request to Validate Transfer .................................................... 35 15.4.2 Responder : Generic SET Response .................................................................. 36

15.4.2.1 Responder : Validate Request : Validation OK ............................................... 36 15.4.2.2 Responder : Validate Request : Error in PacketCRC ..................................... 37 15.4.2.3 Responder : Validate Request : No data transferred ...................................... 37



15.4.2.4 Responder : Validate Request : Result not available yet ................................ 38 15.4.2.5 Responder : Validate Request : Error in SessionID ........................................ 38 15.4.2.6 Responder : Validate Request : Error in FileID ............................................... 39 15.4.2.7 Responder : Validate Request : Validation Failure ......................................... 39 15.4.2.8 Responder : Validate Request : Any other reason.......................................... 39

15.4.3 Controller : GET Request to Validate Transfer.................................................... 40 15.4.4 Responder : Generic GET Response .................................................................. 40

15.4.4.1 Responder : Validate Request : Validation OK ............................................... 41 15.4.4.2 Responder : Validate Request : No (SET) Request made ............................. 41 15.4.4.3 Responder : Validate Request : Result not available yet ................................ 41 15.4.4.4 Responder : Validate Request : Validation failure. ......................................... 42

15.5 Commit Data (uses SET:FTC_COMMIT) ..................................................... 43 15.5.1 Controller : SET Request to Commit Data .......................................................... 43 15.5.2 Responder : Generic SET Response .................................................................. 44

15.5.2.1 Responder : Commit Data Request : OK – Responder commit will start ....... 44 15.5.2.2 Responder : Commit Data Request : Error in PacketCRC ............................. 44 15.5.2.3 Responder : Commit Data Request : Missing Validation Request ................. 45 15.5.2.4 Responder : Commit Data Request : Modal Error .......................................... 45 15.5.2.5 Responder : Commit Data Request : Error in SessionID ................................ 46 15.5.2.6 Responder : Commit Data Request : Error in FileID ....................................... 46 15.5.2.7 Responder : Commit Data Request : Validation Failure ................................. 47 15.5.2.8 Responder : Commit Data Request : Write Protect Fail ................................. 47 15.5.2.9 Responder : Commit Data Request : Other Failure ........................................ 47

15.5.3 Controller : GET Request to Commit Data .......................................................... 49

15.6 Transfer Data (uses GET/SET FTC_TRANSFER) ....................................... 50 15.6.1 Sending Data TO a Responder ........................................................................... 51 15.6.2 Responder : Generic Response .......................................................................... 52

15.6.2.1 Responder : Data accepted : OK to continue ................................................. 52 15.6.2.2 Responder : Data accepted : WAIT before continue ...................................... 52 15.6.2.3 Responder : Data rejected : Resend Packet ................................................... 53 15.6.2.4 Responder : Data rejected : Abandon Transfer .............................................. 54

15.6.3 Obtaining Data FROM a Responder ................................................................... 55 15.6.3.1 Responder : Reply with data or end of file ...................................................... 56 15.6.3.2 Responder : Error condition ............................................................................ 56

15.7 Obtain Proxy Device Transfer Details (uses GET:FTC_PROXY_CAPABILITIES) ......................................................................... 58

15.7.1 Controller Request Fetch Proxy Device Capability ............................................. 58 15.7.2 Responder : Reply to Fetch Proxy Device Capabilities ....................................... 58

15.8 GET File_LIST (FTC_FILELIST) ................................................................... 59 15.8.1 Controller Request for File List. ........................................................................... 60

15.8.1.1 Responder : Reply with File List...................................................................... 61 15.8.1.2 Responder : File Type not supported .............................................................. 62 15.8.1.3 Responder : No files available ........................................................................ 62

15.9 GET FileType_DESCRIPTION (FTC_FILETYPE_DESCRIPTION) ............... 63 15.9.1 Controller Request for FileType Description ....................................................... 63

15.9.1.1 Responder : Reply with FileType Descriptive Text ......................................... 63 15.9.1.2 Responder : FileType not supported ............................................................... 63

15.10 GET File_DESCRIPTION (FTC_FILE_DESCRIPTION) ............................ 64



15.10.1 Controller Request for File Description ............................................................... 64 15.10.1.1 Responder : Reply with FileID Descriptive Text ......................................... 64 15.10.1.2 Responder : FileID not supported ............................................................... 65

Appendix A: Defined Parameters ............................................................................................... 66

Table A-1: Parameter ID Defines ............................................................................ 66

Table A-2: Response Status Defines ..................................................................... 67

Table A-3: Use of Response Data field .................................................................. 67

Table A-4: Transfer Query Status Defines ............................................................. 67

Table A-5: Response Status Nack Reason Codes ................................................ 68

Table A-6: [RDM] Additional Nack Reason Codes ................................................ 68

Table A-7: File Type Enumeration .......................................................................... 69

Appendix B: Control Flow for “1:1” upload transfers ............................................................. 70

Example B-1 : Controller to Responder : Successful Validation ......................... 70

Example B-2 : Controller to Responder : Validation Fails .................................... 72

Example B-1 : Controller to Responder : Successful Validation, Commit Rejected ................................................................................................................... 73

Example B-3 : Controller to Responder : Negotiate Fails ..................................... 75

Appendix C: Control Flow for “1:1” download transfers ........................................................ 76

Example C-1 : Controller from Responder : Successful Transfer ........................ 76

Example C-2 : Controller from Responder : Failed Transfer ................................ 77

Appendix D: Control Flow for “1:many” transfers ................................................................... 78

Example D-1 : Controller to Responder using 1:many transfers ........................ 78

Appendix E: Control Flow PROXY DEVICES ............................................................................ 80

Example E-1 : Controller to Responder via Proxy : Successful Validation ......... 80

Appendix F: Transfer Time Guidance........................................................................................ 81

Appendix G CRC Example Algorithm ........................................................................................ 82



List of Tables

Table A-1: Parameter ID Defines .................................................................................................. 66 Table A-2: Response Status Defines ............................................................................................ 67 Table A-4: Use of Response Data field ......................................................................................... 67 Table A-3: Transfer Query Status Defines .................................................................................... 67 Table A-5: Response Status Reason Codes ................................................................................. 68 Table A-6: File Type Enumeration ................................................................................................. 69



1. Introduction

This document provides developers of RDM responder hardware with a standard means of implementing firmware upload using the basic communication structure provided by the ANSI E1.20 RDM standard. The E1.20 standard is referenced as [RDM] throughout this document.

The design approach is intended to facilitate data transfers to responders that may be built using processors with very limited memory resources as well as devices that can support the largest possible [RDM] packet. The Parameter Data for each [RDM] message is limited to 231 bytes, and multiple packets will inevitably be transferred in order to facilitate firmware uploads. In order to conserve bandwidth, the design supports “1:1” uploads, whereby each packet can be acknowledged, together with “1:many” transfers using [RDM] Broadcast messages.

When using a “1:many” scheme, a controller may wish to poll individual devices after the data transfer has occurred, in order to ascertain the integrity of the data prior to committing the data and forcing a reload of responder firmware.

The approach described in this document, although specifically targeting firmware uploads, may be used for the transfer of other file data as required, both to and from a responder.

The method described herein is therefore referred to as File Transfer Control (FTC)

1.1 Adoption as a standard

In the development of this FTC process, consideration has been given to possible adoption of this protocol as an extension to the existing [RDM] standard, and publication in a similar fashion to E1.37.

1.2 Terminology

Within this document, an upload refers to the transfer of data from a controller TO a responder, and a download refers to the collection of data from a responder by a controller.

2. Scope

This document sets out the minimum requirements for controllers and responders to allow file transfers using RDM to be successfully implemented. This standard defines the process and command implementation to allow transfers in either direction.

This standard specifically provides a transfer mechanism that can be applied to memory limited responders with transmit and receive buffers as small as 64 bytes, while allowing scalable improvements (a net reduction) in transfer times for responders that have larger buffers.

An objective of this standard is to provide firmware upload capability in a manner that minimises the number of RDM PIDs required. (Code space support for each additional PID can be significant and might otherwise prevent implementation in responders with limited code space.)

3. Overview

This section summarises FTC operation by which a controller may send a file, provided by the manufacturer of the responder, to the responder for the purpose of firmware or other File Upload function. It also summarises the means by which a controller may request the Download of file data from a responder.

This section of the document is informative only and does not contain specific requirements.

It is provided so that readers of the standard can gain understanding as to the suitability of this standard to their requirements. The basic [RDM] specification determines the maximum payload/packet that may be sent as 231 bytes.



A File Upload transfer (from controller to responder) comprises four stages: Negotiate, Transfer, Validate and Commit.

A File Download transfer (from responder to controller) comprises two stages. Negotiate and Transfer.

This design uses new Parameter ID’s (PIDs) as extensions to the [RDM] PID list.

These PIDs are used to control all aspects of Firmware or File Upload to a responder, and are the only PIDs required to support Firmware or File uploads.

Further optional PIDs allow declaration of details relating to file naming, file type and file access, and are required in order to support File Download transfers from a responder to controller.

3.1 Use of Broadcast Message Transfers

This standard allows for a controller to use RDM broadcast messages for transfer of data, but does not mandate such support.

Responders that cannot process data transfers via broadcast messages shall declare this as outlined in section 6.4.7 of this standard.

For simplicity, this standard requires controllers to use known Inter-packet and other delay times, obtained from the responder as part of the negotiate stage. This allows one design approach to cater for both “1:1” and “1:many” transfers. In the event that a controller makes use of broadcast messages in relation to data transfer, the controller may [if desired] request confirmation of successful data transfer by polling responders using the GET:FTC_VALIDATE message. This will return the last offset into the data received by the responder. Comparing this with the packets sent by a controller will allow determination of failures or loss of packets.

This standard does not preclude the use of broadcast messages to initiate the Validate or Commit stages, but system designers should accept that there is no guaranteed delivery or execution of instructions issued in this manner.

3.2 Use of Proxy Devices

Consideration has been given to the use of Proxy Devices (such as wireless DMX/RDM data links) in conjunction with controllers and responders wishing to use this standard.

Controllers issuing commands as 1:1 transfers using this protocol would expect Proxy Devices to use the ACK_TIMER method described in the [RDM] standard when it is not possible to provide an immediate response to a controller.

Controllers issuing commands as “1:many”, using Broadcast messages, may wish to modify their behaviour to suit limitations imposed by the presence of one or more PROXY DEVICES.

Proxy devices such as Wireless DMX/RDM links may choose to support the FTC_PROXY_NEGOTIATE PID, in order for the Proxy device to notify additional delays, for the purpose of simplifying or allowing time to propagate the forward transfer of data over the wireless link.

Such message modifications are limited to increasing the declared Inter-packet, accumulated packet, validate and commit delays.



An example of control flow with Proxy devices may be found in Appendix D:

3.3 Master Control

A controller may, at any stage during a transfer, issue a command to cancel the transfer. Receipt of such a command by a responder allows the responder to abandon all further expectation of data transfer until a new session is initiated by a controller.

3.4 Transfer times

An example calculation of transfer times is provided in Appendix E.

4. File Requirements

4.1 Source Media

The choice of media support is outside the scope of this standard. Controller manufacturers are free to choose whatever media support they feel is appropriate to their product. Typical source data media may be in the form of (but not limited to) USB key, SD Card, Email or Internet download.

4.2 File Structure

A firmware or other file for uploading to a responder by a controller shall contain data in binary format. A controller shall have no interaction with the content of a file, beyond calculation of a FileCRC as outlined in this document.

This standard places no constraints on the naming of any source file or the internal structure of the file.

4.2.1 Firmware File Structure

It is recommended that information necessary to determine the integrity of the entire transferred firmware file is contained in the file. The manner in which this is determined is the remit of the manufacturer, and beyond the scope of this standard.

4.3 File Compatibility

It is recommended that the information required to determine that the data is suitable for the target responder (by make, model and version or other method as chosen by the responder manufacturer) is contained in the first few packets transferred.

The manner in which this is determined is the remit of the responder manufacturer, and beyond the scope of this standard.

Manufacturers who elect to encode this information into the first 16 bytes of their files may benefit from efficiencies to be had in the use of this standard.

4.4 Data Integrity

Manufacturers may also wish to embed segment numbers, checksum or cyclic redundancy checking information in the content that is transferred over the data link using this standard. The manner in which such checks are embedded in manufacturers’ files is beyond the scope of this standard.

A PacketCRC is calculated by the controller and offered to the responder for each negotiate and transfer packet.



5. Controller Requirements

5.1 [RDM] Support Requirements

Controllers implementing this standard should provide support for ACK_TIMER and GET:QUEUED_MESSAGE handling as described in [RDM].

Although the use of ACK_TIMER is specifically avoided in this standard, the potential use of ACK_TIMER by Proxy Devices (in accordance with the [RDM] Standard) makes this demand of controllers. The requirement placed on controllers to support ACK_TIMER and GET:QUEUED_MESSAGE is so that Proxy Devices may work as expected in conjunction with responders implementing this standard.

Controllers implementing this standard shall accept the maximum size RDM packet as defined in [RDM].

5.2 Functional Requirements

Controllers shall accept file data supplied by the manufacturer for transfer to a responder using the methods described in this standard.

This standard does not specify the format of any file generated by a manufacturer for a particular responder.

A Controller interrogates a responder to ascertain the requirements and capabilities of the responder, using the Negotiate mechanism described in this standard.

The size of each transfer packet shall be determined by the controller from information obtained from the responder.

Controllers wishing to transfer data using this standard shall determine the required Max Block Size, Initial Delay, Inter-Packet Delay, Accumulated Packet Count, associated Accumulated Packet Count Delay and Commit Delay appropriate to each responder, in accordance with the methods described in this document.

Controllers that have determined the existence of Proxy Devices may also determine any required Max Block Size, Initial Delay, Inter-Packet Delay, Accumulated Packet Count, associated Accumulated Packet Count Delay and Commit Delay constraints appropriate to the Proxy Device, in accordance with the methods described in this document.

The method of determining the existence of Proxy Devices is beyond the scope of this standard.

The controller shall use these declared sizes and delays to regulate the transfer of data from controller to responder.

In the event that the controller wishes to make use of “1:many” transfers using RDM broadcast messages, the controller shall determine and use the longest required Initial Delay, Inter-Packet Delay, and Accumulated Packet Count Delay.

Controller manufacturers are advised to consider both the declared Max Block Size and Accumulated Packet Count, as it is expected that controllers will need to group similarly capable responders into a ‘session’ in order to successfully make use of “1:many” transfers.



These delays are to allow controller-responder transfers without the need for responders to advise required wait times as part of successive packet transfers.

Controllers electing to use “1:many” transfers may [if desired] request confirmation of successful transfer by polling each responder using messages defined in this standard.

A responder may, at any point in the transfer, indicate that the data offered is not suitable for the responder.

Receipt of such an error code by a controller shall cause the controller to abandon further data transfer in the current ‘session. This is only relevant to a “1:1” transfer operation. A controller utilising “1:many” will most likely continue on regardless, until failure is determined at the time of requesting validation of the transfer.

6. Responder Requirements

There are some minimum requirements that should be facilitated by responders to reliably use the transfer scheme detailed in this document. Responder manufacturers shall observe the following points to ensure the integrity of their products during any firmware upload process.

6.1 Hardware Design

Responders should use a design whereby at any stage of the FTC process, a stable or known state will be resumed in the case of any error condition created by the controller, loss of data or power failure. If any of these conditions cannot be met, they shall be explicitly declared by the manufacturer as a known risk.

Responders supporting firmware uploads shall provision for the entire upload data to be held in storage without affecting the ability of the responder to repeat the FTC process, even after a power failure or other disruption of the data transfer process.

6.2 Responder Firmware

Responders should not erase and or re-flash their operating firmware in response to any FTC command before data transfer has completed, data integrity has been confirmed and the data commit request has been received.

6.3 Responder Limited Behaviour

It shall be acceptable for a responder to limit or stop its normal functionality during the FTC process.

The extent of responder functionality during the FTC process is not defined by this standard, and is outside the scope of this document.

Responders shall declare if they allow DMX refresh or limit normal functions using the Capabilities field as described in section 6.4.7 of this standard.

For example, a responder may allow DMX packet processing while transferring a dimmer curve file, but not while accepting the transfer of a firmware file.

6.4 Responder Declarations

Typically, responder hardware will have some design constraint(s) that determine how much data may be accepted before it can be committed to storage. Microcontrollers or other off-chip memory devices may impose a “page” size, at which point a finite time (and possibly longer than the



normal inter-packet time) is required to commit the data to non-volatile storage. In this standard these requirements are declared by use of the Accumulated Packet Count and Accumulated Packet Count Delay.

During any delay time the responder may not be able to accept DMX Packets, RDM messages, or perform normal operations.

Responders may also have memory limitations that limit the size of each RDM packet that can be received.

Responders shall declare any required internal delays as part of the Negotiate stage as described in section 15.2 of this standard.

6.4.1 Max Block Size (8 bit)

The responder shall declare the maximum number of bytes of file data to be sent in each packet.

[Valid range is 16-224]

This value shall be used by a controller to determine the maximum number of bytes of file data to send to the responder in each FTC_TRANSFER message packet.

The 224 byte limitation is derived from (i) the maximum payload of 231 bytes defined in [RDM], and (ii) the use of a small header within payload of each transfer packet.

The transfer protocol defined in this standard requires a small header in each packet as part of the Parameter Data.

The Block Size has been limited to a value which is a multiple of 16bytes in deference to designers of small/simple responders.

6.4.2 Initial Delay Time (16 bit)

Minimum time (in ms) that the responder requires the controller to wait after negotiation before the first FTC_TRANSFER packet is sent.

Valid Range [0-65535ms]

This value shall be used by a controller to determine when to send the first FTC_TRANSFER packet.

When attempting to use “1:many” messaging to transfer data to a group of responders, controllers shall use the longest minimum Initial Delay time obtained by polling the responders in the group prior to commencement of the transfer.

Responder designers are encouraged to keep this Initial Delay time as low as possible, and preferably zero. In any event, successive packets cannot be sent with less than 176us inter-packet time as stated in the [RDM] standard.

6.4.3 Inter-packet Delay Time (8 bit)

Minimum time (in ms) that the responder requires the controller to wait after each FTC_TRANSFER packet.




This value shall be used by a controller to determine when to send each FTC_TRANSFER packet to a single responder, and when to send the validation request following the successful transfer of the last packet of the file.

Responders shall acknowledge the request before commencement of any internal operation that is the reason for requiring the delay.

When attempting to use “1:many” messaging to transfer data to a group of responders, controllers shall use the longest minimum Inter-packet Delay time obtained by polling the responders in the group prior to commencement of the transfer.

Responder designers are encouraged to keep this Inter-Packet Delay time as low as possible, and preferably zero. In any event, successive packets cannot be sent with less than 176us inter-packet time as stated in the [RDM] standard.

6.4.4 Accumulated Packet Count (16 bit)

The Accumulated Packet Count shall be used by a controller to determine when to further delay packet transfers after “N” packets have been transferred to the responder.

A responder that does not require any intermediate delays shall set this field to 0x0000.

6.4.5 Accumulated Packet Delay Time (16 bit)


A responder that does not require any intermediate delays shall set this field to 0x0000.

This parameter shall be used by a controller to determine how long to wait (in ms) once the number of transmitted packets reaches the declared Accumulated Packet Count.

This is to allow time for the responder(s) to save the accumulated data to non-volatile storage as may be required by their hardware designs.

Controllers shall reset their internal packet counter every time the delay is applied.

When attempting to transfer the same data to a group of responders using “1:many” messages, controllers shall ensure that all responders in a group have declared the same Max Block Size and Accumulated Packet Count.

Controllers shall use the longest declared Inter-packet Delay and Accumulated Packet Delay values from the responders within the targeted group.

This scheme allows for responders with limited buffer sizes to accept data as efficiently as possible prior to having the controller wait while the responder [potentially] goes off line to validate and write to local non-volatile storage.

For firmware uploads, it is most likely that the group of responders will all be of the same model, and so these parameter values may well be the same for all. However the responders may not all be running the same version of firmware code and thus these



values might differ. It is the responsibility of the controller application to check and use this information as appropriate.

6.4.6 Commit Delay Time (16 bit)

Valid Range [0-65535s]

This time shall be declared by a responder to indicate how long a controller should wait (in seconds) after sending a commit request. It indicates the time before the responder is expected to resume normal operation.

6.4.7 Responder Capabilities (16 bit )

A number of responder characteristics are reported using a 16 bit capabilities field.

Bit15 Bit14 Bit13 Bit12 Bit11 Bit10 Bit9 Bit8 Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0

Unless otherwise specified, bits shall be cleared ( 0 ).

Bit 0 : Set if responder is able to accept offered FileID for upload

Bit 1 : Set if responder is able to supply offered FileID for download

Bit 2 : Set if responder processes PacketCRC on reception

Bit 3 : Set if responder generates PacketCRC.

Bit 4 : Set if responder generates FileCRC for download.

Bit 5 : Set if responder processes FileCRC. on completion.

Bit 6 : Set if NullStartCcode DMX packets ignored during transfers

Bit 7 : Set if the responder limits normal functions during transfers

Bit 8 : reserved

Bit 9 :. reserved

Bit 10 :.Set if E1.37-1 PID Unlock required before upload accepted

Bit 11 : Set if Proprietary Unlock required before upload accepted

Bit 12 : Set if responder does not accept E1.37-X as broadcast messages

Bit 13 : reserved

Bit 14 : reserved

Bit 15 : reserved

7. Message Structure

All FTC messages shall use the standard RDM message structure as defined in [RDM].

The standard NACK responses for Format Error or Data Out of Range, as defined in [RDM] shall be used when the message construct does not comply with this document, unless specifically stated in this document.

Successful message delivery shall return a response type ACK with additional information as described in this document.

To assist with verifying the integrity of transferred file data, a number of PIDs defined in this standard use a Cyclic Redundancy Check (CRC) within the Parameter Data payload of the RDM packet.



8. Operational Overview

The FTC_NEGOTIATE PID shall be used to set up the operation.

Transfer of file data shall use the FTC_TRANSFER PID.

The FTC_VALIDATE PID shall be used to determine whether the previous stages of negotiation and transfer are complete.

The FTC_COMMIT PID shall be used to initiate re-flashing or reprogramming of hardware once the transfer has been completed and validated.

The FTC_CANCEL PID shall be used when the controller wishes to abort any transfer without proceeding to validate or commit state.

Controller and responder support for the FTC_NEGOTIATE , FTC_TRANSFER, FTC_VALIDATE FTC_COMMIT PID and FTC_CANCEL PIDs is required as noted in Table A-1

When the transfer data is intended as replacement firmware for the responder, the commit stage initiates responder reprogramming/re-flashing of code space.

An optional PID FTC_PROXY_NEGOTIATE PID allows for determination of any additional constraints when attempting to use “1:many” transfers in conjunction with Proxy Devices such as wireless DMX/RDM links.

8.1 Negotiate Transfer

Typically, responder hardware will have some design factors that determine how much data may be accepted before it can be committed to storage. Microcontrollers or other off-chip memory devices may impose a “page” size, at which point a finite time (longer than the normal inter-packet time) is required to commit data to non-volatile storage. During this time the responder may not be able to accept RDM messages, or perform normal operations.

Responders may also have memory limitations that limit the size of each RDM packet that can be received.

8.2 Transfer File Data

Files shall be uploaded to the responder by the controller (or downloaded from the responder to the controller), using an RDM packet size in accordance with characteristics obtained from the responder.

The amount of file data that can be transferred in each RDM packet shall be determined from the responder during the Negotiate stage. This amount is referred to as the Block Size. This Block Size may be different to any hardware “page” size constraints imposed by the responder. The maximum allowed Block Size is restricted by the maximum Parameter Data Length (of 231 bytes) imposed by the RDM Standard.

Thus to send a [hardware] “page” of data, it may be required to transmit one or more RDM packets.



Failure or interruption of the data transfer process, or corruption of data shall not in any way affect the subsequent operational integrity of the responder.

Data transfers are made using the FTC_TRANSFER PID.

8.3 Validate File Data

Responders shall provide a means for a controller to verify the suitability and integrity of the uploaded data in accordance with this standard. On successful validation of uploaded data, responders should maintain the integrity of the data until completion of the commit stage or the transfer process is re-initiated.

Responders unable to provide an immediate validation result shall return an ACK packet with the use of FTC_RS_ACKWAIT, rather than use the [RDM] ACK_TIMER mechanism.

Validate requests are made using the FTC_VALIDATE PID.

Controllers choosing to issue the Validate request using “1:many” transfer [Broadcast Validate] should then poll individual responders to request the result of the Validate request.

8.4 Commit File Data

Controllers using “1:1” transfers shall only issue an instruction to commit after receipt of a successful Validate response.

Controllers using “1:many” transfer of the file data should undertake a “1:1” poll with each responder that has been listening to the “1:many” transfer, to verify the result of the Validate request.

For controllers using “1:many” transfer for the Commit, the controller shall wait the designated Validate Delay time after issuance of the Validate request before issuing the instruction to commit.

For firmware uploads, the instruction to commit is the only instruction that initiates the responder self reload/reflash and reboot.

A responder shall reject any instruction to commit if it has not been asked to perform the validate process since the initial negotiate stage.

A responder shall reject any instruction to commit if it has not previously been asked to validate and has reported successful validation.

Commit Requests are made using the FTC_COMMIT PID

8.5 Resuming Communications

Controllers shall only attempt to resume communication with a responder that has successfully acknowledged the Commit request after expiry of the Commit Delay time.



9. Use of FileCRC

Where mention is made of FileCRC in this standard, the following implementation shall be followed.

The CRC, the Cyclic Redundancy Check, shall be the 16-bit remainder after division modulo 2 of the message polynomial by the generator polynomial x^16+x^12+x^5+1, calculated according to the algorithm described in Appendix G.

The calculated FileCRC shall be transmitted in Big Endian Order.

For example 0xE5CC would be transmitted as

Table 9-1 CRC Byte Order

Slot# Data

i 0xE5 Most significant byte

i+1 0xCC Least significant byte

10. Use of CRC

Where mention is made of CRC in this standard, the following implementation shall be followed.

The CRC, the Cyclic Redundancy Check, shall be the 16-bit remainder after division modulo 2 of the message polynomial by the generator polynomial x^16+x^12+x^5+1, calculated according to the algorithm described in Appendix G.

In this standard, the CRC will be calculated over the Parameter Data field of the RDM packet as indicated elsewhere in this document, excluding the CRC locations which are always the last two bytes of the Parameter Data.

The calculated CRC shall be transmitted in Big Endian Order, in accordance with the example detailed in Table 9.1

Controllers shall attempt to use data obtained from responders that do not support CRC generation, but may report such situations to their user interface or request some other means of confirmation.

11. Use of SessionID The SessionID is used to uniquely identify a file transfer session between a controller and responder. It is created by the controller and offered to the responder as part of the Negotiate stage. It is then used in the Transfer, Validate and Commit stages. The SessionID shall be in the range 0x00-0xFF and controllers should avoid re-using SessionIDs whenever possible. The method of selection is beyond the scope of this standard. SessionIDs provide several benefits:

• A responder that has been disconnected during a file transfer, and subsequently reconnected during a different transfer has a means of rejecting the data as the new transfer should have a different SessionID.



• A responder that has been relocated onto another physical data link that is in the process of transferring file data can reject the transfer.

• Controllers may group responders of similar characteristics in a “1:many” transfer session and interleave multiple sessions (using different SessionID) so that responders can identify which broadcast packets they should act upon.

Controllers that choose not to implement sessions shall set the SessionID field to 0x00, and thus cannot initiate concurrent transfers to multiple responders.

The SessionID 0xFF is reserved for use when a controller wishes to cancel all current transfers.

Responders shall verify that the SessionID for the Transfer, Validate and Commit messages match the SessionID supplied in the Negotiate message.

This standard does not support the simultaneous use of multiple file transfers to an individual responder. Such file transfers shall be performed sequentially.

12. Use of FileID

In the context of this standard the FileID is a 16bit file reference defined by the responder.

The FileID does not denote any particular type of data or file format.

Responders may elect to support one or more FileIDs, and may elect to expose details of the file type and accessibility for upload/download using PIDs defined in this standard.

Manufacturers should ensure that their use of FileIDs is consistent within their own product range. This is to allow two different products (or models) to use identical data structures.

Example : Products A and B both support 8 bit dimmer curve lookup tables. The manufacturer desires the ability to upload and download the dimmer curve data. By specifying the same FileID in both products a controller may use “1:many” transfers to upload the same dimmer curve to both products.

Example : Product A supports a finite number of user selectable image files. The manufacturer allocates separate FileIDs for each image location, allowing the user to load any library image to a specific location.

13. Replies from Responders

All replies from a responder to the FTC_NEGOTIATE, FTC_VALIDATE, FTC_COMMIT and FTC_CANCEL PIDs include the Response Status and Response Data fields.

All SET responses to the FTC_TRANSFER PID include the Response Status and Response Data fields.

GET responses to the FTC_NEGOTIATE PID use the Response Status field to report on the current state of the Negotiate/Validate/Commit cycle.

GET responses to the FTC_TRANSFER PID do NOT include the Response Status and Response Data fields and the existing [RDM] NACK handling is used to report error conditions.



13.1 Good response

The Response Status of FTC_RS_ACKOK is used to indicate successful execution of a request.

13.2 Good response – more time required

The Response Status FTC_RS_ACKWAIT informs the controller that the responder requires further time to action the SET request. The delay time is returned in the Response Data field.

Responders that choose not to allow dynamic delay control shall set this field to 0xFFFF.

The delay time returned in this field shall always be less than or equal to the corresponding times returned as part of the negotiate stage as defined in section 6.4.3 and 6.4.5 of this standard.

Controllers utilising “1:1” transfers may choose to use this time to dynamically adjust the interpacket timing, but are not obligated to do so. In the absence of any delay time reported via the FTC_RS_ACKWAIT response, a controller shall utilise the default timings provided during the Negotiate phase.

Although this has functionality similar to the use of ACK_TIMER as described in [RDM], the ACK_TIMER granularity of 100ms is considered too coarse for timely upload of data that may require less than 10ms for the data to be saved by a responder in its internal non-volatile storage.

Use of FTC_RS_ACKWAIT is not equivalent to the ACK_TIMER in so far as no use of QUEUED_MESSAGES is implied or required.

A controller utilising “1:many” transfers shall wait the required time as declared during the Negotiate stage, before continuing with any further traffic to the responder in question, as there will be no FTC_RS_ACKWAIT responses seen due to the use of Broadcast messages from the controller.

13.3 Bad Response – attempt recovery

Responders may report errors in the receipt of file data from the SET:FTC_NEGOTIATE or SET:FTC_TRANSFER PID thereby giving a controller the opportunity to resend the packet.

13.4 Fatal Errors

Responders may report fatal errors in the receipt of file data from the SET:FTC_NEGOTIATE or SET:FTC_TRANSFER PID and request that the controller abandon the transfer process.

14. Limitations It should be recognized that firmware upload is by its nature a maintenance operation and should not normally be undertaken during show performance situations. It should be recognized that responders may not be able to provide normal functionality while processing FTC requests, and are not required by this standard to do so.

It should be recognized that controllers may cease or delay generation of NULL start code packets during FTC processing.



15. PID Use and Definition

To obtain details about a possible file transfer, the controller may issue a GET: FTC_NEGOTIATE PID.

To initiate a file transfer in either direction, the controller shall issue a SET: FTC_NEGOTIATE PID.

Controllers wishing to obtain details about the transaction shall use the GET: FTC_NEGOTIATE PID.

The use of the GET: FTC_NEGOTIATE also allows collection of required transfer configuration information without preparing a responder for a new data transfer. It also allows for a controller to monitor the progress of an upload (transfer from controller to responder).

In order to best understand this procedure, this standard describes the GET first.

15.1 Obtain Transfer Details and Status (uses GET:FTC_NEGOTIATE)

This PID may be used prior to a SET: in order to determine the required transfer configuration information without preparing a responder for a new data transfer. This may be used by a controller for grouping responders that have similar requirements and thus allow the use of “1:many” data transfers using Broadcast messages.

This command obtains the same dataset as provided by the SET:Response to a SET: FTC_NEGOTIATE, but it does not tell the responder anything about a pending data transfer.

Responders shall only expect a data transfer after receipt of the SET command.

This PID may also be used to retrieve information about the progress of file transfer to one or more responders.

A Responder that is not currently processing a transfer shall return a response status of FTC_TQS_IDLE.

A responder that has been issued a SET:FTC_NEGOTIATE, but has not yet received any SET:FTC_TRANSFER messages shall return a response FTC_TQS_NEGOTIATE.

Once a responder has successfully processed a SET:FTC_TRANSFER or GET:FTC_TRANSFER PID it shall return FTC_TQS_UPLOAD or FTC_TQS_DOWNLOAD as appropriate.

Once a responder has successfully processed a SET:FTC_VALIDATE PID it shall return FTC_TQS_VALIDATE.

Once a responder has successfully processed a SET:FTC_COMMIT PID it may return FTC_TQS_COMMIT until such time as the commit has completed. Once the commit has competed, the responder shall return FTC_TQS_IDLE, noting that responders are not obligated to respond to RDM requests during the commit cycle.



Receipt of the FTC_TQS_COMMIT response by a controller after the declared commit timeout would suggest that there is something wrong with the responders processing of the commit cycle.

A responder that has for any reason abandoned the transfer process shall return FTC_TQS_ERROR.

The GET:FTC_NEGOTIATE may be used at any point mid transfer to confirm that the transfer is proceeding as expected. This may be helpful to controllers making use of “1:many” transfers, for monitoring progress.

15.1.1 Controller Request Obtain Transfer Details and Status

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_NEGOTIATE

(PDL)

0x03

(PD)

SessionID

FileID

Data Description:

Session ID (8 bit):

This shall be set to 0x00

FileID (16 bit):

This shall be set to the FileID that the controller wishes to send or receive, or wishes to obtain current transfer status for.



15.1.2 Responder : Reply to Obtain Transfer Details and Status

Responder : (GET Response)

Controllers should use this PID to ascertain the capabilities of a responder prior to initiating a transfer using the corresponding SET:, or to monitor transfer progress.

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)

Copy of Controller SD

(CC)

GET_COMMAND_RESPONSE

(PID)

FTC_NEGOTIATE

(PDL)

0x18

(PD)

Transfer Query Status

Response Data

SessionID

FileID

Capabilities Bit Field

DataOffset Upper 16bits

DataOffset Lower 16bits

Max Block Size

Inter-packet Delay

Initial Delay (16bit)

Accumulated Packet Count

Accumulated Packet Delay (16-bit)

Commit Delay

Packet CRC

The dataset returned by this GET shall be the same as that returned for a SET:Response to a SET:FTC_NEGOTIATE and as detailed in Section 15.2.1 of this standard, with the following exceptions :

Transfer Query Status

Responders shall set this field in accordance with the current transfer query status as defined in Table A-4

Controllers may use this information to recover or continue a transfer.

Response Data

A responder shall set this to 0x0000

SessionID (8bit)

Responders shall report the SessionID offered during the (SET) Negotiate stage.

Responders that have not yet been offered a SessionID shall report 0x00.

FileID:

Responders shall report the FileID offered during the (SET) Negotiate stage.

Responders that have not yet been offered a FileID shall report 0xFFFF.



Capabilities Bit Field (16 bit)

This shall be set by the responder in accordance with section 6.4.7 of this standard.

DataOffset (32bit):

The responder shall return the current file offset.

For uploads this should equate to the last offset sent by the controller in the SET plus the length of data stored by the responder. Where no data has yet been received by a responder this field shall be set to 0x00000000.

For downloads this should equate to the offset that the responder is expecting to send in the next GET transfer. Where no data has yet been sent by a responder this field shall be set to 0x00000000.

Controllers may use this information to recover or continue a transfer.

Max Block Size (8 bit): [Valid range is 16-224]

The responder shall declare the maximum number of bytes of file data to be sent in each packet.

This value shall be used by a controller to determine the maximum number of bytes of file data to send to the responder in each FTC_TRANSFER message packet.

Inter-packet Delay (8bit):

Minimum time (in ms) that the responder requires the controller to wait after each transfer of a FTC_TRANSFER packet.


Initial Delay (16bit):

Minimum time (in ms) that the responder requires the controller to wait after negotiation before the first FTC_TRANSFER packet is sent.


Accumulated Packet Count (16 bit):

This field shall be set by the responder in accordance with section 6.4.4 of this standard.

The Accumulated Packet Count shall be used by a controller to determine when to further delay packet transfers after “N” packets have been transferred to the responder. This field determines when to make use of the Accumulated Packet Delay.

Accumulated Packet Delay: (16 bit)



This parameter should be used by a controller to determine how long to wait (in ms) once the number of transmitted packets reaches the declared Accumulated Packet Count.




Commit Delay (16 bit):



This parameter should be used by a controller to determine how long to wait (in ms) once the commit request has been sent and acknowledged, before expecting the responder to resume normal operations.

Packet CRC (16 bit):

Responders that do not support Packet CRC generation shall set this field to 0x0000.

Responders that support Packet CRC in accordance with the method referenced in this standard shall apply the CRC calculation to the Parameter Data only.

15.2 Negotiate and Initiate Transfer (uses SET:FTC_NEGOTIATE)

A controller shall issue a SET: FTC_NEGOTIATE PID to inform the responder that it is about to commence file transfer using the FTC_TRANSFER PID.

When uploading, the SET: FTC_NEGOTIATE command provides information about the size of file being offered and the SET response returns details that are used by the controller to manage the upload process.

When downloading, the SET: FTC_NEGOTIATE command identifies the file being requested and the SET response returns information about the size of the available file that is used by the controller to manage the download process.

A responder shall ACK this message provided there are no RDM packet format errors in the request. In the event of such low levels errors the existing [RDM] NACK response shall be used.

The responder shall treat out of range values in the SET request differently to other [RDM] responses. It is not appropriate to use the [RDM] NACK : DATA_OUT_OF_RANGE response when replying to the SET: FTC_NEGOTIATE.

In the event that the responder detects invalid or out of range parameter data values the responder shall still ACK the request and return the error using the Response Status and Response Data fields as described in this standard.

For example, a responder that does not support the requested FileID shall reject the transfer request as specified in section 15.2.2.3 of this standard. Responders that do not wish to accept (for upload) or supply (for download) any file data shall ACK the request, and reply with an appropriate Response Status and Response Data (reason code) as described in this standard.

Responders that are rejecting a transfer negotiate request for more than one issue shall reply with a single Reason Code prioritized in the order as presented in Table A-4.

Responders implementing this standard shall reply to this PID without use of the [RDM] ACK_TIMER mechanism.



15.2.1 Controller : SET Request to Negotiate File Transfer:

Controller: (SET) Controller request to negotiate file transfer.

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

SET_COMMAND

(PID)

FTC_NEGOTIATE

(PDL)

0x1B

(PD)

SessionID

FileID

File Size upper 16 bits

File Size lower 16 bits

File Data (1st byte) File Data (2nd byte)

File Data (3rd byte) File Data (4th byte)

File Data (5th byte) File Data (6th byte)






FileCRC

Packet CRC

Data Description:

SessionID (8bit) :

The SessionID shall be issued by a controller and allows a controller to target data at groups of responders. Selection of SessionID is as defined in section 8 of this standard.

FileID (16 bit) :

The controller shall specify the FileID that relates to the file about to be sent to the responder, or to be requested from the responder.

For firmware uploads a controller shall set the FileID to 0x0000.

For any other application, the controller may determine the supported FileIDs for a particular responder by use of the GET:FTC_FILELIST PID described in this standard.

FileIDs are described in section 12 of this standard.

File Size Upper 16bits

File Size Lower 16bits

For a controller initiating an upload these fields shall be set to total file size in bytes.

For a controller requesting a download these two fields shall be set to 0x0000.

File Data (16 bytes)

For a controller initiating an upload this field shall be set to the first 16 bytes of the file.



This is to allow responders (should they wish to) to validate that the data to be transferred is in fact appropriate to the responder. In the event that the file data is less than 16 bytes, controllers shall set the remaining bytes as 0x00.

The 16byte limit in the negotiate stage is to satisfy the requirements of memory limited responders. The overall size of this PID (PDL plus RDM header) is designed to be less than 64bytes. This allows for responders which can only support small RDM packets to use this standard.

While some manufacturers may wish more data to be transferred, there is nothing in this standard that prevents manufacturers of responders rejecting the data transfer after actual transfer has commenced.

The data does not need to be stored by the responder at this point, and shall be sent again by the controller as part of the first packet transfer using the FTC_TRANSFER PID.

Responders that do not verify suitability of the data using this method are free to reject data transfers at any time during the upload process.

For a controller requesting a download this field shall be filled with 0x00.

FileCRC (16 bit) :

For a controller initiating an upload this field shall be set to the CRC of the file being offered, in accordance with the method referenced in section 9 of this standard

For a controller requesting a download this field shall be set to 0x0000.

PacketCRC (16 bit) :

This field shall be set to a CRC in accordance with the method referenced in section 10 of this standard for calculating a CRC for the Parameter Data contained within the current packet.



15.2.2 Responder : Generic response

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)

SET_COMMAND_RESPONSE

(PID)

FTC_NEGOTIATE

(PDL)

0x18

(PD)

Response Status

Response Data

SessionID

FileID


DataOffset Upper 16bit / FileSize Upper 16bit

DataOffset Lower 16bit / FileSize Lower 16bit

Max Block Size

Inter-packet Delay

Initial Delay (16bit)



Commit Delay / FileCRC

Packet CRC

15.2.2.1 Responder : Negotiate OK : Provide Transfer Requirements

A responder that is OK to service the transfer request shall reply with the details outlined in this section. These provide the controller with the information necessary to proceed with and manage the file transfer.

Data Description:

Response Status (8 bit):

This field shall be set to FTC_RS_ACKOK.

Response Status values are enumerated in Table A-2

Response Data (16 bit):

This field shall be set to FTC_RDNRC_NULL

Response Data varies dependent on the entry in the Response Status field, as enumerated in Table A-3

SessionID (8bit)

The SessionID is issued by a controller and allows a controller to target data at groups of responders.

A responder shall return the SessionID as offered by the controller.

Responders are required to keep the SessionID for use in accepting subsequent transfer packets and for the validation and commit stages.

FileID (16 bit):

The FileID is issued by a controller and selects the data the controller wishes to transfer or request.



If the requested FileID is supported by the responder, the responder shall return the FileID.

If the responder does not support the requested FileID it shall set this field to 0xFFFF.

The responder shall also declare the ability to accept and or supply the requested FileID using the designated bits in the Capabilities Bit Field as described below.

Responders are required to keep the FileID for use in the validation and commit stages.



DataOffset (32bit):

A responder asked to initiate a file upload shall set this field to 0x00000000.

This indicates that the responder is expecting to transfer data from the beginning of the file.

A responder asked to initiate a file download shall set this field to the total file size in bytes of the responder’s requested file.

Max Block Size (8 bit):

[Valid range is 16-224]


This value shall be used by a controller to determine the maximum number of bytes of file data to send to the responder in each FTC_TRANSFER packet.


Minimum time (in ms) that the responder requires the controller to wait after each transfer of a FTC_TRANSFER packet.


Initial-Packet Delay (16bit):

Minimum time (in ms) that the responder requires the controller to wait before the first transfer of a FTC_TRANSFER packet.












Commit Delay (16 bit) / FileCRC:

A responder asked to accept a file upload shall set this field with the Commit Delay in accordance with section 6.4.6 of this standard.



A responder asked to initiate a file download should set this field to the FileCRC of the responder’s requested file in accordance with the method referenced in section 10.

Responders that do not support FileCRC generation shall set this field to 0x0000.

Packet CRC (16 bit):

Responders that do not support Packet CRC generation shall set this field to 0x0000.

Responders that support Packet CRC shall do so in accordance with the method referenced in section 10 of this standard.

15.2.2.2 Responder : Negotiate Fail : Error in Packet CRC

A responder that supports the use of CRC and determines a Parameter Data CRC mismatch shall reject the negotiate request.

Responder : (SET Response) : There is a mismatch in the Parameter data CRC.

Data Description:


This field shall be set to FTC_RS_NACK.

Response Status values are enumerated in Table A-2


This field shall be set to FTC_RDNRC_PACKET_CRC_ERROR as defined in Table A-5

Response Data varies dependent on the entry in the Response Status field, as detailed in Table A-3

Remaining fields, with the exception of the Packet CRC field shall be filled with zeros.

Responders that support Packet CRC shall do so in accordance with the method referenced in section 10 of this standard. Responders that do not support Packet CRC generation shall set the Packet CRC field to 0x0000.



The controller may resend the request. If the controller chooses not to resend the negotiate request it shall abandon the upload process in accordance with the procedure described in section 15.3 of this standard.

We could have allowed that in this case the controller is not required to abandon the upload in accordance with section 15.3, as the responder should still be in the TRANSFER IDLE state, but probably better for controllers to be able to treat all NACK CRC errors in the same manner.

If, after issuing three successive SET: FTC_NEGOTIATE requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall regard the transfer as a failure and abandon the upload process.

A responder that has repeatedly sent this reply may elect to abandon the transfer process and reply with FTC_RS_FATALERROR, rather than FTC_RS_NACK.

15.2.2.3 Responder : Negotiate Fail : Reject FileID

A responder that does not support the requested FileID shall reject the negotiate request using this response.

Response : (SET Response) Responder does not support offered FileID

Data Description:


This field shall be set to FTC_RS_FATALERROR.


This field shall be set to FTC_RDNRC_UNSUPPORTED_FILEID.



15.2.2.4 Responder : Negotiate Fail : Reject due to E1.37 Lock Mechanism.

A responder that cannot currently support the requested transfer because of a lock or write protect system as controlled by the lock PIDs described in E1.37 shall reject the negotiate request using this response.

Controllers in receipt of this response are advised to provide some means of user warning or dialog. The means of unlocking and continuing the transfer are outside the scope of this standard.

Response : (SET Response) Responder does not support offered FileID



Data Description:




This field shall be set to FTC_RDNRC_E137LOCKACTIVE.



15.2.2.5 Responder : Negotiate Fail : Reject due to Other Lock Mechanism.

A responder that cannot currently support the requested transfer because a proprietary lock or other write protect system is active, shall reject the negotiate request using this response.

Controllers in receipt of this response are advised to provide some means of user warning or dialog. The means of unlocking and continuing the transfer are outside the scope of this standard.

Response : (SET Response) Responder cannot accept file due to active proprietary lock.

Data Description:




This field shall be set to FTC_RDNRC_OTHERLOCKACTIVE.



15.2.2.6 Responder : Negotiate Fail : Reject File Content

A responder that wishes to reject the file transfer on the basis of the content of the first 16 bytes of the file (as offered by the controller) shall reject the negotiate request using this response.

Response : (SET Response) Responder does not accept offered File data content.

Data Description:




This field shall be set to FTC_RDNRC_NOT_COMPATIBLE.





15.2.2.7 Responder : Negotiate Fail : Any other reason

A responder that wishes to reject the file transfer on the basis of any other reason shall reject the negotiate request using this response.

Response : (SET Response) Responder does not support transfer (Unknown Error).

Data Description:




This field shall be set to FTC_RDNRC_UNDEFINED_ERROR.





15.3 Abandon a Transfer (uses SET:FTC_CANCEL)

A controller that wishes to cancel transfer of data may issue a SET:FTC_CANCEL and the file transfer process shall be abandoned by the target responder(s), based on the specified SessionID and FileID.

After successful processing of a SET:FTC_CANCEL request, a responder shall return a status of FTC_TQS_IDLE to any GET:FTC_NEGOTIATE requests.

15.3.1 Controller : SET Request to Cancel:

Controller: (SET) Controller Request to cancel transfer.

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200 or 0xFFFF

(CC)

SET_COMMAND

(PID)

FTC_CANCEL

(PDL)

0x03

(PD)

SessionID

FileID

Data Description:

SessionID (8bit) :

The controller shall set this to the SessionID relating to the transfer that it wishes to cancel.

Controllers that do not support multiple transfer sessions shall set this field to 0x00.

Controllers that wish to cancel a responder from any current transfers, without reference to a specific SessionID shall set this field to 0xFF.

FileID (16 bit) :

The controller shall specify the FileID that relates to the data transfer it wishes to cancel.

Responders shall cancel the current transfer based on the SessionID and FileID.

If the SessionID is 0xFF responders shall cancel the current transfer irrespective of the FileID offered by the controller.



15.3.2 Responder : Generic SET Response

Responder Response .

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_CANCEL

(PDL)

0x03

(PD)

Response Status

Response Data

15.3.2.1 Responder : Cancel request : Accept

Responder Response : Request to Cancel has completed successfully.

Data Description:


This field shall be set to FTC_RS_ACKOK.


This field shall be set to FTC_RDNRC_NULL.

15.3.2.2 Responder : Cancel request : Error in PacketCRC

Responder Response : Request to Cancel cannot be confirmed as there is a PacketCRC error in the request.

Data Description:




This field shall be set to FTC_RDNRC_PACKET_CRC_ERROR.

15.3.2.3 Responder : Cancel request : Error in SessionID

Responder Response : Request to Cancel cannot be actioned as the responder is not listening to requested SessionID.

Data Description:




This field shall be set to FTC_NRC_STREAM_ID_MISMATCH.

The controller may resend the request with the required SessionID.



If, after issuing three successive SET: FTC_CANCEL requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall cancel the transfer by setting the requested SessionID to 0xFF.

A responder that has repeatedly sent this reply may elect to abandon the transfer process and reply with FTC_RS_FATALERROR.

15.3.2.4 Responder : Cancel request : Error in FileID

Responder Response : Request to Cancel cannot be actioned as the responder is not transferring the requested FileID.

Data Description:




This field shall be set to FTC_NRC_ UNSUPPORTED_FILEID.

The controller may resend the request with the required FileID.

If, after issuing three successive SET: FTC_CANCEL requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall stop issuing cancel requests.

15.4 Validate File Data (uses SET/GET FTC_VALIDATE)

This command shall be used once all data has been uploaded, to instruct a responder to validate the entire upload. This step must be completed in preparation for the responder to action any commit command.

If the data validation result is not immediately available, the responder shall return an FTC_RS_ACKWAIT and the controller shall issue a GET: FTC_VALIDATE after expiry of the appropriate wait time as determined by the response to the SET.

If, after issuing three successive GET: FTC_VALIDATE requests, the responder is still returning an FTC_RS_ACKWAIT response, the controller shall regard the transfer as having failed and abandon the upload process.

It is recommended that a responder write protect the data at this point if it has not already done so to minimise risk of corruption prior to the commit stage.

15.4.1 Controller : SET Request to Validate Transfer

Controller: (SET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) ) – 0x0200 or 0xFFFF

(CC)

SET_COMMAND

(PID)

FTC_VALIDATE

(PDL)

0x03

(PD)



SessionID

FileID

Data Description:

SessionID (8bit) :

The controller shall set this to the SessionID relating to the transfer that it has completed and now wishes the responder to validate.

Controllers that choose not to implement SessionID shall set the SessionID field to 0x00

FileID (16 bit) :

The controller shall specify the FileID that relates to the transfer that it has completed and now wishes the responder to validate.


Set as calculated in accordance with section 10 of this standard.

Responders receiving this message as a broadcast shall ignore this request if the SessionID and FileID do not match the values from the negotiate request. Under such circumstances responders should continue listening for a message with matching values.


The responder shall send this reply when the SessionID and FileID have been checked and the integrity of the file data has been confirmed.

The actual method of determining the integrity of the file is beyond the scope of this standard.

Responder Response : Validation has been requested and has completed successfully.

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_VALIDATE

(PDL)

0x03

(PD)

Response Status

Response Data

15.4.2.1 Responder : Validate Request : Validation OK

The responder shall send this reply when the SessionID and FileID have been checked and the integrity of the file data has been confirmed.

The actual method of determining the integrity of the file is beyond the scope of this standard.

Responder Response : Validation has been requested and has completed successfully.

Data Description:




Responder shall set to FTC_RS_ACKOK.


Responder shall set to FTC_RDNRC_NULL.

The controller may now proceed to the commit stage.

15.4.2.2 Responder : Validate Request : Error in PacketCRC

This error relates to a CRC error in the SET request, and does not apply to CRC errors detected as part of the validation of the transferred file data.

Responder Response: Validation has been requested and there is a PacketCRC error in the request.

The responder shall respond with the Response Status and Response Data set to indicate failure of the validate stage.

Data Description:


Responder shall return as Set to FTC_RS_NACK.


Responder shall set to FTC_RDNRC_PACKET_CRC_ERROR.

The controller shall NOT proceed to the commit stage.

The controller may resend the request. If the controller chooses not to resend the validate request it shall abandon the upload process in accordance with section 15.3 of this standard.

If, after issuing three successive SET: FTC_VALIDATE requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall regard the transfer as a failure and abandon the upload process.


15.4.2.3 Responder : Validate Request : No data transferred

Responder Response: Validation has been requested without any data transfer.

Data Description:


Responder shall set to FTC_RS_NACK.


Responder shall set to FTC_RDNRC_MODAL_ERROR.




15.4.2.4 Responder : Validate Request : Result not available yet

Responders may require time to validate the entire file after it has been transferred. While it is possible that the validation checks may be pre-empted on receipt of the last FTC_TRANSFER packet, there may be some situations where the responder does not have the validation result immediately available for the controller.

Responder Response: Validation has been requested but is not yet available – please wait

The responder shall respond with the Response Status and Response Data set to indicate the recommended wait time.

Data Description:


Responder shall set to FTC_RS_ACKWAIT.


Responder shall return a value to indicate the remaining wait time in ms.

Valid range is 0x0000-0xFFFF (0-65535ms).

The controller shall try again after the wait time has expired, using a GET request as outlined in section 15.4.3 of this standard. A controller should only proceed to the commit stage in accordance with the response outlined in section 15.4.4.1 of this standard.

If the Response Data is 0x0000 the controller may try again using GET: FTC_VALIDATE but is not obligated to do so.

15.4.2.5 Responder : Validate Request : Error in SessionID

Responder Response: Validation has been requested but SessionID does not match transfer.

The responder shall respond with the Response Status and Response Data set to indicate a SessionID mismatch.

Data Description:




Responder shall set to FTC_NRC_STREAM_ID_MISMATCH.


The controller may resend the request with the required SessionID. If the controller chooses not to resend the validate request it shall abandon the upload process in accordance with section 15.3 of this standard.



If, after issuing three successive SET: FTC_VALIDATE requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall regard the transfer as a failure and abandon the upload process.


15.4.2.6 Responder : Validate Request : Error in FileID

Responder Response: Validation has been requested and FileID is not supported.


Data Description:


Responder shall return as Set to FTC_RS_FATALERROR


Responder shall set to FTC_RDNRC_UNSUPPORTED_FILEID.


Both the controller and responder shall abandon the upload process. The controller is not required to issue any cancellation request.

15.4.2.7 Responder : Validate Request : Validation Failure

This is the error situation where the SessionID, FileID and CRC of the request are all OK, but the FileCRC check of the entire file OR some other check of the file integrity (as determined by the manufacturer) indicates that the file is unable to be used.

Responder Response: Validation has been requested and is not successful.


Data Description:




Responder shall set to FTC_RDNRC_VALIDATION_ERROR.



15.4.2.8 Responder : Validate Request : Any other reason

A responder that wishes to reject the validation request on the basis of any other reason shall reject the request using this response.





Data Description:




Responder shall set to FTC_RDNRC_VALIDATION_ERROR.



15.4.3 Controller : GET Request to Validate Transfer

The use of a GET: FTC_VALIDATE does not initiate the validate process. It may only be used to establish the validation state of the responder.

The use of GET: FTC_VALIDATE is not required if the responder has successfully confirmed a valid transfer as part of the SET_COMMAND_RESPONSE to the SET: FTC_VALIDATE message.

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_VALIDATE

(PDL)

0x03

(PD)

SessionID

FileID

Data Description:

SessionID (8 bit):

FileID (16 bit):

15.4.4 Responder : Generic GET Response

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_VALIDATE

(PDL)

0x03

(PD)

Response Status

Response Data



15.4.4.1 Responder : Validate Request : Validation OK

Responder Response : Validation has already been requested and has completed successfully.

Data Description:


Responder shall set to FTC_RS_ACKOK.


Responder shall set to FTC_RDNRC_NULL

This response confirms that a controller has already issued a SET:FTC_VALIDATE and that is has been successfully processed by the responder.

The controller may now proceed to the commit stage.

15.4.4.2 Responder : Validate Request : No (SET) Request made

Responder Response: Data validation has not yet been requested.

Data Description:




Responder shall set to to FTC_RDNRC_MODAL_ERROR.

The controller shall NOT proceed to issue a SET:FTC_COMMIT request

Responders that choose to process validation “on the fly”, or automatically at the conclusion of the file transfer shall still be required to process the SET:FTC_VALIDATE message before they can report the result of the validation stage.

15.4.4.3 Responder : Validate Request : Result not available yet

Responder Response: Data validation has been requested but is not yet available

The responder shall respond with the Response Status and Response Data set to indicate that a result is still not yet available.

Data Description:


The responder shall set to FTC_RS_ACKWAIT.


Responder should set to indicate the remaining validation wait time in ms.

Responders unable to calculate the remaining time shall return the original validation wait time.



Valid range is 0x0000-0xFFFF [0-65535ms].


The controller shall try again after the wait time has expired and not before.

If, after issuing three successive GET: FTC_VALIDATE requests, a controller finds the responder is still responding with an FTC_RS_ACKWAIT response, the controller shall regard the transfer as a failure and abandon the upload process using the method described in section 15.3.1

When the remaining validation time has expired, the responder should only be replying with either Validation OK (as per section 15.4.4.1 of this standard) or Validation Failure (as per section 15.4.4.4 of this standard).

15.4.4.4 Responder : Validate Request : Validation failure.

This is the error situation where the SessionID, FileID and PacketCRC of the request are all OK, but the FileCRC check of the entire file OR some other check of the file integrity (as determined by the manufacturer) indicates that the file is unable to be used.


Data Description:


Responder shall set to FTC_RS_FATALERROR


Set to FTC_RDNRC_VALIDATION_ERROR.

The controller shall NOT proceed to issue a SET:FTC_COMMIT request.




15.5 Commit Data (uses SET:FTC_COMMIT)

A SET:FTC_COMMIT shall be used by a controller to instruct a responder to re-program itself from the uploaded data.

A controller shall only issue this command following the successful receipt of FTC_RS_ACKOK following issuance of a SET:FTC_VALIDATE, or a subsequent GET:FTC_VALIDATE.

Responders receiving a SET:FTC_COMMIT prior to issuance of a successful validation response (by the responder) shall report a Modal error in accordance with section 15.5.2.3

Responders shall ensure that a response to the SET:FTC_COMMIT is issued prior to commencement of any firmware reload or re-flash that results in the responder going off-line.

Controllers shall expect that, following receipt of a good response to the commit, the responder will go off-line and may not necessarily re-appear with the same RDM UID. It may be necessary to run a discovery process before further communications with the responder(s) are possible.

15.5.1 Controller : SET Request to Commit Data

Controller: (SET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

SET_COMMAND

(PID)

FTC_COMMIT

(PDL)

0x03

(PD)

SessionID

FileID

Data Description:

SessionID (8bit) :

The controller shall set this to the SessionID relating to the transfer that has been validated and it now wishes to commit.

Controllers that choose not to implement SessionID shall set the SessionID field to 0x00

FileID (16 bit) :

The controller shall specify the FileID that relates to the transfer that has been validated and it now wishes to commit.






(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_COMMIT

(PDL)

0x03

(PD)

Response Status

Response Data

15.5.2.1 Responder : Commit Data Request : OK – Responder commit will start

Responder Response : Commit has been requested and Responder will start commit stage.

The responder shall respond with the Response Status and Response Data set to indicate success and the estimated commit time.

Data Description:


Responder shall set to FTC_RS_ACKWAIT.


Responder shall return a value to indicate the estimated commit time in ms.


The process of transfer is complete.

Note that in the event that the committed file transfer results in a firmware reload, the responder will most likely go off-line and may not necessarily re-appear with the same RDM UID. It may be necessary to repeat a discovery process before further communications with the responder are possible.

A controller shall not attempt to communicate with the responder during the estimated commit time.

15.5.2.2 Responder : Commit Data Request : Error in PacketCRC

Responder Response : Commit has been requested and Responder cannot commit.

The responder shall respond with the Response Status and Response Data set to indicate the failure.

Data Description:


Responder shall set this field to FTC_RS_NACK.


Responder shall report FTC_RDNRC_PACKET_CRC_ERROR



The controller may resend the request. If the controller chooses not to resend the commit request it shall abandon the upload process in accordance with section 15.3 of this standard.

If, after issuing three successive SET: FTC_COMMIT requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall regard the transfer as a failure and abandon the upload process in accordance with section 15.3 of this standard.


15.5.2.3 Responder : Commit Data Request : Missing Validation Request

This response shall be used when the responder receives a request to commit prior to a request to validate.



Data Description:




Responder shall report FTC_RDNRC_MISSING_VALIDATION.

The process of transfer is not complete.

The controller may try again by issuing a SET validation request in accordance with section 15.4.1 of this standard.


15.5.2.4 Responder : Commit Data Request : Modal Error

This response shall be used when the responder has received a request to validate, and then receives a request to commit prior to the validation process having being completed. Had the controller enquired, using a GET request to validate transfer, the responder would still be returning “Result not available yet”.

Responder Response : Commit has been requested, Responder has uncompleted validation.


Data Description:






Responder shall report FTC_RDNRC_MODAL_ERROR.



15.5.2.5 Responder : Commit Data Request : Error in SessionID



Data Description:




Responder shall report FTC_RDNRC_SESSIONID_MISMATCH


The controller may resend the request with the required SessionID. If the controller chooses not to resend the commit request it shall abandon the upload process in accordance with section 15.3 of this standard.

If, after issuing three successive SET: FTC_COMMIT requests, a controller finds the responder is still responding with an FTC_RS_NACK response, the controller shall regard the transfer as a failure and abandon the upload process in accordance with section 15.3 of this standard.


15.5.2.6 Responder : Commit Data Request : Error in FileID



Data Description:


Responder shall set this field to FTC_RS_FATALERROR.


Responder shall report FTC_RDNRC_UNSUPPORTED_FILEID.




15.5.2.7 Responder : Commit Data Request : Validation Failure

This is the case when the controller asks for a commit even after the responder has failed to successfully validate the data. It would suggest an error in the controller implementation, as the controller should already have abandoned the transfer in such situations.



Data Description:




Responder shall report FTC_RDNRC_VALIDATION_ERROR.

The controller shall abandon the upload process. The controller is not required to issue any cancellation request.

15.5.2.8 Responder : Commit Data Request : Write Protect Fail

This is the case when the controller asks for a commit but the commit cannot take place because of some write protection scheme.

The controller may attempt to unlock the responder and retry the commit. The method of unlock may be manufacturer specific and is beyond the scope of this standard.



Data Description:




Responder shall report FTC_RDNRC_WRITE_PROTECTED.


15.5.2.9 Responder : Commit Data Request : Other Failure

A responder that wishes to reject the commit request on the basis of any other reason shall reject the request using this response.





Data Description:




Responder shall report , FTC_RDNRC_UNDEFINED_ERROR.

The controller shall abandon the upload process. The controller is not required to issue any cancellation request.



15.5.3 Controller : GET Request to Commit Data

Use of GET: FTC_COMMIT is not supported in this standard.

Responders shall treat such requests as errors using NRC_UNSUPPORTED_COMMAND_CLASS in accordance with [RDM].



15.6 Transfer Data (uses GET/SET FTC_TRANSFER)

This parameter is used to transfer data from/to a responder.

The SET command class is used by a controller to upload file data to a responder.

The GET command class is used by a controller to download file data from a responder.

Responders may choose not to implement support for the GET if they do not want firmware or other data to be downloadable to the controller. Responders that do not support the GET shall NACK the request and report UNSUPPORTED_COMMAND_CLASS in accordance with [RDM].

Responders may choose to reject a SET command if it is received before a SET: FTC_NEGOTIATE has been processed by the responder.

In order to best understand the application of this standard to the firmware upload procedure, this document describes the SET first.



15.6.1 Sending Data TO a Responder

Controller: (SET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200 or 0xFFFF

(CC)

SET_COMMAND

(PID)

FTC_TRANSFER

(PDL)

0x07- 0xE7

(PD)

SessionID

DataOffset Upper 16bit

DataOffset Lower 16bit

Data (0-224 Bytes)

PacketCRC

Controllers shall use the Block Size returned by the responder during the negotiate stage to determine the number of data bytes to be sent in each packet.

Controllers shall use the Initial-packet Packet delay values returned by the responder during the negotiate stage to control the time between the Negotiate packet and the first packet sent using the FTC_TRANSFER PID.

Controllers shall use the inter-packet Packet delay values returned by the responder during the negotiate stage to control the time between each packet sent.

Where a responder has declared a non zero Accumulated Packet Count and non zero Accumulated Packet Delay as part of the negotiate stage, the controller shall use these values in lieu of the inter-packet delay after every N packets where N = Accumulated Packet Count.

SessionID (8 bit) :

The SessionID is issued by a controller and allows a controller to target data at groups of responders.

The controller shall set this to the SessionID generated at the time of the negotiate stage and as defined in section 8.

Responders shall reject the packet if the SessionID does not match that offered by the controller during the negotiate stage.

DataOffset (32bit) :

The Controller shall indicate the byte offset within the file for the data in this packet. This shall be used by the responder to store the data.

Data:

This field contains the data being transferred from the controller to the responder. The length of the data may be the Max Block Size for each packet sent, with the exception of the final packet where the length will be less than or equal to the Max Block Size.





15.6.2 Responder : Generic Response

Response: (SET:Response)

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_TRANSFER

(PDL)

0x07

(PD)

Response Status

Response Data



15.6.2.1 Responder : Data accepted : OK to continue

Data Description:


Responder shall set this field to FTC_RS_ACKOK


Responder shall return a value of FTC_RDNRC_NULL

DataOffset (32bit):

The responder shall return the next expected file offset. This should equate to the offset sent by the controller in the SET plus the length of data stored by the responder.

The controller may verify the expected and actual offsets in order to determine successful processing of the packet by the responder.

15.6.2.2 Responder : Data accepted : WAIT before continue

The responder shall respond with the Response Status and Response Data set to indicate successful transfer but a requirement for the controller to delay before continuing.

The use of this response should not normally be required if the responder has correctly declared its delay characteristics in the negotiate stage. It is beyond the scope of this standard to require controllers to support dynamic delay timing.

Although this has functionality similar to the use of ACK_TIMER as described in [RDM], the ACK_TIMER granularity of 100ms is considered too coarse for timely upload of data that may require less than 10ms to be saved by a responder in its internal non-volatile storage.

Use of FTC_RS_ACKWAIT is not equivalent to the ACK_TIMER in so far as no use of QUEUED_MESSAGES is implied or required.



Data Description:


Responder shall set this field to FTC_RS_ACKWAIT


Responder shall return a value to indicate the wait time in ms.


Controllers shall wait the specified time in addition to any inter-packet delay before continuing with the next FTC_TRANSFER packet.

DataOffset (32bit):

The responder shall return the next expected file offset. This should equate to the offset sent by the controller in the SET plus the length of data stored by the responder.

The controller may verify the expected and actual offsets in order to determine successful processing of the packet by the responder.

15.6.2.3 Responder : Data rejected : Resend Packet

Response: (SET:Response) Good response – data transfer rejected – resend data


Data Description:


Responder shall set this field to FTC_RS_NACK


Responder shall report FTC_RDNRC_PACKET_CRC_ERROR, or FTC_RDNRC_UNDEFINED_ERROR.

DataOffset (32bit):

The responder shall return the offset into the file sent by the controller.


A Controller may elect to resend the packet or abandon the transfer. A controller shall limit resends to a maximum of three attempts for any one packet.

In the event that the Controller decides to abandon the transfer (received error code or resend count exceeded), it shall do so in accordance with section 15.3



15.6.2.4 Responder : Data rejected : Abandon Transfer

Response: (SET:Response) Good response – data transfer rejected – abandon transfer

There may be several reasons why a responder rejects a data transfer from a controller.

Data Description:




Responder shall report one of :

FTC_RDNRC_SESSIONID_MISMATCH, FTC_RDNRC_UNSOLICITED_TRANSFER, FTC_RDNRC_INTERNAL_ERROR, FTC_RDNRC_MODAL_ERROR, FTC_RDNRC_WRITE_PROTECTED, FTC_RDNRC_UNDEFINED_ERROR as deemed appropriate by the responder.

DataOffset (32bit):

The responder shall return 0x00000000.

The process of transfer is terminated. The controller is not required to issue any cancellation request.



15.6.3 Obtaining Data FROM a Responder

Controllers requiring data from a responder using this standard shall first issue a GET: FTC_FILELIST PID to establish the available FileIDs.

Controllers should make some allowance for the user to select the required FileID for download.

A controller shall then issue a SET: FTC_NEGOTIATE PID in order to establish the download session.

When there are multiple packets of data to transfer from a responder to the controller, responders shall use the mechanism described in this standard and not the ACK_OVERFLOW mechanism described in [RDM].

With the ACK_OVERFLOW scheme described in [RDM], controllers can simply concatenate the received Parameter Data from successive packets. This is not appropriate when obtaining data from the responder as described here, due to the additional SessionID and DataOffset header information contained within the Parameter data.

Controllers shall continuing issuing the GET: FTC_TRANSFER until the end of the file has been reached or the transfer aborted by receipt of an error response.

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_TRANSFER

(PDL)

0x05

(PD)

SessionID



SessionID (8bit) :

The SessionID shall set to the value determined by the controller as part of the negotiate stage.


Controllers shall start the download by setting the offset to 0x00000000 on the first request.

Subsequent requests shall increment the offset by the length of the received data.

A controller may determine the end of file has been reached by comparing the adjusted data offset to the file size obtained from the responder as part of the negotiate stage. Alternatively the controller may issue GET: FTC_TRANSFER until the responder returns a packet with no embedded data.

In the even that a controller detects a CRC error in the response, the controller may re-request the same packet by not incrementing the DataOffset.

Controllers shall limit re-requests to a maximum of three.



The number of bytes returned per packet is determined by the responder.

15.6.3.1 Responder : Reply with data or end of file

Response: (GET Response) Good response - Responder has data to transfer or has reached end of file.

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_TRANSFER

(PDL)

0x07- 0xE7

(PD)

SessionID



Data [0-224 bytes]

PacketCRC

SessionID (8bit) :

The Responder shall echo the SessionID as per the controller request.


The Responder shall indicate the file offset of the data being returned in this packet.

Data (0-244bytes)

This field contains the data being transferred from the responder to the controller. The length of the data is calculated by subtracting 0x07 from the PDL. Note that this length may be zero in which case this field is effectively absent and the CRC follows the DataOffset.

Such a condition shall be interpreted by a controller as indicating end of file.

PacketCRC (16 bit):

Calculated by a responder and shall include the SessionID, DataOffset and Data (where present).

Responders that do not support CRC generation shall set this field to 0x0000.

Responders shall use this same response if there is no data available for the requested file.

15.6.3.2 Responder : Error condition

Response: (GET Response) Error response – Invalid SessionID or DataOffset

(Response Type)

NACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_TRANSFER

(PDL)

0x02

(PD)

NACK Reason Code (as per [RDM]) 16bit



A responder that detects an invalid SessionID or DataOffset beyond end of file shall report NACK and NR_DATA_OUT_OF_RANGE in accordance with [RDM].



15.7 Obtain Proxy Device Transfer Details (uses GET:FTC_PROXY_CAPABILITIES)

This PID may be used to retrieve information about a Proxy Device

Internal limitations of a Proxy Device may impact the efficient throughput of file transfers to one or more responders when using “1:many” transfers and Broadcast packets.

Controllers should use this PID to ascertain the capabilities of a Proxy Device prior to initiating any transfers using “1:many” Broadcast packets.

The requirements of the Proxy Device shall be used in conjunction with those of the target responder(s) to determine the optimal inter-packet delay, validate and commit delay.

15.7.1 Controller Request Fetch Proxy Device Capability

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000 (Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_PROXY_CAPABILITIES

(PDL)

0x00

(PD)

15.7.2 Responder : Reply to Fetch Proxy Device Capabilities

Responder : (GET Response)

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_PROXY_ CAPABILITIES

(PDL)

0x0A

(PD)


Max Block Size

Inter-packet Delay



Commit Delay


This shall be set by the responder acting as a Proxy Device in accordance with section 6.4.7 of this standard.

Max Block Size (8 bit): [Valid range is 16-224]

The responder acting as a Proxy Device shall declare the maximum number of bytes of file data to be sent in each packet.



This value shall be used by a controller, in conjunction with those obtained from the target responders, to determine the maximum number of bytes of file data to send to the responders in each FTC_TRANSFER message packet.

Manufacturers of Proxy Devices are encouraged NOT to limit this below 224 wherever possible.


Minimum time (in ms) that the responder acting as a Proxy Device requires the controller to wait after each transfer of a FTC_TRANSFER packet.

This shall be set by the Proxy Device in accordance with section 6.4.3 of this standard.









Commit Delay (16 bit):




15.8 GET File_LIST (FTC_FILELIST)

This PID is used to obtain further details about a responders file transfer capabilities.

Responder support for this PID is optional. Responders that only support firmware upload (and not firmware download) are not required to implement this PID.

Responders that currently have no files of the requested type may respond with a successful response with no parameter data.

Controllers should be aware that the list of available files may change over time.



15.8.1 Controller Request for File List.

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000(Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_FILELIST

(PDL)

0x01

(PD)

File Type Requested

File Type : (8bit)

File type to obtain the file list of the designated file type.

File Types are enumerated in Table A-7 and may be added to from time to time.

Refer website for additional File Types. Needs proper reference here.

To request details for all supported files the controller shall set the File Type requested to FTC_TYP_ALL



15.8.1.1 Responder : Reply with File List

Response: (GET:Response) Good response – File List available

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_FILELIST

(PDL)

0x00-0xE7

(PD)

File 1

File Type (byte)

FileID (16bit)

Capabilities (bit field)



FileCRC

File 2

File Type (byte)

FileID (16bit)




FileCRC

File n

File Type (byte)

FileID (16bit)




FileCRC

File Type:

File Types are enumerated in Table A-6

Controllers that receive File Types that are unknown to them should use the GET:FTC_FILETYPE_DESCRIPTION PID in order to display a description of the file type.

FileID :

The FileID is the unique 16bit file reference defined by the responder.

Responders shall reserve FileID 0x0000 for firmware transfers. Responders may elect to report FileID 0x0000 under File Type FTC_TYP_FIRMWARE in this list.

Controllers may attempt to load FileIDs that have not explicitly been declared by a responder in this list.

Where a responder supports user defined files, it shall report a FileID even if there not yet any file data stored within the responder. A responder supporting N user defined files shall reply with N unique FileIDs.



A responder that has more File List data than can be packed within a single response shall make use of the ACK_OVERFLOW mechanism as described in [RDM].

Capabilities :


FileSize :

The responder shall set these fields to total file size in bytes.

FileCRC:

The responder shall set this field to the calculated file CRC.

Responders that do not support CRC generation shall set this to 0x0000.

The number of FileIDs per packet may be determined by dividing the PDL by 11.

15.8.1.2 Responder : File Type not supported

Response: (GET:Response) Bad response – File Type not supported

(Response Type)

NACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_FILELIST

(PDL)

0x02

(PD)

[RDM] Nack Reason Code

Responders that do not support the requested File Type shall NACK the request with a NR_DATA_OUT_OF_RANGE reason code in accordance with [RDM]

15.8.1.3 Responder : No files available

Response: (GET:Response) Good response – Empty file list for File Type

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)

FTC_FILELIST

(PDL)

0x00

(PD)

Responders that currently have no files of the requested type shall respond with ACK and no parameter data.

Responders that in principle support files of a particular type, but do not have any available at the time of the controller request shall reply in this manner.

This is like saying “I support error logs (FTC_TYP_ASCII_LOGFILE) but there are none at present”



15.9 GET FileType_DESCRIPTION (FTC_FILETYPE_DESCRIPTION)

This PID is used to obtain further description of the responders supported File Type.

15.9.1 Controller Request for FileType Description

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000(Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_FILETYPE_DESCRIPTION

(PDL)

0x01

(PD)

FileType Requested

File Type : (8bit)

File type to obtain the file list of the designated file type.

File Types are enumerated in Table A-6 and may be added to from time to time.

Controllers shall not use FTC_TYP_ALL with this PID

15.9.1.1 Responder : Reply with FileType Descriptive Text

Response: (GET:Response) Good response – FileType supported

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)


(PDL)

0x01-0x21

(PD)

FileType

File Type Description 0-32 characters

File Type(8bit):

The responder shall echo the requested File Type.

File_Type_Description (0-32 Characters):

Text to describe the File_Type

15.9.1.2 Responder : FileType not supported

Response: (GET:Response) Bad response – File Type not supported



(Response Type)

NACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)


(PDL)

0x02

(PD)


Responders that do not support the requested File Type shall NACK the request with a NR_DATA_OUT_OF_RANGE reason code in accordance with [RDM]

15.10 GET File_DESCRIPTION (FTC_FILE_DESCRIPTION)

This PID is used to obtain further description of the responders supported FileID.

15.10.1 Controller Request for File Description

Controller: (GET)

(Port ID)

0x01-0xFF

(Message Count)

0x00

(Sub-Device)

0x0000(Root) – 0x0200

(CC)

GET_COMMAND

(PID)

FTC_FILE_DESCRIPTION

(PDL)

0x02

(PD)

FileID

FileID:


15.10.1.1 Responder : Reply with FileID Descriptive Text

Response: (GET:Response) Good response – FileID supported

(Response Type)

ACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)


(PDL)

0x02-0x22

(PD)

FileID

File Description 0-32 characters

FileID (16 bit):


File_Description (0-32 Characters):

Text to describe the specific FileID



15.10.1.2 Responder : FileID not supported

Response: (GET:Response) Bad response – FileID not supported

(Response Type)

NACK

(Message Count)

0x00

(Sub-Device)


(CC)


(PID)


(PDL)

0x02

(PD)


Responders that do not support the requested FileID shall NACK the request with a NR_DATA_OUT_OF_RANGE reason code in accordance with [RDM]



Appendix A: Defined Parameters Table A-1: Parameter ID Defines

Note : PID values are not yet defined – final values will be assigned at time of formal release of the standard.

GET

Allowed

SET Allowed

RDM Parameter ID’s (Slot 20-21) Value Comment Required

✓ ✓ FTC_NEGOTIATE ✓

✓ ✓ FTC_VALIDATE ✓

✓ FTC_COMMIT ✓

✓ ✓ FTC_TRANSFER +Support for GET is optional. ✓+

✓ FTC_PROXY_CAPABILITIES

✓ FTC_CANCEL

✓ FTC_FILELIST *Required if download supported. ✓*

✓ FTC_FILETYPE_DESCRIPTION *Support required if FTC_FILELIST is exposed.

✓*

✓ FTC_FILE_DESCRIPTION *Support required if FTC_FILELIST is exposed.

✓*



Table A-2: Response Status Defines

Response Status is returned in respect of SET:FTC_NEGOTIATE, SET:FTC_

Response Status Defines Value Comment

FTC_RS_IDLE 0x00

FTC_RS_ACKOK 0x01

FTC_RS_ACKWAIT 0x02 Delay reported in Response Data

FTC_RS_NACK 0x03 Reason code reported in Response Data

FTC_RS_FATALERROR 0xFF The responder has cancelled the transfer. Reason code reported in Response Data

Table A-3: Use of Response Data field

The Response Data field provides additional detail in respect of various Response Status entries.

Response Status Response Data Field use

Comment

FTC_RS_IDLE FTC_RDNRC_NULL

FTC_RS_ACKOK FTC_RDNRC_NULL

FTC_RS_ACKWAIT Time in ms to wait while busy

FTC_RS_NACK URS Nack reason code Refer to reason code as enumerated in Table A-5

FTC_RS_FATALERROR URS Nack reason code The responder has cancelled the transfer. Refer to reason code as enumerated in Table A-5

Table A-4: Transfer Query Status Defines

Transfer Query Status is returned in the Transfer Query Status field in respect of a GET:FTC_NEGOTIATE response.

Transfer Query Status Defines Value Comment

FTC_TQS_IDLE 0x00 No successful SET:FTC_NEGOTIATE yet received

FTC_TQS_NEGOTIATE 0x01 Negotiate complete but no FTC_TRANSFER yet received.

FTC_TQS_UPLOAD 0x02 Negotiate complete and one or more SET :FTC_TRANSFER received.

FTC_TQS_DOWNLOAD 0x03 Negotiate complete and one or more GET :FTC_TRANSFER received.

FTC_TQS_VALIDATE 0x04 Validation complete but no Commit yet received.

FTC_TQS_COMMIT 0x05 Commit still in progress. After a successful commit the response should be FTC_TQS_IDLE.



FTC_TQS_ERROR 0xFE Use when a responder has unexpectedly abandoned or aborted the transfer process

FTC_TQS_UNKNOWN 0xFF

Table A-5: Response Status Nack Reason Codes

When the Response Status field is set to FTC_RS_NACK or FTC_RS_FATALERROR, the Response Data field is used to return an associated Nack Reason Code.

Response Status NACK Reason Codes Value Comment

FTC_RDNRC_NULL 0x0000 Nothing to report

FTC_RDNRC_UNSOLICITED_TRANSFER 0x0101 The responder has received an unexpected data transfer packet

FTC_RDNRC_SESSIONID_MISMATCH 0x0102 SessionID does not match expected ID

FTC_RDNRC_UNSUPPORTED_FILEID 0x0103 The responder does not support the requested FileID

FTC_RDNRC_NOT_COMPATIBLE 0x0104 The file is not compatible with the responder

FTC_RDNRC_PACKET_CRC_ERROR 0x0105 The responder reports CRC mismatch

FTC_RDNRC_INTERNAL_ERROR 0x0106 The data transferred to a responder has an invalid internal check sum or CRC.

FTC_RDNRC_VALIDATION_ERROR 0x0107 The responder cannot validate the data uploaded by the controller

FTC_RDNRC_MISSING_VALIDATION 0x0108 The responder has not been asked to validate the data as uploaded by the controller

FTC_RDNRC_MODAL_ERROR 0x0109 The responder is in the wrong state to accept the command.

FTC_RDNRC_E137LOCKACTIVE 0x010A Locked/Unlock using E137 PIDs

FTC_RDNRC_OTHERLOCKACTIVE 0x010B Locked/Unlock using other scheme

FTC_RDNRC_WRITE_PROTECTED 0x01FE A memory protection scheme is preventing acceptance of data

FTC_RDNRC_UNDEFINED_ERROR 0x01FF Any error generated by the responder not covered in the above list

Table A-6: [RDM] Additional Nack Reason Codes

This standard extends the standard [RDM] Nack Reason codes with the following enummerations

Response Status NACK Reason Codes Value Comment

FTC_NRC_SESSIONID_MISMATCH TBC SessionID does not match expected ID in GET:FTC_TRANSFER download request.

FTC_NRC_UNSUPPORTED_FILEID TBC The responder does not support the requested FileID in GET:FTC_TRANSFER download request



Table A-7: File Type Enumeration

File Type Value Comment

FTC_TYP_FIRMWARE 0x80

FTC_TYP_BOOTLOADER 0x81

FTC_TYP_OUTPUT_CURVE_8_8 0x82 8bit in 8bit out






FTC_TYP_FADE_PROFILE_8 0x88

FTC_TYP_FADE_PROFILE_16 0x89

FTC_TYP_PRESETDATA 0x8A

FTC_TYP_PIXELMAP 0x8B

FTC_TYP_GOBOMAP 0x8C

FTC_TYP_IMAGE 0x8D

FTC_TYP_ASCII_LOGFILE 0xFE

FTC_TYP_ALL 0xFF



Appendix B: Control Flow for “1:1” upload transfers Example B-1 : Controller to Responder : Successful Validation

Controller sends Negotiate Request using SET_FTC_NEGOTIATE Responder replies with Transfer Requirements

Controller sends transfer data (note1) Responder replies with FTC_RS_ACKOK

Controller waits declared Inter-packet time (note2)



Repeat as required

Controller sends transfer data final packet (note1) Responder replies with FTC_RS_ACKOK


Controller sends SET Validate Request

Responder replies with

FTC_RS_ACKOK


FTC_RS_ACKWAIT and validate time



Responder replies with FTC_RS_ACKWAIT and

validate time of 0xFFFF to indicate no support for dynamic delay timing.

Controller waits the returned Validate

time

Controller does not support dynamic delay

timing so uses the delays as declared during Negotiate

Responder does not provide dynamic delay

timing so Controller uses the delays as declared

during Negotiate

Controller sends GET Validate

Request

Controller sends GET Validate Request


FTC_RS_ACKOK

Responder replies with FTC_RS_ACKOK

Controller sends Commit Request

Responder replies with FTC_RS_ACKWAIT and commit time(note3)

Controller waits returned Commit time

Controllers may assume transfer is complete after the expiry of the commit time (note4).



Note 1 : The transfer Block Size is as determined in the response to the negotiate request.

Note 2 : Inter-packet time is potentially extended after a series of packets has been transferred as defined by the Accumulated Packet Count and Accumulated Packet Count Delay.

Note 3 : The commit time should be in accordance with the time declared as a result of the negotiate request, but controllers shall use the longer time if there is a discrepancy.

Note 4: If the controller has been transferring Firmware (FileID 0x0000) it should assume that the responder may have new features and /or new UID. Controllers are advised to attempt re-establish communications using the Discovery process described in [RDM].



Example B-2 : Controller to Responder : Validation Fails

Controller sends Negotiate Request Responder replies with Transfer Requirements





Repeat as required




Responder replies with FTC_RS_NACK


validate time

Responder replies with FTC_RS_FATALERROR

Controller does NOT send Commit Request

Controller waits the requested time

The controller may choose to resend or adjust the request, dependent on the returned Response Status Reason

Code.



A controller that wishes to abandon the transfer sends a

Cancel Request (note 3)

Controller does NOT send Commit Request

A responder that wishes to reject repeated requests stops

using FTC_RS_NACK and replies with

FTC_RS_FATALERROR

Both the controller and responder regard the transfer process as finished.



Note 3 : Responders are required to reply to the cancellation request



Example B-1 : Controller to Responder : Successful Validation, Commit Rejected

Controller sends Negotiate Request Responder replies with Transfer Requirements





Repeat as required





Responder replies with FTC_RS_ACKWAIT and validate time

Controller waits the returned Validate time






The controller may choose to resend or adjust the request, dependent on the returned

Response Status Reason Code.

A controller that wishes to abandon the transfer sends a Cancel Request (note 3)


A responder that wishes to reject repeated requests stops using FTC_RS_NACK and

replies with FTC_RS_FATALERROR





Example B-3 : Controller to Responder : Negotiate Fails

Controller sends Negotiate Request



The controller may choose to resend or adjust the request, dependent on the returned Response Status Reason

Code.

A controller that wishes to abandon the transfer sends a

Cancel Request (note 1)


A responder that wishes to reject repeated requests stops

using FTC_RS_NACK and replies with

FTC_RS_FATALERROR

Note 1 : Responders are required to reply to the cancellation request



Appendix C: Control Flow for “1:1” download transfers

Example C-1 : Controller from Responder : Successful Transfer

Controller sends Negotiate Request with requested FileID and assigned SessionID Responder replies with Transfer Requirements

Controller requests transfer data (note1) Responder replies with ACK as per [RDM] and requested data




Repeat as required

Controller fetches transfer data (note1) Responder replies with and requested data

Controller determines there is no more data to fetch based on file size returned in Negotiate.

Controller waits declared Inter-packet time ACK as per [RDM] (note2)

In this case a responder may still have more data if the file size was incorrectly reported

Controller requests transfer data (note1)

Responder replies with ACK as per [RDM] and no data in the response payload


If the file size was correctly reported, the responder should have no more data and a GET:FTC_NEGOTIATE should now return a response transfer state of FTC_TQS_IDLE

Note 1 : The transfer Block Size is determined by the responder and may be anywhere in the range 16-224 bytes.

Note 2 : The use of the declared Inter-packet time provides improved granularity compared to the use of ACK_TIMER.



Example C-2 : Controller from Responder : Failed Transfer

Controller sends Negotiate Request with requested FileID and assigned SessionID Responder replies with Transfer Requirements





Repeat as required


Responder wishes to reject request due SessionID mismatch

Responder issues [RDM] NACK, and the FTC_NRC_SESSIONID_MISMATCH

reason code.

Responder wishes to reject request due DataOffset beyond end of file

Responder issues [RDM] NACK, and the FTC_NRC_UNSUPPORTED_FILEID

reason code


Note 1 : The transfer Block Size is determined by the responder and may be anywhere in the range 16-224 bytes.

Note 2 : The use of the declared Inter-packet time provides improved granularity compared to the use of ACK_TIMER.



Appendix D: Control Flow for “1:many” transfers Example D-1 : Controller to Responder using 1:many transfers

Controller sends Negotiate request to first target responder

Responder replies with Transfer Requirements

Controller sends Negotiate request to next target responder


Controller sends Negotiate request to next target responder


(repeat as required)

Controller sends Capabilities request to known Proxy Device

Proxy Device replies with Transfer Requirements

(repeat as required to known Proxy Devices)

Controller sends transfer data as BROADCAST message (note1)

Controller waits allocated time (note2)

Controller sends transfer data as BROADCAST message (note1)


Repeat as required

Controller sends transfer data final packet as BROADCAST message (note1)


Controller sends SET: Validate Request as BROADCAST message

Controller sends GET:Validate Request to first target responder

Responder replies with ACKOK or ACKWAIT (note3)

Controller sends GET:Validate Request to next target responder


Controller sends GET:Validate Request to next target responder



Controller waits allocated Validate time (note3)

Controller sends Commit Request to first target responder


Controller sends Commit Request as BROADCAST message

Controller sends Commit Request to next



target responder



Controller waits allocated Commit time (note3)

Controller should assume devices may have new UID and/or features and should attempt new Discovery

Note 1 : The transfer Block Size is the smallest obtained by the original negotiation with the “many” responders by the response to the Negotiate request.

Note 2 : The allocated time is the longest time obtained by the original negotiation with the “many” responders . Any allocated time is potentially extended after a series of packets has been transferred as defined by the Accumulated Packet Count and Accumulated Packet Count Delay.

Note 3 : any ACKWAIT time should be in accordance with the time declared as a result of the Negotiate request, but controllers shall use the longer time if there is a discrepancy.



Appendix E: Control Flow PROXY DEVICES

Example E-1 : Controller to Responder via Proxy : Successful Validation

Controller sends Request to the PROXY using GET:FTC_PROXY_CAPABILITIES Proxy replies with Transfer Requirements of the Proxy

Controller sends Negotiate Request using SET_FTC_NEGOTIATE Responder replies with Transfer Requirements

The controller determines required delays based on the longer of the two timings obtained from the Proxy and Responder.

The controller determines required packet size based on the smaller of the two values obtained from the Proxy and Responder.





Repeat as required





FTC_RS_ACKOK






validate time of 0xFFFF to indicate no support for dynamic delay timing.

Controller waits the returned Validate

time

Controller does not support dynamic delay

timing so uses the delays as declared during Negotiate

Responder does not provide dynamic delay

timing so Controller uses the delays as declared

during Negotiate

Controller sends GET Validate

Request






FTC_RS_ACKOK


Responder replies with FTC_RS_ACKWAIT and commit time(note3)

Controller waits returned Commit time

Controllers may assume transfer is complete after the expiry of the commit time (note4).

Note 1 : The transfer Block Size is as determined in the response to the capabilities request on both the Proxy and the responder. The smaller of the two reported values should be used by the controller.

Note 2 : Inter-packet time is potentially extended after a series of packets has been transferred as defined by the Accumulated Packet Count and Accumulated Packet Count Delay reported by both the Proxy and the responder. The larger of the two reported values should be used by the controller.



Appendix F: Transfer Time Guidance

This analysis is provided as informative. All calculations are approximate.

It is intended to provide guidance as to the suitability of the transfer process, especially as it might relate to larger files.

To transfer a file of 64Kbytes of data will require [65535/224 = 293] packets to be sent.

Assuming the best case of Break, MAB and inter-character time in the outgoing transmission, each transmitted packet takes :

176us Break+12us MAB+((25+231)*44)us [11.22ms].

Assuming each packet gets an ACK, with a PDL of 3 bytes, the response takes

176us Break+12us MAB+((25+3)*44)us [1.420ms].

This assumes the best case of Break, MAB and inter-character time in the return (response) transmission

Assuming best case turn-around of 176us there is 293*176us [51.6ms] of system delay

Best case Total transfer time estimated at (293 *11.22ms Tx Data) [3287ms] + (293 * 1.420ms Rx Data) [416ms]+ System delay [51.6ms] which gives approximately 3754ms (



Assuming worst case turnaround of 2.8ms there is 292*2.8ms [817.6ms] of system delay, so the transfer time would increase to 4521ms.

Further delays may occur depending on the time taken by the responder to validate transfers and re-flash memory.

A file size of 4GB would, however, take at least 246,807 seconds using this protocol. The use of this standard to transfer files of this size may not be appropriate to some applications.

Appendix G CRC Example Algorithm

A CRC is called an n-bit CRC when its check value is n-bits. For a given n, multiple CRCs are possible, each with a different polynomial. Such a polynomial has highest degree n, and hence n + 1 terms (the polynomial has a length of n + 1). The remainder has length n. The CRC has a name of the form CRC-n-XXX.

The Algorithm referred to in this standard is commonly known as CRC-16-CCITT, and has a polynomial representation of 0x1021.

This appendix details the implementation requirements of the 16-bit CRC-CCIT specification to be used in this standard which is

• Width = 16 bits

• Truncated polynomial = 0x1021

• Initial value = 0xFFFF

• Input data is NOT reflected

• Output CRC is NOT reflected

• No XOR is performed on the output CRC

• The CRC value for the ASCII reference string, “123456789” is 0xE5CC.

A number of guidance notes may be found on the internet

http://ww1.microchip.com/downloads/en/AppNotes/00730a.pdf

http://www.ross.net/crc/download/crc_v3.txt

http://ww1.microchip.com/downloads/en/AppNotes/00730a.pdf

http://www.ross.net/crc/download/crc_v3.txt

firmware or file upload control -...

Documents