DOA_values.html and Raspberry system time discrepancy

Hello. I have written a small script to pre-process data from the DOA_value.html (for Kraken remote control and data caching) and noticed a strange behaviour after the new image release. It seems that previously, the timestamps in the DOA records in the CSV file were taken from the Linux system on a Raspberry. Now, it is extracted (correct me if I am wrong) from the KrakenSDR directly, which seems to be in the UTC format. Becase of that, there is a noticeable timestamp discrepancy between Raspberry system time (timestamps) and KrakenSDR+DOA_values.html timestamps. I need correct timestamps (i.e. similar to the system datetime) in the DOA_values for filtering out the old data from my cache.

Is this a bug? Or a feature (like from now on, all the timestamps in the DOA_values will be in the UTC format)?

Hm this was a change from a third party pull request, I didn’t think it would affect anything.

But I don’t fully understand what problem you are having with the new timestamp format? Do you mean that you have a bunch of log files that you are trying to sort through?

@krakenrf_carl I am parsing DOA_values.html every ~100 ms, extracting the current DOA and frequency, and caching it I’m my script that is running as a service on Raspberry:
{ ts: 1686912390, doa: 121, confidence: 4.1 },
{ ts: 1686912490, doa: 122, confidence: 4.3 },
My script also has an endpoint GET /cache?time_threshold=X, that returns this data as JSON payload for further processing. The records I respond with are filtered by the delta now() - ts < X, i.e. I filter out DOA records older than X ms. Also, I was relying on those timestamps to merge DOA records from multiple scanners to triangulate the source by picking the records that are the closest in terms of time. Now, I can not rely on the timestamps in the DOA_values.html because that PR made them more or less useless - the time discrepancy between the timestamps and the current time on the Raspberry is enormous (0-24 hours depending on your timezone). It is better to remove those timestamps from the DOA_values.html completely so as not to confuse anyone, or to fix the issue by setting the time in the self.module_receiver correctly

P.S. I’d expect timestamps in the DOA_values.html output to be similar to the OS date and time. For instance, if I watch some program’s logs, I expect record timestamps to be aligned with the system time, not UTC

“The definition of UNIX timestamp is time zone independent. The UNIX timestamp is the number of seconds (or milliseconds) elapsed since an absolute point in time, midnight of Jan 1 1970 in UTC time. (UTC is Greenwich Mean Time without Daylight Savings time adjustments.) Regardless of your time zone, the UNIX timestamp represents a moment that is the same everywhere. Of course you can convert back and forth to a local time zone representation (time 1397484936 is such-and-such local time in New York, or some other local time in Djakarta) if you want.”

This is an awesome thing to know, but now those timestamps in DOA_values are useless since they are far behind the system time.

@dubrsl Could you please write a sample code that reads a line from the DOA_values and checks if the record timestamp is older than 5 seconds? Because now I can not do it properly. Also, could you please explain what particular problem has been solved with those timestamp changes? Thank you

@DrunkP you are right. DOA_value.html has the wrong timesteps.
PR: Fix wrong timestamps conversion by godsic · Pull Request #82 · krakenrf/krakensdr_doa · GitHub
Thank you for report!

Merged the fix, I’ll update the Pi4 image file within the week.