Re: [USRP-users] List of compatible parts

[Nate Temple via USRP-users]

Hi Daniel, Michael:

Generally there should be no compatibility issues. Where you may run into an 
issue with compatibility is if for example, you build UHD & GNU Radio, then 
switch the major version of UHD without rebuilding GNU Radio. This will cause 
an ABI mismatch, and GNU Radio needs to be rebuilt.  

Generally as long as you follow the order of building UHD -> GNU Radio, there 
should never be a mismatch issue. Keep in mind, unless you're installing to a 
local directory, and have a custom environment setup file, you'll want to 
remove any previous versions of UHD/GR before starting with a new install. 

Another point to note, you should not mix source installs of UHD/GR with 
package installations (apt-get, yum, dnf, etc) of UHD/GR. This will often cause 
headaches and difficult to diagnose problems. 

Now if you have a USRP such as a N2xx or X3xx, where the FPGA image is stored, 
if you switch versions of UHD that require a different FPGA version, you'll 
need to download (with uhd_images_downloader) new FPGA images and write them to 
the USRP EEPROM (with uhd_image_loader) once.

Below is a guide on installing UHD/GR from source on Linux and has been 
throughly tested against the operating systems listed within the app note. 

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux


+Michael - I've attached a rough outline of instructions that cover installing 
OpenBTS I've put together which should get you started. These have been 
ran/tested on Ubuntu 14.04 and 16.04. If you're running Ubuntu 14.04, you don't 
need to perform the manual service starting at the end as Ubuntu 14.04 uses 
upstart. The manually starting of services is only required if you are using a 
version of Ubuntu which uses systemd.


Regards,
Nate Temple


 Update your system
sudo apt-get update
sudo apt-get upgrade

 Install Deps
sudo apt-get install libboost-all-dev libusb-1.0-0-dev python-mako doxygen 
python-docutils cmake build-essential libncurses5-dev libncurses5 python-dev 
python-requests ncurses-bin libncurses5-dbg libudev-dev git 

 Create working dir
mkdir ~/workarea
cd ~/workarea/

 Install UHD (skip if you already have UHD installed )
git clone https://github.com/EttusResearch/uhd
cd uhd/
git checkout release_003_009_006
cd host/
mkdir build
cd build/
cmake ..  
make -j3
sudo make install
sudo ldconfig

### Install UDEV Rules
cd ../utils/
sudo cp uhd-usrp.rules /etc/udev/rules.d/
sudo udevadm control --reload-rules
sudo udevadm trigger

### Create usrp group and add user
sudo addgroup usrp
sudo usermod -a -G usrp $USER

### Add rtprio line to limits.conf
sudo sh -c "echo '@usrp\t-\trtprio\t99' >> /etc/security/limits.conf"

### Log out and log back in

### Download UHD Images
sudo uhd_images_downloader 







 Clone OpenBTS build scripts
cd ~/workarea/
git clone https://github.com/RangeNetworks/dev.git
cd dev/

 Update build scripts to skip installing the repo UHD packages
sed -i 's/installIfMissing\ libuhd-dev/#installIfMissing\ libuhd-dev/g' build.sh
sed -i 's/installIfMissing\ libuhd003/#installIfMissing\ libuhd003/g' build.sh
sed -i 's/installIfMissing\ uhd-host/#installIfMissing\ uhd-host/g' build.sh
sed -i '/#installIfMissing\ uhd-host/a \\techo "Skipping UHD Package Install"' 
build.sh

 Clone openbts, and all other repos using build script util
 Switch to master branch
 Build OpenBTS and friends
./clone.sh 
./switchto.sh master
./build.sh B210

 Install built packages, * This command will fail 
 *** Select "Y" to overwrite config files when prompted
 You must change the path of this command to match the folder and replace 
