On 08/27/2020 08:20 AM, Ivan Zahartchuk via USRP-users wrote:
Hi there. My problem is that even after calibration I can clearly see
the mirror channel on my USRP N 210 with SBX. Maybe someone will tell
you how to solve this problem. This problem is observed on several
boards and different boards.
What version of UHD?
How are you running the calibration tools?
Looks like the image suppression is only about 20dB, which I *think* is
poorer than the algorithms can achieve (it has been a while since I looked
at this).
вт, 16 июн. 2020 г. в 17:28, Michael Dickens
<[email protected] <mailto:[email protected]>>:
Hi Ivan - OK; so you got the GRC <-> GR <-> UHD <-> GPIO access to
work? Well done!
As for your next question about tuning times: the E313 is the same
as an E310 in terms of the USRP part. Here's my understanding:
Tuning times if the frequencies do not require changing out a RX
filter should be around 25 ms; jumping between RX filters should
be more like 125 ms; we use a different "RX filter" for each
different frequency range. These are -very- typical tuning times
for the E31x series; actually, this is true for most of our USRPs
except the N3xy series which are intentionally designed with fast
frequency switching in mind (among other attributes).
In theory one could speed up tuning via FPGA code. I'm not an FPGA
programmer, so I don't know how to do this nor the complexity of
doing so -- just that in theory it could be done for specific user
needs.
I hope this is useful! - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: [email protected] <mailto:[email protected]>
Web: https://ettus.com/
On Tue, Jun 16, 2020 at 6:39 AM Ivan Zahartchuk
<[email protected] <mailto:[email protected]>> wrote:
Hello. I nevertheless got to work and equipment and
everything worked out for me. Gpio works. It turns out that in
theory, you can connect to it through dev as well as to the
gps receiver. I have one more question for you. I plan to also
use the E313 as a frequency tunable scanning receiver. But as
far as I was written before (and I was convinced of this
myself) that the frequency tuning is slow due to the
configuration of the filters on the board. Tell me how can I
get around this and speed up the scan. I want to achieve a
speed of at least 1ms at 50 MHz and the frequency tuning
itself in the E310 takes about 100 ms.
пт, 29 мая 2020 г. в 23:28, Michael Dickens
<[email protected] <mailto:[email protected]>>:
Hi Ivan - It was a crazy week for me; I still don't even
have the required software installed; putting out so many
fires I can't count them any longer! I sincerely hope next
week is less stressful, and I can make progress on getting
things installed. Have you made any progress on your end?
Cheers & happy weekend again! - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: [email protected] <mailto:[email protected]>
Web: https://ettus.com/
On Mon, May 25, 2020 at 6:36 PM Ivan Zahartchuk
<[email protected] <mailto:[email protected]>> wrote:
Hello. There are no changes so far. There is no way
to get to the equipment. Waiting for your feedback on
the code. Have a nice weekend))))
вт, 19 мая 2020 г. в 00:19, Michael Dickens
<[email protected]
<mailto:[email protected]>>:
HI Ivan - Happy Monday! I hope you had a good
weekend. I took an extra part day off on both
ends, which made for a lovely elongated time. I'll
take a look at your code shortly; I'm moving
between computers, so I'll need to create the UHD
3.15.0.0 + GR 3.7.14.0 Release + gr-ettus master
installs for testing this. Always a good time
getting a new computer, but it does take time to
set it up reasonably well! Any updates on your
end? - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: [email protected] <mailto:[email protected]>
Web: https://ettus.com/
On Fri, May 15, 2020 at 9:46 AM Ivan Zahartchuk
<[email protected] <mailto:[email protected]>>
wrote:
Thanks for your support. The archive has a
file for USRP E310 and for PC. For now, I'm
just sending a request via gnuradio using the
slider. I just have not figured out
get_gpio_attr but the fact that the values
change there gives me hope that this works.
пт, 15 мая 2020 г. в 00:09, Michael Dickens
<[email protected]
<mailto:[email protected]>>:
That's some positive progress, Ivan! Do
you have any code you can pass on to me to
try? I have a variety of USRPs around that
should be usable with GPIO; doesn't need
to be an E310 specifically (that's what my
notes tell me you're using ... yes?). I
also have both UHD 3.15.0.0 and the
3.15.LTS branch available for testing. - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: [email protected]
<mailto:[email protected]>
Web: https://ettus.com/
On Thu, May 14, 2020 at 3:50 PM Ivan
Zahartchuk <[email protected]
<mailto:[email protected]>> wrote:
Hello. Yes, I have advanced in this direction.
Indeed, I figured out a bit with GPIO. The idea is to initialize usrp_source
earlier than the RFNoC block (I don’t know what this is related to), and then I
avoid the error and in theory I have the same access to gpio. But when calling
the get_gpio_banks command. “FP0” is returned to me and not “INTO”; I have not
yet carried out any further experiments in connection with quarantine.
чт, 14 мая 2020 г. в 22:29, Michael
Dickens <[email protected]
<mailto:[email protected]>>:
Hi Ivan - I'm glad to hear you got
the firmware / FPGA images sorted
out. That's really quite
something! I'll need to do some
playing around with how to do GPIO
in UHD C++. I'm confident there's
a way ... just need the right
"special sauce" if you know what I
mean. Maybe you've made progress
on this end? - MLD
---
Michael Dickens
Ettus Research Technical Support
Email: [email protected]
<mailto:[email protected]>
Web: https://ettus.com/
On Mon, May 11, 2020 at 4:04 PM
Ivan Zahartchuk
<[email protected]
<mailto:[email protected]>> wrote:
If I understand you correctly,
then I need to create another
block uhd
self.uhd_usrp_source =
uhd.usrp_source ( ",".
join (("", "")),
uhd.stream_args (
cpu_format = "fc32",
channels = range (1),
), )
so I created it. But I don’t
understand how it works since
I don’t connect it anywhere
and I get an error
[WARNING] [RFNOC] [legacy
compat] Not enough FIFO ports
to connect, not all TX sinks
will be connected [WARNING]
[RFNOC] [legacy_compat] No
DDCs detected. You will only
be able to receive at the
radio frontend rate. [WARNING]
[RFNOC] [legacy_compat] No
DUCs detected. You will only
be able to transmit at the
radio frontend rate. [WARNING]
[RFNOC] Assuming max packet
size for 0 / Radio_0 thread
[thread-per-block [0]: <block
uhd_rfnoc_FIFO (7)>]:
RuntimeError: On node 0 /
FIFO_0, output port 0 is
already connected.
If somewhere there are
examples of how to get to gpio
correctly, I would be very
grateful if you would provide
them to me. I figured out the
FPGA firmware and now the only
problem is gpio.
пн, 11 мая 2020 г. в 17:58,
Michael Dickens
<[email protected]
<mailto:[email protected]>>:
Hi Ivan - I was out last
week; here now for a few
days. Please keep
[email protected]
<mailto:[email protected]>
on CC so that someone
there can try to help you
when I'm away.
Here's a summary of the
discussion with the Ettus
R&D person I spoke with
about accessing the GPIO
via GRC: you have to
create a UHD USRP
Source/Sink object, then
you use it to access the
underlying C++ USRP object
(via Python) to obtain the
GPIO API. You can't access
the UHD GPIO API from
RFNoC blocks; there is no
USRP object to provide access.
Are you still having
issues with the FPGA
creation? If so, please
update me on where you're
at and I'll do what I can
to help. - MLD
---
Michael Dickens
Ettus Research Technical
Support
Email: [email protected]
<mailto:[email protected]>
Web: https://ettus.com/
On Thu, May 7, 2020 at
7:38 AM Ivan Zahartchuk
<[email protected]
<mailto:[email protected]>>
wrote:
Hello. Sorry to bother
you so often. But I
really want to
understand this board
and firmware. I solved
the problem with the
fact that I did not
create an image for
FPGA. The problem was
that at startup, the
rfnoc_ce_auto_inst_e31x.v
configuration file is
created, which also
tells which blocks to
compile for VIvado.
But the next time you
call
./uhd_image_builder,
this file is not
replaced with a new
one, but the
rfnoc_ce_auto_inst_e310.v
file is created, which
does not participate
in further work. But I
also had questions
about the GPIO.
вс, 3 мая 2020 г. в
14:09, Ivan Zahartchuk
<[email protected]
<mailto:[email protected]>>:
Hello. Your
colleagues haven’t
answered anything
yet? Tell me,
could you generate
firmware for RFNoC
and drop it to me.
Sorry to ask a
lot, I just can
not test the error
with generating a
bit file for FPGA
differently.
ср, 29 апр. 2020
г. в 08:11, Ivan
Zahartchuk
<[email protected]
<mailto:[email protected]>>:
Thanks! I
found out that
the problem in
the firmware
comes from
applications
for creating
this firmware.
After opening
the firmware
using Vivado,
I found in it
the same FIR
block that I
did not add
there. Perhaps
this is due to
the fact that
I installed
the wrong
version of
Vivado.
Because I also
don’t generate
the dts file
that is needed
for firmware.
I installed
Vivado 18.3 HL
System Edition.
ср, 29 апр.
2020 г. в
00:12, Michael
Dickens
<[email protected]
<mailto:[email protected]>>:
Hi Ivan -
Let me
discuss
your query
with the
Ettus R&D
guy who
handles
gr-uhd.
Hopefully
he'll be
able to
clarify
your
query. - MLD
---
Michael
Dickens
Ettus
Research
Technical
Support
Email:
[email protected]
<mailto:[email protected]>
Web:
https://ettus.com/
On Mon,
Apr 27,
2020 at
7:59 PM
Ivan
Zahartchuk
<[email protected]
<mailto:[email protected]>>
wrote:
Unfortunately
for all this time I have not come a step closer to solving my problems. I don’t
know how to solve the problem with flashing fpga.
I even
reinstalled ubuntu but it did not help. The only assumption is that the board
has its own memory that is not erased after overwriting the SD card. But this
is also doubtful.
In addition, I
still didn’t get to switch to the GPIO through the RFNoC block and I am
thinking about returning to version 3.14. But honestly I would like to deal
with this version.
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
