Re: [Discuss-gnuradio] The shortest pulse length
This is what I did: def build_graph (): nchan = 1 interp = 512 duc0 = 0 duc1 = 0 fs = 250e3#2nd sample rate between usb and dac max_dev = 32e3 #1st sample rate divided by 4 (1st = 2nd sample rate) gain = 16e3 k = 2 * math.pi * max_dev / fs vec1 = Numeric.arange (0.624, 0.656, 0.128) vsource = gr.vector_source_f(vec1, False) fmmod = gr.frequency_modulator_fc (k) amp = gr.multiply_const_cc(gain) fg = gr.flow_graph () u = usrp.sink_c (0, interp, nchan) tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u) m = usrp.determine_tx_mux_value(u, tx_subdev_spec) u.set_mux(m) subdev = usrp.selected_subdev(u, tx_subdev_spec) subdev.set_enable(True) sample_rate = u.dac_freq () / interp u.set_tx_freq (0, duc0) u.set_tx_freq (1, duc1) fg.connect (vsource, fmmod, amp, u) return fg I modified a version of siggen_min2.py into the above. Regards Lance - Original Message From: David Scaperoth <[EMAIL PROTECTED]> To: seph 004 <[EMAIL PROTECTED]> Cc: Lee Patton <[EMAIL PROTECTED]>; discuss-gnuradio@gnu.org Sent: Thursday, March 1, 2007 5:59:22 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Feb 28, 2007, at 4:29 AM, seph 004 wrote: Well, I have implemented a bit of a strange setup which seems to be working somewhat now. I'm not really trying to view only the first few samples, I'm currently trying to track where I might of made a mistake with trying to generate a defined pulse with a specific length. My aim is to generate a very narrow band chirp to transmit on a little ultrasonic tranducer. I figured out which numerical values to the gr.modulation block produce which frequencies. Using this, I made a vector of the exact number of samples I want with the values to produce the frequencies I want. In my case 39-41 kHz. For some reason these low frequencies still make it through the transformer on the basic TX db, so I'm using them. Initially I was just generating a sine wave, and trying to use gr.head to limit the number of samples, but I've since switched to this approach I figured that if I wanted to produce a wave form lasting 10 msecs, then I would need at least 2500 samples. I got this number from the DAC rate of 128M and the highest interpolation factor of 512. When I test with the scope set to auto store, I spot the waveform, but it is only 1 msec long. So either I've lost a lot of samples somewhere, or my scaling is wrong. How are you creating the flow graph? I pretty much abandoned using gr.head, as it wasn't producing anything. At least now though I can see a waveform, though my scaling seems to have gone wrong somewhere. When you say you used a looback, do you mean you connected the TX db output and RX db input, and used the gr.oscope block to view your signals? Regards Lance - Original Message From: Lee Patton <[EMAIL PROTECTED]> To: seph 004 <[EMAIL PROTECTED]> Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 27, 2007 12:58:31 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote: > I have a vector source producing a sine wave, and then I'm using > gr.head to limit the number of samples sent. I'm sure you checked this, but are you trying to capture the first few samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0. So, you won't see anything in the first few samples anyway. > From your explanation, I should be ok with even a low number of > samples. When I tested my setup, I couldn't catch anything on the > scope. There is probably some problem in how I made the app. > > I saw something mentioned elsewhere in the discussion archives that > the usrp dumps the first few samples it receives from the host before > transmitting. Is this still something to take note of? I don't know whether or not the USRP dumps the first few samples. I don't think I've ever experienced it though. I can say that there is an unpredictable delay from the generation of the first sample in software until the time it actually reaches the output port. I haven't tried to do what you're doing -- i.e., capture the first few output samples on a scope. How is the scope triggered? (What I did was create a loopback whereby I transmit and receive by reading the bleedover on the daugherboard.) -Lee Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index_
Re: [Discuss-gnuradio] The shortest pulse length
On Feb 28, 2007, at 4:29 AM, seph 004 wrote: Well, I have implemented a bit of a strange setup which seems to be working somewhat now. I'm not really trying to view only the first few samples, I'm currently trying to track where I might of made a mistake with trying to generate a defined pulse with a specific length. My aim is to generate a very narrow band chirp to transmit on a little ultrasonic tranducer. I figured out which numerical values to the gr.modulation block produce which frequencies. Using this, I made a vector of the exact number of samples I want with the values to produce the frequencies I want. In my case 39-41 kHz. For some reason these low frequencies still make it through the transformer on the basic TX db, so I'm using them. Initially I was just generating a sine wave, and trying to use gr.head to limit the number of samples, but I've since switched to this approach I figured that if I wanted to produce a wave form lasting 10 msecs, then I would need at least 2500 samples. I got this number from the DAC rate of 128M and the highest interpolation factor of 512. When I test with the scope set to auto store, I spot the waveform, but it is only 1 msec long. So either I've lost a lot of samples somewhere, or my scaling is wrong. How are you creating the flow graph? I pretty much abandoned using gr.head, as it wasn't producing anything. At least now though I can see a waveform, though my scaling seems to have gone wrong somewhere. When you say you used a looback, do you mean you connected the TX db output and RX db input, and used the gr.oscope block to view your signals? Regards Lance - Original Message From: Lee Patton <[EMAIL PROTECTED]> To: seph 004 <[EMAIL PROTECTED]> Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 27, 2007 12:58:31 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote: > I have a vector source producing a sine wave, and then I'm using > gr.head to limit the number of samples sent. I'm sure you checked this, but are you trying to capture the first few samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0. So, you won't see anything in the first few samples anyway. > From your explanation, I should be ok with even a low number of > samples. When I tested my setup, I couldn't catch anything on the > scope. There is probably some problem in how I made the app. > > I saw something mentioned elsewhere in the discussion archives that > the usrp dumps the first few samples it receives from the host before > transmitting. Is this still something to take note of? I don't know whether or not the USRP dumps the first few samples. I don't think I've ever experienced it though. I can say that there is an unpredictable delay from the generation of the first sample in software until the time it actually reaches the output port. I haven't tried to do what you're doing -- i.e., capture the first few output samples on a scope. How is the scope triggered? (What I did was create a loopback whereby I transmit and receive by reading the bleedover on the daugherboard.) -Lee Now that's room service! Choose from over 150,000 hotels in 45,000 destinations on Yahoo! Travel to find your fit. ___ 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] updated packet format on USRP inband signaling
On Wed, Feb 28, 2007 at 07:23:32PM -0500, Timothy Brown wrote: > I'm considering the case whereby users might want to attach a USRPng > to a network, then either L2/L3 to multiple processing frontends. > > Thanks, > Tim Good. Thanks. Eric > > On Feb 28, 2007, at 3:39 PM, Eric Blossom wrote: > > >On Wed, Feb 28, 2007 at 09:44:30AM -0500, Timothy Brown wrote: > >>This is a somewhat unrelated question, but i'm just curious if > >>multicast is part of the thought process here? > > > >I hadn't given it much thought, one way or the other. > > > >Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
On Wed, Feb 28, 2007 at 04:54:14PM -0500, Tim Meehan wrote: > Hi Johnathan, > > make clean > ./bootstrap > ./configure > make > > also fails. See below > > If there is something I can do to help you figure this out let me > know, but don't sweat it on my account. For the moment I will just > run without mblock and when I get some time I will dig into it. > > creating libmblock-qa.la > (cd .libs && rm -f libmblock-qa.la && ln -s ../libmblock-qa.la > libmblock-qa.la) > if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DOMNITHREAD_POSIX=1 > -I../../../omnithread -I../../../pmt/src/lib -g -O2 -Wall > -Woverloaded-virtual -pthread -MT test_mblock.o -MD -MP -MF > ".deps/test_mblock.Tpo" -c -o test_mblock.o test_mblock.cc; \ > then mv -f ".deps/test_mblock.Tpo" ".deps/test_mblock.Po"; else rm -f > ".deps/test_mblock.Tpo"; exit 1; fi > /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall > -Woverloaded-virtual -pthread -o test_mblock test_mblock.o > libmblock-qa.la > g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock > test_mblock.o -pthread ./.libs/libmblock-qa.so -Wl,--rpath > -Wl,/usr/local/lib > ./.libs/libmblock-qa.so: undefined reference to > `mb_mblock::handle_message(boost::shared_ptr)' > ./.libs/libmblock-qa.so: undefined reference to > `omni_thread::init_t::init_t[in-charge]()' > ./.libs/libmblock-qa.so: undefined reference to > `mb_mblock_impl::make_accepter(std::basic_string std::char_traits, std::allocator >)' Tim and Johnathan, can you please post the contents of your /etc/ld.so.conf? Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
I'm considering the case whereby users might want to attach a USRPng to a network, then either L2/L3 to multiple processing frontends. Thanks, Tim On Feb 28, 2007, at 3:39 PM, Eric Blossom wrote: On Wed, Feb 28, 2007 at 09:44:30AM -0500, Timothy Brown wrote: This is a somewhat unrelated question, but i'm just curious if multicast is part of the thought process here? I hadn't given it much thought, one way or the other. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
Hi Johnathan, make clean ./bootstrap ./configure make also fails. See below If there is something I can do to help you figure this out let me know, but don't sweat it on my account. For the moment I will just run without mblock and when I get some time I will dig into it. creating libmblock-qa.la (cd .libs && rm -f libmblock-qa.la && ln -s ../libmblock-qa.la libmblock-qa.la) if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -g -O2 -Wall -Woverloaded-virtual -pthread -MT test_mblock.o -MD -MP -MF ".deps/test_mblock.Tpo" -c -o test_mblock.o test_mblock.cc; \ then mv -f ".deps/test_mblock.Tpo" ".deps/test_mblock.Po"; else rm -f ".deps/test_mblock.Tpo"; exit 1; fi /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_mblock test_mblock.o libmblock-qa.la g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock test_mblock.o -pthread ./.libs/libmblock-qa.so -Wl,--rpath -Wl,/usr/local/lib ./.libs/libmblock-qa.so: undefined reference to `mb_mblock::handle_message(boost::shared_ptr)' ./.libs/libmblock-qa.so: undefined reference to `omni_thread::init_t::init_t[in-charge]()' ./.libs/libmblock-qa.so: undefined reference to `mb_mblock_impl::make_accepter(std::basic_string, std::allocator >)' . On 2/28/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: Greg Troxel wrote: > I am able to build svn head on NetBSD, including mblock. It seems to > be using the new .la references for pmt and omnithread. > > (I have up-to-date auto* and swig and gcc 4.1.2.) This is useful, thanks. Tim Meehan wrote: > Just to give you another data point, I get the same errors Josh does > when trying to do a fresh build. > > svn update (4669) > > ./bootstrap > ./configure > make Can you 'make clean' first, just make sure it's actually trying to relink everything? > When I disable mblock (./configure -disable-mblock) the rest of 4669 > builds fine. This is an appropriate work around if you still run into problems. The 'mblock' component on the trunk is a work-in-progress and nothing depends upon it yet. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USPR segmentation fault
On Wed, Feb 28, 2007 at 04:19:14PM -0500, Liu Xin wrote: > Thank you for your reply, Eric. > May I ask how long you test the program? For me the segmentation fault > appears after some time (some minutes)of running . > Also I wonder what is your OS and version? > Thank you, > Xin I ran it for a couple of minutes. I tested under SuSE 10.1 on a core duo x86 laptop. [EMAIL PROTECTED] more-ecu]$ uname -a Linux cyan 2.6.16.27-0.6-smp #1 SMP Wed Dec 13 09:34:50 UTC 2006 i686 i686 i386 GNU/Linux Eric > > On Wed, 28 Feb 2007, Eric Blossom wrote: > > > On Wed, Feb 28, 2007 at 12:17:57PM -0500, Liu Xin wrote: > > > Hello, All: > > > I am running the following small program which generate a periodical > > > signal using vectors. I got Segmentation Fault, as shown in the following: > > > > > > > > > [EMAIL PROTECTED]:sudo ./Signal3.py > > > Blocked waiting for GDB attach (pid = 7714) > > > Press Enter to continue: > > > Sample rate = 8M > > > Signal will generated by : A: Flex 2400 Tx > > > Carrier : 2.468G > > > Press Enter to quit : > > > uUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUSegmentation fault > > > > > > > > > Could anyone give any suggestion on how to trace the bug or why it > > > happens? > > > > Your program runs OK for me. It does not segfault. > > > > I tested it with the current svn trunk. > > > > Eric > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USPR segmentation fault
Thank you for your reply, Eric. May I ask how long you test the program? For me the segmentation fault appears after some time (some minutes)of running . Also I wonder what is your OS and version? Thank you, Xin On Wed, 28 Feb 2007, Eric Blossom wrote: > On Wed, Feb 28, 2007 at 12:17:57PM -0500, Liu Xin wrote: > > Hello, All: > > I am running the following small program which generate a periodical > > signal using vectors. I got Segmentation Fault, as shown in the following: > > > > > > [EMAIL PROTECTED]:sudo ./Signal3.py > > Blocked waiting for GDB attach (pid = 7714) > > Press Enter to continue: > > Sample rate = 8M > > Signal will generated by : A: Flex 2400 Tx > > Carrier : 2.468G > > Press Enter to quit : > > uUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUSegmentation fault > > > > > > Could anyone give any suggestion on how to trace the bug or why it > > happens? > > Your program runs OK for me. It does not segfault. > > I tested it with the current svn trunk. > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
On Wed, Feb 28, 2007 at 12:43:27PM -0800, Johnathan Corgan wrote: > > Can you 'make clean' first, just make sure it's actually trying to > relink everything? > > > When I disable mblock (./configure -disable-mblock) the rest of 4669 > > builds fine. > > This is an appropriate work around if you still run into problems. The > 'mblock' component on the trunk is a work-in-progress and nothing > depends upon it yet. It would be nice to get to the bottom of this problem. It seem odd that only a small subset of users are seeing it. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
Greg Troxel wrote: > I am able to build svn head on NetBSD, including mblock. It seems to > be using the new .la references for pmt and omnithread. > > (I have up-to-date auto* and swig and gcc 4.1.2.) This is useful, thanks. Tim Meehan wrote: > Just to give you another data point, I get the same errors Josh does > when trying to do a fresh build. > > svn update (4669) > > ./bootstrap > ./configure > make Can you 'make clean' first, just make sure it's actually trying to relink everything? > When I disable mblock (./configure -disable-mblock) the rest of 4669 > builds fine. This is an appropriate work around if you still run into problems. The 'mblock' component on the trunk is a work-in-progress and nothing depends upon it yet. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
On Wed, Feb 28, 2007 at 09:44:30AM -0500, Timothy Brown wrote: > This is a somewhat unrelated question, but i'm just curious if > multicast is part of the thought process here? I hadn't given it much thought, one way or the other. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Release 3.0.3 Available
GNU Radio Release 3.0.3 unofficial tarballs are now available: http://gnuradio.org/releases/gnuradio/gnuradio-3.0.3.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.3.tar.gz These are the official release tarballs, but have not been signed or uploaded yet to the official GNU Project mirror system. This is a bug fix and very minor enhancement update to the stable branch. All of the relevant bug fixes that have occurred on the main development trunk have been back ported here. Details regarding the release history may be found at: http://gnuradio.org/trac/wiki/Release3.0Branch A few notes: * For those using the digital packet modulator/demodulators, a long-time issue with stalled packet transfers has been corrected. A bug in the correlator was causing false sync in the middle of packets, corrupting their content. * Shared library linking cleanup, regression Shared library linking has been cleaned up significantly in this release. This ensures that the proper GNU Radio libraries in the build tree are linked against and prevents conflicts with old or previously installed versions of GNU Radio. However, this change also introduces a functional regression relative to 3.0.2 and earlier. It is not possible to build individual GNU Radio components completely in isolation; rather, one must at least build the gnuradio-core component simultaneously with any other component. This problem mainly impacts packaging systems attempting to split GNU Radio into a package for each component; most users are unaffected. The instructions at: http://gnuradio.org/trac/wiki/BuildConfiguration ...remain unchanged. * There are many small updates to the build system for cross-platform compatibility. We are striving to ensure GNU Radio builds without change across GNU/Linux (various distributions), NetBSD, FreeBSD, Mac OS/X, and as a stretch goal, the Cygwin/MSYS environment under Win32. Enjoy. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with gri_fftw
On Wed, Feb 28, 2007 at 11:30:52AM -0800, John Clark wrote: > I am setting up a 'embedded' gnuradio application, and have run across > the following diagnostic > message. > > gri_fftw: Bad address > gr_vmcircbuf_createfilemapping: createfilemapping is not available > (null)/.gnuradio/prefs/gr_vmcircbuf_default_factory: No such file or > directory > > I've noticed simular sorts of messages when I have my root disk 'read > only', etc. > > But this one seems to cause the fft to stop processing. > > What is this prefs item, and how do I set it up correctly in a embedded > environment, and use an http server to initiate the gnuradio application > (which > is probably why there is a '(null)' in front of the directory for the > prefs, as > there may be no assigned directory for the http 'user' being used to > initiate > the application.) Try setting the HOME environment variable such that it points at a writable directory. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
I am able to build svn head on NetBSD, including mblock. It seems to be using the new .la references for pmt and omnithread. (I have up-to-date auto* and swig and gcc 4.1.2.) Making all in src gmake[1]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/mblock/src' Making all in lib gmake[2]: Entering directory `/usr/home/gdt/ADROIT-public/gnuradio/mblock/src/lib' /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_connection.lo -MD -MP -MF .deps/mb_connection.Tpo -c -o mb_connection.lo mb_connection.cc mkdir .libs g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_connection.lo -MD -MP -MF .deps/mb_connection.Tpo -c mb_connection.cc -fPIC -DPIC -o .libs/mb_connection.o mv -f .deps/mb_connection.Tpo .deps/mb_connection.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_endpoint.lo -MD -MP -MF .deps/mb_endpoint.Tpo -c -o mb_endpoint.lo mb_endpoint.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_endpoint.lo -MD -MP -MF .deps/mb_endpoint.Tpo -c mb_endpoint.cc -fPIC -DPIC -o .libs/mb_endpoint.o mv -f .deps/mb_endpoint.Tpo .deps/mb_endpoint.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_exception.lo -MD -MP -MF .deps/mb_exception.Tpo -c -o mb_exception.lo mb_exception.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_exception.lo -MD -MP -MF .deps/mb_exception.Tpo -c mb_exception.cc -fPIC -DPIC -o .libs/mb_exception.o mv -f .deps/mb_exception.Tpo .deps/mb_exception.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock.lo -MD -MP -MF .deps/mb_mblock.Tpo -c -o mb_mblock.lo mb_mblock.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock.lo -MD -MP -MF .deps/mb_mblock.Tpo -c mb_mblock.cc -fPIC -DPIC -o .libs/mb_mblock.o mv -f .deps/mb_mblock.Tpo .deps/mb_mblock.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock_impl.lo -MD -MP -MF .deps/mb_mblock_impl.Tpo -c -o mb_mblock_impl.lo mb_mblock_impl.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_mblock_impl.lo -MD -MP -MF .deps/mb_mblock_impl.Tpo -c mb_mblock_impl.cc -fPIC -DPIC -o .libs/mb_mblock_impl.o mv -f .deps/mb_mblock_impl.Tpo .deps/mb_mblock_impl.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_message.lo -MD -MP -MF .deps/mb_message.Tpo -c -o mb_message.lo mb_message.cc g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_message.lo -MD -MP -MF .deps/mb_message.Tpo -c mb_message.cc -fPIC -DPIC -o .libs/mb_message.o mv -f .deps/mb_message.Tpo .deps/mb_message.Plo /bin/ksh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/adroit/include -g -O2 -Wall -Woverloaded-virtual -pthread -MT mb_ms
Re: [Discuss-gnuradio] mblock linking error
Hi Johnathan, Just to give you another data point, I get the same errors Josh does when trying to do a fresh build. svn update (4669) ./bootstrap ./configure make When I disable mblock (./configure -disable-mblock) the rest of 4669 builds fine. I am running Debian stable with updated python, swig ... Tim On 2/28/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: Josh Blum wrote: > So I manually installed pmt. The make stops a new error with omnithread. > Going into the omnithread directory and make install doesnt fix this > one. So is ubuntu just megaborked for gnuradio? I should seek a new OS > (like fedora?) -Josh Was this after doing an 'svn update' to get the Makefile.am fix I posted last night? -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.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
Re: [Discuss-gnuradio] problem with gri_fftw
Greg Troxel schrieb: You left out a lot, like what operating system you are using. But I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a file in tmp to get shared memory, and it needs to be writable. Perhaps using mfs or tmpfs, or some other kind of memory filesystem for /tmp is in order. I'm using Linux... and whatever 'gr-vmcircbuf_createfilemapping' is, is buried deep in the gnuradio sources. In this case it looks like there's a presumption about the 'user' and having a directory associated with that user, where 'preferences', etc. can be read/written, rather than using say, /tmp or similar 'well known' writeable location. I'll have to do a find on the gnuradio sources to find the specific reference, and then figure out 'what to do'... John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] modification of gr-trellis to support, multiple initial and/or final states
Hi Achilleas No problem. Would you like me to update the documentation and submit a patch? Good luck getting back up and running. Tim On 2/28/07, Achilleas Anastasopoulos <[EMAIL PROTECTED]> wrote: Tim, thanks for the contribution. At this point I am gnuradio-less since my hard disk failed a couple of days ago... but I'll test all the uploaded code as soon as I am up and running. Thanks again, Achilleas Tim Meehan wrote: > Achilleas and Eric, > > I have attached a patch to trellis_viterbi_X.cc.t, > trellis_viterbi_X.i.t and trellis_viterbi_X.h.t > > This patch allows for multiple initial and/or final states by calling > viterbi with a vector for S0 and/or SK. The call is overloaded so > that viterbi can still be called with a scalar. The two accessor > methods for d_S0 and d_SK still work for scalars but just return the > first element if S0 or SK are vectors. I was not sure how to overload > this based on return type. > > I would be happy to write a patch for the test code qa_trellis.py but > it does not seem to have a test for viterbi right now. > > I would also be happy to write a patch for the documentation > gr_trellis.xml (was this written by hand or machine generated?) > > I don't think there was any bounds checking for the scalar call with > S0 and SK so I did not add any for the vector call. i.e. you can call > viterbi with a value for SK that is greater than the number of states. > > > Tim ___ 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] problem with gri_fftw
You left out a lot, like what operating system you are using. But I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a file in tmp to get shared memory, and it needs to be writable. Perhaps using mfs or tmpfs, or some other kind of memory filesystem for /tmp is in order. It may be that the diagnostics are not quite right. Try ktrace/truss/etc. -- Greg Troxel <[EMAIL PROTECTED]> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with gri_fftw
I am setting up a 'embedded' gnuradio application, and have run across the following diagnostic message. gri_fftw: Bad address gr_vmcircbuf_createfilemapping: createfilemapping is not available (null)/.gnuradio/prefs/gr_vmcircbuf_default_factory: No such file or directory I've noticed simular sorts of messages when I have my root disk 'read only', etc. But this one seems to cause the fft to stop processing. What is this prefs item, and how do I set it up correctly in a embedded environment, and use an http server to initiate the gnuradio application (which is probably why there is a '(null)' in front of the directory for the prefs, as there may be no assigned directory for the http 'user' being used to initiate the application.) Thanks John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USPR segmentation fault
On Wed, Feb 28, 2007 at 12:17:57PM -0500, Liu Xin wrote: > Hello, All: > I am running the following small program which generate a periodical > signal using vectors. I got Segmentation Fault, as shown in the following: > > > [EMAIL PROTECTED]:sudo ./Signal3.py > Blocked waiting for GDB attach (pid = 7714) > Press Enter to continue: > Sample rate = 8M > Signal will generated by : A: Flex 2400 Tx > Carrier : 2.468G > Press Enter to quit : > uUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUSegmentation fault > > > Could anyone give any suggestion on how to trace the bug or why it > happens? Your program runs OK for me. It does not segfault. I tested it with the current svn trunk. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic TX board
Jonathan Gill wrote: Hi, Can any one tell me how far apart the SMA connectors are set on the basic TX daughter board; I’m trying to design a PCB to match up with it 0.570 inches ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hi Eric! I need some help about OFDM
Hi I am a graduate student of Korea. I have saved all .py file of the OFDM into my directory http://gnuradio.org/trac/browser/gnuradio/branches/developers/n4hy/ofdm/gnuradio-examples/python/ofdm?rev=4566 But I don't know what file I should run firstly. How can I run and test and see the result. Help me~~~ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
Josh Blum wrote: > So I manually installed pmt. The make stops a new error with omnithread. > Going into the omnithread directory and make install doesnt fix this > one. So is ubuntu just megaborked for gnuradio? I should seek a new OS > (like fedora?) -Josh Was this after doing an 'svn update' to get the Makefile.am fix I posted last night? -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USPR segmentation fault
Hello, All:
I am running the following small program which generate a periodical
signal using vectors. I got Segmentation Fault, as shown in the following:
[EMAIL PROTECTED]:sudo ./Signal3.py
Blocked waiting for GDB attach (pid = 7714)
Press Enter to continue:
Sample rate = 8M
Signal will generated by : A: Flex 2400 Tx
Carrier : 2.468G
Press Enter to quit :
uUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUuUSegmentation fault
Could anyone give any suggestion on how to trace the bug or why it
happens?
BTW, I tried to use gdb, whenver I do "(gdb) attach PID" the program stops
running, it resumes until I quit from gdb.
Thank you for your input.
xin
The python program
=
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
from gnuradio import eng_notation
import os
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
def build_graph (carrier=2.462e9):
interp = 16
duc0 = 5e6 # IF frequency
nchan = 1
fg = gr.flow_graph ()
dest = usrp.sink_c (0, interp, nchan)
sample_rate = dest.dac_freq() / interp
print "Sample rate = ", eng_notation.num_to_str (sample_rate)
dest.set_tx_freq (0, duc0)
dest.set_pga(0,20)
max = (2**15)-1
min = -max
vector = []
for i in range(40):
vector.append(complex(max,max))
vector.append(complex(max,min))
vector.append(complex(min,max))
vector.append(complex(min,min))
for i in range(60):
vector.append(complex(0,0))
src = gr.vector_source_c(vector,True)
fg.connect (src, dest)
dboard = usrp.selected_subdev(dest, (0,0))
print "Signal will generated by :", dboard.side_and_name()
rf = dest.tune(dboard._which, dboard, carrier)
if rf:
print "Carrier :", eng_notation.num_to_str(rf.baseband_freq)
else:
print "The range of the daugtherboard's frequency is :", \
eng_notation.num_to_str(dboard.freq_range()[0]), "-", \
eng_notation.num_to_str(dboard.freq_range()[1])
raise SystemExit
return fg
if __name__ == '__main__':
mygraph = build_graph ()
mygraph.start ()
raw_input ("Press Enter to quit : ")
mygraph.stop ()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
Robert McGwier wrote: > This problem is understood. There is a change in libtool in the > Debian/Ubuntu community. I believed this was fixed here by finding > out some shell changes but it is not. Just FYI, my main development machine is Ubuntu 6.10. I have never had this issue with libtool/rpath that you describe. I have the default build installed which does indeed have the /bin/sh -> /bin/dash symlink. So there is something else going on here. > If you cannot build mblock, you need to install pmt, which alway > builds first. Go into the pmt directory and make install or sudo > make install depending on your situation. In this particular case, I believe that the specific mblock build failure that was seen was a problem with the Makefile.am that was fixed on the trunk yesterday evening. I'm still waiting confirmation of a fix or not. > There are a couple of really aggravating things in Ubuntu 6.1 (maybe > earlier) and libtool and link of sh to dash are at the top of my > list. I could not understand what in the world was going on with > these shells which had Again, there must be something else going on as neither of these are a problem for me. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] OFDM - on air?
Hi! Just curious on the channel transfer function, I did some modification on the ofdm simulation to see the magnitude and the argument. I am inverting your equalizer coefficients (and actually scaling them down). The coefficients of the region of interest in frequency domain are sent out through a new vector stream. In order to have it visual, the simulation script now is a class derived from stdgui. Maybe you are interested in that, e.g. for some demo purposes. I attached a patch. Dominik ofdm_gui.tar.gz Description: application/compressed-tar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
So I manually installed pmt. The make stops a new error with omnithread. Going into the omnithread directory and make install doesnt fix this one. So is ubuntu just megaborked for gnuradio? I should seek a new OS (like fedora?) -Josh creating libmblock-qa.la (cd .libs && rm -f libmblock-qa.la && ln -s ../libmblock-qa.la libmblock-qa.la) if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DOMNITHREAD_POSIX=1 -I../../../omnithread -I../../../pmt/src/lib -g -O2 -Wall -Woverloaded-virtual -pthread -MT test_mblock.o -MD -MP -MF ".deps/test_mblock.Tpo" -c -o test_mblock.o test_mblock.cc; \ then mv -f ".deps/test_mblock.Tpo" ".deps/test_mblock.Po"; else rm -f ".deps/test_mblock.Tpo"; exit 1; fi /bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o test_mblock test_mblock.o libmblock-qa.la g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock test_mblock.o ./.libs/libmblock-qa.so -Wl,--rpath -Wl,/usr/local/lib ./.libs/libmblock-qa.so: undefined reference to `omni_thread::init_t::init_t()' ./.libs/libmblock-qa.so: undefined reference to `omni_thread::init_t::~init_t()' ./.libs/libmblock-qa.so: undefined reference to `mb_mblock_impl::component(std::basic_stringstd::char_traits, std::allocator > const&)' ./.libs/libmblock-qa.so: undefined reference to `mb_mblock::fullname() const' collect2: ld returned 1 exit status make[4]: *** [test_mblock] Error 1 make[4]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src/lib' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/usr/src/gnuradio_trunk/mblock/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/gnuradio_trunk/mblock' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/gnuradio_trunk' make: *** [all] Error 2 Robert McGwier wrote: This problem is understood. There is a change in libtool in the Debian/Ubuntu community. I believed this was fixed here by finding out some shell changes but it is not. If you cannot build mblock, you need to install pmt, which alway builds first. Go into the pmt directory and make install or sudo make install depending on your situation. Then when you go back to the base directory and do make, the mblock (and the rest of the) make will complete quickly. There are a couple of really aggravating things in Ubuntu 6.1 (maybe earlier) and libtool and link of sh to dash are at the top of my list. I could not understand what in the world was going on with these shells which had #!/bin/sh at the top from IBM for the Cell SDK (for example), and others, not working and really bombing badly. Ubuntu has placed /bin/dash, their step towards a posix compliant sh, in the symbolic link. Shell script authors have used sh in their scripts when they probably wanted the bash extensions and should have used bash. It is still a bit ugly to drop this on us without warning and to break so many shell scripts in the process. Bob Johnathan Corgan wrote: Josh Blum wrote: The same problem occurs on cygwin. I know cygwin is a lower priority, but the issue may not be ubuntu specific. -josh Roshan Baliga wrote: I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk rev 4662 (current). The trunk tree built fine for me on the same box a month ago. (I already tried make distclean and bootstrap.) Could you gentlemen please update and retry? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] modification of gr-trellis to support, multiple initial and/or final states
Tim, thanks for the contribution. At this point I am gnuradio-less since my hard disk failed a couple of days ago... but I'll test all the uploaded code as soon as I am up and running. Thanks again, Achilleas Tim Meehan wrote: Achilleas and Eric, I have attached a patch to trellis_viterbi_X.cc.t, trellis_viterbi_X.i.t and trellis_viterbi_X.h.t This patch allows for multiple initial and/or final states by calling viterbi with a vector for S0 and/or SK. The call is overloaded so that viterbi can still be called with a scalar. The two accessor methods for d_S0 and d_SK still work for scalars but just return the first element if S0 or SK are vectors. I was not sure how to overload this based on return type. I would be happy to write a patch for the test code qa_trellis.py but it does not seem to have a test for viterbi right now. I would also be happy to write a patch for the documentation gr_trellis.xml (was this written by hand or machine generated?) I don't think there was any bounds checking for the scalar call with S0 and SK so I did not add any for the vector call. i.e. you can call viterbi with a value for SK that is greater than the number of states. Tim ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] mblock linking error
This problem is understood. There is a change in libtool in the Debian/Ubuntu community. I believed this was fixed here by finding out some shell changes but it is not. If you cannot build mblock, you need to install pmt, which alway builds first. Go into the pmt directory and make install or sudo make install depending on your situation. Then when you go back to the base directory and do make, the mblock (and the rest of the) make will complete quickly. There are a couple of really aggravating things in Ubuntu 6.1 (maybe earlier) and libtool and link of sh to dash are at the top of my list. I could not understand what in the world was going on with these shells which had #!/bin/sh at the top from IBM for the Cell SDK (for example), and others, not working and really bombing badly. Ubuntu has placed /bin/dash, their step towards a posix compliant sh, in the symbolic link. Shell script authors have used sh in their scripts when they probably wanted the bash extensions and should have used bash. It is still a bit ugly to drop this on us without warning and to break so many shell scripts in the process. Bob Johnathan Corgan wrote: Josh Blum wrote: The same problem occurs on cygwin. I know cygwin is a lower priority, but the issue may not be ubuntu specific. -josh Roshan Baliga wrote: I've run into the same problem on Ubuntu 6.06 (Dapper Drake) at trunk rev 4662 (current). The trunk tree built fine for me on the same box a month ago. (I already tried make distclean and bootstrap.) Could you gentlemen please update and retry? -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "Taking fun as simply fun and earnestness in earnest shows how thoroughly thou none of the two discernest." - Piet Hine ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: RE: why does this code don't work!! help
Quoting anmar <[EMAIL PROTECTED]>: > hi Tom, > thanks for your help, > > > need to make sure the signal's sampling rate matches the DAC's sampling > > rate > > of 128 Msps _after_ interpolation (so if inter=128, sampling_freq=1e6). > > ok I didn't understood the interpolation, in fact i the hole > interpolation is confusing me because we have : > usrp interp, dac rate and usrp rate, i get them all mixed up. If you don't understand interpolation and decimation, I suggest you read up on them and on sampling theory in general. These are _very_ important concepts in SDR. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
This is a somewhat unrelated question, but i'm just curious if multicast is part of the thought process here? On Feb 28, 2007, at 2:06 AM, Eric Blossom wrote: On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote: Eric Blossom <[EMAIL PROTECTED]> writes: On Tue, Feb 27, 2007 at 07:49:02AM -0500, Greg Troxel wrote: I'm thinking layer 2 with a unique Ethernet packet type (probably use some abandoned packet type). That said, there's nothing stopping us from doing UDP, except the additional bandwidth. I don't see any need to do TCP. I think that it should be possible for an unprivileged user (on most Free systems) to interact with a USRP over GigE. Actually this raises the issue of authorization and confidentiality/integrity of the data, probably taken care of by a dedicated ethernet port. Under GNU/Linux they may need to be holding CAP_NET_RAW, since I think the way to get the raw ethernet frames is with libpcap and/or opening a raw socket using socket(PF_PACKET, SOCK_RAW, ...) Any idea how we would get this done under *BSD? Two ways: use bpf. This requires r/w access to /dev/bpf, but that also enables reading and writing other traffic. Presumably CAP_NET_RAW on Linux does too, and that's overly broad. write a protocol family driver for the USRP ethertype (hard) OK. To me, this all argues for IP/UDP (at the cost of 28 bytes) being the standard approach, with raw being an optimization if needed. It handles the privilege issues, and gives you multiplexing hooks (which we may not usually need). OK. I'm hoping on suitable machines to be able to run near wire- speed, so that also argues for a dedicated ethernet port. Sure, but speed should be an orthogonal design issue from security and multiplexing. OK. Also, absent some driver hacking to mux and demux commands and responses, we may need a user space process to handle that stuff. In that case, only that processes would need access to the magic socket, and the rest of the user code would use some kind of IPC to talk to that one. OK, but that's likely to be somewhat slower. But I don't understand the mux/demux need, beyond connecting a USRP to a user process. Do you envision two programs each accessing some part of the resources on a single GigE connected USRPng? Sure. It's a common operation now. We often run an fft in one process and some kind of transmitter in another. Somebody's got to handle the dumuxing of command replies. Using your UDP example, we'd have the source port of the request to route the reply. That still leaves the flags such as Overrun, Underrun, etc., which I was thinking were only going to get reported once, and then cleared. (I didn't see a good reason for forcing the host to explicitly clear the flag.) Pause frames provide flow control. According to folks at Vanu (who use Gigabit ethernet to implement their basestations), that's been sufficient, assuming any switches along the way aren't brain damaged. Locally, sure one can enforce that by declaring them broken and replacing them. If somebody wanted to ship samples a long way reliably, then some higher-level protocol is probably in order. It may make sense to define a TCP or SCTP method, but then again it may not - this is perhipheral attachment. I'd hate to try to stuff either of those in an inexpensive FPGA. Of course if somebody wanted those, they could stick some kind of single board computer next to the USRPng and have it run TCP or SCTP or whatever. Eric ___ 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: RE: why does this code don't work!! help
hi Tom, thanks for your help, > need to make sure the signal's sampling rate matches the DAC's sampling > rate > of 128 Msps _after_ interpolation (so if inter=128, sampling_freq=1e6). ok I didn't understood the interpolation, in fact i the hole interpolation is confusing me because we have : usrp interp, dac rate and usrp rate, i get them all mixed up. >> src0 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 30e4, 1.0, 1 >> ) >> src1 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 10e4, 0.5, 1 >> ) > > You are using floating point signal sources here ohh that is very stupid of me, i didn't noticed that, didn't even looked there ops Anmar -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated packet format on USRP inband signaling
Eric Blossom <[EMAIL PROTECTED]> writes: > Sure. It's a common operation now. We often run an fft in one > process and some kind of transmitter in another. Somebody's got to > handle the dumuxing of command replies. Using your UDP example, we'd > have the source port of the request to route the reply. That still > leaves the flags such as Overrun, Underrun, etc., which I was thinking > were only going to get reported once, and then cleared. (I didn't see > a good reason for forcing the host to explicitly clear the flag.) I envision some number of data streams to/from the USRP, each with it's own destination on the host. They then could each have over/underrun flags. If it's mainly about tx vs rx, or separate data streams, then that's something that could be muxed on udp port. This likely requires a lot more thought. > On Tue, Feb 27, 2007 at 11:28:26AM -0500, Greg Troxel wrote: > >> It may make sense to define a TCP or SCTP method, but then again it >> may not - this is perhipheral attachment. > > I'd hate to try to stuff either of those in an inexpensive FPGA. Of > course if somebody wanted those, they could stick some kind of single > board computer next to the USRPng and have it run TCP or SCTP or > whatever. Sure - I was thinking the same thing. The requirements document probably should say "local bus attachment". ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] why does this code don't work!! help
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:discuss-
>
> hi,
> i have made this simple program, it spouse to send tx signals one to
> each tx board.
> #!/usr/bin/env python
> from gnuradio import gr
> from gnuradio.eng_notation import num_to_str, str_to_num
> from gnuradio import usrp
> from gnuradio import audio
> from gnuradio import blks
> from gnuradio.eng_option import eng_option
> from optparse import OptionParser
> import usrp_dbid
> import math
> import sys
>
> def build_graph ():
>
> fg = gr.flow_graph ()
> u = usrp.sink_c(nchan=2, interp_rate=128)
> sampling_freq = 128e6
That high of a sampling rate? I hope you're running this on a super
computer, because a normal system won't be able to handle this. Also, you
need to make sure the signal's sampling rate matches the DAC's sampling rate
of 128 Msps _after_ interpolation (so if inter=128, sampling_freq=1e6).
> src0 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 30e4, 1.0, 1
> )
> src1 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 10e4, 0.5, 1
> )
You are using floating point signal sources here
>
> #this was an am_tx script
> #mixer = gr.multiply_ff ()
> #dst = usrp.sink_c(0, 128)
> #f2c = gr.float_to_complex()
>
> interleaver = gr.interleave(gr.sizeof_gr_complex)
And here you're using complex values.
> fg.connect(src0, (interleaver, 0))
> fg.connect(src1, (interleaver, 1))
> fg.connect(interleaver, u)
> r0 = u.tune(0, u.db[0][0], 10e6) # set center freq on side A
> d'board
> r1 = u.tune(1, u.db[1][0], 5e6)
> return fg
>
> if __name__ == '__main__':
> fg = build_graph ()
> fg.start ()
> raw_input ('Press Enter to quit: ')
> fg.stop ()
>
> when i run that code i get this error:
>
> # python am_tx_two_sig.py
> Traceback (most recent call last):
> File "am_tx_two_sig.py", line 41, in ?
> fg = build_graph ()
> File "am_tx_two_sig.py", line 32, in build_graph
> fg.connect(src0, (interleaver, 0))
> File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
> line 115, in connect
> self._connect (points[i-1], points[i])
> File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
> line 120, in _connect
> self._connect_prim (s, d)
> File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
> line 128, in _connect_prim
> self._check_type_match (src_endpoint, dst_endpoint)
> File
> "/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
> line 242, in _check_type_match
> raise ValueError, (
> ValueError: source and destination data sizes are different:
> sig_source_f interleave
Look at your error message, it's telling you where the problem is. The
signal source outputs are different data types (float, 4 bytes) than the
interleaver (gr_complex, 8 bytes).
>
> what is going wrong this is not much different of the
> fm_tx_2_daughterboard.py.
> Thanks
> anmar
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] No BPSK modulator?
> -Original Message- > From: Matt Ettus [mailto:[EMAIL PROTECTED] > > > (which makes me > > curious, does anyone use non-differential 8PSK?). > > > > Yes, satellites often do. > > Matt Good enough for me. We should support it, then. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] No BPSK modulator?
> -Original Message- > From: [EMAIL PROTECTED] [mailto:discuss- > > 2007/2/27, Eric Blossom <[EMAIL PROTECTED]>: > > On Tue, Feb 27, 2007 at 05:07:31PM -0500, Tom Rondeau wrote: > > > > -Original Message- > > > > From: [EMAIL PROTECTED] > [mailto:discuss- > > > > [EMAIL PROTECTED] On Behalf Of Trond > Danielsen > > > > Sent: Tuesday, February 27, 2007 10:46 AM > > > > To: gnuradio mailing list > > > > Subject: [Discuss-gnuradio] No BPSK modulator? > > > > > > > > Hi, > > > > > > > > Is there a reason why there is no "ordinary" n-PSK modulator and > > > > demodulator available, only the differential one? If not, I'll > modify > > > > the existing one and submit a patch. > > > > > > It's not so much that there isn't a non-differential BPSK modulator, > it's > > > that there is no demod for it. Basically, we have to be able to > determine > > > the phase orientation of the incoming signal in some way to know what > our > > > phase is. In BPSK, this is simple, and this was the original reason > why > > > gr_correlate_access_code_bb had a d_flip variable in it, so that when > the > > > phase inversion was detected, it would decode it properly. > > > > > > However, this was never a good solution and ended up hurting us > because > > > sometimes we'd trigger this flip with random data, which would screw > up the > > > packets. This was the reason the SSH sessions would crash and why > Johnathan > > > made the original fix in the whitener. > > > > > > The solution to this is to use the correlator to detect the phase, but > let > > > the next guy down the line understand what to do with it. We probably > want > > > to send a control signal out to set the phase derotation and trigger > the > > > access code found state at the same time, specifically, in the simple > framer > > > state machine. > > > > You could use bit 2 of the output stream of > > gr_correlate_access_code_bb to encode the "I've seen the inverted > > pattern". Then anybody who cared could look at it and take action if > > they wanted to, but it wouldn't interfere with any existing code. > > > > Eric > > > > Thank you all for anwering. What I am really looking for is just BPSK, > so that should simplify things a bit. I intent to demodulate the BPSK > modulated message from GPS satellites, therefore the interest in > not-differential PSK modulation. I was under the same opinion, which was why d_flip was in correlate_access_code originally, but that screwed some stuff up down the chain. I think whatever new solution we use should be general for non-differential MPSK and not just BPSK. > To make things a bit clearer: correlate_access_code is in reality a > preamble detector, or am I missing something? The access code, which is not only used to identify the start of a MAC frame, but it can also identify the network being used. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] No BPSK modulator?
2007/2/27, Eric Blossom <[EMAIL PROTECTED]>: On Tue, Feb 27, 2007 at 05:07:31PM -0500, Tom Rondeau wrote: > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:discuss- > > [EMAIL PROTECTED] On Behalf Of Trond Danielsen > > Sent: Tuesday, February 27, 2007 10:46 AM > > To: gnuradio mailing list > > Subject: [Discuss-gnuradio] No BPSK modulator? > > > > Hi, > > > > Is there a reason why there is no "ordinary" n-PSK modulator and > > demodulator available, only the differential one? If not, I'll modify > > the existing one and submit a patch. > > It's not so much that there isn't a non-differential BPSK modulator, it's > that there is no demod for it. Basically, we have to be able to determine > the phase orientation of the incoming signal in some way to know what our > phase is. In BPSK, this is simple, and this was the original reason why > gr_correlate_access_code_bb had a d_flip variable in it, so that when the > phase inversion was detected, it would decode it properly. > > However, this was never a good solution and ended up hurting us because > sometimes we'd trigger this flip with random data, which would screw up the > packets. This was the reason the SSH sessions would crash and why Johnathan > made the original fix in the whitener. > > The solution to this is to use the correlator to detect the phase, but let > the next guy down the line understand what to do with it. We probably want > to send a control signal out to set the phase derotation and trigger the > access code found state at the same time, specifically, in the simple framer > state machine. You could use bit 2 of the output stream of gr_correlate_access_code_bb to encode the "I've seen the inverted pattern". Then anybody who cared could look at it and take action if they wanted to, but it wouldn't interfere with any existing code. Eric Thank you all for anwering. What I am really looking for is just BPSK, so that should simplify things a bit. I intent to demodulate the BPSK modulated message from GPS satellites, therefore the interest in not-differential PSK modulation. To make things a bit clearer: correlate_access_code is in reality a preamble detector, or am I missing something? -- Trond Danielsen ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Basic TX board
Hi, Can any one tell me how far apart the SMA connectors are set on the basic TX daughter board; I'm trying to design a PCB to match up with it Thanks Jon Gill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] why does this code don't work!! help
hi,
i have made this simple program, it spouse to send tx signals one to
each tx board.
#!/usr/bin/env python
from gnuradio import gr
from gnuradio.eng_notation import num_to_str, str_to_num
from gnuradio import usrp
from gnuradio import audio
from gnuradio import blks
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import usrp_dbid
import math
import sys
def build_graph ():
fg = gr.flow_graph ()
u = usrp.sink_c(nchan=2, interp_rate=128)
sampling_freq = 128e6
src0 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 30e4, 1.0, 1
)
src1 = gr.sig_source_f ( sampling_freq, gr.GR_SIN_WAVE, 10e4, 0.5, 1
)
#this was an am_tx script
#mixer = gr.multiply_ff ()
#dst = usrp.sink_c(0, 128)
#f2c = gr.float_to_complex()
interleaver = gr.interleave(gr.sizeof_gr_complex)
fg.connect(src0, (interleaver, 0))
fg.connect(src1, (interleaver, 1))
fg.connect(interleaver, u)
r0 = u.tune(0, u.db[0][0], 10e6) # set center freq on side A
d'board
r1 = u.tune(1, u.db[1][0], 5e6)
return fg
if __name__ == '__main__':
fg = build_graph ()
fg.start ()
raw_input ('Press Enter to quit: ')
fg.stop ()
when i run that code i get this error:
# python am_tx_two_sig.py
Traceback (most recent call last):
File "am_tx_two_sig.py", line 41, in ?
fg = build_graph ()
File "am_tx_two_sig.py", line 32, in build_graph
fg.connect(src0, (interleaver, 0))
File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
line 115, in connect
self._connect (points[i-1], points[i])
File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
line 120, in _connect
self._connect_prim (s, d)
File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
line 128, in _connect_prim
self._check_type_match (src_endpoint, dst_endpoint)
File
"/usr/local/lib/python2.4/site-packages/gnuradio/gr/basic_flow_graph.py",
line 242, in _check_type_match
raise ValueError, (
ValueError: source and destination data sizes are different:
sig_source_f interleave
what is going wrong this is not much different of the
fm_tx_2_daughterboard.py.
Thanks
anmar
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP.. programming the FPGA..
Hello i have tried with USRP_fft.py and then took a sinosidal input and then after running this on cygwin (on window xp) , we were able to see this sine wave at one RX daughter board. so now we didnt understood that by doing so how the FPGA is programmed for this operation, what we have done for that. as i guess that USRP_FFT.PY must be containing some instantiation of.RBF file. so what i understood is that first we have to generate a .RBF file from a verilog code using quartus 2 software and then we have to use usrp_fft.py to download it into FPGA. but i am not clear how it is happening, suppose if i will modify .RBF file then should i need to modify usrp_fft.py code also i hope for more information regarding this.. thank you pankaj Eric Blossom <[EMAIL PROTECTED]> wrote: On Mon, Feb 26, 2007 at 08:21:10AM -0800, pankaj kumar wrote: > the code which you have suggested, how to get that..? > > usrp_fft.py > > where i am supposed to get this one... > > pankaj First off, download the GNU Radio code. Start here: http://gnuradio.org/trac/wiki It's in gnuradio-examples/python/usrp/usrp_fft.py Eric - Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started!___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
Well, I have implemented a bit of a strange setup which seems to be working somewhat now. I'm not really trying to view only the first few samples, I'm currently trying to track where I might of made a mistake with trying to generate a defined pulse with a specific length. My aim is to generate a very narrow band chirp to transmit on a little ultrasonic tranducer. I figured out which numerical values to the gr.modulation block produce which frequencies. Using this, I made a vector of the exact number of samples I want with the values to produce the frequencies I want. In my case 39-41 kHz. For some reason these low frequencies still make it through the transformer on the basic TX db, so I'm using them. Initially I was just generating a sine wave, and trying to use gr.head to limit the number of samples, but I've since switched to this approach I figured that if I wanted to produce a wave form lasting 10 msecs, then I would need at least 2500 samples. I got this number from the DAC rate of 128M and the highest interpolation factor of 512. When I test with the scope set to auto store, I spot the waveform, but it is only 1 msec long. So either I've lost a lot of samples somewhere, or my scaling is wrong. I pretty much abandoned using gr.head, as it wasn't producing anything. At least now though I can see a waveform, though my scaling seems to have gone wrong somewhere. When you say you used a looback, do you mean you connected the TX db output and RX db input, and used the gr.oscope block to view your signals? Regards Lance - Original Message From: Lee Patton <[EMAIL PROTECTED]> To: seph 004 <[EMAIL PROTECTED]> Cc: discuss-gnuradio@gnu.org Sent: Tuesday, February 27, 2007 12:58:31 AM Subject: Re: [Discuss-gnuradio] The shortest pulse length On Mon, 2007-02-26 at 00:55 -0800, seph 004 wrote: > I have a vector source producing a sine wave, and then I'm using > gr.head to limit the number of samples sent. I'm sure you checked this, but are you trying to capture the first few samples of sin(x)? I so, sin(x) = x for small angles, and sin(0)=0. So, you won't see anything in the first few samples anyway. > From your explanation, I should be ok with even a low number of > samples. When I tested my setup, I couldn't catch anything on the > scope. There is probably some problem in how I made the app. > > I saw something mentioned elsewhere in the discussion archives that > the usrp dumps the first few samples it receives from the host before > transmitting. Is this still something to take note of? I don't know whether or not the USRP dumps the first few samples. I don't think I've ever experienced it though. I can say that there is an unpredictable delay from the generation of the first sample in software until the time it actually reaches the output port. I haven't tried to do what you're doing -- i.e., capture the first few output samples on a scope. How is the scope triggered? (What I did was create a loopback whereby I transmit and receive by reading the bleedover on the daugherboard.) -Lee Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] OFDM - on air?
Hi! So there is no obvious fault, e.g. that I set the wrong decimation/interpolation rate? (the samplerate should be 400kS/s?) I just compared "tx_ofdm.dat", recorded in your simulation, to my recorded file. Therefore I modified usrp_fft.py. In tx_ofdm.dat, it shows a large frequency band in use, as expected. Unfortunately, my file does not show the same behavior :-( It looks like gaussian noise with a small carrier in the middle. Maybe I did not setup correctly the transmit path. The first few seconds while recording, there were no signal transmission. This stage can be recognized in a waterfall diagram. It seems to me that "the gaussian noise" I saw could be the transmitted OFDM signal. > If you want to start playing around with it, benchmark_ofdm.py does a > loopback simulation with optional AWGN and multipath channels between the Tx > and Rx blocks. We're hoping to inject some quiet time into this simulation > to test the signal acquisition capabilities. That is, we know that under > steady-state conditions we synchronize pretty well, but we don't know the > transient behavior when we first get s signal into the receiver. Good work! I studied the simulation for some hours, before I started to port the sim to use the usrp. > Yes, we've injected a lot of debug information here, but I thought the code > checked in had that output turned off. Are you using the newest code (and > yes, I did just check a few new things in that we didn't do before Matt > left). The debug information appear because I turned it on. I am working on the latest copy. > Thanks! It's a bit premature still, but I'm sure we'll all be glad for more > feedback as it comes together. If you like, I can give you further feedback from time to time. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB packet format / inband signaling
On Tue, Feb 27, 2007 at 08:24:48PM -0500, Brian Padalino wrote: > Hi Thibaud, > > Here is my response as to how I understand things to work - which > could be completely wrong. > > On 2/27/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote: > >Hi all, > > > >First of all, I would like to make sure that I have understood what is > >going to be modified. I have made a diagram with the whole Gnuradio > >component stack: http://img168.imageshack.us/img168/415/groveralleb2.png > > > >1) The new usb packet will be encoded/decoded in the gnuradio uspr > >driver and in the FX2 firmare right? > > On the host side, the message blocks will queue up the commands and > create the packet structure that will go down to the USRP driver and > be delivered by libusb. > > A specific endpoint within the FX2 will be used to figure out if it's > an m-block packet or something else (like a packet to tell the FX2 to > program the FPGA). We'll still have 3 endpoints: ep0, the control endpoint, will be used to load firmware into the FX2 and the bitstream into the FPGA. ep2 is the Tx (outbound) endpoint. It supports "bulk" transfers. All Tx data and command packets will be sent to this endpoint. ep6 is the Rx (inbound) endpoint. It supports "bulk" transfers. All Rx data and command replies will come from this endpoint. The FX2 will only examine the ep0 commands. Data on ep2 and ep6 is transparently passed between the FPGA and host via the FX2 GPIF interface. At most minor changes should be required in the FX2 firmware. The transparent forwarding of ep2 and ep6 will work just like it does now. > The FX2 firmware will then be pretty transparent and pass along the > information over the same datapath as the current TX/RX samples. Yes. > Once inside the FPGA, some command parsing happens and the samples are > sent on through to a FIFO where they sit until their timestamp comes > up while the control words go on to some kind of control FSM that will > take care of all those commands based on timestamp. Yes. One thing to be aware of is that there are two clock domains in the FPGA: the master clock (64 MHz) and the USB Clock (48 MHz). The Rx and Tx FIFOs bridge those two clock domains. > The packets going from the USRP to the host will be created within the > FPGA and send on out through the m-block FIFO that the FX2 will read. Yes. The FPGA will build 512 byte packets and queue them for transmission to the FX2 across the GPIF interface. The FX2 will transparently forward them to the host. The host code will then "do the right thing" ;) > Again - I am not sure if this is how it is supposed to be, but this is > how I have read it thus far. > > >2) The FX2 and the fpga communicate using the serial bus (SDI/SDO) (plus > >some control signal like usb_ctl, usb_rdy) and the usb_data bus. Will > >the commands be sent trough the serial bus or through the usb_data bus ? > > I suppose I answered this a bit up above. The SDI/SDO stuff won't be used to communicate between the FX2 and the FPGA. In the current code we use it to read and write FPGA registers. Everything will be sent across the GPIF. The flow control (HAS_SPACE and PKT_AVAIL) and bus interface pins will be used exactly as they currently are. The RX_OVERRUN, TX_UNDERRUN, and FPGA_CLR_STATUS pins will no longer be needed, since that information will be communicated in the bits in the header of the OUT packets. > >What is exactly the daughter board role and its responsibilities ? Is it > >only a physical interface for the antenna ? > > For the most part, it's our link to the outside world. When doing a > frequency hopping scheme or a TDMA scheme, you have to transmit at > extremely specific times, or change frequencies very quickly and > accurately. To do this, you need tight control over the PLL, > synthesizer, mixer, any tuners, etc that will govern how and where > your signal shows up in the spectrum. The role of the daugherboard is > really to make sure the signal gets out as cleanly as possible. Yes. They handle the analog conversion between baseband and RF. > >I also a few question about the format itself: > > > >I don't understand the purpose of the Tag field. Can you explain it a > >little bit ? > > I think this is just a specific identifier for future use. I am not > exactly certain myself. Stay tuned. I think the host is going to want it, but it might turn out to be unnecessary. I was thinking it could be used by the host to determine when an Rx frequency change had occurred without requiring a reply packet. E.g., if the FPGA copied the last seen IN tag into the OUT packets, the host could use a new tag for the command packet that contained the "tune commands". When it saw that new tag in the IN stream, it would know that the "tune" had occurred. This could be "premature optimization..." > >I don't understand how the timestamps will work on OUT packets: How the > >host will know what the value of the 32 bits counter incremented by the
