Hi,
>
> num_recv_frames=128
>
> In the device arguments, or left it at the default?
I've always been curious why UHD doesn't automatically set those
parameters depending on the sample rate ... because AFAICT the
defaults universally sucks for high sample rate and changing them is
always the first
Hi Martin,
Thanks for the fast reply, makes sense.
Because the file I was looking at was time64_core_200.cpp , with a 200
in its name, I thought that was specifically for the b200.
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.
Hi,
In UHD you find :
void set_time_next_pps(const uhd::time_spec_t &time){
const uint64_t ticks = time.to_ticks(_tick_rate);
_iface->poke32(REG_TIME64_TICKS_LO, uint32_t(ticks >> 0));
_iface->poke32(REG_TIME64_IMM, FLAG_TIME64_LATCH_NEXT_PPS);
_iface->poke32(R
Hi,
MMm, I thought there was an "all in one" mode where fosphor had built
in optimized windows / fft / re-order blocks to greatly reduce
resource usage, but looking back at the logs it seems this was never
merged into mainline :/
Cheers,
Sylvain
_
Hi,
> I wonder if there is an operation mode where TX and RX use the SAME LO, or
> some trick to achieve this. Probably not?
The AD9361 itself allows for external LO injection ( RX_EXT_LO_IN ,
TX_EXT_LO_IN ), but that's not broken out in anyway on a B2xx.
You'd need serious rework skill to get t
Hi
> When I plug in the B205 and go to run it for the first time, it takes a
> minute or more to download the stock fpga image to the unit. From that point
> forward, each subsequent run it doesn't have to download the FPGA image. But
> when I disconnect it from USB and re-connect, it must be
On Wed, Jun 5, 2019 at 4:41 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> OK, thanks everyone. I guess I have some superhet reading up to do 🙂.
>
In a nutshell, it's _always_ using LO offset :)
The RF path always brings the signal to some IF (150 MHz IIRC), then the
D
> Any ideas why? Thank you.
This might just be the limited precision of fixed point math used on the FPGA.
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> This task should be performed in B210 (I guess, ethernet MAC is drived
> by FPGA in here).
The B210 is a USB3 device ... there is no ethernet anywhere in there.
> So, how can i start to this task ? Where can i find an
> example or some information to drive built-in ethernet MAC in FPGA ? It
> w
Hi,
Yes, it's connected to the PS and not the PL.
_However_ ... you could just remove the ethernet driver from the linux
side, then drive the built-in ethernet mac from the FPGA by just
acting as an AXI master.
None of this is trivial however ...
Cheers,
Sylvain
__
Hi,
Does anyone here have any tips to reduce the power of a B210 (both
when running and also when idle).
Deconfiguring the FPGA and FX2 when it does nothing does save a whole
lot of power but it takes a significant amount of time to go back to
running mode unfortunately.
Also seems the radio cloc
Hi Piotr,
The main issue is that the AUX DAC output swing is between 0.5v and 1V
(i.e. VDD_GPO-0.3v).
That's not the right range at all to control the VCXO meaningfully.
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http:
Hi,
integer-N tuning maybe ?
And use the DDC/DUC for the rest ?
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> but I think for general usage the block will need to be updated to handle
> them properly.
Just my 2ct, but I think RFNoC globally would benefit from a way to
handle larger vector size split across packets.Even in some limited
form, like for instance some config register that would say that
pac
Just throwing it out there, but have you looked at rfnoc-fosphor ?
I mean capturing and processing large bandwidth spectrum and
decimating it to low bandwidth data is kind of exactly what it does.
Cheers,
Sylvain
On Tue, Feb 19, 2019 at 4:19 PM Jonathon Pendlum via USRP-users
wrote:
>
> Hi
> No dice, same ver 35 and 36 mismatch error.
When looking at the commit you mention (
6af6ac32c30d2dc0efa6eab61e4a3920649e3e62 ), the expected compat number
is 35 :
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_fw_common.h#L26
Looking at the latest FPGA sources on the
Hi,
> As a backup, since the B210 has 2 RX chains, I can do my application with RX1
> and record GPS L1 signals on RX2, then post-process the GPS data to solve for
> clock offset.
It has 2 RX chains with a single LO, you need to receive the _same_
frequency. (at least within the same RF bandwid
Hi,
> Well if the phase difference is constant then i can manage it, but if it is
> random then I have a problem?
>
> There is high residual mutual phase-noise between B205s in this scenario.
> So, not useful for applications that require
> phase-coherence.
If you're ok with a bit of solder
Hi Michael,
> Thank you for letting us know. That is quite a jump in utilization. We will
> take a look when we have some time.
>
> We did recently make recent bug fixes in axi_packet_gate. It looks like
> that, and possibly other changes, inadvertently increased resource
> utilization more
If I read the block diagram correctly, the N310 also has 2G of DRAM
allocated to the fabric. So with RFNoC you could write a block where
you "slowly" load samples to the PL DRAM (from the embeded PS using
microsd for instance), then play them in a loop from the PL DRAM.
Cheers,
Sylvain
_
And the culprit is axi_packet_gate
It actually uses so much more BRAMs than the MAP process replaces some
of the inferred BRAM by inferred dist ram instead to fit everything in
a B200.
Not sure why this now needs some much more resources than it did before.
Cheers,
Sylvain
Hi,
Before I spend possibly hours tracing this, I was wondering if someone
had an obvious reason for which the FPGA base design size for the B200
increases significantly between 3.9 and 3.13 ?
Just a few examples :
Number used as Memory: 4004 out of 1107236%
Number used as Mem
Hi,
I didn't see the screenshots (not posted to the list ?)
But if absolute precision of the clock doesn't matter, you might be better
off disabling the servo loop once it's "close enough". That will require
fpga modifications to expose the refpll control though.
Actually I think this would be a
Yeah the FPGA and even the FX3 are fully loaded from the host. There is
nothing permanent written on the B2xx devices, so worst case you unplug /
replug and it will reprogram everything starting from the FX3 ROM loader
which you can't possible overwrite.
As for FPGA mods, as long as you don't chan
Hi,
> Brian, I really only want to send data when appropriate. I don't have the
> code in front if me at the moment, but I can have tvalid high while I wait
> for tready, right.
Actually tvalid high with tready low is completey expected. Because
you CANNOT have tvalid depend on the status of tr
Hi,
> Just for curiosity:
> The .bit-file is exactly the same as the .bin-file, except that the
> .bit-file has an additional header, right? In my case (Vivado 2017.04),
> the header of the .bit-file is 124 Bytes while the uhd_image_loader
> assumes a header size of 116 Bytes. Depends this header
> ~/workarea-rfnoc/uhd/fpga-src/usrp3/top/x300/build/usrp_x310_fpga_RFNOC_HG.bit
You need to use the .bin and not the .bit file.
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-us
Hi,
I don't think you can transmit a 1ms long packet every 1ms with SOB/EOB.
If the packets are contiguous, you must not set EOB. Because this
stops the internal logic in the FPGA and it can't resume _instantly_,
it needs a small gap. So if you transmit packets of 1ms every 1ms ...
from the radio
Hi,
> The E310's ethernet connection is directly linked to the ARM side of the
> processor so it is not possible to directly stream samples to the host.
I wouldn't say "impossible".
I mean, yes the EMAC is on the PS side, but I don't see why you
couldn't write specialized software that would us
This is the connector :
https://www.digikey.com/product-detail/en/te-connectivity-amp-connectors/1-1734261-2/A98759CT-ND/1855540
Cheers,
Sylvain
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-us
Hi,
> So the question is: Is it possible to modify something ins the firmware in
> order to establish only USB 3.0 connections?
The problem is that there is no firmware when you first plug it :)
It relies on the FX3 boot rom to download the code into USB and this
USB boot mode only supports USB 2
Hi List,
Small update: Problem "resolved". In quote marks because though I have
a version that works consistently, I still have no idea why the
previous version didn't work and through what mechanism this was
causing the ADI to fail ...
A bit more detail:
The custom logic is essentially a sort
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
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,
I was wondering why the B200 didn't support the "user registers" ?
I'm using 3.9.5 here, but upon checking newer UHD I didn't see that
support either in the git master.
I found several posts in the past dealing with this including that
internal support existed and was going through Q/A but th
Or actually it might just be that the usrp_dev->get_rx_bandwidth()
call doesn't return what's really programmed.
Looking at _setup_rates, the var _baseband_bw is setup there.
In case (1) I have rate=N and divfactor=32 (as I mentionned in the
first mail, I force FIR 4x interp here) and _baseband_b
Hi,
> That’s strange, by default the analog filters should be being configured from
> the master_clock_rate to have optimal bandwidth for the master_clock_rate on
> the assumption your signal uses the bulk of that bandwidth.
That's what I would have thought. Maybe I'm just probing it too early
Hi,
I'm comparing two cases that, in theory (at least in my understanding
of things), should yield the same result but don't :)
1) I'm sending data to the USRP at sample_rate N with
master_clock_rate N and the ADI has FIR 4x, HB 2x,2x,2x
2) I'm sending data to the USRP at sample_rate N with
mast
Hi Ian,
> Are you working on an old UHD version?
Yeah, sorry forgot that. App that I use is designed for UHD 3.9 so I'm
using the latest from that branch and it seems that this commit never
made it to 3.9 branch despite it not being very new :p
Do you see any reason that cherry picking it would
Hi,
It seems that the minimum master_clock_rate for the B200 is fixed to 5
MHz in UHD :
static uhd::meta_range_t get_clock_rate_range(void)
{
//return uhd::meta_range_t(220e3, 61.44e6);
return uhd::meta_range_t(5e6,
ad9361_device_t::AD9361_MAX_CLOCK_RATE); //5 MHz DCM low
>> I will be using a Raspberry Pi 3B+ (gigabit Ethernet), GNUradio, and
>> am wondering if anyone has used/tried network attached USB hubs to
>> use a USB3 device with a computer that only has USB2 ports?
Huh ... the Gigabit ethernet on the RPi is a USB 2.0 attached network
controller.
So you wou
Hi Piotr,
And do you set both the Clock and Time source to the external ones
when using it in that configuration ?
I just had a look at both the schematic and VHDL and there is actual
switches ... the GPSDO 10M and PPS should basically be completely
disconnected when the reference for time and c
Personally I'm using a patched UHD where I expose the SPI device :
diff --git a/host/lib/usrp/b200/b200_impl.cpp b/host/lib/usrp/b200/b200_impl.cpp
index a513e1336..01c1e3b51 100644
--- a/host/lib/usrp/b200/b200_impl.cpp
+++ b/host/lib/usrp/b200/b200_impl.cpp
@@ -549,6 +549,8 @@ b200_impl::b200_i
43 matches
Mail list logo
