[Discuss-gnuradio] Is it possible to buy a RFX900 without the filter?
Hi, I read the discuss-gnuradio list and know that I need to bypass the filter with a capacitor and cut away the filter. I would like to know if it is possible to get a RFX900 which has removed the filter when I order it. I might burn the board if I do this by myself. The capacitor is so small and I don't think I can solder the small capacitor on the RFX900. I don't have tools. I don't know what the proper way is to cut the trace and solder the capacitor. Thank you, Jhon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] half duplex operation
Hi everyone, I am trying to implement a transmitter receiver handshake in which the transmitter first sends a 'Ready to send' and the receiver upon receiving it sends a 'Clear to send' back. After this the TX is supposed to send data and RX is supposed to receive it which they are not being able to do. I have tried using a single antenna with auto tr mode enabled. I have also tried to use two separate antennas at different frequencies however none of these work. I would appreciate it if someone could guide me regarding this. Thanks a lot everyone. Regards Neha Kochar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Symbol rates. USRP2 vs USRP1
To confirm, you were able to receive 802.11b using the USRP2? On Wed, Apr 22, 2009 at 5:57 PM, Doug Geiger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Colby Boyer wrote: > > What changes did you have to make to the sample/baud rate? > > > > How high is high SNR? 10dB? 15dB? > > > > I can only establish communication within simulation. When I try to > > transmit stuff over the air, it fails. > > > > I was transmitting with a USB WiFi dongle about 3 feet away and getting > successful packet decoding with some initial success (I've been putting > off getting back to that part of my project, so I don't have much useful > information about measured SNR, etc.) and I was occasionally picking up > packets from another laptop in the same room. As I understand it that's > about the same performance that the original code did with the USRP1 - > so we ought to be able to better. > For the samples/baud, it depends on the decimation rate: but since > 802.11 uses a 1Mbaud/s symbol rate before spreading (either DBPSK for > 1Mbps, or DQPSK for 2Mbps), at -d 4 that ends up being 25 symbols/baud, > 20 sym/baud at -d 5, etc. > Doug > > - -- > Doug Geiger > Research Assistant > Communications and Signal Processing Lab > Oklahoma State University > doug.gei...@gmail.com > doug.gei...@ieee.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.10 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAknvvRMACgkQPJjTsCiwNz5/EQCePFIFoLxCmDEEBym/pcZjTwBO > VVEAn0S9sPJhacmw4eHGshRK5iAKwoB5 > =GGJO > -END PGP SIGNATURE- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Sending output of dbpsk modulator block into the air
Hello all, I was wondering how to transmit the complex samples from the dbpsk modulator block into the air so that another USRP can receive it with the usrp_source_c() block? -- Dumezie Maduike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about the antenna VERT2450
Matt Ettus wrote: > > Bill, > > The short answer is that there is no answer to your question. > > The long answer is that noise temperature is a function of where you > point the antenna, and the ambient noise environment. It is also not > normally specified for low gain antennas, only for dishes and the like. > > I would suggest that you read the Wikipedia article on noise temperature. > > Matt > Even for dishes, you have to factor in the feed assembly as well (a dish with a 15dB edge taper feed will have a lower spillover noise than one with the standard 10dB edge taper). Ground noise should only be a problem due to spillover, and a mesh surface that isn't well-matched to the wavelength of interest. The ground is a blackbody radiator with an equivalent noise temperature of about 300K, and how much of this noise leaks into your feed determines what the effective noise temperature is of a parabolic reflector antenna. A feed with an aggressive edge taper, and a good solid-surface dish should push the ground noise down to under 5K. For a low-gain antenna, it just isn't relevant. The antenna "sees" all noise sources within its 3dBi "torus". It's rather similar for amplifiers in the HF bands. The ambient noise temperature is so high (100,000K) in HF that specifying the noise temperature of the amplifier just isn't meaningful. -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about the antenna VERT2450
Hi, Matt I have read that Wiki article and got it! The noise temperature of that antenna could be ignored. Thank you! Bill From: Matt Ettus To: Bill Stevenson Cc: discuss-gnuradio@gnu.org Sent: Wednesday, April 22, 2009 8:01:48 PM Subject: Re: [Discuss-gnuradio] a question about the antenna VERT2450 Bill, The short answer is that there is no answer to your question. The long answer is that noise temperature is a function of where you point the antenna, and the ambient noise environment. It is also not normally specified for low gain antennas, only for dishes and the like. I would suggest that you read the Wikipedia article on noise temperature. Matt Bill Stevenson wrote: > Hello, Erric > > Could you tell me the effective noise temperature for VERT2450? I have > searched the mailing list, but there is no answer for it. Thank you! > > Bill > > > *From:* Bill Stevenson > *To:* discuss-gnuradio@gnu.org > *Sent:* Tuesday, April 21, 2009 6:48:34 PM > *Subject:* [Discuss-gnuradio] a question about the antenna VERT2450 > > Hello, > > I have a simple question about the antenna effective noise temperature for > VERT2450. Does anybody know its effective noise temperature? Thanks a lot! I > hope Ettus could let me know. > > Thanks! > > Bill > > > > > > ___ > 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] KD7LMO Killed while bicycling
Martin: the news was disgusting, not the post. Don Martin DvH > > On Wed, 2009-04-22 at 12:10 -0600, Don Latham wrote: >> DISGUSTING!!! >> > The news itself, or the fact that I posted this to the mailinglist. > > I have no intention of offending anyone. > > Best Regards, > > Martin Dudok van Heel > >> Martin DvH >> > I am sorry to bring you this sad news. >> > >> > I found this information on: >> > http://groups.yahoo.com/group/Ballooning/message/2810 >> > >> > "KD7LMO Killed while bicycling >> > We have received word that Michael Gray, KD7LMO, was killed Sunday, >> > April 12, while bicycling to visit his parents. This occurred about >> > 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial >> > information was that he was bicyling with two friends, when he was >> > struck from behind by a drunk driver ." >> > >> > Many Gnuradio users used his OTA (of-the-air) capture files on >> > >> > http://www.kd7lmo.net/ground_gnuradio_ota.html >> > >> > This allowed them to start playing with Gnuradio without the need of >> an >> > USRP. >> > >> > The website seems to be down now. >> > >> > Michael Gray was active with ballooning with ANSR (Arizona Near Space >> > Research) >> > >> > He will be missed. >> > >> > Martin Dudok van Heel >> > >> > >> > >> > >> > >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> >> > -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] KD7LMO Killed while bicycling
Martin: sorry, most assuredly the news. Your post was timely and well-received. Sorry not to be clear :-) Don Martin DvH > > On Wed, 2009-04-22 at 12:10 -0600, Don Latham wrote: >> DISGUSTING!!! >> > The news itself, or the fact that I posted this to the mailinglist. > > I have no intention of offending anyone. > > Best Regards, > > Martin Dudok van Heel > >> Martin DvH >> > I am sorry to bring you this sad news. >> > >> > I found this information on: >> > http://groups.yahoo.com/group/Ballooning/message/2810 >> > >> > "KD7LMO Killed while bicycling >> > We have received word that Michael Gray, KD7LMO, was killed Sunday, >> > April 12, while bicycling to visit his parents. This occurred about >> > 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial >> > information was that he was bicyling with two friends, when he was >> > struck from behind by a drunk driver ." >> > >> > Many Gnuradio users used his OTA (of-the-air) capture files on >> > >> > http://www.kd7lmo.net/ground_gnuradio_ota.html >> > >> > This allowed them to start playing with Gnuradio without the need of >> an >> > USRP. >> > >> > The website seems to be down now. >> > >> > Michael Gray was active with ballooning with ANSR (Arizona Near Space >> > Research) >> > >> > He will be missed. >> > >> > Martin Dudok van Heel >> > >> > >> > >> > >> > >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> >> > -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resource busy error:
On Wed, 2009-04-22 at 18:47 -0500, kollimarla bhargav wrote: > > Thanks a lot Martin, that solved our problem, now we are able to call > another reciever code in benchmark_rx.py .One last question we tried > to call benchmark_rx.py from usrp_spectrum_sense.py, but still we get > the same error "Resource busy" > It seems that another top block other than tb is running in > usrp_spectrum_sense.py This might have to do with: self._tune_callback = tune(self)# hang on to this to keep it from being GC'd GCing (Garbage collecting) is exactly what we want here. There is a kind of circular reference here so the tb keeps existing I would try: tb._tune_callback.tb=None tb._tune_callback=None tb.u=None tb=None Good luck, Martin > > thanks > bhargav > > > > On Wed, Apr 22, 2009 at 5:54 PM, Martin DvH > wrote: > > On Wed, 2009-04-22 at 17:41 -0500, kollimarla bhargav wrote: > > Hi all, > > We are trying to run a simple receiver program > using > > benchmark_rx.py. The problem we are facing is when we try to > run > > another receiver program like usrp_spectrum_sense.py inside > the > > benchmark_rx.py using os.system() command , the error is " > Device or > > Resource busy". We get a feeling that the thread from > benchmark_rx.py > > is still running. We even used thread.stop before calling > > usrp_spectrum_sense.py, but this did not work, the same > error message > > popped up. Is there any other way of exclusively kill the > thread and > > call another receiver program.??? > > We are able to call a benchmark_tx.py transmitter code in > > benchmark_rx.py receiver code, > > This is logical. > The TX part of the USRP can be used seperately from the RX > part. > The RX part is still in use so it can't be used for a new > receiver. > > but the combination of calling any program with a reciever > block from > > benchmark_rx.py was not successful and we got a error > message > > "Resource busy ". Is this a thread issue?? > > Appreciate any help!! > > > > Your receiver chain still exists, even if it is not running. > This keeps the RX part of the USRP in use. > > Did you instruct the topblock to stop and wait for it to > finish. > > If you did, you could try after stopping the topblock. > > tb.rxpath=None > > or even > tb = None > > This throws away the reference to the receive_path (which > keeps the RX > part of the USRP in use and thus 'Resource Busy'.) > > Martin > > > Thanking you > > bhargav > > > > > > ___ > > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 eth_buffer
Hi all ext file system is the go, with my high speed digitizer I stream 250 MB/s (thats bytes) to a six disk raid (0) array. The raid zero is the go if you can afford to loose data in the unlikely event of a disk failure. Bruce - Original Message - From: Eric Blossom Date: Thursday, April 23, 2009 8:04 am Subject: Re: [Discuss-gnuradio] USRP2 eth_buffer To: j...@sgo.fi Cc: "discuss-gnuradio@gnu.org" , Johnathan Corgan > On Wed, Apr 22, 2009 at 11:06:19PM +, Juha Vierinen wrote: > > > Try setting your application to run using real-time scheduling > > > priority. This is done in C++ via a call to: > > > > > > gr_enable_realtime_scheduling() > > > > I am using this. > > Juha, > > What kind of filesystem are you using? I've never been able to stream > reliably to disk using the ext3 filesystem. I think it chokes when > posting its journal. I have been successful when mounting an ext3 > filesystem as an ext2 filesystem. > > I've got a RAID 10 system using 6 drives plus 1 hot spare. > > Eric > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] remove the ISM band filter (RFX900)
Hi, http://www.gnuradio.org/trac/wiki/OpenBTS/DesktopTestingKit said that the ISM band filter on the RFX900 will need to be removed, as described in the wiki link. However, I don't find any information about how to remove the ISM band filter in the wiki link. I read the discuss-gnuradio list and know that I need to bypass the filter with a capacitor and cut away the filter. Does it mean I need to remove the filter FIL1 and put a 100pf capacitor on C204? Sorry for this basic question. I am new in this field. Thank you, Jhon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] remove the ISM band filter (RFX900)
Hi, http://www.gnuradio.org/trac/wiki/OpenBTS/DesktopTestingKit said that the ISM band filter on the RFX900 will need to be removed, as described in the wiki link. However, I don't find any information about how to remove the ISM band filter in the wiki link. I read the discuss-gnuradio list and know that I need to bypass the filter with a capacitor and cut away the filter. Does it mean I need to remove the filter FIL1 and put a 100pf capacitor on C204? Sorry for this basic question. I am new in this field. Thank you, Jhon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.2-RC2 Build failure
Jonathan, Just to confirm that you are correct. I copied gnuradio/pmt/src/scheme/gnuradio/macros-etc.scm from the trunk into RC2 and it builds just fine. Now to make sure my code will work on 3.2! Regards, Steve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 eth_buffer
On Wed, Apr 22, 2009 at 11:06:19PM +, Juha Vierinen wrote: > > Try setting your application to run using real-time scheduling > > priority. This is done in C++ via a call to: > > > > gr_enable_realtime_scheduling() > > I am using this. Juha, What kind of filesystem are you using? I've never been able to stream reliably to disk using the ext3 filesystem. I think it chokes when posting its journal. I have been successful when mounting an ext3 filesystem as an ext2 filesystem. I've got a RAID 10 system using 6 drives plus 1 hot spare. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] a question about the antenna VERT2450
Bill, The short answer is that there is no answer to your question. The long answer is that noise temperature is a function of where you point the antenna, and the ambient noise environment. It is also not normally specified for low gain antennas, only for dishes and the like. I would suggest that you read the Wikipedia article on noise temperature. Matt Bill Stevenson wrote: Hello, Erric Could you tell me the effective noise temperature for VERT2450? I have searched the mailing list, but there is no answer for it. Thank you! Bill *From:* Bill Stevenson *To:* discuss-gnuradio@gnu.org *Sent:* Tuesday, April 21, 2009 6:48:34 PM *Subject:* [Discuss-gnuradio] a question about the antenna VERT2450 Hello, I have a simple question about the antenna effective noise temperature for VERT2450. Does anybody know its effective noise temperature? Thanks a lot! I hope Ettus could let me know. Thanks! Bill ___ 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] a question about the antenna VERT2450
Hello, Erric Could you tell me the effective noise temperature for VERT2450? I have searched the mailing list, but there is no answer for it. Thank you! Bill From: Bill Stevenson To: discuss-gnuradio@gnu.org Sent: Tuesday, April 21, 2009 6:48:34 PM Subject: [Discuss-gnuradio] a question about the antenna VERT2450 Hello, I have a simple question about the antenna effective noise temperature for VERT2450. Does anybody know its effective noise temperature? Thanks a lot! I hope Ettus could let me know. Thanks! Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resource busy error:
Thanks a lot Martin, that solved our problem, now we are able to call another reciever code in benchmark_rx.py .One last question we tried to call benchmark_rx.py from usrp_spectrum_sense.py, but still we get the same error "Resource busy" It seems that another top block other than tb is running in usrp_spectrum_sense.py thanks bhargav On Wed, Apr 22, 2009 at 5:54 PM, Martin DvH wrote: > > On Wed, 2009-04-22 at 17:41 -0500, kollimarla bhargav wrote: > > Hi all, > > We are trying to run a simple receiver program using > > benchmark_rx.py. The problem we are facing is when we try to run > > another receiver program like usrp_spectrum_sense.py inside the > > benchmark_rx.py using os.system() command , the error is " Device or > > Resource busy". We get a feeling that the thread from benchmark_rx.py > > is still running. We even used thread.stop before calling > > usrp_spectrum_sense.py, but this did not work, the same error message > > popped up. Is there any other way of exclusively kill the thread and > > call another receiver program.??? > > We are able to call a benchmark_tx.py transmitter code in > > benchmark_rx.py receiver code, > This is logical. > The TX part of the USRP can be used seperately from the RX part. > The RX part is still in use so it can't be used for a new receiver. > > but the combination of calling any program with a reciever block from > > benchmark_rx.py was not successful and we got a error message > > "Resource busy ". Is this a thread issue?? > > Appreciate any help!! > > > Your receiver chain still exists, even if it is not running. > This keeps the RX part of the USRP in use. > > Did you instruct the topblock to stop and wait for it to finish. > > If you did, you could try after stopping the topblock. > > tb.rxpath=None > > or even > tb = None > > This throws away the reference to the receive_path (which keeps the RX > part of the USRP in use and thus 'Resource Busy'.) > > Martin > > > Thanking you > > bhargav > > > > > > ___ > > 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] Symbol rates. USRP2 vs USRP1
What changes did you have to make to the sample/baud rate? How high is high SNR? 10dB? 15dB? I can only establish communication within simulation. When I try to transmit stuff over the air, it fails. On Wed, Apr 22, 2009 at 3:16 PM, Douglas Geiger < doug.gei...@bioradiation.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Colby Boyer wrote: > > Hi all, > > > > As some of you know, I am working on porting the BBN 802.11b code to the > > USRP2. I understand that the ADC/DAC rates are higher than the USRP1. > What > > are the effects, if any, on the rate at which symbol are sent through the > > air? I am suspect that this could be the reason I cannot decode sent > > packets. > > > > Colby > > > > Main change I had to do when I was working on it was the samples/baud. I > only had it recognizing very high SNR 1 and 2Mbps packets. > Doug > > - -- > Doug Geiger > Research Assistant > Communications and Signal Processing Lab > Oklahoma State University > http://cspl.okstate.edu > douglas.gei...@okstate.edu > doug.gei...@ieee.org > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Cygwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFJ75c/gfOzzR5bXIgRAmHfAJ4iANMn3cFMUJRXH6+3jtYS0+7DmQCeL7or > RdX3Vm2+66ESDf+TB+yxcsY= > =Okof > -END PGP SIGNATURE- > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 eth_buffer
> Try setting your application to run using real-time scheduling > priority. This is done in C++ via a call to: > > gr_enable_realtime_scheduling() I am using this. > We use the Linux kernel packet ring method of receiving packets from > sockets. This is a speed optimized method that maps memory in such a > way that the kernel sees it as kernel memory and the user process sees > it at its own memory, so there is no copying from kernel to user > space. It also lets us receive multiple packets with one system call. > (At full rate, we process about 50 packets per system call.) > > The kernel maintains a ring of pointers to pending packets, and these > ring descriptors must be stored in one kernel memory region. These > memory regions are of MAX_SLAB_SIZE, and each descriptor is > sizeof(void*). So the tp_block_nr variable calculates the number of > possible packets by dividing the buffer length by the block size, and > if that is more than can be stored in MAX_SLAB_SIZE, it reduces it to > the limit that imposes. Doesn't this apply only for pre 2.6.5 and 2.4.26 kernels? At least that is what the Documentation/networking/packet_mmap.txt says. BTW, shouldn't the MAX_SLAB_SIZE should be 131072 instead of 131702? > So you probably aren't using all 500 MB of that memory. You can > uncomment the debug printf in that part of code to see the number of > blocks actually allocated. I think I'm using it all. I removed the MAX_SLAB_SIZE constraint and it still works in mmaped mode. The setsockopt still succeeds and the data looks ok. > What tends to happen if you aren't running your user process as RTPRIO > is that the libusrp2 driver grabs the packets from the kernel okay, > but your flowgraph doesn't read them from the driver fast enough, and > you get backed up into an overflow. This is exactly the problem. On average the disk bandwidth is more than enough, but there are fairly large "hiccups" that cause the buffer to overrun. I could try to write my own buffer, but that would be one extra memory copy, I'd prefer a large kernel-space buffer to a large user space buffer. juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Resource busy error:
On Wed, 2009-04-22 at 17:41 -0500, kollimarla bhargav wrote: > Hi all, > We are trying to run a simple receiver program using > benchmark_rx.py. The problem we are facing is when we try to run > another receiver program like usrp_spectrum_sense.py inside the > benchmark_rx.py using os.system() command , the error is " Device or > Resource busy". We get a feeling that the thread from benchmark_rx.py > is still running. We even used thread.stop before calling > usrp_spectrum_sense.py, but this did not work, the same error message > popped up. Is there any other way of exclusively kill the thread and > call another receiver program.??? > We are able to call a benchmark_tx.py transmitter code in > benchmark_rx.py receiver code, This is logical. The TX part of the USRP can be used seperately from the RX part. The RX part is still in use so it can't be used for a new receiver. > but the combination of calling any program with a reciever block from > benchmark_rx.py was not successful and we got a error message > "Resource busy ". Is this a thread issue?? > Appreciate any help!! > Your receiver chain still exists, even if it is not running. This keeps the RX part of the USRP in use. Did you instruct the topblock to stop and wait for it to finish. If you did, you could try after stopping the topblock. tb.rxpath=None or even tb = None This throws away the reference to the receive_path (which keeps the RX part of the USRP in use and thus 'Resource Busy'.) Martin > Thanking you > bhargav > > > ___ > 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] Resource busy error:
Hi all, We are trying to run a simple receiver program using benchmark_rx.py. The problem we are facing is when we try to run another receiver program like usrp_spectrum_sense.py inside the benchmark_rx.py using os.system() command , the error is " Device or Resource busy". We get a feeling that the thread from benchmark_rx.py is still running. We even used thread.stop before calling usrp_spectrum_sense.py, but this did not work, the same error message popped up. Is there any other way of exclusively kill the thread and call another receiver program.??? We are able to call a benchmark_tx.py transmitter code in benchmark_rx.py receiver code, but the combination of calling any program with a reciever block from benchmark_rx.py was not successful and we got a error message "Resource busy ". Is this a thread issue?? Appreciate any help!! Thanking you bhargav ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Symbol rates. USRP2 vs USRP1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colby Boyer wrote: > Hi all, > > As some of you know, I am working on porting the BBN 802.11b code to the > USRP2. I understand that the ADC/DAC rates are higher than the USRP1. What > are the effects, if any, on the rate at which symbol are sent through the > air? I am suspect that this could be the reason I cannot decode sent > packets. > > Colby > Main change I had to do when I was working on it was the samples/baud. I only had it recognizing very high SNR 1 and 2Mbps packets. Doug - -- Doug Geiger Research Assistant Communications and Signal Processing Lab Oklahoma State University http://cspl.okstate.edu douglas.gei...@okstate.edu doug.gei...@ieee.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ75c/gfOzzR5bXIgRAmHfAJ4iANMn3cFMUJRXH6+3jtYS0+7DmQCeL7or RdX3Vm2+66ESDf+TB+yxcsY= =Okof -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 eth_buffer
On Wed, Apr 22, 2009 at 1:48 PM, Juha Vierinen wrote: > I have been trying to get 25 MHz to disk with USRP2. I am using the > C++ interface and a five disk software raid 0 that can do about 150 > MB/s. I can easily run at 25 MHz with a simple nop_handler that only > checks for underruns and timestamps continuity, but when I write to > disk, I can barely do 10 MHz for longer than 30 s without overruns. I > have tried just about every filesystem with the same result every > time. Try setting your application to run using real-time scheduling priority. This is done in C++ via a call to: gr_enable_realtime_scheduling() or from Python: gr.enable_realtime_scheduling() Check the return value to ensure that it worked, it should == gruel::RT_OK from C++ or in python gr.RT_OK. You must have permission to do this, either by virtue of running as root, or by allowing your user/group to do so by adding a line to /etc/security/limits.conf: @usrp - rtprio 50 Then add your username to the 'usrp' group (which needs to be created if it doesn't already exist.) > Why is there a (int)(MAX_SLAB_SIZE/sizeof(void*)) limit? We use the Linux kernel packet ring method of receiving packets from sockets. This is a speed optimized method that maps memory in such a way that the kernel sees it as kernel memory and the user process sees it at its own memory, so there is no copying from kernel to user space. It also lets us receive multiple packets with one system call. (At full rate, we process about 50 packets per system call.) The kernel maintains a ring of pointers to pending packets, and these ring descriptors must be stored in one kernel memory region. These memory regions are of MAX_SLAB_SIZE, and each descriptor is sizeof(void*). So the tp_block_nr variable calculates the number of possible packets by dividing the buffer length by the block size, and if that is more than can be stored in MAX_SLAB_SIZE, it reduces it to the limit that imposes. So you probably aren't using all 500 MB of that memory. You can uncomment the debug printf in that part of code to see the number of blocks actually allocated. What tends to happen if you aren't running your user process as RTPRIO is that the libusrp2 driver grabs the packets from the kernel okay, but your flowgraph doesn't read them from the driver fast enough, and you get backed up into an overflow. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP2 eth_buffer
Hi, I have been trying to get 25 MHz to disk with USRP2. I am using the C++ interface and a five disk software raid 0 that can do about 150 MB/s. I can easily run at 25 MHz with a simple nop_handler that only checks for underruns and timestamps continuity, but when I write to disk, I can barely do 10 MHz for longer than 30 s without overruns. I have tried just about every filesystem with the same result every time. The reason seems to be lack of buffering. I have gone with the easiest path of increasing the eth_buffer from approximately 25 MB to 500 MB. I know people will flame me for using this much kernel memory, but it seems to work fairly reliably (I have been saving 25 MHz to a five disk software raid already for an hour without problems). I think there should be a user configurable option similar to fusb_blocksize and fusb_nblocks with usrp1, which defines the eth_buffer size. I am willing write a patch if somebody is interested, but I don't fully understand why there is a MAX_SLAB_SIZE in eth_buffer.cc: // Calculate number of blocks req.tp_block_nr = std::min((int)(MAX_SLAB_SIZE/sizeof(void*)), (int)(d_buflen/req.tp_block_size)); Why is there a (int)(MAX_SLAB_SIZE/sizeof(void*)) limit? juha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Symbol rates. USRP2 vs USRP1
Hi all, As some of you know, I am working on porting the BBN 802.11b code to the USRP2. I understand that the ADC/DAC rates are higher than the USRP1. What are the effects, if any, on the rate at which symbol are sent through the air? I am suspect that this could be the reason I cannot decode sent packets. Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Increase transmit power on the USRP2?
Hi all, Is it possible to increase the TX power of the 2.4 GHz cards or is it fixed? Thanks, Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX Problem
Yeah I figured that out just after I sent the email. Thanks for the feedback though! On Wed, Apr 22, 2009 at 1:53 PM, Eric Blossom wrote: > On Wed, Apr 22, 2009 at 10:54:12AM -0400, Matthew Dolloff wrote: >> I'm having a problem creating a GUI. I'm trying to bind an event to a >> button but when i bind the event, the callback is called immediately. >> I'm not sure what the heck is happening. Any help would be greatly >> appreciated. if you look at the code below you can see that the >> callback is getting called immediately. >> >> #Code Snippet >> >> def _create_Gui (self, vbox): >> self.myform = myform = form.form() >> >> hbox = wx.BoxSizer(wx.HORIZONTAL) >> hbox.Add((5,0),0) >> >> self.b1 = wx.ToggleButton(self.panel,wx.ID_ANY,"button 1") >> print "1" >> self.b1.Bind(wx.EVT_LEFT_DCLICK, self._setText()) > > self.setText() is a call, that's why it's getting called right away. > Try self.setText [no parens]. > >> print "2" >> hbox.Add(self.b1,1,wx.LEFT | wx.RIGHT ,2) >> >> self.b2 = wx.Button(self.panel,wx.ID_ANY,"button 2") >> hbox.Add(self.b2,1,wx.LEFT | wx.RIGHT ,2) >> vbox.Add(hbox, 0, wx.EXPAND) >> return >> >> def _setText(self): >> print "button pressed" >> self.b1.Show(False) >> return >> >> # Terminal Window Output >> 1 >> button pressed >> 2 >> >> >> ___ >> 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] KD7LMO Killed while bicycling
On Wed, Apr 22, 2009 at 07:33:55PM +0200, Martin DvH wrote: > I am sorry to bring you this sad news. > > I found this information on: > http://groups.yahoo.com/group/Ballooning/message/2810 > > "KD7LMO Killed while bicycling > We have received word that Michael Gray, KD7LMO, was killed Sunday, > April 12, while bicycling to visit his parents. This occurred about > 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial > information was that he was bicyling with two friends, when he was > struck from behind by a drunk driver ." Thanks for posting this. > Many Gnuradio users used his OTA (of-the-air) capture files on > > http://www.kd7lmo.net/ground_gnuradio_ota.html > > This allowed them to start playing with Gnuradio without the need of an > USRP. > > The website seems to be down now. FYI, I've got a static copy of the web site as of a few days ago. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WX Problem
On Wed, Apr 22, 2009 at 10:54:12AM -0400, Matthew Dolloff wrote: > I'm having a problem creating a GUI. I'm trying to bind an event to a > button but when i bind the event, the callback is called immediately. > I'm not sure what the heck is happening. Any help would be greatly > appreciated. if you look at the code below you can see that the > callback is getting called immediately. > > #Code Snippet > > def _create_Gui (self, vbox): > self.myform = myform = form.form() > > hbox = wx.BoxSizer(wx.HORIZONTAL) > hbox.Add((5,0),0) > > self.b1 = wx.ToggleButton(self.panel,wx.ID_ANY,"button 1") > print "1" > self.b1.Bind(wx.EVT_LEFT_DCLICK, self._setText()) self.setText() is a call, that's why it's getting called right away. Try self.setText [no parens]. > print "2" > hbox.Add(self.b1,1,wx.LEFT | wx.RIGHT ,2) > > self.b2 = wx.Button(self.panel,wx.ID_ANY,"button 2") > hbox.Add(self.b2,1,wx.LEFT | wx.RIGHT ,2) > vbox.Add(hbox, 0, wx.EXPAND) > return > > def _setText(self): > print "button pressed" > self.b1.Show(False) > return > > # Terminal Window Output > 1 > button pressed > 2 > > > ___ > 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] error while loading shared libraries
On Wed, Apr 22, 2009 at 10:31 AM, Don Latham wrote: > Sorry, forgot to include that the error occurs during operation. Try doing a 'make distclean', then starting again with the bootstrap step. It looks like you have left overs from a previous make. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] KD7LMO Killed while bicycling
I am sorry to bring you this sad news. I found this information on: http://groups.yahoo.com/group/Ballooning/message/2810 "KD7LMO Killed while bicycling We have received word that Michael Gray, KD7LMO, was killed Sunday, April 12, while bicycling to visit his parents. This occurred about 3:30 P.M. on Maricopa Road near the Maricopa Fire Department. Initial information was that he was bicyling with two friends, when he was struck from behind by a drunk driver ." Many Gnuradio users used his OTA (of-the-air) capture files on http://www.kd7lmo.net/ground_gnuradio_ota.html This allowed them to start playing with Gnuradio without the need of an USRP. The website seems to be down now. Michael Gray was active with ballooning with ANSR (Arizona Near Space Research) He will be missed. Martin Dudok van Heel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error while loading shared libraries
Sorry, forgot to include that the error occurs during operation. ./configure does not end with an error message. In fact, the config.log gives: HAVE_BOOST 1 HAVE_BOOST_THREAD 1 HAVE BOOST_DATE_TIME 1 HAVE_BOOST_PROGRAM_OPTIONS 1 and at end of configure, exit 0 -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] error while loading shared libraries
Apparently configure is asking for libboost_thread-gcc42-mt-d-1_34_1.so.1_34_1 which does not exist in my libraries. I am using 1_35 version of boost. The 1_34 file does indeed not exist. I have 1.35 in /usr/lib and have notified gnuradio via ld.so.conf. Why is configure asking for the older version at all libboost_thread etc for 1.35 is in the library Baffled Don -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 benchmark_rx.py, benchmark_tx.py, transmit_path_usrp2.py, receive_path_usrp2.py, pick_bitrate.py
Hi, Did you try to send and receive packets between 2 USRP2? I tryed but without any result. Are you sure that it's working correctly? I will have a look to the code in more details and tell you if something will work. Ben Yahmed Smith L. wrote: Hi, This is what I get when I run benchmark _tx.py and benchmark_rx.py respectively on USRP2 with transmit_path_usrp2.py and receive_path_usrp2.py respectively: benchmark_tx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_tx.py -f 2400M -v usrp2::ctor reset_db failed usrp2::ctor set_rx_gain failed usrp2::ctor set_tx_interp failed usrp2::ctor set_rx_scale_iq failed gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board 43 Tx amplitude 12000 modulation: gmsk_mod bitrate: 500kb/s samples/symbol:2 interp: 100 Tx Frequency:2.4G ...m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ benchmark_rx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_rx.py -f 2400M -v usrp2::ctor reset_db failed gr_fir_fff: using SSE bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board 39 Rx gain: 35 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim: 100 Rx Frequency:2.4G Now the same thing for usrp1 but using transmit_path.py and receive_path.py which is already provided in gnuradio: benchmark_tx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_tx.py -f 2400M -v gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Flex 2400 Tx MIMO B Tx amplitude 12000 modulation: gmsk_mod bitrate: 500kb/s samples/symbol:2 interp: 128 Tx Frequency:2.4G ...m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ benchmark_rx.py:- m...@mcrl-desktop:~/gnuradio/gnuradio-examples/python/digital$ sudo ./benchmark_rx.py -f 2400M -v gr_fir_fff: using SSE bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board A: Flex 2400 Rx MIMO B Rx gain: 45 modulation: gmsk_demod bitrate: 500kb/s samples/symbol:2 decim:64 Rx Frequency:2.4G I am using the same pick_bitrate.py file that is already provided in gnuradio. As it can be seen that both usrp systems have the default bit rate irrespective of whether it acts as receiver or transmitter. My concern is with the interpolation and decimation. Do I need to make changes to the pick_bitrate.py file for USRP2? If yes, then what kind of changes. I also observed that even though USRP2 shows a bit rate of 500kbps, however I believe that its transmitting too fast which does not allow USRP1 to receive correctly.I would greatly appreciate any help in this matter. Thanks in advance. Smith Eric Blossom wrote: On Tue, Apr 14, 2009 at 01:48:21PM -0700, Smith L. wrote: Hi, I am trying to establish communication between USRP2 and USRP1. I am using RFX2400 daughterboard. I am using Ubuntu 8.10. I am using the svn version of GNU Radio. I dont know the revision number. I am not able to receive anything on USRP2 when USRP1 is transmitting and vice versa. The python codes for USRP2 work perfectly fine. I guess
Re: [Discuss-gnuradio] Gnuradio-3.2rc2 with Ubuntu 9.4 configure problem
On Wed, Apr 22, 2009 at 5:15 AM, Gilbert wrote: > configure failed because, ubuntu packages "python-wxgtk2.8" and > "python-wxgtk2.6" where installed. Removing "python-wxgtk2.6" solved the > issue. Maybe you could change the configure script to detect the newer > one? Our script detects the version that gets used when Python does a 'import wx' (as that is what our relevant Python scripts do), so the system must be configured to use 2.8 as the default. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3.2-RC2 Build failure
On Wed, Apr 22, 2009 at 12:09 AM, Steve Glass wrote: > It looks like macros-etc is needed but my configure seems ok. Am I missing > something obvious and if so what is it? There was a file missing from the distribution tarball. It's really odd this didn't show up in earlier testing or affect other people, but it is fixed now in the trunk. You can copy the file over manually and continue with your testing if you like. Thanks for the bug report. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WX Problem
I'm having a problem creating a GUI. I'm trying to bind an event to a button but when i bind the event, the callback is called immediately. I'm not sure what the heck is happening. Any help would be greatly appreciated. if you look at the code below you can see that the callback is getting called immediately. #Code Snippet def _create_Gui (self, vbox): self.myform = myform = form.form() hbox = wx.BoxSizer(wx.HORIZONTAL) hbox.Add((5,0),0) self.b1 = wx.ToggleButton(self.panel,wx.ID_ANY,"button 1") print "1" self.b1.Bind(wx.EVT_LEFT_DCLICK, self._setText()) print "2" hbox.Add(self.b1,1,wx.LEFT | wx.RIGHT ,2) self.b2 = wx.Button(self.panel,wx.ID_ANY,"button 2") hbox.Add(self.b2,1,wx.LEFT | wx.RIGHT ,2) vbox.Add(hbox, 0, wx.EXPAND) return def _setText(self): print "button pressed" self.b1.Show(False) return # Terminal Window Output 1 button pressed 2 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cycle/period detection of a cyclic/periodic transmitter
Thanks Firas, It is clear and I will implement it and will come back soon hopefully with successfull results. Best Regards Firas A. wrote: > > > Hi, > >> On Wed, 4/22/09, kaleem ahmad wrote: >> >> Thanks Firas, >> >> But I can simply tell that it always transmit a fix packet (with >> bitrate=500kbps) of 1220 micro sec including preamble. It means that >> after every T ms (T is repetition cycle time and can be a fixed >> value from range: 1ms...200ms, I selected 10ms for above given data) it >> transmits a 1220 microsec long signal. >> > > If your transmitter works for 1220 microsec (1.22 msec) and it repeat the > transmission (for example) every 10 msec, then your calculations is wrong. > > If you want to sense the time of a signal, you have to run your FFT frames > with a rate at least equal to required minimum signal time. For example in > your case, If the signal to be detected has a 1.22 msec then you have to > collect the data at rate of 500K (USRP decimation =128). The 512 FFT > length will be 1.024 msec. This means (after using appropriate spectrum > threshold value) you need to count number of FFT frames that the desired > signal is exist in it. > > So, back to our example (signal with duty 1.22msec and repetition of > 10msec), if data rate is 500k, and you used 512 FFT points, then you will > see this signal once in every 10 FFT frames. The resolution will be 1.024 > msec. > > However, if you received the signal with data rate of 8MHz (USRP > decimation =8), and you computed 512 FFT points then your resolution will > be 64 usec, which means that the signal will be ON for 19 FFT frames and > OFF for 137 FFT frames. > > Is that clear ? > > > > Best Regards, > > Firas > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/cycle-period-detection-of-a-cyclic-periodic-transmitter-tp23171564p23175140.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
[Discuss-gnuradio] Gnuradio-3.2rc2 with Ubuntu 9.4 configure problem
Hello, configure failed because, ubuntu packages "python-wxgtk2.8" and "python-wxgtk2.6" where installed. Removing "python-wxgtk2.6" solved the issue. Maybe you could change the configure script to detect the newer one? thx a lot Gilbert Forke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cycle/period detection of a cyclic/periodic transmitter
Hi, > On Wed, 4/22/09, kaleem ahmad wrote: > > Thanks Firas, > > But I can simply tell that it always transmit a fix packet (with > bitrate=500kbps) of 1220 micro sec including preamble. It means that > after every T ms (T is repetition cycle time and can be a fixed > value from range: 1ms...200ms, I selected 10ms for above given data) it > transmits a 1220 microsec long signal. > If your transmitter works for 1220 microsec (1.22 msec) and it repeat the transmission (for example) every 10 msec, then your calculations is wrong. If you want to sense the time of a signal, you have to run your FFT frames with a rate at least equal to required minimum signal time. For example in your case, If the signal to be detected has a 1.22 msec then you have to collect the data at rate of 500K (USRP decimation =128). The 512 FFT length will be 1.024 msec. This means (after using appropriate spectrum threshold value) you need to count number of FFT frames that the desired signal is exist in it. So, back to our example (signal with duty 1.22msec and repetition of 10msec), if data rate is 500k, and you used 512 FFT points, then you will see this signal once in every 10 FFT frames. The resolution will be 1.024 msec. However, if you received the signal with data rate of 8MHz (USRP decimation =8), and you computed 512 FFT points then your resolution will be 64 usec, which means that the signal will be ON for 19 FFT frames and OFF for 137 FFT frames. Is that clear ? Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cycle/period detection of a cyclic/periodic transmitter
Thanks Firas, The transmitter which I want to detect the cycle for (You are correct that I want to find that repitition cycle). I am little bit confused to know what is the duty cycle of it. But I can simply tell that it always transmitt a fix packet (with bitrate=500kbps) of 1220 micro sec including preamble. It means that after every T ms (T is repetition cycle time and can be a fixed value from range: 1ms...200ms, I selected 10ms for ablove given data) it transmitts a 1220 microsec long signal. Is it sufficient??? Could you have a look at code and especially the decimation process and the filter_coefficients??? Best Regards Firas A. wrote: > > > Hi, > >> On Wed, 4/22/09, kaleem ahmad wrote: >> >> Hi All, >> >> I am trying to detect the cycle (or period) time of a cyclic data >> transmitter by sensing the channel. The transmitter can be any general >> e.g. >> FSK/ZigBee/Bluetooth etc, and transmitting a fixed packet after every 'T' >> ms. I am interested to detect this T using GNURadio/USRP. >> > > You info is not enough. > > For a cyclic transmitter there is a transmission duty cycle and repetition > cycle. From what I understand, you are trying to measure repitition cycle. > > But, > > What is the duty cycle of your transmitter (the time it will stay ON)? > > For example, Blue tooth is a frequency hopping device. It hops 1600 > hop/sec. This means the duty cycle for it is 625usec. > > > > > > Best Regards, > > Firas > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://www.nabble.com/cycle-period-detection-of-a-cyclic-periodic-transmitter-tp23171564p23174531.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
Re: [Discuss-gnuradio] cycle/period detection of a cyclic/periodic transmitter
Hi, > On Wed, 4/22/09, kaleem ahmad wrote: > > Hi All, > > I am trying to detect the cycle (or period) time of a cyclic data > transmitter by sensing the channel. The transmitter can be any general e.g. > FSK/ZigBee/Bluetooth etc, and transmitting a fixed packet after every 'T' > ms. I am interested to detect this T using GNURadio/USRP. > You info is not enough. For a cyclic transmitter there is a transmission duty cycle and repetition cycle. From what I understand, you are trying to measure repitition cycle. But, What is the duty cycle of your transmitter (the time it will stay ON)? For example, Blue tooth is a frequency hopping device. It hops 1600 hop/sec. This means the duty cycle for it is 625usec. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cycle/period detection of a cyclic/periodic transmitter
Hi All, I am trying to detect the cycle (or period) time of a cyclic data transmitter by sensing the channel. The transmitter can be any general e.g. FSK/ZigBee/Bluetooth etc, and transmitting a fixed packet after every 'T' ms. I am interested to detect this T using GNURadio/USRP. The idea is to sense the channel with appropriate sampling time/FFT size and then analyze the FFT bin to find the value of T i.e cycle time. The cycle time can be between e.g 1ms...200ms, this corresponds to a frequency range of 1KHz to 5 Hz. So I need a minimum sample rate of 2 K-samples/sec. I am using 3 to have some margin. Now the high-rate data stream is run through a 1.5 KHz low-pass filter (for anti-aliasing) and downsampled to a 3 Ksample/sec rate. A 512 bin FFT now has a resolution of around 5 Hz per bin (mean 512 FFT time resolution is 200 ms). To acheive this I am doing decimation at two levels, one in USRP (with D=256), and then to further reduce the sampling rate I am using gr.fir_filter_ccf, as explained in the following. USRP RF sampling rateAfter decimation with D=256---Second level decimation with gr.fir_filter_ccf 64MHz 64MHz/256=250kHz gr.fir_filter_ccf(125, filter_coeff) = 2k it finally gives me 2ksample/sec-> sample time=500micro sec, which means if I take 512 fft, I will get a time resolution of 500micro sec * 512 = 256 ms, with 500 micr sec distance between consective fft bins. Now suppose a cyclic data transmisster is transmitting with 10ms cycle time, i.e. after every 10ms there is a signal to be detected by my USRP system. >From above calculation 10ms = 500 micro sec * 20It means that in my 512 FFT bin after every 20 bins there should be a peak (Am I correct??? Please note that there is only one transmitter in the area, no other source of interference) In similar way if I choose 75, 50 or 25 for second level decimation by gr.fir_filter_ccf, then I should get a peak after every 33.33, 50, and 100 bins respectively, as explained below. gr.fir_filter_ccf(75, filter_coeff) = 3.33k -> 512 FFT resulution = 300 micr sec -> 10ms = 33.33 bins gr.fir_filter_ccf(50, filter_coeff) = 5k -> 512 FFT resulution = 200 micr sec -> 10ms = 50 bins gr.fir_filter_ccf(25, filter_coeff) = 10k -> 512 FFT resulution = 100 micr sec -> 10ms = 100 bins But unfortunately I am unable to get these results, for example with gr.fir_filter_ccf(125, filter_coeff) I got following results, for few consective scans: To understand these results please not that there are two columns, first is the power level of the peak and the second is the index of it in 512 FFT bin (Only peaks are displayed, and all values with smaller than a predefined threshold value are discarded). Amplitude index_in_512_FFT_array - Scan 1 18.6298904419 74 19.0259571075 75 18.2597370148 87 19.7134284973 88 19.5969486237 101 19.1021556854 114 18.6094284058 149 19.4388046265 161 19.6380805969 162 20.0642223358 174 19.3017559052 175 18.2230033875 187 --- scan 2 21.5638103485 74 21.9744911194 112 23.012506485 125 21.8563117981 126 21.370016098 137 23.2401256561 138 21.655248642 139 22.3047294617 151 --- scan 3 22.1015739441 139 22.8458404541 151 22.8282699585 152 23.0492572784 163 23.7630844116 164 22.387878418 165 22.9494457245 176 22.7077884674 177 --- scan 4 19.5143814087 2 19.4494800568 15 20.1066360474 65 20.4122695923 78 21.3697834015 172 20.4298725128 173 21.0880489349 185 20.013879776 186 --- scan 5 19.0756263733 112 19.4551143646 153 19.4751834869 163 19.4504451752 165 20.5185012817 166 21.0303726196 175 21.0539245605 176 19.145084 177 19.1931247711 178 20.0467262268 188 19.171252 189 --- So you can see that from FFT bin it is impossible to interpret what is the cycle time, when I used 75/50/25 in fir_filter_ccf or if I used FFT lenght different from 512, it was still meaningless and I got similar results. If you like to have a look at my code then it is very short and is attached. If some of you can specially have a look on at least the filter coeefficients and entire decimation process in this code then it will be great help for me, because I am not very good in filter design. Please suggest me what/where is the problem and how can I solve it. Any suggestion to calculate this cycle time in a different way will also be welcomed. Thanks and Best Regards Kaleem http://www.nabble.com/file/p23171564/Cycle_sensing.py Cycle_sensing.py -- View this message in context: http://www.nabble.com/cycle-period-detection-of-a-cyclic-periodic-transmitter-tp23171564p23171564.html Sent from the GnuRadio mailing list archive at
[Discuss-gnuradio] 3.2-RC2 Build failure
Hi, I get the following build error with RC2. Making all in lib make[4]: Entering directory `/home/stevie/src/gnuradio-3.2rc2/mblock/src/lib' GUILE_LOAD_PATH="/home/stevie/src/gnuradio-3.2rc2/pmt/src/scheme:/home/stevie/src/gnuradio-3.2rc2/mblock/src/scheme" /usr/bin/guile -e main -s ../../../mblock/src/scheme/gnuradio/compile-mbh.scm ./qa_bitset.mbh qa_bitset_mbh.cc ERROR: no code for module (gnuradio macros-etc) make[4]: *** [qa_bitset_mbh.cc] Error 1 It looks like macros-etc is needed but my configure seems ok. Am I missing something obvious and if so what is it? All the best Steve -- The highest human happiness is not the exploitation of the present but the preparation of the future. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
