Ok, admittedly I’m not using a high end Ublox NEO-M9N, instead I’m using a cheap and cheerful NEO-6M to provide GPS location and timestamping at my RPi4 gateway.
While there is an intoxicating about of precision in my data, it is not what one could call accurate, certainly as far as location goes.
Is there any configuration option I can use in local_conf.json to use my statically configured reference location and altitude, but also exploit the precise timestamp from the Ublox NEO?
After all, my gateway doesn’t move around, contrary to what GPS is indicating
Also, location imprecision invariably implies time imprecision, since location in GPS is derived from time.
There are possible reasons why knowing time within a few milliseconds but not location could be useful, but trying to understand your precise goals.
Basically what it would come down to is that you could easily modify the packet forwarder source to override some details; but sending “faked” data up to TTN would need careful thought.
It might be helpful if you would tell us how accurate the ‘location’ reported by your Gateway’s GPS actually is, within1m, 10m, 100m, 100km ?
Also realise that whilst the PPS signal produced by the GPS will be synced to GPS time, the time produced by the GPS as in sent out in the NMEA sentences, can be a second or more out in relation to UTC in some circumstances.
I see many posts here & else where about using a GPS on a Pi gateway. Mostly it’s about the fact the GPS isn’t properly configured and once they have figured out how to redirect BlueTooth, /dev/ttyAMA0, /dev/ttyS0 & mini-UART etc etc. And then they find it doesn’t actually do anything. But at least the constant messages in the logs about GPS not found etc go away.
Most Pi based gateways don’t transmit the GPS location to TTN such that TTN uses it. And I’m not sure the gateway actually picks up the time information without some extra help. Whereas it’s quite easy, after Googling the command for the umpteenth time, to turn on the built in NTP client that ships turned off.
It’s not accurate enough for any needed timing; and in terms of time reported to application clients, it’s the time the data hits the server that would be used, for consistency across gateways which won’t have matching ideas of NTP time.
It is true though that GPS doesn’t server much purpose either.
syslog timestamps are applied by the host OS to the messages generated by the packet forwarder
On a remotely modern Linux that tends to mean that they’re intended to be NTP based already.
However, that has the interesting side effect that they’re usually wrong on (re) boot, and then you use a jump in the logs when the network connection comes up and an NTP fix is obtained.
I think there’s one packet forwarder setup floating around that won’t actually start the receiver until it has a network connection.
Yup, this - that’s even if the NTP is on, if not, it picks up from the timestamp from shutdown. Hours of fun trying to decipher logs from clients and get them to line up with the online logs.
Thanks for reminding me to put getting one of the two battery backed RTC solutions on our custom board working on the to-do list. Had completely forgotten about that.
With a properly configured RPi and packet forwarder the uplinks will have slightly better timestamp information. Also the packet forwarder would be able to be used for class B which required GPS time sync. However for TTN both are not particularly useful, the timestamps are still a magnitude to imprecise for any location calculations and TTN doesn’t do class B.
Also, location imprecision invariably implies time imprecision, since location in GPS is derived from time.
GPS was enabled on the RPi gateway purely for my academic interest and to learn a little more and see the impact on the metadata. I had noticed that other gateways were including their position information when one of my nodes reached out to them.
I wasn’t sure if TTN could make use of the more accurate timing data, but it sounds like it is not any particular advantage.
The MQTT data snapshot below shows the point before and after GPS enabled on the gateway.
It’s easy to see the extra decimal places on the “time” field, plus the insertion of latitude, longitude & altitude which was my original goal when incorporating the NEO-6M.
My altitude is bouncing up and down by maybe 10 metres from my reference height, but it can’t really be relied upon anyway because the GPS antenna is currently closer to the RPi than to the LoRa antenna!
The geometry of GPS satellite positions often means that most of the involved satellites are out “to the side” with few truly “overhead” and as a result the distance-from-satellite measurements are fairly well aligned with position on the earth’s surface, but fairly poorly aligned with measuring altitude: imagine the center of a trampoline, where you can bounce up and down without the distance to the side supports changing much. And +/- 10 meters isn’t bad for GPS without a local differential reference in any case.
