SX1301 timestamp using PPS

I have a gateway consisting of an iC880A with a Raspberry Pi 4. I connected an Ublox Neo-7M GPS module to it for location and timestamping. You may see where this is going.

According to the datasheet the SX1301 can timestamp received packages using PPS. I assume by this they are referring to the internal counter being converted to UTC timestamp. using PPS The internal timestamp is in microseconds, so the timestamp is in microseconds too.

The SX1301 has a 32 MHz clock. Does that not mean that it sould be able to give a counter with 1/32M = 31.25 ns accuracy? Is it possible to get a more accurate timestamp and convert it to a UTC timestamp with that same accuracy (provided that the PPS pulse is accurate enough of course)?

I believe the PPS is used to keep the internal clock in-sync rather than to give you a better resolution.

If you are hoping for ns resolution so you can calculate time of flight for geo-location, you need a board that has the Semtech additional support that runs additional algorithms in an additional chip to figure out what the received time actually was.

Thanks for your quick response.

Should I not be able to at least get a counter with a 31.25 ns accuracy then? (which can then be synced with PPS). Or at lest in theory. I can imagine that there are some factors that worsen the accuracy but even 100ns or something would be acceptable.

People have hacked around with the code in lora_gateway code:

I gather that the varying processing timings make ns timestamps pointless unless you have the top end server.

What are you hoping to achieve with the ns timestamps?

I need it for measuring distance. It doesn’t have to be very accurate for my application but the microsecond inaccuracy is just not ideal.

I have read that thread. They refer to the high performance gateways as well but from my understanding the whole point of those was that they can run without GPS (might not remember that correctly) and that they are way more accurate and can achieve actual nanoseconds accuracy (so better than 31ns) which I don’t need.

Also in that thread someone also mentioned the fact that the time accuracy for the SX1301 is 32MHz and the register cuts off at a microsecond but no one responded to it and the thread got closed. I just feel like there is no clear yes or no answer anywhere.

I cannot see how you can make any meaningfull measurement of distance unless you know the time difference of arrival of a packet at different gateways to a very high accuracy and resolution.

Without a GPS (and thus PPS) how could you syncronise the gateways so that they are within less than 100nS of each other ?

Remember in 1uS a radio wave travels around 300m.

Atomic clocks are not that cheap …

I do have GPS/PPS. Syncing is not the problem. The counter just only shows microseconds.

Then tell us, why would you want to know whethere a packet arrived at your one gateway at 1.0000001 seconds or it was 1.0000002 seconds ?

(100ns difference)

I don’t have one gateway I have two and I need to know the general distance to both, the location doesn’t matter at the moment. It’s not-quite-TDoA (but could be expanded in the future which should be easy if I solve this problem). 100ns isn’t a hard cutoff it was just an example. I need “as good as possible” for now and I really hope that isn’t 1us.

Does it make a difference for the question?

Semtech using their nanosecond technology calculated they need data from at least 4 gateways to have a reasonable chance of calculating a location due to reflections and multipath interference.

If you look at the code of the packet forwarder there should be additional precision when a GPS is connected. However if you search this forum you will find older threads on the subject that concluded things were not working as expected.
I don’t recall if the backend reduced the precision or if the packet forwarder was to ‘blame’.

Makes a very big difference, I was responding to this comment you made;

They refer to the high performance gateways as well but from my understanding the whole point of those was that they can run without GPS (might not remember that correctly) and that they are way more accurate and can achieve actual nanoseconds accuracy (so better than 31ns) which I don’t need.

Now, what would be the point of a high degree of resolution, without a GPS and PPS or an atomic clock to make sense of it all by syncing it all up ?

Two gateways are of little to zero value here, how would you know if the packet arrived from 2kms in one direction or 2km in the other, i.e a 4km error ?

You can’t, but that’s fine because I don’t need the location I just need the distance.

As for the high performance gateway. Yeah I assume they do use GPS to sync I remembered it wrong and worded it badly. They just have more accurate timestamps to the point where PPS actually adds uncertainty because it’s less precise. But I don’t have one of those gateways so that’s not an option for me.

So your back to the sync issue, and here, to do what you want, the node (that you want to know the distance of) now needs to be synched and have some mechanism of defining to the gateway the precise point, to a few nS, at which transmission started. If you dont know when the transmission started then when it arrives is irrelavent.

Now if as @kersing suggested you have more than two gateways, then you could start thinking about measuring distance.

Just spend a half hour with the code tracing how a register read of the internal counter when the PPS pulse is marked gets through the LoRa HAL and into the packet forwarder. It’s either microsecond from the hardware, or divided there in the software, and won’t take you long to find out which.

If whatever is available there isn’t useful to you, then you’ll have to log at the whole encrypted but maybe not really fine timestamps thing…