Timestamp question

1

In the CSV output, I see the timestamp value comes from here: https://github.com/krakenrf/krakensdr_doa/blob/934398d28eb7ef7986c7d1fe87c72097af2c8435/_signal_processing/krakenSDR_signal_processor.py#L259

self.timestamp = self.module_receiver.iq_header.time_stamp

If I compare the timestamp of the KrakenSDR timestamp when visiting the http://PI4_IP_ADDR:8081/DOA_value.html URL, I notice the timestamps are quite different. What causes such a disparity? I am trying to figure out where the self.module_receiver.iq_header.time_stamp is generated.

Heres an example output when I hit the URL and log a timestamp at the same time:
Timestamp: 1689708941655
KrakenCSV data: 1689705340949

This leaves a difference of: 3600706

Any ideas? I would think the Kraken would be getting the time from the Pi system but I am not entirely sure.

2

Are you comparing the CSV file output from the app?

The iq_header timestamp is generated in heimdall, at the time of acquisition.

3

No, I wasn’t comparing the timestamp value from the CSV. I was polling the DOA_value.html page, and comparing the timestamp of the cURL request to the timestamp of the returned data in position 0. It looks like in the heimdall code there is some logic going into taking out latency or other factors. I was just surprised there was such a gap between the current data on the page and the timestamp of the request that it had me wondering. I would like to ping the webpage data instead of using the CSV data but in reality I just need to get the most recent data when I am querying the KrakenSDR from my custom application.

4

The timestamp in the CSV data will be from the Raspberry Pi’s clock, whereas the cURL timestamp would be from your PC. They won’t be synced, so there could be a major discrepancy there.

5

No I am running this code from the raspberry pi

If I do a cURL from the Pi to the Kraken, take a timestamp at the time of the request and compare it to the response from DOA_value, theres a large discrepancy.

6

The timestamp does come from the Pi system, via Unix time stamps. The time stamp is acquired at the time of data acquisition in rtl_daq.c in heimdall, and there can be maybe 1-2 seconds latency between acquisition and it displaying on the network output.

But your observed difference seems to be too large, not sure what is going on there yet.

7

Ok, thanks Carl. Just wanted to bring it to your attention. It was fairly easy to spot. I created a script to get system timestamp and compared it to the DOA_Value.html timestamp on a loop. I noticed in the rtl_daq.c it looks like its using gettimeofday, there may be more reliable ways to grab the system time besides this function.

8

Can you upload your script? cURL should be returning the same timestamp as gettimeofday + some latency.

Is your script somehow outputting time in a different timezone?

9

Welp, maybe I am just an idiot… after running it again it looks like its much much closer.

This was my script and result:

>>> import requests
response = requests.get(url)

# Get the current timestamp in milliseconds from epoch
timestamp = int(datetime.datetime.now().timestamp() * 1000)

