Smart Electric Motorcycle Development Guide

This guide is written for hardware / firmware / app developers who want to build smart electric motorcycle products (including electric mopeds) on the Tuya Developer Platform.
Smart electric motorcycles share the same overall solution architecture as the existing "smart electric vehicle (e-bike)" reference. This document follows the same eight-step development trunk and weaves the motorcycle-specific differences (new GB national standard classification, license plate, BLE+X hardware architecture, dashboard ↔ app interaction) directly into each step, so you don’t have to jump between pages.

Before You Start: Identify the Vehicle Class

In China, "electric two-wheelers" are split into three classes by GB 17761-2024 (the new national standard) and the Safety Requirements for Electric Motorcycles and Electric Mopeds. Different classes have completely different compliance, registration, license, category and panel rules, so you must align on this before development.

Class	Top speed	Legal nature	Driver license	License plate
Electric bicycle (e-bike)	≤ 25 km/h	Non-motor vehicle	Not required	Small yellow plate
Electric moped	≤ 50 km/h	Motor vehicle	Class F	Blue plate
Electric motorcycle	> 50 km/h	Motor vehicle	Class E / D	Large yellow plate

The new standard introduces several hard requirements that have the biggest impact on development:

• Over-speed power cut-off: e-bike models capped at 25 km/h must mandatorily cut motor power on over-speed.
• Three-piece anti-tamper: battery, controller and speed limiter must mutually authenticate so that the speed limit cannot be bypassed by a simple modification.
• Plastic content: ≤ 5.5% of total vehicle mass, to control fire risk.
• CCC certification: must be issued against the new GB 17761-2024 standard.
• Commercial fleet positioning + safety monitoring: commercially operated vehicles must support BeiDou positioning, communication and status monitoring — exactly the Tuya Developer Platform’s core strengths.

Key timeline:

• From 2025-09-01, all newly produced vehicles must comply with GB 17761-2024
• From 2025-12-01, vehicles that do not meet the new standard are banned from sale

If you are working on > 25 km/h vehicles (electric mopeds / motorcycles), follow the full flow below. If you are working on ≤ 25 km/h e-bikes, this guide still applies — just pay extra attention to the over-speed cut-off and anti-tamper DPs in Step 1 (feature definition).

Create the Product

Prerequisites

• A registered Tuya developer account
• Enterprise verification is recommended to unlock more feature permissions

Steps

Open the Tuya Developer Platform → Create Product → in the Standard Category navigation choose:

Outdoor Travel  ➜  Travel  ➜  Smart Electric Vehicle

Note: Smart electric motorcycles, mopeds and e-bikes currently share the same Smart Electric Vehicle category. Choosing the wrong category directly affects the recommended DPs, panel selection and app integration logic later, so don’t change it casually after creation.

After the product is created the platform generates a PID (Product ID). All subsequent firmware / app / cloud integration is keyed on this PID.

Feature Definition (DPs)

Tuya abstracts hardware capabilities into DPs (Data Points), in three categories:

Type	Defined by	Use case	Examples
Standard	Pre-built by Tuya	Common capabilities	Lock / unlock, battery, speed, location
Custom	You define	When standards are not enough	Proprietary BMS fields, custom riding modes
Advanced	Activated on the platform	Cross-device / cloud-side business	QR-code pairing, NFC card management, track recording, password management

There are exactly six DP data types: Boolean (bool) / Value / Enum / Fault (bitmap) / String / RAW (raw transparent).

Common DPs for E-motorcycles (excerpt)

The table below lists the actual values from the Tuya platform’s "Smart Electric Vehicle / E-motorcycle" standard DP template. Use it as the minimum viable set when creating a new product — pick the corresponding DP IDs directly during development.

