[Discuss-gnuradio] Info regarding replacing USB with Infiniband Optical Fiber
Hi, We are working on using GNURadio for using it as RF node capable of 2*2/4*4 MIMO. All the RF nodes are connected to very big FPGA like the one used in "Berkeley Emulation Engine (BEE)" using "Infiniband" Optical Fiber. All the signal processing is implemented in "BEE" hardware. We wanted to replace USB with Infiniband so that we can send raw ADC/DAC samples to/from BEE processing engine. It would be very helpful if some body could give us pointers on how to do this so that we can reuse most of the design of GNUradio board. Also, I have come across some people using two GNURadio boards for 4*4 MIMO. Is there a document which describes how to synchronize the LOs of two GNURadio boards for coherent MIMO processing and program two GNURadio boards for 4*4 MIMO?? Thanks, Rohit ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error make usrp
Hi, everyone. I have problems with installing usrp when i give a command make. The error like this: [EMAIL PROTECTED] usrp-0.12]# make make all-recursive make[1]: Entering directory `/home/usrp/usrp-0.12' Making all in config make[2]: Entering directory `/home/usrp/usrp-0.12/config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/usrp/usrp-0.12/config' Making all in host make[2]: Entering directory `/home/usrp/usrp-0.12/host' Making all in misc make[3]: Entering directory `/home/usrp/usrp-0.12/host/misc' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/usrp/usrp-0.12/host/misc' Making all in lib make[3]: Entering directory `/home/usrp/usrp-0.12/host/lib' make all-am make[4]: Entering directory `/home/usrp/usrp-0.12/host/lib' if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../host/lib -I../../firmware/include -g -O2 -Wall -Woverloaded-virtual -MT fusb_linux.lo -MD -MP -MF ".deps/fusb_linux.Tpo" -c -o fusb_linux.lo fusb_linux.cc; \ then mv -f ".deps/fusb_linux.Tpo" ".deps/fusb_linux.Plo"; else rm -f ".deps/fusb_linux.Tpo"; exit 1; fi g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../host/lib -I../../firmware/include -g -O2 -Wall -Woverloaded-virtual -MT fusb_linux.lo -MD -MP -MF .deps/fusb_linux.Tpo -c fusb_linux.cc -fPIC -DPIC -o .libs/fusb_linux.o fusb_linux.cc:30:28: error: linux/compiler.h: No such file or directory make[4]: *** [fusb_linux.lo] Error 1 make[4]: Leaving directory `/home/usrp/usrp-0.12/host/lib' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/usrp/usrp-0.12/host/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/usrp/usrp-0.12/host' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/usrp/usrp-0.12' make: *** [all] Error 2 [EMAIL PROTECTED] usrp-0.12]# Can someone help me? Thanks mahendra ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
G'day,
I've successfully built and tested gnuradio-3.0.3rc1 with pkgsrc see below:
barossa: {376} make install
===> Checking for vulnerabilities in gnuradio-3.0.3rc1
===> Installing for gnuradio-3.0.3rc1
=> Automatic manual page handling
=> Registering installation for gnuradio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-jack-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-oss-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-portaudio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-docs-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-examples-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-gsm-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-howto-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-radio-astronomy-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-trellis-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-video-sdl-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-wxgui-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-docs-3.0.3rc1
barossa: {377}
BTW: Is there any particular reason why gr-howto-write-a-block is standalone
and not part of the gnuradio distribution? Seems odd
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
Eric Blossom <[EMAIL PROTECTED]> writes: > The build tree should be linking against the build tree > (non-installed) libs. I agree, and pretty clearly it wasn't. > I understand your goal, but that's not how we're currently doing it. > If you've got a suggestion (and a patch) to handle this robustly both > ways, I'm willing to entertain it. Entirely reasonable. > What I want to be sure that we can do is to run make check against the > non-installed libraries prior to installation. > > Is NetBSD using a vanilla version of libtool, or a modified version? pkgsrc has a slightly modified version, but it seems to be only patches for various platforms that haven't been merged upstream for various reasons. I'm aware of no intent to behave oddly on purpose. Jonathan Corgan wrote: On my main development system (Linux Ubuntu 6.10), I normally do a 'make uninstall' to clean out the system directories of related libraries, .py files, .h files, etc. Then I do a 'make distclean' inside the tree, to remove all the old cruft. Only then do I do the usual ./bootstrap, ./configure, etc. I did make uninstall, clean, make and it built. But I'd say it's a bug if you have to uninstall first. I can't trivially reproduce this first, but it seems to be mblock's use of pmt that's troublesome. This could be just the only user of functions that changed signature, though. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
On Fri, Feb 23, 2007 at 05:27:45PM -0500, Greg Troxel wrote: > I updated and tried to build the head of svn recently after not having > done so for several weeks. The block code failed to build, > complaining about several pmt_foo functions not being found. I did a > 'make -k install' from top level, and then it built fine. So it seems > that the build is linking against installed libs rather than in-tree > libs. The build tree should be linking against the build tree (non-installed) libs. > I'm of two minds here, becaues I think it's very important that we be > able to build components by themselves against installed libraries. > So, probabaly the build should use -L for the build tree and then also > the installed path, in that order. I understand your goal, but that's not how we're currently doing it. If you've got a suggestion (and a patch) to handle this robustly both ways, I'm willing to entertain it. What I want to be sure that we can do is to run make check against the non-installed libraries prior to installation. Is NetBSD using a vanilla version of libtool, or a modified version? At least under GNU/Linux the unmodified libtool does what I expect (supports testing against non-installed libs), and relinks against the install path as part of installation. The Ubuntu folks have patched libtool in a way that breaks the ability to test before installing. Putting it mildly, I think they're out of their minds ;) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
On 2/23/07, John Clark <[EMAIL PROTECTED]> wrote: Daniel Garcia schrieb: > can you send me the output from the console? and the command line you used. > > -Daniel This is what I get: ./usrp_tv_rcv_testingNTSC.py -n -f 477.25 -d 26 This may be a stupid question, but does it matter that the frequency specified there does not have the "M" suffix that the example webpage uses? ./usrp_tv_rcv_testingNTSC.py -n -f 477.25 -d 26 ./usrp_tv_rcv_testingNTSC.py -n -f 481.25M -d 26 R C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] compile failure of svn head with slightly old install
Greg Troxel wrote: > I updated and tried to build the head of svn recently after not having > done so for several weeks. The block code failed to build, > complaining about several pmt_foo functions not being found. I did a > 'make -k install' from top level, and then it built fine. So it seems > that the build is linking against installed libs rather than in-tree > libs. On my main development system (Linux Ubuntu 6.10), I normally do a 'make uninstall' to clean out the system directories of related libraries, .py files, .h files, etc. Then I do a 'make distclean' inside the tree, to remove all the old cruft. Only then do I do the usual ./bootstrap, ./configure, etc. I've done this twice today on the trunk with no problems, and once with the release 3.0 branch, including 'make distcheck'. Not sure what's happening in your situation--can you try the above? -- 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] compile failure of svn head with slightly old install
I updated and tried to build the head of svn recently after not having done so for several weeks. The block code failed to build, complaining about several pmt_foo functions not being found. I did a 'make -k install' from top level, and then it built fine. So it seems that the build is linking against installed libs rather than in-tree libs. I'm of two minds here, becaues I think it's very important that we be able to build components by themselves against installed libraries. So, probabaly the build should use -L for the build tree and then also the installed path, in that order. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX400 modifications
thanks Brian. vincenzo On Fri, 2007-02-23 at 16:54 -0500, Brian Padalino wrote: > On 2/23/07, Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote: > > Hi Matt, > > > > could you please detail to me the modification needed to use the > > following feature of the RFX400 > > > > > > quote: > > > > " > > Additionally, minor modifications to the board can move > > receive ports.the frequency range to anywhere from 200 MHz to > > 800 MHz (contact Ettus Research for details). > > > > " > > Surprisingly enough, while updating the Wiki, I ran into a place where > Matt had described this. > > It can be found here: > > http://gnuradio.org/trac/wiki/UsrpDBoardRFX400 > > > we could be interested in buying a couple of them in our lab in Pisa > > for two applications: a dvb-t transmitter and something (I'm not working > > on it) involving Marine VHF band. > > > > is it possible to achieve a lower frequency bound of 150MHz? > > > > thanks > > vincenzo > > Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Preliminary In-band signaling
On Thu, Feb 22, 2007 at 12:43:13AM -0500, Brian Padalino wrote: > On 2/21/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > >I'm planning on adding a section talking about the control channel. > >I expect the control channel payload to be composed of a sequence of > >ops + args that is reasonably easy to parse in the FPGA. Control > >channel ops will honor the timestamp too. > > > >One of the ops will be WRITE_REGISTER. > >Others will include the rest of the stuff that can't be squeezed into > >WRITE_REGISTER such as I2C_READ/WRITE, SPI_READ/WRITE > > Very nice. Are you thinking more of like a special machine language > that gets put together based on daugherboards PLL locking times and > sequencing of the bring up / tear down of the RF section? I was thinking of something less general than that, though I like the idea! Maybe we do it in two passes. First pass is to implement the existing "host driven" tuning processes by providing the appropriate primitives for reading and writing the SPI, I2C, etc., then the second pass is to move the actual daughterboard specific "tune" code into the FPGA. This would enable FPGA controlled frequency hopping, amongst other things. There's probably some kind of minimalistic microcontroller core at opencores.org that we could use for this. Something like an micro- or pico-blaze, but free and not tied to a particular vendor. > Knowing the sequencing times for all the daughterboards and how > quickly we can switch between TX/RX and change frequencies is > definitely essential to calculating guard times. Are these documented > anywhere, or does it require going through the datasheets and picking > Matt's brain? Matt's brain and the data sheets ;) > >One of the use cases we want to be able to satisfy is TDMA waveforms. > >In those cases you need to be able to hit a transmit slot that is > >defined in relationship to some other receive slot. Think about how > >cellular mobiles work. > > > >The timestamp will be a free running counter that is logically > >adjacent to the A/D and D/A i/o pins. On receive, the value stuck into the > >packet is the value of the counter that corresponds to the first > >sample in the payload. On Tx, the timestamp corresponds to the tick > >that the first sample of the payload will be sent to the DACS. > > Since all real processing occurs inside the host computer, how do we > know how many samples we need to send back to the host during one of > these RX sessions? Should the duration be set in terms of samples or > in terms of start time / stop time? First pass, I think we just leave the RX signal processing path running all the time. We can control the RF front end T/R switch as needed, but (outside of wasted bandwidth), I don't see any harm in running the Rx chain. I think we'll want to stick the current value of the RSSI into the received packet header too. See below on h/w agc for packet based processing. > The way I've seen it done in the past is to use an acquisition matched > filter and look for the correlation peak, but with all the different > modulation types available, it might not be feasible to run them all > in the same FPGA load. Yes. A related issue is the control loop for the hardware AGC. I think that there are at least two modes or versions, the continuous stream and and the packet based version. With the packet based version it looks like we need quick acquistion and lockup, so that we don't miss much of the packet. We'll need to lock it up for the duration of the packet for amplitude sensitive demods such as QAM or OFDM. > As for the sequencing and setting up time slots, it might be easy to > be able to set up some sort of TDMA epoch editor which would > inherently have the rollover included from one epoch to the next. > This could easily be accomplished in an M4k block in the FPGA where > each address is the next coarse time in the transmit sequence. > > In other words, if the sequence were to: > * Lock PLL > * Wait 200 us > * Unmute TX > * Wait 10 us > * Ramp up Modulated TX data > > That could be a RAM with the subsequent addresses have a resolution of > 10us in ticks. The first could be a control word to lock the PLL, the > next 20 would be NOP commands, the next command Unmute TX, NOP, > TX_DATA. I see. > The only thing that might have to be considered is frequency offset > and correction of timestamps as to account for sliding timeslots in > the TDMA sequence. Do you know, off hand, what the maximum frequency > offset is for the USRP oscillator? I believe the standard oscillator is spec'd at 50 ppm. > On a side note, I suppose the AGC loop should be figured out to > calculate settling time to cover the entire range for all > daugherboards. > > >We'll provide some way for the host to set or reset the counter, but > >this really only matters in multi-board setups. In that case (on the > >upcoming USRP2), we'll provide h/w that supports coherent timing > >across multiple boards. > > U
Re: [Discuss-gnuradio] RFX400 modifications
On 2/23/07, Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote: Hi Matt, could you please detail to me the modification needed to use the following feature of the RFX400 quote: " Additionally, minor modifications to the board can move receive ports.the frequency range to anywhere from 200 MHz to 800 MHz (contact Ettus Research for details). " Surprisingly enough, while updating the Wiki, I ran into a place where Matt had described this. It can be found here: http://gnuradio.org/trac/wiki/UsrpDBoardRFX400 we could be interested in buying a couple of them in our lab in Pisa for two applications: a dvb-t transmitter and something (I'm not working on it) involving Marine VHF band. is it possible to achieve a lower frequency bound of 150MHz? thanks vincenzo Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFX400 modifications
Hi Matt, could you please detail to me the modification needed to use the following feature of the RFX400 quote: " Additionally, minor modifications to the board can move receive ports.the frequency range to anywhere from 200 MHz to 800 MHz (contact Ettus Research for details). " we could be interested in buying a couple of them in our lab in Pisa for two applications: a dvb-t transmitter and something (I'm not working on it) involving Marine VHF band. is it possible to achieve a lower frequency bound of 150MHz? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
John, You may also want to try increasing the decimation (lowering the bandwidth); this may help cut some noise. Change the -d flag to 32 or 64. -Daniel - Original Message From: Daniel Garcia <[EMAIL PROTECTED]> To: John Clark <[EMAIL PROTECTED]> Cc: GNURadio Discussion List Sent: Friday, February 23, 2007 3:38:19 PM Subject: Re: [Discuss-gnuradio] NTSC Receiver I see your using an over the air channel. I've only tested with cable tv. The simple detector probably can't deal with the noise found in that signal. I will connect an antenna to my board tonight and look in to that. If you happen to have cable (or the VHF output of a TV receiver) you can try that for now. Thanks, Daniel >TV Channel 15 should be 476 - 482, and the Video at 477.25, which >I see on my FFT display of the channel. > >John Clark. Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Have a burning question? Go to www.Answers.yahoo.com and get answers from real people who know. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
I see your using an over the air channel. I've only tested with cable tv. The simple detector probably can't deal with the noise found in that signal. I will connect an antenna to my board tonight and look in to that. If you happen to have cable (or the VHF output of a TV receiver) you can try that for now. Thanks, Daniel >TV Channel 15 should be 476 - 482, and the Video at 477.25, which >I see on my FFT display of the channel. > >John Clark. Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Deadline Friday 3/2: Open Source SDR track at [EMAIL PROTECTED] Symposium
2007 Virginia Tech Symposium on Wireless Personal Communications http://wireless.vt.edu/symposium.htm June 6-8, 2007 Special Track for Open Source Software Defined Radio. For the 16th annual Wireless Symposium, [EMAIL PROTECTED] will host a special track focused on Open Source Software Defined Radio. [EMAIL PROTECTED] invites presentations related to Open Source SDR based on projects such as; GNU Radio , High Performance Software Defined Radio (HPSDR), SDR-1000 , SCARI Open , and [EMAIL PROTECTED]'s own OSSIE . If interested, please submit a 500 word abstract by Friday, March 2, to [EMAIL PROTECTED], that describes the planned presentation. Please use "Open SDR abstract" in the subject line. Presentations should address the following subjects, and how open source software radio helped researchers achieve their goals. Presentation length is thirty minutes. Software Radio Frameworks - GNU Radio - Software Communication Architecture Applications of Open Source SDR - Modulation/Demodulation - MANET's - Spectrum Access - Cognitive and Adaptive Radios - Networking Benefits of Open Source SDR Hardware for Open Source SDR Basically, if you have benefited from Open Source SDR, tell us about it! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
Daniel Garcia schrieb: can you send me the output from the console? and the command line you used. -Daniel This is what I get: ./usrp_tv_rcv_testingNTSC.py -n -f 477.25 -d 26 Using RX d'board A: TV Rx Rev 3 width:156 height:262 d_output_buffer_size:40872 LEADING_EDGE_DETECTION_THRESHOLD: 0.9 TRAILING_EDGE_DETECTION_THRESHOLD: 0.3 SDL screen_mode 32 bits-per-pixel SDL overlay_mode 842094169 FYI: No Powermate or Contour Knob found TV Channel 15 should be 476 - 482, and the Video at 477.25, which I see on my FFT display of the channel. John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
Trond Danielsen wrote: > Sorry for not expressing myself clearly. This is what I was thinking of: > > d_length = (int)(1ULL << degree)-1; That's a 64-bit unsigned long long constant equal to 1. I need that to be able to shift left by 32; if it were just the 1UL it would fall off the end. > Sorry to bother you. No, you inadvertently found a bug in my code anyway, so thanks. After going through the work of creating a 64-bit value, I was immediately casting it to 'int'. It's been fixed. The joys of having ones "intermediate work product" on display for the world :-) -- 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] segmentation error and fftw make error
Sorry for the confusion. My program jammer.py got Segmentation error and stopped. Now I am trying to rebuild fftw_3.0.1 (since from previous list in this group, some one suggested to rebuild fftw without --enable-sse), it cannot pass through the make :( Thank you, Xin On Fri, 23 Feb 2007, Eric Blossom wrote: > On Fri, Feb 23, 2007 at 03:22:28PM -0500, Liu Xin wrote: > > Dear Eric: > > > > Thank you for your response. > > My memory size is 515936 kB and the swap size is 835340 kB. > > > > The program is used to generate some noise to 802.11 communication. > > I am generating different signals with a certain pulse width (e.g. 20us), > > and fixed idle width (e.g. 1000us). The program runs for some time > > (minutes or one hour) --> screen outputs: Segmentation fault -> program > > stops. > > > > Now I am rebuilding fftw_3.0.1 on Ubuntu, still get errors when doing the > > make :( > > > > Thanks, > > Xin > > > > I'm confused. Is the compiler dying compiling fftw, or is your > program which uses fftw dying? > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
2007/2/23, Johnathan Corgan <[EMAIL PROTECTED]>:
Trond Danielsen wrote:
> Is this correct?
> - - - - - - - - -
> gr_glfsr_source_b::gr_glfsr_source_b(int degree, bool repeat, int
> mask, int seed)
> : gr_sync_block ("glfsr_source_b",
> gr_make_io_signature (0, 0, 0),
> gr_make_io_signature (1, 1, sizeof(unsigned char))),
>d_repeat(repeat),
>d_index(0)
> {
> if (degree < 1 || degree > 32)
>throw std::runtime_error("gr_glfsr_source_b: degree must be
> between 1 and 32 inclusive");
> d_length = (int)(1ULL << degree)-1;
>^
> - - - - -
Not sure I understand what you're questioning, the formatting is messed
up. But now that I stare at it, I think I misplaced a parenthesis; the
-1 should be inside.
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com
Sorry for not expressing myself clearly. This is what I was thinking of:
d_length = (int)(1ULL << degree)-1;
A quick google search enlightened me, I have never seen the 1ULL
decimal-constant integer-suffix before. Sorry to bother you.
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Preliminary In-band signaling
On 2/21/07, Eric Blossom <[EMAIL PROTECTED]> wrote: I'm planning on adding a section talking about the control channel. I expect the control channel payload to be composed of a sequence of ops + args that is reasonably easy to parse in the FPGA. Control channel ops will honor the timestamp too. One of the ops will be WRITE_REGISTER. Others will include the rest of the stuff that can't be squeezed into WRITE_REGISTER such as I2C_READ/WRITE, SPI_READ/WRITE Very nice. Are you thinking more of like a special machine language that gets put together based on daugherboards PLL locking times and sequencing of the bring up / tear down of the RF section? Knowing the sequencing times for all the daughterboards and how quickly we can switch between TX/RX and change frequencies is definitely essential to calculating guard times. Are these documented anywhere, or does it require going through the datasheets and picking Matt's brain? One of the use cases we want to be able to satisfy is TDMA waveforms. In those cases you need to be able to hit a transmit slot that is defined in relationship to some other receive slot. Think about how cellular mobiles work. The timestamp will be a free running counter that is logically adjacent to the A/D and D/A i/o pins. On receive, the value stuck into the packet is the value of the counter that corresponds to the first sample in the payload. On Tx, the timestamp corresponds to the tick that the first sample of the payload will be sent to the DACS. Since all real processing occurs inside the host computer, how do we know how many samples we need to send back to the host during one of these RX sessions? Should the duration be set in terms of samples or in terms of start time / stop time? The way I've seen it done in the past is to use an acquisition matched filter and look for the correlation peak, but with all the different modulation types available, it might not be feasible to run them all in the same FPGA load. As for the sequencing and setting up time slots, it might be easy to be able to set up some sort of TDMA epoch editor which would inherently have the rollover included from one epoch to the next. This could easily be accomplished in an M4k block in the FPGA where each address is the next coarse time in the transmit sequence. In other words, if the sequence were to: * Lock PLL * Wait 200 us * Unmute TX * Wait 10 us * Ramp up Modulated TX data That could be a RAM with the subsequent addresses have a resolution of 10us in ticks. The first could be a control word to lock the PLL, the next 20 would be NOP commands, the next command Unmute TX, NOP, TX_DATA. The only thing that might have to be considered is frequency offset and correction of timestamps as to account for sliding timeslots in the TDMA sequence. Do you know, off hand, what the maximum frequency offset is for the USRP oscillator? On a side note, I suppose the AGC loop should be figured out to calculate settling time to cover the entire range for all daugherboards. We'll provide some way for the host to set or reset the counter, but this really only matters in multi-board setups. In that case (on the upcoming USRP2), we'll provide h/w that supports coherent timing across multiple boards. USRP2? Is this a major upgrade, or just a slight one? Will there be a change in FPGAs to one with embedded multipliers? I'm too used to these Cyclone II/III FPGA's with loads of RAM and loads of multipliers. No problem. I'm planning on doing more work on the description this evening or tomorrow morning. Let me know if you think I'm missing something, or if I'm designing something that's hard to implement, or if you think you've got a better way to approach the problem. I look forward to hearing your comments on my comments. Thanks for all your efforts on the Wiki! No problem - I just hope the information I am reading is actually accurate. I am trying my best to figure out everything you guys are doing as I hope to try to bring our RF channel simulator software over to the GNU Radio framework for work. Our current C model is a pretty accurate model but can be considered a coding mess. Eric Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Preliminary In-band signaling
On Wed, Feb 21, 2007 at 11:11:43PM -0500, Brian Padalino wrote: > Eric, > > I realize what you have checked in is strictly very preliminary (hence > keeping this off-list), but I was curious if you had plans to add > basically every one of the FPGA register settings that might get set > for each burst transmission. I'm planning on adding a section talking about the control channel. I expect the control channel payload to be composed of a sequence of ops + args that is reasonably easy to parse in the FPGA. Control channel ops will honor the timestamp too. One of the ops will be WRITE_REGISTER. Others will include the rest of the stuff that can't be squeezed into WRITE_REGISTER such as I2C_READ/WRITE, SPI_READ/WRITE > I was also curious in regards to the timestamp field and > synchronization. Since the FPGA has no sense of time other than clock > ticks, what kind of reference does that timestamp really give? One of the use cases we want to be able to satisfy is TDMA waveforms. In those cases you need to be able to hit a transmit slot that is defined in relationship to some other receive slot. Think about how cellular mobiles work. The timestamp will be a free running counter that is logically adjacent to the A/D and D/A i/o pins. On receive, the value stuck into the packet is the value of the counter that corresponds to the first sample in the payload. On Tx, the timestamp corresponds to the tick that the first sample of the payload will be sent to the DACS. We'll provide some way for the host to set or reset the counter, but this really only matters in multi-board setups. In that case (on the upcoming USRP2), we'll provide h/w that supports coherent timing across multiple boards. We'll also have to work out some way for the host to estimate round-trip latency looped-back through the Tx/Rx path. > Sorry if this is just too soon. No problem. I'm planning on doing more work on the description this evening or tomorrow morning. Let me know if you think I'm missing something, or if I'm designing something that's hard to implement, or if you think you've got a better way to approach the problem. Thanks for all your efforts on the Wiki! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [EMAIL PROTECTED]: Preliminary In-band signaling]
Moving off-list conversation back to list... --- Begin Message --- Eric, I realize what you have checked in is strictly very preliminary (hence keeping this off-list), but I was curious if you had plans to add basically every one of the FPGA register settings that might get set for each burst transmission. I was also curious in regards to the timestamp field and synchronization. Since the FPGA has no sense of time other than clock ticks, what kind of reference does that timestamp really give? Sorry if this is just too soon. Thanks, Brian --- End Message --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
On Fri, Feb 23, 2007 at 03:22:28PM -0500, Liu Xin wrote: > Dear Eric: > > Thank you for your response. > My memory size is 515936 kB and the swap size is 835340 kB. > > The program is used to generate some noise to 802.11 communication. > I am generating different signals with a certain pulse width (e.g. 20us), > and fixed idle width (e.g. 1000us). The program runs for some time > (minutes or one hour) --> screen outputs: Segmentation fault -> program > stops. > > Now I am rebuilding fftw_3.0.1 on Ubuntu, still get errors when doing the > make :( > > Thanks, > Xin > I'm confused. Is the compiler dying compiling fftw, or is your program which uses fftw dying? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
Thank you. I run the make for fftw multiple times. Each it stops at different files, all because of "/bin/sh: line xxx Segmentation Fault". Best, Xin On Fri, 23 Feb 2007, Brian Padalino wrote: > On 2/23/07, Liu Xin <[EMAIL PROTECTED]> wrote: > > Now I am rebuilding fftw_3.0.1 on Ubuntu, still get errors when doing the > > make :( > > I've seen on my cygwin system where fftw would get a lot of "Resource > busy" lines just before make would error out. At times, I've even had > to run make up to 10 times in a row to get it to compile fully. > > Have you tried just running make multiple times in a row? > > Brian > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
Eric Blossom wrote: > Looks like this needs some QA code. > > The original version probably didn't _really_ generate an m-sequence ;) The QA code is there; it actually checks for the proper auto-correlation properties for all sequences of degree 1 through 11, which implies the length calculation is correct also. Since the auto-correlation is done naively and in Python, it's dog slow, and anything longer than 2047 starts to take many seconds to complete. I'll add some QA code that only instantiates the block and asks it what length it thinks it's going to have. The bug Trond identified would only have created a problem with a sequence of degree 32. -- 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] segmentation error and fftw make error
On 2/23/07, Liu Xin <[EMAIL PROTECTED]> wrote: Now I am rebuilding fftw_3.0.1 on Ubuntu, still get errors when doing the make :( I've seen on my cygwin system where fftw would get a lot of "Resource busy" lines just before make would error out. At times, I've even had to run make up to 10 times in a row to get it to compile fully. Have you tried just running make multiple times in a row? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
On Fri, Feb 23, 2007 at 12:10:17PM -0800, Johnathan Corgan wrote:
> Trond Danielsen wrote:
> > Is this correct?
> > - - - - - - - - -
> > gr_glfsr_source_b::gr_glfsr_source_b(int degree, bool repeat, int
> > mask, int seed)
> > : gr_sync_block ("glfsr_source_b",
> > gr_make_io_signature (0, 0, 0),
> > gr_make_io_signature (1, 1, sizeof(unsigned char))),
> >d_repeat(repeat),
> >d_index(0)
> > {
> > if (degree < 1 || degree > 32)
> >throw std::runtime_error("gr_glfsr_source_b: degree must be
> > between 1 and 32 inclusive");
> > d_length = (int)(1ULL << degree)-1;
> >^
> > - - - - -
>
> Not sure I understand what you're questioning, the formatting is messed
> up. But now that I stare at it, I think I misplaced a parenthesis; the
> -1 should be inside.
Looks like this needs some QA code.
The original version probably didn't _really_ generate an m-sequence ;)
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
Dear Eric: Thank you for your response. My memory size is 515936 kB and the swap size is 835340 kB. The program is used to generate some noise to 802.11 communication. I am generating different signals with a certain pulse width (e.g. 20us), and fixed idle width (e.g. 1000us). The program runs for some time (minutes or one hour) --> screen outputs: Segmentation fault -> program stops. Now I am rebuilding fftw_3.0.1 on Ubuntu, still get errors when doing the make :( Thanks, Xin On Fri, 23 Feb 2007, Eric Blossom wrote: > On Fri, Feb 23, 2007 at 01:45:58PM -0500, Liu Xin wrote: > > Hello, All: > > > > I am using USRP for my project. > > I got fragmentation fault when running the python code. Googleing online I > > found one soultion might be to build fftw without --enable-sse. > > > > Therefore I download fftw-3.1.2: > > ./configure -prefix=$home --enable-single --enable-shared > > make > > The make fails [rank0.lo] (I made clean and make multiple times, each > > time it fails at different files, but all in rdft/) > > > > I am using Ubuntu build 2.6.15-23-386 and Athlon XP2200+. Is there anyone > > who can help with this? > > > > Also I use gdb to debug the program as suggested in the mailing list > > before. However each time the gdb attach the pid the my python program > > stops running until the I quit the gdb. > > Can anyone help with debugging this Segmentation Fault Problem? > > > > Thanks a lot for your input, > > Xin > > How does it fail? > > The compiler could be running out of memory. > How much RAM and swap does your machine have? > > Eric > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
Trond Danielsen wrote:
> Is this correct?
> - - - - - - - - -
> gr_glfsr_source_b::gr_glfsr_source_b(int degree, bool repeat, int
> mask, int seed)
> : gr_sync_block ("glfsr_source_b",
> gr_make_io_signature (0, 0, 0),
> gr_make_io_signature (1, 1, sizeof(unsigned char))),
>d_repeat(repeat),
>d_index(0)
> {
> if (degree < 1 || degree > 32)
>throw std::runtime_error("gr_glfsr_source_b: degree must be
> between 1 and 32 inclusive");
> d_length = (int)(1ULL << degree)-1;
>^
> - - - - -
Not sure I understand what you're questioning, the formatting is messed
up. But now that I stare at it, I think I misplaced a parenthesis; the
-1 should be inside.
--
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] Galois-form LFSR now in trunk (r4613)
2007/2/23, Johnathan Corgan <[EMAIL PROTECTED]>:
An implementation of a Galois-form LFSR pseudo-random sequence generator
is now in the trunk as of r4613.
gr.glfsr_source_b(degree, repeat=True, mask=0, seed=1)
degree: The shift register length, 1-32 inclusive
repeat: whether to repeat once sequence completes (True, False)
defaults to True
mask: The LFSR polynomial mask to use. If not supplied, a suitable
one is chosen based on the degree specified.
seed: The initial shift register value. This should not be zero, and
if not supplied, defaults to 1
The block outputs a series of bytes equal to 0 or 1, forming a maximal
length sequence (m-sequence) of length 2^degree-1. The output of this
block can be further processed by other blocks to map it to other
values, pack it into bytes, etc.
The simplest use is to specify only the degree:
src = gr.glfsr_source_b(32)
This will generate a 2^32-1 length m-sequence and repeat until the the
application is exited.
M-sequences are useful as digital noise sources, as they contain energy
at every discrete frequency interval up to the Nyquist frequency, for a
given sampling rate and sequence length.
--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com
Is this correct?
- - - - - - - - -
gr_glfsr_source_b::gr_glfsr_source_b(int degree, bool repeat, int
mask, int seed)
: gr_sync_block ("glfsr_source_b",
gr_make_io_signature (0, 0, 0),
gr_make_io_signature (1, 1, sizeof(unsigned char))),
d_repeat(repeat),
d_index(0)
{
if (degree < 1 || degree > 32)
throw std::runtime_error("gr_glfsr_source_b: degree must be
between 1 and 32 inclusive");
d_length = (int)(1ULL << degree)-1;
^
- - - - -
--
Trond Danielsen
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation error and fftw make error
On Fri, Feb 23, 2007 at 01:45:58PM -0500, Liu Xin wrote: > Hello, All: > > I am using USRP for my project. > I got fragmentation fault when running the python code. Googleing online I > found one soultion might be to build fftw without --enable-sse. > > Therefore I download fftw-3.1.2: > ./configure -prefix=$home --enable-single --enable-shared > make > The make fails [rank0.lo] (I made clean and make multiple times, each > time it fails at different files, but all in rdft/) > > I am using Ubuntu build 2.6.15-23-386 and Athlon XP2200+. Is there anyone > who can help with this? > > Also I use gdb to debug the program as suggested in the mailing list > before. However each time the gdb attach the pid the my python program > stops running until the I quit the gdb. > Can anyone help with debugging this Segmentation Fault Problem? > > Thanks a lot for your input, > Xin How does it fail? The compiler could be running out of memory. How much RAM and swap does your machine have? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
can you send me the output from the console? and the command line you used. -Daniel - Original Message From: John Clark <[EMAIL PROTECTED]> To: Daniel Garcia <[EMAIL PROTECTED]> Cc: GNURadio Discussion List Sent: Friday, February 23, 2007 1:16:55 PM Subject: Re: [Discuss-gnuradio] NTSC Receiver Daniel Garcia schrieb: > Hello, > > I've completed a prototype for an NTSC decoder blockset for gnu radio. > It's not very sophisticated but it lets you see video on the screen > using gr-video-sdl. My development platform is Ubuntu 6.10 x86. All I got was a black window. I know there is an analog TV station on the channel because my current work is using the USRP + fft to monitor the spectrum. When I display the FFT there is clearly a analog TV chanel with a 'classic' signature... i.e. clearly deliniated peaks for all signal elements, Video, Chomanence, and Audio. What could be going wrong with my setup. John Clark. Never Miss an Email Stay connected with Yahoo! Mail on your mobile. Get started! http://mobile.yahoo.com/services?promote=mail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] remote gnuradio session
Achilleas Anastasopoulos wrote: > but I have not been able to "redirect" > audio to my local computer (eg, usrp_wfm_rcv.py does not work). > > Any ideas how to fix this? The X remote protocol doesn't ship sound. It's not trivial, but there's a solution: http://www.radscan.com/nas.html Your distribution may have this already packaged. I used this several years ago but don't recall the details on how it is set up or how well it worked. -- 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] convolutional code + viterbi working
Hi Achilleas,
yes.. I had got a bit confused about how to use these blocks...
is this correct instead?
Nfft=2048
file_source_bytewise=gr.file_source(gr.sizeof_char,
"/mnt/root/gnuradio_datastreams/1.MPG")
file_chunker=gr.packed_to_unpacked_bb(1,gr.GR_LSB_FIRST) #second
argument is endianness
f=trellis.fsm("/root/MAIN/soft/gnuradio/gr-mystuff/finite_state_machine")
convolutional_encoder = trellis.encoder_bb(f,0)
self.connect(file_source_bytewise,file_chunker,convolutional_encoder,symbol_mapper)
self.connect(symbol_mapper,series_to_parallel,inverse_fft,parallel_to_series,gain,self.u)
today I've been showing the code to prof. Luise, and he was suggesting
that it is a bit too difficult to achieve the convolutional encoder
needed in DVB-T by specifying a finite state machine, as it would have
too many states and transitions to figure out..
is it possible to specify the encoder using the associated polynomial?
and this is how I connected the viterbi decoder:
metrics =
trellis.metrics_c(f.O(),1,constellation,trellis.TRELLIS_EUCLIDEAN)
viterbi_decoder = trellis.viterbi_b(f,K,0,-1)
file_repacker=gr.unpacked_to_packed_bb(1,gr.GR_LSB_FIRST)
file_sink=gr.file_sink(gr.sizeof_char,
"/mnt/root/gnuradio_datastreams/2")
self.connect(gain,series_to_parallel_2,direct_fft,parallel_to_series_2,metrics,viterbi_decoder,file_repacker,file_sink)
this stuff seems to work as it is just giving me back the original file
as it happened with the qpsk+ofdm-only script.
best regards
and really realy thanks
vincenzo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NTSC Receiver
Daniel Garcia schrieb: Hello, I've completed a prototype for an NTSC decoder blockset for gnu radio. It's not very sophisticated but it lets you see video on the screen using gr-video-sdl. My development platform is Ubuntu 6.10 x86. All I got was a black window. I know there is an analog TV station on the channel because my current work is using the USRP + fft to monitor the spectrum. When I display the FFT there is clearly a analog TV chanel with a 'classic' signature... i.e. clearly deliniated peaks for all signal elements, Video, Chomanence, and Audio. What could be going wrong with my setup. John Clark. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] remote gnuradio session
Maybe this is a bit off topic (I apologize): I want to do a gnuradio demo using a laptop and connecting remotely to my desktop (where gnuradio is installed and the USRP is connected). Using ssh -Y I can get all windows appear etc (eg, usrp_fft.py works fine), but I have not been able to "redirect" audio to my local computer (eg, usrp_wfm_rcv.py does not work). Any ideas how to fix this? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Galois-form LFSR now in trunk (r4613)
An implementation of a Galois-form LFSR pseudo-random sequence generator is now in the trunk as of r4613. gr.glfsr_source_b(degree, repeat=True, mask=0, seed=1) degree: The shift register length, 1-32 inclusive repeat: whether to repeat once sequence completes (True, False) defaults to True mask: The LFSR polynomial mask to use. If not supplied, a suitable one is chosen based on the degree specified. seed: The initial shift register value. This should not be zero, and if not supplied, defaults to 1 The block outputs a series of bytes equal to 0 or 1, forming a maximal length sequence (m-sequence) of length 2^degree-1. The output of this block can be further processed by other blocks to map it to other values, pack it into bytes, etc. The simplest use is to specify only the degree: src = gr.glfsr_source_b(32) This will generate a 2^32-1 length m-sequence and repeat until the the application is exited. M-sequences are useful as digital noise sources, as they contain energy at every discrete frequency interval up to the Nyquist frequency, for a given sampling rate and sequence length. -- 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] segmentation error and fftw make error
Hello, All: I am using USRP for my project. I got fragmentation fault when running the python code. Googleing online I found one soultion might be to build fftw without --enable-sse. Therefore I download fftw-3.1.2: ./configure -prefix=$home --enable-single --enable-shared make The make fails [rank0.lo] (I made clean and make multiple times, each time it fails at different files, but all in rdft/) I am using Ubuntu build 2.6.15-23-386 and Athlon XP2200+. Is there anyone who can help with this? Also I use gdb to debug the program as suggested in the mailing list before. However each time the gdb attach the pid the my python program stops running until the I quit the gdb. Can anyone help with debugging this Segmentation Fault Problem? Thanks a lot for your input, Xin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NTSC Receiver
Hello, I've completed a prototype for an NTSC decoder blockset for gnu radio. It's not very sophisticated but it lets you see video on the screen using gr-video-sdl. My development platform is Ubuntu 6.10 x86. The signal starts out by using a custom AGC which simply scales the samples by dividing all samples by a local maximum. This puts most of the samples in the 0 to 1.0 range. Then the frame detector uses a simple threshold method to determine when pulses begin and end. The length of time between pulses is used to determine the type of pulse. A simple state machine keeps the output buffered correctly so the screen doesn't get out of whack. Current features: * Black/White reception (vertical and horizontal sync) * Contrast/Brightness adjustment (still a little buggy) Planned features: * automatic black level * color * stereo audio * better sync detection * documentation Any feedback would be appreciated. http://www.danielgarcia.info/thesis/ http://www.danielgarcia.info/thesis/files/gr-video-analog.tgz -Daniel Do you Yahoo!? Everyone is raving about the all-new Yahoo! Mail beta. http://new.mail.yahoo.com___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ping example
Hi all anybody knows something about PING example in USRP architecture, got by OFDM modulation? If yes, could you drive me to that? 10x a lot Roberto ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] convolutional code + viterbi working
On Fri, Feb 23, 2007 at 11:31:22AM -0500, Achilleas Anastasopoulos wrote: > Eric, > > I have developed a generic interleaver class and int/deint blocks in > gr-trellis. They can handle any kind of interleaving (block, random, > convolutional, file specified permutations, etc) and also interleave > chunks of data at a time. > I am sure the interleave block in gr-astsc can be > wrapped in this one as well. > > I was wondering if a more appropriate location for this blocks is indeed > gnuradio-core. > > Achilleas I think gr-trellis a fine place for it. gr-atsc is still "a bit in the woods", since it still needs some work... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] convolutional code + viterbi working
Eric, I have developed a generic interleaver class and int/deint blocks in gr-trellis. They can handle any kind of interleaving (block, random, convolutional, file specified permutations, etc) and also interleave chunks of data at a time. I am sure the interleave block in gr-astsc can be wrapped in this one as well. I was wondering if a more appropriate location for this blocks is indeed gnuradio-core. Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Re: transmitting two independent Signals
On Fri, Feb 23, 2007 at 10:17:21AM +0100, anmar wrote:
> Eric Blossom wrote:
> > On Wed, Feb 21, 2007 at 11:11:17AM +0100, anmar wrote:
> >> > stream of complexes. (Yes, the interface is a bit strange and ought
> >> > fg.connect(interleaver, u)
> >> > That's right. If you're using a single Basic Tx daughterboard, and
> >> > you want independent real output out the I and Q, that'll take a fair
> >> > amount of hacking. Using two daughterboards is going to be much, much
> >> > easier ;)
> >>
> >> ok that is to bad, but do you know any one how tried to do this
> >
> > No.
> >
> >> or do you know where to begin hacking :)?
> >
> > Getting this right requires understanding how the host, the FPGA code
> > and the AD9862 all interact. If you've been following Brian's
> > questions about the FPGA over the past few days, you're on the right
> > track. Note also, that if you send two real signals to the AD9862 you
> > lose the use of the digital up converter ("Fine Modulator") in the
> > AD9862. Assuming you need a DUC, you'll have to reimplement this
> > functionality in the FPGA. [In "two independent real signal mode" you
> > only have Block C "Interpolator" and Block B "Coarse Modulator"
> > available.]
> >
> >> We just want to see if it can be done with the time that we have, or
> >> just go and use two Tx daugterboards.
> >
> > Any particular reason you don't want to use two Tx daughterboards?
> > If you use two Tx daughterboards, you could have your independent-signal
> > transmitter up and working in 30 minutes.
> >
> > Eric
>
> hi Eric,
> can you post an example that transmits to tx signales from two tx
> boards?
> we have trying the code that you posted earlier, but it won't work. we
> have tyied the fm_tx_2_daugtherboards.py that worked well, but is pit
> comcplicated to understand and when modifying it don't work any more.
>
> thanks in advance
> anmar and wim
>
The fm_tx_2_daughterboards.py code is about the simplest code that
transmits on two daughterboards. What part of it do you have
questions about? Do you understand how to transmit on a single
daughterboard?
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The shortest pulse length
The shortest pulse duration which you can transmit is going to be limited by: a) the sampling rate of the converters b) the USB interface c) the bandwidth of IF/RF components I don't know your exact setup. So, let me provide an example of what I'm doing: I transmit and receive in an always-on fashion using a single USRP in 4 Byte/sample mode (2 for real, 2 for complex) Therefore, for each sample that must be transmitted and received, 8 bytes will traverse the USB (4 for Tx, 4 for Rx). The USRP is limited to 32 MB/s across the USB. Therefore, I can only handle signals 4 MHz wide. Because the USRP does complex sampling, 4 MHz becomes the maximum sampling rate I can use to generate my signal at baseband. (This signal will be interpolated to 128 MHz on the USRP.) Because the fastest I can generate samples is 4 MHz, the smallest interval between samples is 1/4e6 = 250 ns. That is (theoretically) the shortest pulse width. Now, anytime you signal using one sample you will suffer more system distortion than if you used, say, two. This is because the converters will act as a really wide low-pass filter. However, with that said, I am able to do it. I believe the minimum interpolation factor is 16. Therefore, in a transmit-only mode, I believe the minimum pulse width would be 1/8MHz = 125 ns. I haven't had coffee yet to day. So, caveat emptor on these calculations, but I hope they help. -Lee On Fri, 2007-02-23 at 06:08 -0800, seph 004 wrote: > Hi > > Does anyone know what the shortest duration pulse is which the USRP > can transmit? I've tried to test it by using gr.head to limit the > number of samples to produce a short waveform, but I can't catch > anything appearing at the output. Is there a simple test I could do to > check? > > Regards > > Lance > > > > __ > TV dinner still cooling? > Check out "Tonight's Picks" on Yahoo! TV. > ___ > 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] The shortest pulse length
Hi Does anyone know what the shortest duration pulse is which the USRP can transmit? I've tried to test it by using gr.head to limit the number of samples to produce a short waveform, but I can't catch anything appearing at the output. Is there a simple test I could do to check? Regards Lance Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ARRL seeking comments on new digital HF radio protocol
http://www.arrl.org/news/stories/2007/02/22/102/?nc=1 ARRL Seeks Comments on New HF Digital Protocol NEWINGTON, CT, Feb 22, 2007 -- The ARRL is seeking comments from amateurs concerning development of an open-source (non-proprietary) data communications protocol suitable for use by radio amateurs over high-frequency (HF) fading paths. This is not a Request for Proposals (RFP). An RFP may or not be forthcoming depending on evaluation of the information received. Specifically, the League is asking for comments and information on the following issues: * Access Method: Is Orthogonal Frequency-Division Multiplexing (OFDM) the best candidate technology, or should other competitive technologies be considered? * Data Rate and Bandwidth: What data rates/throughputs are achievable at various bandwidths up to 3 kHz bandwidth? * Adaptivity: What adaptive features should be considered, such as automatic adjustment of transmitter power, modulation waveform and coding, in order to maximize throughput and efficiency in two-way contacts? * Robustness: What is achievable for reliable operation at power levels typical in the Amateur Radio Service and low signal/noise and interference ratios? * Error control: What are the appropriate applications of error control suitable for HF channels? For example, how should Repeat reQuest (ARQ) and Forward Error Control (FEC) be applied to two-way contacts and one-to-many (roundtable and bulletin) transmissions? * Activity Detection: What is an effective method of determining whether a frequency is busy prior to transmission? * Operating System: What operating systems (such as Windows or Linux) are appropriate for Amateur Radio use with this protocol? * Hardware: What practical and affordable hardware platforms are suitable for amateur stations? Consider the use of personal computers with or without sound cards. Provide any information about the need for an additional "box" if needed. Please provide the following with your response: (1) name of respondent, (2) respondent's contact information, (3) related experience, and (4) type of respondent: (individual, partnership, corporation or group). Do not include proprietary information as part of your response. Post, fax or e-mail your response by 1900 UTC, May 15, 2007, to ARRL Chief Technology Officer Paul Rinaldo, W4RI, 3545 Chain Bridge Rd -- Suite 209, Fairfax, VA 22030; Fax: 703-934-2079. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Re: transmitting two independent Signals
Eric Blossom wrote:
> On Wed, Feb 21, 2007 at 11:11:17AM +0100, anmar wrote:
>> > stream of complexes. (Yes, the interface is a bit strange and ought
>> > fg.connect(interleaver, u)
>> > That's right. If you're using a single Basic Tx daughterboard, and
>> > you want independent real output out the I and Q, that'll take a fair
>> > amount of hacking. Using two daughterboards is going to be much, much
>> > easier ;)
>>
>> ok that is to bad, but do you know any one how tried to do this
>
> No.
>
>> or do you know where to begin hacking :)?
>
> Getting this right requires understanding how the host, the FPGA code
> and the AD9862 all interact. If you've been following Brian's
> questions about the FPGA over the past few days, you're on the right
> track. Note also, that if you send two real signals to the AD9862 you
> lose the use of the digital up converter ("Fine Modulator") in the
> AD9862. Assuming you need a DUC, you'll have to reimplement this
> functionality in the FPGA. [In "two independent real signal mode" you
> only have Block C "Interpolator" and Block B "Coarse Modulator"
> available.]
>
>> We just want to see if it can be done with the time that we have, or
>> just go and use two Tx daugterboards.
>
> Any particular reason you don't want to use two Tx daughterboards?
> If you use two Tx daughterboards, you could have your independent-signal
> transmitter up and working in 30 minutes.
>
> Eric
hi Eric,
can you post an example that transmits to tx signales from two tx
boards?
we have trying the code that you posted earlier, but it won't work. we
have tyied the fm_tx_2_daugtherboards.py that worked well, but is pit
comcplicated to understand and when modifying it don't work any more.
thanks in advance
anmar and wim
--
Posted via http://www.ruby-forum.com/.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
