Right, I was still thinking you wanted the ns time of the work call for something. Ignore my last answer and go with Nick's!
On Tue, Jun 23, 2020 at 2:18 PM Nick Foster <[email protected]> wrote: > 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 >> >> >> >>