DP ID	Function	Identifier (ID)	Type	R/W	Description
1	Anti-theft switch	blelock_switch	bool	rw	BLE anti-theft arm / disarm switch
2	Start	start	bool	rw	Vehicle start / power-on control
3	Battery percentage	battery_percentage	value	ro	0~100, remaining percentage of the main battery
4	GPS position	gps_position	string	ro	Latitude/longitude string, see vehicle positioning protocol
5	Speed	speed	value	ro	km/h, 0~250, recommended ≥ 1 Hz reporting
6	Single-trip time	ridetime_once	value	ro	seconds, accumulated riding time since current power-on
11	Unit setting	unit_set	enum	rw	km / mile, display unit on dashboard and in app
12	Total mileage	mileage_total	value	ro	km, accumulated since power-on, persists across power loss
13	Estimated range	endurance_mileage	value	ro	Predicted range computed dynamically from current battery
14	Single-trip mileage	mileage_once	value	ro	km, accumulated since current power-on
18	Riding mode	level	enum	rw	eco / normal / sport etc.; e-motorcycles usually have ≥ 3 modes
19	Find vehicle	search	bool	rw	Triggered by the app to beep / flash for location
24	GPS signal	gps_signal_strength	value	ro	GPS signal strength level
25	4G signal	4g_signal_strength	value	ro	4G signal strength level
26	Fault detection	fault_detection	bool	rw	App-initiated whole-vehicle fault self-check
27	Status	status	enum	ro	Vehicle state machine (idle / riding / charging / fault, etc.)
29	Power system	power_system	fault	ro	Fault bitmap: motor / controller / speed limiter, etc.
30	Smart system	smart_system	fault	ro	Fault bitmap: head-unit / communication / positioning, etc.
31	Electronic system	electronic_system	fault	ro	Fault bitmap: dashboard / lights / horn, etc.
32	Lithium battery system	ithium_battery_system	fault	ro	Fault bitmap: battery / BMS related
45	Geofence	geofence_switch	bool	rw	Geofence switch, requires the geofence advanced feature on the platform
58	Battery #1 info	battery_info	string	ro	Detailed main-battery fields (voltage / temperature / cycle count, etc.)
60	ICCID	iccid	string	ro	ICCID of the 4G module’s SIM, used for positioning / billing / SIM platform integration

Bitmap design example for fault DPs (fault type)

For an e-motorcycle, split faults into 4 sub-system fault DPs (power_system / smart_system / electronic_system / ithium_battery_system). Each DP encodes one class of fault source by bit (refine the layout against your real vehicle fault list):

power_system            smart_system           electronic_system      ithium_battery_system
bit0  Motor over-temp   bit0  4G link lost     bit0  Dashboard comm.   bit0  Battery low
bit1  Hall sensor       bit1  BLE link lost    bit1  Dashboard light   bit1  Battery over-temp
bit2  Controller temp   bit2  GPS lost lock    bit2  Headlight         bit2  Battery under-volt
bit3  Controller over-I bit3  Cloud auth fail  bit3  Turn signal       bit3  Battery over-volt
bit4  Speed limiter     bit4  OTA interrupted  bit4  Horn              bit4  Cell delta alarm
bit5  Power under-volt  ...                    ...                    bit5  BMS comm. error
...                                                                  ...

Recommendation: always use the fault type + bitmap for fault DPs, do not create one bool DP per fault. Splitting by sub-system makes the app’s fault alarm classification clearer and easier to extend.

When to Use a Custom DP

Whenever no exact match exists in the standard DP catalogue, add a custom DP. For example:

• A per-cell voltage array reported by your BMS → use a RAW DP and define your own byte protocol
• A proprietary "commute mode" voice prompt switch → use a bool DP commute_voice_enable

Advanced Features (activate on demand)

The most commonly used advanced features for e-motorcycles:

• QR-code pairing: users scan the QR code on the vehicle in the app to bind, without typing a PID
• NFC card management: replaces the physical key
• Track recording: cloud-side ride track recording with in-app playback
• Password management: local 4–6 digit unlock code
• BLE keep-alive: auto unlock when the phone is near, auto lock when far away
• Direct device-to-cloud: 4G version connects to the cloud directly, bypassing the phone

Configure the App Panel

Which App to Use

The Smart Electric Vehicle / E-motorcycle category must use Tuya’s dedicated travel app, not the "Smart Life" app. Pick the version by sales region:

Sales region	Control app	App store search keyword
Mainland China	Tuya Chuxing (涂鸦出行)	涂鸦出行
Overseas	Tuya Ride	Tuya Ride

