Basic Services

Last Updated on : 2024-06-04 06:16:47download

This topic describes the data format and basic features for the cellular standard protocol. The serial protocol is used for serial communication between Tuya’s LTE Cat.1 module and the third-party MCU.

Tuya LTE Cat.1 ModuleUser MCURX->TXTX<-RXTuya LTE Cat.1 ModuleUser MCU

Serial communication

  • Baud rate: 115200, 9600, 460800, and 921600. The baud rate will be automatically detected for two minutes. If not specified, the default baud rate of 115200 will be used.
  • Data bit: 8
  • Parity check: none
  • Stop bit: 1
  • Data flow control: none
  • MCU: microcontroller unit. Your MCU communicates with Tuya’s modules through the serial port.

Frame format

Field Bytes Description
Header 2 It is fixed to 0x55aa.
Version 1 It is used for updates and extensions.
Command 1 The frame type.
Data length 2 Big-endian format.
Data N -
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.
  • All data greater than one byte is transmitted in big-endian format.

  • Typically, one command is sent by one party and received by the other party synchronously. That is, one party sends a command and waits for a response from the other party. If the sender does not receive a correct response packet within a specified time period, the transmission times out.

    MCUModuleSend the command NRespond to the command NMCUModule
  • If the module does not respond to the MCU command within two minutes, the MCU must restart it. After the MA510 module completes an OTA update, it will restart without notifying the MCU. If the MA510 module starts with uart3_tx high, it will fail to start and require the MCU to trigger a restart.

  • Both command sending and status reporting use asynchronous transmission. Assume that the module sends a control command X and the MCU reports status Y. The data transmission is performed as shown below.

    • The module sends a control command:

      ModuleMCUSend the control command XReport the status YModuleMCU
    • The MCU reports status:

      MCUModuleReport the status YMCUModule

Response format for unsupported commands

The module returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0xFF
Data length 2 2+N (version information)
Data 2+N
  • Data[0]: Command
  • Data[1]: Subcommand
  • Data[2…]: Version information in string format
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 55 AA 00 FF 00 07 70 24 31 2E 30 2E 31 87

Basic services

Heartbeat check (0x00)

  • The module sends heartbeats to the MCU every 15 seconds. If the MCU does not respond within the 90-second timeout period, the module considers a communication exception occurred and will restart the software.

  • The MCU can determine whether the module works properly by the regular heartbeat check. If the MCU does not receive a heartbeat packet as expected, it can use the reset pin to reset the module.

The module sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x00
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 00 00 0000 ff

The MCU returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x00
Data length 2 0x0001
Data 1
  • 0x00: The MCU returns this value only one time after a restart. The module uses this value to determine whether the MCU restarts during operation.
  • 0x01: The MCU returns this value except for the first response after a restart.
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example:
The MCU returns 0x55aa 03 00 0001 00 03 after a restart.
The MCU returns 0x55aa 03 00 0001 01 04 except for the first response after a restart.

Query product information (0x01)

Product information consists of the product ID (PID) and the MCU software version number.

  • PID: a unique identifier assigned to each product created on the Tuya Developer Platform for storing product information in the cloud.
  • MCU software version number: It is expressed in dot-decimal notation x.x.x where x is a decimal digit between 0 and 99.

The module sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x01
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 00 01 0000 00

The MCU returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x01
Data length 2 N
Data N {“p”:“AIp08kLIftb8x2x0”,
 “v”:“1.0.0”,
 “m”:1,
 “apn”:“cniot”,
 “mht”:60,
 “qr”:1,
 “slave”:1,
 “ext_ota”:[{
  “ch”:1,
  “v”:“0.1.1”
  },
  …
 {
  “ch”:n,
  “v”:“0.1.n”
  }],
 “U”:0,
 “dp_cache”:1,
 “cops”:“xxx”
“dp_ack”:1,
“online_tts”:0 }
apn is optional. If apn is not specified, the system will configure the APN settings automatically. mht, qr, and slave are optional.
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: {"p":"AIp08kLIftb8x2x0", "v":"1.0.0", "m":1}

  • p indicates the PID is AIp08kLIftb8x2x0.

  • v indicates the MCU version is 1.0.0.

  • m indicates the power consumption of the module.

    • 0: standard power.
    • 1: low power. The period of the provided timer is one second.
  • mht: the MQTT heartbeat interval for the module, in seconds. The default value is 300 seconds.

  • qr: specifies whether to get the short URL of the QR code for pairing.

    • 1: get the short URL.
    • 0: not get the short URL. If a device has been paired, the short URL will not be pulled.
  • slave: specifies whether the LTE Cat.1 module works in tandem with a Bluetooth LE module.

  • ext_ota: OTA update for subordinate MCU firmware. v: version information. The maximum length is 10 bytes, with up to six update channels supported. The update channels dedicated to the application firmware and basic firmware must not be used.

  • U: specifies the protocol for MCU OTA updates.

    • 0: protocol version 0

    • 1: protocol version 1

      • If slave is set and U is not set, protocol version 0 is used.
      • If both slave and U are set, 0 and 1 represent protocol version 0 and protocol version 1 respectively.
      • If both slave and U are not set, protocol version 0 is used.
      • If slave is not set and U is set, 0 and 1 represent protocol version 0 and protocol version 1 respectively.
  • dp_cache: specifies whether to enable DP cache. DP cache requires an additional cloud-based feature. For more information, contact your account manager.

    • 1: Enable.
    • Other values: Disable.
  • (Optional) cops: specifies the public land mobile network (PLMN) of the mobile operator. The value must be numeric encoding. For example, cops:"20416" is equivalent to AT command AT+COPS=1,2, "xxxxx". If you are using LTE Cat-M1 modules, check with your product manager to decide if this field needs to be set.

  • (Optional) dp_ack: specifies whether to enable acknowledgment (ACK) response. Set it to 1 to enable ACK. If the module does not receive an ACK message after it sends DP data to the MCU, it will transmit the packet again. A packet can be retransmitted up to three times, with an ACK wait time of 500 ms.

  • online_tts: setting it to 1 indicates that online text-to-speech (TTS) is supported. This feature applies when the module supports the audio service.

  • gps: GPS model, defaulting to Unicore UFirebird. Allystar’s GPS module also applies. When using the assisted GNSS (AGNSS) service, you need to specify the GPS model. The MCU integration protocol must be v1.1.3 or later.

  • env_pre: 1 for the staging environment, and other values for the production environment. The MCU integration protocol must be v1.1.3 or later.

  • net_type (for MA510 only): The MCU integration protocol must be v1.1.4 or later.

    • 0 or empty: Auto
    • 1: GSM
    • 2: LTE
    • 4: CATM
    • 5: NB-IoT

      When specifying this field, check the supported network types of the module.

