Hi Lakshay,
indeed, you're right, you will need to export some C++ functionality to
python land if you want to expose functionality.
There's no specific SWIG tutorial I can think of, sadly.
Best regards,
Marcus
On 15.08.2016 16:56, Lakshay Narula wrote:
> Hi Marcus,
>
> Thanks, that is a
Hi Marcus,
Thanks, that is a better workaround!
However, I am worried that at some point I will come across a function
which will not have such a Python workaround. So, is there a general way to
handle this? For example, could I program a SWIG file interface to deal
with such data type
Hi Lakshay,
yeah, I figured that was the case here; but you're right,
get_real_secs() is suboptimal, because e.g. setting "wall clock time"
will lead to large values for the "full seconds" part, and that will
lead to reduced accuracy for the fractional part, if you combine the
full and fractional
Hi Marcus,
Yes, from_long() did actually work fine with the hardware.
However, I think I am facing a more general problem with Python binding of
GNU Radio. For example, the uhd.usrp_sink.get_full_secs() function returns
a variable of data type time_t. Once again, this is not recognized in
Hi Lakshay,
haven't tried that in a while; but wouldn't from_long() work?
Best regards,
Marcus
On 12.08.2016 16:26, Lakshay Narula wrote:
> Hello,
>
> I am trying to use the "tx_time" tag in my Python OOT block. The value
> for this tag is a tuple of PMTs: integer seconds in PMT format
Hello,
I am trying to use the "tx_time" tag in my Python OOT block. The value
for this tag is a tuple of PMTs: integer seconds in PMT format derived
from uint64_t, and fractional seconds in PMT format derived from double.
These data type conversions work well in C++. But in Python there are
