Sinocastel IDD-212G device
I will try in the next hour.
However, reading updated java code, you parse only 0x2001 message (and reply with 0x1001 message); if 0x1001 will be accepded by device, I'm aspecting that device starts to send data every 10 seconds, but using new command 0x200c wich you do not parse at the moment.
I'll give a look at the log then I'll let you know if that's right!
Does 0x200c include GPS data?
Did you had a look at the document (3rd message example)?
http://randomelectronicsprojects.blogspot.it/p/blog-page.html
There you'll find all informations about 0x200c message.
With the new server version I see you send back to device message 0x1001, but device won't reply anymore. Look: device don't attempt to send the 3 0x2001 messages as before.. it stops just after received the 0x200c from server, as if there's anything to do.
You useresponse.writeInt((int) (System.currentTimeMillis() / 1000));
as 'Message number' but I'm not really sure this can be a good value for that field.
Have a look at message 0x200c from device: it has 'Message number' field, as it would be an auto-increment value for each message device sends to server. If so, server should send back to device (within message 0x1001) the latest 'Message number' value he received from the device latest time. So device knows where to start from.. (device has internal flash to store data when GSM network is not available.. server informs device wich one is the latest message he received, so device starts to send from the next one).
So, try to use 0x00 0x00 0x00 0x00 for 'Message number' when repliyng with 0x1001 to device, let's see if something changes asking device to start send from the first message available in memory.
Done. Here is a new build:
https://www.dropbox.com/s/cgmlansv32j3ii0/tracker-server.jar?dl=0
Well, we're in the right direction.
I updated my server after midnight, when vehicle was parked and engine off.
The second time (after update) device connected with server, the command sequence has been:
01:41:33 dev -> 0x2001
01:41:33 srv <- 0x1001
01:41:35 the next messages are arrived in "block" (~600 bytes), all together in a single log line
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)
I think here server should be reply with someting else..
01:42:15 dev -> 0x2011
01:43:05 dev -> 0x2003
stop
Then, at interval of 01 hours and 02 minutes, the communication is:
dev -> 0x2001
srv <- 0x1001
dev -> 0x2011
dev -> 0x2003
dev -> 0x200c (~1000 bytes divided in many messages)
until this morning I powered on engine and:
dev -> 0x2001
srv <- 0x1001
dev -> 0x200c (~1000 bytes divided in many messages)
dev -> 0x2004 (each 10 seconds)
unitl the trip end.
After the trip end and engine off I still get 0x2004 messages, as if device is sending my latest trip remaining data..
I understand there is much work to do to support this device.. are you interested in full support IDD-212G?
I am interested, but it would be better to have proper documentation.
It will be the goal! But you just know manufacturer won't give us protocol specifications.
I wrote to Sinocastel both tech and commercial addresses, but anyone replied yet..
We have to do it by ourself..
Not sure how you plan to reverse engineer it without any documentation. Even worse the situation is with responses.
Ok, we can wait for Sinocastel reply, but I mean we'll wait infinitely...
I don't see any other options. Do you?
Yes I do! Have a look at the past 5 days.. now you are able to decode (part) of a new protocol, you never know before, isn't so. I know with documentation the work could be more easy, but I think it's only a question of time, the result is really near.
I will start my own application in C# (I don't now Java ad NetBeans IDE) and will try to decode the maximum informations available from device. Also try to understand how server reply to device. Then I'll let you have all my work so you can quickly implement a (new) ProtocolDecoder in Traccar.
In really new in Traccar, but I find it very intersting. But I don't understand if other info (as: coolant temp, oil temp, MAF, strong accell/decell, OBD2 DTC codes, eco driving..) you are able to manage inside application. Also full trip playback in maps is possible?
Sounds like a plan.
Any additional data can be decoded. Trip playback is not supported yet.
Let's start a new plan, then! :)
Well, hope to see playback in the next feature!
Sinocastel has finally replied. They said they can provide protocol only for someone who bought the device. They are asking for your name.
Added response. Here is a new build to try:
https://www.dropbox.com/s/cgmlansv32j3ii0/tracker-server.jar?dl=0