Physical Mounting

9 Pin Connector

The M5 Communications Module 9 pin connector is molded neoprene, 10,000 psi rating, 9 contacts with AWG, 600 VDC, per pin.

Connector pin configuration: Male face from the front

Pin Configuration

This table applies to the M5 Communications Module female connector.

Pin	Conductor AWG	Conductor Color	Signal Name	Comments
1	28	RED	ETH-RXP-
2	28	GREEN	ETH-RXP+
3	28	BLACK	24 V DC
4	28	GRAY	ETH-RTX+
5	28		Ground
6	28		ETH-RTX-
7	28		RS-485 A
8	28		RS-485 B
9	28		12 V DC

Mating Connector

Connector Vendor: Teledyne Impulse

LPIL-9-MP, Male / Female Connector with whip used on the module

LPIL-9-MP, Male Connector with whip used on the module

LPBH-9-FS, Female Bulkhead Connector used on the platform vehicle

Bootloader Operation

The bootloader runs on the module upon power up. The module will remain in the bootloader for 1 second waiting for a command to remain in the bootloader. If no command is received and the module has a valid application firmware loaded then the module will run the application firmware. If the "remain in bootloader" command is received or if there is no valid application firmware the module will remain in the bootloader.

The module must have the bootloader running. The primary mechanism of installing the bootloader on the module is via JTAG (Joint Test Action Group). If you require provisioning a module with a bootloader, please see the appropriate documentation.

Bootloader LED Blink Patterns

The bootloader blinks the module status LED to indicate its operational state.

• Start-up Blink (3 blinks): The bootloader will blink 3 blinks (100ms ON, 200 ms OFF) on startup.

• Active Blink (fast 5 times a second continuous): The status led will rapidly blink (5 times a second) while running in the bootloader. The blink will remain continuously active until the module leaves the bootloader.

• Command reception blink (fast 5 times a second continuous): The status led will rapidly blink (5 times a second) while running in the bootloader. The blink will remain active while the module is in the bootloader.

Typical blink startup pattern will be:

3 blinks, followed by 1 second of rapid blinks, followed by the application firmware blink pattern. If there is no valid application, the pattern will be 3 blinks, followed by continuous rapid blinks.

Verification of Bootloader Operation via a Terminal

The bootloader emits an identifying message on startup. Part of the message is ASCII and thus human readable. This provides a method to insure that the bootloader is loaded on the module.

Connect a terminal emulator (such as tera term or putty) to the serial port connected to the module. The terminal should be set to 115200, 8n1.

Upon power up of the module the terminal will display the received characters. The display will look similar to the image below. If the text "BOOT" is visible then it is most likely that the bootloader is on the module.

ASCII terminal display showing bootloader message as well as text banner from a module application firmware (LED Controller). "BOOT" is highlighted in yellow, and the firmware message is highlighted in green.

Firmware

Updating Firmware on M5 Modules

Quick Steps for manual updating a single module:

1. Download vr_refresh if needed from ftp.videoray.com
2. Download new firmware for the module from ftp.videoray.com
3. Connect the serial power to the module. Do NOT power on the module yet.
4. Run vr_refresh with a command line similar to "vr_refresh -c COM7 firmware-1.0.0.hex"
5. Apply power to the module.
6. It should start the download process. If not, or if any errors during download, repeat steps 3-5.

Downloading Firmware and Tools

