discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Transmission time control from python level


From: Nazmul Islam
Subject: Re: [Discuss-gnuradio] Transmission time control from python level
Date: Fri, 27 Jul 2012 16:37:31 -0400

Thanks a lot, Josh. I tried to use the time_spec_t class in the GRC generated python code through the following way:


class TimeFind(grc_wxgui.top_block_gui):
  .............................
self.time_spec_t = uhd.time_spec_t(0)
.................................

if __name__ == '__main__':
................................
tb = TimeFind()
var = 1
tb.start()
while var == 1:
            sleep(0.1)
            print "current fractional time :" , tb.time_spec_t.get_frac_secs()
            print "System time: " , tb.time_spec_t.get_system_time()
            print "full sec: " , tb.time_spec_t.get_full_secs()
            print "real second: " , tb.time_spec_t.get_real_secs()
tb.stop()

********************************

Basically, My code produces the following output:

current fractional time : 0.0
System time:  <gnuradio.uhd.uhd_swig.time_spec_t; proxy of <Swig Object of type 'uhd::time_spec_t *' at 0x34fbe10> >
full sec:  <Swig Object of type 'time_t *' at 0x34fbe10>swig/python detected a memory leak of type 'time_t *', no destructor found.

real second:  0.0


Unfortunately, this same output is displayed repeatedly. I am not sure why the time does not change. Is there any other command that will keep printing/pulling the recent time after 10 ms (1 ms)?


Thanks,

Nazmul


On Fri, Jul 27, 2012 at 2:07 PM, Josh Blum <address@hidden> wrote:


On 07/27/2012 10:24 AM, Nazmul Islam wrote:
> Sorry for the previous email. I mistakenly hit the sent button before
> completing the mail. Here is the complete mail:
>
> Is it possible to see the time through USRP GPSDO with
> microsecond/millisecond granularity? I want to synchronize the timing of my
> computers and run gnuradio codes based on the synchronized timing.
>

When synchronized to a common clock reference and time, a group of USRPs
can perform actions simultaneously with accuracy down the the jitter of
GPSDO ref clock + clock synthesizer chain.

> For example, if I have ethernet based internet connection, I can use ntp
> servers to synchronize the computers and read the time (using
> "time.time()") with milisecond granularity. I am trying attain the same
> thing using GPSDO. I am using the following python code.
>

the "magic" of the GPSDO and time synchronization is that there is a
shared "pulse" aka PPS. This pulse is used to latch a time value into
the FPGA at a very specific moment. From that point on, a group of usrps
share the same concept of time.


> ****
>
> class TimeFind :
>
> .........
>     self.uhd_usrp_source_0 = uhd.usrp_source(
>             device_addr="",
>             stream_args=uhd.stream_args(
>                 cpu_format="fc32",
>                 args="peak=0.5",
>                 channels=range(1),
>             ),
>         )
>
> ...........................
> ..............................
>
> if __name__ == '__main__':
>
> tb = TimeFind()
>
> print "current time :" , tb.uhd_usrp_source_0.get_time_now()
> print "last pps time :" , tb.uhd_usrp_source_0.get_time_last_pps()
> print "GPS Time: " ,
> tb.uhd_usrp_source_0.get_mboard_sensor("gps_time").to_int()
> tb.Run(True)
>
> *************
>
> I have the following issues:
>
> 1. The current time and last pps time show the following output:
>
> current time : <gnuradio.uhd.uhd_swig.time_spec_t; proxy of <Swig Object of
> type 'uhd::time_spec_t *' at 0x331fcf0> >
> last pps time : <gnuradio.uhd.uhd_swig.time_spec_t; proxy of <Swig Object
> of type 'uhd::time_spec_t *' at 0x331fcf0> >
>
> How can I get the time value?
see member functions:
http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1time__spec__t.html
>
> 2. "GPS Time: " shows the time with 1 second granularity. Can I get higher
> resolution that 1 second? Is there an option that allows to see the exact
> time instead of the integer time?
>

GPS time in seconds is actually a blocking call that waits until the
seconds increments to return you the time. That way you know very
precisely that the next pulse will be time_read + 1 seconds.

-josh

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



--
Muhammad Nazmul Islam

Graduate Student
Electrical & Computer Engineering
Wireless Information & Networking Laboratory
Rutgers, USA.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]