[Discuss-gnuradio] multiple tabs
hi thanks for the reply,but i want some paramters to be specified in one tab and some other in other tab.is it possible? pls do help. Ranjini On Sun, Feb 27, 2011 at 12:54 AM, Sivaramakrishnan B C < maverick2...@gmail.com> wrote: Use the notebook block under "misc" caegory in grc. Siva On Sat, Feb 26, 2011 at 7:46 AM, ranjini ram wrote: hi can anybody help me out in creating multiple tabs in a single output window.eg.one tab indicating RF spectrum second IF spectrum and so on.. Thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131
Hello Arya, AS> I was trying to build the gnuradio on yet AS> another machine running Ubuntu 10.10. from AS> source today after checking out the latest AS> code from the dev trunk: I see Ubuntu 10.10 has native packages. Is there a reason why you need to compile it? Perhaps you are looking for the latest and greatest. Youmay have dependency problems. These dependencies may be resolved by installing the native packages. Perhaps you can open Synaptic and install the native gnuradio that way and see if that helps your compile process. Best regards. .. ..-. / -.-- --- ..- / .-. . .- -.. / - .. ... .-.. . - ... / .- ...- . / .- / -... . . .-. Jared Harvey Operator KB1GTT e-mail m...@jaredharvey.com Web page http://jaredharvey.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131
Hi Jared, thanks for that suggestion. Anyway, I realized that I was using GNU compiler gcc-4.6 (experimental) which apparently imposes stricter rules and allows package builds to fail where previous versions used to succeed. So the suggested fix for one typical "ptrdiff_t does not name a type" is #include , which I did in the /usrp/host/swig/python/usrp_prims.cc file, and the build completed to success. Arya On Sun, Feb 27, 2011 at 3:15 AM, Jared Harvey wrote: > Hello Arya, > > AS> I was trying to build the gnuradio on yet > AS> another machine running Ubuntu 10.10. from > AS> source today after checking out the latest > AS> code from the dev trunk: > > I see Ubuntu 10.10 has native packages. Is there a > reason why you need to compile it? Perhaps you are > looking for the latest and greatest. > > You may have dependency problems. These > dependencies may be resolved by installing the > native packages. Perhaps you can open Synaptic and > install the native gnuradio that way and see if > that helps your compile process. > > Best regards. > > .. ..-. / -.-- --- ..- / .-. . .- -.. / - .. ... > .-.. . - ... / .- ...- . / .- / -... . . .-. > > Jared Harvey Operator KB1GTT > > e-mail m...@jaredharvey.com > Web page http://jaredharvey.com > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: FUNCube dongle
schrieb Moeller on 2011-02-26 13:11: > Sync problems? I thought, the "audio" devices implement > a fixed sampling clock and the USB transmission is buffered to > achieve a continuous stream without gaps or clock variations. > Only the PC audio output has a different clock, but that problem > occurs with other external sources too, like the USRPs. The problem arises between system clock and audio clock. While the Audio clock is most probably a free running clock in the device, the computer may have a slightly different time base. Now who is right about the sampling rate? One thing you can do is accept occasional resyncs with small hickups or clicks, that is some lost samples or some extra samples. Or you can resample the stream, which is computational intensive and decreases quality. Or you manage to synchronize the clocks, which is possible with USB. But the USB clock has probably too much jitter for high quality signal sampling... No easy task. Anyway, refer to SDR widget, they have thought of every possible problem and solution. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] book/video (MIT courseware, whatever) recommendations?
National Instruments also has some nice RF tutorials on their web site. In particular, I found this one very helpful in understanding I/Q data: http://zone.ni.com/devzone/cda/tut/p/id/4805 Warm regards, James S. Blachly, MD On Feb 22, 2011, at 6:04 PM, Brett L. Trotter wrote: > Is there one or two books that give a pretty comprehensive, yet low base > communications/DSP knowledge requirement that would be a guided > walkthrough of waves and fields, various forms of modulation, carriers, > filters, sidebands, etc? I'm really looking for something that's either > not a textbook, or not written like one- most textbooks are very dry and > hard to understand without someone guiding the experience and asking the > right questions. I realize the material is fairly dry, so I understand > that it's not going to be a crichton novel, but the less crazy math and > algorithm intensive it is, the better. > > Long story short, what's a good way to get a more solid grasp of how > driving a DAC can create electromagnetic waves, and what can one do with > those waves. I'd really really like to walk away understanding how > complex numbers turn into constellations are really formed as an > electromagnetic wave, etc, and the real guts of some basic things like > FM and DSSS. > > -Brett > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Real-only direct-conversion
I was on a call the other night with someone who asserted that you didn't need an I & Q representation for a direct-conversion receiver, and that I and Q could be synthesized later from a real-mode-only baseband signal. I know that very-early (1940s) direct-conversion receivers didn't use I and Q signal chains, but they were typically used for demodulating AM signals, where the +/- frequency ambiguity wouldn't have been an issue. So, my feeling is that you *absolutely need* the I and Q "form" in order to disambiguate +/- frequencies when dealing with direct-conversion baseband signals. Who's right? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real-only direct-conversion
Yes, it is possible: For a bandpass signal at f_0 with bandwidth 2W, if you sample with rate: Rs=4f_0/(2n+1) where n is an integer you will get the in-phase components at the even samples and the quadrature components at the odd samples. In particular, if you set n= integer part of (f0/2W -1/2) then you can have the minimum required sampling rate (Rs~= 4W) for perfect reconstruction of in-phase and quadrature components without the need of I/Q chain. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usb errors while stopping flowgraph
On Sat, Feb 26, 2011 at 12:34 AM, Brett L. Trotter wrote: > I've got several different flowgraphs here that upon shutting down some > portion of the time, they emit a series of errors and then totally tank > my USB controller on a number of test systems, requiring a full system > reboot to reset the USB (the RHEL6 box I'm using has USB modules > compiled into the kernel, so rmmod isn't an option). The flowgraphs stop > normally about 3/4 times. It seems to be chance when its in some odd > state that it won't shutdown right. > > Errors emitted: > usb_control_msg failed: error sending control message: Connection timed out > write_cmd failed You should consider switching over to the new UHD blocks as the old driver is no longer in active development. You can try building with the libusb-1.0 backend (--with-fusb-tech=libusb1) to see if the problem goes away, but UHD is the long term solution. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 802.11g
On Wed, Feb 16, 2011 at 1:50 PM, Thomas Nitsche wrote: > Hi, > we are doing some research here on decoding 802.11g using GNURadio. As far > as i know there is code available for transmission of 802.11g frames on > CGRAN but no receiver code. Is there any work going on for the receiver side > right now? Is it theoretically possible to decode a signal received with the > USRP N210? The bandwidth provided by the gigabit ethernet connection should > be sufficient in contrast to the USRP1 USB connection, or am i wrong? > Thomas, Yes, the N210 will handle the bandwidth of 802.11g. > I had a look at the (generic) GNURadio OFDM mod/demod code but its kind of > hard to understand whats going on there. I have reused the ofdm-sync-pm code > to generate seemingly helpful frequency offset values from the 802.11 short > training sequence. I also extracted timing information by correlating with > the known short sequence. However i am not sure if this synchronization is > accurate enough for at least a few fft blocks. > > Is there anything like: > > fine timing/frequency correction, > Yes, provided by the ofdm_sync block in ofdm_receiver.py. > sampling offset correction, > Yes, also provided by the ofdm_sync block in ofdm_receiver.py. channel estimation or > Yes, in ofdm_frame_acq in ofdm_receiver.py. > code for using pilot tone subcarriers > No. That's one of the biggest gaps in the current implementation. > in the generic GNURadio ofdm implementation that could be reused for a > 802.11g receiver? What is with the code for extracting infos from the > subcarriers? Would it be easier to rewrite it from scratch or can some of > the gnuradio code be reused? > > Thanks for any information you can provide, > Thomas It should be a place to start, but it'll probably take some work (though hopefully less than starting from scratch). For getting the subcarriers, you probably want to look at the gr_ofdm_frame_sink block. Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Constant output message source
On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san wrote: > > Hi, > > I was wondering if there is a method to have a source block constantly > sending out "0" and once it recieves a message from python, e.g a packet, > it > will then stream the message and switch back to sending "0" when done. > > I've tried: > Message Source > (Add, 0) > Constant Source/Vector Source with 0 -> (Add, 1) ---> output > > However, the add block (and all blocks in gnuradio) waits for stream items > from both inputs to be ready (i.e no interpolation) before making a output > stream item. This effectively nullifies the const source in the above > example. > > I was wondering if there is any possible way to solve this problem? > > The reason I am asking this is I am using a dual TX setup on a single USRP > which interleaves output signals. I have I output signal that is constantly > sending (beacon) and one that is only sending sometimes, however the > interleaving of output signals means that both streams needs to be > constantly sending. > Right, the add block needs to see items from both streams so that it can add them together. If there is no data on one stream, there is nothing to add and it does not assume zeros. My advice is to make a new block. The easiest would probably to make a new add block that inherits from gr_block instead of gr_sync_block. In this block, you tests the length of both inputs and add which items together that you want, substituting zeros when there is no more data on the incoming message stream. It will be pretty specific to your needs, and be careful with your consume() and return item numbers to account for what you've done with both streams. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Howto transmit idle pattern output when data isn't available
On Wed, Feb 23, 2011 at 4:07 PM, Phelps Williams wrote: > I have what I would suspect is a common dilemma with the gnuradio > architecture. I have a udp socket which is providing me a packets at less > than the bitrate being transmitted by the usrp. The datagrams being > received by the udp socket are variable in size and message timing is not > regular. > > If my gnuradio transmitter exhausts the data available on the udp socket > there will be a gap in the modulated output (I would expect the output of my > usrp to just go CW at this point correct?). This will definitely happen > because the bitrate my modulator expects is higher than the actual amount of > data available. This causes the receiver to go out of bit lock and it must > attempt to relock when modulation starts again. > > Is it possible to inject an idle pattern when datagrams are not available > to keep the receiver in lock? I'm thinking I may need to write my own > source which does a non blocking read on the socket, if data isn't available > it outputs an idle sequence, if data is available it provides that instead. > Is there an easier way to do this (that doesn't require me to do additional > work)? > > Thanks! > > -Phelps > Nope, no easy way that doesn't require you to do more work :) Making your own block to handle this case might be the easiest thing to do right now. Eventually, I think the answer to your question is the new stream tagging interface, probably in the receiver. I would like to make this work for all of our digital modulation blocks, too, which have a number of syncing loops that go crazy when there is no signal and then have to resync when the signal returns. I would like for a block to check the power of the incoming signal and determine if there is energy or not. When there is no energy, it needs to send a tag downstream that tells all of the recovery loops to stop working. When energy is detected again, send a tag to turn back on. The idea being that, most likely, in the time between bursts, the channel and conditions have not changed greatly, so the last stable point of the sync loops should still be close. The difficulty with this method is mostly that we have not written documentation on the stream tagging interface, nor have we provided many good examples for how to use it. It is currently only available in the 'next' branch. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM mod/demod test code
On Wed, Feb 23, 2011 at 5:41 PM, Tuan (Johnny) Ta wrote: > A lot of people seem to have problem with the OFDM receiver in gnuradio. > Since there's no confirmation of a working *2-way* communication using > OFDM yet, I've decided to dig into the OFDM receiver implementation. I want > to test the performance of the OFDM synchronization block. To do that, first > I want to isolate the ofdm_sync block and make sure the rest of the chain > works. > > I found that there is a test file for OFDM mod and demod, named > ofdm_mod_demod_test.py, without invoking OFDM synchronization, FFT, preamble > and cyclic. However, that code is outdated and not applicable for the > current implementation. > > I'm trying to generate similar test code for the current version of OFDM > mod and demod but there seems to be no straight-forward way. It used to be > that we can hook the ofdm_mapper straight into an ofdm_frame_sink. It's no > long the case as the frame_sink now requires a 2nd input, which is a stream > of bytes signaling the beginning of a symbol. This input is provided by > ofdm_frame_acquisition, which in turn requires the signaling from the > ofdm_sampler. The ofdm_sampler gets the signaling from the ofdm_sync x_x. > > Long story short, I haven't found a way to test the system while bypassing > the ofdm_sync block yet. Can anyone give me some suggestion? > > Thanks a lot, > > Johnny > Johnny, Try using the "fixed" version of the ofdm_sync block found on line 96 of ofdm_receiver.py. This takes information about what you expect the timing and frequency offset to be and does nothing but use that to trigger the follow-on components. It was made for doing exactly the kind of things you are looking at doing. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: High CPU usage
On Fri, Feb 25, 2011 at 3:47 PM, peng senl wrote: > > > > The legacy driver or UHD? Are you using 32-bit complex > > floats or > > 16-bit complex shorts for you data? > > In my case, I am using GNU Radio with USRP2 in C++. > The CPU usage for 5MHz is 30% with 3.2 G duo core CPU and around 70% for > 20MHz sample frequency. > > > I'd be very interested to hear your benchmarking of the > > different > > types here. That is UHD/32fc vs. USRP2/32fc and UHD/16sc > > vs. > > USRP2/16sc. Also, UHD/32fc vs. UHD/16sc. > > I just read data coming over the Ethernet. I did not even convert from big > to little endian or convert data to other format. So I try to minimize the > operations. But I still get such a high CPU usage. I wondering is it > possible to simplify the data receive operations. > Ok, that didn't answer my question at all. HOW are you reading them from the Ethernet port? Which function are you calling in the USRP2 library to do this? Or which GNU Radio usrp2_source_XXX are you using (usrp2_source_32fc or usrp2_soruce_16sc)? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Adding dual usrp sink block to benchmark_tx.py
On Sat, Feb 26, 2011 at 5:17 AM, Jay Gaona wrote: > Hello everyone, > > I've added a dual usrp sink block and duplicated the tx flow graphs in > benchmark_tx.py example. However, I am unable to transmit packets when I set > the following in the flow graph: > > self.packet_transmitter = \ > blks2.mod_pkts(modulator, >access_code=None, >msgq_limit=4, >pad_for_usrp=True) > > self.packet_transmitter_2 = \ > blks2.mod_pkts(modulator_2, >access_code=None, >msgq_limit=4, >pad_for_usrp=True) > > > self.connect(self.packet_transmitter, self.amp, (self, 0)) > self.connect(self.packet_transmitter_2, self.amp_2, (self, 1)) > > I have tried the following 2 codes and were able to transmit packets from > the first flow graph, and then the packets from the second flow graph: > > self.connect(self.packet_transmitter, self.amp, (self, 0)) > self.connect(self.null_source, self.amp_2, (self, 1)) > > self.connect(self.null_source, self.amp, (self, 0)) > self.connect(self.packet_transmitter_2, self.amp_2, (self, 1)) > > Any idea why I am unable to simultaneously transmit packets from both flow > graphs? Thanks in advance! > Right now, no, sorry, no ideas. It seems like it should work. I will suggest two things, though. First, remove the message sources from the graph. Replace your packet_transmitter_X and replace them with two gr.sig_source_c() with different frequencies and make sure that they transmit as expected from each output of the USRP. Next, keep your packet transmitters, but replace the USRP dual sink with file sinks and make sure they are getting the proper signals from the source. Between these two experiments, maybe you'll get enough information to fix your problem. Or let us know more about what's happening to be more help to you. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multirate Blocks
On Sat, Feb 26, 2011 at 8:00 AM, Antoine Dedave < qlmqny_anti_r...@hotmail.com> wrote: > Hi, > > I'm implementing a 2-FSK modulator (I Know that a good one already exists > but > i have to do it myself for academic purpose). > > To do so, i produce a given (N) number of samples corresponding to the > sampling of a complex exponnetial for each > incoming bits. > > The "sampling rate" (one bit => N samples) is increased by N through the > modulator, so i'm doing this > > Constructor: > > set_relative_rate(N); > set_output_multiple(N); > > General_work: > > consume_each(noutput_items/N); > > Is that correct? and is there anything else to do? > > Thanks in advance, > > Antoine Dedave > First, what type of gr_block are you inheriting from? The fact that you are using noutput_items/N in your consume_each function makes it look almost like you are using a gr_sync_block, which would not be the right answer here. In fact, you can use a gr_sync_interpolator since you know the direct relationship between input and output samples (1-to-N). Set the interpolation rate as N and you don't need to worry about any of the reset (setting the relative_rate or consume_each; the parent class knows what to do with them). Look at the implementation of gr_sync_interpolator to see how it handles setting everything up for you to do the interpolation properly. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Build error GNU Radio release v3.3.1git-971-ga02bb131
On Sun, Feb 27, 2011 at 6:51 AM, Arya Santini wrote: > Hi Jared, thanks for that suggestion. > > Anyway, I realized that I was using GNU compiler gcc-4.6 > (experimental) which apparently imposes stricter rules and allows > package builds to fail where previous versions used to succeed. So the > suggested fix for one typical "ptrdiff_t does not name a type" is > #include , which I did in the > /usrp/host/swig/python/usrp_prims.cc file, and the build completed to > success. > > Arya > Thanks for bringing this up (and for the solution). The usrp_prims.cc file is actually generated by SWIG, so I've explicitly included stddef.h into the .i file, which is done for most of the other SWIG files already for other reasons. This really seems like a SWIG problem, so hopefully this will be fixed in future releases before the new GCC takes over. Hopefully, this fixes our last hole, anyways. I'll be pushing changes to next and master soon. Tom > On Sun, Feb 27, 2011 at 3:15 AM, Jared Harvey > wrote: > > Hello Arya, > > > > AS> I was trying to build the gnuradio on yet > > AS> another machine running Ubuntu 10.10. from > > AS> source today after checking out the latest > > AS> code from the dev trunk: > > > > I see Ubuntu 10.10 has native packages. Is there a > > reason why you need to compile it? Perhaps you are > > looking for the latest and greatest. > > > > Youmay have dependency problems. These > > dependencies may be resolved by installing the > > native packages. Perhaps you can open Synaptic and > > install the native gnuradio that way and see if > > that helps your compile process. > > > > Best regards. > > > > .. ..-. / -.-- --- ..- / .-. . .- -.. / - .. ... > > .-.. . - ... / .- ...- . / .- / -... . . .-. > > > > Jared Harvey Operator KB1GTT > > > > e-mail m...@jaredharvey.com > > Web page http://jaredharvey.com > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real-only direct-conversion
On 27.02.2011 17:28, Marcus D. Leech wrote: > I was on a call the other night with someone who asserted that you > didn't need an I & Q representation > for a direct-conversion receiver, and that I and Q could be > synthesized later from a real-mode-only > baseband signal. ... > So, my feeling is that you *absolutely need* the I and Q "form" in order > to disambiguate +/- > frequencies when dealing with direct-conversion baseband signals. > Who's right? As long as you receive the complete signal bandwidth, you can create the I/Q form later. Of course you need the double sample rate, if there's only the real "baseband" representation. I call it baseband, but you can also call it IF with the lowest possible IF frequency. Strictly speaking it's not a "direct-conversion" receiver, since there is a fixed IF in the middle of the baseband spectrum. The "data rate" is the same for both, one has double sample rate but only half the sample size (real vs. complex numbers). Complex baseband (I/Q) reconstruction: - Hilbert transform eleminates the (symmetric) negative frequencies - Frequency shifting the IF frequency to zero by multiplying a complex exp(-j*2*pi*f_IF*t) This is standard in digital down converters (DDC). The TVRX-Board is working this way. According to the schematic, only the bipolar A channel is connected to the tuner chip, a real input. Other Dboards use both A/B inputs for separate I/Q channels. I think both variants have their advantages and disadvantages. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] build-gnuradio script
I've put together a script for building GnuRadio+UHD for both Ubuntu
recent and Fedora recent.
I've attached it.
This is outgrowth of a script I put together and distributed to a few
people several years ago, but it has
been updated quite a bit and supports both Ubuntu and Fedora.
Your mileage may vary. Void where prohibited. Some settling may have
occurred during transit. Batteries not
included. Only use while awake. Do not use in the bathtub.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
#!/bin/sh
#
# Build script for UHD+GnuRadio on Fedora and Ubuntu
#
SUDOASKED=n
function prereqs {
sudocheck
echo Installing pre-prequisites
#
# Check whether we're on a Fedora or Ubuntu system, and "do the right
thing"
# for either system
#
# It's a Fedora system
#
if [ -f /etc/fedora-release ]
then
case `cat /etc/fedora-release` in
*12*|*13*|*14*|*15*)
sudo yum -y groupinstall "Engineering and Scientific"
"Development Tools"
sudo yum -y install fftw-devel cppunit-devel
wxPython-devel libusb-devel \
guile boost-devel alsa-lib-devel numpy gsl-devel
python-devel pygsl \
python-cheetah python-lxml guile-devel PyOpenGL \
PyQt4-devel qwt-devel qwtplot3d-qt4-devel libusb
libusb-devel \
libusb1 libusb1-devel cmake git wget sdcc
;;
*)
echo Your Fedora system release must be at least 12 to
proceed
exit
;;
esac
#
# It's a Ubuntu system
#
elif [ -f /etc/lsb-release ]
then
case `grep DISTRIB_RELEASE /etc/lsb-release` in
*10.04*|*10.10*)
sudo apt-get -y install libfontconfig1-dev
libxrender-dev libpulse-dev swig g++ \
automake autoconf libtool python-dev libfftw3-dev \
libcppunit-dev libboost-all-dev libusb-dev fort77 sdcc
sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl
libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools
libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools \
cmake git wget sdcc
;;
*9.10*)
sudo apt-get -y install swig g++ automake autoconf
libtool python-dev libfftw3-dev \
libcppunit-dev libboost1.38-dev libusb-dev fort77 sdcc
sdcc-libraries \
libsdl1.2-dev python-wxgtk2.8 git-core guile-1.8-dev \
libqt4-dev python-numpy ccache python-opengl
libgsl0-dev \
python-cheetah python-lxml doxygen qt4-dev-tools
libusb-1.0-0-dev \
libqwt5-qt4-dev libqwtplot3d-qt4-dev pyqt4-dev-tools \
cmake git wget sdcc
;;
*)
echo Your Ubuntu release must be at least 9.10 to
proceed
exit
;;
esac
else
echo This script supports only Ubuntu and Fedora systems
echo Your Fedora system must be at least Fedora 13
echo Your Ubuntu system must be at least Ubuntu 9.10
exit
fi
}
function gitfetch {
cd $HOME
date=`date +%Y%m%d%H%M%S`
#
# Check for existing gnuradio directory
#
if [ -d $HOME/gnuradio ]
then
mv $HOME/gnuradio $HOME/gnuradio.$date
fi
#
# Check for existing UHD directory
#
if [ -d $HOME/uhd ]
then
mv $HOME/uhd $HOME/uhd.$date
fi
#
# GIT the gnu radio source tree
#
git clone http://gnuradio.org/git/gnuradio.git
if [ ! -d gnuradio/gnuradio-core ]
then
echo GIT checkout of Gnu Radio failed!
exit
fi
#
# GIT the UHD source tree
#
git clone git://code.ettus.com/ettus/uhd.git
if [ ! -d uhd/host ]
then
echo GIT checkout of UHD failed!
exit
fi
}
function uhd_build {
#
# UHD build
#
sudocheck
cd $HOME
if [ ! -d uhd ]
then
echo you do not appear to have the \'uhd\' directory
echo you should probably use $0 gitfetch to fetch the
appropriate
Re: [Discuss-gnuradio] Real-only direct-conversion
On 02/27/2011 06:16 PM, Moeller wrote: As long as you receive the complete signal bandwidth, you can create the I/Q form later. Of course you need the double sample rate, if there's only the real "baseband" representation. I call it baseband, but you can also call it IF with the lowest possible IF frequency. Strictly speaking it's not a "direct-conversion" receiver, since there is a fixed IF in the middle of the baseband spectrum. The "data rate" is the same for both, one has double sample rate but only half the sample size (real vs. complex numbers). Complex baseband (I/Q) reconstruction: - Hilbert transform eleminates the (symmetric) negative frequencies - Frequency shifting the IF frequency to zero by multiplying a complex exp(-j*2*pi*f_IF*t) This is standard in digital down converters (DDC). The TVRX-Board is working this way. According to the schematic, only the bipolar A channel is connected to the tuner chip, a real input. Other Dboards use both A/B inputs for separate I/Q channels. I think both variants have their advantages and disadvantages. Right, for a non-zero IF, it's easy to see how to do the Hilbert transform and convert to I+Q, provided the sample rates are correct. But for a zero-IF, direct-conversion, with only a single baseband output (single mixer), I don't see how you can make it work. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real-only direct-conversion
On 28.02.2011 00:22, Marcus D. Leech wrote: > But for a zero-IF, direct-conversion, with only a single baseband output > (single mixer), I don't see how you >can make it work. A real valued zero-IF "universal" (modulation independent) receiver does not exist. I think you have the a demodulating receiver in mind that relies on symmetry in the baseband spectrum, like for AM. In this concept, "baseband" is the real valued audio baseband. For digital modulations it doesn't make sense. The real valued representation with IF at half of the one-sided signal bandwidth can be called "real baseband", in contrast to the "complex baseband". Same data size, same content, same bandwidth, just shifted in spectrum. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Real-only direct-conversion
On 02/27/2011 06:41 PM, Moeller wrote: A real valued zero-IF "universal" (modulation independent) receiver does not exist. I think you have the a demodulating receiver in mind that relies on symmetry in the baseband spectrum, like for AM. In this concept, "baseband" is the real valued audio baseband. For digital modulations it doesn't make sense. The real valued representation with IF at half of the one-sided signal bandwidth can be called "real baseband", in contrast to the "complex baseband". Same data size, same content, same bandwidth, just shifted in spectrum. Yup, that's pretty much what I said in my initial post on the subject. The 1940s-era direct-conversion receivers were designed specifically for things like AM, where the +/- frequency ambiguity didn't matter. Yup, placing the IF at Fs/4 makes sense in that you can later do a Hilbert transform and convert to complex. But if the IF is at zero, you lose. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: UHD Announcement - February 25rd 2011
> When you say "2x" performance increase, do you mean CPU performance or > send()/recv() latency? Do you mind saying a few words on what changes > you have made? > Much of the performance gains involved removing things out of the fast-path that only needed to be called once at initialization (forgoing code simplicity for performance). Example: a vector of pointers, a bound callable object; many of which had calls to malloc and free which incurs quite a lot of unnecessary overhead. Less cpu cycles/less time are spent in the send()/recv() calls. This roughly worked out to about half the CPU usage when looking at oprofile. Because of this, the overall latency is reduced. We measured about 250us RTT from device to host and back to device with the latency measurement app in uhd examples. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] multiple tabs
The graphical widgets all take a notebook parameter which is notebook_id, tab_index. See the documentation in the various blocks. -josh On 02/26/2011 07:46 AM, ranjini ram wrote: > hi > > can anybody help me out in creating multiple tabs in a single output > window.eg.one tab indicating RF spectrum second IF spectrum and so on.. > > Thanks in advance > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About the -ve represenation on FFT graph.
Sorry if the question was re-posted. Can anyone reply this entry level question? In complex data representation such as the attached image by grc, the LPF cut the frequency in both direction(+/- freq) which the center frequency is 0Hz http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif When I set the base frequency to a large positive value such as 10MHz, the cutoff shows on both side apart from the center frequency too. http://www.fungkai.com/~howie/sdr/complex_1_basefreq10.gif What's the frequency lower then the center frequency represent? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About the -ve represenation on FFT graph.
On 02/27/2011 07:57 PM, rono wrote: > Sorry if the question was re-posted. > > > Can anyone reply this entry level question? > > > In complex data representation such as the attached image by grc, > the LPF cut the frequency in both direction(+/- freq) > which the center frequency is 0Hz > > http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif > > When I set the base frequency to a large positive value such as 10MHz, > the cutoff shows on both side apart from the center frequency too. > The baseband frequency parameter only changes the value printed on the x axis. For example: If you had a usrp source tuned to frequency X, you would also set the baseband frequency to X -> for display purposes. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue. I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation fails because of the libusb-0.1.12 link, more specifically the "libusb-gnur.a" library. For some reason GCC is expecting the library to have the "-fPIC" flag passed when building the library which doesn't make sense since it's trying to link against a static library and not a shared librar ... it was complaining about an ARM_MOV or something like that assembly command. To my understanding the libtool included in the libusb should make sure that such confusion doesn't happen which in using GCC 4.3 was not an issue but with the GCC 4.5 included in the new tree is an issue. I also tried incorporating the libusb fix against the GNU Radio GIT recipe but the configure stage fails because gnuradio can't find the "USB_BULK_WRITE" function in the libusb library from libusb-0.1.12 which when I looked is actually there. When I bypass the configure check for USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio 3.2.1. I feel like the libusb-0.1.12 static library is corrupt for some reason more specifically I think libtool might be the culprit. I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might explain why I can receive but I can't write using the UHD driver. The libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use libusb-0.1.12? an older or newer version maybe? did it use a different libtool? I need to find a way to pass the -fPIC flag to the configure stage of libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and I'm about to head out of town for a few days. Other than that doese anyone have any suggestion? Josh or Philip :) al fayez -Original Message- From: Almohanad Fayez To: philip Cc: discuss-gnuradio Sent: Thu, Feb 24, 2011 6:42 pm Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard 1- I'm using the host USB not the OTG 2- I'm using the 2.6.37 kernel with Angstrom 2010 3- The following is the dmesg output which looks ok ... at least to me :) [ 108.369293] usb 1-2.3.1: USB disconnect, address 4 [ 108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap and address 6 [ 108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe, idProduct=0002 [ 108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=6 [ 108.889465] usb 1-2.3.1: Product: USRP Rev 4 [ 108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks [ 108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b I think I'll try to attempt to redo your libusb hack by copying it from the older gnuradio recipes and attempt to use the original USRP USB driver if the problem ends up being too major ... unless you want to do that as a favor to me and push the recipe into the openembedded tree !!! pretty please :) al fayez -Original Message- From: Philip Balister To: Almohanad Fayez Cc: discuss-gnuradio Sent: Thu, Feb 24, 2011 2:20 pm Subject: Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard On 02/23/2011 11:25 PM, Almohanad Fayez wrote: > I was wondering about people's experience with the UHD driver on the E100 or the Beagleboard. I am able to use it to receive IQ data from the USRP but I can't seem to transmit anything from it ... if I take the same flowgraph to a laptop I'm able to transmit IQ using the same USRP/daughterboard and the UHD driver however when I try to run the same transmitter on the Beagleboard and I check my spectrum analyzer I don't see anything > > I already did a signal capture before sending to the USRP and made sure that there is data getting pushed through ... is there a problem with UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure that I'm using the latest UHD firmware on the beagleboard. > > > The following is the version info printed when I run the flowgraph: > linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500; UHD_0001.20110224034946.1 Al, Which USB port are you using to connect the USRP1? What kernel version? Can you run dmesg and see if there are any usb related messages at the end? Philip ___ iscuss-gnuradio mailing list iscuss-gnura...@gnu.org ttp://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP output power
Does anybody know about output power of a USRP antenna, in voltage and ampere ? I'm trying to make a circuit connected with a USRP antenna port. And, in the future, the human body will replace the circuit Of course, it's a kind of experimental. So, If I send a sinusoidal signal with magnitude 35536 which is a maximum value allowed by USRP, what voltage and ampere value does the antenna output? Thank you for all in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Constant output message source
Cool thanks for the reply. The reason I am doing this is because I am trying to transmit signals at different times... and testing shows the interleave block acts like the sync type blocks you mention. I am guessing the same idea can be applied and make a new interleave block and inherits from the gr_block. Though I am just wondering that this has to be a common problem with the dual usrp TX usage, I was wondering if anyone else has done similar work already or has an more "standard" solution using the tools already built into GNU radio. As I am not too familiar with the build toolchain and the C++ backbones behind the python, however I will be reading up on it now. Tom Rondeau wrote: > > On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san wrote: > >> >> Hi, >> >> I was wondering if there is a method to have a source block constantly >> sending out "0" and once it recieves a message from python, e.g a packet, >> it >> will then stream the message and switch back to sending "0" when done. >> >> I've tried: >> Message Source > (Add, 0) >> Constant Source/Vector Source with 0 -> (Add, 1) ---> output >> >> However, the add block (and all blocks in gnuradio) waits for stream >> items >> from both inputs to be ready (i.e no interpolation) before making a >> output >> stream item. This effectively nullifies the const source in the above >> example. >> >> I was wondering if there is any possible way to solve this problem? >> >> The reason I am asking this is I am using a dual TX setup on a single >> USRP >> which interleaves output signals. I have I output signal that is >> constantly >> sending (beacon) and one that is only sending sometimes, however the >> interleaving of output signals means that both streams needs to be >> constantly sending. >> > > Right, the add block needs to see items from both streams so that it can > add > them together. If there is no data on one stream, there is nothing to add > and it does not assume zeros. > > My advice is to make a new block. The easiest would probably to make a new > add block that inherits from gr_block instead of gr_sync_block. In this > block, you tests the length of both inputs and add which items together > that > you want, substituting zeros when there is no more data on the incoming > message stream. It will be pretty specific to your needs, and be careful > with your consume() and return item numbers to account for what you've > done > with both streams. > > Tom > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Constant-output-message-source-tp30964604p31029150.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] python versions
I just tested the next branch with 2.4 and the only incompatibility was a "with" statement in gr_xmlrunner.py. The "with" statement was introduced in 2.5. Once that was removed the "make check" ran fine. The replacement for the "with" statement was: fss = _fake_std_streams() fss.__enter__() try: test(result) try: out_s = sys.stdout.getvalue() except AttributeError: out_s = "" try: err_s = sys.stderr.getvalue() except AttributeError: err_s = "" finally: fss.__exit__(None, None, None) On Wed, Feb 23, 2011 at 6:20 PM, Tom Rondeau wrote: > On Wed, Feb 23, 2011 at 1:28 PM, Ben Reynwar wrote: >> What are the oldest and newest versions of python that gnuradio should >> work with? >> >> That way I can test stuff using those two versions. > > > Python 2.4 is the oldest that I _know_ will work (and I don't think, > but haven't tried, 2.3), and I've used it with 2.7. It will not work > with 3.+. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Driver in E100/Beagleboard
On Sun, Feb 27, 2011 at 11:39 PM, Almohanad Fayez wrote: > I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue. > I've tried bitbaking Philip's GNU Radio 3.2.1 recipe and the compilation > fails because of the libusb-0.1.12 link, more specifically the > "libusb-gnur.a" library. For some reason GCC is expecting the library to > have the "-fPIC" flag passed when building the library which doesn't make > sense since it's trying to link against a static library and not a shared > librar ... it was complaining about an ARM_MOV or something like that > assembly command. To my understanding the libtool included in the libusb > should make sure that such confusion doesn't happen which in using GCC 4.3 > was not an issue but with the GCC 4.5 included in the new tree is an issue. UHD uses libusb-1.0 and does not support libusb-0.1. Despite some similarities in the API, version 1.0 is a complete rewrite there is no compatibility or relation between versions. In that sense, the gnuradio 3.2 recipe is completely unrelated to UHD. > I also tried incorporating the libusb fix against the GNU Radio GIT recipe > but the configure stage fails because gnuradio can't find the > "USB_BULK_WRITE" function in the libusb library from libusb-0.1.12 which > when I looked is actually there. When I bypass the configure check for > USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio > 3.2.1. I feel like the libusb-0.1.12 static library is corrupt for some > reason more specifically I think libtool might be the culprit. If you are using libusb-0.1 and the gnuradio driver, you generally _don't_ want to be using the mentioned libusb calls, which are synchronous (slow). Normally, with libusb-0.1, the control and setup functions go through libusb, while data flows through a separate OS specific implementation - usbdevfs in the case of Linux. The only time you should be seeing usb_bulk_write is when configure falls back to the synchronous calls in the absence of any "fast" version. Now the Linux implementation does have some evil bits, so perhaps this isn't surprising. > I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might > explain why I can receive but I can't write using the UHD driver. The > libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use > libusb-0.1.12? an older or newer version maybe? did it use a different > libtool? Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD. > I need to find a way to pass the -fPIC flag to the configure stage of > libusb-0.1.12 unfortunately I can't seem to find an easy way to do it and > I'm about to head out of town for a few days. Other than that doese anyone > have any suggestion? In UHD with libusb-1.0, sends and receives are treated similarly (USB is host driven) where pre-allocated buffers are submitted and retrieved from the device. The difference is mainly in flags and endpoint settings; the problem, IMO, is unlikely to be build related. Of course, that doesn't provide any insight into why this is only coming up on the Beagle. I'd like to recreate this issue on my newly setup E100, but, at the moment, I'm not seeing any USB devices, and I think I just bricked my FPGA. So I need to get a little bit more settled until I can try out additional things. Perhaps later this week... Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About the -ve represenation on FFT graph.
Thanks for your kindly reply. Can you explain more that, both sides from the center frequency of the input frequency has been cut by a low pass filter. Doesn't a low pass filter allow the lower frequency to pass? Thanks, Rono On 28/02/11 12:22, Josh Blum wrote: On 02/27/2011 07:57 PM, rono wrote: Sorry if the question was re-posted. Can anyone reply this entry level question? In complex data representation such as the attached image by grc, the LPF cut the frequency in both direction(+/- freq) which the center frequency is 0Hz http://www.fungkai.com/~howie/sdr/complex_1_basefreq0.gif When I set the base frequency to a large positive value such as 10MHz, the cutoff shows on both side apart from the center frequency too. The baseband frequency parameter only changes the value printed on the x axis. For example: If you had a usrp source tuned to frequency X, you would also set the baseband frequency to X -> for display purposes. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: High CPU usage
p { margin-bottom: 0.08in; }
Hello Tom,
Here is how I collect the data:
I am using the example
rx_streaming_samples.cc to collect data. I disabled the function
copy_u2_16sc_to_host_16sc() in the example.
I think the program keeps calling bool
ok = rx_nop_handler::operator()(items, nitems, metadata) to return
the pointer of the received meta data array.
There is a background thread
usrp2::impl::bg_loop() running in real time. This function calls
“d_eth_buf->rx_frames(this, 100); ” to get the data out from
the ethernet buffer. That is basically what this program does.
Do you think the CPU usage is normal?
I also notice that the block timeout is 100ms. Is there a reason for
doing this?
--- On Sun, 2/27/11, Tom Rondeau wrote:
From: Tom Rondeau
Subject: Re: High CPU usage
To: "peng senl"
Cc: discuss-gnuradio@gnu.org
Date: Sunday, February 27, 2011, 4:37 PM
On Fri, Feb 25, 2011 at 3:47 PM, peng senl wrote:
> The legacy driver or UHD? Are you using 32-bit complex
> floats or
> 16-bit complex shorts for you data?
In my case, I am using GNU Radio with USRP2 in C++.
The CPU usage for 5MHz is 30% with 3.2 G duo core CPU and around 70% for 20MHz
sample frequency.
> I'd be very interested to hear your benchmarking of the
> different
> types here. That is UHD/32fc vs. USRP2/32fc and UHD/16sc
> vs.
> USRP2/16sc. Also, UHD/32fc vs. UHD/16sc.
I just read data coming over the Ethernet. I did not even convert from big to
little endian or convert data to other format. So I try to minimize the
operations. But I still get such a high CPU usage. I wondering is it possible
to simplify the data receive operations.
Ok, that didn't answer my question at all. HOW are you reading them from the
Ethernet port? Which function are you calling in the USRP2 library to do this?
Or which GNU Radio usrp2_source_XXX are you using (usrp2_source_32fc or
usrp2_soruce_16sc)?
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronizing multiple USRPs
Hello, I have eight (08) USRP N210s that has been synchronized using 10MHZ and 1PPS reference. I am receiving data from them using a gigabit ethernet switch to my computer. My question is when I will receive packets from all of them through a single switch, how will I know the time reference for each sample? Thanks, Khalid. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
