brocaar / chirpstack-application-server

ChirpStack Application Server is an open-source LoRaWAN application-server.
https://www.chirpstack.io
MIT License
502 stars 325 forks source link

Time info missing on rxInfo component in the new version #64

Closed mihaispataru closed 7 years ago

mihaispataru commented 7 years ago

With the new version of lora-app-server the time information of the frames disappeared. Ex:

{ "applicationID":"1", "applicationName":"Test", "nodeName":"S11", "devEUI":"0004a30b001aa4d2", "rxInfo":[ { "mac":"7276ff00ff020072", "rssi":-82, "loRaSNR":9.8, "name":"Indoor-home-dan", "latitude":44.4082630369662, "longitude":25.999295711517338, "altitude":15 } ], "txInfo":{ "frequency":868300000, "dataRate":{ "modulation":"LORA", "bandwidth":125, "spreadFactor":7 }, "adr":false, "codeRate":"4/5" }, "fCnt":4500, "fPort":1, "data":"MQ==" }

brocaar commented 7 years ago

Does your gateway have a GPS?

mihaispataru commented 7 years ago

No. We use 3 different types of gateways (Kerlink Femto, Kerlink Outdoor and IMST+rPI). We have a history of all the received frames, and we saw that after we made the upgrade to the latest version, the time info disappeared, nothing else was changed in our infrastructure.

brocaar commented 7 years ago

Note that this was a bug and the time was always set to a value like 0001-01-01..... The only accurate time-source would be when the gateway has a GPS (e.g. when doing triangulation in the future, the system-time of a gateway would not be accurate enough). See also:

    "rxInfo": [
        {
            "mac": "0303030303030303",                 // MAC of the receiving gateway
            "name": "rooftop-gateway",                 // name of the receiving gateway
            "latitude": 52.3740364,                    // latitude of the receiving gateway
            "longitude": 4.9144401,                    // longitude of the receiving gateway
            "altitude": 10.5,                          // altitude of the receiving gateway
            "time": "2016-11-25T16:24:37.295915988Z",  // time when the package was received (GPS time of gateway, only set when available)
            "rssi": -57,                               // signal strength (dBm)
            "loRaSNR": 10                              // signal to noise ratio
        }
    ],
mihaispataru commented 7 years ago

What we have regardin GPS, is that we manually set the coordinates in the "Manage Gateways" interface.

As you can see below this is a live export from the mqtt topic

mosquitto_sub -t "application/+/node/+/rx" -v
application/2/node/0004a30b001a4ae7/rx

{  
   "applicationID":"2",
   "applicationName":"PKGTST",
   "nodeName":"S10-OTAA",
   "devEUI":"0004a30b001a4ae7",
   "rxInfo":[  
      {  
         "mac":"7276ff00ff020072",
         "rssi":-41,
         "loRaSNR":8.2,
         "name":"Indoor-home-dan",
         "latitude":44.4082630369662,
         "longitude":25.999295711517338,
         "altitude":15
      }
   ],
   "txInfo":{  
      "frequency":868100000,
      "dataRate":{  
         "modulation":"LORA",
         "bandwidth":125,
         "spreadFactor":7
      },
      "adr":false,
      "codeRate":"4/5"
   },
   "fCnt":17506,
   "fPort":102,
   "data":"LRE="
}
brocaar commented 7 years ago

Note that you can set the location manually (if you would have a GPS it would be set automatically). However this is unrelated to the time field. The gateway only provides a timestamp when the frame was received when it has a GPS receiver.

LoRa Server or LoRa App Server can't set this timestamp for you as it doesn't know the latency between the gateway and the server. E.g. in some installations there might be a latency of multiple seconds.

As mentioned, there was a bug exposing a 2001-01-01 00:00:00 timestamp (which was of no use). This has been fixed into leaving out the timestamp field when there is no time known.

mihaispataru commented 7 years ago

Ok, now i understand, but how come that it worked until a certain version. It was set by the LoRa Server?

brocaar commented 7 years ago

Because of a "bug" in the code :-)