Wrong timestamp in JSON data


(Remcohn) #1

This is a piece of data i got earlier today for a node:

stdClass Object
(
    [port] => 1
    [counter] => 1
    [metadata] => stdClass Object
        (
            [time] => 2017-01-09T12:32:15.224329067Z
            [gateways] => Array
                (
                    [0] => stdClass Object
                        (
                            [snr] => 2.5
                            [rssi] => -116
                            [time] => 2017-01-09T12:32:15.20423Z
                            [gtw_id] => eui-fffeb827eba9cc4e
                            [channel] => 7
                            [altitude] => 7
                            [latitude] => 51.77467
                            [longitude] => 5.22301
                            [timestamp] => 3659699484
                        )

                    [1] => stdClass Object
                        (
                            [snr] => -14.5
                            [rssi] => -121
                            [time] => 2017-01-09T12:32:15.205645Z
                            [gtw_id] => eui-b827ebfffe4f4a22
                            [channel] => 7
                            [altitude] => 50
                            [latitude] => 51.7282
                            [longitude] => 5.29376
                            [timestamp] => 1194768516
                        )

                    [2] => stdClass Object
                        (
                            [snr] => 5
                            [rssi] => -103
                            [time] => 1754-08-30T22:43:41.128654848Z
                            [gtw_id] => eui-1dee138c7dd7f1a4
                            [channel] => 7
                            [altitude] => 5
                            [latitude] => 51.74474
                            [longitude] => 5.26719
                            [timestamp] => 410230220
                        )

                )

            [data_rate] => SF12BW125
            [frequency] => 867.9
            [modulation] => LORA
            [coding_rate] => 4/5
        )

    [payload_raw] => BjAAAAAAAAIAAAAA
)

The 'time' field of gateway[2] is wayyyy off, but the date on the gateway is set correctly. The gateway is a Lorank8, running the stock firmware.
I also noticed that the 'timestamp' field of all 3 gateways is very different, and none of them are even close to beeing the correct unix timestamp.

Has anyone any whats going wrong here?

Remco


#3

I noticed the same strange date/time (1754-08-30T22:43:41.128654848Z) on a new gateway nearby.

Actually, it is the same strange date/time, and it doesn't change over time!


(Remcohn) #4

oh good one, i didnt notice that yet, but you are right. the 'time' field doesnt change. the 'timestamp' field does. on a packet received a few hours later from the same node on the same gateway it is 3904588844.

The gateway is located in Hedel, The Netherlands, bit north of Den Bosch.
so if you are in that area, it might have been the same gateway.


#5

The gateway that I see is located in Wageningen, NL. So it looks like some software/configuration issue for the Lorank8 running stock firmware...
(I don't know the make/model of the gateway I see, but if it quacks like a duck...)


(Remcohn) #6

All Ideetron Loranks start with 0x1dee as their ID, so thats something you can check.
I'll check if i can get access to the gateway to possibly test things there, although i have no idea what.

Is there someone from TTN who can search all packets for this behavior and create a list of all gateways that are having this issue?


#7

The gateway I see having this behaviour has id eui-0000024b080e080d.


#8

In this case, it's probably no duck :persevere:

A little googling indicates that 1754-08-30T22:43:41.128654848Z is a 'magic' date in golang. (time.Time{} zero value), which probably places the bug at the server side...


(Hylke Visser) #9

Just had a look at the issue. It looks like these gateways are misconfigured. They're sending data in a wrong format. Please make sure your gateways are running the correct packet forwarder software and configuration.


(Dario Gonano) #10

I am experiencing the same timestamp problem.

The device I am using is a GlobalSAT LT-100E which i s Uploading the proper Payload.

The gateway I am using is a Kerlink Wirnet Station;
I updated the FW via USB installing the TTN Packed Forwarder version dota_thethingsnetwork_v1.3_EU.tar.gz.

The TTN packet forwarder works fine and I get correct data on the TTN console.

As an example I list below an extract of the Payload captured on the TTN console,showing only the MetaData Payload:

{
  "time": "2017-07-03T12:58:28.732164193Z",
  "frequency": 868.1,
  "modulation": "LORA",
  "data_rate": "SF12BW125",
  "coding_rate": "4/5",
  "gateways": [
    {
      "gtw_id": "eui-0000024b........",
      "timestamp": 1175897596,
      "time": "2017-07-03T12:58:28.737573Z",
      "channel": 0,
      "rssi": -25,
      "snr": 8.2,
      "rf_chain": 1,
      "latitude": 46.14417,
      "longitude": 13.22217,
      "altitude": 171
    }
  ]
}

Converting the timestamp "1175897596" I found it is 07/04/2007 orario 00:13:16 +0200 (CEST).
As you can see it doesn't match with the same Metadata "time": "2017-07-03T12:58:28.737573Z"

I was thinking the problem was on the Kerling GW assuming a wrong date and time (and so timestamp) was present and assuming the Metadata Payload get the timestamp and time from the Kerling GW.

connecting via ssh the Kerling GW I get the following information (few minutes after receiving the previous payload):

>date
Mon Jul  3 15:04:07 CEST 2017

>date +%s
1499087080

converting the timestamp "1499087080" I found a correct information "03/07/2017 orario 15:04:40 +0200 (CEST)".

Could you please let me know where the problem is?
The timestamp and time information stored in the Metadata Payload is fetched fro mwhere?

Thanks Dario


#11

Both are transmitted by the gateway. The values are completely unrelated. The time is wall clock time. The timestamp is an internal reference for the concentrator chip which is not synchronized to the wall clock.

There is no problem...


Gateway time timestamp in console
(Dario Gonano) #12

Thank you for your answer.

As I know timestamp and date are not unrelated (See http://www.unixtimestamp.com/)

As I was writing I verified on the Kerlink Gateway the Timestamp information and date are the same.
I used a timestamp to date converter (Refer to http://www.unixtimestamp.com/ ) to check it with the below listed results:

Date = "03/07/2017 orario 15:04:40 +0200 (CEST)"
Timestamp = "1499087080"
Converted Timestamp = 07/03/2017 @ 1:04pm (UTC)

The point is:
If the Timestamp and Date on the Kerlink GW is correct, how the Timestamp in the Consolle Metadata Payload differs?


(Hylke Visser) #13

The timestamp 1175897596 that you posted before is in no way related to a Unix timestamp. It's a uint32 with the 32 lsb of the number of microseconds since the concentrator started, while a Unix timestamp is the number of seconds since 1 Jan 1970 00:00:00 (minus leap seconds).


(Arjan) #14

...which is used to tell a gateway at what relative time it should transmit a downlink, if applicable.

Like if in an uplink (say, a Join Request) the gateway says its current timestamp is 1,175,897,596 and the TTN backend commands the gateway to transmit a downlink after 5 seconds (say, for a Join Accept), then TNN will set the timestamp for that downlink to 1,175,897,596 + 5,000,000 = 1,180,897,596. This way the gateway does not need to know the exact real time (wall time).