Important reminder: The development platform shows a default tip "Use SmartLife app to scan and try" — this is incorrect for the smart electric vehicle category. Pick the right app per sales region (Tuya Chuxing / Tuya Ride) when previewing and testing the panel.

The Stock Panel: "Travel E-Vehicle Stock Panel"

Tuya Chuxing / Tuya Ride ships with a built-in "Travel E-Vehicle Stock Panel", which 90% of e-motorcycle customers can use out of the box without any customization. The screenshot below shows the actual home page (3D vehicle model + battery / range / speed / signal status + one-tap lock + shortcuts for riding mode / unlock method / lights / sound):

Capabilities covered by the stock panel:

• Home: vehicle 3D status card (battery, range, speed, 4G / GPS / BLE signal)
• Control: one-tap lock / unlock, riding mode switch, find vehicle
• Settings: unlock method, lights, sound, speed limit, anti-theft sensitivity, NFC card management, password management
• Services: health report, track playback, geofence

Only consider applying for a custom panel if you have strong differentiation needs (custom BMS detail page, brand-specific 3D model, brand colors, etc.).

A Suggestion: Roles of the Phone vs. the Dashboard

E-motorcycles are ridden at high speed, so looking at the phone while riding is itself a safety hazard. The intelligent design principle therefore differs from e-bikes:

• The dashboard is the primary entry point during riding: navigation turn prompts, incoming calls, messages and vehicle alerts must be presented on the dashboard
• The phone leans toward "non-riding scenarios": remote vehicle status, parameter configuration, track analytics, alert push

Example: a rider receives a call mid-ride; the dashboard shows the caller info and the rider answers / hangs up using a handlebar button — the phone never leaves the pocket. This is the standard interaction model for smart e-motorcycles, almost never seen on e-bikes.

Hardware Design

Tuya provides two hardware integration paths for e-motorcycles. Pick one based on your main control compute power and cost:

Path	Main control	Module	Suitable for	Difficulty
MCU SDK	Your own MCU	Tuya BLE / 4G module	Mainstream, most common	Low
TuyaOS	Module runs the business logic	TuyaOS-compatible module	Plenty of resources, want cross-platform	Medium

Choosing the Communication Protocol

Scenario	Recommended
Standard e-motorcycle, users mostly control via phone	BLE (Bluetooth Low Energy)
Commercial fleet / large vehicles	BLE + 4G dual-mode
Overseas / export models	BLE first, add 4G when needed

BLE is the primary communication protocol for e-motorcycles for three reasons:

1. Low power consumption, no impact on standby current
2. Almost every phone supports it natively, no extra cost for the user
3. Combined with Tuya’s "BLE keep-alive" advanced capability it enables seamless unlock

Hardware Form-Factor Options

By "feature granularity" and "cost", e-motorcycle intelligence has three typical form factors. All three are built on the BLE+X Hardware Architecture below and can be upgraded smoothly:

Form factor	Communication	Typical features	Use case	Installation
① BLE anti-theft device	BLE only	One-tap start/stop, find vehicle, BLE proximity unlock, anti-theft alarm	Entry-level e-motorcycle, near-field experience only	Standalone module, single power rail
② 4G smart head-unit	BLE + 4G + GPS	Remote positioning, remote control, seat lock, analog input/output	Mid/high-end e-motorcycle, fleet / operations	Standalone box, reusable across models
③ 4G dashboard	BLE + 4G + GPS (integrated)	Full dashboard display + all remote capabilities, highest integration	Integrated whole-vehicle design, BOM reduction	Built into the dashboard, no extra parts

Selection advice: pure C-end entry-level → ①; operations / fleet / high-end whole vehicle → ②; new model with a planned dashboard refresh → ③.

BLE+X Hardware Architecture