# Store the response and timestamp
data = {
    "timestamp": timestamp,
    "response": response.text
>>> import datetime
>>>
>>> # URL to cURL
>>> url = "http://localhost:8081/DOA_value.html"
>>>
>>> # Make the GET request
>>> response = requests.get(url)
>>>
>>> # Get the current timestamp in milliseconds from epoch
>>> timestamp = int(datetime.datetime.now().timestamp() * 1000)
>>>
>>> # Store the response and timestamp
>>> data = {
...     "timestamp": timestamp,
...     "response": response.text
... }
>>>
>>> print(data)
{'timestamp': 1690464311680, 'response': '1690464310652, 180.0, 2.108546197414398, -65.1626968383789, 416588000, UCA, 436, NOCALL, 0.0, 0.0, 0.0, 0.0, GPS, R, R, R, R, 3.61, 3.56, 3.51, 3.45, 3.40, 3.34, 3.28, 3.21, 3.15, 3.08, 3.01, 2.94, 2.87, 2.80, 2.73, 2.66, 2.58, 2.51, 2.44, 2.36, 2.29, 2.22, 2.15, 2.08, 2.01, 1.94, 1.87, 1.80, 1.74, 1.67, 1.61, 1.55, 1.48, 1.42, 1.37, 1.31, 1.25, 1.20, 1.14, 1.09, 1.04, 0.99, 0.94, 0.90, 0.85, 0.81, 0.76, 0.72, 0.68, 0.64, 0.61, 0.57, 0.53, 0.50, 0.47, 0.44, 0.41, 0.38, 0.35, 0.32, 0.30, 0.27, 0.25, 0.23, 0.21, 0.19, 0.17, 0.15, 0.13, 0.12, 0.10, 0.09, 0.08, 0.06, 0.05, 0.04, 0.03, 0.03, 0.02, 0.01, 0.01, 0.01, 0.00, 0.00, 0.00, 0.00, 0.00, 0.00, 0.01, 0.01, 0.02, 0.03, 0.04, 0.05, 0.06, 0.07, 0.08, 0.10, 0.12, 0.14, 0.16, 0.18, 0.20, 0.22, 0.25, 0.28, 0.31, 0.34, 0.37, 0.41, 0.44, 0.48, 0.52, 0.56, 0.60, 0.65, 0.69, 0.74, 0.79, 0.84, 0.89, 0.94, 0.99, 1.05, 1.11, 1.16, 1.22, 1.28, 1.34, 1.41, 1.47, 1.53, 1.60, 1.66, 1.73, 1.80, 1.86, 1.93, 2.00, 2.07, 2.14, 2.20, 2.27, 2.34, 2.41, 2.48, 2.55, 2.61, 2.68, 2.75, 2.81, 2.88, 2.94, 3.01, 3.07, 3.13, 3.20, 3.26, 3.31, 3.37, 3.43, 3.48, 3.54, 3.59, 3.64, 3.68, 3.73, 3.77, 3.81, 3.85, 3.88, 3.91, 3.94, 3.97, 3.99, 4.01, 4.03, 4.04, 4.05, 4.06, 4.06, 4.06, 4.06, 4.05, 4.04, 4.03, 4.01, 3.99, 3.96, 3.93, 3.90, 3.87, 3.83, 3.79, 3.75, 3.70, 3.65, 3.60, 3.55, 3.50, 3.44, 3.38, 3.32, 3.26, 3.20, 3.14, 3.08, 3.01, 2.95, 2.88, 2.81, 2.75, 2.68, 2.62, 2.55, 2.48, 2.42, 2.35, 2.29, 2.22, 2.16, 2.09, 2.03, 1.97, 1.90, 1.84, 1.78, 1.72, 1.66, 1.60, 1.55, 1.49, 1.43, 1.38, 1.32, 1.27, 1.22, 1.17, 1.12, 1.07, 1.02, 0.97, 0.92, 0.88, 0.83, 0.79, 0.75, 0.71, 0.66, 0.63, 0.59, 0.55, 0.51, 0.48, 0.45, 0.41, 0.38, 0.35, 0.32, 0.30, 0.27, 0.25, 0.22, 0.20, 0.18, 0.16, 0.14, 0.13, 0.11, 0.10, 0.09, 0.08, 0.07, 0.07, 0.06, 0.06, 0.06, 0.06, 0.06, 0.07, 0.07, 0.08, 0.09, 0.11, 0.12, 0.14, 0.16, 0.18, 0.20, 0.23, 0.26, 0.29, 0.32, 0.35, 0.39, 0.43, 0.47, 0.52, 0.56, 0.61, 0.66, 0.72, 0.77, 0.83, 0.89, 0.95, 1.02, 1.08, 1.15, 1.22, 1.29, 1.36, 1.44, 1.52, 1.59, 1.67, 1.75, 1.83, 1.92, 2.00, 2.08, 2.17, 2.25, 2.34, 2.42, 2.51, 2.59, 2.67, 2.76, 2.84, 2.92, 2.99, 3.07, 3.14, 3.21, 3.28, 3.35, 3.41, 3.47, 3.53, 3.58, 3.63, 3.67, 3.71, 3.74, 3.77, 3.79, 3.81, 3.83, 3.83, 3.84, 3.84, 3.83, 3.82, 3.80, 3.78, 3.75, 3.72, 3.69, 3.65 \n'}