RAK7240 NTP/GPS-time on buffered packages? time: null

johan · January 29, 2021, 7:46am

Hi
We have tried to store lora packages on the 7240 gateways SD card if communication to the Lorawan network server is interrupted/down. All of the messages arrive to the LNS again when network is established but the Lora packages have the same timestamp, not when the messages arrived in the gateway.

We tried using GPS time and NTP server enabled… We recieve. time: null if the GPS reciever is broken we should get the NTP time ? We recieve time: null

We need prompt answer for our project. What can we do? Is it a bug ?

Image here

cstratton · January 29, 2021, 3:44pm

We recieve. time: null if the GPS reciever is broken we should get the NTP time ? We recieve time: null

Typically a LoRaWan network server should not “trust” the time of a gateway’s clock, unless that is directly derived by GPS. Otherwise all a server pays attention to is the rolling microsecond counter, which is used just to time downlink replies sent back through that same gateway, but not as a source of “time” when reporting packets to an application. As such, a packet forwarder will not traditionally include an actual time, unless it is coming from GPS.

eg, here in the upstream Semtech version of sourcecode, the receive time is only inserted if the GPS reference time is valid:

github.com

Lora-net/packet_forwarder/blob/master/lora_pkt_fwd/src/lora_pkt_fwd.c#L1616


      
              exit(EXIT_FAILURE);
          }
          
          /* Packet RX time (GPS based), 37 useful chars */
          if (ref_ok == true) {
              /* convert packet timestamp to UTC absolute time */
              j = lgw_cnt2utc(local_ref, p->count_us, &pkt_utc_time);
              if (j == LGW_GPS_SUCCESS) {
                  /* split the UNIX timestamp to its calendar components */
                  x = gmtime(&(pkt_utc_time.tv_sec));
                  j = snprintf((char *)(buff_up + buff_index), TX_BUFF_SIZE-buff_index, ",\"time\":\"%04i-%02i-%02iT%02i:%02i:%02i.%06liZ\"", (x->tm_year)+1900, (x->tm_mon)+1, x->tm_mday, x->tm_hour, x->tm_min, x->tm_sec, (pkt_utc_time.tv_nsec)/1000); /* ISO 8601 format */
                  if (j > 0) {
                      buff_index += j;
                  } else {
                      MSG("ERROR: [up] snprintf failed line %u\n", (__LINE__ - 4));
                      exit(EXIT_FAILURE);
                  }
              }
              /* convert packet timestamp to GPS absolute time */
              j = lgw_cnt2gps(local_ref, p->count_us, &pkt_gps_time);
              if (j == LGW_GPS_SUCCESS) {

It’s somewhat questionable if you’d have reliable NTP time when you cannot establish a connection to the LoRaWan server; possibly, or you might have a time last synchronized quite a while ago which has now drifted. Shortly after boot you may also have a time which is wrong by many months or years (either being in 1970, or being the most recent modification timestamp in the filesystem).

Also keep in mind that a LoRaWan server will ordinarily reject packets delivered to it out of frame count order, so if any more recent packet has snuck in (perhaps via another gateway) the whole saved archive will be ignored unless you disable frame counter checks - archiving packets before processing is not really anticipated in the design of LoRaWan, so implementations tend to run into incompatibilities.

If you have an ability to change the operation of the LoRaWan network server or to do some pre-processing of the feed of stale packets server side before they are processed, then one thing you could do is to extract an approximate time progression from the timestamps recorded in the stats packets (if those are actually making it into the archive?)