The BLE+X architecture uses the Bluetooth module (BLE) as the system hub. UART links the BLE module to the vehicle MCU and the 4G (CAT.1) module: BLE handles near-field control, low-power keep-alive and power management; 4G provides remote capabilities; the MCU runs the vehicle business logic. The standalone GPS module is recommended to hang directly on the MCU UART, with the MCU parsing NMEA data and reporting on demand.

                           ┌──────────────┐
                  ┌──UART──┤ 4G CAT.1 mod │── ✈ Cloud
                  │        └──────────────┘
            ┌─────┴────┐
            │ BLE mod   │── 📱 BLE direct ── Tuya Chuxing / Tuya Ride
            │ (BF6H-M) │
            │ System hub │
            │ + Power mgmt│
            └─────┬────┘
                  │ UART
                  │
            ┌─────┴────┐         ┌──────────────┐
            │   MCU    │── UART──┤ Standalone GPS │── Satellites
            │ Vehicle  │         │ GB600/610 etc. │
            │ business │         └──────────────┘
            └──────────┘

Routing GPS through the MCU has three benefits: ① BLE module IO is freed up to focus on communication; ② the vehicle business logic gets raw positioning locally, making track filtering and geofence checks more efficient; ③ GPS power-on timing aligns naturally with the vehicle ignition / start state machine.

Key Pins of the BLE Module (BF6H-M as example)

Pin (silkscreen)	IO	Direction	Function
TXD0 / RXD0	PD7 / PD6	OUT / IN	UART to the 4G module
TXD1 / RXD1	PA3 / PA2	OUT / IN	UART to the MCU
PWM1	PA7	IN	Cellular → BLE wake (active low ≥ 60 ms)
PWM0	PA6	IN	Cellular presence detection (active low, used across PCBs)
PWM5	PA5	OUT	BLE → 4G module power control (high = power on)
PWM4	PA4	OUT	Reserved peripheral power control (high = power on), pick per design
PA1	PA1	OUT	BLE → MCU wake (high ≥ 20 ms before sending data)
PA0	PA0	IN	MCU → BLE wake (high ≥ 50 ms before sending data)

Vehicle sleep / wake: the BLE acts as the system power manager. In standby it actively powers down the 4G module to save energy. When a remote command arrives, the 4G module wakes BLE through PWM1, then BLE wakes the MCU. GPS power is managed by the MCU and follows the vehicle ignition / start state machine.

Critical Handshake Timing

• Cellular wakes BLE: before the 4G module sends UART data, PWM1 outputs a low pulse ≥ 60 ms to ensure BLE has exited sleep.
• BLE wakes MCU: PA1 stays high for ≥ 20 ms before sending UART data; the MCU uses an IO interrupt to wake.
• MCU wakes BLE: PA0 stays high for ≥ 50 ms before sending UART data, to avoid byte loss.
• Pull low after data: the wake line is pulled low after the data transfer ends, returning to low-power state. The duration is configurable via UART commands.

Voltage Level Matching

The UART between the BLE module (3.3 V) and the 4G module (1.8 V) must go through level translation to avoid port damage or unstable communication. Two recommended approaches:

Approach	Components	Strengths	Suitable for
Bidirectional level translator IC	TXS010X / SN74LVC family	Few parts, strong noise immunity, automatic bidirectional	First choice for mass production
Discrete NPN inverter	S8050 + pull-up resistors (10 kΩ + 1 kΩ)	Lowest cost	Minimalist / low-cost backup

Standalone GPS Module Integration

The recommended approach is to hang the standalone GPS module directly on the vehicle MCU’s UART. The MCU parses the NMEA messages and reports positioning, speed and satellite count as DPs on demand. This frees up the BLE UART resource and lets the MCU control the GPS power-on timing freely.

Recommended GPS module	Vendor	Band	Use case
GB600	Tuya	L1 single-band (GPS / BDS / Galileo / QZSS / GLONASS five-system multi-mode)	First choice for entry-level / cost-driven mass production. Beken BK1661 SoC, small form, low power
GB610	Tuya	L1 + L5 dual-band (multi-mode multi-frequency joint positioning, including BDS B2A/B2B/B2I, Galileo E5A, etc.)	High-precision scenarios. Beken BK1662 SoC, 120 tracking channels, cold start ≈ 28 s, tracking sensitivity −165 dBm

Both modules are documented at Tuya Developer Center · GNSS Modules with full datasheets and sample code. For new designs, default to GB600; switch to GB610 only when positioning accuracy is critical (fleet, dense urban areas with high-rise occlusion, etc.).

