Queclink GT300 shows no data
Does it use TCP or UDP protocol? If TCP, the problem is that message delimiter is missing.
Yes it is using TCP short connection. What exactly do you mean with the message delimiter?
I have set it on TCP long connection, which results in the following hex:2b524553503a47544c474c2c3335393436343033303439323634342c312c322c312c302c302e342c302c3239392e372c312c352e3435353535312c35312e3434393737362c32303136303331303230333533322c303230342c303031362c303345432c424439342c30302c303031442c30313032303930353031
Still no data.
TCP is a stream protocol, so there must be a delimiter to split the stream into messages. For GL200 it can be "$" or a zero byte.
Thanks for your fast response. I cannot seem to find any settings according the delimiter. But the message should end in a '$' or '0'? My minifinder protocol device ends in a ';' like in the example below:
!D,10/03/16,20:23:18,51.447208,5.456486,2,306,150000,17.4,57,7,14,0;
Delimiter is different for different protocols. For minifinder it is ";".
Do you maybe have any experience to let the GT300 use a delimiter? I cannot find any setting to make it use a delimiter. The acknowledgment examples messages in the protocol also don't have any delimiter. They look like this:+ACK:GTSRI,359464030492644,0000,20160310205302,0032,0102090501
You can find the GT300 protocol here. According to the protocol the entire message string should end with "\0". There is an option in the settings called "\0'Switch. I tried using it with this switch on and off.
Unfortunately I don't have any experience with configuring these devices.
Is it possible that the '\0' they are talking about in the GT300 protocol is the 'zero byte' you mentioned? I know we are close... It's just very strange it looks like the device doesn't send any message delimiter at all.
Yes, '\0' is the zero byte.
Ok, so shouldn't the message look like this for example?:+ACK:GTSRI,359464030492644,0000,20160310205302,0032,0102090501/
You need to check HEX message to see if there is a zero byte at the end.
Hello Anton, I really appreciate your help!
How exactly can I check the HEX message to see if there is a zero byte at the end? I am pretty new to these things. Beneath I have a part of the log where the GT300 sends data to the Traccar server. As you can see I have it on TCP short now, so it makes connection to the server and disconnects when the message is send (it still keeps the session at my provider open, so that's great!).
2016-03-10 16:35:36 DEBUG: [88FDC818: 5004 < 91.241.29.10] HEX: 2b524553503a47544254432c3335393436343033303439323634342c32303130303130313033333935322c303030352c30313032303930353031
2016-03-10 16:35:39 INFO: [88FDC818] disconnected
2016-03-10 16:35:39 INFO: [03A69765] connected
2016-03-10 16:35:39 DEBUG: [03A69765: 5004 < 91.241.29.10] HEX: 2b524553503a47544254432c3335393436343033303439323634342c32303130303130313033343033382c303030362c30313032303930353031
2016-03-10 16:35:43 INFO: [03A69765] disconnected
2016-03-10 16:35:43 INFO: [9F401E15] connected
2016-03-10 16:35:43 DEBUG: [9F401E15: 5004 < 91.241.29.10] HEX: 2b524553503a475452544c2c3335393436343033303439323634342c312c302c302c312c302e342c302c3330342e332c312c352e3435353535392c35312e3434393831382c32303136303331303135303430382c303230342c303031362c303345432c424439342c30302c303030372c30313032303930353031
2016-03-10 16:35:46 INFO: [9F401E15] disconnected
2016-03-10 16:35:47 INFO: [8F217FBB] connected
2016-03-10 16:35:47 DEBUG: [8F217FBB: 5004 < 91.241.29.10] HEX: 2b524553503a47544254432c3335393436343033303439323634342c32303136303331303135303631392c303030382c30313032303930353031
2016-03-10 16:35:50 INFO: [8F217FBB] disconnected
2016-03-10 16:35:51 INFO: [F9112A79] connected
2016-03-10 16:35:51 DEBUG: [F9112A79: 5004 < 91.241.29.10] HEX: 2b41434b3a47545352492c3335393436343033303439323634342c303030302c32303136303331303135313631362c303030392c30313032303930353031
2016-03-10 16:35:54 INFO: [F9112A79] disconnected
2016-03-10 16:35:54 INFO: [C90A4E09] connected
2016-03-10 16:35:54 DEBUG: [C90A4E09: 5004 < 91.241.29.10] HEX: 2b41434b3a47545352492c3335393436343033303439323634342c303030302c32303136303331303135323133312c303030412c30313032303930353031
2016-03-10 16:35:58 INFO: [C90A4E09] disconnected
2016-03-10 16:35:58 INFO: [848EB70F] connected
2016-03-10 16:35:58 DEBUG: [848EB70F: 5004 < 91.241.29.10] HEX: 2b41434b3a4754534f532c3335393436343033303439323634342c303030302c32303136303331303135323635312c303030422c30313032303930353031I am wondering now why the data doesn't show. Because in the log Traccar clearly sees it as seperated messages, doesn't it?
Look at the last two digits in the HEX message. It should be "00".
I have put the setting '\0 switch' on, now it sends the following hex when I let the GT300 send its location to the traccar server.
2016-03-11 09:37:24 DEBUG: [505DDE4B: 5004 < 91.241.29.10] HEX: 2b524553503a47544c474c2c3335393436343033303439323634342c312c322c312c302c302e342c302c3239392e372c312c352e3435353535312c35312e3434393737362c32303136303331313038333232392c303230342c303031362c303345432c424439342c30302c303033362c3031303230393035303100
2016-03-11 09:37:28 INFO: [505DDE4B] disconnectedAs you can see it now ends in "00", but it still shows no location in my Traccar.
Dear Anton and Traccar community,
I have been working with Traccar for a while now with devices using the minifinder protocol on port 5062. These are working like a charm and I really like Traccar!
At the moment I am trying to connect a Queclink GT300 with my traccar server over port 5004. It uses the @track protocol, but I think it differs a bit from the GL200 @Track protocol as implemented on port 5004 at the moment. At least, I can't get it working (no information/localization in Traccar).
Beneath a copy of the log: