Re: Pail of Milky Way Horn Radio Telescope

[Glen Langston]

Dear Gisle,

Thanks for your careful look at our GnuRadio code.

I’ve see, based on looking at your Github code, that you
outrank me in coding skill.

Concerning the time tag accuracy, we’re working on my “Key
Science” project; Detecting radio flashes from cosmic rays
striking the earths atmosphere.   We are getting times 
at 4 different telescopes with roughly 0.5 second accuracy,
which is not as good as we’d like.

This may be due to the different positions of the events in the circular 
gnuradio buffers for each block.    I know I should do these timing tests
in a more controlled manner, using GPS based flashes, but have not
done a complete test yet.

The two figures show
1) The time series samples of the single 4-telescope detected event from 
yesterday 23May04
The telescope numbers are 3,5,7 and 9. For each event, the tag is HH MM 
SS_milliseconds
The RA and Declination along with the Galactic Longitude and Latitude are also 
in the plot legend.  This is a galactic plane event (Latitude = 0.4 degrees)

2) A plot of the number of events (radio flashes) detected in 24 hours (UTC 23 
May 04)
With event counts in 10 minutes blocks stacked on top of the other, so showing 
that events
are seen by multiple telescopes roughly at the same time, but not always.  The 
telescopes are in a Y shaped pattern separated by about 50 meters. (# 5 in the 
middle with an AIRSPY mini)
and the other 3 using SDRPlay RSP1A.  

The mini has 6 MHz samples while the others have 8 MHz samples.  Each telescope 
collects the same number of samples so the 6MHz samples is a longer time range.

This is a long, and not specific answer to your question, which is pretty much 
any
NTP based time tag would be good to capture.   If I could get to 0.001 second 
accuracy
that would be great.   I think there are more issues with GnuRadio buffers than 
with
getting the computer time.

Best regards

Glen

> On May 4, 2023, at 6:17 AM, Gisle Vanem <gvanem@yahoo.no> wrote:
> 
> Hello Glen!
> 
> Glen Langston wrote:
> 
>> My understanding is that it is possible to run the code on Windows,
>> but I’ve not yet done that.   I might give that a try, but it will
>> take me a while to get a Windows computer and start the installation
>> process.
>> The DSPIRA teachers do use windows, but I think they also need to use linux 
>> for
>> some of the data reduction.
> 
> Supporting Windows seems trivial if the only issue is the use
> of 'clock_gettime()' etc. I've been experimenting with the use
> of '<gnuradio/hires_timer.h>' instead. But I'm not sure which
> your timestamps you're after.
> 
> Is an absolute wall-clock with 100 nsec resolution enough?
> If so, Win-8 has the 'GetSystemTimeAsFileTime()'.
> 
> But I've no way to test this since I've have no suitable
> hardware. But some raw IQ-file would perhaps be helpful.
> Do you have any test-program to suite that?
> 
> This is my initial diff:
> 
> --- a/lib/detect_impl.cc 2023-05-03 10:35:47
> +++ b/lib/detect_impl.cc 2023-05-03 11:54:59
> @@ -35,6 +35,7 @@
>  #endif
> 
>  #include <gnuradio/io_signature.h>
> +#include <gnuradio/high_res_timer.h>
>  #include <stdio.h>
>  #include <time.h>
>  #include "detect_impl.h"
> @@ -43,6 +44,18 @@
> 
>  #define EPSILON 0.03    // define small value for waiting for data
> 
> +static inline long get_time_now (struct timespec *ts, time_t *now)
> +{
> +  *now = time(NULL);
> +#ifdef _WIN32
> +  ts->tv_nsec = gr::high_res_timer_now() % (gr::high_res_timer_tps() / 
> 1000000000);
> +  ts->tv_sec = *now;
> +  return (0);
> +#else
> +  return clock_gettime(CLOCK_REALTIME, ts);
> +#endif
> +}
> +
>  namespace gr {
>    namespace radio_astro {
> 
> @@ -125,10 +138,11 @@
>      // get_utc() returns the time of day of cpu clock in utc fractions of a 
> day
>      {
>        double utc = 0, seconds = 0, dtd = 0.;
> -      struct timespec ts;
> -      long r = clock_gettime(CLOCK_REALTIME, &ts);
>        char buff[100];
> -      time_t now = time(NULL);
> +      struct timespec ts;
> +      time_t now;
> +
> +      get_time_now(&ts, &now);
>        struct tm *ptm = gmtime(&now);
> 
>        strftime(buff, sizeof buff, "%D %T", gmtime(&ts.tv_sec));
> @@ -145,10 +159,12 @@
>      detect_impl::get_mjd( )
>      {
>        double mjd = 0, seconds = 0, dtd = 0.;
> -      struct timespec ts;
> -      long r = clock_gettime(CLOCK_REALTIME, &ts);
>        char buff[100];
> -      time_t now = time(NULL);
> +      struct timespec ts;
> +      time_t now;
> +
> +      get_time_now(&ts, &now);
> +
>        struct tm *ptm = gmtime(&now);
> 
>        long year = ptm->tm_year + 1900;
> @@ -189,10 +205,12 @@
>      // passes the cpu clock utc (fraction of a day) back as an pointer
>      {
>        double seconds = 0, utc = 0., mjd = 0.;
> -      struct timespec ts;
> -      long r = clock_gettime(CLOCK_REALTIME, &ts);
>        char buff[100];
> -      time_t now = time(NULL);
> +      struct timespec ts;
> +      time_t now;
> +
> +      get_time_now(&ts, &now);
> +
>        struct tm *ptm = gmtime(&now);
> 
>        long year = ptm->tm_year + 1900;
> 
> -------------------
> 
> And playing with e.g. 'vectordemo.py' gives me this nice attached
> Qt-dialogue.
> 
> But things crashes at exit due to an illegal 'free()' inside Python3.
> Running with 'PYTHONVERBOSE' shows the crash right after
> '# destroy _csv'. Some module you use?
> 
> 
> -- 
> --gv
>