Sinocastel IDD-212G device

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!

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.

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.

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

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

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

Hi Anton, any news from Sinocastel??

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

..hoping so!

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

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

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.

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

I have pushed the changes to GitHub.

There is no reply message yet.

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