[Discuss-gnuradio] Question on signal processing block: input buffer size
Hi All, Anyone know how many bytes a signal processing block can buffer at the input before an overflow occurs? --Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about USRP2 transmitter with OFDM packet.
Hi, One weeks ago I downloaded OFDM program (modified for USRP2, from Veljko Pejovic ) and tested with it. I got a problem when I used USRP2 to transmit OFDM packets. When I transmit continuous OFDM signals the receiver only receive some pieces of packet. So I tried to test with one packet. Size of my (modulated, cp added)OFDM packet is about 90KB(default ofdm parameters, fft size 512, occupied tones 200,packet size 400, etc). First I saved one OFDM packet in a file. Then I used GRC to read this packet content from file and send it to USRP2 sink.(Just one packet). Center frequency 2.4GHz( with XCVR2450) At last I used GRC to receive packet with another USRP2, and record the received samples. It seems that the USRP2 transmitter could not send the whole OFDM packet properly. With interpolation/decimation rate 32, the receiver could see about first 30% of OFDM packet. With interpolation/decimation rate 16 and 8, about 70% of the OFDM packet is received...With interpolation rate 14 the OFDM packet is broken into 2 pieces... I also found that no matter what interpolation rate is used, the OFDM tx program just send data to USRP2 at same data rate, which seems unreasonable. After all, it seems that if main program send ethernet packages too fast, USRP2 tx buffer will be overflowed and the transmit signal will be lost. Is it true? If so, what is size of tx buffer in USRP2? Is it possible to control the ethernet data rate so that the tx buffer in USRP2 is not overflowed? Please give some advices, all replies are appreciated! Thank you! Liang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to remove/suppress gr_buffer::allocate_buffer: warning:
Hello Martin, I will check my code to find out why it is so big. Is there an easy way to somehow suppress this warning in case I am willing to ignore it? Johannes 2011/6/17 Martin Braun : > On Fri, Jun 17, 2011 at 03:42:07PM +0200, Johannes Schmitz wrote: >> I am getting the following warning when running my script: >> >> gr_buffer::allocate_buffer: warning: tried to allocate >> 4 items of size 88192. Due to alignment requirements >> 32 were allocated. If this isn't OK, consider padding >> your structure to a power-of-two bytes. >> On this platform, our allocation granularity is 4096 bytes. >> >> Can somebody tell me how to solve this problem or suppress this warning? >> >> I found it has to do something with fft-size that is not power of 2.. > > Buffers between blocks are always an integer multiple of the > item-size (in your case 88192) and 4096. The LCM of 88192 and 4096 > is pretty large, and tadaa, you get a warning. > > It's just a warning. If everything works fine... just ignore it. But > it's a waste of memory. If you want to optimize this, change your > itemsize. You will normally have to adapt the way the data is handled, > e.g., you could pad the input to 90112=22*4096 and then discard > 90112-88192=1920 Bytes of every input vector. > > Personally, I usually just ignore it, since it rarely turns up in less > unusual applications. > > MB > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Help: CIR measurement problems using usrp_sounder.py
On Jun 15, 2011, at 4:51 PM, Johnathan Corgan wrote: > On Wed, Jun 15, 2011 at 00:22, Martin Braun wrote: > > IIRC, the bottom line was that no, gr_sounder is not really useful. In > particular, it has no means of synchronisation and therefore the result > is too noіsy to be useful. > Should I interpret this that gnuradio_sounder.py in fact is unusable in its current state ? Or is there is some easy way or fix to actually get some relevant CIR:s out of it? > Reimplementing this application as a custom FPGA build for the E and N series > USRPs and the UHD, with synchronization, is "on the list." > > Johnathan That should be very usable and raise the interest of GnuRadio for many I believe. I hope its "high on the list" :-) Rickard___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to remove/suppress gr_buffer::allocate_buffer: warning:
I am getting the following warning when running my script: gr_buffer::allocate_buffer: warning: tried to allocate 4 items of size 88192. Due to alignment requirements 32 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. Can somebody tell me how to solve this problem or suppress this warning? I found it has to do something with fft-size that is not power of 2.. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UCLA ZigBee install on Win
Hi, I would like to ask you if anybody could install Ucla Zigbee on Windows OS? The problem is that I don't really know how it has to be installed and I couldn't find any article about this only some ideas regarding the installation on Linux. Somehow I will understand the code for CC1000 transceiver (that is quite complicated with so many C++ and .py files) and I hope I will be able to modify it for a different transceiver that also is using FSK modulation but different packet structure and different data-rate and frequency. How I hate source code that's not commented or it has no description. Anyway the biggest problem is that I don't know how to integrate this ucla source code into gnuradio and I would really appreciate any help. I wish everybody a very nice day. Best regards, Pascal.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Maximum Frequency Hopping speed of the Ettus Transceiver RF frontends
Dear Matt Ettus, I have noticed that I can modify the member function: usrp2_source_base::set_center_freq(double frequency, usrp2::tune_result *tr) by replacing the default: usrp2::impl::transmit_cmd_and_wait(void *cmd, size_t len, pending_reply *p, double secs) with the version without any waiting time: usrp2::impl::transmit_cmd(void *cmd_, size_t len_) In this way the "set frequency" call seems to return in about 10us, so almost immediately. My first question is that if using "transmit_cmd" could generate problems when changing frequency at a Bluetooth hopping rate (1600 hops/s or 625us). I've read that the XCVR2450 MAXIM2829 RF transceiver provides a CHANNEL-SWITCHING FREQUENCY SETTLING time (page 17 in the datasheet) of about 25/30us (maybe I can even tolerate some frequency error in the Bluetooth case so that it can be considered shorter). The second question is how can I estimate the minimum delay required to reach the PLL when a transmit_cmd is called? I was wondering if I can consider the PLL lock process started when the transmit_cmd(...) is being called in the modified set_center_freq (...) member function. If yes, I could wait for the PLL to lock with little error on the next frequency hop (30us), plus the time to process the set frequency command (200us ?) without any return (the already measured 400us delay / 2 = 200us, I guess). Is that correct? Best Regards, Sergio Benco > On 06/10/2011 06:15 AM, Sergio Benco wrote: >> >> Dear all, >> >> I've read on the Ettus transceiver daughterboards datasheet that the >> PLL lock time is around 200us, which makes it suitable for some FH >> systems (eg. Bluetooth). > > > Having worked on Bluetooth systems in the past, I can tell you that > 200us would be marginal at best for hopping time. > > I've tried to measure this time (plus any other >> possible latency between the Host and the USRP2) by timestamping a >> sequence of "set_center_freq()" calls that swaps between two different >> frequencies (2.412 GHz and 2.413 GHz) many times in a top_block run >> (using only C++, not Python). >> >> The resulting measured time values are around 400us using a USRP2 + >> XCVR2450 and a quadcore host. >> >> 1) How was the 200us time value measured? > > This is the time between when the PLL starts the frequency change to > when it is finished. It is highly variable, and affected by numerous > settings in the chip. > >> 2) Is it possible to obtain a sustained hopping rate of 1/200us? > > Probably not when the hopping is initiated from the host. > >> 3) If yes, how can we get that value? >> > > > Initiate the hopping on the device. This will take some FPGA work on > your part. > > Matt > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
