[Discuss-gnuradio] controlling Digital I/O from GRC
Hi, I would like to control the digital I/O (8 of the lines) of the USRP X300 from GNU Radio Companion. Has anyone attempted this? From reading the gpio_api online, it sounds like I need to discover the digital I/O by using the get_gpio_banks function in multi_usrp, and then use usrp_x300-set_gpio_attr() to control the digital I/O. Is there a way to do this from GNU Radio Companion? My experience thus far has been dragging and dropping blocks in GRC. If I make a block from scratch, I am assuming I will need to pass the usrp_x300 handle into the block to make the calls (I don't have experience making my own GRC blocks). I would also need a user interface to assign the value for the output of the digital I/O. Any recommendations on where to begin? Thanks! -Ben smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] X300 PCIe issues
Does the 10 Gigabit Ethernet PCI-express adapter card sold by Ettus work with Ubuntu 14.04 LTS? From the previous discussion, it sounds like the PCIe interface does not work with the new kernel, but that 10GigE might work. -Ben From: discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org [mailto:discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org] On Behalf Of Robert McGwier Sent: Monday, April 28, 2014 7:26 AM To: Marcus D. Leech Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] X300 PCIe issues It needed to be said, but my only goal is to ACCEPT AND LOVE 10GigE until and unless you demand the low latency afforded by the PCIe interface. The things I am working on demand that we meet the tight timing requirements of open specification waveforms. PCIe was required. The x3x0 series are major accomplishments for Ettus and should they just get past the major changes that 14.04 LTS and then BE EXPLICIT about which kernels they will support, etc. They should be good until the next LTS comes out. Bob On Sun, Apr 27, 2014 at 5:48 PM, Marcus D. Leech mle...@ripnet.com wrote: On 04/27/2014 05:32 PM, Sylvain Munaut wrote: While the top side API is very stable so that applications hardly *ever* experience API changes that require on-going tedious maintenance, the same cannot be said of code that runs in the kernel. Quite the contrary. Linus and friends *routinely and regularly* change critical APIs within the kernel, sometimes even across minor version revs of the same codebase. Come on, it's not _that_ bad ... Kernel API are stable inside the maintenance release, so they can only change like every 2 month at most. And when they change, finding the relevant commit is pretty easy with git and it will show exactly what need to be changed in your driver (because that commit fixed every other driver in-tree for the same change). And searching LKML will also give all the gory details. It's like half a day or one day of work at the most. So 1 day of code maintenance every 2 month to keep your codebase current is not what I'd call a nightmare. And if you want to avoid even that, just get your module merged upstream, it will be adapted for you free of charge when APIs change. And wrt to maintaining the same code building for several kernel, that's just the wrong approach. Just maintain different version in different branches. When the code is well written, the driver specific part will be decoupled enough from the kernel api part that there will hardly be any conflicts. And when your driver core function doesn't change (and for the NI driver, it seems it hasn't changed it's functionality for a while AFAICT, just added new kernel support, but I could be wrong on that), then it's even easier to just release a new code for each new kernel. For only a few revisions appart, you might be ok with #ifdef, but if you're trying to go back to ancient times, like the NI module which seems to support 2.6.0 (that's 11 years ago ), yeah there is going to be some serious changes ... Cheers, Sylvain PS: and yeah, for 2 years or so, I maintained an in-house PCIe driver for a FPGA board, so I did experience that. So, would we accept an applications-layer API that changed roughly every two months? I would argue, no, we wouldn't. But people developing in kernel land seem to accept it as some kind of necessary gospel. I reject that notion. Just because kernel-land is where all the kewl kids play is not a good reason to break things on a regular basis. Anyway, this thread is now going fairly far afield -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Bob McGwier Co-Owner and Technical Director, Federated Wireless, LLC Professor Virginia Tech Senior Member IEEE, Facebook: N4HYBob, ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] sample time alignment in GRC
Hi, I have two USRP X310 devices that I am trying to time align in GNU Radio Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS signals to the other one. The GPS is locked. Ideally I would have matched length cables for 10 MHz reference and 1 PPS, but I think my setup is close enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with matched length cables, USRP output sampling rate = 5M, USRP center frequency = 10M.) I am using WX GUI Scope Sink to look at the magnitudes of each stream from the USRP devices. I expect to see no/minimal delay between the two signal streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run between the two signal streams. The period of the signal is 50 samples, so the maximum delay difference is 25 samples. Am I missing something in my configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect time alignment between the two sample streams. Is there a GRC block for forcing time alignment? Thanks! -Ben smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sample time alignment in GRC
Hi All, I am still having trouble time aligning sample streams from two USRP X310 devices. In GRC I noticed a random time offset from run to run in the two data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also see a random time offset from run to run in the two data streams (8, 18, and 24 sample offset). I verified that the two data streams that I am inputting into the X310 devices are time aligned using a physical scope. My GRC setup: USRP Source 1 (with internal GPSDO-MINI) - Sync = unknown PPS - Mb0: Clock Source = Default - Mb0: Time Source = Default USRP Source 2 - Sync = unknown PPS - Mb0: Clock Source = External - Mb0: Time Source = External For looking at the data streams I have USRP Source - Complex to Mag - WX GUI Scope Sink. For recording the data streams I have USRP Source - Head (5K) - File Sink (Unbuffered: OFF) Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable. PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” SMA cable. RF input to USRP devices is a pulsed RF signal, to make it easier to look at time offset. GPS on USRP 1 is locked; however, I work with tall buildings completely surrounding me and so I don’t know the strength of the GPS lock. I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but until then.. Does anyone have any other ideas for getting time-aligned samples from run to run in GRC, or what I am doing wrong? I would expect at most a minimal constant time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked. Thanks! -ben From: Marcus Leech [mailto:mle...@ripnet.com] Sent: Friday, June 13, 2014 2:04 PM To: Lapointe, Benjamin - 1008 - MITLL Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sample time alignment in GRC Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and all of them should use time synch of unknown PPS. Also, there has been a bug in the scope sink (dunno if fixed) where samples are *not* time-aligned in the scope sink. The except is that a complex-pair will be time-aligned internally, but not necessarily to other streams being displayed. on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL blapoi...@ll.mit.edu wrote: Hi, I have two USRP X310 devices that I am trying to time align in GNU Radio Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS signals to the other one. The GPS is locked. Ideally I would have matched length cables for 10 MHz reference and 1 PPS, but I think my setup is close enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with matched length cables, USRP output sampling rate = 5M, USRP center frequency = 10M.) I am using WX GUI Scope Sink to look at the magnitudes of each stream from the USRP devices. I expect to see no/minimal delay between the two signal streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run between the two signal streams. The period of the signal is 50 samples, so the maximum delay difference is 25 samples. Am I missing something in my configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect time alignment between the two sample streams. Is there a GRC block for forcing time alignment? Thanks! -Ben _ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sample time alignment in GRC
I am using BasicRX daughterboards, each sampling a single real-mode signal. -ben From: discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org [mailto:discuss-gnuradio-bounces+blapointe=ll.mit@gnu.org] On Behalf Of Marcus D. Leech Sent: Tuesday, June 17, 2014 10:06 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sample time alignment in GRC On 06/17/2014 09:58 AM, Lapointe, Benjamin - 1008 - MITLL wrote: Hi All, I am still having trouble time aligning sample streams from two USRP X310 devices. In GRC I noticed a random time offset from run to run in the two data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also see a random time offset from run to run in the two data streams (8, 18, and 24 sample offset). I verified that the two data streams that I am inputting into the X310 devices are time aligned using a physical scope. My GRC setup: USRP Source 1 (with internal GPSDO-MINI) Sync = unknown PPS Mb0: Clock Source = Default Mb0: Time Source = Default USRP Source 2 Sync = unknown PPS Mb0: Clock Source = External Mb0: Time Source = External For looking at the data streams I have USRP Source - Complex to Mag - WX GUI Scope Sink. For recording the data streams I have USRP Source - Head (5K) - File Sink (Unbuffered: OFF) Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable. PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” SMA cable. RF input to USRP devices is a pulsed RF signal, to make it easier to look at time offset. GPS on USRP 1 is locked; however, I work with tall buildings completely surrounding me and so I don’t know the strength of the GPS lock. I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but until then.. Does anyone have any other ideas for getting time-aligned samples from run to run in GRC, or what I am doing wrong? I would expect at most a minimal constant time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked. Thanks! -ben From: Marcus Leech [mailto:mle...@ripnet.com] Sent: Friday, June 13, 2014 2:04 PM To: Lapointe, Benjamin - 1008 - MITLL Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sample time alignment in GRC Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and all of them should use time synch of unknown PPS. Also, there has been a bug in the scope sink (dunno if fixed) where samples are *not* time-aligned in the scope sink. The except is that a complex-pair will be time-aligned internally, but not necessarily to other streams being displayed. on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL blapoi...@ll.mit.edu wrote: Hi, I have two USRP X310 devices that I am trying to time align in GNU Radio Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS signals to the other one. The GPS is locked. Ideally I would have matched length cables for 10 MHz reference and 1 PPS, but I think my setup is close enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with matched length cables, USRP output sampling rate = 5M, USRP center frequency = 10M.) I am using WX GUI Scope Sink to look at the magnitudes of each stream from the USRP devices. I expect to see no/minimal delay between the two signal streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run between the two signal streams. The period of the signal is 50 samples, so the maximum delay difference is 25 samples. Am I missing something in my configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect time alignment between the two sample streams. Is there a GRC block for forcing time alignment? Thanks! -Ben _ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio What daughtercards are you using again? There *will* be a random phase offset between the two sides here, because GRC flow-graphs can't take advantage of timed-commands to phase-align the LOs on WBX and SBX cards. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org smime.p7s Description: S/MIME cryptographic signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] sample time alignment in GRC
Nicholas, Thanks for your message, I implemented your changes to my top_block.py file, but was unable to get the two data streams from the X310s to start sampling at the same time. I verified with the print statements that python was doing the time conversions and math correctly. I used a WX Scope Sinc and analyzed recorded data in MATLAB to look at time offsets in the two data streams. I also set the 1 second waits to 2 second waits. I generally saw time offsets in the range of 5 to 25 samples (1 to 5 usec with 5MHz output), and one occurrence of ~200 sample offset between the two sample streams. Nicholas, how did you verify sample time alignment? I attached my top_block python file, in case anyone has time to look at it. Any other ideas/comments? Thanks! -Ben From: Linnenkamp, Nicholas [mailto:nlinnenk...@appcomsci.com] Sent: Tuesday, June 17, 2014 1:54 PM To: Robert Kossler; Lapointe, Benjamin - 1008 - MITLL Cc: discuss-gnuradio@gnu.org Subject: RE: [USRP-users] sample time alignment in GRC Ben/Rob, I addressed the issue of getting time aligned samples going for USRP devices sometime back. I had similar issues until I did a deep dive and worked out some of the problems. There is a bit more to the process than just setting sync and reference sources. http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-April/009277.html That contains code for getting gnu-radio to perform the required initialization for the devices so that they sample at the same time. Perhaps someone from the gnuradio camp can figure out how to do it automagically. Nicholas From: USRP-users [mailto:usrp-users-boun...@lists.ettus.com] On Behalf Of Robert Kossler via USRP-users Sent: Tuesday, June 17, 2014 10:28 AM To: Lapointe, Benjamin - 1008 - MITLL Cc: usrp-us...@lists.ettus.commailto:usrp-us...@lists.ettus.com; discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [USRP-users] sample time alignment in GRC Hi Ben, I am having a similar (but not identical issue). I have a single X310 for which I am trying to make sure both channels are time aligned. I have tried both the internal PPS signal and an external PPS signal. I noticed channel-to-channel time delays of 1, 2, or 3 clock cycles (at clock rate, not sample rate) which varied from run to run. My measurements were done with a modified rx_samples_to_file program and Matlab processing. I have not yet duplicated using GRC. Rob On Tue, Jun 17, 2014 at 9:58 AM, Lapointe, Benjamin - 1008 - MITLL via USRP-users usrp-us...@lists.ettus.commailto:usrp-us...@lists.ettus.com wrote: Hi All, I am still having trouble time aligning sample streams from two USRP X310 devices. In GRC I noticed a random time offset from run to run in the two data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also see a random time offset from run to run in the two data streams (8, 18, and 24 sample offset). I verified that the two data streams that I am inputting into the X310 devices are time aligned using a physical scope. My GRC setup: USRP Source 1 (with internal GPSDO-MINI) - Sync = unknown PPS - Mb0: Clock Source = Default - Mb0: Time Source = Default USRP Source 2 - Sync = unknown PPS - Mb0: Clock Source = External - Mb0: Time Source = External For looking at the data streams I have USRP Source - Complex to Mag - WX GUI Scope Sink. For recording the data streams I have USRP Source - Head (5K) - File Sink (Unbuffered: OFF) Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6” SMA cable. PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6” SMA cable. RF input to USRP devices is a pulsed RF signal, to make it easier to look at time offset. GPS on USRP 1 is locked; however, I work with tall buildings completely surrounding me and so I don’t know the strength of the GPS lock. I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but until then.. Does anyone have any other ideas for getting time-aligned samples from run to run in GRC, or what I am doing wrong? I would expect at most a minimal constant time offset between data streams if the 10 MHz Ref and 1 PPS signals are locked. Thanks! -ben From: Marcus Leech [mailto:mle...@ripnet.commailto:mle...@ripnet.com] Sent: Friday, June 13, 2014 2:04 PM To: Lapointe, Benjamin - 1008 - MITLL Cc: discuss-gnuradio@gnu.orgmailto:discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] sample time alignment in GRC Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and all of them should use time synch of unknown PPS. Also, there has been a bug in the scope sink (dunno if fixed) where samples are *not* time-aligned in the scope sink. The except is that a complex-pair will be time-aligned internally, but not necessarily to other streams being displayed. on Jun 13, 2014, Lapointe, Benjamin - 1008