the __TIMESTAMP_OF_BUILD__ 
sudo dpkg -i BUILDS/__TIMESTAMP_OF_BUILD__/*.deb

 Resolve Deps from previous command
sudo apt-get -f install

 Run the install again for packages, this will pass
sudo dpkg -i BUILDS/__TIMESTAMP_OF_BUILD__/*.deb

 Change permissions on asterisk database
sudo chown -R asterisk:asterisk /var/lib/asterisk/sqlite3dir


 Starting OpenBTS & Friends
# In four new terminals run:

# Terminal 1:
sudo /usr/local/sbin/smqueue 

# Terminal 2:
sudo /usr/local/sbin/sipauthserve 

# Terminal 3:
sudo /usr/sbin/asterisk -

# Terminal 4:
# * Note: Run uhd_usrp_probe before starting OpenBTS, so the FPGA image is 
loaded. OpenBTS's startup can timeout waiting on the FPGA to load.
uhd_usrp_probe 
cd /OpenBTS
sudo ./OpenBTS

### OpenBTS should now be running with a prompt:

OpenBTS >

### Adjusting RX Gain:
OpenBTS > rxgain 20

### Config Open Regristration:
OpenBTS> config Control.LUR.OpenRegistration ".*"

# You should now be able to search for the network and connect to it with your 
phones.
# Register with SIP by sending a 7-10 digit phone number to the number: 101
# OR manually add each IMSI with the commands below:

 Notes on adding SIP subscribers manually
# * In new terminal

cd ~/workarea/dev/NodeManager/

# read current subscribers
./nmcli.py 

Re: [USRP-users] List of compatible parts

[Michael Cameron via USRP-users]

Hi Daniel,
*** I was hoping that there would be a list somewhere so that I don’t have to 
play Russian roulette and hope that I am git checking out the correct 
version.***
   Stay strong! This is part and parcel of the open source ecosystem--a 
challenge or a puzzle to be solved.  Looking through source code or build 
scripts to identify and fix the issues is just part of what we USRP'ers have to 
do (or we can just buy an Icom 7300 or FlexRadio where it has all been done for 
us!). 
That is not to minimize the issue. When the build script was last revised in 
2013, and the SW components have since been revised at different dates, things 
are bound to break.  It is frustrating--but working the issues in a logical way 
makes it all worth it once you finally get an error-free build.  Gradually, as 
we work on these issues, we develop the expertise that others will pay for (or 
at least can be used to impress at cocktail parties).  Good luck!
BTW, please, if you get such a list, send it around. I have the B210 and am 
having a heck of a time getting all the OpenBTS components to play nicely!  
Cheers, Mike   ___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Uhd Python API rx and tx samples

[Ivan Zahartchuk via USRP-users]

Hello.How to interrupt the transmission of a signal on a button and how to
generate a constant and not a specified amount of time ??
Tell me how the get_rx_stream function works and what arguments are passed
to it. I do not want to open the session every time.
I use Python API
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Flow control in UHD

[James Dunn via USRP-users]

Hello,

We have been using RFNoC to implement a complete radio system (PHY + MAC)
on the FPGA with limited control and interfacing in GNURadio.  Because the
MAC can exhibit arbitrary transmit delay, we need some method to prevent
the host from sending packets when the transmit buffer on the FPGA is
full.  We planned on implementing a split SW/HW buffer to handle this
issue.  However, to make this scheme work, we need some flow control
mechanism to prevent the host from emptying its buffer when there is no
room in the FPGA buffer.  We have done some Googling and came across
references to a flow control mechanism built into CHDR and RFNoC (
https://static1.squarespace.com/static/543ae9afe4b0c3b808d7
2acd/t/55f85bc2e4b067b8c2af4eaf/1442339778410/3-pendlum_jona
thon-rfnoc_tutorial_fpga.pdf, http://ionconcepts.com/files/
USRP3_concepts.pdf).  However, we are not sure if this flow control
mechanism exists only within the FPGA context or if it extends to
UHD/GNURadio on the host.  We could also not find an example of this form
of host to FPGA flow control.  Can anyone point us to some flow control
examples or documentation?  Thanks!

James Dunn & Chris Yarp
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Buffer underrun issue with simultaneous transmit and receive on the X310

[Jason W Zheng via USRP-users]

@robin, I reset the usrp clock to zero right before creating my threads, I also 
tried your suggestion of starting transmit much later, but once transmits 
start, I get underflows, so same problem. It doesn't look like transmitting 
later helps.

@marcus, i've tried running on UHD 3.10.2, but I get the same problem.



From: Jason W Zheng
Sent: Tuesday, August 15, 2017 9:54:45 AM
To: Marcus D. Leech; ROBIN TORTORA
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310


@robin, I reset the usrp clock to zero right before creating my threads, I also 
tried your suggestion of starting transmit much later, but once transmits 
start, I get underflows, so same problem. It doesn't look like transmitting 
later helps.


@marcus, i've tried running on UHD 3.10.2, but I get the same problem.




From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Tuesday, August 15, 2017 5:07:01 AM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310

On 08/14/2017 08:27 PM, Jason W Zheng via USRP-users wrote:

I don't think the problem is in the metadata, unless I'm really doing it wrong. 
I've tried the suggestion you put out earlier, modeling my code after the 
example txrx_loopback_to_file. The first packet has a startofburst = true and 
subsequent packets have the start_of_burst value and the has_time_spec value 
set to false after the first transmission.

COuld you try reverting to UHD 3.10.2 and see if that changes things?   Just 
got this hint from engineering.



// set up TX streams and threads
std::thread tx_threads[NUM_CHANNELS];
uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(0.1);

for (int i = 0; i < NUM_CHANNELS; i++){
stream_args.channels = std::vector(1,i);
tx_streams[i] = usrp->get_tx_stream(stream_args);
//start the thread
std::cout << "Starting tx thread " << i << std::endl;
tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);
}

///
the thread function




void txTask(Complex *buff, uhd::tx_streamer::sptr tx_stream, uhd::tx_metadata_t 
md){

size_t num_acc_samps = 0;
struct timespec start_time;
clock_gettime(CLOCK_MONOTONIC, _time);

while(!stop_signal_called){
size_t samples_sent = tx_stream->send(buff,BUFF_SIZE,md);
num_acc_samps += samples_sent;

md.start_of_burst = false;//after first transmission set to false
md.has_time_spec = false;  //after first transmission set to false
}

struct timespec end_time;
clock_gettime(CLOCK_MONOTONIC, _time);
double runtime = (end_time.tv_sec  - start_time.tv_sec)  +
 (end_time.tv_nsec - start_time.tv_nsec ) / 10.0;
std::cout << std::endl << "Sent " << num_acc_samps
  << " samples in " << runtime << "s"
  << " Throughput = " << num_acc_samps / 1e6 /runtime << " Msps"
  << std::endl;

//send a mini EOB packet
md.end_of_burst = true;
tx_stream -> send("",0,md);

printf("End transmit \n");
}


Even with the metadata fix I still get underflows when transmitting and 
receiving on the same channel, no matter what the rate. If you have an X310, I 
wonder if you could compile and run my code and see if you get the same result?


Thanks,

Jason



From: The Tilla 
Sent: Monday, August 14, 2017 4:47:31 PM
To: Jason W Zheng; mle...@ripnet.com
Cc: usrp-users@lists.ettus.com
Subject: RE: [USRP-users] Buffer underrun issue with simultaneous transmit and 
receive on the X310

I think some of the issue here as well is the tx_metadata.

For continuous streaming, the first packet ONLY should have startofburst = true…

Further packets after the first one should have startofburst = false, cuz they 
really are not start of burst, they are continuations of the initial burst.

Furthermore, for continuous streaming as soon as possible, you should not 
provide a timespec.

If you continually provide a timespec to each packet, it will continually try 
to send them at time = 0.1, which is not what you want…

If you want to start your tx at a specific time, then similar to startofburst, 
you should only provide a timespec with the first packet, all subsequent 
packets should not include a timespec.

Does that make sense?

It can be a bit confusing at first, but after writing a few apps, you will be 

Re: [USRP-users] UHD Version for New UBX Hardware Rev

[Dave NotTelling via USRP-users]

Derek,

 Thank you very much!

-David

On Tue, Aug 15, 2017 at 11:03 AM, Derek Kozel  wrote:

> Hello Dave,
>
> This commit added the EEPROM IDs for the updated UBX version.
> https://github.com/EttusResearch/uhd/commit/f5a082fd3841571d2a53a9e677b5df
> e6d653bd94
>
> It was added August 22nd and 3.9.5 has it. I believe there have been a few
> improvement changes since then which are on the 3.9 branch, but basic
> support would start from 3.9.5.
>
> Regards,
> Derek
>
> On Tue, Aug 15, 2017 at 3:47 PM, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I got a UBX-40 that wouldn't work in my N210 and I remembered seeing
>> something on the forums about the older UHD versions not working for the
>> new UBX-40 rev.  What is the oldest version of UHD that is guaranteed to
>> work with the new UBX-40 rev?  I was running 3.9.4 and when I upgraded to
>> 3.9.7 things worked again.  The thing that tipped me off was that the
>> UBX-40 didn't show up properly in uhd_usrp_probe.
>>
>> Thanks!
>>
>> ___
>> 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

Re: [USRP-users] UHD Version for New UBX Hardware Rev

[Derek Kozel via USRP-users]

Hello Dave,

This commit added the EEPROM IDs for the updated UBX version.
https://github.com/EttusResearch/uhd/commit/f5a082fd3841571d2a53a9e677b5dfe6d653bd94

It was added August 22nd and 3.9.5 has it. I believe there have been a few
improvement changes since then which are on the 3.9 branch, but basic
support would start from 3.9.5.

Regards,
Derek

On Tue, Aug 15, 2017 at 3:47 PM, Dave NotTelling via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I got a UBX-40 that wouldn't work in my N210 and I remembered seeing
> something on the forums about the older UHD versions not working for the
> new UBX-40 rev.  What is the oldest version of UHD that is guaranteed to
> work with the new UBX-40 rev?  I was running 3.9.4 and when I upgraded to
> 3.9.7 things worked again.  The thing that tipped me off was that the
> UBX-40 didn't show up properly in uhd_usrp_probe.
>
> Thanks!
>
> ___
> 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

Re: [USRP-users] doubts about burst tranmission using tag SOB and EOB

[Marcus D. Leech via USRP-users]

I'll note that the "Message Burst Source" is now deprecated.  Not sure 
what it has been replaced with.   I've taken the liberty of cross-posting to

  discuss-gnuradio.


On 08/02/2017 02:05 PM, Yang Liu via USRP-users wrote:

Dear all,

I tried to achieve burst transmission on usrp X310, the brief tx 
flowgraph is in the below:


message_burst_source -> signal processing blocks --> usrp_sink

New message will be inserted into the message queue of 
message_burst_source.


Since message_burst_source will attach SOB and EOB tag to the data 
stream, usrp will know the start and end of each burst. After reading 
'Busrt Transmission' section in this link: 
https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__sink.html, my 
understanding is that because of these two tags, even the two message 
arrives at usrp at a different time, usrp will not complain about 
underrun. However, according to results from my experiments, as the 
time difference between two contiguous message increases, underflow 
will show up and become more and more severe. For a real burst 
transmission, time gap between two message should be expected. 
Therefore, I feel confused about the using of SOB and EOB tags here. 
Can they help to remove "underrun" under burst transmission? If not, 
is there any other methods that can make burst transmission with usrp 
possible without triggering underrun?


Thanks a lot for your help,
Yang



___
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

Re: [USRP-users] Buffer underrun issue with simultaneous transmit and receive on the X310

[Marcus D. Leech via USRP-users]

On 08/14/2017 08:27 PM, Jason W Zheng via USRP-users wrote:


I don't think the problem is in the metadata, unless I'm really doing 
it wrong. I've tried the suggestion you put out earlier, modeling my 
code after the example txrx_loopback_to_file. The first packet has a 
startofburst = true and subsequent packets have the start_of_burst 
value and the has_time_spec value set to false after the first 
transmission.


COuld you try reverting to UHD 3.10.2 and see if that changes things?   
Just got this hint from engineering.




// set up TX streams and threads
std::thread tx_threads[NUM_CHANNELS];
uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];
uhd::tx_metadata_t md;
md.start_of_burst = true;
md.end_of_burst = false;
md.has_time_spec = true;
md.time_spec = uhd::time_spec_t(0.1);

for (int i = 0; i < NUM_CHANNELS; i++){
stream_args.channels = std::vector(1,i);
tx_streams[i] = usrp->get_tx_stream(stream_args);
//start the thread
std::cout << "Starting tx thread " << i << std::endl;
tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);
}

///
the thread function




void txTask(Complex *buff, uhd::tx_streamer::sptr tx_stream, 
uhd::tx_metadata_t md){


size_t num_acc_samps = 0;
struct timespec start_time;
clock_gettime(CLOCK_MONOTONIC, _time);

while(!stop_signal_called){
size_t samples_sent = tx_stream->send(buff,BUFF_SIZE,md);
num_acc_samps += samples_sent;

md.start_of_burst = false;//after first transmission set 
to false

md.has_time_spec = false;  //after first transmission set to false
}

struct timespec end_time;
clock_gettime(CLOCK_MONOTONIC, _time);
double runtime = (end_time.tv_sec  - start_time.tv_sec)  +
 (end_time.tv_nsec - start_time.tv_nsec ) / 
10.0;

std::cout << std::endl << "Sent " << num_acc_samps
  << " samples in " << runtime << "s"
  << " Throughput = " << num_acc_samps / 1e6 /runtime << " 
Msps"

  << std::endl;

//send a mini EOB packet
md.end_of_burst = true;
tx_stream -> send("",0,md);

printf("End transmit \n");
}

Even with the metadata fix I still get underflows when transmitting 
and receiving on the same channel, no matter what the rate. If you 
have an X310, I wonder if you could compile and run my code and see if 
you get the same result?



Thanks,

Jason



*From:* The Tilla 
*Sent:* Monday, August 14, 2017 4:47:31 PM
*To:* Jason W Zheng; mle...@ripnet.com
*Cc:* usrp-users@lists.ettus.com
*Subject:* RE: [USRP-users] Buffer underrun issue with simultaneous 
transmit and receive on the X310


I think some of the issue here as well is the tx_metadata.

For continuous streaming, the first packet ONLY should have 
startofburst = true…


Further packets after the first one should have startofburst = false, 
cuz they really are not start of burst, they are continuations of the 
initial burst.


Furthermore, for continuous streaming as soon as possible, you should 
not provide a timespec.


If you continually provide a timespec to each packet, it will 
continually try to send them at time = 0.1, which is not what you want…


If you want to start your tx at a specific time, then similar to 
startofburst, you should only provide a timespec with the first 
packet, all subsequent packets should not include a timespec.


Does that make sense?

It can be a bit confusing at first, but after writing a few apps, you 
will be an expert 


*From:* Jason W Zheng [mailto:jason.w.zh...@aero.org]
*Sent:* Monday, August 14, 2017 4:41 PM
*To:* ROBIN TORTORA ; mle...@ripnet.com
*Cc:* usrp-users@lists.ettus.com
*Subject:* Re: [USRP-users] Buffer underrun issue with simultaneous 
transmit and receive on the X310


Hi Robin, Marcus

It makes no sense to me, then why changing transmit to be on its own 
channel (daughtercard) would cause the program to work.


// set up TX streams and threads

std::thread tx_threads[NUM_CHANNELS];

uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];

uhd::tx_metadata_t md;

md.start_of_burst = true;

md.end_of_burst = false;

md.has_time_spec = true;

md.time_spec = uhd::time_spec_t(0.1);

for (int i = 0; i < NUM_CHANNELS; i++){

stream_args.channels = std::vector(1,i); //changing this from 
i to 1 causes it to work for unknown reasons


tx_streams[i] = usrp->get_tx_stream(stream_args);

//start the thread

std::cout << "Starting tx thread " << i << std::endl;

tx_threads[i] = std::thread(txTask,tx_buffs[i],tx_streams[i],md);

}

The relevant line is commented in the above code snippet. When I 
change the channels arguments for the tx stream_args to be on 

[USRP-users] RFNoc Multiple stream general practices

[Joshua Sendall via USRP-users]

Hi,


I have just started looking at using RFNoC in C++, and I am unsure about what 
is the "correct" or "best" practice to get multiple streams from a device to 
the host. In the examples, for a single channel, the streamer source is 
selected via

streamer_args["block_id"]  = xxx;

streamer_args["block_port"]  = xxx;

Do you need to have a streamer for each block, or can you have multiple blocks 
connected to a streamers? And ultimately what is the correct way to implement 
this?


Kind regards,

Joshua Sendall


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com