Ask a question

3508 questions

3993 answers

2983 comments

26358 members

Ask a question
0 votes
5,149 views
in Vehicle tracking by
Hello everyone, I would like to know where I can find detailed information on how the FM3612 works. Since we have a project in which we have to create a socket server for this device to connect to us and send data.

Basically we have tried to configure the UDP protocol in the device. But we do not know exactly what to respond to the device in the ACK messages. And what should the device answer after the ACK message?

Then the frequency of sending packets of the device is configurable? Does this change when the server sends an ACK message?

Now we are about to do tests with the TCP protocol.

We need your help.

Thank you.
by
At this moment we have enabled the device to send TCP packets and receive them on the server, we answer with 01 but we always receive the IMEI of the device?

Does anyone know why?

We are following this guide that tells us:

"First when module connects to server, module sends its IMEI. IMEI is sent the same way as encoding

barcode. First comes short identifying number of bytes written and then goes IMEI as text (bytes).

For example IMEI 123456789012345 would be sent as 000F313233343536373839303132333435

After receiving IMEI, server should determine if it would accept data from this module. If yes server will reply

to module 01 if not 00. Note that confirmation should be sent as binary packet.

Then module starts to send first AVL data packet. After server receives packet and parses it, server must

report to module number of data received as integer (four bytes).

If sent data number and reported by server doesn’t match module resends sent data."

1 Answer

0 votes
by

All correct.

@ TCP answer is 4 bytes - 3 zeroes and last (4th) byte -> is NOD (number of data records sent to server).

@ UDD: answer is 7 bytes: you can keep first 5 zeroes - 6th is avl_packet_ID (server must reply with same avl_packet_id as sent from device)

7th - NOD

https://wiki.teltonika.lt/view/Codec

codec8 - data records sending

codec8 extended- data records sending with 2Bytes per AVL_ID (which is IO id basically).

codec12 - gprs commands sending between device <-> server.

codec13 - device sends buffered RS232/RS485 packets to server.

codec16 - used only in FM6X family devices.

FM36 probably supports only codec 8.

Can try this demo server: https://we.tl/t-zA1fCam52c

launch on your PC - configure FMB device to send records to your PC/PORT (as configured @ values.txt file)

TCP:1 - means tcp connection, TCP:0 - means udp connection.

And then see via console log - or log file -> how server communicates with device regarding acceptance of sent records.

Regards

by
can i have the demo server too?
The file link is expired. Thank you.
by

Honestly I don't understand the instructions on UDP acknowledgement at https://wiki.teltonika.lt/view/Codec

It says there that if we got Packet Type = 1 from the device then it doesn't require an acknowledge reply from the server, then it follows by saying you DO need to send it - quoting:

Module sends UDP channel packet with encapsulated AVL data packet (Packet type=1 or 0). If packet type is 0, server should respond with valid UDP channel acknowledgment packet. Since server should respond to the AVL data packet, UDP channel acknowledgment is not necessary in this scenario, so Packet type=1 is recommended.

Server sends UDP channel packet with encapsulated response (Packet type=1 – this packet should not require acknowledgment)

Module validates AVL packet id and Number of accepted AVL elements. If server response with valid AVL packet id is not received within configured timeout, module can retry sending.


Example: Module sends the data:

UDP channel header AVL packet header AVL data array

Len – 253,

Id – 0xCAFE, Packet type – 01 (without ACK)

AVL packet id – 0xDD,

IMEI – 1234567890123456

CodecId – 08,

NumberOfData – 2. (Encoded using continuous bit stream)

00FDCAFE01 DD000F3133343536373839303132333435 0802…(data elements)…02


Server must respond with acknowledgment:

UDP channel header AVL packet acknowledgment

Len – 5,

Id – 0xABCD, Packet type – 01 (without ACK)

AVL packet id – 0xDD,

NumberOfAcceptedData – 2

0005ABCD01 DD02

See the parts in bold they are contradicting each other ! You don't need ack but you actually do need to send ack with the number of data ?! What's the point then ?!

A few lines above (in the wiki page) the ACK packet looks different! Quoting:

Acknowledgment packet
Packet length 2 bytes 0x0003
Packet id 2 bytes same as in acknowledged packet
Packet type 1 byte 0x02

So what kind of ACK do we need to send ?

The entire purpose of us picking UDP is to not have to deal with these kind of things (UDP is send and forget).

It is enough that the client needs to program his own code for decoding these protocols - No proper software packages are provided by Teltonika and the only code example is some undocumented C# example code that is horridly complex.

So I implemented the UDP in Python but am stuck on these pointless ACK packets.

What do I need to send there?

How does the device (FMB630) affected if I don't send these packets ?

Will it at some point give up on the old records and move on to sending the latest record ? (As it should)

Can you please come up with SIMPLE and CLEAR instructions on what needs to be done ? This messing around costs us time and money!

by
I tried to run the demo server but it doesn’t do anything.

