Dear Karan,
could you share the verbatim output of uhd_usrp_probe (including the
very first line)?
Best regards,
Marcus
On 07/11/2017 09:00 PM, Karan Suri via USRP-users wrote:
> Hi
> I recently got two UBX160 daughter boards to work in the ISM band of
> 5.8 GHz. I am not able to detect these
About ESD protection, in my B210 the first switch U807 dies all the time; these
need some protection, too :) At the moment I have removed them...
Ralph.
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
Marcus Müller via USRP-users
Sent: Sunday, July 9, 2017 10:56
Thanks for reply.
--
Usman
On Sat, Jul 8, 2017 at 8:25 PM, Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Dear Usman,
>
> pretty much anywhere. There's nothing special about these cables, and they
> are specified in the datasheet on the N2xx GPSDO product page on our
> websi
Hello Derek and Martin.
Thank you for your answers.
I need to have DDC and to propagate to the computer 4 complex flow.
I've read design code for X310 and I wish to know if it's possible for
someone, without a big knowledge about this design (and globally USRP's
design), to add this option (and
Hello Derek and Martin.
Thank you for your answers.
I need to have DDC and to propagate to the computer 4 complex flow.
I've read design code for X310 and I wish to know if it's possible for
someone, without a big knowledge about this design (and globally USRP's
design), to add this option (and
I agree. When a B2XX has died for me, it's always this.
On Wed, Jul 12, 2017 at 4:04 AM Ralph A. Schmid, dk5ras via USRP-users <
usrp-users@lists.ettus.com> wrote:
> About ESD protection, in my B210 the first switch U807 dies all the time;
> these need some protection, too :) At the moment I have
Hi hope this is the the right place to ask.
I attempted an ip address change using the NI USRP utility tool and when
changed the n210 fpga stopped being recognised by the computer.
I am able to boot it in safe mode and the computer can contact the device
(ping's okay, and uhd_find_devices is ab
Hello everyone,
[USRP E310]
We need to capture some 300 Hz signal for a long period of time (up to
15'), as long as a GPIO is '1'. Minimum configurable bandwith is 286 KHz,
what makes us sample the data at 286 KSPS. At this sampling rate, every 15'
of capture results in a file of 2.2 GB.
The fol
My two cents:
Only useful reference: https://files.ettus.com/manual/page_gpio_api.html
UHD example:
https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp
In E310 you have to select the correct GPIO bank, that being *INT0 *(took
me a while to figure it out). You can start your pr
Hi Thomas!
The point is that the FPGA image doesn't contain the IP address – that
is stored, separately, on the EEPROM.
So, as soon as you're in safe mode, use the usrp_burn_mb_eeprom tool
that came with UHD (depending on your OS and way of installing, it might
be somewhere like /lib64/uhd/utils/
I have a timing question that has me going in circles, I don't
understand how the USRP timestamps work when using RFNoC.
In a normal system, packets have timestamps with them (or at least the
first one does) and you can compute the time of any samples based on the
timestamp, sample rate, and n
On 07/12/2017 07:00 AM, Brais Ares via USRP-users wrote:
Hello everyone,
[USRP E310]
We need to capture some 300 Hz signal for a long period of time (up to
15'), as long as a GPIO is '1'. Minimum configurable bandwith is 286
KHz, what makes us sample the data at 286 KSPS. At this sampling rat
Hey Jason,
The timestamp of each packet describes the time the first sample in the
packet was received. The timestamp is based on a counter in
noc_block_radio_core (timekeeper.v.) that increments at the sample rate
(i.e. radio_clk). The time is relative to that counter's placement in the
processin
Howdy Jonathon!
Is a "packet" determined before or after the RFNoC stage of the chain (I
assume before since it is in the radio core)?
Is there anyway to modify things if I decide to resample in an RFNoC
block? It seems like it would throw off the timing since the sample
rate into the block
Your assumption is correct: we are using an edited rx_samples_to_file code.
I forgot to mention it.
We'll try thread-splitting and see how it goes. Thank you.
Regards,
Brais.
2017-07-12 18:54 GMT+02:00 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com>:
> On 07/12/2017 07:00 AM, Brais
Hi Marcus,
I have attached the file "ubx160.txt" , which lists the output for the
command uhd_usrp_probe in verbatim. The daughter board ubx-160 is
connected to the RF "B". RF "A" has an SBX 120 installed. Let me know if
you need any other information. Thanks
Karan Suri
University of Michigan
Mas
Hello Karan:
Do you have one of the new Rev D UBX boards?
When was this UBX board purchased?
--Neel Pandeya
On 12 July 2017 at 11:57, Karan Suri via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi Marcus,
> I have attached the file "ubx160.txt" , which lists the output for the
> command
Dear UHD users,
when running uhd_images_downloader with the -i switch, the script will
still attempt to clear the target directory (this is the default
behaviour). To avoid this, you have the option of specifying `-k` (or
`--keep`) to not delete anything.
Future versions of UHD will have addition
Hi,
I just pulled the latest rfnoc-devel and gr-ettus updates. After resolving
dependencies (I was missing the python2-future package), I had the
following problem:
rfnocmodtool newmod test
Traceback (most recent call last):
File "/opt/rfnoc/bin/rfnocmodtool", line 27, in
m
The packetization happens in the radio_core (which is in
noc_block_radio_core) in a block called rx_control_gen3. That is where the
timestamp is applied. The output of that module goes to AXI Wrapper, which
doesn't do much since rx_control_gen3 generates the header too.
If you want to resample, co
Hi,
Try taking a look at Sylvain's presentation on RFNoC fosphor at GRCon 2015:
- Video: https://www.youtube.com/watch?v=ey9W2CUZKRs
- Presentation:
http://www.trondeau.com/s/2-munaut_sylvain-rfnoc_fosphor-2015-08-27.pdf
On Tue, Jul 11, 2017 at 1:56 AM, john liu via USRP-users <
usrp-users@lists.
21 matches
Mail list logo