Re: [Discuss-gnuradio] Re: USRP2 expansion interface
[EMAIL PROTECTED] wrote: Can you also provide details concerning the debug port? The debug port is a standard Mictor connector which is often used with logic analyzers from Agilent and Tektronix. It has 2 clock pins and 32 data pins. All 34 of those are directly connected to the FPGA, so you can do whatever you want with them. If you plug in a BasicRX or LFRX and a BasicTX or LFTX, you will have an additional 32 bits of IO and 2 clocks which can also be used for debugging. This gives a total of 64 bits of debug. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: USRP2 expansion interface
[EMAIL PROTECTED] wrote: Hi, I'm Kevin Bobrowski. I am currently doing research with GNUradio, USRP, and soon the USRP2 at Worcester Polytechnic Institute. A while back, I noticed that there was an expansion port. I and along with others in my lab would like to interface to this port to connect the USRP2 to a Virtex 5 SXT eval board. I am looking for any documentation concerning this port, especially how it is tied into the the FPGA, if that is the case. Can you also provide details concerning the debug port? The expansion port is pretty straightforward. It uses a serial-attached SCSI (mini-SAS) cable. The cable has 4 lanes. Each lane consists of 1 differential pair input and 1 differential pair output. All lanes are AC (capacitor) coupled. The 4 lanes are allocated as follows: 1 - High-speed SERDES, 2 gbps 8B10B encoded. This interface is handled by a TLK2701 from TI, and it connects to the FPGA. You should be able to connect this interface to the RocketIO GTP/GTX transceivers on the virtex 5. Also, see the usrp2/fpga/serdes directory in the SVN repository to see how we handle the interface and protocol, framing, and flow control. 2 - 10 MHz clock reference 3 - Digital IO, connected directly to LVDS IOs on the FPGA. We currently have this set up to do time syncing, but you can do whatever you like with it. 4 - Unused Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 1 PPS input for USRP2
On Sat, Sep 13, 2008 at 03:05:18AM +0300, Juha Vierinen wrote: > > Samples can be time stamped, and that time can be calibrated to the 1 PPS > > signal. In the most general case, that 1 PPS input just goes directly to > > the FPGA, so internally you can do whatever you want with it. > > Is there a standard way to get timestamps on samples, or does this > require verilog programming? > > juha There's a timestamp associated with each frame of samples. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 1 PPS input for USRP2
> Samples can be time stamped, and that time can be calibrated to the 1 PPS > signal. In the most general case, that 1 PPS input just goes directly to > the FPGA, so internally you can do whatever you want with it. Is there a standard way to get timestamps on samples, or does this require verilog programming? juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Frequency Step
On Fri, Sep 12, 2008 at 05:38:02PM -0600, Gnu Radio Explorer wrote: > Hi, > > I was going through user manual at > http://rapidshare.com/files/72169239/Simple-Gnuradio-User-Manual-v1.0.pdf > > In this document I see something called "Frequency Step". For example, Page# > 183 lists flex_2400_tx has a min freq, max freq and freq step of 2300 MHz, > 2900 MHz, and 4 MHz respectively. What does "Frequency Step" actually mean? > > Thanks. For most purposes it means nothing. Tuning is a two step process. First the front end is tuned, then the DDC is used to get the signal where you want. In your case, the front end has a step size of 4MHz, but the library knows that and adjusts the DDC to give you the frequency that you ask for. I believe there's a write up in the FAQ on tuning. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Frequency Step
Hi, I was going through user manual at http://rapidshare.com/files/72169239/Simple-Gnuradio-User-Manual-v1.0.pdf In this document I see something called "Frequency Step". For example, Page# 183 lists flex_2400_tx has a min freq, max freq and freq step of 2300 MHz, 2900 MHz, and 4 MHz respectively. What does "Frequency Step" actually mean? Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
Dustin wrote: I have only some experience with gnuradio...how hard was it to get your local copy of BBN 80211b to work? Were the only changes in regard to hier_block2 or were their other namespace changes you had to make? Thanks for your help, -Dustin For the BBN code I believe the main changes were: first change all the hier_block to hier_block2, then you have dig a little bit into the internal flow graph code and figure out what the inputs and outputs are, as you need to set the io signature (http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplications helps - about half way down you can find the instructions on creating a hierarchical block). The flowgraph code then gets connected a bit differently, as you connect from self (input) to the internal blocks back to self (output). Unfortunately I've been pretty bad about keeping track of my changes, so I need to reorganize a bit before I could just send you a nice patch to apply, but the main changes are in bbn_80211b.py, bbn_80211b_pkt.py, and either bbn_80211b_rx.py or bbn_80211b_tap.py (depending on how you want to look at the traffic - or both). In other words it's the code in the gr-bbn/src/examples directory - nothing in the src/bbn directory needs changing. Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
I have only some experience with gnuradio...how hard was it to get your local copy of BBN 80211b to work? Were the only changes in regard to hier_block2 or were their other namespace changes you had to make? Thanks for your help, -Dustin On Fri, 2008-09-12 at 16:36 -0500, Douglas Geiger wrote: > Dustin wrote: > > The latest trunk doesn't include hier_block; instead, it uses > > hier_block2 exclusively. This causes errors with BBN 80211b. I believe > > there are several other changes as well, but I'm looking for a list. > > > > -Dustin > > > > > > > > Right - I had forgotten about those changes. I have made my local copy > of the 80211b code work with the hier_block2. I have on my list of > things to do to make sure I can publish these changes so other folks can > make it work with the latest gnuradio code. Sounds like I now have a > good reason to get on top of that task (along with pushing out my local > updates to the multi_usrp code to work with hier_block2 as well). > Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] updated BBN 80211 code?
Dustin wrote: The latest trunk doesn't include hier_block; instead, it uses hier_block2 exclusively. This causes errors with BBN 80211b. I believe there are several other changes as well, but I'm looking for a list. -Dustin Right - I had forgotten about those changes. I have made my local copy of the 80211b code work with the hier_block2. I have on my list of things to do to make sure I can publish these changes so other folks can make it work with the latest gnuradio code. Sounds like I now have a good reason to get on top of that task (along with pushing out my local updates to the multi_usrp code to work with hier_block2 as well). Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 1 PPS input for USRP2
subodh chiwate wrote: Hi, I just saw the specifications for USRP2. I wanted to know the use of the 1 PPS and 10 MHz inputs. These are standard outputs of a GPS unit. So is it just a set of external references or they are used in the ethernet time stamping? The USRP2 has a 100 MHz clock internally. That clock will be locked to the 10 MHz reference you provide. Samples can be time stamped, and that time can be calibrated to the 1 PPS signal. In the most general case, that 1 PPS input just goes directly to the FPGA, so internally you can do whatever you want with it. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] updated BBN 80211 code?
Hello, Has anyone updated the BBN 80211 code to work with the current trunk? I would like to use the BBN code in conjunction with the XCVR2450 daughterboard, which doesnt seem to be supported in the last stable release. If nobody has modified the code BBN code, how difficult would it be? Is there any documentation regarding updating old code for use with the trunk? Regards, Dustin Maas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 FPGA Notes
Please note that the USRP2 uses a Spartan 3-2000 chip. This means that if you intend to do your own FPGA development, you need to use the full version of the Xilinx tools in order to generate an image for it. You cannot use the free web pack version. Thus there are several options for you: - Just use the prebuilt FPGA images we provide - Purchase the full version of ISE from Xilinx - Get a 60 day demo version from the Xilinx Web Site - Convince your Xilinx apps engineer to get you a free copy - Universities often get the tools free of charge - Release your changes to the community and we can find some sort of way to build them for you (if anybody wants to work on putting together some scripts to do this automatically, let me know). Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Not able to set TX freq from c++ (branchtrondeau/dbs) - solved (part 1)
On Friday 12 September 2008 14:22:49 you wrote: > Stefan, > > Could you just direct me to where I can find this file. Hi Per, I have the code running, but I want to clean it up further.The code is a cleaned up version of the code by trondeau. I will release my changes next week (hopefully monday, maybe wednesday). Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen mailto:lurch at gmx.li http://www.kawo1.rwth-aachen.de/~lurchi/ phone: +49 241 53809034 mobile: +49 151 50412019 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Announcement
- Start Original Message - Sent: Fri, 12 Sep 2008 12:04:44 -0700 From: Eric Blossom <[EMAIL PROTECTED]> To: Douglas Geiger <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] USRP2 Announcement > On Fri, Sep 12, 2008 at 01:54:08PM -0500, Douglas Geiger wrote: > > Very exciting! > > > > One technical question: > > By 25 MHz of instantaneous RF bandwidth - do you mean the 100Msamples/s > > from the ADC gets decimated down to 50Msamples/s? In which case, is the > > Gig-E able to handle that much sustained throughput (I'm guessing that's > > with 8-bit samples?). > > 100MS/s I & Q is decimated to 25MS/s complex. We use 16-bit I & Q. > That works out to ~800Mbit/s on the gigabit ethernet, which the USRP2 > can sustain, no problem. > > > Also, does the locking of the clocks of multiple USRP2's work like the > > USRP, e.g. where I can set one as the master and the other as slave - i.e. > > is the MIMO cable you refer to a coax SMA-SMA cable to connect the clock > > in/out connect (which have to be soldered in place) and the 2-wire cable to > > the daughterboard (like described on > > http://gnuradio.org/trac/wiki/MultiUsrp)? > > No soldering required. The mimo cable is a serial attached scsi cable > repurposed for our needs. The host configures the clocking on the > USRP2s over the ethernet. > > Here are the clocking options: > > USRP uses it's own free running xtal oscillator > USRP uses the external reference input (SMA connector) > USRP uses the clock provided over the MIMO cable. > > In addition, the master is programmed to drive clock onto the > MIMO cable. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > - End Original Message - Hello, Is 14 bits good enough to do HF receive without doing special gain control or filtering? I assume that I could take the whole HF spectrum, output it at 15 MSPS, and only need 480Mbit/s of ethernet bandwidth and 60 MBytes of disk space per second of recording. I could put about 1-1/2 minutes of HF spectrum on a single layer DVD-R. I guess I need that Blu-Ray drive now. I ordered one today and I hope I get it before I leave for the DCC. The case alone looks neat. 73 Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 1 PPS input for USRP2
Hi, I just saw the specifications for USRP2. I wanted to know the use of the 1 PPS and 10 MHz inputs. These are standard outputs of a GPS unit. So is it just a set of external references or they are used in the ethernet time stamping? Regards Subodh _ See how Windows connects the people, information, and fun that are part of your life. http://clk.atdmt.com/MRT/go/msnnkwxp1020093175mrt/direct/01/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Announcement
On Fri, Sep 12, 2008 at 01:54:08PM -0500, Douglas Geiger wrote: > Very exciting! > > One technical question: > By 25 MHz of instantaneous RF bandwidth - do you mean the 100Msamples/s > from the ADC gets decimated down to 50Msamples/s? In which case, is the > Gig-E able to handle that much sustained throughput (I'm guessing that's > with 8-bit samples?). 100MS/s I & Q is decimated to 25MS/s complex. We use 16-bit I & Q. That works out to ~800Mbit/s on the gigabit ethernet, which the USRP2 can sustain, no problem. > Also, does the locking of the clocks of multiple USRP2's work like the > USRP, e.g. where I can set one as the master and the other as slave - i.e. > is the MIMO cable you refer to a coax SMA-SMA cable to connect the clock > in/out connect (which have to be soldered in place) and the 2-wire cable to > the daughterboard (like described on > http://gnuradio.org/trac/wiki/MultiUsrp)? No soldering required. The mimo cable is a serial attached scsi cable repurposed for our needs. The host configures the clocking on the USRP2s over the ethernet. Here are the clocking options: USRP uses it's own free running xtal oscillator USRP uses the external reference input (SMA connector) USRP uses the clock provided over the MIMO cable. In addition, the master is programmed to drive clock onto the MIMO cable. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 Announcement
Very exciting! One technical question: By 25 MHz of instantaneous RF bandwidth - do you mean the 100Msamples/s from the ADC gets decimated down to 50Msamples/s? In which case, is the Gig-E able to handle that much sustained throughput (I'm guessing that's with 8-bit samples?). Also, does the locking of the clocks of multiple USRP2's work like the USRP, e.g. where I can set one as the master and the other as slave - i.e. is the MIMO cable you refer to a coax SMA-SMA cable to connect the clock in/out connect (which have to be soldered in place) and the 2-wire cable to the daughterboard (like described on http://gnuradio.org/trac/wiki/MultiUsrp)? Thanks, Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] USRP support plan
I'm very happy to hear that, Matt. The SBRAC observatory architecture is based on USRP1! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Ettus Sent: Friday, September 12, 2008 2:31 PM To: Alberto Trentadue Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] USRP support plan Alberto Trentadue wrote: > Hello > I have recently purchased the USRP and planning SDR/education > applications. > Now that USRP2 is out, what is the plan to keep USRP supported, both > HW-wise and by GNURadio? > The USRP will continue to be both produced and supported for the foreseeable future. We have no plans to discontinue it. Matt ___ 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] USRP support plan
Alberto Trentadue wrote: Hello I have recently purchased the USRP and planning SDR/education applications. Now that USRP2 is out, what is the plan to keep USRP supported, both HW-wise and by GNURadio? The USRP will continue to be both produced and supported for the foreseeable future. We have no plans to discontinue it. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 Announcement
USRP News and Announcements September 2008 1 USRP2 Now Available 2 Status of the original USRP 3 Daughterboard Status 4 Upcoming Events 1 USRP2 Now Available We are very happy to be able to announce that the USRP2 is now available for purchase. The USRP2 builds on the success of the original USRP, and adds these new features: - Gigabit Ethernet interface - 25 MHz of instantaneous RF bandwidth - Xilinx Spartan 3-2000 FPGA - Dual 100 MHz 14-bit ADCs - Dual 400 MHz 16-bit DACs - 1 MB of high-speed SRAM - Locking to an external 10 MHz reference - 1 PPS (pulse per second) input - Configuration stored on standard SD cards - Standalone operation - The ability to lock multiple systems together for MIMO - Compatibility with all the same daughterboards as the original USRP At this time, the USRP2 is in "beta release" state. Not all of the software and/or features are currently ready for production use. The USRP2 is initially supported on Linux, and we anticipate that drivers for Windows, Mac OS X, and other systems will be developed in the coming months. We are currently offering the USRP2 for a special introductory price of $1400, which may change in early 2009. Due to the high initial demand, and the beta release status, we have made some modifications to the normal order fulfillment process: - You may order as many systems as you like, but we can only ship up to 2 units to each customer from the first batch. The remainder will be held as a back-order, and will be shipped when available. You can cancel the remainder at any time, if you wish. - Precedence will be given to longtime members of, and contributors to, the GNU Radio / USRP community. - There are no quantity, academic, distributor, reseller, or other discounts. We will not be selling to resellers for the time being, only directly. We apologize for any inconvenience this may cause, but we feel that this policy will ensure that we can get systems to the maximum number of users in the short term. The USRP2 package includes the USRP2 motherboard, an enclosure, 2 SMA-SMA Bulkhead cables for RF, an ethernet cable, power supply, SD memory card, and a hardware packet. The USRP2 is only available in this complete package configuration. Also available are extra ethernet cables, extra SD cards, and SD memory reader/writers for USB ports. The power supply is the same as the one used for the original USRP. For those wishing to use their USRP2s in a MIMO configuration, we are selling the USRP2 MIMO cable for $70 each. You only need 1 MIMO cable for every pair of USRP2s. The beginning of a wiki page for the USRP2 is at: http://gnuradio.org/trac/wiki/USRP2 2 Status of the original USRP We will continue to produce and support the original USRP for the forseeable future. We have no intention of discontinuing it. There is no trade-in or upgrade program available. 3 Daughterboard Status Unfortunately, the release of the WBX0510 has been significantly delayed. We hope to have it ready in early 2009. We are sorry for any inconvenience this may have caused. The RFX400, which covers 400 to 500 MHz has been reintroduced, at the original price of $275. These are available to order immediately. 4 Upcoming Events The USRP2 will demonstrated at the TAPR Digital Communications Conference, and will be the subject of a technical talk given by Matt. The DCC is being held in Chicago from September 26th through 28th. http://www.tapr.org/dcc Ettus Research is proud to be a sponsor of the 2008 IEEE DySPAN conference on Dynamic Spectrum Access Networks. Johnathan Corgan of Corgan Enterprises will be giving a half-day tutorial on GNU Radio and the USRP, and there will be public demonstrations of the USRP and USRP2. DySPAN 2008 will be held from October 14th through 17th in Chicago, Illinois. http://www.ieee-dyspan.org/2008 Ettus Research will be exhibiting at the SDR'08 Technical Conference and Product Exposition, being held from October 26th through 30th in Washington, D.C. Matt is also the chair for the "Open Source Hardware and Software" session which will feature several exciting papers. Additionally, Ettus Research is proud to be a sponsor of the 2008 Smart Radio Challenge, a competition between university teams to solve real world communication problems using software radios. http://sdrforum.org/sdr08/index.html http://www.radiochallenge.org/ If you attend any of these events, pleas
RE: [Discuss-gnuradio] ATSC demod tips
> I got a few underruns during the "usrp_rx_cfile". > About 10 in 10 seconds. The raw data file is 446 meg. Underruns are bad. Try capturing the data to a ram disk instead of your hard drive if you do not have a faster hard drive setup available (i.e. RAID). I used the ATSC demodulator a few months back and was never able to successfully store that data down to my hard drive, so I allocated a 512 MB ramdisk and used that which worked great. Thanks, Brandon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP support plan
On Fri, Sep 12, 2008 at 10:27 AM, Alberto Trentadue <[EMAIL PROTECTED]> wrote: > Hello > I have recently purchased the USRP and planning SDR/education > applications. > Now that USRP2 is out, what is the plan to keep USRP supported, both > HW-wise and by GNURadio? The USRP2 does not really replace USRP. The USRP2 is 2x the price. The USRP2 has only support for one TX and one RX daughterboard. Both support the same daughterboards. While the USRP2 has many advantages, including increased dynamic range, improved clocking, a much larger FPGA, greatly increased bandwidth, and more on-board intelligence, there are many applications which do not need the USRP2s improvements and would be hurt by the 4x increase in price per-supported daughterboard. There is also a rather large installed base of USRP. As far as I'm aware Matt intends to continue to sell USRP, and I expect that the GNURadio software stack will continue to support it. I would expect that there will be some new blocks and examples applications which require the increased bandwidth or the improved FPGA on USRP2, but the sorts of things which already work should expect to work. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A problem of the turbo channel coding!
This apparently went off-list and I didn't catch it. Achilleas Anastasopoulos did a great job with the gr-trellis work and documentation. Brian -- Forwarded message -- From: Brian Padalino <[EMAIL PROTECTED]> Date: Fri, Sep 12, 2008 at 10:15 AM Subject: Re: [Discuss-gnuradio] A problem of the turbo channel coding! To: Shucai Xiao <[EMAIL PROTECTED]> Through a couple minutes in the trunk I was able to find GREAT documentation written for gr-trellis! Kudos to Achilleas Anastasopoulos for writing such great documentation. Check here: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-trellis/doc/gr-trellis.xml And there are a bunch of good examples here: http://gnuradio.org/trac/browser/gnuradio/trunk/gr-trellis/src/examples I'd guess this will probably keep you busy for a while. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to use if statement in GNU radio
On Fri, Sep 12, 2008 at 10:19 AM, Pu, Di <[EMAIL PROTECTED]> wrote: > Hi All, > > I was trying to combine two signals in GNU radio. One is a sinusoid wave, and > the other is a constant wave. The amplitude of the sine wave is higher than > that of the constant wave. What I want to do is to truncate the top part of > the sinusoid wave: when the sine wave is higher than the constant wave, let > it be the constant wave. I don't know whether it is feasible with IF > statement in GNU radio. > > The IF part of my code: >self.siggen = gr.sig_source_f (self.usb_freq (), > gr.GR_SIN_WAVE, > self.waveform_freq, > self.waveform_ampl, > self.waveform_offset) > >self.siggen1 = gr.sig_source_f (self.usb_freq (), > gr.GR_CONST_WAVE, > self.waveform_freq, > 0.5*self.waveform_ampl, > self.waveform_offset) > >if self.siggen < self.siggen1: > self.connect (self.siggen, self.src) >else: > self.connect (self.siggen1, self.src) > > If it is not doable, could you provide me with some methods to do this? Thank > you very much! You can't really do comparisons against the objects and expect an attribute of the object to hold true. In this case you have two objects which provide streams of data and you are trying to compare the streams to each other. The idea behind the Python interface is that it supplies the glue to your flowgraph and all the real work is done in C++. I believe what you want to do is clip your sine wave - is that correct? If a block doesn't exist to perform said clipping, you should think about writing your own clipping block. There are tutorials on how to write your own C++ gnuradio blocks, and (obviously) many examples of blocks currently in place. If you run into a problem or are stumped, the Wiki is a great resource as well as old list posts. Hope this helps! Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP support plan
Hello I have recently purchased the USRP and planning SDR/education applications. Now that USRP2 is out, what is the plan to keep USRP supported, both HW-wise and by GNURadio? Thanks A. Con Tiscali Adsl 8 Mega navighi SENZA LIMITI e GRATIS PER I PRIMI TRE MESI. In seguito paghi solo € 19,95 al mese. Attivala subito, l’offerta è valida fino al 18/09/2008! http://abbonati.tiscali.it/promo/adsl8mega/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to use if statement in GNU radio
Hi All, I was trying to combine two signals in GNU radio. One is a sinusoid wave, and the other is a constant wave. The amplitude of the sine wave is higher than that of the constant wave. What I want to do is to truncate the top part of the sinusoid wave: when the sine wave is higher than the constant wave, let it be the constant wave. I don't know whether it is feasible with IF statement in GNU radio. The IF part of my code: self.siggen = gr.sig_source_f (self.usb_freq (), gr.GR_SIN_WAVE, self.waveform_freq, self.waveform_ampl, self.waveform_offset) self.siggen1 = gr.sig_source_f (self.usb_freq (), gr.GR_CONST_WAVE, self.waveform_freq, 0.5*self.waveform_ampl, self.waveform_offset) if self.siggen < self.siggen1: self.connect (self.siggen, self.src) else: self.connect (self.siggen1, self.src) If it is not doable, could you provide me with some methods to do this? Thank you very much! Sincerely, Di ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A problem of the turbo channel coding!
2008/9/12 Shucai Xiao <[EMAIL PROTECTED]>: > Thanks for your response. > > I have another problem that, if the USRP board is used in the system and the > GMSK modulation is used, what kind of channel coding module can be used, and > where should we insert the channel coding, before the GMSK module or after > the GMSK? I'm having a hard time following your question. What exactly are you trying to do? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] A problem of the turbo channel coding!
Also, if there is any existing channel encoding/decoding modules that use short/char as input and use the same type as the output, too? Thanks Best regards Shucai -Original Message- From: Brian Padalino [mailto:[EMAIL PROTECTED] Sent: 2008年9月12日 8:54 To: Shucai Xiao Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] A problem of the turbo channel coding! On Fri, Sep 12, 2008 at 8:37 AM, Shucai Xiao <[EMAIL PROTECTED]> wrote: > Hi, all > > > > Currently, I am trying to establish a data transmission system > using the Viterbi coding method as the channel coding. > > I found a problem that the output of the coding module is short > type, > > Enc = trellis.encoder_ss(f, 0) > > > > While the decode module needs a float type > > Va = trellis.viterbi_s(f, K, 0, -1) > > > > Can some one tell me how to make them compatible? The encoder works on hard data bits that you want to transmit over the air. The decoder works on soft decision bits that you have received. Scale your encoder bits to be within the soft decision range. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] A problem of the turbo channel coding!
Thanks for your response. I have another problem that, if the USRP board is used in the system and the GMSK modulation is used, what kind of channel coding module can be used, and where should we insert the channel coding, before the GMSK module or after the GMSK? Thanks a lot Shucai -Original Message- From: Brian Padalino [mailto:[EMAIL PROTECTED] Sent: 2008年9月12日 8:54 To: Shucai Xiao Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] A problem of the turbo channel coding! On Fri, Sep 12, 2008 at 8:37 AM, Shucai Xiao <[EMAIL PROTECTED]> wrote: > Hi, all > > > > Currently, I am trying to establish a data transmission system > using the Viterbi coding method as the channel coding. > > I found a problem that the output of the coding module is short > type, > > Enc = trellis.encoder_ss(f, 0) > > > > While the decode module needs a float type > > Va = trellis.viterbi_s(f, K, 0, -1) > > > > Can some one tell me how to make them compatible? The encoder works on hard data bits that you want to transmit over the air. The decoder works on soft decision bits that you have received. Scale your encoder bits to be within the soft decision range. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A problem of the turbo channel coding!
On Fri, Sep 12, 2008 at 8:37 AM, Shucai Xiao <[EMAIL PROTECTED]> wrote: > Hi, all > > > > Currently, I am trying to establish a data transmission system > using the Viterbi coding method as the channel coding. > > I found a problem that the output of the coding module is short > type, > > Enc = trellis.encoder_ss(f, 0) > > > > While the decode module needs a float type > > Va = trellis.viterbi_s(f, K, 0, -1) > > > > Can some one tell me how to make them compatible? The encoder works on hard data bits that you want to transmit over the air. The decoder works on soft decision bits that you have received. Scale your encoder bits to be within the soft decision range. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] A problem of the turbo channel coding!
Hi, all Currently, I am trying to establish a data transmission system using the Viterbi coding method as the channel coding. I found a problem that the output of the coding module is short type, Enc = trellis.encoder_ss(f, 0) While the decode module needs a float type Va = trellis.viterbi_s(f, K, 0, -1) Can some one tell me how to make them compatible? Thanks Shucai ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3rd party software
Hi Community, I want to share my 2 cents too, > George Nychis Wrote: > > I agree, svn+trac is the way to go here. It's what everyone is already > familiar with, and it works great. I agree too. > I was thinking that the SVN structure should be something like: > / > /project_name > /project_name/trunk > /project_name/tags > /project_name/branches I think, since it has not been created yet, careful structure should be followed. We should seek Eric and Johnathan advices. > > and then everyone has read access to everything, and commit access is > given to individuals working on > a project, or pretty much anyone who > wants it. I just don't think we can leave it anonymous commit. > Ok, but I think the documentation should be leaved to anonymous commit. > > Then, there is a mandatory project summary page for each project. It > needs to include basic > information like the platforms it runs on, the version of GNU Radio > needed, and any other additional > dependencies with a brief description of the project. Probably some > maintainer information too. I think we should add project references, snapshots, Bugs, Todo, documentation, Project voting, License...etc fields too. We should investigate "SourceForge" or any other similar web site to import useful features from it. Best Regards, Firas -- View this message in context: http://www.nabble.com/3rd-party-software-%28was-comedilib-question%29-tp19148615p19450726.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
