Pluto sample timestamp to seconds

[tylersweat]

Hi,

I want to use this timestamping project with the Pluto to get a relative time difference in seconds. I'm done some experimenting and I'm seeing that the sample timestamp increases at a rate of roughly 30.7 Msps. What is the target internal counter frequency that I can use to convert the sample timestamp into seconds?

Additionally, after the first time I receive samples, it looks like the internal counter stops freely incrementing. Instead, the second call to receive samples has a timestamp that is the size of the buffer samples larger than the timestamp after the first batch of samples, regardless of how long it has been between calls for samples. I'm using IIO to interface with the Pluto and receive samples. I process the received data to find the known words to find the timestamp. Why isn't the timestamp incrementing after the first call for samples?

[ofontbach]

Hi @tylersweat,

I am not sure if I get your question right.
By default, the Pluto project will target the lowest possible BW (1.4 MHz), for which the sample timestamp increases at a rate of exactly 1.92 MSPS (which, as you mentioned, is derived from the base 30.72 MSPS used by LTE).

As you've noticed, each DMA packet containing samples has a timestamp which is exactly the previous one incremented by the number of samples requested per packet. This is because the timestamps are meant to count samples (or clock-ticks from the clock used to obtain those samples if you prefer). This is expected. If you don't read the flow of DMA packets with I/Q samples in time you will start noticing gaps in the timestamp values (these gaps will be a number of times the size of the number of samples requested per packet), as the DMA buffers will get full.

With this being said, when using the default 1.92 MSPS, then each group of 1920 samples (that is, contents of the DMA packet after discarding the timestamping headers + known words), you get 1 ms worth of data. So each 1000 packets you'll get 1 second (i.e., 1 second is equal to a distance of 1920000 between timestamps).

I am not sure if you're using the RF IIO driver that we are providing with our solution, but this will handle interfacing with IIO and manage the known words + timestamp parsing.

Cheers,.
Oriol

[tylersweat]

Hi @ofontbach,
Thank you for your reply! I looked at the way I was testing the timestamping with a delay and I was waiting for a set amount of time and then setting the sample rate and immediately asking for samples so I was seeing whatever the default sample rate is. If I set the sample rate first and then wait the set amount of time I'm seeing the timestamp increase at the sample rate.

I see what you're saying the the DMA packet timestamp incremented by the number of samples requested per packet. It looks like new data only enters the DMA buffers once data has been read from the buffer so if I wait a long time between asking for samples, I may be getting samples that are 30 seconds old by that point. Is there a way to set it so that it is constantly refilling the oldest buffer?

[ofontbach]

Hi @tylersweat,

The design is thought for constant sample streaming. I guess the easiest way is to constantly flush the DMA buffers, even if you simply drop the data afterward.