Teltonika FMC650 Leading GNSS LTE GSM/BLE Terminal For Advanced Applications User Guide

Teltonika FMC650 Leading GNSS LTE GSM/BLE Terminal For Advanced

Applications

To use the Manual CAN request functionality user should select the Manual CAN Requests tab in the configurator. Afterward, the user will be able to configure CAN parameters in the Manual CAN Request settings tab.

Manual CAN Requests

The main benefit of using Manual CAN request functionality is that the user can read data via CAN BUS without requiring additional CAN protocol development from the device’s firmware side if parameters need to be requested more frequently or vice versa. To read data with this functionality, the user must have:

FMB1YX device

03.01.00.Rev.00 or newer firmware (for FMB641/FMC650/FMM650) Transport or equipment with CAN interface which works via the J1939 protocol Transport or equipment CAN communication protocol (with information about frames,
parameters, ID‘s, Baudrate)

Manual CAN requests I/O settings

Users can configure up to 70 Manual CAN Request elements by setting CAN ID/Request ID, Request Period, Request Data Length, and RTR parameters. Additionally, in the Manual CAN I/O tab, the user needs to choose by configured Manual Request input name – CAN type, Data mask Data Source, CAN ID. Each CAN I/O has its parameters and can be configured independently. Configured CAN request will be shown by Manual CAN IO AVL ID.

• Functionality will work only when Ignition is ON Baudrates are configurable in CAN \ Tachograph tab settings for connected CAN lines which could be CAN1 or CAN2.
• For Manual CAN request functionality, CAN is selected in the Manual CAN IO tab. In Manual CAN IO, the input that should receive value must be enabled.
• Request ID/PGN – depends on the CAN Type parameter and defines which CAN ID will be requested by the device.
• Payload – defines data bytes, which are sent if RTR (Remote Transmission Request) is disabled.
• Request Period – defines how often the request will be sent. If 0 is selected – ID will not be requested.
• Request Data Length – defines the data length of the requested ID.
• RTR – Remote Transmission Request, is the choice of the data frame that needs to be sent (if disabled) and if the data frame needs to be requested (if enabled).
• If the data must be requested to receive CAN information from a heavy-duty vehicle – RTR must be enabled. If data can be received without requesting it from a heavy-duty vehicle – RTR can be disabled.

Example
In the Tachograph/CAN section, the user has to select a suitable baudrate. Manual CAN baudrate should be visible in the CAN protocol. If it is not known, the user can try to choose different baud rates to indicate which one works.

1. Select CAN Type. Normally, every CAN protocol documentation should mention which CAN type to use. If not, select Extended.
2. Fill in the correct Data mask. This field determines which IO elements of the frame the user will receive. As an example, the part of the CAN protocol was taken. Firstly, the user has to locate the data frame, that he wants to read, for this situation, the data frame „Battery status“ was taken into account.
3. It holds five I/O parameters of the battery. If we would like to receive all data of the frame, in the configurator the user has to leave the default value in the Data mask field (Selected ALL) – which is used in this example.

If the user would like to get everything except, for example, the Battery Temperature value, some modifications have to be done to the Data mask field. In this case, if the user does not want to get the Battery Temperature value, he should find where this information stands in the data frame (byte orientation). For this example, the Battery Temperature parameter can be found between the 4th and 5th byte of the frame. It is explained in the table below how the 8-byte CAN frame breaks down and which part of the frame has to be changed according to this example.

Protocol example

CAN ID to send CAN COMMAND
CAN ID to receive value in Manual CAN of CAN COMMAND

1. Enter the correct CAN ID in the Manual CAN tab. In this case, the Frame ID is needed to be entered. Here, the CAN ID is 0x300, so in the configurator, the user will need to enter 300 instead of the last three F values (FF0300FF). This means that it will take the data only from the ID 300.
2. For Manual CAN Requests tab configuration. In Manual, CAN0 Request will be configured Battery Status message request by the provided documentation. For proper configuration by the protocol, Request ID should be entered with Source addresses, Frame ID, and Priority – 18030102, and the payload 0000000000000002 to receive all needed information.
3. Additionally, it can also have a request period configured. As an example, to receive data every 10 seconds, the request period must be set to 10.
4. Request data length configured as 8 bytes.
5. Received I/O values are RAW and the user has to decode it. The image below is an example of how it can be decoded using additional software (we have used Busmaster for this):

Important note
Enabling all commands could drastically increase delay – sending could take up to 1.5 s (all commands configured with a 100 ms period).

We strongly advise

1. If all commands are necessary with a certain period – keep all commands with the same sending period.
2. Do not leave any enabled CAN reading parameters if CAN reading is not used.
3. Keep Data Acquisition settings higher than 15 seconds.

Send Period details Records could drastically increase the CAN command sending period as records could be generated every second by configured Features records, Data Acquisition settings, or IO element operands. Each particular case has a different effect on CAN Command delay, which depends on configuration and in case of an issue should be investigated individually.

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>