FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

4167 questions

4739 answers

3460 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
3,149 views
in Vehicle tracking by

Hello,

This week, we tested in real conditions a tracker and our server on a long journey.
Everything worked very well. The Java server (based on that of teltonika in C#).
However, I noticed a little worry. I guess it comes from me, but I'm not sure where.

This is the configuration of the tracker (FMB120) :

  •     When the vehicle goes fast, on a highway, it sends frames very quickly.
  •     When the vehicle goes slowly or is stopped, the beacon emits few frames.

I noticed that when I sent commands to the tracker when the vehicle was on the highway and emits a lot of frames, they were not taken into account by the tracker. And the connection between the server and the tracker was lost.
On the other hand, the commands are always well taken into account when the tracker does not move and emits few frames.

Regarding Codec 12, is the "GPRS commands (in 12 codec)" part (in blue) at the bottom of the message queue for a particular reason? (https://wiki.teltonika.lt/wiki/images/f/f2/Wq.png)

When I decide to send command to the tracker, my server send directly the command. (is this a problem ?)
My changes to recieve Codec 12 ACK is here. In the TcpClientService.cs class. (I have used Java)

I really do not know where the problem may come from and where to look for it.
Would there be a simple example of a server that handles Teltonika commands?

If you need more explanation, do not hesitate to ask me.

Thanks you really for your help,
Regards,

by

Hello AlliageSphere,

What commands are you sending to the FMB120 ?  We use CODEC 12 for both commands and Serial/RS485 data on other FMB devices and they work well BUT generally for static applications.

In terms of the TCP connection, do you still see CODEC 8 or 8E data AFTER you send the command ?  This implies that the TCP connection is still alive and not lost from the device side through loss of signal / network handover during travel.

Are you monitoring for stale TCP sockets and new sockets from the same device ?  This is quite low level but will need to be managed well for mobile devices.

Hope you resolve your issue as these types of problems can be tricky !

by
Hello !

Thanks a lot for your answer,

When I had made my tests, it was to send setdigout commands. But it should be nice to configure geofencing (setparam 20100:1;20101:3;20102:1;20103:20;20104:0;20105:50;20106:5;20107:56) or other things whenever.

Yes, for the moment, Codec 12 is working good except when there are many data to treat.
So if I understand, commands shouldn't (can't ?) be used when the tracker is doing something (like emitting frames) ?
Is there a way to bypass it ? Maybe my server can keep commands in memory and send them when tracker is not busy ?

"In terms of the TCP connection, do you still see CODEC 8 or 8E data AFTER you send the command ?". Sorry, I don't understand what you are saying. Can you reformulate please ?
However, during my tests in a car, I have often seen that the connexion is lost just after the sending my command.
This is almost never the case when the tracker is emitting slowly its data (with Codec 8/8E).

I have just checked my code and the socket of an active connexion is closed directly when the connexion is lost. Is this what you was talking about ?
In order to test this "functionnality" I have configured the tracker for emitting a lot of frames and make connexion cut by sending a command...
Yes, this is not a good practice I think...

If you have more questions, don't hesitate to ask me.

Sincerely,

Axel DUMAS.

PS : "Hope you resolve your issue as these types of problems can be tricky !". Thanks a lot !
by anonymous

Hello AlliageSphere,

For the question 'In terms of the TCP connection, do you still see CODEC 8 or 8E data AFTER you send the command ?', I was enquiring if you received any 8/8E packets on the same socket ID (the exact same connection that you received 8/8E packets prior to you sending the command).  This should imply that the socket is not stale and still valid to send commands but the commands are not being actioned due to buffering or a queue (Teltonika should be able to confirm and intimated by your original comment of the commands in blue being at the bottom of the diagram on the wiki).normally 

I am not a software developer but I am familiar with various TCP server implementations and there should be a way to ID the socket for each packet that arrives (and subsequently send your ACK / commands back on which I guess you are doing but are you monitoring the ID and linking to the IMEI somehow ?).  Interesting that you suggest the socket is closed immediately when the device loses connection as I have not seen this before - we usually see the socket become stale and have to either timeout due to inactivity and close from the server or attempt to send commands and receive no reply and then close the connection, again from the server. 

One question for you - are you sending the 8/8E ACK before the command and as a separate packet ?  Wireshark or TCPDUMP should be able to confirm what is happening on the wire.  With the speed of packets arriving during the vehicle being mobile, the ACK timing may be even more critical.

by
Hello,
sorry for being late.
When I send a command to the tracker (and when it works), the socket is the same. Same IP, Same Port.
However, when a command fails, the socket is closed and a new port (on the tracker) is used.
I think all is good from this side. And you ?

In fact, when a tracker is connected to my server, I put its IMEI and its socket in a sort of associative array.
Thus, I just have to specify the correct IMEI to use the correct socket. And for the moment, it's seems to work fine.
Is it what you was thinking about ?

My server use sockets to be opened to internet (Server Socket) and also, when a new tracker is connected, a new client socket is linked to it. So if I have 100 trackers, I have 100 sockets (+1 for internet).

When I started this project, I had few knowledge. I have learned a lot of thing with TCP communications, Sockets and Java thanks to Teltonika.

As recommended, I have set "Open Link Timeout" to 259200 seconds. I think I generally close the socket connection only when the tracker cut the connexion with the server (when the tracker got a "problem". Often due to bad command).
But when there is only a loss of signal, sockets should stay opened.

I am constantly learning so I will keep in mind what you was talking about in order to see how I can do it in my program. I will see more deeply how it works according to trackers.

For your question, I don't know when the ACK of the Codec 8/8E is sent. I think the ACK is sent after the reception of the command. Which, I think, is bad. I will try to confirm it.
Thanks a lot for your help !
Sincerely,

PS : You're many to help me on this subject and everyone give me very helpful answers. Thanks you !
by anonymous
Hi,

I think your issue may be down to your sending a command down to the device on a stale connection.  The scenario would be as follows -

Device sending data and arriving at your sever

Cellular service is disrupted for whatever reason (common when mobile)

Connection lost at the device but your server does not see a clean TCP FIN -> FIN-ACK closure of the connection

Server thinks the connection is still active

You send a command but receive no response

Device regains Cellular service

New connection gets established with your server IF the device has something to send

I think there are two aspects here - the time between the connection going stale and the new connection being established, but you initially state that you are sending lots of data from the device so reconnection should be reasonably quick, although I seem to remember there is a setting for this somewhere to prevent TCP SYN 'flooding'.

You timeout seems pretty large as most networks will close the TCP connection after some hours - 4, 8, 12 which is under your timeout and you potentially risk having lots of stale connections on your server that are consuming resource (memory mostly).

Monitoring the network with Wireshark or TCPDUMP will help understand both the connection attempts and the data flow here - well worth a look.
by
I set today socket timeout parameter to 259200 and you're right, this was not a good thing. I have removed this.

In order to avoid flooding maybe, the "Send Period" number can be higher than "Min Period". It should work. But otheriwise, I don't know which parameter do you think.

Thanks for your scenario. I will verify if this what it is happening when I send command and it is not working.

I will take a look at Wireshark. Thanks !
Sincerely,

1 Answer

0 votes
by anonymous
Hello, AlliageSphere,

Thank you for query.

How I understand from your issue description, you get too much AVL data packet (Codec 8 Extended). That is the reason why you can't send SMS when vehicle is moving because the device is busy with AVL data packet sending. Please check how your Data acquisition are set in the device by Teltonika configurator. More information about this settings you can find in our Teltonika Wiki page: https://wiki.teltonika.lt/view/FMB120_Data_acquisition_settings

Please feel free to ask if you will have more questions.

Best regards,

Teltonika Support
by

Hello,

thanks a lot for your answer ! I will check the configuration of the tracker and give you more details on it.

Also thanks for your link. I did not know him.

Thanks to my calculations, I have seen that if a vehicle is at 130Km/H, a frame is sent every 2 seconds (min distance 100)...Maybe it's too high for the tracker to also receive a command ?

So, do you think it can just be a bad configuration (made by myself) of the tracker and not due to the server ?

PS : Sorry for my late. I had difficulties to open the tracker to take the configuration.

by anonymous
Thank you for information and questions.

Your values in Moving settings is by default and Min Distance is too low for your attached speed. These parameters can be configured by yourself how usually you want to get data. Additionally, if you do not want to generate data by Min Period, Min Distance, Min Angle or Min Speed Delta, you can set zero values. But one of them must have value higher than zero.

Let us know if you will need a help to configure it or you will have more questions.
by

Thanks a lot for your help.

I have made some changes to the tracker settings. I expect they could work for our application case.

I think that keeping Min Period, Min Distance, Min Angle or Min Speed Delta could be a good idea. For example :

  • Min Period for periodical data sending.
  • Min distance for highway.
  • Min angle for cities when the car is turning.
  • Min Speed Delta...I don't know where to use it.

Here it is my new settings. Maybe, it can be better :

Do you think that for our application case, it could work ?

Thanks again for your support.

Sincerely,

by anonymous
Thank you for questions and sorry for late reply.

Yes, these settings will work by your wishes. You can try to monitor it.

If you will have more questions about this settings or something else, please feel free to ask in Teltonika Crowd Support forum.

Have a nice weekend!
by
Hello,
there is no problem for your "late".
You helped me a lot.

I will try to test these settings the next days and keep you informed.

Thanks you,
Have a good week-end !