Hi Sarah - You're welcome & the PER block sounds cool ... do you have a public repo where we can view the source? Well done! As for your other question: Have you tried updating to the latest UHD release (3.11)? That might fix the issue "out of the box" ... and if not, try building from source via the latest GIT master branch. Even though 3.10 isn't really that old, it's old enough that updating might fix the issue. If not, then please provide the startup info from UHD to show its version & build, along with some code / specifics on how to replicate your issue & we'll definitely take a look & see what we can do. Cheers! - MLD
On Thu, Mar 15, 2018, at 6:19 PM, Sarah Tran wrote: > I was able to make a PER block and it turns out I was dropping some > packets, so when I took into account those dropped packets when I > performed the BER, I was in a much better place 10e-2. Thank you for > the explanation and help!> > I had another question. I was previously using the N210 for this, and > have since upgraded to the X310. However I get severe underruns (I > tried the WBX and UBX-160 daughtercards). No matter what samp rate I > use (from 400kHz to 10 MHz), I get lots of U’s printed on my console > and then the X310 stops transmitting and freezes. I saw a previous > thread that mentioned it was a problem with the UHD 3.10 code (which I > am running), but didn’t say how it was fixed. (See > http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/023924.html). > Do you have any idea what the problem could be? I also put a null > source instead of file source and changed the uhd sink to a > probe+message debug, and it looks like my rates are good 2e7. The N210 > works great and the X310 will transmit other data at the same rates, > but not the ofdm_tx code.
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
