There are two operational modes:

Serial ASCII Protocol ON

can2serial ascii

In this mode (Use Serial ASCII Protocol) any CAN message can be transmitted or received. A custom ASCII protocol is used that has the following format:

#ID,DLC,A,B...<cr>

Where:

ID = CAN message ID

DLC = Length of CAN message (0 to 8)

A,B,… = individual data bytes

So, for example, sending “100,2,1,2” would transmit a CAN message with ID 0x100, and two data bytes being 0x01 and 0x02.

Send Output Every - this time ensures that even if no CAN messages are seen on the bus there will still be a "keep alive" output on the serial port; this is useful to reassure that the probe is operational and configured. Setting this to zero will disable this functionality.

Output time deltas - when this is set an approximate time delta is added to the ASCII packet. Due to hardware constraints, the delta is only approximate and its accuracy can vary. The delta time is tagged onto the ASCII output after the last packet byte i.e. after the DLC account of comma-separated byte values.

Serial ASCII Protocol OFF

can2serial direct

In this mode, any character received on the serial port will be encoded into a CAN message. If you send the string YELLOW into the serial port then a CAN message will be emitted as:

[TX CAN ID][6][‘Y’][‘E’][‘L’][‘L’][‘O’][‘W’]

If you send “YELLOWCOG” there will not be enough room in one standard eight-byte CAN message so two messages will be emitted, as such:

[TX CAN ID][8][‘Y’][‘E’][‘L’][‘L’][‘O’][‘W’][‘C’][‘O’]

[TX CAN ID][1][‘G’]

The exact way the message is split will depend on the (unknowable) timing of the Pilot hardware and CAN bus shift registers. As long as the data rates are sustainable then no byte will be missed.

For received CAN messages the direction is reversed. Any data received as the payload on the configured receive CAN ID will be transmitted out the serial port as the same raw binary data. e.g. if the CAN message is comprised of ASCII viewable characters then you will get out will be readable text.