AXIOMATIC AX141100 CAN to Bluetooth Bridge and Datalogger User Manual

AXIOMATIC AX141100 CAN to Bluetooth Bridge and Datalogger User Manual

P/N: AX141100

Axiomatic Technologies Oy
Höytämöntie 6
33880 LEMPÄÄLÄ, Finland
Tel. +358 103 375 750
salesfinland@axiomatic.com
www.axiomatic.fi

Axiomatic Technologies Corporation
1445 Courtneypark Dr. E.
Mississauga, ON Canada L5T 2E3
Tel. 1 905 602 9270
sales@axiomatic.com
www.axiomatic.com

VERSION HISTORY

DEFAULT PIN CODES
Pairing: 000000
Configuration mode: 000000

ACRONYM

REFERENCES

This document assumes the reader is familiar with the SAE J1939 standard. Terminology from the standard is used, but not described in this document.

NOTE: This product is supported by Electronic Assistant V5.13.84.0 and higher.

1. Overview of The Controller

Figure 1 – AX141100 Block Diagram

The CAN to Bluetooth device (later CAN2BT) can be used for accessing the CAN bus and the other CAN nodes connected to it using Bluetooth communications and a smart device, such as a phone or a tablet.

The CAN2BT device provides also data logging capabilities. It has 4GBits of internal Flash storage for storing the selected CAN messages with time stamp information.

The CAN2BT device can be configured using an Android application called CAN2BT Configuration. With this tool, all the functionality of the CAN2BT device can be configured, such as setting PIN codes, connection options, CAN receive filtering and CAN data logging rules. Also RTC time setting and different Flash memory operations such as download data and data erase are supported.

The CAN2BT device can be operated in two main operation modes, namely the Interface Mode and the Bridge Mode. The Interface Mode is targeted for data logging operation and in this mode the CAN2BT device can be accessed using Electronic Assistant.

When in Bridge Mode, the CAN receive filtering is disabled and the device accepts all incoming CAN frames. The main purpose of the Bridge Mode is to use two CAN2BT devices as a wireless CAN data bridge between two different CAN networks. When in Bridge Mode, the CAN2BT device is transparent to the CAN bus and cannot be seen in Electronic Assistant’s list of J1939 nodes. The device can be still accessed using the CAN2BT Configuration tool.

In case the module startup fails (a communication error between the CPU and the Bluetooth module is detected), the CAN2BT device will indicate the failure by sending the following DM1 (PGN 0xFECA / 65226) to CAN bus on 1s intervals. In addition to the DM1, the two built-in LEDs are blinking and not responding to user configuration nor control messages. In failure mode, the unit will be accessible only via the CAN bus.

2. CAN to Bluetooth Function Blocks

This section explains the different functions and configuration available on the CAN2BT. The CAN2BT Configuration Android application is used as a reference. The application is available from Google Play.

2.1. PIN codes

Figure 2 – PIN Code settings

The PIN Code settings allow the user to define PIN codes that are used when accessing the device. Pairing PIN is the PIN code that will be used when pairing the CAN2BT device with a new smart device. Configuration PIN code is required when configuration is accessed (most configuration options require that the CAN2BT device is put to configuration mode. Entering the configuration mode requires the user to enter the configuration PIN). Remote Connection PIN is the code that is used when the CAN2BT makes a connection with another CAN2BT device (when forming a data brigde for wireless CAN communications).

DEFAULT PIN CODES
Pairing: 000000
Configuration mode: 000000

2.2. CAN Bus Configuration

Figure 3 – CAN bus configuration

CAN bus configuration allows changing the CAN interface baudrate. The list of available baudrate options include 50k, 100k, 125k, 250k (default), 500k and 1M. When changing the baudrate, the CAN2BT device needs to be restarted (power cycled) to apply the new baudrate to the CAN interface.

The Echo TX CAN Frames makes the CAN2BT device to send back all CAN messages that are sent to its Bluetooth interface using commands 0x12 and 0x13. Please see section 5.2 for more info about CAN message sending.

2.3. Connection Options

Figure 4 – Connection options

Connection options menu list the functions available for connecting the CAN2BT device to other CAN2BT node. Scan starts a scan for other Bluetooth nodes (CAN2BT works as a master). Connect to node makes a connection to one of the nodes returned in the Scan results. Disconnect from node disconnects the currently active connection. Set autoconnect can be used for setting a BD ADDRESS of a remote node with which the CAN2BT device will attempt to connect automatically at power on (targeted for data bridge operations). Disable autoconnect will reset the BD ADDRESS set using command Set autoconnect.

