eelink TK319H
It's a binary protocol, so trying to decode it into a text won't work.
I have the TK319-L, since this is the only affordable NB-iot device I found to play with.
Same problem here:
I can see the device come up in traccar, but all variables (coordinates, ...) are zero.
This is the same on the demo servers.
So I suppose these devices are not supported (yet)
2019-10-13 10:02:50 INFO: [a5bbf47b] connected
2019-10-13 10:02:53 INFO: [a5bbf47b: eelink < 172.17.0.1] HEX: 67670100180003035467909019745301200209120900010446006266c6
2019-10-13 10:02:53 INFO: [a5bbf47b: eelink > 172.17.0.1] HEX: 676701000800035da2f64d0100
2019-10-13 10:02:55 INFO: [a5bbf47b: eelink < 172.17.0.1] HEX: 676712002900015da2f63b00046e1164046b0000000000000d90010f000000000000000000000000000000000000676715000a00025da2f63c0002046a676712003400045da2f64e0200ce000a4a9c01029f072e046a115d04400000000000000d90010f000000000000000000000000000000000000
2019-10-13 10:02:55 INFO: [a5bbf47b: eelink > 172.17.0.1] HEX: 67671200020001
2019-10-13 10:02:55 INFO: [a5bbf47b] id: 354679090197453, time: 1970-01-01 00:00:00, lat: 0.00000, lon: 0.00000, course: 0.0
2019-10-13 10:02:55 INFO: [a5bbf47b: eelink > 172.17.0.1] HEX: 67671500020002
2019-10-13 10:02:55 INFO: [a5bbf47b] id: 354679090197453, time: 1970-01-01 00:00:00, lat: 0.00000, lon: 0.00000, course: 0.0
2019-10-13 10:02:55 INFO: [a5bbf47b: eelink > 172.17.0.1] HEX: 67671200020004
2019-10-13 10:02:55 INFO: [a5bbf47b] id: 354679090197453, time: 1970-01-01 00:00:00, lat: 0.00000, lon: 0.00000, course: 0.0
2019-10-13 10:06:05 INFO: [a5bbf47b: eelink < 172.17.0.1] HEX: 67670300040005046a
2019-10-13 10:06:05 INFO: [a5bbf47b: eelink > 172.17.0.1] HEX: 67670300020005
2019-10-13 10:06:05 INFO: [a5bbf47b] id: 354679090197453, time: 1970-01-01 00:00:00, lat: 0.00000, lon: 0.00000, course: 0.0The only option is then to go for professional services and request a new protocol integration?
I do want to support traccar, but I am only using traccar as a hobby setup, for one devices only (my bike).
So investing 150 euros is steep for me.
So, I am left with choosing another commercial server that supports the device and gives one device for free.
A pity, since I like traccar, and the thought of setting it up in my docker environment myself.
Let us know if there is development planned on this or what other options are possible.
If there s something we should/could look into, solving it.
Thanks and keep up the good work!
Kheno,
I think your 319-L will work. I have one of those too. I bought the 319-H and 319-L NB-iot LTE. Once Anton told me the hex represented binary I started to figure it out. It’s really important to try to understand the eelink device protocol and get it set up to send data packages you want with the timing you want and keep the heartbeat TCP packages coming regularly enough so you’re ISP doesn’t reset the connection and restart the eelink handshake process over again.
I’m new to traccar but it is awesome and as far as I can tell completely handles all the things the server is expected to do for the eelink protocol. The real trouble I had was the limited instruction for setting up the device (and also some problem where I didn’t see the right data in the logs, haven’t figured that out yet, maybe I was looking at the wrong days? Maybe my server time is off? Still looking into it…). Does your 319 send the right location if you SMS it? Does is the GPS module timers set to be always on? Or do they turn on and off on timers if the device is active or not?
Thing to check on eelink protocol that I have found:
APN?
AGPS?
GSM?
GPS?
COLLECT?
HBT?
SERVER?
You really have to research to figure out what all of those settings are and how they affect what the device tries to do.
I see you’re time on the device is definitely off. I’m betting there are some device configuration problems. I’ll post again if I have more info… I’m just getting into this myself.
Sorry, for the late response! I am in the midst of migrating servers at work, so working late. :)
Thanks for the great response! It gave me courage to keep looking.
So I've placed the device outside, done a few other config changes, and now its working.
Inside, after a window, it seems not to work well.
Because my phone does has reception indoor I suspect config issues.
The commands you gave me respond with a lot more info, than documented, so this will be guessing what they stand for.
My current config:
Disregard the "at^mcmd=" I am sending commands through console using a usb cable.
What I have now setup:
at^mcmd=status?
'''BATTERY:100%
GPRS:SUCCESS
GSM:HIGH,58
GPS:FIXED,8
ACC:OFF
RELAY:OFF
POWER:OK
MS:LIS3DH'''
at^mcmd=APN?
'''APN:nbiot.iot,,'''
This one is ok, since the status tells me connection is ok.
at^mcmd=gsm?
'''GSM:0,120,0,0,0,0,3748'''
No idea what these mean, anyone?
at^mcmd=collect?
'''COLLECT:30,0,15,10,1'''
COLLECT:[INTERVAL],[DISTANCE],[TURN],[ACTIVE],[QUANTITY]
Name Description
[INTERVAL] The time interval (in seconds) it will send updates nomatter what
[DISTANCE] The running distance (in meters) before it will trigger gps
[TURN] The turning angle (in degrees) rotation before triggering gps
[ACTIVE] The time interval when device is moving/active (in seconds)
[QUANTITY] The number of cached location packages before they are sent
at^mcmd=gps?
'''GPS:0,120,0,0,0,0,548'''
This returns a lot more than I suspected.
The only documented info I have is to set the GPS saving modes:
GPS,0# : GPS ALWAYS ON
GPS,1#: GPS ONLY ON When it move or inquiry the location.
GPS,2#: GPS only one when it inquiry the location .
GPS,3# : GPS Closed
Currently set to 1
Anyone an idea what all the other values mean?
at^mcmd=HBT?
'''HBT:3.00'''
Heartbeat: 0-60 min. packet which is sent to the server? Every 3 minutes. I supose this should be ok.
at^mcmd=server?
'''SERVER:"tcp://<domainname>:5064"'''
'''at^mcmd=Delay?
DELAY:10'''
No clue what this delay is for?
Its also difficult to understand how to set it up:
you have the motion setting "MOTION" and an angle setting under "COLLECT"
So these are two different systems, or is this the same gyro setting?
at^mcmd=motion?
MOTION:2,5
You're right the time is off. Only Time zone can be set. Suppose this should come through the cellular network.
Weird that it now picks up the time, as it did not before.
And indeed, when looking into the logs, time is now correct. Well, probably need to play with GMT to get it completely correct.
2019-10-18 08:20:10 INFO: [bf8fd59a] id: 354679090197453, time: 2019-10-18 08:10:19, lat: 51.04749, lon: 3.75341, course: 0.0
at^mcmd=version?
IMEI:xxxxx
IMSI:xxxxx
ICCID:xxxxxx
SYSTEM:M6135_V2.0.9B8
VERSION:M6135_V2.0.9B8
BUILD:2019/03/20 14:57
Above settings are a good starting point, I think. Now I need to figure out the undocumented information, and do more testing.
But I am happy already, getting results. Especially when you start to look into the wrong direction.
Thank you for that Jeff!
If anyone should have more information, please post!
I was having trouble with figuring out why the eelink device was sending old data. SMS queries like URL? responded with current and accurate location and time. But the info being sent to traccar was a day old. I force cleared all the pending packages with an SMS CLEAR# command. Immediately the info sent to the server was current and accurate. However I watched the logs and saw that it began to fall behind again and start sending old data.
SOLUTION: I changed the server address on the eelink devices to use UDP instead of TCP. SERVER,udp://domain_name.com:6054# -it has been running up to date for a day now and doesn't seem to fall behind. I guess there is a lot of overhead with TCP headers for fault correction and maybe the little processors on these things can't decode the server acknowledgement responses quickly enough and so it falls behind if you are sending packages too frequently (I'm only doing one every 5 mins at idle). That's my theory anyway. UDP (User Datagram Protocol) is faster because there are no checks for data integrity. I just though I'd share this to maybe help someone else who is new to this like me.
It is weird that the hex reports have now changed the first identifying bytes from 6767 to 454c... Just figured it out... There is a new UDP header added so the server can try to verify it has the whole correct UDP package. If you look down the hex several characters the 6767 is still there.
Actually, scratch that last post. (I tried to edit the post it but it says 'unauthorized') I changed my COLLECT parameter the same time I changed my server setting to UDP. The problem was with package collection. I set it to COLLECT,300,0,0,0,0# which I assumed meant it would only collect and send a location package every 300 seconds. But somehow it was constantly collecting packages as fast as it could, and sending them, locking up, rebooting every 3 mins or so, then starting the whole process again. Then it would send the oldest data first. Looking at a day of old data in the traccar reports showed a new location every couple of feet when I was traveling at 50 MPH! I set the param COLLECT,300,020,60,1# and it is much more reasonable now and reports well with UDP or TCP. No reboots, accurate and current data reported.
any probelm about Eelink‘s devices can be asked for me。The complete probelm about Eelink‘s devices can be asked for me。The complete protocol eelink 2.0 eelink protocol 20.
Thanks Willis.
I do have a few questions I am trying to figure out.
The only command from the 2.0 protocol I can't seem to get to work is FACTORY# trying to do a factory reset. Is there something special about that command?
In my testing, it seems that the devices only send data to the server about once per minute even though sometimes there are several packages generated in under a minute. This causes the device to get behind and it is stuck sending the old data, before it can catch up and send current data. Is there a way to send data faster? or more often? or make it include more packages in one transfer?
Is there a specific format to enter ublox assist now URL with the token that is required now? I have a token assigned to me but I am not sure how to include it in the server URL for the eelink devices.
Concerning the IN/OUT ports... The way I understand it the two wires on their own (the black and red on it's own connector) can be set to input via commands to the device and then either grounded to 'pull down' or given 5V to 'pull up' the port. Will this state change trigger an event automatically? Can I use 12V-14V to 'pull up' the port? Or will this damage the device?
I have read the protocol but I don't quite understand the GSM and GPS, waking, and working phases etc. I do want to be able to save battery when the device is idle, what are some good defaults to be able to do this?
1.About the firmware . different model has different firmware version, .
FACTORY# is the command to restore all settings can you tell me more details？ you want to restore all settings ？and what happened？
2.After communicating with the technical team, i will answered other questions.
2..About the time interval of devices' data, we have command to modify the uploading time interval.
You can see the EELINK protocol 2.0 , there is a command COLLECT which is used to control the data sending condition and time interval.
and you can set the time interval freely。
3.if you want to achieve that，you need to customized the function。
Ok thanks Willis. I have continued to test these things and the problem I keep having is that they begin sending old data. When there is no movement, I get current info, but when the device starts to move it seems to get overwhelmed. My collect settings are 420,0,30,60,1.
Every 420 seconds at idle.
No package for distance.
Package when course changes 30 degrees
Every 60 seconds when moving.
I have just changed the settings to 420,0,0,60,1 to see if it can stay current if I turn the course (turn) package creation off.
Is it possible that my network is slow or is holding up the packages? Is there a way to test network speed? How many packages can the eelink devices send per minute? The most important thing is to have current data, Not historical data.
If you find that the login package is uploaded repeatedly, then you can see if the serial number changes. If the serial number does not change, it means that there is no correct response. If there is a change, there may be too many caches.
How many packages are sent in one minute is determined by your settings.
If it is a problem of sending packets repeatedly, then we need to analyze your example specifically.
New to the whole traccar world and very impressed so far. I'm looking for help with a device...
hex is:
which gets decoded to:
I'm not sure what to do with that.
Should I try other ports? will I get a different hex code on other ports?
I just bought the device on eBay with no instructions. It seems to be running eelink protocol 2.0.3 or something on it. Although the factory# command doesn't do anything when I try to load factory defaults.
I would be interested in any input from the community on what device I can source for monitoring small boats in the US, something that will show the external supply voltage of the battery in the boat and also a 12V Accessory activity to monitor the bilge pump.