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
1,351 views
in Vehicle tracking by anonymous

I have an FMB900 

FW: 03.25.15.Rev02

Hw: FMB900 Mod:3

Data Acquisition Settings are

Data Acquisition settings are default (except Min Speed delta is now 0 as it is not required).

The IO settings are below:

The IO settings (set at default) - all Priority values are either Low or None. Nothing is High or Panic.

On Moving -  I am expecting the FMB900 to send all the generated records to the server every 120s based on the information at

https://wiki.teltonika-gps.com/view/FMB900_First_Start

Based on my settings - Records Generated

  • every Min Period = 300s
  • every Min Distance 100m
  • every Min Angle = 60 degrees

and sent every Send Period (120s) only requiring a Min Saved Record of 1.

But the records are being sent more often than 120s.

Looking at the server logs, data packets are not being sent every 120s, they are being sent far more frequently, below is a sample of the server logs to show this

2020-08-04 17:17:27  INFO: [a6378b17: teltonika < 1.2.3.4] HEX: Short_String

2020-08-04 17:17:27  INFO: [a6378b17: teltonika > 1.2.3.4] HEX: 01

2020-08-04 17:17:29  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:17:29  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:17:49  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:17:49  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:18:09  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:18:09  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:18:30  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:18:30  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:18:50  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:18:50  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:19:10  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:19:10  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

2020-08-04 17:19:30  INFO: [46cf1a64: teltonika < 1.2.3.4] HEX: Long_String

2020-08-04 17:19:30  INFO: [46cf1a64: teltonika > 1.2.3.4] HEX: 00000001

I have anoymized the IP and replaced the Hex string with the value of Long_String or Short_String for the sake of brevity.

Line 2 of the above server server logs shows the correct acknowledgement of 01 when the device initially sends the IMEI (Line 1 in the logs, replaced in the above logs with Short_String).

So - it appears that Send Period (for moving) is being overridden and records are being sent whenever they are being Generated. From speaking to one of your Sales Managers, he stated the following:

Please have in mind, that the send period can overridden, if you have any values in the other fields like min angle or distance.

For example if you reach an angle of 10 or more, sooner than that 120 s cut off, then it will send a record earlier.

What your Sales Manager states appears to match what the device is doing - but your documentation states:

Send Period controls the frequency of data being sent to server over GPRS. Module makes attempts to send collected data to the server every defined period of time. If it does not have enough records (depends on the parameter Min. Saved Records described above), it tries again after the defined time interval.

Can you confirm how the device is supposed to behave? Or assist in getting the device to behave as your documentation states?

Thanks

by anonymous

After updating the FMB900 to 03.25.15.Rev.32, doing a Reset Configuration (using Configurator v1.14.14.23292 as supplied with the 03.25.15.Rev.32 firmware) and re-configuring the FMB900 manually (i.e. putting all the config information back in), the behaviour is the same as before.

Your documentation at https://wiki.teltonika-gps.com/view/FMB900_Data_acquisition_settings shown below,

Suggests that records will be generated as per Min Period, Min Distance, Min Angle and Min Speed Delta but sent as per Send Period. Your documentation at https://wiki.teltonika-gps.com/view/FMB900_First_Start shown below,

further suggests the same. The following answers by Teltonika Support are saying the same thing:

https://community.teltonika-gps.com/3791/configure-teltonika-fmb920-send-data-packet-minute-server

https://community.teltonika-gps.com/10148/to-send-data-every-10s-when-in-movement

From the 2nd link above;

You can configure data acquisition parameters in configurator. If you want device to send data every 10 seconds when moving, just set Send Period parameter to 10 seconds. Please note, that device will try to send data every 10 seconds, but if no record was generated, device has nothing to send. You can configure record generation by changing Min period, Min Distance, Min Angle and Min Speed parameters. If Min period parameter is set to 10 s, record will be generated every 10 seconds, as well as when vehicle exceeds Min Distance, Min Angle or Min Speed  thresholds.

Your answer matches your documentation - i.e. Record Generation is controlled by Min Period, Min Distance, Min Angle and Min Speed Delta and Send Period controls the sending.

I collected the logs as instructed by https://wiki.teltonika-gps.com/view/How_to_debug_FM3001_device_over_Android_smartphone%3F.

