You could calculate the fractional offset and store it in the tag.

On Tue, Jun 23, 2020 at 10:35 AM Adam Gorski <[email protected]> wrote:

> Nick, Jeff,
>
>
>
> Thank you for the detailed feedback. I am indeed doing multilateration on
> ADS-B signals, will investigate procuring a GPSDO for accurate timing.
>
>
>
> The way I understand it, once I’m using the GPSDO to acquire an accurate
> timestamp the offset added to each message will still be at a minimum 500ns
> (at 2Msps). Is there anything that can be done to decrease this amount?
>
>
>
> Thanks,
>
>
>
> Adam Gorski
>
> Virginia Tech Applied Research Corporation (VT-ARC)
>
> Wireless Communications Systems Engineer
>
> 410-818-3188
>
>
>
> *From:* Nick Foster <[email protected]>
> *Sent:* Sunday, June 21, 2020 7:01 PM
> *To:* Adam Gorski <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: Modifying Offset Stream Tag
>
>
>
> I think you are misunderstanding what the tag offset represents. The
> timestamp is coming from datetime.datetime.utcnow() in init(), and the tag
> offset added to that is just the offset (samples since the flowgraph
> started) of the burst divided by the sample rate. Because the burst offset
> is in *samples* and not *seconds*, its resolution is limited to
> 1/samp_rate. Thus, at 2Msps, the resolution is limited to 500ns. In any
> case, Gnuradio knows nothing at all about time -- it only knows about
> samples.
>
>
>
> To play Clippy for a bit, it sounds like you're trying to do
> multilateration on ADS-B signals. The approach being used in gr-adsb will
> not work for this. You cannot use the host clock (i.e., datetime) because
> its accuracy is nowhere near what is required (if you're using
> PTP/IEEE-1588 with a local timeserver you'll be closer, but it will still
> be a mess). You need to synchronize the radio to GPS time either using a
> built-in GPSDO, or an external one.
>
>
>
> If the radio is not synchronized to a GPSDO, then instead of one problem
> you will have two: the initial time (since it's CPU time) will be wrong,
> and the time offset will drift over time (since the sample rate of the
> radio will not be synchronized).
>
>
>
> Nick
>
>
>
> On Sun, Jun 21, 2020 at 2:56 PM Adam Gorski <[email protected]>
> wrote:
>
> Hello community,
>
>
>
> I am currently using an out of tree module (gr-adsb) with GNU Radio 3.7
> that captures received ADSB messages. I would like to change the timestamp
> resolution for each message received from microseconds to nanoseconds. The
> timestamp of each message is declared in the demod.py (attached) by adding
> the start time of the block to the offset stream tag (line 111 in
> demod.py).
>
>
>
> The offset stream tag is not declared within the out of tree module, but
> somewhere in the GNU Radio source code. There are a handful of python files
> within the GNU Radio source code that include the offset tag, however I
> believe the declaration may lie in one of the following files (these have
> essentially the same code):
>
>    - ~/gnuradio/gnuradio-runtime/python/gnuradio/gr/packet_utils.py
>    - ~/gnuradio/gr-digital/python/digital/utils/tagged_streams.py
>
>
>
> I would like to declare the offset tag with a nanosecond resolution. I
> have been able to accomplish this type of declaration with the demod block
> start time by calling a c function within a shared library, however I’m
> unsure how to do the same within GNU Radio source code as any sort of test
> print statements within the two files listed above never gets displayed in
> the flowgraph output.
>
>
>
> My questions:
>
>    - Is one (or both) of the files indicated above the correct file to
>    modify?
>    - How do I test modifications to GNU Radio source code files?
>    - Are there other methods of changing the offset tag resolution I
>    should consider?
>
>
>
> The c function and shared library code is as follows. I chose this way due
> to the flowgraph code builder in GNU Radio 3.7 using python2; if I used a
> python3 function I believe I’d have to rewrite the flowgraph code builder
> in python3.
>
>
>
> Time_ns.c:
>
>
>
> #include <stdio.h>
>
> #include <time.h>
>
>
>
> long long time_ns() {
>
>     struct timespec t0;
>
>     clock_gettime(CLOCK_REALTIME, &t0);
>
>     long long ns = (t0.tv_sec * 1000000000) + t0.tv_nsec;
>
>     return ns;
>
> }
>
>
>
> int main()  {
>
>   return 0;
>
> }
>
>
>
> Next use this command to create a shared library:
>
> cc -fPIC -shared -o time_ns.so time_ns.c
>
>
>
> Ns.py:
>
>
>
> from ctypes import *
>
> so_file = '~/time_ns.so'
>
> c_time_ns = CDLL(so_file)
>
> c_time_ns.time_ns.restype = c_longlong
>
> return c_time_ns.time_ns()
>
>
>
> Thanks,
>
>
>
> Adam Gorski
>
> Virginia Tech Applied Research Corporation (VT-ARC)
>
> Wireless Communications Systems Engineer
>
> 410-818-3188
>
>
>
>

Reply via email to