Wiring tips:

• MCU UART ↔ GPS UART: default baud rate 9600 / 115200, configured per vendor; only RX/TX are required, PPS can optionally be wired to an MCU interrupt pin for time sync.
• Power: GPS modules are typically 3.3 V powered; switch them on/off via an MCU GPIO or an LDO enable pin and cut power during vehicle sleep.
• Antenna: e-motorcycles have lots of plastic and metal fuel-tank shielding. Place the antenna on top of the dashboard or on the rear grab rail, away from shielding bodies, with a GND reflector reserved.
• Voltage levels: MCU and GPS are both typically 3.3 V — no level translation needed. If the GPS is 1.8 V, refer back to Voltage Level Matching.

Tuya Recommended Module List

The following modules have been validated in e-motorcycle scenarios and can be picked directly. All datasheets and SDK documentation are searchable at the Tuya Developer Center:

4G Modules (pick by sales region)

Model	Sales region	Bands	Size	Resources
L511C-Y6E	China	LTE FDD B1/3/5/8, TDD B34/38/39/40/41	17.7×15.8×2.3 mm	datasheet · MCU SDK
L511E-Y6E	Europe / SEA / Africa / Oceania / Middle East / HK MO TW	LTE FDD B1/3/5/7/8/20/28, TDD B38/40/41	same as above	same L511 family
L511A	North America	LTE FDD B2/4/5/12/13/14*/66/71	same as above	same L511 family
MG661-LA-19	Latin America	LTE FDD B2/3/4/5/7/8/28/66	—	—

BLE Module

Model	Sales region	Band	Size	Resources
BF6H-M	Global	2.4 GHz ISM band	19×15.5×2.5 mm	datasheet · MCU SDK

Pick the 4G module by sales region, and use BF6H-M for BLE everywhere. Other 4G modules (NL668-AM / MC665-EU / MA510-GL, etc.) have been integrated as well, but they exist as compatibility options for legacy stock or special customer demand. New designs should default to the L511 family.

Firmware Development

MCU SDK Path (recommended for 90% of customers)

Workflow:

Your MCU                 Tuya BLE module             Phone app / Cloud
┌──────────────┐ UART  ┌──────────────┐ BLE/4G  ┌────────────────────┐
│  Vehicle     │<----->│ Tuya standard │<------> │ Tuya Chuxing /     │
│  business +  │ TX/RX │ protocol      │         │ Tuya Ride          │
│  MCU SDK     │       │ (Tuya generic │         │ + Tuya Cloud       │
└──────────────┘        │  integration) │         └────────────────────┘
                        └──────────────┘

What MCU SDK does for you:

• Frame packing / parsing (you only deal with DPs, not bytes on the UART)
• Heartbeat, state machine, reconnection
• OTA reception and verification
• Time sync, pairing state machine

You only need to implement two callbacks:

• dp_download_handle() — control DPs sent down by the app (e.g. lock vehicle)
• dp_report() — report current state DPs (e.g. speed, battery)

TuyaOS Path

The module itself runs the TuyaOS kernel, and the vehicle MCU integrates through a simple interface. The advantage is that the same business code can be reused across different chip platforms and protocols (BLE / cellular). The downside is that you need to pick a module that supports TuyaOS.

When to use TuyaOS:

• A single model needs to ship in BLE and BLE+4G variants
• The vehicle MCU is resource constrained and you want the business code to run on the module
• You want to use TuyaOS components directly (OTA / KV storage / RPC)

A Few Hard Rules for Firmware Development

• DP reporting frequency: high-frequency DPs (speed, position) ≥ 1 Hz; low-frequency ones (battery, mileage) report on change only — avoid blindly flushing the link
• OTA chunking: e-motorcycle firmware is often ≥ 1 MB. BLE OTA must support resume; large 4G OTA versions should be pushed during charging to avoid eating user data
• Fault reporting: report through fault DPs + bitmap, not 100 separate bool DPs
• Power-loss protection: cumulative values like mileage and ride records must be persisted to Flash and survive power loss
• New national-standard compliance: speed limit, over-speed cut-off and the three-piece anti-tamper status all need DPs for audit

