[Discuss-gnuradio] mblock update
I've merged the work-in-progress on mblocks + the usrp inband signaling stuff into the trunk as of r5221. The "standalone mblock" stuff is effectively done, and is usable in its current state. By "standalone" I mean all mblocks, no combinations of flow graphs and mblocks. Still remaining are: * finishing the host and FPGA work for inband signaling * gluing mblocks and flow graphs together in the same system If you're interested in seeing what mblocks look like, there are some examples in the QA code that show fairly typical usage (but are of course contrived tests). I'd suggest looking at: mblock/src/lib/qa_bitset.cc: examples of mblock composition and INTERNAL, EXTERNAL and RELAY ports. mblock/src/lib/qa_disconnect.cc: examples of reconfiguration "on the fly" mblock/src/lib/qa_timeouts.cc: examples of one-shot and periodic timeouts The primary include files are: mblock/src/lib: mb_runtime.h mb_mblock.h mb_port.h mb_message.h Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_correlate_access_code_bb question
Dan Halperin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, Sorry to bring up painful memories :). I did some calculations to work out frequency drift of the USRPs, and I wanted to know where I'm going wrong. The crystals in the RFX 2400 are spec'ed at 50ppm error, which is to say that the maximum frequency offset between the sender and receiver is then 2 * 50 ppm * 2.462 GHz (802.11b Channel 11) = 246.2 kHz. 246.2 kHz sampled at 64 MHz is 246.2 kHz * 2pi / 64 MHz which is approximately 0.02417 radians / sample. At, say, DBPSK 250kbps, oversampled by a factor of 2, that means we decimate by 128 (500 ksamples per second), to then get at most ~3.094 radians per sample drift. With DBPSK this could flip all of our bits! Does that mean we in fact do need to worry about the case where the complement of the access code is detected? Is my understanding of the meaning of ppm error wrong? Does the distribution we assume for the frequency offset make this possibility negligible? No it means you have to estimate the carrier frequency offset and remove it, even in DBPSK. You do this by using the access code to find the frequency offset and the differentially detect it. Thanks! - -Dan Bob -- AMSAT Director and VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP, QRP ARCI, QCWA, FRC. ARRL SDR WG Chair "If you're going to be crazy, you have to get paid for it or else you're going to be locked up." Hunter S. Thompson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_correlate_access_code_bb question
On 5/1/07, Dan Halperin <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, Sorry to bring up painful memories :). I did some calculations to work out frequency drift of the USRPs, and I wanted to know where I'm going wrong. The crystals in the RFX 2400 are spec'ed at 50ppm error, which is to say that the maximum frequency offset between the sender and receiver is then 2 * 50 ppm * 2.462 GHz (802.11b Channel 11) = 246.2 kHz. I think 50ppm is a total drift of the 64MHz oscillator, so no +/- just 50ppm being the max deviation between two crystals. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr_correlate_access_code_bb question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, Sorry to bring up painful memories :). I did some calculations to work out frequency drift of the USRPs, and I wanted to know where I'm going wrong. The crystals in the RFX 2400 are spec'ed at 50ppm error, which is to say that the maximum frequency offset between the sender and receiver is then 2 * 50 ppm * 2.462 GHz (802.11b Channel 11) = 246.2 kHz. 246.2 kHz sampled at 64 MHz is 246.2 kHz * 2pi / 64 MHz which is approximately 0.02417 radians / sample. At, say, DBPSK 250kbps, oversampled by a factor of 2, that means we decimate by 128 (500 ksamples per second), to then get at most ~3.094 radians per sample drift. With DBPSK this could flip all of our bits! Does that mean we in fact do need to worry about the case where the complement of the access code is detected? Is my understanding of the meaning of ppm error wrong? Does the distribution we assume for the frequency offset make this possibility negligible? Thanks! - -Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGN+uOy9GYuuMoUJ4RAoGqAKDQEPs1o5BtCEsfMo4PLm9zLh09CwCeIi/8 9wr0qg+XJ2dexNuIRPr0tgw= =8wIA -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU make extension corrections?
On May 1, 2007, at 3:44 PM, Eric Blossom wrote: "In the process of" OK. No problem. I'm not sure if we'll be able to get rid of the warnings. I think they're coming from automake, but I haven't confirmed that. I just tried the bootstrap commands individually and, yes, it's automake. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU make extension corrections?
On Tue, May 01, 2007 at 03:07:49PM -0400, Michael Dickens wrote: > I noticed that in ticket:142 < http://www.gnuradio.org/trac/ticket/ > 142 >, which is part of the "GNU make extensions" issue of this > email, the end result is: > " * status changed from assigned to closed. > * resolution set to wontfix. > GNU make has become a required tool." > > I haven't changed the way I'm doing the bootstrap, and am still > getting these messages ... yet the compile still works [0] on OSX, so > in what way has "GNU make" become a required tool, or is it in the > process of? Thanks! - MLD "In the process of" I'm not sure if we'll be able to get rid of the warnings. I think they're coming from automake, but I haven't confirmed that. > [0] At least for the GNU make extension found in gr-trellis, so I > presume it also would for gr-qtgui, though I haven't gotten the > dependencies to compile just yet so I don't know this for a fact. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU make extension corrections?
Michael Dickens wrote: > I haven't changed the way I'm doing the bootstrap, and am still getting > these messages ... yet the compile still works [0] on OSX, so in what > way has "GNU make" become a required tool, or is it in the process of? It was decided that we would not change things to avoid using the existing GNU Make extensions that are in gr-trellis and gr-qtgui. So nothing has changed in the code, only in policy :-) -- 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] GNU make extension corrections?
I noticed that in ticket:142 < http://www.gnuradio.org/trac/ticket/ 142 >, which is part of the "GNU make extensions" issue of this email, the end result is: " * status changed from assigned to closed. * resolution set to wontfix. GNU make has become a required tool." I haven't changed the way I'm doing the bootstrap, and am still getting these messages ... yet the compile still works [0] on OSX, so in what way has "GNU make" become a required tool, or is it in the process of? Thanks! - MLD [0] At least for the GNU make extension found in gr-trellis, so I presume it also would for gr-qtgui, though I haven't gotten the dependencies to compile just yet so I don't know this for a fact. On Apr 17, 2007, at 2:39 PM, Johnathan Corgan wrote: I'll take care of these, but please enter it in Trac. Michael Dickens wrote: Now that gr-qtgui is back, I again get the 3 "comments" when bootstrapping from there, as well as 1 from gr-trellis (which has been all along). Can someone correct this (I've written before about it), or should I enter it into Trac as a low-priority fix? I'm sure it's something simple, but I won't be able to get to it for at least 1.5 weeks. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QE: Cognitve radio network with USRP
Heskamp, M. (Marnix) wrote: > Can someone give me some advice about building a wireless network with > USRP boxes? How difficulty is it to build a MAC layer on top of a USRP > physical layer? Has someone have experience with that? What order of > magnitude is the average latency between the moment the signal is at the > antenna and the moment you can act upon it in software? The GNU Radio software currently has an example implementation of a CSMA MAC that allows multiple USRPs to be configured as network cards sharing a common frequency. This allows, for example, binding a TCP/IP stack and using traditional networking applications over the radio. > We are considering to buy some USRPs to experiment with in our cognitive > radio project. The goal of the project is to set up a wireless network > as secondary users without interfering with primary users. This is certainly feasible. -- 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] QE: Cognitve radio network with USRP
Hello, Can someone give me some advice about building a wireless network with USRP boxes? How difficulty is it to build a MAC layer on top of a USRP physical layer? Has someone have experience with that? What order of magnitude is the average latency between the moment the signal is at the antenna and the moment you can act upon it in software? We are considering to buy some USRPs to experiment with in our cognitive radio project. The goal of the project is to set up a wireless network as secondary users without interfering with primary users. Thank you, Marnix Heskamp ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sin and COS wave form's both are the same!!!!!
when I load the my code it doesn't mater which waveform I chose, I still get a sin wave on the scope. I send two signals from the two TX basic board's, one is Sin and the other is COS. when I still get two SIN signals!! only the when I connect the two out singles from one TX board to the scope I get sin and cos, but these are the I and Q singles. did any one tried to doe this, and have it actually working? please help thanks. Anmar -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
