TTIG Problems, - no location data, wrong date/time, wrong channel and stability issues

#124

Hey Franz,

The updates are now rolled out to the EU cluster as well.

Regards,
Krishna

3 Likes
#125

Hello Krishna,

my TTIGs work like a charm … I’m really impressed
many thanks for this solution 8-;))

cu
Franz

1 Like
#126

Yes @KrishnaIyerEaswaran2, it works fine now.
But still missing the TTNmapper integration (read: not shown on the map with use of the app)
Yes, location is set correctly and visible for the public

BR,

Jeroen

#127

After i noticed the new firmware rollout post here, today i reinstalled my TTIG.
Now it delivers time of day in metadata, great! :grinning:
But: it’s about 1 second late, compared to my MatchX1701 gateway which uses GPS time.

Or the MatchX1701 is wrong? :frowning_face:

Need to analyze this further. Will keep you posted here.

"gateways": [
    {
      "gtw_id": "eui-40d63cfffeMATCHX",
      "timestamp": 64530420,
      "time": "2020-02-28T18:20:49.389245Z",
      "channel": 5,
      "rssi": -69,
      "snr": 8,
      "latitude": 52.53737,
      "longitude": 13.41779,
      "altitude": 60
    },
    {
      "gtw_id": "eui-58a0cbfffeXXTTIG",
      "timestamp": 568394828,
      "time": "2020-02-28T18:20:48.352178096Z",
      "channel": 0,
      "rssi": -78,
      "snr": 8.25
    }
  ]
}
#128

‘GPS Time’ is normally understood to be the time at the beginning of 1980. Since then there has been 18 leap seconds added, so there is now an 18 second difference between the time the GPS network uses as a base and UTC time.

I suspect what you mean is ‘time obtained from a GPS’. The time taken from the GPS (and then used by the gateway) can be different from UTC time.

Its often assumed GPSs put out UTC time, this is not always the case.

#129

I know all that, but it does not explain why we see a difference of around 1 second here.

The MatchX gateway uses time obtained from gps for feeding the PPS input line of Semtech’s concentrator chip. The packet concentrator code (Semtech) draws absolute time from NMEA sentences of same gps signal. For me it looks like this code has a bug: if NMEA record arrives near top of second, it is intepreted with the next pps pulse, instead with previous. This makes the absolute time advance by 1 second.

If this is the root cause here, the “new” TTIG time will probably be correct.

#130

Just for the sake of completeness:

I don’t think it was new firmware, but these were changes in the backend instead (like maybe the bridge sitting between the TTIG and V2, or between V3 and V2). Given that, even though the TTIG indeed knows time, maybe the time in the meta data is added at some later stage. I guess that’s unlikely though, if only as for large latency then even for perfect clocks that would yield a time that is in advance rather than late.

If one wants to know, maybe one can compare UART logging to the values in the meta data.

#131

That depends, but I dont know the software.

If at powerup\startup the Gateway waits for the GPS (which has also just powered up) to get a fix or the time and then updates its internals with that time and then uses the PPS to increment that time; then the time the gateway uses could indeed be out by a second or more.

If however the extraction of the time from the GPS NMEA data is a continuous process (rather than just at startup) then after at most 12.5 minutes of good reception the GPS ought to be putting out the time that is equivalent of UTC.

#132

It’s always that tricky +/- 1 second problem, which maybe a result of not advanced code for PPS & time handling.

#133

For all packet forwarders based on the semtech code this is applies.

#134

Indeed so, but all too often coders are not aware that GPSs do not always put out UTC.

#135

But at least the coders at Semtech/Cycleo were aware of that:

And each time an NAV-TIMEGPS UBX message has been received:

  • get the concentrator timestamp (using lgw_get_trigcnt, mutex needed to protect access to the concentrator)
  • get the GPS time contained in the UBX message (using lgw_gps_get)
  • call the lgw_gps_sync function (use mutex to protect the time reference that should be a global shared variable).

Then, in other threads, you can simply used that continuously adjusted time reference to convert internal timestamps to GPS time (using lgw_cnt2gps) or the other way around (using lgw_gps2cnt). Inernal concentrator timestamp can also be converted to/from UTC time using lgw_cnt2utc/lgw_utc2cnt functions.

#136

The TTIG seems to pull system time on some unknown way over the 443 port from the TTN network server:

1970-01-01 00:00:14.572 [TCE:INFO] Connecting to INFOS: wss://lns.eu.thethings.network:443
1970-01-01 00:00:15.325 [TCE:INFO] Infos: 58a0:cbff:feXX:XXX muxs-::0 wss://lns.eu.thethings.network:443/traffic/eui-58A0CBFFFEXXXXXX
1970-01-01 00:00:15.461 [TCE:VERB] Connecting to MUXS…
1970-01-01 00:00:16.202 [TCE:VERB] Connected to MUXS.
2020-02-29 11:48:03.166 [RAL:WARN] Ignoring unsupported/unknown field: antenna_gain
2020-02-29 11:48:03.173 [RAL:INFO] Lora gateway library version: Version: 4.1.1;

#137

Did some simple real time analysis, see enclosed photo.
The time of the TTIG seems pretty precise, in terms of some milliseconds.Screenshot_20200229-130536

#138

So, does the TTIG UART log for an uplink show (almost) the same time as the meta data?

(Again, I’d also assume that the TTIG includes that time in its Basic Station uplink message, though I now see that such is actually not too clear from the specification? It might be easy to validate by comparing the UART log to the meta data, if you want to know.)

#139

Any suggestion, how i can see the metadata in realtime?
In TTN console i need to click to open it, so no realtime monitoring possible here.

#140

I’d say simply pick a few random uplinks from the UART log, and manually compare to the time in their meta data in TTN Console?

That’s not realtime, indeed. Also, I don’t know what the TTIG logs for an uplink. And all only matters if you want to know what’s the origin of the time in the TTIG’s meta data. Maybe @KrishnaIyerEaswaran2 can also simply tell you. :wink:

#141

I took two samples, see below. There is a difference of about 9ms between timestamp of uplink in gateway’s log and metadata.

That’s a lot. With the MatchX gateway i get timestamps in metadata that are at most 5ms off from gps/pps synched time.

Sample 1

Server 22:17:59.895805704
Metadata 22:17:59.862910032
Gateway 22:17:59.854

d1 = 33ms
d2 = 9ms

Sample 2

Server 22:19:04.088411484
Metadata 22:19:04.051260948
Gateway 22:19:04.042

d1 = 37ms
d2 = 9ms

d1 = Server ./. Metadata
d2 = Metadata ./. Gateway

#142

Not sure what problem this actually creates for you? If a gateway is equipped with GPS module, you typically can obtain GPS timestamp for a packet. And if there’s no GPS module, you hardly can get a precise enough timestamp.

#143

I am seeing the same behaviour (i.e. pressing reset twice with some delays, or power cycling will restart the TTIG). “Last Seen” field in TTN console never updates though.

I only have one TTIG, but it’s yet to work a single time. It’s not even useful as a paperweight, too light…