Product Configuration

In the developer platform’s "Product Configuration" page, enable / configure the following items as needed:

Configuration item	E-motorcycle focus
Firmware upgrade	Enable for both BLE and 4G; prefer pushing large versions during charging to save user data
Multi-language	Mandatory: zh-CN and English are the baseline; for export add Spanish / Portuguese / Vietnamese / Indonesian
Pairing info	Choose BLE pairing; the 4G variant needs no pairing
Device push notifications	Anti-theft alarms, low battery, over-speed, geofence breaches all go through the push channel
Scene linkage	Rarely used on e-motorcycles, skip for now
Quick switches	Place high-frequency operations like one-tap lock and find vehicle on the app home page
Product manual	Use the platform’s electronic manual to save print costs

Pairing Examples (Bluetooth)

E-motorcycles have no Wi-Fi, so the only pairing channel is Bluetooth. Tuya recommends two BLE pairing methods — pick one or run both based on your production workflow and target users:

Approach	Trigger	User action	Use case
A · BLE trigger pairing	The user performs a physical action on the vehicle (e.g. press anti-theft button for 5 s, ignite 3 times in a row) to enter discoverable advertising	Discover automatically on the app’s "Add device" page	Entry-level, anti-theft form factor, factories that don’t want extra printing steps
B · BLE QR-code pairing	A unique QR code (containing PID + MAC + one-time binding token) is pre-printed on the vehicle / packaging	"Scan" inside the app for one-tap binding	Mid/high-end whole vehicle, 4G dashboard / smart head-unit, premium unboxing experience

Comparison

Dimension	A · Trigger pairing	B · QR-code pairing
User experience	Average: requires reading the manual to learn the trigger action	Smooth: scan to bind, near-zero learning cost
Mis-binding prevention	Weak: multiple nearby vehicles broadcast the same name, user must distinguish	Strong: QR code carries unique MAC + token, 1:1 lock
Production process	Simple: no need to generate / print per-device codes	Complex: production line must generate, print and apply per-device codes
After-sales replacement	None	Lost QR code requires customer-service replacement / re-trigger
Platform dependency	Standard BLE pairing, supported by all BLE-version devices by default	Requires the "QR-code pairing" advanced feature to be enabled in product configuration
Recommended pairing	Entry-level e-motorcycle / BLE anti-theft form factor	4G smart head-unit / 4G dashboard whole vehicle

Recommendation: prefer option B for high-end / whole-vehicle shipments, and keep option A as a fallback when needed (e.g. the QR code is lost or damaged).

Push Notification Examples

Trigger	Push content
Vibration ≥ threshold detected while parked	"Your scooter Pedal-26B has detected unusual vibration"
Battery ≤ 20%	"Battery is low, please charge soon"
Outside the geofence	"Your vehicle has left the usual area"
OTA complete	"New firmware is ready; please restart the vehicle to apply"

Flashing & Authorization

Once the firmware is ready, you need to flash it together with the authorization code to the device, otherwise it cannot connect to the cloud.

📘 Official documentation entry: full schemes, flashing-tool downloads, per-module (BLE / 4G) pin wiring and production-test flows are at the Tuya Developer Center → Flashing & Authorization (official docs).

Tuya’s Three Official Authorization Schemes

Tuya groups flashing & authorization into three categories by chip type / production system:

Official scheme	Suitable for	Description
Flashing & authorization combined	Tuya standard modules	① Tuya flashes them for you and ships directly; ② or you use Tuya’s "cloud-module flashing & authorization" tool yourself
Flashing & authorization split	Debug stage / non-Tuya-standard modules	Authorization only; firmware is flashed with the chip vendor’s tool
Production-test integration	Customers with a complete production system	Integrate with your own production line via Tuya’s standard interfaces and complete flashing + authorization in-house

For detailed scheme selection and the production-test interface spec, see the official documentation above.

Practical Methods for E-motorcycle Production

In e-motorcycle mass production, the following four practical methods are common (each maps back to one of the official schemes above):