In the FM3612 I wrote in the domain field my home ip and the port 7777. I forwarded that port to my home server. In the server config file I wrote my internal ip (192.168....) and the port (7777).

The server was up all day but it didn’t recived nothing and I was using the car with the gps device .

Did I configured something wrong?
by

"Packet type=1 – this packet should not require acknowledgment)"

This is some old relict from very old devices. 8-10 years old.

All current devices - DO require answer to sent records (both via TCP and UDP).

So please ignore that packet_type - it does not work. I'll forward info to update documentation @ https://wiki.teltonika.lt/view/Codec


"What's the point then ?!"
You always need to send ACK to received records from device.

So what kind of ACK do we need to send ?
1. for TPC packets - 4 bytes. where first 3 bytes are zeroes. and last byte - is number of records received.
2. for UDP packet - 7 bytes. where first 5 bytes can be zeroes. and 6th byte is avl_packet_id - server must sent exactly the same avl_packet_id as with received records packet. and last 7th byte - is number of records received.

"The entire purpose of us picking UDP is to not have to deal with these kind of things (UDP is send and forget)."
Nor FM11/12/53 etc (older devices), nor FMB devices - have UDP communication in the style of send and forget. (except no_ack feature - see below)

"It is enough that the client needs to program his own code for decoding these protocols - No proper software packages are provided by Teltonika and the only code example is some undocumented C# example code that is horridly complex."
We suggest clients use other platforms for device tracking these days: https://wiki.teltonika.lt/view/Other_platforms
Since teltonika announced that tavl / tavl web -> will be going EOL: https://teltonika.lt/policies/eol/

****************

So I implemented the UDP in Python but am stuck on these pointless ACK packets.

What do I need to send there?

[answer] Please check how demo server works and answers records sent from device. If you configure tcp:0 in values.txt -> then server will launch in UDP mode.

Then all you need is to configure device to send records to your PC -> via port which you have opened.

Then all you need to do is to compare to documentation @ https://wiki.teltonika.lt/view/Codec

How does the device (FMB630) affected if I don't send these packets ?

[answer] FMB63/64 - uses the same protocols as FMB family devices. Except it additionally has codec16. But all codecs do require answer to records received by server.

Will it at some point give up on the old records and move on to sending the latest record ? (As it should)

[answer] no. if device does not receive answer to records sent -> FW will repeat records sending (will not delete them).

Records sending order depends on newest / oldest configuration.

Can you please come up with SIMPLE and CLEAR instructions on what needs to be done ? This messing around costs us time and money!

[answer] It is clearly defined how you need to formulate answer packet to sent records from FM device.

The only error - is like you described - with packet_type - which does not work. Never did as far as i know. Just documentation was old - and wasn't updated properly.

**************************

Additional info - there is experimental functionality developed @ 03.23.xx branch (it is not yet available in 03.25.xx branch latest FW).

This functionality is called no_ack. It works only via TCP. And it works like this:

1. FM device sends records to server via TCP.

2. IF FM device is configured with no ack. I.e. device deletes records if via TCP link layer it gets to know - that sent records packet was received by the server.

I.e. server does not need to actually send an answer packet to records received.

http://community.teltonika-gps.com/?qa=blob&qa_blobid=4770832246974996137

This feature will be available at some point in latest base FW version.

You can contact your sales manager - and request it. We might provide it as experimental version for you to test.

Regards

by

I tried to run the demo server but it doesn’t do anything.

In the FM3612 I wrote in the domain field my home ip and the port 7777. I forwarded that port to my home server. In the server config file I wrote my internal ip (192.168....) and the port (7777).

The server was up all day but it didn’t recived nothing and I was using the car with the gps device .

Did I configured something wrong?

***************

[answer] you need to configure (@ values.txt) your local IP - that is correct. You need to configure your local port - that is correct also.

Then you need to make sure that your configured port is open on your router / firewall.

You can check if the port you are trying to use is open on your router: https://www.yougetsignal.com/tools/open-ports/

The device itself -> you need to configure to send records -> to your EXTERNAL IP. Which is your router IP.

How to get to know your external ip? https://myexternalip.com/

So example:

1. in my case my local IP is: 192.168.1.136, im using port 5000

2. i check via https://www.yougetsignal.com/tools/open-ports/ -> and see that port 5000 is closed.

3. i go to router settings and add port forwarding:

4. afterwards check again if port is open -> now its open.

5. launch server_main with my local ip/port: 192.168.1.136:5000

6. to test - can launch hercules software -> https://www.hw-group.com/software/hercules-setup-utility

TCP client -> IP -> my external IP / port -> external port 5000.

And if with port all is ok -> you will be able to connect to server_main app -> via hercules software.

Regards

by
@Oceanfly I don't suppose you'd be willing to share your demo server code with me as well?

Many thanks.
by
HI,

can i please have demo server. The link is expired.

Thx