[Discuss-gnuradio] USRP-KNOPPIX Beta with the Alsa problem fixes: Is there anywhere it can be downloaded?
Hello, Is there anywhere the USRP-KNOPPIX Beta, with Alsa fixes can be downloaded, from? If not, then can at least someone put up the original USRP-Knoppix Beta release for download for all temporarily again please? I cant find it on any of the previous download sites, they are down, that had the first USRP-KNOPPIX Beta. :( Thanks for your assistance. Lamar Owen wrote: > On Thursday 05 May 2005 02:12, Matt Ettus wrote: > >>I have posted an iso image for a KNOPPIX-based distribution with all the >> software necessary for the USRP and GNU Radio built in. This should >>come in handy for those who have had trouble installing software, or >>wish to use their USRP with machines that don't have linux installed. > > > Is there a later iso than this one available now, or are we not up to that > yet? Progress on this is stalled for now, since wxwindows has been temporarily pulled from Debian for licensing reasons. I have a version which is newer than the released one, which fixes the alsa problems. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf
On Tue, Oct 23, 2007 at 05:45:02PM -0700, Hans Glitsch wrote:
> Yes
If it's reporting overruns then all bets are off.
multi_fft.py implements applies a channel filter to each stream.
Try turning it off. It should be possible from the command line, but
isn't. Change:
parser.add_option("-F", "--filter", action="store_true", default=True,
help="Enable channel filter")
to
parser.add_option("-F", "--filter", action="store_true", default=False,
help="Enable channel filter")
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf
Yes - Original Message - From: "Eric Blossom" <[EMAIL PROTECTED]> To: "Hans Glitsch" <[EMAIL PROTECTED]> Cc: Sent: Tuesday, October 23, 2007 5:37 PM Subject: Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf On Tue, Oct 23, 2007 at 05:16:14PM -0700, Hans Glitsch wrote: Hi, There's a problem with the std_4rx_0tx.rbf in the latest release. This problem did not exist in 3.0. Please see the attached image. All four inputs should look exactly the same, but there is something wrong with input 0. It could be that the imaginary part of the input 0 signal is getting suppressed. I don't know. Here's what I did: I have a brand new usrp with two basic rx boards. I connected a signal generator to a four way splitter and then connected the four way splitter directly to the four usrp inputs. The signal generator was set to 480khz at -17 dbm. Then I executed "multi_fft.py -d 100 -f 50 -g 0". The attached screen shot shows the problem with input 0. If I move the signal generator to 520khz, the reflection moves to the other side of zero freq. If I swap cables on input 0 and input 1, the problem stays with input 0. Thanks for your help, Hans Is it reporting any overruns? I.e., uOuOuOuOuOuOuOuO... Eric -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.503 / Virus Database: 269.15.6/1086 - Release Date: 10/22/2007 7:57 PM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] found problem with std_4rx_0tx.rbf
On Tue, Oct 23, 2007 at 05:16:14PM -0700, Hans Glitsch wrote: > Hi, > > There's a problem with the std_4rx_0tx.rbf in the latest release. This > problem did not exist in 3.0. > > Please see the attached image. All four inputs should look exactly the > same, but there is something wrong with input 0. It could be that the > imaginary part of the input 0 signal is getting suppressed. I don't know. > > Here's what I did: I have a brand new usrp with two basic rx boards. I > connected a signal generator to a four way splitter and then connected the > four way splitter directly to the four usrp inputs. The signal generator > was set to 480khz at -17 dbm. Then I executed "multi_fft.py -d 100 -f > 50 -g 0". The attached screen shot shows the problem with input 0. If > I move the signal generator to 520khz, the reflection moves to the other > side of zero freq. If I swap cables on input 0 and input 1, the problem > stays with input 0. > > Thanks for your help, > Hans Is it reporting any overruns? I.e., uOuOuOuOuOuOuOuO... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-channel I/Q buffer format...
Jared Jensen wrote: > I'm getting some strange behavior when I use two DBSRX boards with my > USRP. I just wanted to vet some of my assumptions as I'm debugging. > I'm assuming that the data comes across the USB bus as follows > > I_A/Q_A/I_B/Q_B/I_A/Q_A/ > > Is that correct? i.e. do we get I/Q of one board followed by I/Q of > the other board? And they come across as 2-byte samples for each I > and 2-byte samples for each Q? > > So... > > I_A_16bits/Q_A_16bits/I_B_16bits/Q_B_16bits/... and so on? yes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.0 Release Tarballs Available
On Mon, Oct 22, 2007 at 07:05:43PM -0700, Johnathan Corgan wrote: > GNU Radio stable release 3.1.0 is now available for download: > To emphasize what Johnathan already said: > This new stable branch will be maintained such that existing Python and > C++ code based upon it will not break due to updates in the series. New > releases in this series will have backported bug fixes and new features > added. However, no changes will be made that (intentionally!) result in > existing user code not functioning. > > If it sounds like this means we *will* be making such changes on the > trunk, you are absolutely right. Several features targeted for the 3.2 > stable branch will require deep surgery and will break user code that > doesn't keep up: > > * Removal of gr.flow_graph(), leaving only gr.top_block() added in 3.1 > * Removal of gr.hier_block(), leaving only gr.hier_block2() added in 3.1 > > Install and develop for the 3.1 stable branch if you want to avoid any > issues, or work off the trunk and enjoy the ride. We'll probably start tearing the old flow graph code out of the trunk in the next 24 hours or so. FAQ: Why are you doing this? Answer: the 3.1 stable branch contains two parallel implementations of more or less the same functionality. The old one is Python and C++, the new one is pure C++. They do not build on a common core (except at the very bottom). We want to move forward with the Cell port, a new "thread-per-block" scheduler (SMP/SMT goodness) and gluing mblocks and gr_blocks together. Ripping out the old code "clears the decks" for the new development. The new stuff will support Python + C++ (like we do now), but will also enable all C++ development. We don't intend to change the interface to the new top_block/hier_block2 code, so if you've already converted your code to use that, the trunk should remain a safe place for development. If you're tracking the trunk, and have code that hasn't already been converted to top_block/hier_block2 you'll probably want to consider tracking the 3.1 stable branch instead of the trunk. (See http://gnuradio.org/trac/wiki/BuildGuide for svn instructions) Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] output usrp_fft.py into a file
On Tue, Oct 23, 2007 at 02:53:44PM -0400, [EMAIL PROTECTED] wrote: > I am new to the GNU Radio and Python and need help with outputting the > usrp_fft.py output into a file or a variable at a particular rate. How can I > do that? > > Thank you in advance. Omer You will need to create a modified version of gr-wxgui/src/python/fftsink2.py that logs the information that you want to a file. Use gr.file_sink to write the binary data to a file. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN module
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think the answer you want is: cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel then ./bootstrap && ./configure as you wish from the gr-bbn subdirectory. - -Dan Mohammad Hamed Firooz wrote: > > Hi everyone, > I am going to use BBN code on IEEE802.11b. But these codes need to > import a module named bbn from gnuradio package. My gnuradio has not > this module. Where can I find it and how I can add it to my gnuradio > package. > > Thanks > hamed > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHkSCy9GYuuMoUJ4RAut+AJsFGyVhyBc3va/0kozYynJ6FDJR2ACdGpLT WH0T1Yc5qPMuC9cFso0oyv0= =gmsI -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] output usrp_fft.py into a file
I am new to the GNU Radio and Python and need help with outputting the usrp_fft.py output into a file or a variable at a particular rate. How can I do that? Thank you in advance. Omer -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/messages/discuss-gnuradio@gnu.org/topic.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Translation RFX drivers in C++
Hi, I have to use the RFX400 dboard for a C++ projet. Like the drivers for this board was not available in C++, I translated them from python. I am now debugging my code and I have some issues. 1) I am not able to tune correctly the VCO of the board (ADF4360-7). The VCO generates a signal at about 400 MHz (see on a spectrum analyszer), and I'm not able to change this frequency. On the other end, I was able to see the data on the SPI bus, and seem all right (enable, clock, and the data). So, I can't figure out why the frequency didn't change. I would like to know if there is any special thing we must do to activate the SPI of the chip, that are not on the dirvers (db_flex.py). Also, is the 400 MHz is the default frequency of the VCO? 2) I noticed the VCO output shut down when I disconnect the antenna. Is there any protection on the board to protect the card when there is no antenna on the RX/TX or RX2 connectors. If yes, if I connect a RF spectrum analyser on TX, do you know if the output will be on? Naturally, when I finish I can send you the code, but it is probably not ready for publication. If anyone want to debug it, I can send the actual version of the code. Thanks Maxime Lepage -- View this message in context: http://www.nabble.com/Translation-RFX-drivers-in-C%2B%2B-tf4679543.html#a13370967 Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.0 Release Tarballs Available
Johnathan Corgan wrote: > GNU Radio stable release 3.1.0 is now available for download: The official signed tarballs are now up at gnu.org: ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.1.0.tar.gz ftp://ftp.gnu.org/gnu/gnuradio/gr-howto-write-a-block-3.1.0.tar.gz -- 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] Decoding CPFSK
Some time ago I had checked in a small piece of code that implements arbitrary CPM signals (CPFSK, GMSK, MSK, etc are special cases). It is still there in the trunk in the blks2impl directory under the name cpm.py My plan was to provide a generic trellis-based decoder for this as well, but never found the time to do it... Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN module
Did you run ./configure, make and make install from the 802.11 top level directory? At 12:57 PM 10/23/2007, you wrote: Hi everyone, I am going to use BBN code on IEEE802.11b. But these codes need to import a module named bbn from gnuradio package. My gnuradio has not this module. Where can I find it and how I can add it to my gnuradio package. Thanks hamed ___ 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] Strategy advice
On 10/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: > One approach then would be to ensure this never happens, i.e., add a > small epsilon to each input stream, and make epsilon small enough to not > sufficiently impact the results for "typical" input values. Normalizing > the conjugate product will then give you the cosine as the real value, > as you mentioned. Or, you could just divide the abs value into the real > value of the product, and avoid the extra calculation of the normed > imaginary part which you are going to throw away. Thanks for the replies guys. The above is the approach I went with. It seems to work well, and gave a further BER improvement to my GMSK demod experiments. For those interested, here is how I'm using it in the context of GMSK demod: self.kc = gr.kludge_copy(gr.sizeof_gr_complex) self.delay = gr.delay(gr.sizeof_gr_complex, 2*self._samples_per_symbol) #2T delay self.conj = gr.conjugate_cc() self.mult = gr.multiply_cc() self.c2mag = gr.complex_to_mag() self.safety_add = gr.add_const_ff(0.001) self.c2f = gr.complex_to_float() self.rescaler = gr.divide_ff() self.sub = gr.add_const_ff(-self._decision_threshold) samp_per_sec = samples_per_symbol * sym_per_sec pre_cr_filt_bw = sym_per_sec*pre_cr_filt_bt pre_cr_filt_taps = gr.firdes.low_pass(1.0, samp_per_sec, pre_cr_filt_bw, pre_cr_filt_tr*samp_per_sec, gr.firdes.WIN_HAMMING) self.pre_cr_filt = gr.fir_filter_fff(1, pre_cr_filt_taps) # the clock recovery block tracks the symbol clock and resamples as needed. # the output of the block is a stream of soft symbols (float) self.clock_recovery = gr.clock_recovery_mm_ff(self._omega, self._gain_omega, self._mu, self._gain_mu, self._omega_relative_limit) # slice the floats at 0, outputting 1 bit (the LSB of the output byte) per sample self.slicer = gr.binary_slicer_fb() [...] # Connect & Initialize base class self.connect(self, self.kc, self.delay, self.conj, (self.mult, 0)) self.connect(self.kc, (self.mult, 1)) self.connect(self.mult, self.c2f, (self.rescaler, 0)) self.connect(self.mult, self.c2mag, self.safety_add, (self.rescaler, 1)) self.connect(self.rescaler, self.pre_cr_filt, self.sub, self.clock_recovery, self.slicer, self) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BBN module
Mohammad Hamed Firooz <[EMAIL PROTECTED]> writes: > Hi everyone, > I am going to use BBN code on IEEE802.11b. But these codes need to > import a module named bbn from gnuradio package. My gnuradio has not > this module. Where can I find it and how I can add it to my gnuradio > package. Several people have gotten this to more or less work. It's hard to help unless you describe precisely what you've done. Presumably you have found the code, but if not: http://www.gnuradio.org/trac/wiki/BBN_Technologies_Internetwork_Research_ADROIT_Project ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] m-block/in-band signaling status/questions
On Tue, Oct 23, 2007 at 11:27:36AM -0500, sanmi wrote: > Hey guys, > > Our Group currently has a 2x2 MIMO-OFDM system implemented on the USRP/GNU > radio platform and we are planning on implementing a 4x4 MIMO-OFDM system > which we need working in the next couple of months. We are trying to decide > between a custom FPGA solution and the in-band signaling/m-block solution. > > We saw these recent posts: > > http://www.nabble.com/m-block-%3C--%3E-GR-block-integration-t4536641.html > > http://www.nabble.com/in-band-signaling-project-overview-tf4610363.html#a131 > 66091 > > These indicated that the in-band signaling /m-block implementation is almost > complete but we are unclear about what is done and what need to be > completed. Some specific questions we have are? > > > > Status: > > 1) Is the code in the testing phase or development phase, is there a > timeline for completion? Still in the development phase. > 2) Is there a "hello world" example for m-block/in-band signaling?(Simple > waveform packet tx/rx with all the functionality) No, we're not there yet. > 3) Where can we find the code documentation? You're still early. The development code isn't merged into the trunk. What docs there are are the doxygen comments in the .h files. > Compatibility: > > Is the m-bock wrapper for flow graphs (as outlined in the BBN doc) > implemented? Not yet. > Specifically, what is the interface between the legacy code and > the in-band signaling code? Would we need to redo all our signal processing > blocks? You shouldn't have to reimplement your signal processing blocks. > Any other comments/suggestions are appreciated. This stuff isn't ready for use yet, and the API's are not yet stable. > Sanmi Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.head, and flushing of file sinks
On Tue, Oct 23, 2007 at 12:22:31PM -0400, Steven Clark wrote: > 1) Has anybody ever noticed a case where gr.head doesn't seem to limit the > amount of data that flows through it? I have (some data source) -> (head) -> > (file sink), and sometimes the writing to the file shuts off appropriately, > other times it seems to skip over the limit and would happily consume my > entire hard drive (I watch the file grow to 50MB, 100MB, ...) if I didn't > Ctrl-C. I'm having trouble reproducing this now, but thought I would ask. > > > 2) > b = MyTopBlockWhichWritesToAFileSink() > b.start() > b.wait() > raw_input() #wait indefinitely for user to hit enter > del b > > b.wait() doesn't seem to do a final flush of the file sink...ie if b is > supposed to write 1 bytes to a file, after b.wait() the file will have > 8.0KB (~8192 bytes) in it. Not until del b is the file complete (9.8KB, > ~1 bytes). What exactly does b.wait() do? Is there any way to force a > file flush without deleting b? You could call my_file_sink_instance.close(), which will flush and close the underlying file. This may not be exactly what you want. > > 3) Is there anything wrong with having multiple sequential top blocks? > Something like: > > a = MyTopBlock1() > a.start() > a.wait() > del a > > for i in range(10): > b = MyTopBlock2() > b.start() > b.wait() > del b It should work. Doesn't mean that there isn't a bug somewhere, particularly if you are using the pkt based stuff. There was a report of a hang related to something (the queue reader I think) hanging on a message queue that was never seeing any further messages. FWIW, the existing QA code uses serial top blocks without a problem. If you're using the gr.udp_source, it's broken, and will result in gr.head() never stopping. It'll just hang. In the random suggestion category: stylistically, instead of b.start(), b.wait(), you may want to consider b.run(). It does the start(), wait() for you. If this didn't help, can you cook a simple example that has the problem. E.g., gr.file_source() -> gr.head() -> gr.file_sink() Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BBN module
Hi everyone, I am going to use BBN code on IEEE802.11b. But these codes need to import a module named bbn from gnuradio package. My gnuradio has not this module. Where can I find it and how I can add it to my gnuradio package. Thanks hamed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr.head, and flushing of file sinks
Steven Clark wrote: > 1) Has anybody ever noticed a case where gr.head doesn't seem to limit > the amount of data that flows through it? I have (some data source) -> > (head) -> (file sink), and sometimes the writing to the file shuts off > appropriately, other times it seems to skip over the limit and would > happily consume my entire hard drive (I watch the file grow to 50MB, > 100MB, ...) if I didn't Ctrl-C. I'm having trouble reproducing this now, > but thought I would ask. Please let us know when you have a way to reliably reproduce this, and document a bug on our Trac website. > 2) > b = MyTopBlockWhichWritesToAFileSink() > b.start() > b.wait() > raw_input() #wait indefinitely for user to hit enter > del b > > b.wait() doesn't seem to do a final flush of the file sink...ie if b is > supposed to write 1 bytes to a file, after b.wait() the file will > have 8.0KB (~8192 bytes) in it. Not until del b is the file complete > (9.8KB, ~1 bytes). What exactly does b.wait() do? Is there any way > to force a file flush without deleting b? 'wait()' will cause the calling thread to block until all the top block scheduler threads exit. This may happen on its own or be caused by a SIGINT. The gr.file_sink block doesn't close its file handle and flush to disk until its destructor is called, which doesn't happen until it entirely goes out of scope (that's what your 'del b' is forcing.) There isn't at present a way to cause a flush to occur at random. Partly this is because the file sink fwrite calls are happening in a separate thread, so to add a flush method to the block would require adding locking, etc. Another method might be to add a constructor passed flag that would optionally cause a fflush after every fwrite. This would really slow it down, but would give you the results you want. > 3) Is there anything wrong with having multiple sequential top blocks? > Something like: No, as long as you are deleting each before creating the next one. At present, there is a somewhat artificial limitation of one top block per application. This will go away in release 3.2. -- 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] Mux settings...
On Tue, Oct 23, 2007 at 10:56:09AM -0500, Tarun Tiwari wrote: > Hi Eric, > > A small question :) > Did you mean that 0x3210 was not different from 0x32103210 on RFX > boards? If you're only using two channels, it doesn't matter what you route to the DDC inputs of channels 3 and 4 with this caveat: if you are routing a zero into any of the Q inputs, you must route a zero into all of the Q inputs. > Regards, > Tarun > UT Dallas > > On 10/22/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > > > If you're using a single channel, usrp.determine_rx_mux_value will get you > > the right answer, regardless of the type of daughterboard. > > > > On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you > > up with side A routed to channel 0 and side B routed to channel 1. > > > > See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams > > and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html > > > > Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] m-block/in-band signaling status/questions
Hey guys, Our Group currently has a 2x2 MIMO-OFDM system implemented on the USRP/GNU radio platform and we are planning on implementing a 4x4 MIMO-OFDM system which we need working in the next couple of months. We are trying to decide between a custom FPGA solution and the in-band signaling/m-block solution. We saw these recent posts: http://www.nabble.com/m-block-%3C--%3E-GR-block-integration-t4536641.html http://www.nabble.com/in-band-signaling-project-overview-tf4610363.html#a131 66091 These indicated that the in-band signaling /m-block implementation is almost complete but we are unclear about what is done and what need to be completed. Some specific questions we have are? Status: 1) Is the code in the testing phase or development phase, is there a timeline for completion? 2) Is there a "hello world" example for m-block/in-band signaling?(Simple waveform packet tx/rx with all the functionality) 3) Where can we find the code documentation? Compatibility: Is the m-bock wrapper for flow graphs (as outlined in the BBN doc) implemented? Specifically, what is the interface between the legacy code and the in-band signaling code? Would we need to redo all our signal processing blocks? Any other comments/suggestions are appreciated. Sanmi ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mux settings...
On Tue, Oct 23, 2007 at 08:42:59AM -0700, Hans Glitsch wrote: > > > >For the Basic Rx, 0xf3f2f1f0 is the correct setting to feed 4 separate > >signals into the I inputs of 4 DDCs, with zeros fed to the Q inputs. > > > >To use 4 channels, you must use the std_4rx_0tx.rbf fpga image. > >If you use the std_4rx_0tx.rbf image, the decimation rate must be <= 128. > >If you need more decimation, you must do it in software. > > > >Eric > > > > I wasn't aware that I couldn't use a decimation of 250. 250 seemed to work > fine with release 3.0. This is the problem that was reported last week. Without the halfband in the FPGA, the CIC sections aren't wide enough to support decimation > 128 without losing information. > Are odd numbers ok? Can I use a decimation of 125? With the std_4rx_0tx.rbf image, I believe odd numbers will work. They will not work with std_2rxhb_2tx.rbf > Thanks, > Hans Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AMSAT Meeting in PITTSBURGH (not Philly)
Sorry! I typed Philadelphia (where I was last weekend) and I meant Pittsburgh, Pa which is indicated on the links. Ooops. Bob ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr.head, and flushing of file sinks
1) Has anybody ever noticed a case where gr.head doesn't seem to limit the amount of data that flows through it? I have (some data source) -> (head) -> (file sink), and sometimes the writing to the file shuts off appropriately, other times it seems to skip over the limit and would happily consume my entire hard drive (I watch the file grow to 50MB, 100MB, ...) if I didn't Ctrl-C. I'm having trouble reproducing this now, but thought I would ask. 2) b = MyTopBlockWhichWritesToAFileSink() b.start() b.wait() raw_input() #wait indefinitely for user to hit enter del b b.wait() doesn't seem to do a final flush of the file sink...ie if b is supposed to write 1 bytes to a file, after b.wait() the file will have 8.0KB (~8192 bytes) in it. Not until del b is the file complete (9.8KB, ~1 bytes). What exactly does b.wait() do? Is there any way to force a file flush without deleting b? 3) Is there anything wrong with having multiple sequential top blocks? Something like: a = MyTopBlock1() a.start() a.wait() del a for i in range(10): b = MyTopBlock2() b.start() b.wait() del b ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] AMSAT Meeting in Philadelphia
The Radio Amateur Satellite Corporation, Inc. (AMSAT), a non-profit 501c3 organization in the U.S. which designs, builds, launches satellites for the use of radio amateurs worldwide is holding its annual meeting in Pittsburgh, Pa. this coming weekend. http://www.amsat.org/amsat-new/symposium/2007/index.php As with all amateur radio endeavors of any significance, a lot happens as a result of holding these meetings, and usually in the last hours before the event. This one is no different but I take the time to write to you because of some significant things that will happen at this meeting. The following well known amateurs will attend in addition to the usual list of AMSAT suspects. Frank Brickle, AB2KT Designer and co-author of DttSP, the software core used in PowerSDR (Flex-Radio), uwSDR (http://uwsdr.berlios.de) , jSDR, DttSP-shell, and several others. Designer and author of the VR, a radio kernel to be used in software/cognitive efforts for robust distributed computing radio systems and recently described at the DCC. Contributor to GnuRadio and HPSDR. For a general introduction to the entire area please http://www.nitehawk.com/w3sz/start.htm Phil Covington, N8VB Designer, author, leading developer in the HPSDR offerings (http://hpsdr.org) including Atlas, Ozymandias with contributions to Janus, Mercury, Penelope, and more. Matt Ettus, N2MJI GnuRadio. Design of USRP and USRP2 for GnuRadio. And lead designer on the AMSAT Advanced Communications Package. http://ettus.com http://gnuradio.org/trac Hartmut Päsler DL1YDD (AMSAT-DL V.P.) Hartmut will be telling us of the current status of Phase 3E and their launch opportunities and about Bochum 66' Dish that has been used to receive signals from planetary probes. Bruce Perens K6BP formerly of Pixar and amongst other things, editor of the Bruce Perens Open Source series of books. http://www.informit.com/promotions/promotion.aspx?promo=135563&redir=1 http://perens.com/ Gerald Youngblood, K5SDR Owner of Flex-Radio, designer of the SDR-1000, Flex5000 CONTRIBUTOR OF A MAJOR SYMPOSIUM PRIZE!! At this meeting AMSAT-NA will announce a major new satellite opportunity for us and how we intend to take advantage of it if all the stars line up! President Rick Hambly, W2GPS, has been working nonstop on this and we are excited to tell you about it in the first level of detail we are able to give and how we will be proceeding. We have an international audience attending and the symposium agenda is available from the URL above and many great speakers. Ya'll come. I realize that this is the last minute but more than a little bit of this stuff happened in the LAST TWO WEEKS and until it was ready to release, we just couldn't. I am hoping to reach amateurs who are within driving distance of Pittsburgh or those who can decide at the last minute to come. I believe this is an AMSAT symposium you do not want to miss. Bob McGwier ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decoding CPFSK
Andrew Rose wrote: > 2. 1200Hz/1800Hz continuous-phase FSK encoding 1200 bits per second. > i.e. each output bit is either 1 cycle of a 1200Hz wave (1-bit) or 1.5 > cycles of an 1800Hz wave (0-bit). The start of each bit is at a > zero-crossing (although there are obviously zero-crossings which aren't > the start of a bit). This modulation is known as Fast-Frequency-Shift-Keying (FFSK) or more accurately as Minimum Shift Keying (MSK). A nice description of the algorithm is contained in a 1990 masters thesis by Tim Wescott: http://www.wescottdesign.com/articles/MSK/mskTop.html The decoder in that project was written for a DSP chip, but you should be able follow the theory enough to figure out the right signal chain in GNU Radio. Since you're using the audio output of a scanner, you'll be doing something slightly different, as the typical way to decode FFSK starts with the complex baseband, and doesn't use FM demodulation. FFSK is a popular modem for low speed bursty data, and is very commonly used in public safety transmitter identification. That "braap" you hear at the start or end of many police and fire radio transmissions is usually an FFSK modulated burst of the radio serial number. Some ambulance rigs have a set of push-buttons for the driver to indicate they have arrived, or are driving with lights and sirens, or other status updates, and these go out over a channel as FFSK bursts. Another source of documentation for this protocol are the various chipsets used in the above radios. You'll get far more hits Googling for FFSK than for MSK, though, as FFSK is the "marketing" name while MSK is the more accurate term. When you get this working, we'd love to incorporate it as a standard block or hierarchical block in GNU Radio, if you're willing. -- 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] Mux settings...
Hi Eric, A small question :) Did you mean that 0x3210 was not different from 0x32103210 on RFX boards? Regards, Tarun UT Dallas On 10/22/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > If you're using a single channel, usrp.determine_rx_mux_value will get you > the right answer, regardless of the type of daughterboard. > > On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you > up with side A routed to channel 0 and side B routed to channel 1. > > See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams > and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html > > Eric > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mux settings...
For the Basic Rx, 0xf3f2f1f0 is the correct setting to feed 4 separate signals into the I inputs of 4 DDCs, with zeros fed to the Q inputs. To use 4 channels, you must use the std_4rx_0tx.rbf fpga image. If you use the std_4rx_0tx.rbf image, the decimation rate must be <= 128. If you need more decimation, you must do it in software. Eric I wasn't aware that I couldn't use a decimation of 250. 250 seemed to work fine with release 3.0. Are odd numbers ok? Can I use a decimation of 125? Thanks, Hans ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decoding CPFSK
Andrew Rose wrote: 2. 1200Hz/1800Hz continuous-phase FSK encoding 1200 bits per second. i.e. each output bit is either 1 cycle of a 1200Hz wave (1-bit) or 1.5 cycles of an 1800Hz wave (0-bit). The start of each bit is at a zero-crossing (although there are obviously zero-crossings which aren't the start of a bit). What you are describing is called Mean Shift Keying. It is a specialized form of FSK that is designed to have more efficient bandwidth utilization. I would guess that you could use the Gaussian Mean Shift Keying (GMSK) demodulator, or construct your own using a quadrature demodulator and a root-rased-cosine filter. @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Unable to find USRP
stevie.glass schrieb: I'm running Debian Etch (AMD 64, 2.6.22 kernel) with the binary GNURadio 3.0.2-2 packages. The 32 bit distribution works fine - I've been using it fine on my lab PC (same Debian Etch setup but 32 bit) for months. I only moved it there because this problem cropped up and it was as easy to run it in the lab. Now I want it back at home and I'm foxed by the problem. (IIRC this is something to do with USB send/resume and I was hoping it'd been fixed in the Debian binary by now. Why it works on my lab PC but not the home PC is also something I don't quite understand). If you want the 3.0.4 in Debian (with the mentioned fixes), you can install build-essential, and get the build-dependencies and build it yourself. See http://www.gnuradio.org/trac/wiki/DebianInstall Or you wait a little bit for the 3.1 release. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Decoding CPFSK
I'm trying to use GNURadio to decode a bit-stream from an FM signal and could do with some help. 1. Having removed the narrowband-FM modulation from the signal, I'm left with the following. 2. 1200Hz/1800Hz continuous-phase FSK encoding 1200 bits per second. i.e. each output bit is either 1 cycle of a 1200Hz wave (1-bit) or 1.5 cycles of an 1800Hz wave (0-bit). The start of each bit is at a zero-crossing (although there are obviously zero-crossings which aren't the start of a bit). 3. I then need to extract the data in bytes from the bit stream (1 start bit, 8 data bits, 1 stop bit, no parity bits per byte). I've done step 1 (using a scanner for now - although one day I may use a USRP for this). I'm struggling with step 2. Does GNURadio have a block (or blocks) for doing this? Step 3 is trivial. The only reason I mention it is because I believe steps 2 & 3 together are a fairly common method of encoding digital data for radio transmission - and therefore there might be a single block that does steps 2 & 3 in a single go. Andrew ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Unable to find USRP
Hi, Having a few problems getting GNURadio working on my home PC with the USRP. Can someone provide some tips to help me get it working again? The problem usrper has problems finding the USRP; it reports "usrper: failed to find usrp[0]". All of the examples fail with the "Unable to find USRP #0" error but I think its more basic than this. Here's what the syslog says about the device: /Oct 23 23:42:54 salyut kernel: usb 5-1: USB disconnect, address 8 Oct 23 23:42:54 salyut kernel: usb 5-1: new high speed USB device using ehci_hcd and address 9 Oct 23 23:42:54 salyut kernel: usb 5-1: configuration #1 chosen from 1 choice / But it is not there in lsusb: /Bus 005 Device 001: ID : Bus 004 Device 002: ID 051d:0002 American Power Conversion Back-UPS Pro 500/1000/1500 Bus 004 Device 001: ID : Bus 003 Device 002: ID 046d:0a01 Logitech, Inc. Bus 003 Device 001: ID : Bus 002 Device 002: ID 093a:2468 Pixart Imaging, Inc. Easy Snap Snake Eye WebCam Bus 002 Device 001: ID : Bus 001 Device 001: ID : / In usbview it shows up IN RED with the following details: /USRP Rev 2 Manufacturer: Free Software Folks Serial Number: Speed: 480Mb/s (high) USB Version: 2.00 Device Class: ff(vend.) Device Subclass: ff Device Protocol: ff Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: fffe Product Id: 0002 Revision Number: 1.02 Config Number: 1 Number of Interfaces: 3 Attributes: c0 MaxPower Needed: 0mA Interface Number: 0 Name: (none) Alternate Number: 0 Class: ff(vend.) Sub Class: ff Protocol: ff Number of Endpoints: 0 Interface Number: 1 Name: (none) Alternate Number: 0 Class: ff(vend.) Sub Class: ff Protocol: ff Number of Endpoints: 1 Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Interface Number: 2 Name: (none) Alternate Number: 0 Class: ff(vend.) Sub Class: ff Protocol: ff Number of Endpoints: 1 Endpoint Address: 86 Direction: in Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms / I'm running Debian Etch (AMD 64, 2.6.22 kernel) with the binary GNURadio 3.0.2-2 packages. The 32 bit distribution works fine - I've been using it fine on my lab PC (same Debian Etch setup but 32 bit) for months. I only moved it there because this problem cropped up and it was as easy to run it in the lab. Now I want it back at home and I'm foxed by the problem. (IIRC this is something to do with USB send/resume and I was hoping it'd been fixed in the Debian binary by now. Why it works on my lab PC but not the home PC is also something I don't quite understand). Steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with RFX900 daughterboard
Hi,everyone! I'm trying to transmit square wave from one RFX900 at frequency 915MHz,and I use the spectrum analyser to receive the signal.That's right to work.But after several days,I want to transmit square wave from TX/RX port and receive it from RX2 port with two antenna.First I execute a terminal to run transmit program,then I execute the other terminal to run usrp_oscope.py receive the square wave.Two program run at the same time.At first I can see the square wave at scope sink,but in a moment the signal degrade a lot and became more and more strange.At the last test,I transmit the square wave from TX/RX and receive from spectrum analyser,but I can't see the signal anymore.I doubt RFX900 daughterboard is breakdown.I add my square wave code.Could everybody tell me what's wrong about my experiment or my code? Thanks for help Henry class filesource (stdgui.gui_flow_graph): def __init__(self,frame,panel,vbox,argv): stdgui.gui_flow_graph.__init__ (self,frame,panel,vbox,argv) src=howto.mysource(100,gr.GR_SIN_WAVE,4,1) amp=gr.multiply_const_cc(8000) aa=gr.binary_slicer_fb() bb=gr.char_to_float() cc=gr.float_to_complex() self.connect(src,aa,bb,cc,amp) inter=12800/100 freq=915e6 sink=usrp.sink_c(0,inter) subdev=(0,0) m = usrp.determine_tx_mux_value(sink,subdev) sink.set_mux(m) subdev1=usrp.selected_subdev(sink,subdev) print "Using TX d'board %s" % (subdev1.side_and_name(),) r=usrp.tune(sink,0,subdev1,freq) subdev1.set_enable(True) self.connect(amp,sink) if 0: scope = scopesink.scope_sink_c(self, panel, sample_rate=100, frame_decim=1, v_scale=500, t_scale=0.25) self.connect(amp,scope) vbox.Add (scope.win, 1, wx.EXPAND) if __name__ == '__main__': app = stdgui.stdapp (filesource, "") app.MainLoop () -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/messages/discuss-gnuradio@gnu.org/topic.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with RFX900 daughterboard
Hi,everyone! I'm trying to transmit square wave from one RFX900 at frequency 915MHz,and I use the spectrum analyser to receive the signal.That's right to work.But after several days,I want to transmit square wave from TX/RX port and receive it from RX2 port with two antenna.First I execute a terminal to run transmit program,then I execute the other terminal to run usrp_oscope.py receive the square wave.Two program run at the same time.At first I can see the square wave at scope sink,but in a moment the signal degrade a lot and became more and more strange.At the last test,I transmit the square wave from TX/RX and receive from spectrum analyser,but I can't see the signal anymore.I doubt RFX900 daughterboard is breakdown.I add my square wave code.Could everybody tell me what's wrong about my experiment or my code? Thanks for help Henry class filesource (stdgui.gui_flow_graph): def __init__(self,frame,panel,vbox,argv): stdgui.gui_flow_graph.__init__ (self,frame,panel,vbox,argv) src=howto.mysource(100,gr.GR_SIN_WAVE,4,1) amp=gr.multiply_const_cc(8000) aa=gr.binary_slicer_fb() bb=gr.char_to_float() cc=gr.float_to_complex() self.connect(src,aa,bb,cc,amp) inter=12800/100 freq=915e6 sink=usrp.sink_c(0,inter) subdev=(0,0) m = usrp.determine_tx_mux_value(sink,subdev) sink.set_mux(m) subdev1=usrp.selected_subdev(sink,subdev) print "Using TX d'board %s" % (subdev1.side_and_name(),) r=usrp.tune(sink,0,subdev1,freq) subdev1.set_enable(True) self.connect(amp,sink) if 0: scope = scopesink.scope_sink_c(self, panel, sample_rate=100, frame_decim=1, v_scale=500, t_scale=0.25) self.connect(amp,scope) vbox.Add (scope.win, 1, wx.EXPAND) if __name__ == '__main__': app = stdgui.stdapp (filesource, "") app.MainLoop () -- This message was sent on behalf of [EMAIL PROTECTED] at openSubscriber.com http://www.opensubscriber.com/messages/discuss-gnuradio@gnu.org/topic.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Channel estimation GSM (GMSK modulation)
Hi Guys, I am interested in real-time channel estimation of a GSM signal. Since GSMK is a non-coherent modulation, performing channel estimation is not easy, at least to me. I have found a paper in which they correct for the 90 degree phase shift in every symbol (multiply by i^k, k'th symbol) before they correlate it with a known sequence (mid-amble of the SCH-packet). I hope you guys understand what I'm talking about. The absolute value of the main peak of my channel impulse response is what I expect it to be, however the phase information is totally off. Could anyone point me to some reference, or explain briefly, how I could perform a good channel estimation for GSM? Or any idea where else I should post this question? Thanks, Teun van Berkel Philips Research Nat.Lab., WY 5.015a Eindhoven, The Netherlands ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