Method	Suitable for	Maps to official scheme	Notes
Online flashing	Prototype stage	Flashing & authorization combined	Device authorized directly via the Tuya cloud
Offline flashing	Factory mass production	Flashing & authorization combined	Authorization package is pushed in advance
Whole-vehicle authorization	Once at the end-of-line vehicle test	Flashing & authorization split / Production-test integration	Recommended, merge with the EOL station
MCU self-flashing	The MCU runs the authorization flow itself	Production-test integration	MCU SDK path only

Production Recommendations

• One authorization code per PID — do not reuse
• Include "power on/off check + BLE connection test" as an EOL test item to avoid missed flashing
• Different modules (BLE / 4G) have different flashing pins, programmers and drivers — prepare fixtures and production-test scripts according to the corresponding section in the official documentation

Product Testing

A test report is mandatory before release. Pick one of three paths:

1. Self-test: download test cases from the "Testing Service" page, run them, and upload the report
2. Tuya Cloud Test app: run the cases directly through the cloud test app
3. Tuya testing service: pay Tuya’s testing team to do it for you

E-motorcycle testing has extra focus areas:

• BLE stability at high / mid-low speeds (vibration, far from phone)
• DP state self-healing after a 4G outage and reconnection
• Battery DP accuracy under extreme temperatures
• OTA recovery after a mid-flash power loss
• New-standard compliance: DP and alarm path after speed-limit cut-off and anti-tamper triggers

Release & Certification

Release

Once the test report passes, click "Release" on the developer platform. After release the PID becomes usable for mass-production authorization.

Required Certifications

Certification	China	Overseas (typical)
Whole vehicle	CCC (GB 17761-2024)	E-mark / EEC / DOT
BLE module	SRRC	FCC / CE-RED / KC / TELEC
4G module	CTA + SRRC	FCC / CE-RED / GCF
Battery	GB 31241	UN38.3, IEC 62133

Reminder: CCC must be issued under the new GB 17761-2024 standard. Old-standard certificates expire after 2025-12-01.

Appendix A: E-motorcycle vs E-bike Quick Comparison

Dimension	E-bike	E-motorcycle
Top speed	≤ 25 km/h (mandatory cut-off)	50 / unlimited
Main control compute	Modest	Mid/high, dashboard SoC class
Dashboard	Mostly segment LCD	TFT color screen, capable of interaction
Rider’s line of sight	Low speed allows looking at phone	High speed prohibits relying on the phone
Pairing protocol	BLE	BLE primary, 4G optional
Anti-tamper	Three-piece (mandatory)	Whole-vehicle level
Typical DP count	30–50	50–100
Price range	RMB 1,500 – 5,000	RMB 8,000 – 50,000
Smart-tech headroom	Limited	Large (navigation, ADAS, calls, screen mirroring)

Appendix B: E-motorcycle FAQ

Q1: A customer offers both e-bike and e-motorcycle models. How many PIDs should we create?
A: At least two. E-bike and e-motorcycle differ heavily in DPs, panel layout, and new-standard compliance — bundling them into one PID makes long-term maintenance painful.

Q2: Which hardware form factor should we choose (BLE anti-theft / 4G smart head-unit / 4G dashboard)?
A: Pure C-end entry-level, cost-sensitive, near-field control + anti-theft only → BLE anti-theft device; operations / fleet, remote positioning + remote control needed → 4G smart head-unit (a standalone box reusable across models); new model with a dashboard refresh in the plan → 4G dashboard (highest integration, no extra parts on the vehicle). All three sit on the same BLE+X architecture and can be upgraded smoothly — see Hardware Form-Factor Options and BLE+X Hardware Architecture.

Q3: Should an e-motorcycle add a voice assistant?
A: First nail the dashboard display and handlebar button interaction, then consider voice. Wind noise and helmet usage during riding hurt recognition rate significantly — voice is a nice-to-have, not a must-have.

Q4: Which app do we use for overseas models?
A: Use Tuya Ride (the overseas counterpart of "Tuya Chuxing"). Same panel capability, just pick the right app per sales region. Overseas dev focus: i18n, regional compliance (GDPR / CCPA), 4G band fitting.