Hi Martin,
Thanks for your suggestions. I have been playing with the script, and just made
a progress. One of the issues in my previous script was that the pulse shaped
samples which are stored in a numpy array has a data type (i.e. dtype) of
np.complex128 which was supposed to be np.complex64.
Hi Tim,
thanks for submitting the bug report as well as sending this email. Makes
it easier for us to track things.
Out of curiosity, have you tried setting the last line (for the ATR_XX
attribute) to HIGH as well? If you're only doing TX, then it shouldn't
matter but it's just another data point
Just as a side note, when you run recv() and send() from different Python
threads, the underlying C++ code that gets into will release the Python
GIL, which allows for true concurrency even with thread vs. multiprocessing.
--M
On Thu, Dec 12, 2024 at 1:51 PM Pedro Vieira wrote:
> Hi Tim, What e
Hi Tim, What equipment are you using? What is the interface? As an initial
suggestion, try using multiprocessing, so that the two codes can be
executed on different cores simultaneously, because when using threads, the
execution of the codes, in Python, is not simultaneous. The following link
expla
Hi Tim,
The recv() call will return if an EOB is detected, or there's a jump in
timestamps. In other words, using recv(), the only option you have is to
receive bursts one-by-one. As you've probably noticed, you can only return
one metadata object per receive call (hence the discontinuity; the rec
Tom,
some pointers:
- I recommend using timed streaming for both Tx and Rx. You will get a more
deterministic time offset.
- I think you're not accounting for phase offsets as well as time offsets.
Your two signals do look similar -- maybe plot the envelope instead of the
real part. Also, you can
tallation of UHD. Could
you please help us here? Thank you.
With regards
Saurav Roy
*From:* White, Joshua J
*Sent:* Friday, July 29, 2022 7:13 PM
*To:* Saurav Roy ; usrp-users@lists.ettus.com
*Subject:* RE: [USRP-users] Re
Dear Saurav Roy,
On 2022-07-29 14:26 +, Saurav Roy via USRP-users wrote:
> However, I am stuck at binary installation in Windows.
The binary executable does not seem to provide the Python API.
I think you will have to compile the UHD library
with the python binding enabled on Windows yourself
use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please notify the sender and destroy all copies and the original
> message.
>
>
>
> From: Saurav Roy via USRP-users
> Sent: Thursday, July 28, 2022 9:25 AM
> To: usrp-users@lists
ly 29, 2022 7:13 PM
To: Saurav Roy ; usrp-users@lists.ettus.com
Subject: RE: [USRP-users] Re: UHD Python API on windows
External Email
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
w. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please notify the sender and destroy all copies and the
original message.
From: Saurav Roy via USRP-users
Sent: Thursday, July 28, 2022 9:25 AM
To: usrp-users@lists.ettus.com
Subject
Dear sir/madam,
we are trying to install UHD and python API for B210 in windows 11. We are
following binary installation for UHD. But after this, we do not know how to
proceed to create the python API. On this page,
https://files.ettus.com/manual/page_python.html instructions are related to
'
12 matches
Mail list logo
