Yes -- use a faster sample rate. At some point (10-20Msps in my experience) you will run into diminishing returns due to both the finite bandwidth of the transmitted signal and its received SNR (due to the CRLB).
Nick On Tue, Jun 23, 2020 at 7:11 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 > > > >
