Hi,
I'm working on a custom fpga image for the B210 running UHD 3.9.5 (and
associated fpga code).
I'm now faced with a problem that I cannot explain :
-- Initialize CODEC control...
terminate called after throwing an instance of 'uhd::runtime_error'
what(): RuntimeError: [ad9361_device_t] B
Hi Ian,
> Ironically, the thing you described that I think is most likely to break the
> system is exporting those signal to the Mictor to look at them!
Hehe, well, there isn't much test points for me to probe them directly :)
But as you said :
- It wasn't working before
- I also built an im
Hey Steve,
so, how much sampling rate do you need? If this is a local network,
directly using the USRP from Windows might just work. But: An X310 can
generate significantly more data per second than fits through gigabit
ethernet, so this can even theoretically only work if sampling rates
are relat
Hello Keith,
Sorry for the long silence - this problem really needed mulling over
in my head, and then I postponed that...
So, yes, I'd see why you want fine-tuned control over threading.
Would modifying UHD be an option for you? I could imagine the following
to be a viable approach:
1. in zero_
Hi ben,
On Sat, 2018-03-24 at 05:32 +, Benny Alexandar wrote:
> on USRP N210 is 100 MHz / 2 = 50 MHz. Is that correct ?
> Can USRP sample at such high rates ?
Yes. But it's impossible to fit 50 MS/s · 32 b/S through a 1 Gb/s link,
so you need to reduce the sample depth to 8 b, so that a comp
That's a bit of a GNU Radio more than a USRP question, but
nevertheless:
You can't do that with the existing file_source. You'd need to extend
the file_source's C++ or write your own block that does that cycling.
Best regards,
Marcus
On Wed, 2018-03-21 at 17:07 +, Benny Alexandar wrote:
> Hi
You can edit the auto-generated Python code to start a thread that
periodically calls:
file_sink.open(next_file_name, repeat=1)
for example. A tag is added whenever a repeating file restarts, if that
helps at all. There is no way to play a list of non-repeating files with
this block, but yo
Hey Marcus
Thanks for taking a look at this for me. Im a pretty competent computer
engineer so I would be comfortable making modifications to UHD given your
starting point. It may be a couple of weeks before I can look at this
again, but I will try to look into this. I may need to pick your brain
Thanks. That temporarily fixes the addressing issue. However, I am now
seeing the following error. Could you please tell me why this might be
happening?
File "/home/colosseum/Downloads/for_steve_gough.py", line 47, in __init__
self.uhd_usrp_source_0.set_clock_source('external', 1)
File
"/hom
On 05/31/2018 12:50 PM, Steve Gough wrote:
Thanks. That temporarily fixes the addressing issue. However, I am now
seeing the following error. Could you please tell me why this might be
happening?
File "/home/colosseum/Downloads/for_steve_gough.py", line 47, in __init__
self.uhd_usrp_source
On 05/31/2018 01:24 PM, Steve Gough wrote:
Oh, I meant I edited the python from the GRC which you had sent to
print the number of motherboards using UHD's get_num_mboards
(https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#ae4efbbc6480fba44939b34c78d44d7e9),
and it returned 1.
Hi Konstanti,
the most common reason for that is actually a typo in the file name or
in the path; can you verifying the file is actually readable (i.e.
ls -l
/home/rfnoc/rfnoc_tutorial/share/uhd/imagesusrp_e310_fpga_RFNOC_sg3.bit
displays read privileges)?
Best regards,
Marcus
On Thu, 2018-05-3
On 05/31/2018 01:53 PM, Steve Gough wrote:
Thanks for the tip. Tried that as well, and I get the below. Device
address in the GRC parameter is set as : "addr=192.168.10.2
addr=192.168.10.5" (as attached)
File "/home/colosseum/Downloads/for_steve_gough2.py", line 37, in
__init__
chann
Hello all,
The python-api UHD branch has been updated. This was a forced update, so
you'll need to manually reset if you're tracking this branch on git*. There
have been a few improvements since our last announcement, which I'll
quickly go over below.
We'd like to thank everyone who has contribut
Good day,
I plan getting a B210. I can call set_time_now with the UHD interface but
there must be latency involved, between the time I do the call and the time
it is updated. Can I set or reset the time through the GPIO?
My idea is to have a switching network piloted by Arduino or similar. The
co
On 05/31/2018 10:08 PM, RizThon via USRP-users wrote:
Good day,
I plan getting a B210. I can call set_time_now with the UHD interface
but there must be latency involved, between the time I do the call and
the time it is updated. Can I set or reset the time through the GPIO?
My idea is to hav
16 matches
Mail list logo
