...
UART -> AT -> PU -> The telemetry value
Mechanical Connection
Electrical connection
UART at 2.8VPads on top side of tracker (Next to SIM holder, with pin 1 labeled 'VBAT'
Connector cable Pins:
pin 1: VCC(orange)
pin 2: RX(white)
pin 3: UART_GND - same as VIN_GND (ground for VIN which is the external power supply to the trackerno use(brown)
pin 4: TRACKER_TX (tracker TX on this pin)
pin 5: TRACKER_RX (external device TX on this pin)
...
no use(green)
pin 5: GND(black)
pin 6: TX(purple)
...
PCB-Pins(from left to right):
GND (black)
VCC(orange)
RX(white)
TX(purple)
GND_Battery(black)
V_Battery(blue)
UART Settings
115200 bit/s
8N1
no flow control
Data Protocols
Generic AT protocol
Send a message containing arbitrary data to the cloud via the tracker:
...
If the PU message could not be uploaded to the cloud the Send OK\r\n is not sent. In future versions of this protocol we plan on adding a known timeout value and an error response once this timeout has occurred. For now we need to manage timeouts in the PU protocol. See below.
Example
Send powunity20:
PU_MSG:
powunity20PU_MSG_LEN: 10
Resulting AT command:
AT%TEST=*1234,230*(10,powunity20)#\r\nResulting AT repsonse after tracker receipt:
OK\r\nResulting AT response after tracker could send to the cloud:
Send OK\r\n
Sending the data via a serial terminal (left side of picture). The message can be seen on http://traccar.powunity.com in the Input tracker attribute:
...
| Info |
|---|
The tracker state will change with the next message sent by the tracker. The Input field will be gone then. You can still view old Input values using Report → Position in the lower section. Make sure to enable the Input column by clicking on the down error in the report columns. |
PowUnity message protocol
...
The difference when using PowUnity’s protocol versus the generic AT Protocol, is that the various fields will get mapped to their own distinct attributes in the position object and some will get copied over to the following position objects even when there is no new data coming from the bike (think of eBike SOC e.g.)
The PU_MSG is an 8-bit ASCII encoded string made up of a version field and one or more data label+value pairs. The version and data pairs are delimeted by the | character. The data label and data value are delimited by the @ character.
...
There can be more than one DATA_LABEL@DATA_VALUE pairs, however, the maximum PU_MSG length must not exceed 16 bytes/characters.
Version 1.1
Data label | Description | Unit | Example |
|---|---|---|---|
0 | Reserved | ||
1 | Internal retry counters: msg_count,retry_count | - | 42,7 for msg number 42 since powerup, and transmission this is the 7th try to upload it |
2 | Battery remaining in % | % | 42 for 42% battery remaining |
2
Battery voltage in 1/10 V
1/10 V
3 | Battery total capacity in 1/10 Ah - | 1/10 Ah | 135 for 13,5 Ah max. battery capacity |
4 | AssistLvl | Step | |
5 | BattRange | 1/10 km | |
6 | LightState | Binary | |
7 | Speed - | 1/10 km/h | |
8 | Odometer | 1/10 km | |
9 | Trip | 1/10 km |
After the PU_MSG has been sent the telemetry device should await the PU_ACK message (see the AT protocol section above) and determine if the message should be resent after a timeout.
For sending battery telemetry (a PU_MSG containing battery information) we recommend waiting for the PU_ACK message for 1 minute and, if no PU_ACK, sending it again,until a PU_ACK is received. Once a PU_ACK has been received we recommend to wait 10 minutes before sending the next battery telemetry message.
Example
...
Report 13,8 Volt battery voltage and battery 87% charged and assist level 3:
PU_MSG:
1|1@872@87|2@1384@3Resulting AT command:
AT%TEST=*1234,230*(1210,1|1@872@87|2@1384@3)#\r\nResulting AT repsonse after tracker receipt:
OK\r\nResulting AT response after tracker could send to the cloud:
Send OK\r\n
...