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 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 > <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> 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 <tel:15.08.2016%2003>: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 >> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>> 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 >> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> >> >> > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
