Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Compiling new firmware on N210 (Henrique Bucher)
2. E310 AD9361 FIR filter Taps (Long, Jeffrey P.)
3. Re: E310 AD9361 FIR filter Taps (Ian Buckley)
4. Best way to change RFNoC block on the fly? (Jason Matusiak)
5. Re: Best way to change RFNoC block on the fly? (Martin Braun)
6. Re: Best way to change RFNoC block on the fly? (Jason Matusiak)
7. Re: Best way to change RFNoC block on the fly? (Martin Braun)
8. Re: X310 RFNOC getting UHD to recognize new RFNOC block
(Martin Braun)
9. Re: srsLTE & X300 box. (Alireza Hariri)
10. Error when switching between QPSK and BPSK modulations
(Damindra Bandara)
11. Re: Define custom setting register on x310 and access them
from uhd. (Martin Braun)
12. Re: X310 runs rfnoc-devel FPGA code but will not run
rfnoc-radio-redo FPGA code (Martin Braun)
13. More: FPGA register access (Seger, Edward H)
14. TX/RX Led turns Red with tx_samples_c app (X300) (Jasuja, Ishwar)
15. Re: TX/RX Led turns Red with tx_samples_c app (X300)
(Martin Braun)
16. Re: TX/RX Led turns Red with tx_samples_c app (X300)
(Michael West)
17. Re: Error when switching between QPSK and BPSK modulations
(Steven Knudsen)
18. X300: master clock & sampling rate (eNodeb simulator from
srsLTE) (Jasuja, Ishwar)
19. Does B210 Rev 4 use leaded or lead free solder
(Patrick Sathyanathan)
20. Re: Does B210 Rev 4 use leaded or lead free solder (Matt Ettus)
21. Re: Does B210 Rev 4 use leaded or lead free solder
(Patrick Sathyanathan)
22. Re: X300: master clock & sampling rate (eNodeb simulator from
srsLTE) (Michael West)
23. Re: X300: master clock & sampling rate (eNodeb simulator from
srsLTE) (Jasuja, Ishwar)
24. Re: X300: master clock & sampling rate (eNodeb simulator from
srsLTE) (Jasuja, Ishwar)
25. Re: X300: master clock & sampling rate (eNodeb simulator from
srsLTE) (Jasuja, Ishwar)
26. Re: Error when switching between QPSK and BPSK modulations
(Damindra Bandara)
27. Re: Error when switching between QPSK and BPSK modulations
(Martin Braun)
28. Re: Error when switching between QPSK and BPSK modulations
(Damindra Bandara)
29. AXI_FIR encrypted IP in Modelsim protected mode when running
noc_block_fir_filter from my own cocotb testbench (Swanson, Craig)
30. Re: AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
(Ian Buckley)
31. Re: AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
(Swanson, Craig)
32. Re: GPSDO as stand-alone component (Claudio Cicconetti)
33. Re: E310 AD9361 FIR filter Taps (Marcus M?ller)
34. Regarding time aligned samples of a MIMO configuration
(avinash kalyanaraman)
----------------------------------------------------------------------
Message: 1
Date: Mon, 20 Jun 2016 08:54:52 -0500
From: Henrique Bucher <[email protected]>
To: [email protected]
Subject: [USRP-users] Compiling new firmware on N210
Message-ID:
<calngcsx0-kqxjfiuba5d-2switxov4dsv2_gz+ngqjo8uju...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello
I want to customize the current firmware on the N210 but hit a glitch.
So far I was able to compile successfully both the FPGA bin and also the
USRP2 firmware binaries.
However I do not know which one is the actual firmware for the N210 that
should be used in the upload tool.
If I upload the FPGA binary with --no-fw, the fpga bin works fine: I reboot
and it behaves the same.
uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --no-fw
--fpga-path uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
However when I try both the device apparently bricks, ie I cannot find it
anymore with uhd_find_devices or uhd_usrp_probe, even changing the
interface IP address:
uhd_image_loader --args="type=usrp2,addr=192.168.26.180" --fw-path
uhd/firmware/usrp2/build/usrp2/usrp2_txrx_uhd.bin --fpga-path
uhd/fpga-src/usrp2/top/N2x0/build-N210R4/u2plus.bin
The whole process finishes and I can see the LEDs but it just does not
further work, which leads me to the realization that perhaps the
usrp2_txrx_uhd.bin firmware is not actually a perfect replacement to the
factory-issued one.
I also see these additional/potential firmwares being created but not sure
what is the difference between them
./usrp2p/bootloader/bootloader.bin
./usrp2p/usrp2p_txrx_uhd.bin
./usrp2/usrp2_txrx_uhd.bin
Would you please advise?
Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/33403f4d/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 20 Jun 2016 17:03:57 +0000
From: "Long, Jeffrey P." <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 AD9361 FIR filter Taps
Message-ID:
<cy1pr09mb082554095eab0170fe1f90d8d9...@cy1pr09mb0825.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Is it possible to set different taps for the FIR in the 9361? I found a file
with a bunch of different tap options:
...../uhd/host/lib/usrp/common/ad9361_driver/ad9361_filter_taps.h
Can it be as easy as generating those correctly and cutting and pasting into
this file? There seem to be different tap lengths for the FIR. How does it
decide which ones to use?
Thanks
Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/43b05142/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 20 Jun 2016 11:26:09 -0700
From: Ian Buckley <[email protected]>
To: "Long, Jeffrey P." <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 AD9361 FIR filter Taps
Message-ID:
<CAM_0ocF54PuQzpTsbbM9zaEWLf_yho3NuFWhrfhpym67+X=y...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Jeff,
The way the programmable FIR works in 9361 is that the H/W implements
16taps of filter and runs on the data converter clock which is a multiple
of the sample clock set by the various interpolation/decimation stages.
Thus the ratio of the converter clock to sample clock dictates how many
taps can be implemented in the RX and TX FIR's. The Ettus driver decides
what that ratio is based on the maximum operating frequencies for the ADC
and DAC, and the the master_clock_rate requested by the user. The driver
thus provides filter taps for all possible legal configuration scenarios.
If you have a certain configuration that you are targeting then work out
what the resulting ratio is and hence which coefficient set is being picked
(via code debug), then, yes, replace with your own coefficients...it really
can be that simple. Remember those FIR filters can run as 1/2/4
interpolator/decimators and the stock Ettus driver is factoring that into
its distribution of interpolation/decimation amongst the various filters
present in the radio when it chooses a configuraton. If you want to change
the mode it wants to run the FIR in then your edits will need to be more
intrusive since I don't recall any way you can use the API to do that.
-Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/a76c44e1/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 20 Jun 2016 14:50:20 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I got past my problem from earlier today worked out where I change the
frequency offset by adjusting a QT GUI Range and I am happy with it.
The next step is to allow a (non-RFNOC) GR block to update the value on
the fly, but I am not sure the best way to do that.
I again looked to fosphor to see if it is doing something similar, but I
honestly can't tell. There is a cfg message path between the fosphor
block and the QT fosphor display, but I couldn't tell what gets passed
through that. If that is how a regular GR block and set registers
within my RFNoC block, I assume that a register number just gets passed
through and nothing needs to get done on the receiver side (my RFNoC block)?
------------------------------
Message: 5
Date: Mon, 20 Jun 2016 12:00:37 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
You can set registers from GNU Radio, but you usually want to use the
set_arg() call instead. The set_arg() call will end up changing an arg
as defined in the block description file (the XML file) and typically
execute the associated Noc-Script. So, you could use a function probe or
something like that to call that API call.
There's no message port for rfnoc blocks yet, but that would be a simple
addition and I'll try and get it in soon.
Cheers,
Martin
On 06/20/2016 11:50 AM, Jason Matusiak via USRP-users wrote:
> I got past my problem from earlier today worked out where I change the
> frequency offset by adjusting a QT GUI Range and I am happy with it.
> The next step is to allow a (non-RFNOC) GR block to update the value on
> the fly, but I am not sure the best way to do that.
>
> I again looked to fosphor to see if it is doing something similar, but I
> honestly can't tell. There is a cfg message path between the fosphor
> block and the QT fosphor display, but I couldn't tell what gets passed
> through that. If that is how a regular GR block and set registers
> within my RFNoC block, I assume that a register number just gets passed
> through and nothing needs to get done on the receiver side (my RFNoC
> block)?
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Mon, 20 Jun 2016 15:28:03 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>/I got past my problem from earlier today worked out where I change the
>>/>>/frequency offset by adjusting a QT GUI Range and I am happy with it.
>>/>>/The next step is to allow a (non-RFNOC) GR block to update the value on
>>/>>/the fly, but I am not sure the best way to do that. />>//>>/I again
>>looked to fosphor to see if it is doing something similar, but I />>/honestly
>>can't tell. There is a cfg message path between the fosphor />>/block and the
>>QT fosphor display, but I couldn't tell what gets passed />>/through that. If
>>that is how a regular GR block and set registers />>/within my RFNoC block, I
>>assume that a register number just gets passed />>/through and nothing needs
>>to get done on the receiver side (my RFNoC />>/block)?/
>
>You can set registers from GNU Radio, but you usually want to use the
>set_arg() call instead. The set_arg() call will end up changing an arg
>as defined in the block description file (the XML file) and typically
>execute the associated Noc-Script. So, you could use a function probe or
>something like that to call that API call.
Thanks for chiming in Martin! OK, so it sounds like nothing would need to
change on my end, just //how// the callback in my RFNoC xml gets called is
changed (by someone else's block), is that right? Is there an example of what
you are saying in the wild?
>There's no message port for rfnoc blocks yet, but that would be a simple
>addition and I'll try and get it in soon.
The only reason I used the word "message" was that while trying to figure out
what was being passed back-and-forth via the cfg port for RFNoC, I noticed in
the display port's XML that the cfg port was labeled as type "message". What
is being passed through there then?
But an actual message port would be pretty sweet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/f80a69eb/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 20 Jun 2016 12:59:30 -0700
From: Martin Braun <[email protected]>
To: Jason Matusiak <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Best way to change RFNoC block on the fly?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 06/20/2016 12:28 PM, Jason Matusiak wrote:
> Thanks for chiming in Martin! OK, so it sounds like nothing would
> need to change on my end, just //how// the callback in my RFNoC xml
> gets called is changed (by someone else's block), is that right? Is
> there an example of what you are saying in the wild?
All of the RFNoC blocks call their own API calls whenever a value is
chagned (e.g., the filter taps). I don't think there's an example out
there where a block calls another block's RFNoC API calls, but that's
just a matter of stitching together some Python. The uhd_fft.grc example
(which is *not* RFNoC related) calls API calls on other blocks, maybe
that'll help you.
>> There's no message port for rfnoc blocks yet, but that would be a
>> simple addition and I'll try and get it in soon.
> The only reason I used the word "message" was that while trying to
> figure out what was being passed back-and-forth via the cfg port for
> RFNoC, I noticed in the display port's XML that the cfg port was
> labeled as type "message". What is being passed through there then?
The fosphor display and RFNoC blocks interact via messages; i.e. if you
change trise from the QT GUI, it'll trigger a message to be sent to the
other block, which it translates into an API call.
M
------------------------------
Message: 8
Date: Mon, 20 Jun 2016 13:03:23 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 RFNOC getting UHD to recognize new
RFNOC block
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hey James,
yes, we'll update those docs soon (and migrate them to the knowledge
base). Underscore is not a valid character, that's correct.
M
On 06/16/2016 01:23 PM, James Wagner via USRP-users wrote:
> OK, so I figured out what the problem was. the framework checks to see
> if the blockname specified in the XML has a valid format if not it
> returns an empty string. apparently underscore is not a valid character.
> so i had the by changing the blockname from pack_samp_decim to
> packsampdecim and it now appears to work.
>
> incidentally it appears that the getting started instructions are out of
> date since most blocks don't actually require their own block controller.
>
> https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
>
>
>
>
>
> On Tue, Jun 14, 2016 at 1:37 PM, James Wagner <[email protected]
> <mailto:[email protected]>> wrote:
>
> we have created a RFNOC block and then successfully loaded it into
> the x310's FPGA but now we are not sure exactly what has to be done
> in order to get the UHD to recognize and communicate with it.
> looking at the getting started page we were able to create an XML
> which seems to enable the uhd_usrp_probe to run without seg faulting
> but the outputted list of blocks shows a blank name for our block.
> the getting started page also suggested that a header and
> implementation for a block controller would need to created but
> seeing how only the fir has it's own block controller(and that seems
> to be for a special method to load the taps) I am not sure that
> requirement is still current.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Mon, 20 Jun 2016 18:11:35 +0430
From: Alireza Hariri <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "Jasuja, Ishwar" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] srsLTE & X300 box.
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
> On Jun 18, 2016, at 12:35 PM, Marcus M?ller via USRP-users
> <[email protected]> wrote:
>
> Hi Ishwar,
>
>
> On 06/18/2016 07:56 AM, Jasuja, Ishwar wrote:
>> CPU utilization never goes above 90%.
> But 90% is very high! What you're looking at is not the maximum CPU
> utilization over the last few seconds, but either an average or an
> instantaneous value!
> Notice that Us might not only be caused by your system being not fast enought
> on average, each U is a point in time where the transmit buffer in the USRP
> ran empty ? leaving the USRP with nothing to transmit, while the DAC must
> continue to run.
>> And all I see is constant stream of U getting sprayed on my console. I can
>> understand occasional underrun if CPU utilization was going high every once
>> in a while.
>>
>> Something just does not add up here. I am surprised srsLTE guys have not
>> tested this recently although they claim on their website that their
>> software works fine with X300.
> I'd assume they've tested it; having seen some of their work in person (been
> at FOSDEM), I'd say they do solid work; they don't gain anything by claiming
> something works that doesn't.
>> I am running this software on Haswell running at 4GHz. Do you recommend any
>> other x86 CPU that I can try?
> This is not the same core i5-5200 @3.3GHz you mentioned earlier?
> Anyway, I think the way to get this to work is probably not by buying a
> faster PC, but to identify the actual bottleneck, and to see what you can do
> about them
>>
>> Software has to be doing something ?really strange? to get Underruns at a
>> sampling rate of 5.7 MHz.
> Not at all ? 5.7MS/s is still a lot of data, and the fact that we can push
> through much more when not doing processing is a feat of optimization in all,
> network or USB drivers, operating system schedulers, UHD type conversion and
> application multithreading, not something that would work out of the box on a
> machine with naively implemented infrastructure. Also, latency is a critical
> issue here.
> Now, as mentioned, LTE isn't really CPU-friendly ? aside from a few FFTs,
> there's very much equalizing, synchronization and channel (de)coding to be
> done, all of which take up quite some CPU cycles, and potentially memory
> bandwidth.
>
>>
>> I was hoping to get this running without going into too much detail of
>> srsLTE software. If I cannot get the basic thing working at such a low
>> sampling rate, it is hard to justify the use of that open source package and
>> the hardware to upper management.
>> Esp when that package only supports release 8 features of LTE Phy.
>>
> Well, we're not affiliated with srsLTE, so as much as I like srs' free
> software approach, we're no more versed in using srsLTE than you are
> (probably less ? I personally haven't tried it), and also, we can't support
> products that aren't ours. We'll try our best to make things work for you by
> applying all knowledge we have on our devices, drivers, and SDR architectures
> in general, but we're no experts in all software that uses our devices.
>
> However, I'm pretty sure that the people behind srsLTE would probably know
> better than I do how to optimize their software ? all I, and other Ettus
> folks, can do is help you optimize the usage of the UHD driver, and that
> includes the set up of networking, which is the nr. 1 performance killer on
> the UHD side for the X310. After the samples "leave" UHD, either by being
> sent as network packets through your operating systems network stack, or by
> being written to a buffer in your application software, there's really
> nothing we can do than to make the handling of everything as smooth as
> possible while it's "inside" UHD. Hence our focus on dealing wiht what we
> know can influence performance. Just a quick check: you're not using any
> network switch, virtualization or firewall in between your PC and your X300?
> Also, which version of Linux are you running? What's the output of ethtool -c
> ${your ethernet device's name, e.g. eth0} ?
>
> I've taken the liberty to "stalk" you a bit and read through your submissions
> in the srsLTE-users mailing list archive. That was an interesting read!
> So, the point is that the N210 seems to able to transmit, at least, though
> everything will be totally broken, because it can't support the 5.72MS/s
> rate. Now, the N210 and the X300 are really not that different as an
> architecture ? the X300 definitely isn't any more "data-hungry"; in fact,
> with the X3xx we introduced a compressed header format, which should actually
> reduce complexity and overhead for the computer. So my guess is that if the
> sampling rate works, then srsLTE might be able try and do useful processing
> with the received signal ? which typically is much more CPU-intense than what
> happens on the transmit side.
>
> So, I don't think this is an issue with your USRP (which really doesn't care
> what kind of operation runs on your PC, and will just throw Us when it runs
> out of samples to send) or UHD. However, I think we would both like to know,
> right?
>
> Now, I don't know how to properly profile srsUE/LTE (not having had any
> involvement in the software so far). I guess a post to their mailing list
> asking how to identify a bottleneck would be smarter than just poking around;
> also, they'd probably hear about what goes wrong where ? after all, by a
> quick glance at their code and usage of VOLK (which is an awesome hardware
> optimized processing library), they're going through quite some effort to
> make srsUE/LTE work fast enough on modern hardware.
>
> My immediate approach would be (you could share this with the mailing list,
> maybe they have something to say about it):
> compile both srsLTE and srsUE after configuration with cmake
> -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
> use the Linux perf tool to get a recording of where CPU is spent when running:
> Enable perf profiling for normal users, including the ability to inspect
> what's happening in the kernel:
> sudo sysctl kernel/perf_event_paranoid=-1
> Run the application of choice, recording what's happening:
> perf record -ag ${the srs application you want to profile}
> Then, analyze the resulting perf data:
> perf report --sort=dso,cpu,comm
> analyze the results: UHD's most intense task should probably be the converter
> (which has the "side effect" of being in charge of getting the data out of
> the network buffer into your program's sample buffer, whilst converting the
> on-the-wire sample format to something your CPU can deal with).
> Now, the result can be that there is a CPU hog somewhere ? maybe a network
> driver in the kernel, maybe actualy somethin in UHD, or maybe some routine in
> srsLTE runs rampant. Or there might not be, and then we that the reason your
> computer is not sending the samples in time to the USRP is something
> architectural.
>
> Hope we can figure something out!
>
> Best regards,
> Marcus
>
>
>>
>>
>> From: Marcus M?ller [mailto:[email protected]
>> <mailto:[email protected]>]
>> Sent: Friday, June 17, 2016 10:45 PM
>> To: Jasuja, Ishwar; Michael West
>> Subject: Re: [USRP-users] srsLTE & X300 box.
>>
>> That's pretty high, because a short increase would be totally sufficient to
>> let your system lose step, and that would lead to an Underrun.
>>
>> Best regards,
>> Marcus
>>
>> On 06/18/2016 02:03 AM, Jasuja, Ishwar wrote:
>> The total CPU utilization hovers around 80-85 %
>>
>> From: Michael West [mailto:[email protected]
>> <mailto:[email protected]>]
>> Sent: Friday, June 17, 2016 4:49 PM
>> To: Jasuja, Ishwar
>> Cc: Marcus M?ller
>> Subject: Re: [USRP-users] srsLTE & X300 box.
>>
>> Hi Ishwar,
>>
>> Increasing the default socket buffer size was to eliminate the firmware
>> communication errors when using larger MTU sizes. Please increase your MTU
>> size to 9000. Also, try increasing the number of descriptors for the
>> interface:
>>
>> > sudo ethtool -G eth<N> rx 4096 tx 4096
>>
>> And disable interrupt coalescing on the TX side:
>>
>> > sudo ethtool -C eth<N> adaptive-tx off
>>
>> If all that doesn't do it, I believe Marcus may be correct about the CPU
>> being too busy to keep up with the TX stream. Check 'htop' to see what the
>> overall CPU load is and if any of the cores is going over 90%.
>>
>> Regards,
>> Michael
>>
>> On Fri, Jun 17, 2016 at 4:34 PM, Jasuja, Ishwar <[email protected]
>> <mailto:[email protected]>> wrote:
>> Just tried it. Still getting Underruns.
>>
>> Cut & pasting output of that test app here. Just in case if you notice
>> anything..
>>
>>
>> Opening RF device...
>> Opening USRP with args:
>> -- X300 initialization sequence...
>> -- Determining maximum frame size... 8000 bytes.
>> -- Setup basic communication...
>> -- Loading values from EEPROM...
>> -- Setup RF frontend clocking...
>> -- Radio 1x clock:200
>> -- Initialize Radio0 control...
>> -- Performing register loopback test... pass
>> -- Initialize Radio1 control...
>> -- Performing register loopback test... pass
>> Trying to dynamically change Master clock...
>> Master clock is configurable. Using reduced symbol sizes and sampling rates.
>> Setting sampling rate 1.92 MHz
>> Set TX gain: 31.5 dB
>> Set TX freq: 2400.00 MHz
>> - Resource Allocation Type: Type 0
>> + Resource Block Group Size: 1
>> + RBG Bitmap: 0x3f
>> - Modulation and coding scheme index: 1
>> - HARQ process: 0
>> - New data indicator: No
>> - Redundancy version: 0
>> - TPC command for PUCCH: --
>> - PRB Bitmap Assignment 0st slot:
>> 0, 1, 2, 3, 4, 5,
>> - PRB Bitmap Assignment 1st slot:
>> 0, 1, 2, 3, 4, 5,
>> - Number of PRBs: 6
>> - Modulation type: QPSK
>> - Transport block size: 208
>> Type new MCS index and press Enter:
>> UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
>>
>> From: Michael West [mailto:[email protected]
>> <mailto:[email protected]>]
>> Sent: Friday, June 17, 2016 4:26 PM
>> To: Jasuja, Ishwar
>> Cc: Marcus M?ller
>>
>> Subject: Re: [USRP-users] srsLTE & X300 box.
>>
>> Hi Ishwar,
>>
>> You need to change the default in addition to the max. Run 'sudo sysctl -w
>> net.core.rmem_default=33554432'.
>>
>> Regards,
>> Michael
>>
>> On Fri, Jun 17, 2016 at 3:59 PM, Jasuja, Ishwar <[email protected]
>> <mailto:[email protected]>> wrote:
>> srsLTE authors claim that their software works on X300 hardware and they are
>> the ones who asked me to ping people on this group.
>> I was hoping that there is some soul out there who is currently running what
>> I am trying to do.
>>
>> Apparently, srsLTE guys only run their latest stuff on B210 hardware with
>> USB interface to Host. (I don?t have that box). Now don?t tell me ..?We can
>> sell you one!!?
>>
>> I tried N210 with Ethernet interface to host and have not had much luck.
>> Sampling rate on that box is not compatible with LTE.
>>
>> Note: Please do not forward this email to the mailing list.
>>
>> Thanks,
>> Ishwar
>>
>> From: Jasuja, Ishwar
>> Sent: Friday, June 17, 2016 3:49 PM
>> To: 'Michael West'; Marcus M?ller
>> Subject: RE: [USRP-users] srsLTE & X300 box.
>>
>> Michael,
>>
>> I have done that already. (both rmem_max & wmem_max)
>>
>> UHD API is kind enough to print out a warning message otherwise.
>> Please run: sudo sysctl -w net.core.rmem_max=33554432
>>
>> I will get hold of a 10 Gbe NIC card and try what you have suggested.
>>
>> Thanks,
>> Ishwar
>>
>> From: USRP-users [mailto:[email protected]
>> <mailto:[email protected]>] On Behalf Of Michael West via
>> USRP-users
>> Sent: Friday, June 17, 2016 3:24 PM
>> To: Marcus M?ller
>> Cc: [email protected] <mailto:[email protected]>
>> Subject: Re: [USRP-users] srsLTE & X300 box.
>>
>> Try increasing the default socket buffer size when using larger MTU sizes.
>> When using the Intel X710-DAO 10 GbE NIC, we found it was necessary to
>> increase the default socket buffer size when using an MTU >3000 or we would
>> get firmware communication or radio control errors. I also recommend
>> increasing the number of tx and rx descriptors on the interface.
>>
>> Regards,
>> Michael
>>
>> On Fri, Jun 17, 2016 at 2:45 PM, Marcus M?ller <
>> <mailto:[email protected]>[email protected]
>> <mailto:[email protected]>> wrote:
>> Hi Ishwar,
>>
>> I haven't used srsLTE, but if things stop working with an MTU > 5000, then
>> that's your maximum MTU size. The X3xx supports bigger frames over network,
>> but there's very little Gigabit ethernet cards that support Jumbo Frames
>> larger than 4KB.
>> So simply leave the MTU at e.g. 4096. If you still get U's, then you'll
>> probably need a faster computer, or other network settings can be improved.
>> I don't know which network card or OS you're using, but at high rates, you
>> should definitely make sure that interrupt coalescing is set to a sensible
>> value.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 14.06.2016 18:11, Jasuja, Ishwar via USRP-users wrote:
>> Hi,
>>
>> Has anyone been running srsLTE software on X300? I have not had much luck
>> with it. I have tried different X300 FPGA versions (15.0 & 20.0) but could
>> not get pdsch_enodeb test app to work.
>>
>> I am connected to the X300 box on GigE interface. If the mtu value is left
>> at default (1500) value, then I get continuous Underruns. If I increase the
>> MTU value to a large value (> 5000), then I get following error.
>>
>> UHD Error:
>> x300 fw communication failure #1
>> EnvironmentError: IOError: x300 fw poke32 - reply timed out
>>
>> If anyone has this test-app running, can you please let me know what version
>> of FPGA & UHD Host drivers you are using? Also, how X300 box is connected to
>> PC that is running the test app.
>>
>> I am using quad-core machine with following x86 CPU.
>> model name : Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
>> I don?t have any other app running on this machine ( which could starve the
>> test app).
>>
>> Strange thing is that the pdsch_ue app does not give this error.
>>
>> Any help will be greatly appreciated.
>>
>> Note: I asked for help on srsLTE mailing list and author asked me to run the
>> question by this mailing list.
>>
>> Thanks,
>> Ishwar
>>
>>
>>
>>
>> Spirent Communications e-mail confidentiality.
>> ------------------------------------------------------------------------
>> This e-mail contains confidential and / or privileged information belonging
>> to Spirent Communications plc, its affiliates and / or subsidiaries. If you
>> are not the intended recipient, you are hereby notified that any disclosure,
>> copying, distribution and / or the taking of any action based upon reliance
>> on the contents of this transmission is strictly forbidden. If you have
>> received this message in error please notify the sender by return e-mail and
>> delete it from your system.
>>
>> Spirent Communications plc
>> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
>> Tel No. +44 (0) 1293 767676 <tel:%2B44%20%280%29%201293%20767676>
>> Fax No. +44 (0) 1293 767677 <tel:%2B44%20%280%29%201293%20767677>
>>
>> Registered in England Number 470893
>> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
>> United Kingdom.
>>
>> Or if within the US,
>>
>> Spirent Communications,
>> 27349 Agoura Road, Calabasas, CA, 91301, USA.
>> Tel No. 1-818-676- 2300 <tel:1-818-676-%202300>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
>>
>>
>>
>>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/851c31db/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 20 Jun 2016 16:38:59 -0400
From: Damindra Bandara <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Error when switching between QPSK and BPSK
modulations
Message-ID:
<CANpceN8VrGUFKUT8qjDaBG7=6wexrd1qpkfg_g2v5eouwjv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am developing an application which changes between the QPSK and BPSK
modulations based on the signal level. My transmitter path is set as
follows.
File source --> Packet Encoder --> Constellation modulator --.> USRP sink.
Initially, the constellation of the 'Constellation modulator' is set to a
QPSK Constellation Rect. Object. To change the modulation to BPSK I change
the Constellation Rect. Object to BPSK.
Everything works fine for the change from QPSK to BPSK. But when I try to
change back to QPSK from BPSK I get the following error.
sched: <block pfb_arb_resampler_ccf (12)> is requesting more input data
than we can provide.
ninput_items_required = 13525
max_possible_items_available = 8191
If this is a filter, consider reducing the number of taps.
I appreciate if you could help me to solve this problem.
Thank you
Damindra
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/4d002d74/attachment-0001.html>
------------------------------
Message: 11
Date: Mon, 20 Jun 2016 13:42:19 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Define custom setting register on x310 and
access them from uhd.
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Patrick,
our recommended solution to this is to use RFNoC. What exactly are
trying to do?
M
On 06/14/2016 02:49 PM, Patrick Berger via USRP-users wrote:
> Hi
>
> Is it possible to add custom setting registers in the ddc and duc chain?
> I've read that there are separate address ranges on the b210 but nothing
> about the x310. If I define the adresses to avoid conflicts with the
> predefined register in radio.v would that work? (Was a discussion in an
> earlier post)
>
> On the other hand I've read that the peek/poke function could be used
> from uhd. But this seems to me that I've to rebuild the uhd driver so
> shared libraries wont be supported on different computers? Isn't there a
> function like this one to access gain or center frequency, just with
> define the radio modul and the adress for reading and adress + value for
> writing?
>
> Best regards
> Patrick
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 12
Date: Mon, 20 Jun 2016 13:45:17 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not
run rfnoc-radio-redo FPGA code
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
The process is mostly the same. In particular, the XML files shouldn't
be any different. You can also use the same NoC-IDs across devices.
Note that underscores are not valid in block names.
M
On 06/13/2016 10:36 AM, Swanson, Craig wrote:
> Martin, Would it be okay if you enlighten me a little about how the
> process works with the X310 comparted to the E310 when creating a new
> noc_block?
>
> E310: - I ran into the same problem of rfnoc-devel running RFNOC but
> not rfnoc-radio-redo. The solution was to get the latest image from
> Ettus and put it on the SD card, then recompile everything on my pc,
> then cross compile what was on my PC with the E310. - If I created a
> new noc_block such as noc_block_Receiver, I would give it a new NOC
> ID. Then I would create a new XML file in gr-ettus. This would
> enable me to see it as a block in gnuradio. But I also had to create
> a new XML file to move over to the E310 in order for uhd_usrp_probe
> to recognize my new noc_block_Receiver. So there were a total of two
> XML files I had to create when I created noc_block_Receiver.
>
> X310: - What is the solution for why noc_block_moving_avg created in
> rfnoc-radio-redo fails but not rfnoc-devel when I run uhd_usrp_probe
> --init-only? - If I create a new noc_block_Receiver, I understand the
> first step which is to put a new .XML file in gr-ettus. But where do
> I put the .XML file so the X310 recognizes it when I run
> uhd_usrp_probe? With the E310, I would move the XML file over to the
> directory where uhd_usrp_probe is looking for it.
>
> Craig
>
>
>
> Craig F. Swanson Research Engineer II Information and Communications
> Laboratory Communications, Systems, and Spectrum Division Georgia
> Tech Research Institute Room 560 250 14th Street NW Atlanta, GA
> 30318 Cell: 770-298-9156 http://www.gtri.gatech.edu
>
> -----Original Message----- From: Martin Braun
> [mailto:[email protected]] Sent: Monday, June 13, 2016 1:24 PM
> To: Swanson, Craig <[email protected]>; Jonathon Pendlum
> <[email protected]> Cc: [email protected] Subject:
> Re: [USRP-users] X310 runs rfnoc-devel FPGA code but will not run
> rfnoc-radio-redo FPGA code
>
> No, it doesn't. Jonathon was referring to the UHD repository.
>
> M
>
> On 06/13/2016 10:05 AM, Swanson, Craig via USRP-users wrote:
>> ?Jonathon,
>>
>> Does running uhd_usrp_probe --init-only rely on gr-ettus? I guess
>> I didn't realize that until now.
>>
>> I will update as you have recommended.
>>
>>
>> Craig
>>
>>
>> *Craig F. Swanson* */Research Engineer II /* */Information and
>> Communications Laboratory/* */Communications, Systems, and Spectrum
>> Division/* /Georgia Tech Research Institute/ /Room 560 250 14th St
>> NW / /Atlanta, GA 30318/ /Cell: 770.298.9156/
>> http://www.gtri.gatech.edu
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf
>>
>>
0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>> ----------------------------------------------------------------------
>>
>>
--
>> *From:* Jonathon Pendlum <[email protected]> *Sent:*
>> Monday, June 13, 2016 12:50 PM *To:* Swanson, Craig *Cc:* Martin
>> Braun; Marcus M?ller; [email protected] *Subject:* Re:
>> X310 runs rfnoc-devel FPGA code but will not run rfnoc-radio-redo
>> FPGA code
>>
>> Craig,
>>
>> The two code bases have a large number of changes, so you need to
>> run a rfnoc-radio-redo FPGA image with the rfnoc-radio-redo UHD /
>> gr-ettus code.
>>
>>
>>
>> Jonathon
>>
>> On Mon, Jun 13, 2016 at 11:44 AM, Swanson, Craig
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> ?Jonathon,
>>
>> After loading the code on the X310 and running uhd_usrp_probe
>> --init-only, I get the following error:
>>
>> Error: RuntimeError: x300_dac_ctrl: timeout waiting for DAC PLL to
>> lock?
>>
>>
>> I am assuming the issue is that the image running on the X310 is
>> not the latest? I knew how to get around this problem with the
>> E310, but I am not sure how to solve the problem with the X310.
>>
>>
>> Craig
>>
>>
>> *Craig F. Swanson* */Research Engineer II /* */Information and
>> Communications Laboratory/* */Communications, Systems, and Spectrum
>> Division/* /Georgia Tech Research Institute/ /Room 560 250 14th St
>> NW / /Atlanta, GA 30318/ /Cell: 770.298.9156 <tel:770.298.9156>/
>> http://www.gtri.gatech.edu
>>
>> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf
>>
>>
0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>>
>>
>>
>>
>> _______________________________________________ USRP-users mailing
>> list [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
------------------------------
Message: 13
Date: Mon, 20 Jun 2016 21:15:40 +0000
From: "Seger, Edward H" <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: [USRP-users] More: FPGA register access
Message-ID:
<b79379c8e247c54d9d1a503ed97cb3c014a48...@msmr-gh1-uea10.corp.nsa.gov>
Content-Type: text/plain; charset="us-ascii"
Folks,
I'd like to access custom registers in the FPGA as well and I have a few
questions about this:
E310, 3.9.3
1. There is a Fn in multi_usrp::set_user_register(). Is this call driving the
same bus as the registers that are in the radio? I can make this call from my
application but I don't see the FPGA register getting set. The comments in the
.hpp mention "user configuration register bus". What is this?
I noticed there is no get_user_register(). When I tried to create one I got a
"no matching function call to uhd::property<unsigned int>::get(uint32_t). Is
there a reason there is no get Fn?
3. I'd be OK using the same bus as the radio registers, but I have not been
able to get to these from up at the multi_usrp level. Is there an example of
doing this? I need a R/W interface in the multi_usrp class.
Thanks
Ed
------------------------------
Message: 14
Date: Mon, 20 Jun 2016 22:03:58 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] TX/RX Led turns Red with tx_samples_c app (X300)
Message-ID:
<by2pr1001mb1061de15913c9cd28a305bd0ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
When I run tx_samples_c example app on X300 box, I see that the TX/RX Led on
first port turns Red. Is this a normal behavior?
I don't see the app giving any error message.
Thanks,
Ishwar
Here is the screen shot
ijasuja@ijasuja-desktop /home2/ijasuja/uhd/host/build/examples $ ./tx_samples_c
-f 2000000000 -g 20
linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-216-gb1c2d4bb
Creating USRP with args ""...
-- X300 initialization sequence...
-- Determining maximum frame size... 8000 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
Setting TX Rate: 1000000.000000...
Actual TX Rate: 1000000.000000...
Setting TX Gain: 20.000000 db...
Actual TX Gain: 20.000000...
Setting TX frequency: 2000.000000 MHz...
Actual TX frequency: 2000.000000 MHz...
Buffer size in samples: 1996
Press Ctrl+C to stop streaming...
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/a9560380/attachment-0001.html>
------------------------------
Message: 15
Date: Mon, 20 Jun 2016 15:07:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] TX/RX Led turns Red with tx_samples_c app
(X300)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Ishwar,
red means "transmitting", green means "receiving". So yes, this is
expected behaviour.
Martin
On 06/20/2016 03:03 PM, Jasuja, Ishwar via USRP-users wrote:
> Hi,
>
>
>
> When I run tx_samples_c example app on X300 box, I see that the TX/RX
> Led on first port turns Red. Is this a normal behavior?
>
>
>
> I don?t see the app giving any error message.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
> Here is the screen shot
>
>
>
> ijasuja@ijasuja-desktop /home2/ijasuja/uhd/host/build/examples $
> ./tx_samples_c -f 2000000000 -g 20
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-216-gb1c2d4bb
>
>
>
> Creating USRP with args ""...
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
> -- Setup RF frontend clocking...
>
> -- Radio 1x clock:200
>
> -- Initialize Radio0 control...
>
> -- Performing register loopback test... pass
>
> -- Initialize Radio1 control...
>
> -- Performing register loopback test... pass
>
> Setting TX Rate: 1000000.000000...
>
> Actual TX Rate: 1000000.000000...
>
>
>
> Setting TX Gain: 20.000000 db...
>
> Actual TX Gain: 20.000000...
>
> Setting TX frequency: 2000.000000 MHz...
>
> Actual TX frequency: 2000.000000 MHz...
>
> Buffer size in samples: 1996
>
> Press Ctrl+C to stop streaming...
>
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking
> of any action based upon reliance on the contents of this transmission
> is strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 16
Date: Mon, 20 Jun 2016 15:07:56 -0700
From: Michael West <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] TX/RX Led turns Red with tx_samples_c app
(X300)
Message-ID:
<cam4xkrqp3dhq2gsbt_dowjudhsddchvgmcosgrrzybn4lad...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ishwar,
For the TX/RX LED, red means actively transmitting and green means actively
receiving. See the manual here
<http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_on_board_leds>.
Regards,
Michael
On Mon, Jun 20, 2016 at 3:03 PM, Jasuja, Ishwar via USRP-users <
[email protected]> wrote:
> Hi,
>
>
>
> When I run tx_samples_c example app on X300 box, I see that the TX/RX Led
> on first port turns Red. Is this a normal behavior?
>
>
>
> I don?t see the app giving any error message.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
> Here is the screen shot
>
>
>
> ijasuja@ijasuja-desktop /home2/ijasuja/uhd/host/build/examples $
> ./tx_samples_c -f 2000000000 -g 20
>
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.010.git-216-gb1c2d4bb
>
>
>
> Creating USRP with args ""...
>
> -- X300 initialization sequence...
>
> -- Determining maximum frame size... 8000 bytes.
>
> -- Setup basic communication...
>
> -- Loading values from EEPROM...
>
> -- Setup RF frontend clocking...
>
> -- Radio 1x clock:200
>
> -- Initialize Radio0 control...
>
> -- Performing register loopback test... pass
>
> -- Initialize Radio1 control...
>
> -- Performing register loopback test... pass
>
> Setting TX Rate: 1000000.000000...
>
> Actual TX Rate: 1000000.000000...
>
>
>
> Setting TX Gain: 20.000000 db...
>
> Actual TX Gain: 20.000000...
>
> Setting TX frequency: 2000.000000 MHz...
>
> Actual TX frequency: 2000.000000 MHz...
>
> Buffer size in samples: 1996
>
> Press Ctrl+C to stop streaming...
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking of
> any action based upon reliance on the contents of this transmission is
> strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/505b7f9e/attachment-0001.html>
------------------------------
Message: 17
Date: Mon, 20 Jun 2016 16:12:15 -0600
From: Steven Knudsen <[email protected]>
To: Damindra Bandara <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Error when switching between QPSK and BPSK
modulations
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Damindra,
I am no expert, but it appears this is not a USRP issue, but rather one from
GR. Might i suggest you debug using a flowgraph that does not employ the USRP
block? I am guessing that you may see the same error.
You may be able to use the tag and message debugging blocks to trace things.
Another guess is that is that you have a bit of race condition, perhaps when
the number of bits per symbol is changed (though I don?t see the relationship
between 13525 and 8191 right away). That is, the resampler ratio appears to be
changed before a source block is changed to produce the required number of
samples. Hard to say more without the flowgraph in hand.
good luck,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
All the wires are cut, my friends
Live beyond the severed ends. Louis MacNeice
> On Jun 20, 2016, at 14:38, Damindra Bandara via USRP-users
> <[email protected]> wrote:
>
> Hi,
>
> I am developing an application which changes between the QPSK and BPSK
> modulations based on the signal level. My transmitter path is set as follows.
>
> File source --> Packet Encoder --> Constellation modulator --.> USRP sink.
>
> Initially, the constellation of the 'Constellation modulator' is set to a
> QPSK Constellation Rect. Object. To change the modulation to BPSK I change
> the Constellation Rect. Object to BPSK.
> Everything works fine for the change from QPSK to BPSK. But when I try to
> change back to QPSK from BPSK I get the following error.
>
> sched: <block pfb_arb_resampler_ccf (12)> is requesting more input data
> than we can provide.
> ninput_items_required = 13525
> max_possible_items_available = 8191
> If this is a filter, consider reducing the number of taps.
>
> I appreciate if you could help me to solve this problem.
>
> Thank you
> Damindra
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/cd8e105b/attachment-0001.html>
------------------------------
Message: 18
Date: Mon, 20 Jun 2016 22:19:56 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] X300: master clock & sampling rate (eNodeb
simulator from srsLTE)
Message-ID:
<by2pr1001mb1061c247f0530cbbd444a6dcec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am trying to run pdsch_enodeb (srsLTE's example app) on X300 hardware.
I am seeing following warning message:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 1.920000 MSps
Actual sample rate: 1.923077 MSps
I have set the master clock to 184.32 MHz. (master clocking rate in this case
is even multiple of sampling rate)
The example app does not seem to like this and it exits.
Am I doing something wrong?
For now, I have commented out the code that terminates the app. I am hoping
that kind of sampling error should not cause problem on receive side (esp when
the signal is BPSK/QPSK modulated)
What should the tx_gain/rx_gain be set to if I have connected Antenna to both
X300 boxes; One running enodeB simulator example app and another running UE
simulator example app.
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676
Fax No. +44 (0) 1293 767677
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/cb9055ac/attachment-0001.html>
------------------------------
Message: 19
Date: Mon, 20 Jun 2016 15:21:57 -0700
From: Patrick Sathyanathan <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: [USRP-users] Does B210 Rev 4 use leaded or lead free solder
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
I am having a couple of components professionally replaced and they want to
know.
Thanks,
--Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/985acdb0/attachment-0001.html>
------------------------------
Message: 20
Date: Mon, 20 Jun 2016 15:32:50 -0700
From: Matt Ettus <[email protected]>
To: Patrick Sathyanathan <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does B210 Rev 4 use leaded or lead free
solder
Message-ID:
<CAN=1kn9r5zyr5pbkxky2lvntag7or7fyw2zlcxvz3-3+gct...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
All of our products are completely lead free, since roughly 2007.
On Mon, Jun 20, 2016 at 3:21 PM, Patrick Sathyanathan via USRP-users <
[email protected]> wrote:
> I am having a couple of components professionally replaced and they want
> to know.
>
> Thanks,
>
> --Patrick
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/6847db82/attachment-0001.html>
------------------------------
Message: 21
Date: Mon, 20 Jun 2016 15:35:27 -0700
From: Patrick Sathyanathan <[email protected]>
To: Matt Ettus <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Does B210 Rev 4 use leaded or lead free
solder
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, Matt.
--Patrick
From: [email protected]
Date: Mon, 20 Jun 2016 15:32:50 -0700
Subject: Re: [USRP-users] Does B210 Rev 4 use leaded or lead free solder
To: [email protected]
CC: [email protected]; [email protected]
All of our products are completely lead free, since roughly 2007.
On Mon, Jun 20, 2016 at 3:21 PM, Patrick Sathyanathan via USRP-users
<[email protected]> wrote:
I am having a couple of components professionally replaced and they want to
know.
Thanks,
--Patrick
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/30d295f2/attachment-0001.html>
------------------------------
Message: 22
Date: Mon, 20 Jun 2016 16:01:48 -0700
From: Michael West <[email protected]>
To: "Jasuja, Ishwar" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb
simulator from srsLTE)
Message-ID:
<CAM4xKrq-u1+nBf8q5=8br76c-hzee-q1uh2ya8xtz0z6m9n...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ishwar,
I am not familiar with the srsLTE software. What I can tell you is that
you will see that warning if the sample rate is set before the master clock
rate is set. Be sure the master clock rate is set first.
Also, if you have the devices directly cabled to each other, you should add
an attenuator (30 dB) to make sure you don't damage the LNAs. With the
attenuator in place, you can put the TX gain to maximum and adjust the RX
gain as needed. The gain range depends on which type of daughterboard you
are using. Run 'uhd_usrp_probe' to see the gain ranges for the
daughterboards you are using.
Regards,
Michael
On Mon, Jun 20, 2016 at 3:19 PM, Jasuja, Ishwar via USRP-users <
[email protected]> wrote:
> Hi,
>
>
>
> I am trying to run pdsch_enodeb (srsLTE?s example app) on X300 hardware.
>
>
>
> I am seeing following warning message:
>
>
>
> UHD Warning:
>
> The hardware does not support the requested TX sample rate:
>
> Target sample rate: 1.920000 MSps
>
> Actual sample rate: 1.923077 MSps
>
>
>
> I have set the master clock to 184.32 MHz. (master clocking rate in this
> case is even multiple of sampling rate)
>
>
>
> The example app does not seem to like this and it exits.
>
>
>
> Am I doing something wrong?
>
>
>
> For now, I have commented out the code that terminates the app. I am
> hoping that kind of sampling error should not cause problem on receive side
> (esp when the signal is BPSK/QPSK modulated)
>
>
>
> What should the tx_gain/rx_gain be set to if I have connected Antenna to
> both X300 boxes; One running enodeB simulator example app and another
> running UE simulator example app.
>
>
>
> Thanks,
>
> Ishwar
>
>
>
>
>
>
> Spirent Communications e-mail confidentiality.
> ------------------------------------------------------------------------
> This e-mail contains confidential and / or privileged information
> belonging to Spirent Communications plc, its affiliates and / or
> subsidiaries. If you are not the intended recipient, you are hereby
> notified that any disclosure, copying, distribution and / or the taking of
> any action based upon reliance on the contents of this transmission is
> strictly forbidden. If you have received this message in error please
> notify the sender by return e-mail and delete it from your system.
>
> Spirent Communications plc
> Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United
> Kingdom.
> Tel No. +44 (0) 1293 767676
> Fax No. +44 (0) 1293 767677
>
> Registered in England Number 470893
> Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10
> 9XN, United Kingdom.
>
> Or if within the US,
>
> Spirent Communications,
> 27349 Agoura Road, Calabasas, CA, 91301, USA.
> Tel No. 1-818-676- 2300
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/961a36b2/attachment-0001.html>
------------------------------
Message: 23
Date: Mon, 20 Jun 2016 23:20:41 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb
simulator from srsLTE)
Message-ID:
<by2pr1001mb106101ce28ce6cb77c594b5bec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Setting the master clock rate is the first thing I do. The code I pulled from
git (srsLTE) was not doing that. It would set the master clock rate after
setting the tx sampling rate and it was causing havoc. Kept getting underrun
errors. No matter what I tried.
I have 20 db attenuator. Let me change that to 30.
Before that I should compare UE simulator?s initialization sequence related to
USRP to the one in rx_samples_c. That is how I found that problem in the enodeB
simulator code by comparing it to tx_samples_c initialization sequence.
Thanks,
Ishwar
From: Michael West [mailto:[email protected]]
Sent: Monday, June 20, 2016 4:02 PM
To: Jasuja, Ishwar
Cc: [email protected]
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb simulator
from srsLTE)
Hi Ishwar,
I am not familiar with the srsLTE software. What I can tell you is that you
will see that warning if the sample rate is set before the master clock rate is
set. Be sure the master clock rate is set first.
Also, if you have the devices directly cabled to each other, you should add an
attenuator (30 dB) to make sure you don't damage the LNAs. With the attenuator
in place, you can put the TX gain to maximum and adjust the RX gain as needed.
The gain range depends on which type of daughterboard you are using. Run
'uhd_usrp_probe' to see the gain ranges for the daughterboards you are using.
Regards,
Michael
On Mon, Jun 20, 2016 at 3:19 PM, Jasuja, Ishwar via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I am trying to run pdsch_enodeb (srsLTE?s example app) on X300 hardware.
I am seeing following warning message:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 1.920000 MSps
Actual sample rate: 1.923077 MSps
I have set the master clock to 184.32 MHz. (master clocking rate in this case
is even multiple of sampling rate)
The example app does not seem to like this and it exits.
Am I doing something wrong?
For now, I have commented out the code that terminates the app. I am hoping
that kind of sampling error should not cause problem on receive side (esp when
the signal is BPSK/QPSK modulated)
What should the tx_gain/rx_gain be set to if I have connected Antenna to both
X300 boxes; One running enodeB simulator example app and another running UE
simulator example app.
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676<tel:%2B44%20%280%29%201293%20767676>
Fax No. +44 (0) 1293 767677<tel:%2B44%20%280%29%201293%20767677>
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300<tel:1-818-676-%202300>
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/7652785e/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 21 Jun 2016 00:05:39 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb
simulator from srsLTE)
Message-ID:
<by2pr1001mb106111008372caafe4e68549ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
I just realized that the API call (uhd_usrp_set_master_clock_rate ) was not
able to change the master clock rate. I have to pass the master_clock_rate in
radio args for it to work.
Finally, got two X300 boxes talking to each other; one running eNodeB
simulator & other running UE simulator.
./pdsch_enodeb -a "type=x300,master_clock_rate=184.32e6" -p 6 -f 2000000000 -g
60
./pdsch_ue -f 2000000000 -g 30 -a "type=x300,master_clock_rate=184.32e6"
Thanks Michael, Marcus
I will try to stream video over from eNodeB to UE simulator app.
Thanks again,
Ishwar
From: Michael West [mailto:[email protected]]
Sent: Monday, June 20, 2016 4:02 PM
To: Jasuja, Ishwar
Cc: [email protected]
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb simulator
from srsLTE)
Hi Ishwar,
I am not familiar with the srsLTE software. What I can tell you is that you
will see that warning if the sample rate is set before the master clock rate is
set. Be sure the master clock rate is set first.
Also, if you have the devices directly cabled to each other, you should add an
attenuator (30 dB) to make sure you don't damage the LNAs. With the attenuator
in place, you can put the TX gain to maximum and adjust the RX gain as needed.
The gain range depends on which type of daughterboard you are using. Run
'uhd_usrp_probe' to see the gain ranges for the daughterboards you are using.
Regards,
Michael
On Mon, Jun 20, 2016 at 3:19 PM, Jasuja, Ishwar via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I am trying to run pdsch_enodeb (srsLTE?s example app) on X300 hardware.
I am seeing following warning message:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 1.920000 MSps
Actual sample rate: 1.923077 MSps
I have set the master clock to 184.32 MHz. (master clocking rate in this case
is even multiple of sampling rate)
The example app does not seem to like this and it exits.
Am I doing something wrong?
For now, I have commented out the code that terminates the app. I am hoping
that kind of sampling error should not cause problem on receive side (esp when
the signal is BPSK/QPSK modulated)
What should the tx_gain/rx_gain be set to if I have connected Antenna to both
X300 boxes; One running enodeB simulator example app and another running UE
simulator example app.
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676<tel:%2B44%20%280%29%201293%20767676>
Fax No. +44 (0) 1293 767677<tel:%2B44%20%280%29%201293%20767677>
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300<tel:1-818-676-%202300>
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/28793509/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 21 Jun 2016 00:16:27 +0000
From: "Jasuja, Ishwar" <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb
simulator from srsLTE)
Message-ID:
<by2pr1001mb1061d8fadf1d34d15b2f4448ec...@by2pr1001mb1061.namprd10.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Well, technically only one is talking (eNodeB simulator) and other (UE
simulator) is listening ?
From: Jasuja, Ishwar
Sent: Monday, June 20, 2016 5:06 PM
To: 'Michael West'
Cc: [email protected]
Subject: RE: [USRP-users] X300: master clock & sampling rate (eNodeb simulator
from srsLTE)
I just realized that the API call (uhd_usrp_set_master_clock_rate ) was not
able to change the master clock rate. I have to pass the master_clock_rate in
radio args for it to work.
Finally, got two X300 boxes talking to each other; one running eNodeB
simulator & other running UE simulator.
./pdsch_enodeb -a "type=x300,master_clock_rate=184.32e6" -p 6 -f 2000000000 -g
60
./pdsch_ue -f 2000000000 -g 30 -a "type=x300,master_clock_rate=184.32e6"
Thanks Michael, Marcus
I will try to stream video over from eNodeB to UE simulator app.
Thanks again,
Ishwar
From: Michael West [mailto:[email protected]]
Sent: Monday, June 20, 2016 4:02 PM
To: Jasuja, Ishwar
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [USRP-users] X300: master clock & sampling rate (eNodeb simulator
from srsLTE)
Hi Ishwar,
I am not familiar with the srsLTE software. What I can tell you is that you
will see that warning if the sample rate is set before the master clock rate is
set. Be sure the master clock rate is set first.
Also, if you have the devices directly cabled to each other, you should add an
attenuator (30 dB) to make sure you don't damage the LNAs. With the attenuator
in place, you can put the TX gain to maximum and adjust the RX gain as needed.
The gain range depends on which type of daughterboard you are using. Run
'uhd_usrp_probe' to see the gain ranges for the daughterboards you are using.
Regards,
Michael
On Mon, Jun 20, 2016 at 3:19 PM, Jasuja, Ishwar via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi,
I am trying to run pdsch_enodeb (srsLTE?s example app) on X300 hardware.
I am seeing following warning message:
UHD Warning:
The hardware does not support the requested TX sample rate:
Target sample rate: 1.920000 MSps
Actual sample rate: 1.923077 MSps
I have set the master clock to 184.32 MHz. (master clocking rate in this case
is even multiple of sampling rate)
The example app does not seem to like this and it exits.
Am I doing something wrong?
For now, I have commented out the code that terminates the app. I am hoping
that kind of sampling error should not cause problem on receive side (esp when
the signal is BPSK/QPSK modulated)
What should the tx_gain/rx_gain be set to if I have connected Antenna to both
X300 boxes; One running enodeB simulator example app and another running UE
simulator example app.
Thanks,
Ishwar
Spirent Communications e-mail confidentiality.
------------------------------------------------------------------------
This e-mail contains confidential and / or privileged information belonging to
Spirent Communications plc, its affiliates and / or subsidiaries. If you are
not the intended recipient, you are hereby notified that any disclosure,
copying, distribution and / or the taking of any action based upon reliance on
the contents of this transmission is strictly forbidden. If you have received
this message in error please notify the sender by return e-mail and delete it
from your system.
Spirent Communications plc
Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN, United Kingdom.
Tel No. +44 (0) 1293 767676<tel:%2B44%20%280%29%201293%20767676>
Fax No. +44 (0) 1293 767677<tel:%2B44%20%280%29%201293%20767677>
Registered in England Number 470893
Registered at Northwood Park, Gatwick Road, Crawley, West Sussex, RH10 9XN,
United Kingdom.
Or if within the US,
Spirent Communications,
27349 Agoura Road, Calabasas, CA, 91301, USA.
Tel No. 1-818-676- 2300<tel:1-818-676-%202300>
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/cf76f564/attachment-0001.html>
------------------------------
Message: 26
Date: Mon, 20 Jun 2016 21:03:28 -0400
From: Damindra Bandara <[email protected]>
To: Steven Knudsen <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Error when switching between QPSK and BPSK
modulations
Message-ID:
<canpcen9npcw3dylp2eaeuulevlhs-az6dc8u66+6uyforz-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Steven,
Thank you very much for your response.
I think you are correct. It is a GNURadio problem. I have to dig more to
find what the reason is.
Best regards,
Damindra
On Mon, Jun 20, 2016 at 6:12 PM, Steven Knudsen <[email protected]> wrote:
> Hi Damindra,
>
> I am no expert, but it appears this is not a USRP issue, but rather one
> from GR. Might i suggest you debug using a flowgraph that does not employ
> the USRP block? I am guessing that you may see the same error.
>
> You may be able to use the tag and message debugging blocks to trace
> things.
>
> Another guess is that is that you have a bit of race condition, perhaps
> when the number of bits per symbol is changed (though I don?t see the
> relationship between 13525 and 8191 right away). That is, the resampler
> ratio appears to be changed before a source block is changed to produce the
> required number of samples. Hard to say more without the flowgraph in hand.
>
> good luck,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
>
> www.linkedin.com/in/knudstevenknudsen
>
>
> All the wires are cut, my friends
> Live beyond the severed ends. Louis MacNeice
>
> On Jun 20, 2016, at 14:38, Damindra Bandara via USRP-users <
> [email protected]> wrote:
>
> Hi,
>
> I am developing an application which changes between the QPSK and BPSK
> modulations based on the signal level. My transmitter path is set as
> follows.
>
> File source --> Packet Encoder --> Constellation modulator --.> USRP
> sink.
>
> Initially, the constellation of the 'Constellation modulator' is set to a
> QPSK Constellation Rect. Object. To change the modulation to BPSK I change
> the Constellation Rect. Object to BPSK.
> Everything works fine for the change from QPSK to BPSK. But when I try to
> change back to QPSK from BPSK I get the following error.
>
> sched: <block pfb_arb_resampler_ccf (12)> is requesting more input data
> than we can provide.
> ninput_items_required = 13525
> max_possible_items_available = 8191
> If this is a filter, consider reducing the number of taps.
>
> I appreciate if you could help me to solve this problem.
>
> Thank you
> Damindra
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/39ffb8a2/attachment-0001.html>
------------------------------
Message: 27
Date: Mon, 20 Jun 2016 18:08:09 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Error when switching between QPSK and BPSK
modulations
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Damindra,
while you're welcome to ask your questions here, this particular
question might be a better one to ask on the discuss-gnuradio mailing
list, as you'll find more people able to answer your question.
Cheers,
M
On 06/20/2016 06:03 PM, Damindra Bandara via USRP-users wrote:
> Hi Steven,
>
> Thank you very much for your response.
>
> I think you are correct. It is a GNURadio problem. I have to dig more to
> find what the reason is.
>
> Best regards,
> Damindra
>
>
>
>
> On Mon, Jun 20, 2016 at 6:12 PM, Steven Knudsen <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Damindra,
>
> I am no expert, but it appears this is not a USRP issue, but rather
> one from GR. Might i suggest you debug using a flowgraph that does
> not employ the USRP block? I am guessing that you may see the same
> error.
>
> You may be able to use the tag and message debugging blocks to trace
> things.
>
> Another guess is that is that you have a bit of race condition,
> perhaps when the number of bits per symbol is changed (though I
> don?t see the relationship between 13525 and 8191 right away). That
> is, the resampler ratio appears to be changed before a source block
> is changed to produce the required number of samples. Hard to say
> more without the flowgraph in hand.
>
> good luck,
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
>
> All the wires are cut, my friends
> Live beyond the severed ends. Louis MacNeice
>
>
>> On Jun 20, 2016, at 14:38, Damindra Bandara via USRP-users
>> <[email protected] <mailto:[email protected]>>
>> wrote:
>>
>> Hi,
>>
>> I am developing an application which changes between the QPSK and
>> BPSK modulations based on the signal level. My transmitter path is
>> set as follows.
>>
>> File source --> Packet Encoder --> Constellation modulator --.>
>> USRP sink.
>>
>> Initially, the constellation of the 'Constellation modulator' is
>> set to a QPSK Constellation Rect. Object. To change the
>> modulation to BPSK I change the Constellation Rect. Object to BPSK.
>> Everything works fine for the change from QPSK to BPSK. But when I
>> try to change back to QPSK from BPSK I get the following error.
>>
>> sched: <block pfb_arb_resampler_ccf (12)> is requesting more input
>> data
>> than we can provide.
>> ninput_items_required = 13525
>> max_possible_items_available = 8191
>> If this is a filter, consider reducing the number of taps.
>>
>> I appreciate if you could help me to solve this problem.
>>
>> Thank you
>> Damindra
>>
>> --
>> Damindra Savithri Bandara,
>> Ph.D. in Information Technology (Candidate)
>> George Mason University,
>> Fairfax,
>> Virginia
>> _______________________________________________
>> USRP-users mailing list
>> [email protected] <mailto:[email protected]>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> --
> Damindra Savithri Bandara,
> Ph.D. in Information Technology (Candidate)
> George Mason University,
> Fairfax,
> Virginia
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 28
Date: Mon, 20 Jun 2016 21:15:59 -0400
From: Damindra Bandara <[email protected]>
To: Martin Braun <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Error when switching between QPSK and BPSK
modulations
Message-ID:
<CANpceN9i+C1tugVyvFwCA+k0_DWpbF=5uswb8=y4f1k1eye...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Martin, I will do it.
On Mon, Jun 20, 2016 at 9:08 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> Damindra,
>
> while you're welcome to ask your questions here, this particular
> question might be a better one to ask on the discuss-gnuradio mailing
> list, as you'll find more people able to answer your question.
>
> Cheers,
> M
>
> On 06/20/2016 06:03 PM, Damindra Bandara via USRP-users wrote:
> > Hi Steven,
> >
> > Thank you very much for your response.
> >
> > I think you are correct. It is a GNURadio problem. I have to dig more to
> > find what the reason is.
> >
> > Best regards,
> > Damindra
> >
> >
> >
> >
> > On Mon, Jun 20, 2016 at 6:12 PM, Steven Knudsen <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Hi Damindra,
> >
> > I am no expert, but it appears this is not a USRP issue, but rather
> > one from GR. Might i suggest you debug using a flowgraph that does
> > not employ the USRP block? I am guessing that you may see the same
> > error.
> >
> > You may be able to use the tag and message debugging blocks to trace
> > things.
> >
> > Another guess is that is that you have a bit of race condition,
> > perhaps when the number of bits per symbol is changed (though I
> > don?t see the relationship between 13525 and 8191 right away). That
> > is, the resampler ratio appears to be changed before a source block
> > is changed to produce the required number of samples. Hard to say
> > more without the flowgraph in hand.
> >
> > good luck,
> >
> > steven
> >
> >
> > Steven Knudsen, Ph.D., P.Eng.
> > www. techconficio.ca <http://techconficio.ca>
> >
> > www.linkedin.com/in/knudstevenknudsen
> > <http://www.linkedin.com/in/knudstevenknudsen>
> >
> >
> > All the wires are cut, my friends
> > Live beyond the severed ends. Louis MacNeice
> >
> >
> >> On Jun 20, 2016, at 14:38, Damindra Bandara via USRP-users
> >> <[email protected] <mailto:[email protected]>>
> >> wrote:
> >>
> >> Hi,
> >>
> >> I am developing an application which changes between the QPSK and
> >> BPSK modulations based on the signal level. My transmitter path is
> >> set as follows.
> >>
> >> File source --> Packet Encoder --> Constellation modulator --.>
> >> USRP sink.
> >>
> >> Initially, the constellation of the 'Constellation modulator' is
> >> set to a QPSK Constellation Rect. Object. To change the
> >> modulation to BPSK I change the Constellation Rect. Object to BPSK.
> >> Everything works fine for the change from QPSK to BPSK. But when I
> >> try to change back to QPSK from BPSK I get the following error.
> >>
> >> sched: <block pfb_arb_resampler_ccf (12)> is requesting more input
> >> data
> >> than we can provide.
> >> ninput_items_required = 13525
> >> max_possible_items_available = 8191
> >> If this is a filter, consider reducing the number of taps.
> >>
> >> I appreciate if you could help me to solve this problem.
> >>
> >> Thank you
> >> Damindra
> >>
> >> --
> >> Damindra Savithri Bandara,
> >> Ph.D. in Information Technology (Candidate)
> >> George Mason University,
> >> Fairfax,
> >> Virginia
> >> _______________________________________________
> >> USRP-users mailing list
> >> [email protected] <mailto:[email protected]>
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > --
> > Damindra Savithri Bandara,
> > Ph.D. in Information Technology (Candidate)
> > George Mason University,
> > Fairfax,
> > Virginia
> >
> >
> > _______________________________________________
> > 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
>
--
Damindra Savithri Bandara,
Ph.D. in Information Technology (Candidate)
George Mason University,
Fairfax,
Virginia
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160620/562f66ba/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 21 Jun 2016 01:22:13 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] AXI_FIR encrypted IP in Modelsim protected mode
when running noc_block_fir_filter from my own cocotb testbench
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon,
I was hoping you might help me figure this out since it really has me stumped.
I have created a testbench using cocotb with python, and it really works well
with several of your noc_blocks, BUT with the exception if they are using any
encrypted IP such as axi_fir in noc_block_fir_filter_tb. I have gotten around
a lot of issues but this one has me out of ideas. When I run Modelsim, I get
the following error:
Loading ieee.std_logic_textio(body)
# Loading ieee.math_real(body)
# ** Fatal: (vsim-7) Failed to open <protected> file "<protected>" in
<protected> mode.
# No such file or directory. (errno = ENOENT)
# Time: 0 ps Iteration: 0 Protected:
/noc_block_Receiver/inst_axi_fir/<protected>/<protected>/<protected>/<protected>
File:
/home/craig/cocotb/examples/noc_block_Receiver/modelsim_proj/modelsim_proj.ip_user_files/ipstatic/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
Line: UNKNOWN
# FATAL ERROR while loading design
# Error loading design?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/5ff2d571/attachment-0001.html>
------------------------------
Message: 30
Date: Tue, 21 Jun 2016 00:35:21 -0700
From: Ian Buckley <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected
mode when running noc_block_fir_filter from my own cocotb testbench
Message-ID:
<cam_0ochm2whfnxbyc895z-92v1mdugc+qs7rrowbmb8kcgj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Craig, This may help
http://www.xilinx.com/support/answers/32936.html
-Ian
On Mon, Jun 20, 2016 at 6:22 PM, Swanson, Craig via USRP-users <
[email protected]> wrote:
> Jonathon,
>
> I was hoping you might help me figure this out since it really has me
> stumped. I have created a testbench using cocotb with python, and it
> really works well with several of your noc_blocks, BUT with the exception
> if they are using any encrypted IP such as axi_fir in
> noc_block_fir_filter_tb. I have gotten around a lot of issues but this one
> has me out of ideas. When I run Modelsim, I get the following error:
>
>
> Loading ieee.std_logic_textio(body)
> # Loading ieee.math_real(body)
> # ** Fatal: (vsim-7) Failed to open <protected> file "<protected>" in
> <protected> mode.
> # No such file or directory. (errno = ENOENT)
> # Time: 0 ps Iteration: 0 Protected:
> /noc_block_Receiver/inst_axi_fir/<protected>/<protected>/<protected>/<protected>
> File:
> /home/craig/cocotb/examples/noc_block_Receiver/modelsim_proj/modelsim_proj.ip_user_files/ipstatic/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
> Line: UNKNOWN
> # FATAL ERROR while loading design
> # Error loading design?
>
>
> Craig
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/cfdeac69/attachment-0001.html>
------------------------------
Message: 31
Date: Tue, 21 Jun 2016 07:56:06 +0000
From: "Swanson, Craig" <[email protected]>
To: Ian Buckley <[email protected]>
Cc: Jonathon Pendlum <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected
mode when running noc_block_fir_filter from my own cocotb testbench
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
?Ian,
Thanks but I already have the -L secureip option in my vsim command and it is
still giving me the <protected> error.
It seems that I cannot simulate an encrypted file outside of the uhd/fpga-src
directory. I cannot figure out what environment settings Jonathon has that
only allow me to run a Xilinx IP within the /lib/rfnoc/noc_block_fir_filter_tb
directory. I think he told me at one time that Modelsim will not simulate
encrypted IP unless it is running within Vivado. I don't think I am running
cocotb within Vivado, but I am using the source setupenv.sh environment.
>From what I am reading, the best solution is to run /top/x300/make
>X310_RFNOC_HGS GUI=1, and then save the project file, and then within
>synthesis create a .vhd or . file. Then run a post-synthesis .vhd or .v
>version of the IP that is not encrypted. This is what I am trying right now.
I am using cocotb to run a python script to simulate my noc_block_Receiver.v
(customized noc_block_skeleton.v in rfnoc-radio-redo branch).
The reason for running cocotb instead of Jonathon's testbench environment is
that I am running a uhd file sink data file through my noc_block_Receiver.
I would love to do this in Jonathon's testbench but modifying his system
verilog testbench seems very, very difficult. He is an amazing code writer but
understanding what he is doing is very challenging and then modifying it seems
to be next to impossible for a novice system verilog coder like myself.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Ian Buckley <[email protected]>
Sent: Tuesday, June 21, 2016 3:35 AM
To: Swanson, Craig
Cc: Jonathon Pendlum; [email protected]
Subject: Re: [USRP-users] AXI_FIR encrypted IP in Modelsim protected mode when
running noc_block_fir_filter from my own cocotb testbench
Craig, This may help
http://www.xilinx.com/support/answers/32936.html
-Ian
On Mon, Jun 20, 2016 at 6:22 PM, Swanson, Craig via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
I was hoping you might help me figure this out since it really has me stumped.
I have created a testbench using cocotb with python, and it really works well
with several of your noc_blocks, BUT with the exception if they are using any
encrypted IP such as axi_fir in noc_block_fir_filter_tb. I have gotten around
a lot of issues but this one has me out of ideas. When I run Modelsim, I get
the following error:
Loading ieee.std_logic_textio(body)
# Loading ieee.math_real(body)
# ** Fatal: (vsim-7) Failed to open <protected> file "<protected>" in
<protected> mode.
# No such file or directory. (errno = ENOENT)
# Time: 0 ps Iteration: 0 Protected:
/noc_block_Receiver/inst_axi_fir/<protected>/<protected>/<protected>/<protected>
File:
/home/craig/cocotb/examples/noc_block_Receiver/modelsim_proj/modelsim_proj.ip_user_files/ipstatic/fir_compiler_v7_2_5/hdl/fir_compiler_v7_2_vh_rfs.vhd
Line: UNKNOWN
# FATAL ERROR while loading design
# Error loading design?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/6afa00c7/attachment-0001.html>
------------------------------
Message: 32
Date: Tue, 21 Jun 2016 10:01:58 +0200
From: Claudio Cicconetti <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] GPSDO as stand-alone component
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Dear all,
I have tried to power up a GPSDO and looked for a 10 MHz signal output:
unfortunately there was none :(
I assume some initialization is needed over the serial interface using
SCPI commands.
I looked to the code in gps_ctrl.cpp and the initialization sequence
seems quite straightforward, with the following commands issued in an
open loop:
_send("SYST:COMM:SER:ECHO OFF\n");
_send("SYST:COMM:SER:PRO OFF\n");
_send("GPS:GPGGA 1\n");
_send("GPS:GGAST 0\n");
_send("GPS:GPRMC 1\n");
_send("SERV:TRAC 0\n");
Does anybody know whether this is sufficient to have the GPSDO produce
10 MHz reference signal from GPS?
Best regards,
Claudio
On 06/15/2016 06:27 PM, Steven Knudsen wrote:
> Being lazy, and since my Octoclock-G is already connected to a scope for
> triggering, I measured the 1 PPS pulse to be 200 ms wide and 2.82 V pk-pk.
> You can easily find GPS chips or modules that will output that level, but I
> am not sure about pulse width. I suspect that as long as the pulse width is
> on the order of 200 us or more, the B200mini will be fine. If you are not
> super fussy about pulse edge degradation, then a 555-based one-shot will make
> the pulse from the GPS module as long as you want.
>
> Obviously, it?s worth consulting the schematic where is says the 1 PPS max is
> -5 / +5 V and min is 0 / 2.5 V and the SN75AUP1T57 is used to buffer
> the signal for FPGA input.
>
> Hope that helps.
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
> www.linkedin.com/in/knudstevenknudsen
>
> Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
> Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
> nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
>
>> On Jun 15, 2016, at 08:32, Claudio Cicconetti via USRP-users
>> <[email protected]> wrote:
>>
>> Dear All,
>> The B200mini does not support any board-mount GPSDO.
>>
>> I am wondering: would it be possible to operate one of the different
>> Ettus GPSDO devices as a stand-alone GPS-disciplined 10 MHz reference
>> clock generator by providing only the external power (+ GPS antenna of
>> course)?
>>
>> Disclaimer: I known a better and more straightforward alternative in the
>> Ettus catalogue would be the OctoClock-G, but the latter does not fit my
>> SWaP constraints.
>>
>> Best regards,
>> Claudio
>>
>> --
>> Claudio Cicconetti, PhD
>> Software Engineer - MBI S.r.l. - Pisa, Italy
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
------------------------------
Message: 33
Date: Tue, 21 Jun 2016 10:26:43 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 AD9361 FIR filter Taps
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Jeffrey, hi Ian,
the API for that is filter_info; it seems pretty stable by now. I think
I have some example for its usage lying around, just don't know where
exactly right now.
Anyway, from a usage perspective, not that much magic involved; use
multi_usrp::get_filter_names() to get the filters that exist for your
USRP, and
::get_filter(name) to get the filter_info object that describes that filter.
Best regards,
Marcus
On 06/20/2016 08:26 PM, Ian Buckley via USRP-users wrote:
> Jeff,
> The way the programmable FIR works in 9361 is that the H/W implements
> 16taps of filter and runs on the data converter clock which is a
> multiple of the sample clock set by the various
> interpolation/decimation stages. Thus the ratio of the converter clock
> to sample clock dictates how many taps can be implemented in the RX
> and TX FIR's. The Ettus driver decides what that ratio is based on the
> maximum operating frequencies for the ADC and DAC, and the the
> master_clock_rate requested by the user. The driver thus provides
> filter taps for all possible legal configuration scenarios. If you
> have a certain configuration that you are targeting then work out what
> the resulting ratio is and hence which coefficient set is being picked
> (via code debug), then, yes, replace with your own coefficients...it
> really can be that simple. Remember those FIR filters can run as 1/2/4
> interpolator/decimators and the stock Ettus driver is factoring that
> into its distribution of interpolation/decimation amongst the various
> filters present in the radio when it chooses a configuraton. If you
> want to change the mode it wants to run the FIR in then your edits
> will need to be more intrusive since I don't recall any way you can
> use the API to do that.
> -Ian
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/6699e6ee/attachment-0001.html>
------------------------------
Message: 34
Date: Tue, 21 Jun 2016 11:29:45 -0400
From: avinash kalyanaraman <[email protected]>
To: [email protected]
Subject: [USRP-users] Regarding time aligned samples of a MIMO
configuration
Message-ID:
<cajpbu_gzubqvtgtfykutvmybsfqclbdn2pamgu-e56wtkyt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello All,
Is there a way I can read the time-aligned samples from 2 USRP N210s
connected via a MIMO cable ?
In other words, I want to be able to run the equivalent of uhd_rx_cfile but
store the time aligned complex samples of both USRPs?
Will simply connecting the two USRP Sources to FileSinks in GRC (as
attached) do this for me - for e.g. then, will the Nth sample in file1 and
Nth sample in file2 be time-aligned samples of the two USRPs?
Thanks!
--
Avinash
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/b0653f64/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mimo_test.png
Type: image/png
Size: 265230 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160621/b0653f64/attachment-0001.png>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 70, Issue 22
******************************************
