Issue with obtaining accurate timestamp for scan data in current date and time in LMS511 and LMS111 sensors

Question

I need to obtain a timestamp for every scan data with the current date and time. However, I am facing some issues with getting the correct time and date values.

I have made changes to the current time in sopas engineering tool, the obtained data still shows the wrong time and date.

I suspect that there might be an error in how I am converting the timestamp. Could someone please guide me on the correct way to obtain and convert the timestamp for accurate time and date representation?

This is the data that i get from the lms111 sensor

sRA LMDscandata 1 1 1195F7E 0 0 5DD8 5DDB BB7E993F BB7EF691 0 0 FF 7 0 1388 168 0 1 DIST1 3F800000 00000000 AAE60 1388 51 515 502 4FC 501 50F 4F0 4F7 501 4E1 4EA 4EC 4F3 4D2 4D7 4E4 4D2 4CD 4CF 4E1 4C5 4D4 4D7 4D5 4D9 4D0 4CD 4D3 4D3 4C8 4C5 4C8 4D5 4D3 4C6 4C6 4C0 4C8 4C1 4CD 4CE 4C9 4CA 4D4 4C8 4C8 4D4 4CE 4C4 4D1 4CA 4C4 4C3 4CF 4DC 4D8 4C3 4D2 4C5 4C8 4D3 4CD 4CB 4CE 4DB 4E8 4E8 4DB 4EB 4EE 4EC 4F4 4E3 4EF 4F1 4F6 510 4FD 4FE 503 508 508 0 0 1 3 SL2 0 1 7B2 1 1 0 34 19 6AB08 0

The bold numbers that i convert into timestamp

def hex_to_date(hex_value):
    try:
        hex_value = hex_value.replace("0x", "")
        decimal_value = int(hex_value, 16)
        timestamp = datetime.datetime.fromtimestamp(decimal_value)
        return timestamp.strftime("%Y-%m-%d %H:%M:%S")
    except ValueError:
        return "Invalid hexadecimal value"

   hex_value = "BB7EF691"
   date = hex_to_date(hex_value)
   print(date)```

This is the answer that i got 2069-09-06 02:27:29.
But expected answer is the current date and time.


Any help or suggestions would be greatly appreciated. Thank you!

Answer 1

I am not familiar with the lms111 sensor but by googling for some documentation I think I can see the problem.

Have a look at the answer here: How to extract x and y coordinates from LIDAR sensor(LMS511) data in Python?

And also the docs on p73 here: https://cdn.sick.com/media/docs/7/27/927/technical_information_telegram_listing_ranging_sensors_lms1xx_lms5xx_tim2xx_tim5xx_tim7xx_lms1000_mrs1000_mrs6000_nav310_ld_oem15xx_ld_lrs36xx_lms4000_en_im0045927.pdf

Part	Description	Type
Time since start up in µs	Counting the time since power up the device; starting with 0. In the output telegram this is the time at the zero index before the measurement itself starts.	Uint_32
Time of transmission in µs	Time in µs when the complete scan is transmitted to the buffer for data output; starting with 0 at scanner bootup.	Uint_32

I think you are taking the second of these.

But note that both of them are only relative time since the device was powered up, they are not a unix timestamp (which would count from 1 Jan 1970)

Then to explain why the value is too large rather than too small:

https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp

Return the local date and time corresponding to the POSIX timestamp, such as is returned by time.time()

https://docs.python.org/3/library/time.html#time.time

Return the time in seconds since the epoch as a floating point number

So fromtimestamp expects a value in seconds since 1 Jan 1970

But you are passing a value in µs since the device was booted up.

As I said I am not familiar with the device in question. But note that on p84 (and elsewhere) of the pdf linked above there appears to be another section where actual date-time data can be received.

Also on p91 it says (re the LMS1xx):

Attention: There is no real time clock inside the device. When the scanner is switched off and after a reboot, the time has to be set again.

...and details an api call for setting the date and time.

Answer 2

As Anentropic already pointed out, these are not the timestamps you're looking for. Let me instead explain how to get the proper one.

Recall from my previous answer on parsing the measurement telegrams that after the fixed header, there is a number of of optional sections. We dealt with one of them that contains measured distances. The real timestamp has a separate section (the second last):

# of encoder blocks         0
[<encoder info>]
# of 16-bit channel blocks  1
[<channel blocks>]
# of 8-bit channel blocks   0
[<channel blocks>]
Position                    0
[<position info>]
Device name                 0
[<name text>]
Comment                     0
[<comment text>]
Time                        0     <----- Here
[<timestamp>]
Events                      0 
[<event info>]

The layout of this part of the telegram is documented in Telegram Listing reference, on page 109:

Note that this section is optional, and you have to configure the sensor to include it in the measurement telegrams. In your case, it is not enabled (hence the 0 in the first field, and the rest omitted).

---

The configuration of the contents of the measurement telegrams is accomplished via the LMDscandatacfg telegram (Telegram Listing, section 4.3.1, pages 80-82). The specific field you're looking for is the second last one:

When this field is set to 1, the measurement telegrams will contain the timestamp section.

You should be able to set this up in SOPAS as well, and save it to non-volatile memory, but for practical purposes, I found it useful to send this telegram every time I connect to the sensor (thus making sure it's always configured the way I want, without needing to rely on other software).

---

Finally, you need to be able to set the sensor's clock in order for the timestamps to have a useful value. This can be accomplished using the LSPsetdatetime telegram (Telegram Listing, section 4.4.1, pages 122-123). The documentation contains the following important notice:

Attention: There is no real time clock inside the device. When the scanner is switched off and after a reboot, the time has to be set again.

This means that this is yet another configuration telegram to send every time you establish a new connection with the sensor.