[USRP-users] Questions regarding BasicTX Daughterboard
Dear All:
I have some questions regarding BasicTX Daughterboard. It seems that this
board does not have complex design such as analog mixer. But it can be set
with a carrier frequency in GNU Radio. My questions are:
1) When I use this daughterboard and set its carrier frequency to nonzero
(e.g., 50 MHz), is the frequency up-conversion done in the digital domain
by the motherboard's FPGA?
2) If I use this daughterboard in IQ mode (i.e., setting frontend to AB),
what are the output signal at antenna ports Tx-A and Tx-B? Denote S(t) as
the digital baseband signal and fc as the carrier frequency specified in
GNU Radio, are the output signals at Tx-A and Tx-B ports
Re{S(t)}*cos(2*pi*fc*t) and Im{S(t)}*sin(2*pi*fc*t), respectively? If not,
what is the output signals at those two antenna ports?
Thank you in advance!
Hua
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] get_rx_antenna() bug in RFNoC x300_radio_ctrl_impl.cpp
Along the same lines, the x300_radio_ctrl_impl code implements set_rx_bandwidth() and get_rx_bandwidth() but not set_tx_bandwidth() and get_tx_bandwidth(). The result is that the Tx functions call the base class which doesn't really do anything apart from locally storing the setting. Rob On Fri, Nov 16, 2018 at 1:56 PM Nate Temple wrote: > Hi Rob, > > Thanks for bringing this to our attention. We will file an issue on our > internal bug tracker and get it resolved. > > Regards, > Nate Temple > > On Fri, Nov 16, 2018 at 10:41 AM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> I am using the RFNoC radio_ctrl API with my X310 and when I call >> get_rx_antenna() , I get an empty string. The problem is in >> x300_radio_ctrl_impl.cpp. The corresponding set_rx_antenna() function >> should be calling the base class radio_ctrl_impl->set_rx_antenna() so that >> the locally cached value is updated. But, this call is missing. Thus, any >> call to get_rx_antenna() which is not overridden for the X310 always >> returns an empty string. >> Rob >> ___ >> 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] get_rx_antenna() bug in RFNoC x300_radio_ctrl_impl.cpp
Hi Rob, Thanks for bringing this to our attention. We will file an issue on our internal bug tracker and get it resolved. Regards, Nate Temple On Fri, Nov 16, 2018 at 10:41 AM Rob Kossler via USRP-users < usrp-users@lists.ettus.com> wrote: > I am using the RFNoC radio_ctrl API with my X310 and when I call > get_rx_antenna() , I get an empty string. The problem is in > x300_radio_ctrl_impl.cpp. The corresponding set_rx_antenna() function > should be calling the base class radio_ctrl_impl->set_rx_antenna() so that > the locally cached value is updated. But, this call is missing. Thus, any > call to get_rx_antenna() which is not overridden for the X310 always > returns an empty string. > Rob > ___ > 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
[USRP-users] get_rx_antenna() bug in RFNoC x300_radio_ctrl_impl.cpp
I am using the RFNoC radio_ctrl API with my X310 and when I call get_rx_antenna() , I get an empty string. The problem is in x300_radio_ctrl_impl.cpp. The corresponding set_rx_antenna() function should be calling the base class radio_ctrl_impl->set_rx_antenna() so that the locally cached value is updated. But, this call is missing. Thus, any call to get_rx_antenna() which is not overridden for the X310 always returns an empty string. Rob ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Timeout On Chan 0 Error
Peter, I know that this is an old thread, but I was wondering if you remember if you've ever solved this? I think that I am running into the same issue with my RFNOC OOT block. Thanks. Hi All, Tutorial aside, I was running the rfnoc_fir example from GNU Radio Companion. At 10M sample rate, the example works with no errors. At 50M sample rate the graphs show data while the terminal prints "overrun on chan 0" errors, then eventually the graphs freeze and the terminal prints "timeout on chan 0". Is this a problem with delays inside the FPGA with the RFNoC blocks? Can the timeout be changed to a larger number for chan 0? Cheers On Tue, May 22, 2018 at 8:08 PM, Peter Sanchez wrote: > Hello, >> I have a USRP X310 and just finished going through the RFNoC Getting > Started tutorial. After uploading the desired blocks to the FPGA, I wanted > to run the example in GNU Radio Companion, like in the tutorial, but the > terminal keeps showing "timeout on chan 0" errors. The Link light flashes > between green and amber while this happens. >> I swapped the custom gain block that I made during the tutorial for the > RFNoC Digital Gain block, in the GNU Radio Companion and in the FPGA, but > the error persists. > If I remove either Gain blocks and connect the DDC straight to the Copy > block, the timeout errors stop. >> Does any one know what is wrong? I'm running Ubuntu and have the latest > RFNoC files installed using the methods described in the tutorial. >> Thanks >> ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] N310 Rack mount Kit
Hi David, You can find the N3xx rack mount kit here: https://www.ettus.com/product/details/n3xx-rack-mount Regards, Nate Temple On Fri, Nov 16, 2018 at 8:19 AM Bengtson, David E. via USRP-users < usrp-users@lists.ettus.com> wrote: > Is there a 19” Rack mount Kit for the N310 available or planned? > > Thanks > > Dave > > > > > ___ > 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
[USRP-users] N310 Rack mount Kit
Is there a 19” Rack mount Kit for the N310 available or planned? Thanks Dave smime.p7s Description: S/MIME cryptographic signature ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] 2x N200 GPSDO PPS relative drift
Thanks for the tip Michael. I'm on travel at the moment, and will try this next week when I get back to the lab. I'll report my findings to mailing list. Cheers Stephan On Wed, Nov 14, 2018 at 1:09 AM Michael West wrote: > Hi Stephan, > > Try moving the GPSDO power from the J509 connector to the J102 connector > on the N200 motherboard. J102 is 6V AUX power and does not sag when > running. The provided cable is a little short, so you will have to get > creative. Give that a try and let us know if it solves the problem. > > Regards, > Michael > > On Sat, Nov 10, 2018 at 9:33 AM Stephan Esterhuizen via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi Robin, >> >> Thank you for the reply. I have debugged the problem more and realized >> two issues. >> >> 1) The massive drift of 14 microseconds/second was due me using a 6V, 2A >> brick supply. This is my fault! After switching it out for a 3A supply, I'm >> able to get the GPSDO to lock (GPS_SERVO message returns 6 for lock status >> field) >> 2) Once you start collecting data, GPSDO PPS & 10 MHz start drifting from >> UTC. As mentioned, this is probably due to a voltage sag on the 6V supply >> for the Firefly GPSDO. >> >> For issue 2, I measured the nominal voltage to GPSDO (USRP N200 J509) to >> be 5.678V (+-2mV), then once I start a data collection, the minimum voltage >> I see is 5.532V, then after a few seconds of data collection it reaches a >> "steady state" of 5.545 V. This small change of (5.678-5.545 V) 133 mV is >> enough to give the PPS a drift of about 5-8 nsec/second. Eventually the >> GPSDO feedback loop catches this and steers it back to something more >> acceptable. For reference, the voltage at the input to N200 (J101) is >> 5.901V+-5mV when idle and collecting samples. >> >> This slight deviation of < 100 nanoseconds due to voltage change is fine >> for my application, I realized I can just read back the GPS_SERVO sensor >> and get the actual offset from UTC to correct any timestamps. >> >> Regards >> >> Stephan >> >> >> On Fri, Nov 9, 2018 at 5:09 PM Robin Coxe wrote: >> >>> Hi Stephan. Your issue looks similar to one that has been previously >>> reported. The Hardware Sustaining Engineering team is currently >>> investigating. >>> >>> Would it be possible for you to try powering the GPSDO module from a lab >>> supply instead of plugging it in to the N210 motherboard and checking if >>> your issue still persists? >>> That would help us determine if you are experiencing the same problem. >>> Another helpful measurement would be to measure the voltage drop of the 6V >>> wall wart when the GPSDO IS powered by the N210 motherboard. >>> >>> We will keep you and list updated on the progress of the investigation. >>> >>> -Robin >>> >>> >>> On Fri, Nov 9, 2018 at 3:06 AM Stephan Esterhuizen via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> Hi All, I have two N200 USRPs with Jackson-Labs Firefly 1A GPSDO. I'm doing a very basic test, where I have a common active GPS antenna split 2 ways (with DC block on one N200 GPS antenna port). I then watch the 1PPS from each GPSDO on a scope, and unfortunately see the PPS drift by as much as 14 microseconds per second relative to each other. When this offset reaches about 1.5-2.0 milliseconds, I see the PPS relative offset "snap" down to a few micro seconds error, but then they immediately start drifting apart again. The N200 GPSDO reports they're locked. I wrote some quick python code to query sensors: -- FIRST N200: -- [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929 [INFO] [USRP2] Setting references to the internal GPSDO GPS lock status: locked GPS_GPGGA: $GPGGA,095011.00,.x,N,.x,E,1,10,0.9,320.7,M,46.9,M,,*6C GPS_SERVO: 18-11-09 3888 94089 21.81 2.08E-11 13 10 6 0x0 GPS epoch time: 1541757012 seconds Ref: locked -- SECOND N200 -- [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev 0.929 [INFO] [USRP2] Setting references to the internal GPSDO GPS lock status: locked GPS_GPGGA: $GPGGA,095027.00,.x,N,.,E,1,08,1.1,317.9,M,46.9,M,,*63 GPS_SERVO: 18-11-09 2948 12 796.02 9.59E-09 13 8 2 0x326 GPS epoch time: 1541757029 seconds Ref: locked At this point, it might be a question for Jacksonlabs, since I'm not really using any N200 functions except for reading back the Ublox GPS NMEA strings. Has anyone seen this kind of behavior before? I'm suspecting the GPS_SERVO field might shed some light, but don't quite know how to read it. Thanks for any pointers Stephan ___ USRP-users
Re: [USRP-users] OctoClock Without GPS Signal
Thank you very much! On Thu, Nov 15, 2018, 18:07 Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com wrote: > On 11/15/2018 11:52 AM, Dave NotTelling via USRP-users wrote: > > Can the GPSDO OctoClock free run without GPS? I've had some PPS > > generators that claim to have the ability to free run, but require a > > GPS signal to start that process up. > > > > Thanks! > > > > -Dave > > > > > IF you have an Octoclock without the built-in GPSDO module, then it > *requires* external 1PPS and 10Mhz inputs--it's JUST a distributor. >But if you have the -G, with the built-in GPSDO, I believe that it > will produce 1PPS and 10Mhz outputs in a "free running" mode until it >gets lock. > > > > ___ > 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] Number of receivers at the same time USRP X-310
Hi, TwinRx is Rx only card. Look at the spec here: https://www.ettus.com/product/details/TwinRX Regarding power measurement calibration this is how it could work (so you can measure signal power entering Rx port of your USRP): Connect to the USRP port an RF signal source with known power 'Px' (let's assume it is a sine wave). Then you can record this signal (i.e. with use of GNU Radio) and compute it's uncalibrated power as Markus described it. In Octave/Matlab this can be written as (you can use 'read_complex_binary' function that is distributed with GNU Radio to read signal samples 'x'): Px_uncal = sum(x.*conj(x))/length(x) and then you can compute simple calibration factor: c=Px/Px_uncal Now you can use it to compute estimate of power 'Py' of another RF signal 'y': Py_uncal = sum(y.*conj(y))/length(y) Py = c * Py_uncal === The calibration factor factor 'c' will be true for some particular frequency range (how wide depends on the frequency response of the receiver) and at some range of input signal power. It depends also on temperature and many other variables. Best Regards, Piotr Krysik W dniu 15.11.2018 o 10:56, Maria Jesus Cañavate Sanchez pisze: > Hi Piotr, > > Thank you for your answer. > > One last question, if you get the twinRX daughter cards to be able to > use 4 rx at the same time, can you still have access to the 2 tx and 2 > rx when convenient? Or the 4 rx are fixed? > > Thank you very much in advance! > > Best regards, > > Maria Jesus > > > On 13/11/2018 12:34, Piotr Krysik via USRP-users wrote: >> Hi, >> >> No, it's not. Each of your UBX-160 has one Rx chain. >> >> BTW somehow it is common confusion that Tx/Rx and Rx2 ports can be used >> to receive signals simultaneously. I have to explain this even to people >> with professor degree in electronic engineering, that behind these ports >> there is one Rx chain and there are switches on UBX/SBX/WBX/etc that >> select to which of these ports this Rx chain is connected. >> >> As Fabian has written there are TwinRX daughter cards, each with two Rx >> chains, that you can use on a USRP X310 to have 4 receivers. >> >> Best Regards, >> Piotr Krysik >> >> W dniu 13.11.2018 o 13:08, Maria Jesus Cañavate Sanchez via USRP-users >> pisze: >>> Hi again, >>> >>> Thank you very much for your answer. I have bought two daughter boards >>> UBX-160, is that enough to have 4 receivers at the same time? >>> >>> Thank you! >>> >>> Best regards, >>> >>> Maria Jesus >>> >>> ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
