Sinocastel IDD-212G device

minimega6 years ago

Hello Anton, I've a Sinocastel IDD-212G device. I've redirected the server IP to my home server (where I've installed Traccar server), and configured port 5086 (default Castel).

However, having a look at traccar/src/org/traccar/protocol/CastelProtocolDecoder.java I think my device could have a protocol different than the one you've implemented. Here are 3 "sentences" logged on tracker-server.log

2016-02-06 12:53:58  INFO: [76752FD7] connected
2016-02-06 12:53:58 DEBUG: [76752FD7: 5086 < 192.168.0.3] HEX: 24243f00676e6768656636313031313132393030313734002001840d0000d2deb556020602100b35360456cf09e6ebac0200000000030000000001abc10d0a
2016-02-06 12:54:40 DEBUG: [76752FD7: 5086 < 192.168.0.3] HEX: 24243f00676e6768656636313031313132393030313734002001840d000000dfb556020602100b36298256cf0956ebac020000990c7f0000000001b4830d0a
2016-02-06 12:55:27 DEBUG: [76752FD7: 5086 < 192.168.0.3] HEX: 24243f00676e6768656636313031313132393030313734002001840d00002edfb556020602100b371a3a56cf0932ebac0200000000030000000001d8410d0a
2016-02-06 12:56:11  INFO: [76752FD7] disconnected

This is the code:

buf.skipBytes(2); // header
buf.readUnsignedShort(); // length
int version = buf.readUnsignedByte();
ChannelBuffer id = buf.readBytes(20);
int type = ChannelBuffers.swapShort(buf.readShort());

Header: 2424
Lenght: 3F00 (63 bytes, this is OK)
Version: 67 (103 -> 1.03??)
id: 6768656636313031313132393030313734002001 (20 bytes.. but the human-readable text ends at byte 17)
type: 840D (swap-> 0D84??) if id was 17 bytes, type could become 0x2000, mabye more "logical" value..

Have you some idea about this protocol??

Thanks!

Anton Tananaev6 years ago

Yeah, it looks like a new protocol. Even prefix (first two bytes) doesn't match current implementation. I guess you need to request protocol documentation from manufacturer or seller for me to be able to implement this protocol.

minimega6 years ago

Hi Anton, I just asked to Sinocastel for protocol specifics.. never had a response from them.
I think the only way is to reverse-engineering my sentences and try to decode as many informations as possible.

Anton Tananaev6 years ago

Reverse engineering of binary protocol is very hard. I'll try to contact them about documentation and see if they reply.

minimega6 years ago

Triyng don't cost at all! :)
I've wrote to support@castelecom.com, let me know!

Anton Tananaev6 years ago

I've sent email to marketing_wx@sinocastel.com. Let's see if they answer.

minimega6 years ago

Hi Anton, any news from Sinocastel??

Anton Tananaev6 years ago

Nothing yet, but it can be explained by Chinese holidays.

minimega6 years ago

..hoping so!

minimega6 years ago

Yeah!, have a look at this well done work:
http://randomelectronicsprojects.blogspot.it/p/blog-page.html

Examples are compatible with my incoming device data, I think we've all the necessary to realese the new parser for IDD-212G device!

Can you have a look and then let me know?

Thanks

minimega6 years ago

Anton, could you please explain me the formula:

double lat = buf.readUnsignedInt() / 3600000.0;
double lon = buf.readUnsignedInt() / 3600000.0;

Why must I divide by 3600000.0?

Thanks

Anton Tananaev6 years ago

I have added support for this format. Here is a new build:

https://www.dropbox.com/s/cgmlansv32j3ii0/tracker-server.jar?dl=0

Please let me know if it works.

minimega6 years ago

Hi Anton, yes, it's now working fine. Very good!
At least, new jar version can decode incoming packets from IDD-212G device and parse correctly lat&lon, showing me cursor on map.

Two questions:

1) can you update (or let me have a copy of) traccar/src/org/traccar/protocol/CastelProtocolDecoder.java so I can check for your modifications? Did you mantained same CastelProtocolDecoder or did you wrote a new one for IDD-212G protocol version?
2) as from http://randomelectronicsprojects.blogspot.it/p/blog-page.html specifications, I get only 0x2001 messages type from device (this is the message sent when engine powers up). But while driving, I get no "rapid" messages (device has been setted to upload lat&lon every 10 seconds). I get always 0x2001 every 30-40 secs for 3 times for TCP session (connected/disconnected), for 3 TCP sessions, then device sleeps for 1 hour. I mean that Traccar server won't reply back to device with 0x1001 command type, so device won't start to send messages when vehicle running. Do you reply back message 0x1001 when you receive 0x2001 from device? Could you please log also the outgoing messages sended to device?

Thanks

Anton Tananaev6 years ago

I have pushed the changes to GitHub.

There is no reply message yet.

minimega6 years ago

Ok, do you think it will be added in the next feature?