Define accepted BD ADDR lets the user to configure a Bluetooth address that will be the only address from which connections are allowed. All other nodes trying to connect to the CAN2BT device will be ignored.

All functions that are used for defining BD ADDRESSes expect to receive an index number that matches to the BD ADDR list returned upon successful device scan (using the Scan command). The list of valid numbers is from 1 to number of Bluetooth nodes found. Index 0 is also accepted, it is interpreted as the BD ADDR of the device that is currenty used for configuring the device. This is useful in cases where the accepted BD ADDR needs to be set.

2.4. CAN Receive Filtering

Figure 5 – CAN Receive Filtering

By default the device won’t read in all received CAN messages. With the CAN receive filtering functions, the user can change this behaviour. Disable CAN fitering removes all CAN receive filtering and makes the CAN2BT device capable of receiving all CAN frames on the bus. With CAN filtering disabled, the CAN2BT device is invisible to the CAN bus. This is the mode that is preferred for using the device as a bridge between two CAN buses.

Enable CAN filtering restores the default CAN receive filtering and makes the CAN2BT device visible to the CAN bus (it will respond to Address Claim messages).

Add CAN RX filter lets the user to define a single CAN filter and optional mask that are added to the low level (HW) CAN receive filter registers. Please note, that if the mask is not specified, the firmware uses a default mask of 29 (or 11) bits wide that will compare all bits in the received CAN frame against the specified filter.

Up to 28 filter definitions will be accepted. The Remove CAN RX filter will remove the specified filter (the removal is done by comparing the IDs of the configured filters and the ID specified to be removed).

The CAN filter definition for adding and removing filters is as follows:

Example 29bit ID filter & mask for receiving all (J1939) frames with Source Address 0xF9
Filter: 800000F9, Mask: FF
Example 11bit ID filter & mask for receiving ID 0x701 (CANopen master HB)
Filter: 701, Mask: 7FF

2.5. CAN Data Logging

Figure 6 – CAN Logging Configuration

The Datalogging configuration includes defining different PGNs or Source Addresses to log. These two functions assume PGNs and Source Addresses as defined in the J1939 specification. The Define ID to log allows the user to freely define a CAN frame ID that will be logged.

Please note, that the CAN Logging configuration does not change the CAN receive filtering. In most cases (unless the device has CAN receive filtering disabled), the user has to define proper CAN receive filters in order the CAN2BT to be able to receive all CAN frames that need to be logged.

The current data logging rules can be read using the List all logging rules function. The Erase all logging rules will erase all rules.

2.6. Flash Memory Operations

Figure 7 – Flash memory operations

Contents of the Flash memory can be downloaded to an Android smart device using the Download flash contents. This function will transfer 96 bytes of the Flash contents at a time, please refer to section 5 for details.

The Flash can be erased few blocks at a time or then a full erase can be done using Erase all flash blocks. The Flash erase functions will require that the device is in configuration mode, so the Flash contents are protected with the Configuration PIN.

The current flash address (block and page) can be set using the Flash address function. All the following Flash writes will use this setting.

Erasing a single block can be done by setting the erase start block and end block to a same value (please note that the flash erase is flash block specific). To download a single flash page, the start address (block & page) and end address (block & page) need to be set to a same value.

Table 2 – Flash chip details

2.7. Real Time Clock Settings

Figure 8 – Real Time Clock

There is an RTC on the CAN2BT device. The RTC is powered from a supercap, capable of keeping the time and data information for 96 hours of stand-by if fully charged before the stand-by period. The fully charging means that the CAN2BT device is being powered at least 8 hours continously.

The time can be set using the Set time and read using the Get time function. Setting the time requires that the CAN2BT device is in configuration mode.

2.8. Miscellaneous Settings

Figure 9 – Miscellaneous settings

The miscellaneous settings consist of setting the CAN2BT device to the configuration mode, and exiting the configuration mode. The CAN2BT device can be also SW reset and the CAN bootloader can be started for firmware updates (please also see section 8).

The Enter Configuration mode requires the user to enter the current Configuration PIN number. In case the smart device is disconnected from the CAN2BT device during configuration, the CAN2BT device automatically exits the confitguration mode.

SW Reset will reset the CPU of the CAN2BT device. Start bootloader will set the start bootloader flag and then reset the CPU. This makes the CAN2BT device enter the firmware reflash mode, and it will be visible on the CAN bus and accessible from EA as Bootloader #1 (please see section 8 for more detailed description of firmware reflashing). Default settings will restore factory default settings and then reset the CPU.

