FMB003 with UDP communication issue

Hi,
We are trying to parse Codec 8 data over UDP by this manual:
https://wiki.teltonika-networks.com/view/VCode#Codec_8
Each time we get the exactly the same data and I’m thinking that we send wrong ACK.
For example we get this data from the tracker:
04c8cafe014f000f33353430313831313637393435333208110000017b3e29e83800000000000000000000000000000000ef1006ef00f00050001504c800450208b50000b60000423133180000cd753fce00d7430fff44002802f10000f2a81000171b36000000017b3e29e84200000000000000000000000000000000f01006ef00f00050001504c800450208b50000b60000423133180000cd753fce00d7430fff44002802f10000f2a81000171b36000000017b3e29ffa9000000000000000000000000000000000000000000000000017b3e2a039000000000000000000000000000000000ef1006ef01f00150011504c800450208b50000b60000423398180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a039a00000000000000000000000000000000f01006ef01f00150011504c800450208b50000b60000423398180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a0f4800000000000000000000000000000000ef1006ef00f00050001504c800450208b50000b600004231d5180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a133000000000000000000000000000000000f01006ef00f00050001504c800450208b50000b600004231d5180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a171800000000000000000000000000000000ef1006ef01f00150011504c800450208b50000b6000042335c180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a172200000000000000000000000000000000f01006ef01f00150011504c800450208b50000b6000042335c180000cd753fce00d743100544002802f10000f2a81000171b36000000017b3e2a598000000000000000000000000000000000ef1006ef00f00050001504c800450208b50000b60000423286180000cd753fce00d743100944002802f10000f2a81000171b36000000017b3e2a615000000000000000000000000000000000f01006ef00f00050001504c800450208b50000b60000423286180000cd753fce00d743100944002802f10000f2a81000171b36000000017b3e2a653800000000000000000000000000000000ef1006ef01f00150011504c800450208b50000b600004234b6180000cd753fce00d743100944002802f10000f2a81000171b36000000017b3e2a654200000000000000000000000000000000f01006ef01f00150011504c800450208b50000b600004234b6180000cd753fce00d743100944002802f10000f2a81000171b36000000017b3e2a74d9000000000000000000000000000000000000000000000000017b3e2a9be800000000000000000000000000000000ef1006ef00f00050001504c800450208b50000b60000423229180000cd753fce00d743100d44002802f10000f2a81000171b36000000017b3e2a9bf200000000000000000000000000000000f01006ef00f00050001504c800450208b50000b60000423229180000cd753fce00d743100d44002802f10000f2a81000171b36000000017b3e2aa3b800000000000000000000000000000000ef1006ef01f00150011504c800450208b50000b600004233fc180000cd753fce00d743100d44002802f10000f2a81000171b360011

And we try to send this ACK:
0005CAFE014F11 or even 0005ABCD014F11. But the tracker keeps sending same payload but with new avl packed id.

The ACK is sent to the same IP:PORT from where we get the tracker data.

Thanks in advance.

Hi Azimin,

Good day, as per checking the packets that you provided are correct, the records sent to your server are different packets it is not the same records, you can check the timestamps when these packets were created.

When configuring UDP a response is needed by the server to confirm that the data was received successfully, otherwise, the data is marked as not yet received.

Your reply is correct as per the AVL ID records

0005 - Length
CAFE - Packet ID
01 - Not usable byte
4F - AVL packet ID
11 - Number of Accepted Data

Wiki page reference for Codec 8: Codec - Wiki Knowledge Base | Teltonika GPS (teltonika-gps.com)

If you have doubts about the number of records you can adjust it by configuring the data acquisition settings
image

Reference: FMB920 Data acquisition settings - Wiki Knowledge Base | Teltonika GPS (teltonika-gps.com)

Best Regards
Maynard C.

Hi Maynard,
So if the server response is correct why I still receive the same data packet from the tracker? I’m using nodejs and I convert hex value to Buffer, or should I convert hex string to buffer?

Hello,

Kindly check the following.

  1. Timestamp.
  2. Number of Data.
  3. AVL packet ID.

Maybe you are not receiving the same data, you can also try to trigger the DIN 1 to test make it as an ignition source and trigger it, then check from your server if the ignition event was there.

Regards
Maynard C

What you be so kind and clarify, what is wrong - packets to the server or response from the server?

This topic was automatically closed after 10 days. New replies are no longer allowed.