Re: [Discuss-gnuradio] uint64_t to PMT in Python

[Lakshay Narula]

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 mismatches? If no, then is this a limitation of using Python for GNU Radio? If yes, do you have any easily accessible SWIG tutorial for GNU Radio in mind? GNU Radio documentation is short on this topic.

Thanks again,

Lakshay.

On Mon, Aug 15, 2016 at 5:25 AM, Marcus Müller <address@hidden> wrote:

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 seconds into a floating number.

There's a couple of workarounds, of which I prefer the following

time_now = usrp_source_0.get_time_now()
frac_seconds = time_now.get_frack_secs()
full_seconds = time_now.to_ticks(1.0) 

Best regards,
Marcus

On 15.08.2016 03:18, Lakshay Narula wrote:

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 Python. I am wondering if this is a limitation of using Python for writing blocks, or is there a way around such data type mismatch issues? (For this particular case, I was able to use uhd.usrp_sink.get_real_secs() and discard the fractional part).

I am guessing there might be something I could change in the SWIG file, but I have not found an answer yet.

Thanks,

Lakshay.

On Sun, Aug 14, 2016 at 2:24 PM, Marcus Müller <address@hidden> wrote:

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 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
> no built-in unsigned integer data types. So I tried using
> numpy.uint64, but the Python function pmt.from_uint64 shows up an
> error saying that the argument must be of type uint64_t.
>
> As a work around, I used long instead of numpy.uint64, and
> subsequently used pmt.from_long to pass the integer seconds. I have
> not tried if it works, but even if it does it is a bit of a hack.
>
> Is there a cleaner way to generate the "tx_time" value tuple in Python?
>
> Thanks,
> Lakshay.
>
>

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


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