Bluetooth ID allows the user to configure the name that device will advertise. The default is “CAN2BT”. In case there are multiple CAN2BT devices in range, it might be advantageous to configure unique names to different controllers. The Bluetooth ID accepts charaters in range 0x20 (‘space’) to 0x7E (‘~’) and can hold up to 248 characters.
The configured Bluetooth ID is also available in the J1939 Software ID (SPN 234).

In case the CAN2BT device is not in configuration mode and the user tries to configure it, the configuration commands return non-zero values.

2.9. CAN Scope

The CAN Scope function shows the frames on the CAN bus. Only the frames that pass the receive filters (please see section 2.4) are shown. The CAN Scope function can be also used for manually sending CAN frames to tbe bus.

The data for the frame to be sent is given in hexadecimal format. The data bytes for the CAN frame need to be given in sequence of bytes. The separator between the bytes can be one of the following characters:

2.10. LED Configuration

Figure 11 – LED Configuration

The build in LEDs of the CAN2BT device can be also manually controlled. The LED Mode function allows the user to set the LED function, default – LED activity based on BT RX and TX and manual – LED states as commanded using the LED commands. Please see section 5.2 for more detailed info about the available LED commands.

3. Installation Instructions

3.1. Dimensions and Pinout

Figure 12 – AX141100 Dimensional Drawing

4. Overview of J1939 Features

The software was designed to provide flexibility to the user with respect to messages sent from the ECU by providing:

• Configurable ECU Instance in the NAME (to allow multiple ECUs on the same network)

4.1. Introduction to Supported Messages

The ECU is compliant with the standard SAE J1939, and supports following PGNs from the standard. From J1939-81 – Network Management

Setpoints are accessed using standard Memory Access Protocol (MAP) with proprietary addresses. The Electronic Assistant (EA) allows for quick and easy configuration of the unit over CAN network.

4.2. NAME, Address and Software ID

The CAN to Bluetooth ECU has the following default for the J1939 NAME. The user should refer to the SAE J1939/81 standard for more information on these parameters and their ranges.

The ECU Instance is a configurable setpoint associated with the NAME. Changing this value will allow multiple ECUs of this type to be distinguishable from one another when they are connected on the same network.

The default value of the “ECU Address” setpoint is 251 (0xFB), which is the default for an on board data logger device. The EA will allow the selection of any address between 0 and 253. It is the user’s responsibility to select an address that complies with the standard. The user must also be aware that since the unit is arbitrary address capable, if another ECU with a higher priority NAME contends for the selected address, the CAN to Bluetooth device will continue select the next highest address until it finds one that it can claim. See J1939/81 for more details about address claiming.

Software Identifier

Byte 1 is set to 5, and the identification fields are as follows.

(Part Number)(Version)(Date)(Owner)(Description)

The EA shows all this information in “General ECU Information”, as shown below.
Note: The information provided in the Software ID is available for any J1939 service tool which supports the PGN -SOFT.

5. SPP Communications

The communications between a smart device such as a phone or a tablet and the CAN2BT device is based on Bluetooth Serial Port Profile (SPP). By default, the CAN2BT firmware declares itself as a SPP device (UUID: 00001101-0000-1000-8000-00805F9B34FB)

The messages are transferred in binary format, least significant byte first. The list of supported proprietary messages is shown below.

5.1. Overall message format

There is an ack response sent by the CAN2BT device after receiving the configuration messages. The overall message format:

in which the is as listed in below. is full message length without the four CRC32 bytes. CRC32 is selected because the support for it is readily available in Android.
All data that is expressed as Byte 0, Byte 1, … in the message descriptions below, is expected to be either 16 bits or 32 bits wide data, broken down to bytes (8 bits) least significant byte first. The only exception is the PIN code data, that is expected to be formatted one digit per byte. The PIN codes are hard formatted to have 6 digits.

Available CAN baudrate options include: 0 – 50k, 1 – 100k, 2 – 125k, 3 – 250k, 4 – 500k, 5 – 1M

5.2. Message types

6. ECU Setpoints Accessed with Electronic Assistant

Currently the CAN2BT device does not have any specific setpoints. Electronic Assistant (later EA) can be used for setting the J1939 NAME parameters when the device is in Interface Mode (when in Bridge Mode, the CAN2BT device is invisible to EA and to other J1939 devices on the bus).

The CAN bootloader can be started using EA, when the device is configured to operate in Interface Mode.

7. Accessing Remote Axiomatic ECUs with BT MAP Tool

