Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
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
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: Example code for a pair of TwinRXs (d.des)
2. Re: Cannot remove X310 image (David Miller)
3. Re: Example code for a pair of TwinRXs (Marcus D. Leech)
4. Re: Building UHD for USRP E310 Without Radio (Martin Braun)
5. Re: best way to avoid dropped samples (Garver, Paul W)
6. Re: Cannot remove X310 image (Paul David)
7. Re: B200mini and low-freq modulation of tx'd signal (Martin Braun)
8. Re: error Hardware too new for software in USRP RIO (Martin Braun)
9. Re: B200mini and low-freq modulation of tx'd signal
(Steven Knudsen)
10. Fwd: Example code for a pair of TwinRXs (ti...@comcast.net)
11. Re: Example code for a pair of TwinRXs (d.des)
12. Re: N210 'benchmark_rate' interpretation in a Docker
container (Martin Braun)
13. How to periodically re-output CVITA time tag (EJ Kreinar)
14. Re: Example code for a pair of TwinRXs (Derek Kozel)
15. Re: How to periodically re-output CVITA time tag (Martin Braun)
16. RFNoC without a Radio Core (Walter Maguire)
17. Re: RFNoC without a Radio Core (Marcus D. Leech)
18. Volk / UHD / GR on macOS 10.12 Sierra (Michael Dickens)
19. Re: UBX-160 Performance < 500 MHz (Perelman, Nathan)
----------------------------------------------------------------------
Message: 1
Date: Wed, 21 Sep 2016 16:15:48 +0000
From: "d.des" <d....@sbcglobal.net>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <1474474548.4934.11.ca...@sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
Well I've got some more information on why uhd is not returning from
recv. ?I looked at the recorded data that I got when I set the rate
using timed commands as in:
uhd::time_spec_t cmd_time = usrp->get_time_now() +
uhd::time_spec_t(0.1);
usrp->set_command_time(cmd_time);
for(int nChan=0;nChan<nChans;++nChan) {
? usrp->set_rx_rate(4.e6, nChan);
}
usrp->clear_command_time();
get_rx_rate returns the 4 MHz value I set but the radio seems to sample
at 100000 Hz instead. ?It wasn't timing out, it was just taking ten
seconds to return the million samples that I was requesting. ?If I use
non-timed commands the rate gets set correctly and it runs fine except
that the last two channels are out of time sync with the first two.
?Timed commands seem to work fine with frequency and gain setting. ?I
can even get it to run at the correct rate by first using non-timed
commands to set rate and then re-setting them using timed commands.
?The time sync is still off, though so the system is not usabe as is.
I'm using uhd_003.011.000 pulled from git about a week ago. ?I also
tried UHD_003.010.000.000-61-g23cd2754 from the maint branch (but still
using the same firmware as before -- I think I heard that I need
different firmware but don't know where to get it...)
You guys had a working configuration last week for the MUSIC demo,
right? ?Could you please make it available?
------------------------------
Message: 2
Date: Wed, 21 Sep 2016 16:22:26 +0100
From: David Miller <david.zod.mil...@gmail.com>
To: Paul David <paul.da...@ettus.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID: <96c16bc4-22c0-e363-fe7d-6b374296e...@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Thanks Paul,
I was able to get access to a machine with Vivado today and used the
Hardware Manager to program the latest bitfile. I'll update the flash
sometime later when I get UHD installed (the machine is RHEL5, too old
for UHD).
The viv_jtag_program utility was not there (does it also use the jtag
server?).
I was also surprised to see the XADC component/IP? on the FPGA. Is there
a way to access the environment data from it with a simple command line
utility?
Thanks again,
Dave
On 20/09/2016 19:07, Paul David wrote:
> Hi David,
>
> To answer your question: you do need Vivado in order to configure the
> FPGA over JTAG using the command: viv_jtag_program <bitfile path> .
>
> Or you can use the hardware manager in Vivado. After you do that,
> you'll need to use uhd_image_loader to burn the same FPGA image so
> that it persists after a power cycle.
>
> I would recommend upgrading UHD to a more recent tagged release as well.
>
> -- Paul
>
> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi,
>
> I have acquired an X310 with an image based on the original uhd
> 3.8.2 image, not sure what it does but doing a uhd_usrp_probe with
> uhd 3.8.2 it works as expected, however no samples are emitted
> with the utilities, it's hosed!
>
> Anyways, I have tried the 3.8.2 burn program
> (usrp_x3xx_fpga_burner) which fails, and currently tried the 3.9.4
> uhd_image_loader.
>
> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>
> Error: RunTimeError: Device reported an error during initialization.
>
> I hacked the code in the x310_send_and_receive() function,
> somewhere in the code, to see if there is any kind of status
> message generated that might help, the recv function returns a len
> of 4 (0 being a timeout), which fails a subsequent check function
> that masks this len value (with 0x04, or whatever the def is) to
> determine that this is a failure. Sorry to be a bit vague, I don't
> have the setup in front of me at the moment.
>
> So, the real question is: How do I recover the unit and burn back
> a working image, is it now only possible using Vivado/ISE/JTAG?
>
> Hope you can help?
>
> Thanks,
> Dave
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> 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/20160921/3d10f419/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 21 Sep 2016 12:23:23 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <57e2b3fb.3070...@ripnet.com>
Content-Type: text/plain; charset=utf-8; format=flowed
On 09/21/2016 12:15 PM, d.des via USRP-users wrote:
> Well I've got some more information on why uhd is not returning from
> recv. I looked at the recorded data that I got when I set the rate
> using timed commands as in:
>
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
>
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_rate(4.e6, nChan);
> }
> usrp->clear_command_time();
Timed commands are largely designed for daughterboard commands, and
setting the sample rate isn't a daughterboard command.
Further, setting sample-rate doesn't need to be made precisely
synchronous, neither, strictly-speaking, does gain.
The only part of it where timed-commands are crucial is in tuning, where
the timed-commands will arrange for phase-syncrhonization.
>
> get_rx_rate returns the 4 MHz value I set but the radio seems to sample
> at 100000 Hz instead. It wasn't timing out, it was just taking ten
> seconds to return the million samples that I was requesting. If I use
> non-timed commands the rate gets set correctly and it runs fine except
> that the last two channels are out of time sync with the first two.
> Timed commands seem to work fine with frequency and gain setting. I
> can even get it to run at the correct rate by first using non-timed
> commands to set rate and then re-setting them using timed commands.
> The time sync is still off, though so the system is not usabe as is.
>
> I'm using uhd_003.011.000 pulled from git about a week ago. I also
> tried UHD_003.010.000.000-61-g23cd2754 from the maint branch (but still
> using the same firmware as before -- I think I heard that I need
> different firmware but don't know where to get it...)
>
> You guys had a working configuration last week for the MUSIC demo,
> right? Could you please make it available?
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Wed, 21 Sep 2016 09:45:38 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Building UHD for USRP E310 Without Radio
Message-ID: <f2e6cb27-3957-4b60-9a41-1615bbbc3...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 09/19/2016 10:01 PM, Walter Maguire via USRP-users wrote:
> I have been using the latest UHD rfnoc-devel release with the associated
> uhd-fpga source. Having studied the FPGA design and UHD library
> software it appears to me that the Radio Core is not treated like a
> standard CE. It looks like the E3xx UHD driver always expects the Radio
> to be present as per the checks to control the associated AD9361 part.
> If the CE approach was fully adopted for the radio block then I would
> assume that not building the radio block in the FPGA would result in the
> enumeration of the RFNoC bus not finding the radio block with its
> associated block id. Therefore the associated configuration of the
> related AD9361 would not be run.
Walter,
the radio blocks are not special in an RFNoC sense (they are only
differently connected in the FPGA, as they have more I/Os than other
blocks).
If you have no radios, you will see a warning ("No Radio Block found.
Assuming radio-less operation."), but it's really not a critical warning.
> I would be grateful if someone would clarify that in order for the UHD
> device driver to work with RFNoC that the associated radio block needs
> to be present in the FPGA design. If this is case, are there any plans
> to make the Radio block control and implementation to be the same as a
> standard CE, such that if it is not present the driver still works.
As said before, radios are regular blocks, and taking them out will not
break anything. The AD9361 will not be activated in that case, either.
Martin
------------------------------
Message: 5
Date: Wed, 21 Sep 2016 16:47:08 +0000
From: "Garver, Paul W" <garv...@gatech.edu>
To: "mredfi...@m42tech.com" <mredfi...@m42tech.com>,
"listera...@gmail.com" <listera...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] best way to avoid dropped samples
Message-ID: <70fcd40f-4d80-4ccc-b22d-049200e60...@gatech.edu>
Content-Type: text/plain; charset="utf-8"
Glad to hear specrec is working well for you, Anon! Also, that data point is
useful about your particular record speeds between uhd_rx_cfile and specrec.
That aligns with our results that specrec is about 2x faster than uhd_rx_cfile.
Some other folks have discussed a ramdisk-based solution to this problem as
well. I can?t remember but I think it is on the discuss-gnuradio mailing list.
That?s a valid approach too, but I will echo that specrec doesn?t require any
OS-level configuration.
In my experience with recording samples to disk, you really can?t trust the
vendor provided write speeds for real time streaming. I think the continuous
write over 10s of seconds, minutes, even hours is much more challenging on the
SSD than the typical bursty load.
Honestly, with any decent SSD and PC, you should not have any trouble recording
1 MSPS using sc16. That?s only 4MBytes/sec.
PWG
From: Anon Lister <listera...@gmail.com<mailto:listera...@gmail.com>>
Subject: Re: [USRP-users] best way to avoid dropped samples
Date: September 21, 2016 at 1:56:52 AM EDT
To: Morgan Redfield <mredfi...@m42tech.com<mailto:mredfi...@m42tech.com>>
Cc: "usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>"
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
Have you seen this[1] 2015 GRCon presentation? They go over their tool,
specrec[2], which basically uses synchronous writes to stream data to disk to
avoid writing a big buffer from memory to disk at once.
I've has very good luck with it as opposed to the rx_cfile example app. With rx
cfile I can do 20Meg sample rate saves with very infrequent dropped samples.
With specrec, I can do 50Meg sample rate captures with no samples dropped for
as long as I've tried on my laptop.
Could be something to try before you go tweaking your OS (even if you could
achieve a similar result playing with OS buffer sizes.)
[1] http://www.trondeau.com/s/5-lincoln_orin-gr_analysis-2015-08-26.pdf
[2] https://github.com/garverp/gr-analysis
On Sep 20, 2016 9:00 PM, "Morgan Redfield via USRP-users"
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote:
I just tested the write performance of my filesystem, and I got sequential
write speeds of 434MB/s.
After that I tried uhd_rx_cfile for a 10min collect, and I did get one 'O'
during that collection. We based our rx script on the uhd_rx_cfile and just
added some switches for timed receive, so I'm not surprised we're getting the
same behavior with the original.
Are the write-behind configurations related to these?
/proc/sys/vm/dirty_ratio
/proc/sys/vm/dirty_background_ratio
Do you have a suggestion for where they should be set?
On Tue, Sep 20, 2016 at 5:01 PM, Marcus D. Leech
<mle...@ripnet.com<mailto:mle...@ripnet.com>> wrote:
On 09/20/2016 07:54 PM, Morgan Redfield wrote:
There's no VM.
I realize that it's always VRT over USB, but I'm curious why we only get VRT
errors if we use sc12, and not if we use sc16.
That may just be because of the way SC12 are packed on the wire, with a dropped
frame "slicing" one of these down the middle.
Is there a standard way of optimizing linux to run with an SSD for gnuradio or
the USRP?
Have you tried uhd_rx_cfile, instead of your own flow-graph?
There's a write-behind cache configuration item for the kernel that controls
how much of main memory gets used for the disk
write-behind cache. If this cache is large, it might take quite a while for
it to flush it to disk all in one gulp, thus causing
some scheduling difficulties. I just can't off the top of my head remember
what it's called :(
Have you actually tested the write performance of your filesystem outside of
gnu radio?
On Tue, Sep 20, 2016 at 4:09 PM, Marcus D. Leech
<mle...@ripnet.com<mailto:mle...@ripnet.com>> wrote:
On 09/20/2016 06:42 PM, Morgan Redfield via USRP-users wrote:
We're using a USRP B200 to collect data for post processing. Our flowgraph is
just a USRP source connected to a filesink. We're using a 1MHz sample rate.
Ultimately, we'd like to be able to record data for 15 to 20 minutes with no
dropped samples.
Every once in a while, we see data overruns ('O's appear in the terminal when
we're sampling). To avoid this, we attempted to use sc12 for the otw format in
order to reduce the length of data being sent from the USRP.
When I have otw_format set to 'sc12', then I get this error after some time
recording:
UHD Error:
The receive packet handler caught a value exception.
ValueError: bad vrt header or packet fragment
WARN: USRP Source Block caught rx error code: 15
DO
So it looks like there's an overflow and a dropped packet.
So I have two questions:
1. What's the best way to avoid dropping samples?
2. Why are we getting VRT packet errors if we use 'sc12' as the OTW format?
VRT == Vita49 Radio Transport --- those headers are present regardless of the
wire format.
With 1Msps, you shouldn't ever be experiencing overruns. My guess is that your
SSD doesn't actually perform at its rated speed.
Also, are you running this on a real, or VM setup?
Thanks for any help you can give,
Morgan
System details:
USRP B200 connected over USB3.0
Computer:
- SSD with 458MB/sec sequential write speeds
- 16GB swap space
- 16GB RAM
- 3.8GHz Intel I7 processor
- Ubuntu 16.04
- GNURadio version 3.7.10.1
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com<mailto: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/20160921/ddad52a6/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 21 Sep 2016 09:50:56 -0700
From: Paul David <paul.da...@ettus.com>
To: David Miller <david.zod.mil...@gmail.com>
Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Cannot remove X310 image
Message-ID:
<cacjvjtwsgzp8esufcodfcofccpylkt4kezwdm7e3tfawmve...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi David,
You should be able to tab complete viv_jtag_program once you run the
following:
source <path to uhd/fpga-src>/usrp3_rfnoc/top/x300/setupenv.sh
Assuming you're on the latest 3.10.0 release. That will load all the
environment variables/data.
-- Paul
On Wed, Sep 21, 2016 at 8:22 AM, David Miller <david.zod.mil...@gmail.com>
wrote:
> Thanks Paul,
> I was able to get access to a machine with Vivado today and used the
> Hardware Manager to program the latest bitfile. I'll update the flash
> sometime later when I get UHD installed (the machine is RHEL5, too old for
> UHD).
> The viv_jtag_program utility was not there (does it also use the jtag
> server?).
> I was also surprised to see the XADC component/IP? on the FPGA. Is there
> a way to access the environment data from it with a simple command line
> utility?
> Thanks again,
> Dave
>
>
>
> On 20/09/2016 19:07, Paul David wrote:
>
> Hi David,
>
> To answer your question: you do need Vivado in order to configure the FPGA
> over JTAG using the command: viv_jtag_program <bitfile path> .
>
> Or you can use the hardware manager in Vivado. After you do that, you'll
> need to use uhd_image_loader to burn the same FPGA image so that it
> persists after a power cycle.
>
> I would recommend upgrading UHD to a more recent tagged release as well.
>
> -- Paul
>
> On Tue, Sep 20, 2016 at 9:08 AM, David Miller via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I have acquired an X310 with an image based on the original uhd 3.8.2
>> image, not sure what it does but doing a uhd_usrp_probe with uhd 3.8.2 it
>> works as expected, however no samples are emitted with the utilities, it's
>> hosed!
>>
>> Anyways, I have tried the 3.8.2 burn program (usrp_x3xx_fpga_burner)
>> which fails, and currently tried the 3.9.4 uhd_image_loader.
>>
>> uhd_image_loader fails (and similarly usrp_x3xx_fpga_burner) with:
>>
>> Error: RunTimeError: Device reported an error during initialization.
>>
>> I hacked the code in the x310_send_and_receive() function, somewhere in
>> the code, to see if there is any kind of status message generated that
>> might help, the recv function returns a len of 4 (0 being a timeout), which
>> fails a subsequent check function that masks this len value (with 0x04, or
>> whatever the def is) to determine that this is a failure. Sorry to be a bit
>> vague, I don't have the setup in front of me at the moment.
>>
>> So, the real question is: How do I recover the unit and burn back a
>> working image, is it now only possible using Vivado/ISE/JTAG?
>>
>> Hope you can help?
>>
>> Thanks,
>> Dave
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> 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/20160921/35e2df1d/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 21 Sep 2016 09:55:49 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] B200mini and low-freq modulation of tx'd
signal
Message-ID: <6347265c-d305-0a67-4fce-6799daf41...@ettus.com>
Content-Type: text/plain; charset=windows-1252
You will need to recover the carrier frequency at the receiver. For
small errors, you can simply use a PLL for this.
Cheers,
Martin
On 09/15/2016 10:54 AM, Steven Knudsen via USRP-users wrote:
> Ah, excellent. I believe you are correct. If I up the frequency, the
> period reduces, so I can see more of the imposed modulation.
>
> So, forgive my ignorance, but how does one correct this?
>
> thanks very much!
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt
> ist zu erreichen. - Franz Kafka/
>
>> On Sep 15, 2016, at 10:57, Torell, Kent <kent.tor...@gd-ms.com
>> <mailto:kent.tor...@gd-ms.com>> wrote:
>>
>> It?s a low frequency carrier error, so you are seeing the bpsk roll
>> into the other quadrature, then invert data.
>>
>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>> Behalf Of *Steven Knudsen via USRP-users
>> *Sent:* Thursday, September 15, 2016 9:50 AM
>> *To:* USRP-users
>> *Cc:* Knud
>> *Subject:* [USRP-users] B200mini and low-freq modulation of tx'd signal
>>
>> Hi,
>>
>> I have a TDMA flowgraph that defines packets using tx_time and tx_sob
>> + tx_eob. Packets are sent to a B200mini every 10 ms (which is not
>> important). Below I have the packet format from GRC followed by 3
>> oscilloscope captures that show the effect I?m seeing.
>>
>> The B200mini is connected to an Octoclock 1 PPS reference.
>>
>> The modulation is BPSK, 2x oversampled, RRC.
>>
>> Image 1 - the GRC waveform that is input to the USRP sink
>> Image 2 - this time the transmitted signal looks pretty good. Note the
>> leading zeros so that the transmit power rises to full before samples
>> are applied.
>> Image 3 - it appears that some form of slow modulation has been applied
>> Image 4 - same again, but obviously at a different offset
>>
>> (oops, forgot to turn off stupid network config menu in scope caps)
>>
>> I am a bit stumped. A ?theory? is that maybe I?m seeing a window of
>> some kind being convolved with the signal.
>>
>> <image001.png>
>>
>> <image002.jpg>
>>
>> <image003.jpg>
>>
>> <image004.jpg>
>>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca/>
>> www.linkedin.com/in/knudstevenknudsen
>> <http://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/
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Wed, 21 Sep 2016 10:02:01 -0700
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] error Hardware too new for software in USRP
RIO
Message-ID: <337b5058-2d3b-43f5-e226-b418bc575...@ettus.com>
Content-Type: text/plain; charset=windows-1252
You will also need to set the 'revision_compat' eeprom value. It looks
like your EEPROM content was somehow corrupted -- there's a sticker on
your motherboard with the serial number, and a letter at the end of that
-- can you tell us what that is?
Cheers,
Martin
On 09/09/2016 01:07 AM, Nikita Airee via USRP-users wrote:
> Hello everybody,
>
> I have only started working on my *USRP **NI 2953R* CBX, 40 MHz
> BW(connected via PCI express card)
>
> When I tried to run my flowgraphs, it showed an error that said unknown
> product code in EEPROM: 160. So I changed the code to 30513(0x7731)
> following the procedure mentioned here.
> <https://kb.ettus.com/About_the_Motherboard_and_Daughtercard_EEPROM_on_USRP_Devices#Restore_X300.2F310_EEPROM_Product_Code>
>
> But now when I run uhd_usrp_probe or even my flowgraph in gnuradio, it
> throws up the following error:
>
> *Error: RuntimeError: Hardware is too new for this software. Please
> upgrade to a driver that supports hardware revision 65308.*
>
> I have updated the UHD driver using the steps mentioned here
> <https://files.ettus.com/manual/page_install.html#install_linux>. But
> the error persists.I have also attached a shot of the command.
>
> //I'm only a novice when it comes to dealing with USRPs. Could you all
> help me with this?
>
> Nikita
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 9
Date: Wed, 21 Sep 2016 11:12:57 -0600
From: Steven Knudsen <ee.k...@gmail.com>
To: Martin Braun <martin.br...@ettus.com>
Cc: USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] B200mini and low-freq modulation of tx'd
signal
Message-ID: <b938cbcf-4765-4c22-b6c6-8bccb4065...@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Thanks for the response.
I was having an off day, seeing issues that I should have understood.
The Correlation Estimator Block works fine for my purposes, giving a phase_est
that I use to correct the frequency offset.
What I?m finding (and this should not be part of this list I know), is the
usual problem with a multi-radio, packet-based system. Many GNU Radio blocks
are meant to deal with non-idealities for stream-based transmissions from a
single transmitter. So, for example, the Polyphase Clock Sync tracking breaks
down in this circumstance. I should know better and am busy adding algorithms
that use my packet preamble to do various estimations and corrections.
Sorry to waste the ?list?s? time?
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 Sep 21, 2016, at 10:55, Martin Braun via USRP-users
> <usrp-users@lists.ettus.com> wrote:
>
> You will need to recover the carrier frequency at the receiver. For
> small errors, you can simply use a PLL for this.
>
> Cheers,
> Martin
>
> On 09/15/2016 10:54 AM, Steven Knudsen via USRP-users wrote:
>> Ah, excellent. I believe you are correct. If I up the frequency, the
>> period reduces, so I can see more of the imposed modulation.
>>
>> So, forgive my ignorance, but how does one correct this?
>>
>> thanks very much!
>>
>>
>> Steven Knudsen, Ph.D., P.Eng.
>> www. techconficio.ca <http://techconficio.ca/> <http://techconficio.ca
>> <http://techconficio.ca/>>
>> www.linkedin.com/in/knudstevenknudsen
>> <http://www.linkedin.com/in/knudstevenknudsen>
>> <http://www.linkedin.com/in/knudstevenknudsen
>> <http://www.linkedin.com/in/knudstevenknudsen>>
>>
>> /Von einem gewissen Punkt an gibt es keine R?ckkehr mehr. Dieser Punkt
>> ist zu erreichen. - Franz Kafka/
>>
>>> On Sep 15, 2016, at 10:57, Torell, Kent <kent.tor...@gd-ms.com
>>> <mailto:kent.tor...@gd-ms.com>
>>> <mailto:kent.tor...@gd-ms.com <mailto:kent.tor...@gd-ms.com>>> wrote:
>>>
>>> It?s a low frequency carrier error, so you are seeing the bpsk roll
>>> into the other quadrature, then invert data.
>>>
>>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>>> Behalf Of *Steven Knudsen via USRP-users
>>> *Sent:* Thursday, September 15, 2016 9:50 AM
>>> *To:* USRP-users
>>> *Cc:* Knud
>>> *Subject:* [USRP-users] B200mini and low-freq modulation of tx'd signal
>>>
>>> Hi,
>>>
>>> I have a TDMA flowgraph that defines packets using tx_time and tx_sob
>>> + tx_eob. Packets are sent to a B200mini every 10 ms (which is not
>>> important). Below I have the packet format from GRC followed by 3
>>> oscilloscope captures that show the effect I?m seeing.
>>>
>>> The B200mini is connected to an Octoclock 1 PPS reference.
>>>
>>> The modulation is BPSK, 2x oversampled, RRC.
>>>
>>> Image 1 - the GRC waveform that is input to the USRP sink
>>> Image 2 - this time the transmitted signal looks pretty good. Note the
>>> leading zeros so that the transmit power rises to full before samples
>>> are applied.
>>> Image 3 - it appears that some form of slow modulation has been applied
>>> Image 4 - same again, but obviously at a different offset
>>>
>>> (oops, forgot to turn off stupid network config menu in scope caps)
>>>
>>> I am a bit stumped. A ?theory? is that maybe I?m seeing a window of
>>> some kind being convolved with the signal.
>>>
>>> <image001.png>
>>>
>>> <image002.jpg>
>>>
>>> <image003.jpg>
>>>
>>> <image004.jpg>
>>>
>>>
>>> Steven Knudsen, Ph.D., P.Eng.
>>> www. techconficio.ca <http://techconficio.ca/> <http://techconficio.ca/
>>> <http://techconficio.ca/>>
>>> www.linkedin.com/in/knudstevenknudsen
>>> <http://www.linkedin.com/in/knudstevenknudsen>
>>> <http://www.linkedin.com/in/knudstevenknudsen
>>> <http://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/
>>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> 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
> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
> 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/20160921/d450827c/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 21 Sep 2016 18:39:15 +0000 (UTC)
From: ti...@comcast.net
To: usrp-users <usrp-users@lists.ettus.com>
Subject: [USRP-users] Fwd: Example code for a pair of TwinRXs
Message-ID:
<944259256.27355223.1474483155933.javamail.zim...@comcast.net>
Content-Type: text/plain; charset="utf-8"
Ahhh, I see what you are saying...
AFIK, the only thing that requires timed commands is freq tuning...
I never use timed commands to set gain or sample rate, and thinking about it, I
am not sure what it would mean to set the sample rate across all channels at
the same time...
Try just using timed commands for freq tuning and use time spec for initial
sample recv...
----- Original Message -----
From: "d.des" <d....@sbcglobal.net>
To: ti...@comcast.net
Sent: Wednesday, September 21, 2016 12:19:58 PM
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Thanks for the note. The issue seems to be related to uhd not honoring
the requested sample rate when submitted with a timed command (at least
the way I'm doing it). If I don't use a time command the channels are
out of sync. Somehow these radios aren't getting created at the same
time, it's not much use as a multi-channel system as is.
On Tue, 2016-09-20 at 15:00 +0000, ti...@comcast.net wrote:
> Not sure if this will help you, but when we do timed receives in the
> near future (+10 seconds) and then stream constantly for an extended
> period, we set the timeout for the first receive to be based on the
> scheduled future start time (+15 seconds) and for subsequent
> receives, use a more traditional timeout parameter value (0.1
> seconds)...
>
> From: "d.des via USRP-users" <usrp-users@lists.ettus.com>
> To: "usrp-users" <usrp-users@lists.ettus.com>
> Sent: Tuesday, September 20, 2016 9:33:58 AM
> Subject: Re: [USRP-users] Example code for a pair of TwinRXs
>
> Marcus Leach said:
> >I should have said, "except for repeatable phase-length
> differences".
> >Which there will always be, some of which will have receiver-
> hardware
> contributions, and some will have external contributions. In any
> > phase-sensitive array, one has to calibrate the "systemic phase
> center".
>
> I'm expecting to see something like what I see with the B210, only
> with
> four channels and lower phase noise. I haven't been able to evaluate
> phase bias, though, since I still can't get four channels of time-
> synced data. if I set stream_cmd.stream_now = true it records all of
> the channels just fine but the second pair of channels seems to start
> later than the first pair. If I set stream_cmd.stream_now = false
> and
> give it a start time a few seconds in the future (as recommended) the
> recv call won't return before timeout even though igot==iget
> indicating
> that it's received all of the requested samples. Here's what I've
> tried while waiting for a recommendation, Am I missing something?
>
> BTW the same code works fine on the B210 if I remove the LO stuff and
> change the subdev and the number of channels. Phase bias is minimal,
> maybe because both channels are in one tiny chip.
>
> ///////////////////////////////
>
> string args("");
> string ref("internal");
> string subdev("A:0 A:1 B:0 B:1");
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
> usrp->set_clock_source(ref);
> usrp->set_rx_subdev_spec(subdev);
>
> usrp->set_rx_lo_export_enabled(true,"all",0);
> usrp->set_rx_lo_source("internal","all",0);
> usrp->set_rx_lo_source("companion","all",1);
> usrp->set_rx_lo_source("external","all",2);
> usrp->set_rx_lo_source("external","all",3);
>
> cout<<"Using Device "<<usrp->get_pp_string()<<" "<<nChans<<"
> channels\n";
> {
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_rate(rate, nChan);
> }
> usrp->clear_command_time();
> }
> {
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_gain(gain, nChan);
> }
> usrp->clear_command_time();
> }
> {
> uhd::time_spec_t cmd_time = usrp->get_time_now() +
> uhd::time_spec_t(0.1);
> usrp->set_command_time(cmd_time);
> for(int nChan=0;nChan<nChans;++nChan) {
> usrp->set_rx_freq(freq, nChan);
> }
> usrp->clear_command_time();
> }
> usleep(1000000);
>
> //TODO: check locked sensor
>
>
> //create a receive streamer
> uhd::stream_args_t stream_args("sc16","sc16");
> std::vector<size_t> channel_nums;
> channel_nums.push_back(0);
> channel_nums.push_back(1);
> channel_nums.push_back(2);
> channel_nums.push_back(3);
> stream_args.channels = channel_nums;
> uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);
>
> //setup streaming
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.stream_now = false;
>
>
> stream_cmd.time_spec = uhd::time_spec_t(usrp-
> >get_time_now().get_full_secs()+3.0);
>
> rx_stream->issue_stream_cmd(stream_cmd);
>
>
> while(!done) {
> igot = rx_stream->recv(IF, iget, md, 3.0, false);
> //process four blocks of IF data
> }
>
> stream_cmd.stream_mode =
> uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
> rx_stream->issue_stream_cmd(stream_cmd);
>
> ///////////////////////////////
>
>
>
> _______________________________________________
> USRP-users mailing list
> 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/20160921/c946423f/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 21 Sep 2016 20:07:54 +0000
From: "d.des" <d....@sbcglobal.net>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID: <1474488474.10655.11.ca...@sbcglobal.net>
Content-Type: text/plain; charset="UTF-8"
>.Timed commands are largely designed for daughterboard commands, and?
setting the sample rate isn't a daughterboard command.
???Further, setting sample-rate doesn't need to be made precisely?
synchronous, neither, strictly-speaking, does gain.
> The only part of it where timed-commands are crucial is in tuning,
where?
the timed-commands will arrange for phase-syncrhonization.
OK, that's fine.??I switched to non-timed versions of gain and rate,
trying them first before and then after the timed set_rx_freq call.??I
also tried setting freq twice to avoid the error mentioned a while back
about frequencies not being compatible with shared LO mode.??No matter
what I try with any of the UHD host and image sets that I have the
second pair of receivers starts 8-20 microseconds after the first pair
and the phase differences between channels are not constant.??Have the
changes mentioned in the September 5th message on phase offset been
introduced into a version of UHD that I have access to???It seems that
at that point someone had created a custom patch by missing bits from
master and maint branches.??There was talk about a new X300_HG image
being posted "tomorrow" but I can't figure out where it and the
corresponding host code would be (github? files.ettus.com?).
------------------------------
Message: 12
Date: Wed, 21 Sep 2016 14:52:01 -0600
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] N210 'benchmark_rate' interpretation in a
Docker container
Message-ID: <57e2f2f1.4070...@ettus.com>
Content-Type: text/plain; charset=windows-1252
------------------------------
Message: 13
Date: Wed, 21 Sep 2016 16:54:13 -0400
From: EJ Kreinar <ejkrei...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] How to periodically re-output CVITA time tag
Message-ID:
<cadrnh23rc4tsodgocszkrfa7fwyuwdpyuqvjdo17wx30s2+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I'm working on a TDOA application where I need to maintain time
synchronization between two (or more) USRPs within the timing accuracies of
a GPS receiver. For background information, we are currently testing both
E310 and B200 hardware. In the future, we would like to move towards the
E310 platform running the RFNoC architecture. A few timing related
questions here:
1. We see a failure case where occasionally the GPSDO loses lock and causes
tens of microseconds of error before re-locking, particularly on the B200.
We would like to be able to handle this error gracefully by periodically
propagating a new, correct time tag from the FPGA to our flowgraph (say
once every 10 seconds or so). Is this operation supported? If so, how do I
generate a new time tag?
I assume I also need to reset the FPGA's cvita_time based on the GPS PPS
timestamp, which I can currently do successfully, but I cannot find a
process (yet) to cause this time to propagate into the flowgraph as a new
time tag without restarting the data flow or dropping a sample.
2. Is the FPGA's cvita_time expressed in units of "ticks" of the radio
master clock rate? (I was confused by some documentation indicating the
cvita_time is a "fractional time"
http://files.ettus.com/manual/page_rtp.html) How is this radio master clock
rate set?
Thanks!
EJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/3074ef5a/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 21 Sep 2016 14:00:53 -0700
From: Derek Kozel <derek.ko...@ettus.com>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Cc: "d.des" <d....@sbcglobal.net>, Samuel Dudley
<dudley.sam...@gmail.com>
Subject: Re: [USRP-users] Example code for a pair of TwinRXs
Message-ID:
<CAA+K=ttx+_HMk=rz8kgpwc1vtzwfa-bdqqefmyyl-cct3cm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Sam and Dave,
I've sent you emails directly with the FPGA image attached. It is too big
to fit on the mailing list so if anyone else needs it please let me know.
I am publicly posting the GNU Radio flowgraph which I use to spot check
phase offset repeatability in case it is useful to others. It uses timed
commands so is in Python rather than GRC. It would be possible to use the
controlport of the USRP Source to do a pure GRC version.
There is an example of tuning using controlport messages included in gr-uhd.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/
examples/grc/uhd_msg_tune.grc
The MUSIC demo was not shown as a talk during the conference so there is no
video or slidedeck from it. The code is undergoing some final cleanup,
testing, and documentation before being made available as a GNU Radio out
of tree module. There will be an application note discussing it on the
Ettus Knowledge Base as well.
The C++ example and GRC only flowgraphs are not yet ready and I will post
to this thread when they are.
Regards,
Derek
On Wed, Sep 21, 2016 at 1:07 PM, d.des via USRP-users <
usrp-users@lists.ettus.com> wrote:
> >.Timed commands are largely designed for daughterboard commands, and
> setting the sample rate isn't a daughterboard command.
> Further, setting sample-rate doesn't need to be made precisely
> synchronous, neither, strictly-speaking, does gain.
>
> > The only part of it where timed-commands are crucial is in tuning,
> where
> the timed-commands will arrange for phase-syncrhonization.
>
> OK, that's fine. I switched to non-timed versions of gain and rate,
> trying them first before and then after the timed set_rx_freq call. I
> also tried setting freq twice to avoid the error mentioned a while back
> about frequencies not being compatible with shared LO mode. No matter
> what I try with any of the UHD host and image sets that I have the
> second pair of receivers starts 8-20 microseconds after the first pair
> and the phase differences between channels are not constant. Have the
> changes mentioned in the September 5th message on phase offset been
> introduced into a version of UHD that I have access to? It seems that
> at that point someone had created a custom patch by missing bits from
> master and maint branches. There was talk about a new X300_HG image
> being posted "tomorrow" but I can't figure out where it and the
> corresponding host code would be (github? files.ettus.com?).
>
> _______________________________________________
> USRP-users mailing list
> 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/20160921/e4bddf61/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twinrx_four_channel_phase_check.py
Type: text/x-python
Size: 19356 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/e4bddf61/attachment-0001.py>
------------------------------
Message: 15
Date: Wed, 21 Sep 2016 16:03:17 -0600
From: Martin Braun <martin.br...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] How to periodically re-output CVITA time tag
Message-ID: <57e303a5.30...@ettus.com>
Content-Type: text/plain; charset=windows-1252
On 09/21/2016 02:54 PM, EJ Kreinar via USRP-users wrote:
> Hi all,
>
> I'm working on a TDOA application where I need to maintain time
> synchronization between two (or more) USRPs within the timing accuracies
> of a GPS receiver. For background information, we are currently testing
> both E310 and B200 hardware. In the future, we would like to move
> towards the E310 platform running the RFNoC architecture. A few timing
> related questions here:
>
>
> 1. We see a failure case where occasionally the GPSDO loses lock and
> causes tens of microseconds of error before re-locking, particularly on
> the B200. We would like to be able to handle this error gracefully by
> periodically propagating a new, correct time tag from the FPGA to our
> flowgraph (say once every 10 seconds or so). Is this operation
> supported? If so, how do I generate a new time tag?
EJ,
every data packet coming from the radio is timestamped. Your recv() call
will also return the metadata, which in turn includes the timestamp.
>
> I assume I also need to reset the FPGA's cvita_time based on the GPS PPS
> timestamp, which I can currently do successfully, but I cannot find a
> process (yet) to cause this time to propagate into the flowgraph as a
> new time tag without restarting the data flow or dropping a sample.
Ah, you want to inject it into a GNU Radio flow graph? There's no option
to do that right now, but it's something that we'll need to add at some
point. However, you can modify the rfnoc_block_impl.cc to parse the
metadata and generate CVITA times. Look for the recv() calls, and you
can then poke the rx_metadata_t object that's returned from there.
> 2. Is the FPGA's cvita_time expressed in units of "ticks" of the radio
> master clock rate? (I was confused by some documentation indicating the
Yes.
> cvita_time is a "fractional
> time" http://files.ettus.com/manual/page_rtp.html) How is this radio
> master clock rate set?
On the E310, it's what you pass in with the master_clock_rate device
arg, or the value of the sampling rate you set on the RFNoC block.
Cheers,
Martin
------------------------------
Message: 16
Date: Thu, 22 Sep 2016 09:16:39 +1000
From: Walter Maguire <wmagu...@iinet.net.au>
To: usrp-users@lists.ettus.com
Subject: [USRP-users] RFNoC without a Radio Core
Message-ID: <54359327-0e6f-dd1a-de2a-398e9ccbd...@iinet.net.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi all,
I didn't seem to get a response that my submission was successful so I
though I might send it again.
"I have been using the latest UHD rfnoc-devel release with the
associated uhd-fpga source. Having studied the FPGA design and UHD
library software it appears to me that the Radio Core is not treated
like a standard CE. It looks like the E3xx UHD driver always expects
the Radio to be present as per the checks to control the associated
AD9361 part.
If the CE approach was fully adopted for the radio block then I would
assume that not building the radio block in the FPGA would result in the
enumeration of the RFNoC bus not finding the radio block with its
associated block id. Therefore the associated configuration of the
related AD9361 would not be run.
I would be grateful if someone would clarify that in order for the UHD
device driver to work with RFNoC that the associated radio block needs
to be present in the FPGA design. If this is case, are there any plans
to make the Radio block control and implementation to be the same as a
standard CE, such that if it is not present the driver still works. "
Regards
Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/93a2edf0/attachment-0001.html>
------------------------------
Message: 17
Date: Wed, 21 Sep 2016 19:24:38 -0400
From: "Marcus D. Leech" <mle...@ripnet.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] RFNoC without a Radio Core
Message-ID: <57e316b6.7050...@ripnet.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 09/21/2016 07:16 PM, Walter Maguire via USRP-users wrote:
>
> Hi all,
>
> I didn't seem to get a response that my submission was successful so I
> though I might send it again.
>
> "I have been using the latest UHD rfnoc-devel release with the
> associated uhd-fpga source. Having studied the FPGA design and UHD
> library software it appears to me that the Radio Core is not treated
> like a standard CE. It looks like the E3xx UHD driver always expects
> the Radio to be present as per the checks to control the associated
> AD9361 part.
> If the CE approach was fully adopted for the radio block then I would
> assume that not building the radio block in the FPGA would result in
> the enumeration of the RFNoC bus not finding the radio block with its
> associated block id. Therefore the associated configuration of the
> related AD9361 would not be run.
>
> I would be grateful if someone would clarify that in order for the UHD
> device driver to work with RFNoC that the associated radio block needs
> to be present in the FPGA design. If this is case, are there any
> plans to make the Radio block control and implementation to be the
> same as a standard CE, such that if it is not present the driver still
> works. "
>
> Regards
>
> Walter
>
>
Martin Braun answered this on the list earlier today:
On 09/19/2016 10:01 PM, Walter Maguire via USRP-users wrote:
> I have been using the latest UHD rfnoc-devel release with the associated
> uhd-fpga source. Having studied the FPGA design and UHD library
> software it appears to me that the Radio Core is not treated like a
> standard CE. It looks like the E3xx UHD driver always expects the Radio
> to be present as per the checks to control the associated AD9361 part.
> If the CE approach was fully adopted for the radio block then I would
> assume that not building the radio block in the FPGA would result in the
> enumeration of the RFNoC bus not finding the radio block with its
> associated block id. Therefore the associated configuration of the
> related AD9361 would not be run.
Walter,
the radio blocks are not special in an RFNoC sense (they are only
differently connected in the FPGA, as they have more I/Os than other
blocks).
If you have no radios, you will see a warning ("No Radio Block found.
Assuming radio-less operation."), but it's really not a critical warning.
> I would be grateful if someone would clarify that in order for the UHD
> device driver to work with RFNoC that the associated radio block needs
> to be present in the FPGA design. If this is case, are there any plans
> to make the Radio block control and implementation to be the same as a
> standard CE, such that if it is not present the driver still works.
As said before, radios are regular blocks, and taking them out will not
break anything. The AD9361 will not be activated in that case, either.
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160921/47795bdc/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 22 Sep 2016 09:31:05 -0400
From: Michael Dickens <michael.dick...@ettus.com>
To: discuss-gnura...@gnu.org, usrp-users@lists.ettus.com
Subject: [USRP-users] Volk / UHD / GR on macOS 10.12 Sierra
Message-ID:
<1474551065.2587209.733765089.59cd4...@webmail.messagingengine.com>
Content-Type: text/plain
Apple released its latest OS earlier this week, now called "macOS" (was
Mac OS X): 10.12.0, codename "Sierra". The vast majority of projects
that built for 10.11 and prior continue to work with 10.12, including
Volk, UHD, and GNU Radio. In MacPorts, I committed changes to Qt4
(qt4-mac) to allow it to build on 10.5 through 10.12, so the gr-QtGui
and related Qt features all seem to work properly. All of Volk, UHD, and
GNU Radio and their dependencies all seem to build, test, and install
cleanly in Sierra. As a -notable- benefit: 10.12 also includes updated
graphics drivers that allow gr-fosphor to work out of the box again; the
graphics drivers in 10.11 were broken for some computers, and required a
non-Apple sanctioned update from NVIDIA that many people (including me)
were hesitant to try. I'm not usually a proponent of adopting a new
major Apple OS before the ".2" release, but thus far Sierra is working
very nicely and contains some useful fixes under the hood -- hence, I'm
cautiously endorsing updating if you have a Mac and want to do so.
Cheers! - MLD
ps> If you are running Mac OS X 10.11 or prior: DO NOT update to Xcode
8! Keep using Xcode 7 or prior. The best work-around if you have updated
is to reinstall Xcode 7 or prior. Xcode 8 defaults to using the build
SDK for 10.12, which is fine if you're running 10.12 but NOT fine if
you're running 10.11 or prior. There are supposedly wants to coerce
Xcode 8 into working in this situation, but the results are not
guaranteed. Hence, my advice is to just not update, or revert back if
you have already updated.
------------------------------
Message: 19
Date: Thu, 22 Sep 2016 14:09:35 +0000
From: "Perelman, Nathan" <nperel...@lgsinnovations.com>
To: Ben Hilburn via USRP-users <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Message-ID: <3bd90cac6a5d4065b6743ddd48f35...@lgs-ex01.lgsdirect.com>
Content-Type: text/plain; charset="utf-8"
Does this affect the UBX-40 as well?
From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of
Michael West via USRP-users
Sent: Tuesday, September 20, 2016 1:05 PM
To: Michael Wentz
Cc: USRP-users@lists.ettus.com
Subject: Re: [USRP-users] UBX-160 Performance < 500 MHz
Hi Michael,
I'm glad to hear that made a substantial improvement.
We need to update the documentation with the dboard_clock_rate parameter
information and we will do that. The MAX2871 synthesizer used on the UBX has
proven to be a bit touchy and has required a lot of special settings to
perform properly. The default dboard_clock_rate on the X310 is 50 MHz, which
is the ideal PFD frequency for the UBX. For frequencies under 1 GHz, we have
found it necessary to reduce the dboard_clock_rate to 20 MHz due to several
limitations in the MAX2871.
We looked into setting the dboard_clock_rate automatically in UHD, but it is a
non-trivial exercise because it is dependent on the user's intended use.
Changing the dboard_clock_rate dynamically whenever the user application
changes the frequency presents a host of other potential problems, not to
mention what to do if there are 2 different types of daughterboards in the
USRP.
Regards,
Michael
On Tue, Sep 20, 2016 at 4:55 AM, Michael Wentz <mchlw...@gmail.com> wrote:
Hi Michael,
Adding "dboard_clock_rate=20e6" made a significant difference - the spurs and
odd shape in the noise floor are both gone, image attached. I did the same
type of measurement and it was around 75 dB SFDR, almost a 20 dB improvement.
I had never heard of the dboard_clock_rate argument before. Are there any
implications of setting that to 20 MHz and using the default master clock rate
of 200 MHz? Also, is there a reason that UHD wouldn't know to use that number
by default (based on the fact that I'm using a UBX < 1 GHz)?
Thanks,
Michael
On Mon, Sep 19, 2016 at 9:34 PM, Michael West <michael.w...@ettus.com> wrote:
Hi Michael,
We do recommend a lower dboard clock rate for frequencies below 1 GHz on the
UBX (for better LO performance). Can you try adding 'dboard_clock_rate=20e6'
to your device arguments and see if there is any change?
It is odd that introducing a signal causes the noise floor to rise. I will
run this by the hardware engineer for the UBX and see if he has any ideas.
Regards,
Michael West
On Mon, Sep 19, 2016 at 5:19 PM, Michael Wentz via USRP-users
<usrp-users@lists.ettus.com> wrote:
I'm using the latest commit on rfnoc-devel, built today. I can also try
without RFNoC but figured it would be identical since the master branch was
merged in 10 days ago.
On Mon, Sep 19, 2016 at 8:15 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
On 09/19/2016 06:30 PM, Michael Wentz wrote:
Hi Marcus,
Thanks for the feedback. Yes, I've tried gain ranges 0 to 31.5 - I'm intending
to use an external LNA so was searching for settings where these issues were
minimized, but they were fairly consistent across the gain range. I've also
tried a variety of input signal strengths, usually around 30-40 dB below IIP3.
I'm aware of the two RF chains and there is a noticeable performance
difference < 500 MHz in the data on files.ettus.com, but nothing that informed
me about the spurious content and odd behavior of the noise floor when there's
a signal applied.
Is the UBX design more optimized for higher frequencies? Wondering if I should
have gone with the WBX-120 here.
-Michael
The UBX design is optimized for its entire frequency range.
What version of UHD are you using?
On Mon, Sep 19, 2016 at 6:03 PM, Marcus D. Leech via USRP-users
<usrp-users@lists.ettus.com> wrote:
On 09/19/2016 02:58 PM, Michael Wentz via USRP-users wrote:
Hi,
I am working with an X310 and UBX-160 with the latest version of UHD. I've
started to characterize the performance a bit at frequencies I'm interested in
(< 500 MHz), and while trying to determine full range I noticed strange
behavior compared to the WBX and SBX. Attached are some screen shots from
measurements I made at 400 MHz with full gain (31.5) on the WBX-40, SBX-120,
and UBX-160. I'm just eye balling the SDFR and picking the most noticeable
spur away from the carrier, nothing really precise.
WBX-40 : input power -15 dBm, SFDR around 76 dB
SBX-120: input power -34 dBm, SFDR around 82 dB
UBX-120: input power -32 dBm, SFDR around 56 dB
I also noticed on the UBX that there is a significant increase in the noise
floor when an input signal is applied, even if that input is 20-30 dB below
where the input would clip. I've verified with test equipment that the noise
floor is not from my signal source. Additionally, I did some measurements at
600 MHz and 1 GHz and saw much better performance, in line with the WBX/SBX.
Is any of this expected? Is there anything I can do to improve the
performance?
Thanks,
Michael
Two quick comments.
The first is that the analog RF chain on UBX is *very* different from SBX/WBX
(which are almost identical, BTW, except for mixers).
The second is a question. Have you tried dropping the gain on the UBX? Have
you tried lowering the signal level? The UBX has two
different RF chains, with 500Mhz being the dividing line between the two.
So I would expect there to be not-subtle differences in things
like OIP3, p1dB, etc.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
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/20160922/7fdc9c70/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4353 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160922/7fdc9c70/attachment-0001.p7s>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 73, Issue 20
******************************************
