Sinocastel IDD-212G

Sinocastel IDD-212G Diagnostic GPS Tracker

This is a diagnostic GPS tracker that connects to a car's OBD II connector and can be used to provide location information along with several car parameters.

Product page link here
This device has the option to add a GPS receiver which can be used to provide tracking information.
The following picture is taken from the supplied user manual.


The G-mouse interface is  a special connector with a standard RS232 interface. The pinout is shown in the picture below.
IDD212G Pinout

The device can be programmed through this interface and also connect to the GPS receiver to acquire the tracking data.
 Sinocastel has a special programming cable which is basically a USB to serial cable that provides power to the device for programming. The programming software can be downloaded from here along with the drivers for the USB to serial cable.
When the OBD connector is plugged in the G-mouse interface runs at 4800bps in order to communicate with the GPS receiver.
In order to program the device it should NOT be plugged in to the OBD car connection and it must be powered through the G-mouse interface. The default G-mouse connection speed during programming is 115200bps.

Pictures from the Internals of the device

Connections viewed from the front
 RED Connector - GPS/Programming connector
 1 - Tx, 2 - GND, 3 - +5V, 4 - Rx
Green Connector - Looks like it's a micro USB port but the connector is smaller and uUSB cable will not fit
Pink - GSM Card slot  







Bottom view - GSM Slot
Top View
OBD Connector


Programming Commands and TCP Communication
I was able to get the command structure information by using a serial port monitor software when using the programming software of the device. Also a VB .NET disassembler was used to extract the information about the various commands hex codes and CRC32 checksum calculation.
For the TCP communication a tcp port monitor software was used along with a network traffic monitoring software. The unit was programmed to report to a local pc ip address which was then redirected to the official server and so in this way i was able to monitor both the server responses and the unit traffic.

It looks like the serial programming commands and the TCP communication commands follow the same structure.
This is a sample command sent to the module through the serial interface to request the device version

 HEX Code                                                                                    ASCII Representation
 40 40 1E 00 00 00 00 00 00 00 00 00 00 00 00 00   @@..............
 
 00 00 00 00 00 00 00 00 12 0E F1 96 0D 0A         ..........ñ–.. 

When requesting something from the device the command starts with 40 40 (@@)

    40 40       1E 00          00 .... 00 00 00 00 00
    |____|     |_____|         |______________________|
 Command start    |          19 characters with the device serial number*
                  |          plus one byte zero padding (00) 
          Number of bytes
        in the request packet
        LSB first MSB second 
 
 12 0E              F1 96              0D 0A
|______|                          |_____|                          |_____|
2 bytes with the           2 bytes with CRC32           Ending bytes of the packet
request command        checksum of all the            Always 0D 0A
                                   previous bytes **

* Note : The device serial number is not sent other the serial connection from the PC but only when it is a network connection

** Note: The CRC32 checksum is calculated to 16-bits so slight modifications to the standard calculation must be done. It must be calculated with a starting polynomial of &H8408 (hex) and initial value for the checksum as &HFFFF. You can find sample code for CRC32 implementation in VB .NET here but replace with the following initial values

Dim poly As UInteger = &H8408UI
and 
Dim crc As UShort = &HFFFFUI
The result must be reversed (LSB first MSB last) so for the example above the result from the function would be 96F1

Example Packets
Packet Sent at PowerUp
24 24 3F 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00 20 01 4F 00 00 00 A9 EB F7 51 02 1E 07 0D 10 24 3A CC 91 88 07 D0 62 2C 07 00 00 00 00 03 00 00 00 00 01 3F D2 0D 0A

Reply from Server
40 40 2A 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00 10 01 A8 05 00 00 FF FF FF FF FF FF FF FF 6E 4C 0D 0A

Update message from device
24 24 34 00 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 00 20 0C 4F 00 00 00 A9 05 00 00 76 EB F7 51 00 06 80 00 06 00 00 00 00 00 56 F8 0D 0A

Packet Start
Number of Bytes
Device Serial Number (19 characters plus zero padding at the end)
Comand/Message Type
Trip Number
Unix Time
GMT Date/Time (from GPS)
GPS Coordinates (Northing)
GPS Coordinates (Easting)
Checksum
Message Number
Packet End

GPS Module
As it was mentioned before the GPS module is operating at 4800bps and requires +5v supply.
Here is a picture of the receiver internals
GPS Module internals
On the right you can see the GT-1613 GPS receiver. Some information is available here


The IC on the top left is an SP3220 RS232 Receiver-Driver which basically translates the TTL levels of the GPS module to RS232 levels. This device can be plugged directly to a PC serial port and monitor the output using hyperterminal or putty.
The receiver will output the location data every second using the NMEA-0183 ASCII format. The device output looks like this

$GPVTG,,T,,M,0.050,N,0.092,K,A*2D
$GPGGA,144144.00,XXXX.XXX,N,YYYYY.YYYYY,E,1,04,7.35,162.6,M,25.0,M,,*55
$GPGSA,A,3,25,02,05,12,,,,,,,,,11.39,7.35,8.69*3D
$GPGSV,1,1,04,02,20,044,26,05,28,085,29,12,40,121,25,25,81,085,28*7B
$GPRMC,144145.00,A,XXXX.XXXXX,N,YYYYY.YYYYY,E,0.119,,080713,,,A*78

XXXX.XXXXX is the Latitude
YYYYY.YYYYY is the Longitude

You can use this location information to search on Google Maps but move the decimal point two places to the left. So XXXX.XXXXX should become XX.XXXXXXXX and YYYYY.YYYYY should become YYY.YYYYYYYY.
For more information about the command structure check out the datasheet of this receiver which is very similar.