The CAN2BT device can access the configuration setpoints of other Axiomatic CAN devices connected to the CAN bus. The Android app for this is called the BT MAP Tool, available from Google Play.

The BT MAP Tool provides an EA like configuration interface to Axiomatic CAN controllers from an Android smart device such as a phone or a tablet.

The BT MAP Tool reads in a setpoint definition file and uses the setpoint addresses and data types specified in that file for accessing the remote Axiomatic CAN device. There are setpoint definition files included in the APK by default, but there are no restrictions of adding more definition files manually.

All Axiomatic CAN controllers that have EA support can be accessed and configured using the BT MAP tool.

8. Reflashing over CAN with EA Bootloader

The AX141100 can be upgraded with new application firmware using the Bootloader Information section. This section details the simple step-by-step instructions to upload new firmware provided by Axiomatic onto the unit via CAN, without requiring it to be disconnected from the J1939 network.

Note: To upgrade the firmware use Electronic Assistant V5.13.84.0 or higher. Further, the AX141100 device needs to be in Interface Mode (CAN receive filtering enabled) in order to be accessible by EA.

Note: In case it is preferred not to set the device to Interface Mode, see Step 3.1 below.

1. When EA first connects to the ECU, the Bootloader Information section will display the following information.

2. To use the bootloader to upgrade the firmware running on the ECU, change the variable “Force Bootloader To Load on Reset” to Yes.

3. When the prompt box asks if you want to reset the ECU, select Yes.

3.1 In case the AX141100 device is in Bridge Mode, it cannot be accessed using EA. In this case, it is possible to start the bootloader from CAN2BT Configuration tool. First from the Misc. configuration menu, the Configuration Mode needs to be set active (on left) and then the Bootloader can be started (on right).

4. Upon reset, the ECU will no longer show up on the J1939 network as an AX141100 but rather as J1939 Bootloader #1.

Note that the bootloader is NOT Arbitrary Address Capable. This means that if you want to have multiple bootloaders running simultaneously (not recommended) you would have to manually change the address for each one before activating the next, or there will be address conflicts. And only one ECU would show up as the bootloader. Once the ‘active’ bootloader returns to regular functionality, the other ECU(s) would have to be power cycled to re-activate the bootloader feature.

5. When the Bootloader Information section is selected, the same information is shown as when it was running the AX141100 firmware, but in this case the Flashing feature has been enabled.

6. Select the Flashing button and navigate to where you had saved the CAN2Bluetooth.bin (or equivalent) file sent from Axiomatic. (Note: only binary (.bin) files can be flashed using the EA tool.)
7. Once the Flash Application Firmware window opens, you can enter comments such as “Firmware upgraded by [Name]” if you so desire. This is not required, and you can leave the field blank if you do not want to use it.
Note: You do not have to date/time-stamp the file, as this is done automatically by the EA tool when you upload the new firmware.

NOTE: If the “Erase All ECU Flash Memory” box is checked, all configuration data currently stored in non-volatile flash including PIN codes will be deleted.

**** The CAN log data won’t be affected by this.
By leaving this box unchecked, none of the settings will be changed when the new firmware is uploaded, unless it is detected by the new firmware that the old settings are incompatible with the new firmware version.

A progress bar will show how much of the firmware has been sent as the upload progresses. The more traffic there is on the J1939 network, the longer the upload process will take.

Once the firmware has finished uploading, a message will pop up indicating the successful operation. If you select to reset the ECU, the new version of the AX141100 application will start running, and the ECU will be identified as such by EA. Otherwise, the next time the ECU is power-cycled, the AX141100 application will run rather than the bootloader function.

Note, if the settings define the AX141100 to be configured to operate in Brigde Mode, the device will disappear from EA upon reset.

Note: If at any time during the upload the process is interrupted, the data is corrupted (bad checksum) or for any other reason the new firmware is not correct, i.e. bootloader detects that the file loaded was not designed to run on the hardware platform, the bad or corrupted application will not run. Rather, when the ECU is reset or power-cycled the J1939 Bootloader will continue to be the default application until valid firmware has been successfully uploaded into the unit.

APPENDIX A – TECHNICAL SPECIFICATION

Specifications are indicative and subject to change. Actual performance will vary depending on the application and operating conditions. Users should satisfy themselves that the product is suitable for use in the intended application.
All our products carry a limited warranty against defects in material and workmanship. Please refer to our Warranty, Application Approvals/Limitations and Return Materials Process as described on https://www.axiomatic.com/service/.

Read More About This Manual & Download PDF:

References

• Return Policy - Axiomatic Technologies Corporation

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>