All M5 software is distributed via the VideoRay FTP server (http://ftp.videoray.com/) using the following credentials:

• Username: quarterdeck
• Password: quarterdeck

Note the use of http://, not ftp:// in the server URL above.

The firmware is located in the ./firmware folder.

Tools (such as vr_refresh) are located in the ./windows_tools folder or ./ubuntu_tools folder depending upon what OS you are using.

At a minimum the firmware for the module and the appropriate vr_referesh application are required to update the firmware on a module

Instructions for using vr_refresh are included in the next section.

Using vr_refresh

The vr_refresh tool is a standalone command line application that can be used to update the firmware on a module. There are no dependencies for vr_refresh.

Usage: vr_refresh [OPTIONS] [SINGLE_HEX_FILE_NAME]

Do not include the brackets [   ].

OPTION	Description
-? [ --help ]	show the help message
--version	show version
-c [ --com ] arg	set com port name (=/dev/ttyUSB0)
-i [ --id ] arg	node ID, 255 for broadcast (=255)
--sn arg	serial number (=any)
--block_size arg	flash block size (=1024)
-d [ --dir ] arg	set firmware folder, not used if an input file is specified
-q [ --quite ]	do not send check active command
-v [ --verbose ]	output verbose diagnostics
-r [ --RESET ]	reset device upon completion
--UNLOCK	allow reprogramming of bootloader
--input_file arg	input file

For example, to download the firmware to a LED controller module, the typical usage on a Windows machine would be:

• vr_refresh -c com7 led_controller-1.0.0.hex

The typically usage on a Linux host would be:

• vr_refresh -c /dev/ttyUSB0 led_controller-1.0.0.hex

By default vr_refresh will use BROADCAST transmissions to establish connections. This behavior can be changed by using the -i or the -sn parameters.

vr_refresh, like all VideoRay command line tools will output its usage options when run with the "-?" parameter.

vr_refresh Methods of Connection

There are two ways to establish a connection between vr_refresh and the module.

Power on Connection

When vr_refresh is run it will sit and wait for the initial announcement message sent by the module. The modules use a randomized transmission to attempt to minimize collisions when there are multiple devices on the bus. Since vr_refresh by default uses broadcasts, this means that if there are multiple devices connected and powered up at the same time it is a matter of chance as to which module will connect. It is therefore recommend that either the -sn or -i parameters be used or only as single module be connected at a time when updating firmware.

Application Firmware Reboot Connection

When vr_refresh is run it will send a REBOOT message immediately (-i parameter applies). If a module is connected, powered up, and accepts the REBOOT message from vr_refresh (either it is a broadcast message or the proper node id was passed in) the module will reboot and jump to the bootloader. It should then connect as desired.

vr_refresh Output

vr_refresh will output status strings during operation. Examples are given below:

Waiting to connect (command line: vr_refresh -c com7 -I 1); response:

• INFO: Attempting connection to Node: 1 S/N: any

Successful connection (command line: vr_refresh -c com7); response:

• INFO: Attempting connection to Node: 255 S/N: any
• INFO: Connected to Node: 5
• INFO: Done

Successful connection VERBOSE mode (command line: vr_refresh -c com7 --verbose); response:

• INFO: Attempting connection to Node: 255 S/N: any
• INFO: Connected to Node: 5
• INFO: Boot Data
  • Data version: 1
  • Device type: 131
  • Incept date: 2014-Nov-10 22:29:55
  • Serial number: LED0001
  • App Size: 0x9118
  • App crc: 0x23f766a8
• INFO: Done

Sample end of firmware update (command line: vr_refresh -c com7 -verbose led_controller-1.0.0.hex); response:

• INFO: Progress 90%
• INFO: Erase 0xc400
• INFO: Progress 91%
• INFO: Progress 92%
• INFO: Progress 93%
• INFO: Erase 0xc800
• INFO: Progress 94%
• INFO: Progress 95%
• INFO: Progress 96%
• INFO: Erase 0xcc00
• INFO: Progress 97%
• INFO: Progress 98%
• INFO: Erase 0xd000
• INFO: Progress 99%
• INFO: Progress 100%
• INFO: Done

Diagnostic / Test Mode

Diagnostic mode is a simple ASCII terminal user interface that allows interaction with the motor controller electronics without requiring any additional topside software other than a serial terminal (such as Tera Term). The baud rate should be set to 115,200.

Test cables are available from VideoRay and use an FTDI RS-485 to USB serial adapter. The driver for the adapter is a available from FTDI's website at: http://www.ftdichip.com/Drivers/D2XX.htm. To enter Diagnostic mode, input "+++++" (5 pluses) within 5 seconds after power up. If 5 seconds have elapsed, or any vrcsr packets have been received, diagnostic mode will be locked out until the next power cycle.

Diagnostic mode includes Motor Activation Mode and Configuration Mode. These modes are described on the following pages.

Since diagnostic mode is a simple ASCII terminal it is not appropriate for multiparty communications.

Configuration Mode

The diagnostic configuration menu allows for various operating parameters to be set. The parameters can also be saved in non-volatile storage.

The diagnostic configuration menu displays the motor controller serial number as well as the firmware versions number and firmware inception date.

In diagnostic configuration mode the "Enter" key must be hit after each command input.

Primary Configuration Commands:

• Pressing "x" followed by "Enter" will exit diagnostic configuration mode and return to the diagnostic menu.
• Pressing "s" followed by "Enter" will save the current parameters in non-volatile memory.
• Pressing "f" followed by "Enter" will reset the all parameters to their hardcoded factory defaults.

Entering a number followed by "Enter" will prompt for a new setting for the configuration parameter. If "Enter" is pressed before a new value has been entered the current value will remain.

Motor Controller: THR0006
SW Version: 0.8.3 Dec 1, 2014 09:38:00

Command	Function	Default Value	Description
1	Motor control flags	0x0	The motor control flags are a bitfield that sets binary operation parameters. Currently defined: CONTROL_FLAG_REVERSE_ROTATION (1 << 0) When set, reverses the rotation of the motor.
2	Motor poles	14	Defines the number of poles in the attached motor.
3	PWM deadband	32	Defines the time that band that insures that the motor driving FETs are off. This prevents both the high and low driving complementary FETs to be on at the same time. Units are in processor cycles.
4	Commutation threshold	0.100000	This defines the trigger level at which the commutation algorithm determines it is time to commutate the motor.
5	Commutation loss timeout	100	If the time between detected commutations is greater than this value, in mS, then the algorithm will assume the motor is stalled and reset the commutation algorithm and switch to open loop startup mode.
6	Startup duty cycle	0.040000	The duty cycle that will be used to power the motor when in initial open-loop startup mode.
7	Startup initial RPM	80	The initial startup RPM that will be used when the motor is in initial open-loop startup mode. The algorithm will attempt to commutate at this RPM using the Startup Duty Cycle PWM. The open loop phase will ramp up from this RPM to the startup end RPM at a rate defined by the Ramp Startup time.
8	Startup final RPM	100	he ending startup RPM that will be used when the motor is in initial open-loop startup mode. The algorithm will attempt to commutate at this RPM using the Startup Duty Cycle PWM. The open loop phase will ramp up to this RPM from the startup initial RPM at a rate defined by the Ramp Startup time.
9	Startup duration	50.000000	This parameter defines the duration required to ramp from startup initial RPM to startup end RPM. This value is in units of ????
10	Negative deadband	-0.020000	This defines the largest (closest to 0) negative value that can be set as a motor thruster setpoint. It is assumed that due to stiction the motor will not spin at power levels closer to 0 than this.
11	Positive deadband	0.020000	This defines the smallest positive (closest to 0) value that can be set as a motor thruster setpoint. It is assumed that due to stiction the motor will not spin at power levels closer to 0 than this.
12	Negative duty cycle limit	-0.990000	This value is the limit in the negative direction of applicable power to the motor. The command setpoint will never be less than this value.
13	Positive duty cycle limit	0.990000	This value is the limit in the positive direction of applicable power to the motor. The command setpoint will never be greater than this value.
14	Acceleration rate	0.000050	This value defines the rate at which the motor will change from the current power setpoint to the target setpoint. This value defines the rate when the absolute value of the target setpoint is larger than the current setpoint. The units of this value are change in normalized power per mS.
15	Deceleration rate	0.000050	This value defines the rate at which the motor will change from the current power setpoint to the target setpoint. This value defines the rate when absolute value of the target setpoint is less than the current setpoint. The units of this value are change in normalized power per mS.
16	Power manager threshold	200.000000	This actively limits the power that the thruster will use. The default is 200W.
17	Fault control	0x0	This is a bit-field mask is used to enable or disable the de-energizeing of the motor on the detection of a fault. Faults will still be detected, but if the bit field is cleared the controller will not de-energize on that specific fault condition. Current fault conditions are defined as: FAULT_UNDERVOLT (1<<0) FAULT_OVERRVOLT (1<<1) FAULT_OVERCURRENT(1<<2) FAULT_OVERTEMP(1<<3) FAULT_STALL(1<<4) FAULT_STALL_WARN (1<<5)
18	Minimum voltage	19.200001	Sets the undervoltage fault trip point in Volts.
19	Max bus voltage	50.000000	Sets the over voltage fault trip point in Volts.
20	Max current	20.000000	Sets the overcurrent fault trip point in Amps.
21	Max temperature	100.000000	Sets the overtemp fault trip point in degrees Celsius.
22	Max stall count	100	Sets the threshold for the number of stall event detections at which to declare a fault.
23	Node Id	2	This is the communication protocol network node id. This is used to designate this device on a multiparty RS-485 communication network. A module will accept a packet which is addressed to its node ID, Group ID, or uses the broadcast ID.
24	Group Id	129	This is the communication protocol network group id. This is used to designate a group of device on a multiparty RS-485 communication network. A module will accept a packet which is addressed to its node ID, Group ID, or uses the broadcast ID.
25	Motor Id	0	This is the motor controller ID. This associates a motor with a specific datum in the motor controller propulsion command. Modules with the same motor ID will all use the same set point when sent an acceptable propulsion command.
26	System control flags	1	The motor control flags are a bitfield that sets binary operation parameters. Currently defined: ENABLE_LOSS_OF_COMMS_TIMOUT (1 << 0) DISABLE_STARTUP_TONES (1<<1) When set the controller will set the power setpoint to 0 if communications have been lossed for 1 second.Clearing this flag allows for a greatly reduced communications bandwidth. However the motor will continue to spin even if communications have been lost.
27	Fault interlock	0	This value must be set to the proper password to allow the faults control mask to be changed. The password is 0xdeadbeef
f	Reset	n/a	Reset parameters to factory default.
s	Save	n/a	Save parameters.
x	Exit	n/a	Exit configuration mode.

Programming

CSR Memory Map

In normal operation the device implements a CSR type memory mapped data space. The VideoRay CSR comms protocol is used for communication. See https://github.com/videoray/VRCommsProtocol_doc/raw/master/VR_CSR_Communication_Protocol.doc for more information on the base binary protocol.

Register	Function	Comments
0x0	float rpm_target	rpm (RW) NOT USED YET
0x4	float pwr_target	-1 to 1 (RW)
0x8	float rpm	rpm (R)
0xc	float bus_v	volts (R)
0x10	float bus_i	amps (R)
0x14	uint32_t fault	fault flags (R)
0x18	float temp	deg C (R)
0x1c	float pwr_actual	-1 to 1 (R)
0x20	float rpm_P	0 to 1 (R) NOT USED YET
0x24	float rpm_I	0 to 1 (R) NOT USED YET
0x28	float rpm_D	0 to 1 (R) NOT USED YET
0x2c	RESERVED
0x4c	uint16_t thruster_ID	ordinal (RW)
0x4e	RESERVED
0x50	uint8_t operation_flags
0x51	RESERVED
0x54	uint32_t motor_fault_interlock	password (RW)
0x58	RESERVED
0x60	uint8_t motor_control_flags	Bitfield (RW)
0x61	uint8_t poles	count (RW)
0x62	uint8_t pwm_deadband	ticks (RW)
0x63	RESERVED
0x64	float commutation_threshold	0 to 1 (RW)
0x68	uint32_t commutation_loss_timeout	ms (RW)
0x6c	float startup_dutycycle	0 to 1 (RW)
0x70	uint16_t startup_initial_rpm	rpm (RW)
0x72	uint16_t startup_final_rpm	rpm (RW)
0x74	float startup_duration	mS (RW)
0x78	float deadband_neg	-1 to 0 (RW)
0x7c	float deadband_pos	0 to 1 (RW)
0x80	float limit_neg	-1 to 0 (RW)
0x84	float limit_pos	0 to 1 (RW)
0x88	float slew_rate_up	delta/mS (RW)
0x8c	float slew_rate_down	delta/mS (RW)
0x90	float rpm_kP	-1 to 1 (RW) NOT USED YET
0x94	float rpm_kI	-1 to 1 (RW) NOT USED YET
0x98	float rpm_kD	-1 to 1 (RW) NOT USED YET
0x9c	RESERVED
0xa4	uint8_t fault_control	flag (RW)
0xa5	uint8_t undervoltage_trigger	volts (RW)
0xa6	uint8_t overvoltage_trigger	volts (RW)
0xa7	uint8_t overcurrent_trigger	amps (RW)
0xa8	uint8_t temp_trigger	deg C (RW)
0xa9	uint8_t stall_count_max	count (RW)
0xaa	RESERVED
0xac	uint32_t undervoltage_err_cnt	count (R)
0xb0	uint32_t overvoltage_err_cnt	count (R)
0xb4	uint32_t overcurrent_err_cnt	count (R)
0xb8	uint32_t temp_err_cnt	count (R)
0xbc	uint32_t stall_err_cnt	count (R)
0xc0	RESERVED
0xd8	uint32_t comms_sync1_err_cnt	count (R)
0xdc	uint32_t comms_sync2_err_cnt	count (R)
0xe0	uint32_t comms_headerxsum_err_cnt	count (R)
0xe4	uint32_t comms_overrun_err_cnt	count (R)
0xe8	uint32_t comms_payloadxsum_err_cnt	count (R)
0xec	uint16_t comms_err_flag
0xee	uint16_t save_settings	code (W)
0xf0	uint32_t custom_command	(W) Special Register
0xf4	uint32_t FACTORY_SERVICE_DATA	(R) Device specific service data
0xf8	uint16_t CONFIG_DATA_SIZE	(R)
0xfa	uint8_t CONFIG_DATA	(R) Special Register
0xfb	uint8_t FIRMWARE_VERSION	(R) Special Register
0xfc	uint8_t NODE_ID	(RW) Special Register
0xfd	uint8_t GROUP_ID	(RW) Special Register
0xfe	uint16_t UTILITY	(W) Special Register

CSR Field Definitions

To be added.

Commands and Responses

The motor controller firmware also supports custom commands that allow for the instantaneous setting of multiple controllers on a party line comms bus.

PROPULSION_COMMAND: 0xaa

The propulsion command is an application custom command which is sent as a write request to CSR address 0xF0 (the custom command register. It has the following data payload format:

• 0xAA R_ID THRUST_0 THRUST_1 THRUST_2 ... THRUST_N

Where:

• 0xAA is the command byte
• R_ID is the NODE ID of the thruster to respond with data
• THRUST_X is the thruster power value (-1 to 1) for the thruster with motor id X

Typically this is sent as a group multicast to address 0x81 which is reserved for thrusters.

RESPONSE_THRUSTER_STANDARD: 0x02

The standard thruster response is typically used in conjunction with the multicast PROPULSION COMMAND to retrieve data from each thruster in the system in a round robin fashion.

When the FLAG byte is set to 0x02 the RESPONSE_THRUSTER_STANDARD data payload is sent.

The format of this payload is defined by the following structure:

Response_Thruster_Standard {
    /** Measured shaft rotational velocity */
    float rpm;
    /** Bus voltage (Volts) */
    float bus_v;
    /** Bus current (Amps) */
    float bus_i;
    /** Temperature (Degree C) */
    float temp;
    /** fault flags */
    uint8_t fault;
}

Please see the example thruster.py for an illustration of how to use the PROPULSION_COMMAND and parse the RESPONSE_THRUSTERS_STANDARD response packet.

European Union (EU)

The following sections are specific to the European Union.

The Waste Electrical and Electronic Equipment Regulations (WEEE) 2013

In accordance with the requirements of the Waste Electrical and Electronic Equipment Regulations 2013, all non fixed electrical and electronic equipment must be disposed of correctly at the end of its useful life through an authorised waste company, and there is an associated requirement to obtain the correct paperwork as per Duty of Care legislation. Please ensure that you treat this equipment as WEEE when you come to dispose of it.