16 comments:

  1. Hi there, I've a Sinocastel IDD-212G too and I'm trying to decode RAW data incoming from device when vehicle is running. Do you have a sort of document with protocol specification? It seems to me that device only sends data, but server never reply back.. for me is important to decode device upload data protocol (via GPRS/TCP connection, not the serial one with PC..)

    Thanks a lot!

    ReplyDelete
    Replies
    1. Hi. I updated the post with a few examples. I was able to understand what most of the numbers mean but some i am not sure. If you need help with a specific packet let me know and we'll see what we can do.

      Delete
  2. Hi, I couldn't find any specification sheet either so i tried to decode it myself. I created a small server which basically would forward requests between the device and the server and recorded those responses by monitoring the network traffic. The communication protocol is pretty similar to the serial protocol. I'll have to take a look at my notes to give you more information (maybe later today).

    ReplyDelete
  3. Yeah, I tryed to decode incoming packets from my device using your Example Packest specification, and 'Packet Sent at PowerUp' fits perfect with receiving packets! So, we've got it!

    Now, I can try to reply back to device using 'Reply from Server' packet, and I'm aspecting to receive all the previous saved (in flash memory) packets waiting to be uploaded by device. 'Message number' has to follow an incremental sequence or can also be always 0??

    Is there any other types of packets (Command/Message Type) you haven't documented here?

    Last question: how did you decode the packets? Have you reverse-engineered the protocol or you've got some suggestions from Sinocastel? Really hard for me to find out 'GPS coordinates' or 'trip number' inside the bytes stream!! :)

    Good job! Great!

    ReplyDelete
    Replies
    1. Hey,
      The message number has to be incremented for each packet sent. The first transmission from the device does not include a message number..... the server then replies with the last message number received and the device will use that number and increment it for every transmission. I'm guessing its just a way for the device to know what is the last message number received by the server so it can upload everything after that (in case of transmission errors).

      Yes I do have a few other Commands/Message types I can send over if you are interested. I would also suggest using a Serial port monitor and use the manufacturer software (press all the buttons and see what comes out the serial and how the device replies). This will help with the Commands/Message types available.

      For decoding the messages I reversed engineered the protocol by matching the information from livetelematics website and the actual packets so maybe I got some things wrong.

      Delete
  4. Hi, have a look here: this is the manufacturer specification for device Castelcom PT-690, but it seems to me very similat to IDD-212G, so I think it can be very userful for our purpose!

    http://roscica2.serverlet.com/owncloud/index.php/s/10A94CtG5cu5AJt

    ReplyDelete
  5. Yes this matches exactly the transmission packets. Nice find....
    Now all that is left is to figure out the commands and their structure and you are good to go!

    ReplyDelete
  6. One question: the 'Message number' fields in 'Reply from server' message (0x1001) is the same value of the latest 'Update message from device' message (0x200c) field, received by the server form the device, isn't it?

    So, it's right to assume that first time device connect to the server, and server has any previous data available, 'Message number' value in 'Reply from server' message (0x1001) should be 0x00 0x00 0x00 0x00?

    ReplyDelete
  7. Actually its not the same. It is incremented by one. Reply from server message number is 0x000005A8 (LSB first in actual message)and the next message number in the Update Message is 0x000005A9. The server will always send the last message number received.

    If the device connects to the server for the very first time then yes the message number will be 0x00000000. However, in the example packets above it was not the first time so it sent the last number.

    ReplyDelete
  8. Hi, thanks for your reply. In fact replying 0x00 0x00 0x00 0x00 device started to send all the messages that before was never sent.

    When trip starts now I get a long "byte array" with may different 'meggages type' inside. At least 600 bytes with messages:
    dev -> 0x2201
    dev -> 0x2203
    dev -> 0x2205
    dev -> 0x2206
    dev -> 0x2208
    dev -> 0x2209 (here I can read the vehicle description in ASCII text)
    dev -> 0x220B
    dev -> 0x2212
    dev -> 0x2214
    dev -> 0x2215
    dev -> 0x2216
    dev -> 0x2218 (here I can read an ASCII IP number and port)

    then, 0x2004 each 10 seconds, with gps position and other info.

    Now, my device seems to has been "blocked" by Sinocastel server, so I'm not really able to understand how server reply to devices messages. Do you still have your IDD-212G device? Can you please send me a log of full bytes-exchange between device and server, for a short vehicle trip?

    If so I'll give you my email address.

    Thanks a lot.

    ReplyDelete
  9. Thaks a lot! please send full log to minimega (at) libero (dot) it.

    ReplyDelete
  10. Hello :)
    I tried that link you sent to calculate CRC32 but it did not return the Integer equivalent of 96F1 like you mentioned. Could you help me out. I've been struggling with the CRC calculation since quite some time now.

    This is what is expected as the input string, right ?
    Crc32.ComputeChecksum(Encoding.UTF8.GetBytes("40 40 7F 00 04 31 30 30 31 31 31 32 35 32 39 39 38 37 00 00 00 00 00 00 00 10 01")).Dump()

    ReplyDelete
    Replies
    1. Hey!
      I added a new page showing the exact code I used for the CRC32 generation. You can find it at http://randomelectronicsprojects.blogspot.com.cy/p/visual-studio-code-for-calculating-crc32.html

      In this code I used the following packet
      40 40 1E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 12 0E F1 96 0D 0A

      The input string should be everything before F1 96 which is the result checksum. When you run the code you should get (hex) 96F1 in the console.

      Let me know if you are still having trouble.

      Delete
  11. Hi Piyush, are you working at IDD-212G protocol decode too?? :)

    ReplyDelete