My analysis of the debug logs and my server logs shows the following (no values in IO are set as High or Panic - they are as the default.):

  • Send Period only applies to Min Period and is overridden by Min Saved Records.
  • Send Period does not apply to values in Min Distance, Min Angle and Min Speed Delta (these 3 variables are affected by Min Saved Records)

So what happens is this - records are sent to the server (assuming the nbr of records stored are greater than or equal to Min Saved records) when

  • Send Period is exceeded (only in relation to Min Period)
  • Or Min Distance has been exceeded
  • Or Min Angle has been exceeded
  • Or Min Speed Delta has been exceeded

This does not match the behaviour as stated in your documentation & the 2 answers I referenced above.

My apologies - I probably have labored the point but I want to make sure there is no misunderstanding. I can provide debug and server logs to demonstrate the behaviour.

Now - I either have a defective device, your documentation is incorrect or the firmware (both 03.25.15.Rev.32 and 03.25.15.Rev.02 have a bug. Can you confirm which please?

Thanks

1 Answer

0 votes
by anonymous
Hello

From pictures you sent I see that Min Angle is set to 10 not 60, If Min Angle is 10 device will generate record every 10 degree. With this settings you will have lot of records, especially when vehicle is turning, please try to set higher Min Angle value or disable it for test by setting to zero and check how is device generating data. Each condition (Min Perid, Min distance, MIn Angle, Min Speed Delta) is checked independently and if at least one condition is met, then device generates record.
Best answer
by anonymous

Thanks for your reply.

From pictures you sent I see that Min Angle is set to 10 not 60, If Min Angle is 10 device will generate record every 10 degree. With this settings you will have lot of records, especially when vehicle is turning, please try to set higher Min Angle value or disable it for test by setting to zero and check how is device generating data. 

Since the posts I changed the Min Angle to 60. The behaviour is the same.

Each condition (Min Perid, Min distance, MIn Angle, Min Speed Delta) is checked independently and if at least one condition is met, then device generates record.

Yes - for these, the device generates the record\s but it also sends it instantly. It doesn't wait for Send Period. The documentation states that the device will generate records but only send them when Send Period (along with Min Saved Records) is met or exceeded.

by anonymous
That is correct, because if Link is open, then device sends record immidiately. Device waits Send Period only when Link is closed. Device closes Data Link after configured Open Link Timeout parameter (GPRS Settings -> Record Settings). If your Send Period is 120 seconds, any value of Open Link Timeout above 120 will keep Link open all the time.
by anonymous
Thanks for your quick reply.

I understand how Min Distance, Min Angle & Min Speed Delta now work - even if the documentation makes you think otherwise. Thank you.

The device still waits for Send Period to send records generated by Min Period even if the Link is open. I set the Open Link Timeout to 600s and Min period to 60s (and Send Period to 60s) - the Link was open and the Min Period records were sent every 60s. [DIN1\IGN was on and the device was not moving, so no Min Distance, Min Angle & Min Speed Delta records were generated\sent]

So - Send Period only applies to Min Period not Min Distance, Min Angle & Min Speed Delta [assuming Min Saved Records has been met or exceeded]?
by anonymous

If there were no Min distance, Min Angle and Min Speed Delta records generated, only records according to Min Period, which was 60 seconds and Data Link was open, device was generating records every 60 seconds and sent them immidiately.

"So - Send Period only applies to Min Period not Min Distance, Min Angle & Min Speed Delta [assuming Min Saved Records has been met or exceeded]?" - No, Send Period applies to all kind of records when Data Link is closed.

For example, if you set Min Period to 120, Send Period to 600 and Open Link Timeout to 10, then you should be receiving records every 600 second

by anonymous

Hi Janusz,

I really appreciate you taking the time out to clarify the workings of the device and these settings.

If I want records generated only

  • Every 60s
  • Every 100m
  • Every 60 degree angle change
  • Speed delta disabled
but sent every 90s, would the following settings work?
  • Min Period 60s
  • Min Distance 100m
  • Min Angle 60 degrees
  • Min Saved Records 1
  • Send Period 90s
  • Open Link Timeout 10s.
Thanks
by anonymous

Hi 

After your replies, I think I have a better understanding - please correct the below if it is wrong:

If the data link is open (controlled by Open Link Timeout)

  • Min Period - when this is reached, records will be sent immediately
  • Min Distance, Min Angle & Min Speed Delta - when these records are generated - they are sent immediately.

[I am assuming Min Saved Records is set to 1.]

Send Period controls how often Data Link is opened and once open, it will stay open for the duration of Open Link Timeout.

If it is required that generated records are not sent immediately (really talking about Min Distance, Min Angle & Min Speed Delta) then you need to reduce the Open Link Timeout to a small nbr (like 10s as you suggested) and make sure Send Period is something larger like 60s (as you suggested).

Reading a little more on https://wiki.teltonika-gps.com/view/Codec#Codec_8 for Example 1 which is sending a few extra IO elements in the AVL packet - like GSM Signal, DIN1 Status, External Voltage, Active GSM Operator & iButton (about 5) which is reasonable - the 

  • IMEI packet - 15 Bytes
  • Server Acknowledgement - 1 Bytes
  • AVL Packet - 58 Bytes
  • Server Acknowledgment - 4 Bytes

Making a total of 78 Bytes (approx). Many M2M providers round up to 1KB on each session (open GPRS connection & then close it, with possibly a 30s timeout check) - this would result in 1KB charges if you force the device to send every 60s Send Period (using a low value for Open Link Timeout).

Whereas if you keep the GPRS session open - using a higher value for Open Link Timeout (say 600s) the device will send it's records as soon as they are generated - and all records after the 1st one would be 16 Bytes less (as there is no IMEI packet & associated acknowledgment), so you could send approx. 15 packets\records and still be under 1KB consumption?

So, it makes sense to set a larger Open Link Timeout.

One last question: Open Link Timeout - if this is set to say 600s, when the 600s are up, will it just close? Or stay open further if packets are being sent? What decides if it open and closes?

Many Thanks

by anonymous

Hello again,

"If I want records generated only

  • Every 60s
  • Every 100m
  • Every 60 degree angle change
  • Speed delta disabled
but sent every 90s, would the following settings work?
  • Min Period 60s
  • Min Distance 100m
  • Min Angle 60 degrees
  • Min Saved Records 1
  • Send Period 90s
  • Open Link Timeout 10s."
Above settings are OK, but remember that when record will be generated during open link, it will be send immidiately. For Example: device sent records to a server and after 5 seconds angle will change more then 60 degrees - a new record will be generated and sent immidately and time counter will be reset (will wait another 10 seconds)
by anonymous
"If data link is open
Min Period - when this is reached, records will be sent immediately" - yes, if data link is open record will be generated and sent
Min Distance, Min Angle & Min Speed Delta - when these records are generated - they are sent immediately" - yes, if link is open
"Send Period controls how often Data Link is opened and once open, it will stay open for the duration of Open Link Timeout." - Send period is the time after which (since closing the link) device checks if there are saved records in device memory and if there is enough records (according to Min Saved Records) Data Link will be opened and reords will be sent.
"If it is required that generated records are not sent immediately (really talking about Min Distance, Min Angle & Min Speed Delta) then you need to reduce the Open Link Timeout to a small nbr (like 10s as you suggested) and make sure Send Period is something larger like 60s (as you suggested)." - Yes, from device side it doesn't matter what kind of records (time, distance, speed, angle) must be send.
Regarding data packet, you are right that providers counting data in a different way, some charges for opening session. From that reason Data Acquisition and GPRS are so highly configurable.
"One last question: Open Link Timeout - if this is set to say 600s, when the 600s are up, will it just close? Or stay open further if packets are being sent? What decides if it open and closes?" - Open Link Timeout works like this: after all records are sent to a server, device doesn't close link, it waits configured time (Open Link Timeout), if during that time device will generate a new record, it will be send immidiately and counter will be reset. If during that time no record would be generated, data link between device and server would be closed after timeout is reached. For example if Data Link Timeout is set to 120 seconds, device will close data link after 120 seconds since last record was sent and if there were no new records during that time, if after 30 seconds since last record has been sent device generate new record it will be send and device will wait another 120 seconds (not 90 seconds).
by anonymous
Hi Janusz,

Just a quick reply to say - both your recent replies providing great detail on how Data Link etc work are greatly appreciated!!

Thanks