Re: [USRP-users] Error when trying to run USRP N310s using external LO
Unfortunately not, I'm trying to get the N310s to operate at 584.2 MHz, so my LO is going at 1168.4 MHz (there's a note saying the external LO should supply twice the desired center frequency). I would have thought there's no need to specify the center frequency when running with the LO switched to external, but when I run the setup without specifying the center frequency it doesn't seem to work. -Mark On Fri, Oct 25, 2019 at 6:27 AM Rob Kossler wrote: > The N310 data sheet (in one of the footnotes) indicates that external LO > is limited to the frequency range 300-4000 MHz. Are you trying to operate > below 300MHz? > Rob > > On Thu, Oct 24, 2019 at 3:42 PM Mark Wagner via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi all, >> >> I'm currently trying to run a set of USRP N310s all using the same >> external LO, but I seem to be getting this error >> >> "[ERROR] [0/Radio_1] RX LO lowband does not support setting source to >> external" >> >> which will repeat for all the radios. I tried looking online for the >> source of the error but no dice. It seems like the radios are ignoring the >> LO I'm giving them and using their internal ones instead. Any thoughts? >> >> -Mark >> >> -- >> Mark Wagner >> University of California San Diego >> Electrical and Computer Engineering >> >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> > -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Error when trying to run USRP N310s using external LO
Hi all, I'm currently trying to run a set of USRP N310s all using the same external LO, but I seem to be getting this error "[ERROR] [0/Radio_1] RX LO lowband does not support setting source to external" which will repeat for all the radios. I tried looking online for the source of the error but no dice. It seems like the radios are ignoring the LO I'm giving them and using their internal ones instead. Any thoughts? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] N310 late packet error (L) when streaming to python block
Hey all, I've been trying to get the embedded python block to work with my USRP N310s, but I'm experiencing late packet errors. My goal is to stream one channel of the N310 to a length 2^12 vector, perform some fancy fance on the vector, then vector to stream to a file sink. The problem: every time I run my basic python block I get late packet errors (). Here's a bare bones python block code that still gives me the error. import numpy as np from gnuradio import gr class blk(gr.sync_block): # other base classes are basic_block, decim_block, interp_block """Embedded Python Block example - a simple multiply const""" def __init__(self, 4096): # only default arguments here """arguments to this function show up as parameters in GRC""" gr.sync_block.__init__( self, name='Embedded Python Block', # will show up in GRC in_sig =[ (np.complex64,4096),(np.complex64, 4096)], out_sig =[(np.complex64,4096),(np.complex64, 4096)] ) def work(self, input_items, output_items): """example: multiply with constant""" output_items[0][:] = input_items[0][:] output_items[1][:] = input_items[1][:] return len(output_items[0]) This code works when I make a synthetic example, but when I stream out of the N310 it doesn't seem to work. Am I doing something wrong? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Digital TV Clock recovery using N310 and GNUradio
Hey all, I'd like to recover the clock tone of a digital TV signal on one USRP N310 and use it as the clock input to another N310. Does anyone have experience doing something like this? I could use some pointers. -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] How to periodically write files using USRP and GNUradio
Hey all, I'd like to know how to write short files of streamed USRP data periodically using GNUradio. For instance, I'd like the USRP to automatically record 5 seconds of data every 10 minutes. It does not matter to me whether the USRP is constantly on and most of the data is being discarded, or if the USRP wakes up every 10 minutes to record the data before sleeping. Whichever is easiest to achieve is fine by me. Does anyone have experience doing this kind of thing? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Absolute dB
Hey all, I calculated the theoretical noise floor for a signal with bandwidth 1 MHz being detected at an N310 (6.8dB noise figure) and found it to be around -106 dBm, but then when I ran my N310 I was seeing the noise floor closer to -120 dB. The plot (made from) GNUradio is labeled as 'Absolute dB' but I am unsure what this means. Is absolute dB supposed to be dB compared to a Watt or does it mean something else? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 time offset between TX RF Outputs
Here's a google drive link with images of the phase drift between rx4 and tx 1&2, and tx 3&4 https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner wrote: > Hi guys, > > Maybe I could jump in and share some related results. My group has been > developing a MIMO system with N310 units. We did a test sounding recently > where we sent 4, length 4096, orthogonal multitone signals from the > transmitters to the receivers and processed the data by finding the channel > response between each transmitter and receiver pair (16 in total) and > recording the magnitude and phase of the arrival spikes between each pair. > > We took several seconds of data and processed it in length 4096 chunks > (around 1500 chunks in total) and looked at the phase difference between > transmitter pairs as time progressed. Since transmitters 1 and 2 are > sharing an LO and our setup was not moved during the sounding we expected > to see a constant phase difference between transmitters 1 and 2 and a > single receiver (same with tx 3 and 4), but we saw some drift. Worse yet, > not all LO sharing pairs drifted in the same way, some didn't drift much at > all while some drifted in linear or non-linear patterns. > > If you're all fine with me breaking the rules I can attach some png images > of what we recorded so you can see what it looks like. Later this week > we'll repeat the experiment but leave the machines running longer to see if > the drift diminishes as the machines run longer. > > Cheers, > -Mark > > > > > > On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Serge, >> >> Are you measuring the phase offset between the TX0 and TX2 signals in a >> steady-state case, or the time difference in the start of those signals? >> >> In the former case, your results could be impacted by the lack of >> internal LO sharing between daughterboards. I would fully expect an unknown >> phase offset between channels 0 and 2 every time you reconfigure the >> device. In the latter case, it sounds like a start trigger mismatch like >> Marcus mentioned. >> >> Can you share more details as to how you're measuring the phase offset? >> >> Thanks, >> -Daniel >> >> >> >> On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image >>> >>> I can try to use lower tx start times to see if the time offset changes >>> with that. >>> >>> Thanks, >>> Serge >>> >>> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech >>> wrote: >>> On 11/07/2018 09:31 PM, Serge Malo wrote: Yes: We only use one streamer for all RF outputs, and send time_spec with each call to the streamer's send method. We reset the internal time with set_time_unkown_pps(0), and program the first samples to be streamed at a time of 0.800s. It is basically the same code we used on the X300/X310. Thanks, Serge Well, that is quite strange--the magnitude of the time offsets is larger than I would expect. Perhaps someone from the N310 team can comment? Serge, are you using the latest UHD and system image versions for the N310? On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote: > > Hi all, > > We are trying to send 4 synchronous signals from the 4 Tx ports of the > N310. > We are using UHD 3.13.1.0 RC1 under Ubuntu. > Central Freq = 1575.42 GHz and 1227.6 MHz > Master Clock rate = 153.6 MHz > > We would expect to have less than 3ns offset between all TX ports of > the N310, like we do with the X300/X310. However, we have measured 4700ns > between TX RF ports 0 and port 2. > We have tried the next things with no more success: > - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps > - Init with the device options "init_cals=ALL" and "force_reinit=1" > - Use the internal GPSDO > - Use clock_source=external and time_source=external (from an > Octoclock). > > Can you tell us: > -What time offset between TX RF ports we should expect to achieve? > -Is there anything else we can try to reduce this offset to less than > 3ns? > > Best regards, > Serge > > > How are you setting up your TX streamer? Is it time-tagged to start > at a particular device time? > > > > ___ > 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] N310 time offset between TX RF Outputs
Hi guys, Maybe I could jump in and share some related results. My group has been developing a MIMO system with N310 units. We did a test sounding recently where we sent 4, length 4096, orthogonal multitone signals from the transmitters to the receivers and processed the data by finding the channel response between each transmitter and receiver pair (16 in total) and recording the magnitude and phase of the arrival spikes between each pair. We took several seconds of data and processed it in length 4096 chunks (around 1500 chunks in total) and looked at the phase difference between transmitter pairs as time progressed. Since transmitters 1 and 2 are sharing an LO and our setup was not moved during the sounding we expected to see a constant phase difference between transmitters 1 and 2 and a single receiver (same with tx 3 and 4), but we saw some drift. Worse yet, not all LO sharing pairs drifted in the same way, some didn't drift much at all while some drifted in linear or non-linear patterns. If you're all fine with me breaking the rules I can attach some png images of what we recorded so you can see what it looks like. Later this week we'll repeat the experiment but leave the machines running longer to see if the drift diminishes as the machines run longer. Cheers, -Mark On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Serge, > > Are you measuring the phase offset between the TX0 and TX2 signals in a > steady-state case, or the time difference in the start of those signals? > > In the former case, your results could be impacted by the lack of internal > LO sharing between daughterboards. I would fully expect an unknown phase > offset between channels 0 and 2 every time you reconfigure the device. In > the latter case, it sounds like a start trigger mismatch like Marcus > mentioned. > > Can you share more details as to how you're measuring the phase offset? > > Thanks, > -Daniel > > > > On Thu, Nov 8, 2018 at 5:30 AM Serge Malo via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Yes: we are using UHD 3.13.1.0 RC1, with the latest file system image >> >> I can try to use lower tx start times to see if the time offset changes >> with that. >> >> Thanks, >> Serge >> >> On Wed, 7 Nov 2018 at 21:44, Marcus D. Leech >> wrote: >> >>> On 11/07/2018 09:31 PM, Serge Malo wrote: >>> >>> Yes: >>> We only use one streamer for all RF outputs, and send time_spec with >>> each call to the streamer's send method. >>> We reset the internal time with set_time_unkown_pps(0), and program the >>> first samples to be streamed at a time of 0.800s. >>> It is basically the same code we used on the X300/X310. >>> >>> Thanks, >>> Serge >>> >>> Well, that is quite strange--the magnitude of the time offsets is larger >>> than I would expect. >>> >>> Perhaps someone from the N310 team can comment? >>> >>> Serge, are you using the latest UHD and system image versions for the >>> N310? >>> >>> >>> >>> On Wed, 7 Nov 2018 at 21:03, Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> On 11/07/2018 08:53 PM, Serge Malo via USRP-users wrote: Hi all, We are trying to send 4 synchronous signals from the 4 Tx ports of the N310. We are using UHD 3.13.1.0 RC1 under Ubuntu. Central Freq = 1575.42 GHz and 1227.6 MHz Master Clock rate = 153.6 MHz We would expect to have less than 3ns offset between all TX ports of the N310, like we do with the X300/X310. However, we have measured 4700ns between TX RF ports 0 and port 2. We have tried the next things with no more success: - Sampling rates of 25.6MSps, 38.4Msps, 76.8Msps - Init with the device options "init_cals=ALL" and "force_reinit=1" - Use the internal GPSDO - Use clock_source=external and time_source=external (from an Octoclock). Can you tell us: -What time offset between TX RF ports we should expect to achieve? -Is there anything else we can try to reduce this offset to less than 3ns? Best regards, Serge How are you setting up your TX streamer? Is it time-tagged to start at a particular device time? ___ 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 >> > > > -- > > Daniel Jepson > > Digital Hardware Engineer > > National Instruments > > > > O: +1.512.683.6163 > > daniel.jep...@ni.com > ___ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Mark Wagner University of California San Diego
[USRP-users] No devices found for ------->
Hi all I've got an N310 USRP which I was trying to update the FPGA image to. I've got the host computer hooked up to the N310 through an RJ-45 cable going into SFP+0. I followed the instructions on the Getting Started page and tried to update using uhd_image_loader --args "type=n3xx,addr=192.168.10.2,fpga=HG" but there was some error and now I am unable to talk to the N310. When I try: uhd_usrp_probe I get: [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501; UHD_3.13.0.HEAD-0-g0ddc19e5 Error: LookupError: KeyError: No devices found for -> Empty Device Address And I am similarly unable to ping or send commands to the N310 anymore. Does anyone have an idea how to fix this? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Can't change MTU on N310
Hi, Right now I'm trying to change the MTU on eth0 to be 8000 as suggested by the Hardware driver and USRP manual but I'm getting an error I'll start my N310 with a 10Gbe connection, screen in as instructed, and type ifconfig eth0 mtu 8000 then get error message eth0: Invalid MTU 8000 requested, hw max 1500 My understanding is that the N310 thinks it can't change the MTU past 1500, but this seems wrong. Has anyone else had this problem? -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Unable to install UHD
Hi USRP mailing list, I'm having trouble installing UHD from source. I've been following the instructions on this page https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux but I keep running into the same problem. I've cloned the latest version from git, added the proper directories, and followed the instructions but I'm getting an error when I use cmake ../ % -- Configuring the python interpreter... -- Python interpreter: /usr/bin/python2.7 -- Override with: -DPYTHON_EXECUTABLE= -- Working off of feature or development branch. Updating version number. -- Using UHD Images Directory: OFF -- Build type not specified: defaulting to release. -- -- Configuring Boost C++ Libraries... -- Looking for optional Boost components... -- Boost version: 1.66.0 -- Found the following Boost libraries: -- python -- Looking for required Boost components... -- Boost version: 1.66.0 -- Found the following Boost libraries: -- chrono -- date_time -- filesystem -- program_options -- regex -- system -- unit_test_framework -- serialization -- thread -- atomic -- Boost include directories: /opt/local/include -- Boost library directories: /opt/local/lib -- Boost libraries: /opt/local/lib/libboost_chrono-mt.dylib;/opt/local/lib/libboost_date_time-mt.dylib;/opt/local/lib/libboost_filesystem-mt.dylib;/opt/local/lib/libboost_program_options-mt.dylib;/opt/local/lib/libboost_regex-mt.dylib;/opt/local/lib/libboost_system-mt.dylib;/opt/local/lib/libboost_unit_test_framework-mt.dylib;/opt/local/lib/libboost_serialization-mt.dylib;/opt/local/lib/libboost_thread-mt.dylib;/opt/local/lib/libboost_atomic-mt.dylib -- -- Python checking for Python version 2.7 or greater -- Python checking for Python version 2.7 or greater - found -- -- Python checking for Mako templates 0.4.2 or greater -- Python checking for Mako templates 0.4.2 or greater - "import mako" failed -- -- Python checking for requests 2.0 or greater -- Python checking for requests 2.0 or greater - "import requests" failed -- -- Python checking for numpy 1.7 or greater -- Python checking for numpy 1.7 or greater - found -- -- Configuring LibUHD support... -- Dependency Boost_FOUND = 1 -- Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE -- Dependency HAVE_PYTHON_MODULE_MAKO = FALSE CMake Error at cmake/Modules/UHDComponent.cmake:59 (MESSAGE): Dependencies for required component LibUHD not met. Call Stack (most recent call first): CMakeLists.txt:431 (LIBUHD_REGISTER_COMPONENT) -- Configuring incomplete, errors occurred! See also "/Users/noiselab/Documents/uhd_install/uhd/host/build/CMakeFiles/CMakeOutput.log". See also "/Users/noiselab/Documents/uhd_install/uhd/host/build/CMakeFiles/CMakeError.log". noiselabs-MacBook-Pro:build noiselab$ %% it looks like Mako can't be found, but when I install mako using pip it tells me I'm on the most recent version and indeed I can find the most recent version when I search for it. I should mention I have 3 versions of Python installed, 2.7, 3.6 and 3.7, and when I use cmake I actually input cmake -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2.7 ../ so the desired path is known. Mako was installed on python2.7 with the following command python2.7 -m pip install mako -Mark -- Mark Wagner University of California San Diego Electrical and Computer Engineering ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