Query working mode (0x02)

The working mode indicates how the network status is indicated and the way to trigger module reset. Theoretically, the module can work in the following two modes:

  • The MCU works with the module to process network events.

    • The module sends its current work status to the MCU through serial communication. The MCU controls the LED to indicate status accordingly.
    • When the MCU detects a request to reset the module, it directs the module to reset through serial communication.
  • The module processes network events itself.

    • The NET_MODE pin on the module drives the LED indicator to indicate the network status.
    • The GPIO input signal determines module reset. When the module detects a low level on the reset pin for more than three seconds, it will trigger a reset action. The following command specifies the GPIO pins of the LED indicator and the reset button. This feature is not available in low power mode.

    In the module self-processing mode, the LED indicator can only be defined by NET_MODE. In this case, the module does not report network status.

The module sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x02
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 00 02 0000 01

The MCU returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x02
Data length 2
  • 0x0000: The module works with the MCU to process network events. You need to implement the functionality mentioned in the above description.
  • 0x0002: The module processes network events itself.
Data 0/2 The data length is 2 bytes. The first byte indicates the GPIO pin of the LED indicator. The fixed value is 0. The second byte indicates the GPIO pin of the reset button.
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example:

  • The module works with the MCU to process network events: 0x55aa 03 02 0000 04 is returned.
  • The module processes network events itself: 0x55aa 03 02 0002 0c0d 1f is returned. 0x0c indicates the LED indicator is connected to GPIO12. 0x0d indicates the reset button is connected to GPIO13.

Report network status (0x03)

Network status Description Status value LED indicator in module self-processing mode
Status 1 The SIM card is not connected. 0x00 Steady on
Status 2 The module searches for cellular networks. 0x01 On for 0.1 seconds and off for 0.3 seconds
Status 3 The module is registered with the cellular network but not connected to the network. 0x02 On for 0.1 seconds and off for 1 second
Status 4 The module is connected to the network and gets an IP address. 0x03 On for 0.1 seconds and off for 2 seconds
Status 5 The module has been connected to the cloud. 0x04 On for 0.1 seconds and off for 3 seconds
Status 6 SIM card registration is denied, which might be because it is not subscribed to a cellular service provider. 0x05 On for 0.1 seconds and off for 0.1 seconds
Status 7 The device is ready for pairing. 0x06 On for 0.1 seconds and off for 2 seconds
Status 8 Unknown status 0xFF -

  • Network status
    • 1: The SIM card is not connected.
    • 2: The module searches for cellular networks.
    • 3: The module is registered with the cellular network but not connected to the network.
    • 4: The module is connected to the network and gets an IP address.
    • 5: The module has been connected to the cloud.
    • 6: SIM card registration is denied, which might be because it is not subscribed to a cellular service provider.
    • 7: The device is ready for pairing.
  • When the module detects that the MCU is restarted or reconnected, it will proactively send the current network status to the MCU.
  • When the network status of the module changes, the module will proactively send its current status to the MCU.
  • If you choose the module self-processing mode, implementing this protocol for your MCU is not necessary.

The module sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x03
Data length 2 0x0001
Data 1 See the description of network status.
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 00 03 0001 00 03

The MCU returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x03
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 03 03 0000 05

Reset the module (0x04)

When the LTE Cat.1 module receives the reset command, it unbinds the device from the cloud.

The MCU sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x04
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 03 04 0000 06

The module returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x04
Data length 2 0x0000
Data 0 None
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Example: 0x55aa 00 04 0000 03

Get version information (0x71 41)

The MCU sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x03
Command 1 0x71
Data length 2 0x0001
Data 1 Subcommand: 0x41
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

The module returns the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x71
Data length 2 0x0002+n
Data n
  • Subcommand: 0x41
  • Result:
    • 0: Failure.
    • 1: Success.
  • Version information in string format. Example:
    fw_name:xxx,fw_ver:xxx;app_name:xxx,app_ver:xxx;pro_name:xxx,pro_ver:xxx;
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.

Send QR code to MCU proactively (0x72 93)

After receiving the short URL of the QR code from the cloud, the module proactively sends it to the MCU. This feature is usually used on devices that have a screen to show the QR code.

The module sends the following data.

Field Bytes Description
Header 2 0x55aa
Version 1 0x00
Command 1 0x72
Data length 2 0x0001 + N
Data 1 + N
  • Subcommand: 0x93
  • Short URL string.
Checksum 1 Start from the header, add up all the bytes, and then divide the sum by 256 to get the remainder.