[Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
Hi, i am trying to calculate at what sampling rate does the tx_sampless.cc and rx_streaming samples.cc are sending the data (file). from 1 USRP2 to another USRP2. i am setting interpolation as 16 at transmitter side (tx_samples.cc) and decimation rate of 16 at receiver side (rx_streaming_samples.cc) according to formula what i have learnt from WEB is Tx Side : Sampling Rate = DAC rate/ Interpolation rate; Rx Side : Sampling Rate = ADC rate/ Decimation rate; are the above equation are correct for determining the sampling rate Thank You Regards KRISHNA S The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] sampling rate of tx_sampless.cc and rx_streaming_sampless.cc
Krishna S wrote: Hi, i am trying to calculate at what sampling rate does the tx_sampless.cc and rx_streaming samples.cc are sending the data (file). from 1 USRP2 to another USRP2. i am setting interpolation as 16 at transmitter side (tx_samples.cc) and decimation rate of 16 at receiver side (rx_streaming_samples.cc) according to formula what i have learnt from WEB is Tx Side : Sampling Rate = DAC rate/ Interpolation rate; Rx Side : Sampling Rate = ADC rate/ Decimation rate; are the above equation are correct for determining the sampling rate Thank You Regards KRISHNA S Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://in.rd.yahoo.com/tagline_ie8_new/*http://downloads.yahoo.com/in/internetexplorer/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Yes, it is the sample-rate on the host-side. DAC rate and ADC rate is 100MHz. BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to add c++ modules after gnuradio-3.2.2. binary installation?
Hi, I reinstalled the system and now it worked. I have managed to run qa_howto.py successfully after binary installation inside the gr-howto... directory. My new question is How can I add new functions and modules using c++ files based on gnuradio-3.2.2 ? For example, there are howto_square2.(h, cc) function in src/lib. I tried to introduce howto_square3.(h, cc) by simply copying howto_square2.(h, cc), and I modified the codes with correct names and classes. I then modified makefile.am and howto.i in src/lib by mimicking declarations of howto_square2.(h, cc), and square2_ff and added declarations of howto_square3.(h, cc), and square3_ff. Finally I make, make check. In make check step, the system gave error below, ImportError: /usr/lib/python2.6/dist-packages/gnuradio/_howto.so: undefined symbol: _Z21howto_make_square3_ffv FAIL: run_tests Could you help solve this problem or give me a general guideline? Thank you. Yao * Hi I installed gnuradio-3.2.2. Binary package in Ubuntu 9.04. It was not flexible to include new c++ files (I could not find bootstrap, configure.ac files etc in usr/share/gnuradio installation directory). I then downloaded gnuradio-3.2.2.tar.gz and gr-howto-write-a-block-3.2.2.tar.gz files and unzipped them in my home folder, and gr-howto-write-a-block-3.2.2 was included as a subdirectory in the gnuradio-3.2.2 directory. I used installation commands ./bootstrap, ./configure, make, sudo make install in gnuradio-3.2.2 directory, and no error was reported. I then tried to run file qa_howto.py (after chmod +x qa* ) in directory gr-howto-write-a-block-3.2.2/src/python, as follows: ./qa_howto.py Error was reported that in import howto, howto module could not be recognized. I tried many other means, including modifying makefile.am in several directories, and using installation ./bootstrap, ./configure, make, sudo make install in gr-howto-write-a-block-3.2.2 directory. No error was reported. But still ./qa_howto.py could not work. Questions: 1) How can I make this work? 2) How can I add new functions and modules using c++ files based on gnuradio-3.2.2 binary installation? Thank you. Jack * Axel Belliard wrote: Hi I'm interrested by reading the message about adding C++ block into old module, but the link is broken. Can you repost the link or the message? Cordialy ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/Re%3A-How-to-add-c%2B%2B-modules-after--gnuradio-3.2.2.-%09binary-installation--tp28066518p28161662.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] benchmark tx and rx help
Hello.. I'm trying to make dbpsk modulation using benchmark tx/rx(two usrp1s(RFX 1800) and two computers).I set costas alpha to 0.05 and gain mu to 0.001 as advised here.When i run the codes i got ok=True for all packages and pktno increases one by one every packet is received properly.But i couldn't understand where can i see the bits that are received(1 or 0).Is the code writing received packages to a file? there is an option in benchmark_tx like --from-file but i couldn't decide how can i create a file that can be seen by code(what will be the extension of the file?) Best regards..Merve İngilizce seviyenizi ücretsiz test edebilirsiniz. Tıklayınız ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp issue
Hello, I've problem with USRP. Since I've upgraded my Ubuntu to 9.0.4 - usrp doesn't work: /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored Testing 2MB/sec... usrp: failed to write fpga hash slot usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Invalid or incomplete multibyte or wide character usb_control_msg failed: error sending control message: Invalid or incomplete multibyte or wide character usb_control_msg failed: error sending control message: Protocol error usrp: failed to reset tx and/or rx path usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Cannot send after transport endpoint shutdown usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error sending control message: No such device usb_control_msg failed: error
Re: [Discuss-gnuradio] Scanning whole spectrum using TVRX
Hope this also helps http://www.ruby-forum.com/topic/169964#new If you are building a temepest/van eck phreaker, I like to join too :) Regards Sreeraj R http://conzole.net/sree_blog/ From: Anand Padmanabha Iyer ai...@ece.iisc.ernet.in To: discuss-gnuradio@gnu.org Sent: Tue, 6 April, 2010 7:26:18 PM Subject: [Discuss-gnuradio] Scanning whole spectrum using TVRX Dear All, I have a TVRX board, and am trying to do some experiments with it. My requirement is to scan the entire spectrum (50MHz - 860MHz), and dump the samples for processing using MATLAB. At a time, I am sensing 250KHz of spectrum (decimation 256), and I am collecting 10,000 samples (40 ms sensing time). My initial take was to call usrp_rx_cfile.py multiple times, each time passing in a different frequency. However, this approach takes around 15 minutes to scan the entire range (I assume it is due to the overheads). Is there any way I could make this faster? Regards, Anand Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! http://downloads.yahoo.com/in/internetexplorer/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Dayton SDR forum speakers sought
On Friday, May 14, I am the moderator (and speaker) at the SDR forum at the 2:30 PM - 5 PM session. I have two speakers (Scotty on openhpsdr, and I speak on general SDR topics). I need to fill out this time and this leaves at least 1.5 hours to fill. I would like to get this settled as soon as possible. Let me know if you are interested in making a presentation. Also, FYI, I will be the AMSAT/TAPR banquet speaker on Friday night. In addition to my forum, SDR, paper delivery with Joel Harrison, work in Flex booth, etc. this will be one of the busiest Dayton's for me in years. I look forward to seeing many of you. Bob McGwier N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- Did you see my previous post about the accelerator PCIe card? To some extent the Microsoft approach is what we're doing. But we want to stay compatible with USRP2 hardware so we connect GbE to the accelerator card; non MAC-related dataflow is PCIe from there. Buffering required to stay compatible with USRP2 software and high, sustained transfer rates moves right, to the accelerator card (which has a lot of memory). Interesting, I didn't see this post. I tried doing some googling for it but I couldn't turn up with it. What was the subject of the post? Here is the archive copy: http://lists.gnu.org/archive/html/discuss-gnuradio/2010-03/msg00481.html The real trick is software. Our approach is that MAC-related code still appears in GNU radio source, but is marked with pragmas (first something specific to our project, then OpenCL, then OpenMP) so that code actually runs on the accelerator card (the TI multicore CPUs on the acclerator card run arbitrary C/C++ code so they're not limited like an Nvidia or other GPU). We plan to use our GNU radio interface to test results of a server acceleration project we're doing for DoE. That's the long story... right now our short-term objective is the GbE-to-GbE USRP2 connection. So right now you're trying to get low latency, but high throughput, between two USRP2's connected directly via GbE? So you're not using the frontend? No, one USRP2 connected to the accelerator card (which is PCI or PCIe). We want to stay as compatible as possible with all USRP2 hardware. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
George- What I got from your paper is that the matched filter approach for fast packet detection would not work in an OFDM setting. What about fast ACK generation? Would it require an IFFT implementation on the USRP? Would it help much? It's a good question, and something I haven't explored, and I'm not much of a DSP guy. So, I'll punt the question to everyone else who has more DSP experience than me. Both are all about signal detection, both the fast-packet detection and fast ACK generation. So what you want to do is first detect the preamble in the USRP without decoding (because it's complex and takes long). So, we propose using a matched filter on the USRP to detect the packet preamble. In 802.11ab, the preamble was done with BPSK (even if the data is sent using OFDM in 802.11a). With 802.11g, it can be a full OFDM preamble. So, with a full OFDM preamble, you can still detect it with a matched filter, but I'm a little unclear about how to generate the coefficients. You essentially are detecting in the time domain with the matched filter. It might require an IFFT on the USRP... anyone? Dan? :) This all said... I really think we need a better interface to reduce latency. Some platforms take the: run on the board approach, such as WARP which puts the MAC on a core on the board. Good luck conjuring up $10-15k just for a single WARP board plus frontends though :P Is there anything that would prevent GNUradio developers to push the MAC layer functionality on the USRP? The USRP and USRP2, from what I understand, are both tight for space in the FPGA. I'm pretty confident you can't fit an OFDM implementation on the USRP. There are free multipliers and space on the USRP2, but I think it would also be tight, leaving you with not much room for the MAC. Then, you'd be building the MAC in verilog which sucks. Most people who want to do MAC development have CS backgrounds, not EE backgrounds, form which Verilog is black magic ;) To cover a wide range of MAC layer standards at fast RF data rates, some type of processing element is required in the front-end data flow; i.e. before the x86 server. One way is an embedded processor core in the FPGA that runs C code and has a library of useful stuff (matched filtering, iFFT, etc) that look like basic function calls, but are implemented as parallel structures in FPGA logic, outside the processing core. C/C++ code calls the function, waits some number of clock ticks or gets a callback, and it's done (well, more or less). This approach both abstracts the FPGA logic to the C/C++ programmer and gives the FPGA more flexibility (i.e. reduces the number of applications where people need to reprogram the FPGA). I would guess that between Matt and NI guys they're planning (if not already started) on developing a more powerful version of the USRP2, with larger FPGA. My understanding is that Matt originally chose Spartan-3 because it was Xilinx's highest performance FPGA (with reasonable chip cost) that would still allow developers to use WebPACK. Evidently he had to move to S-3 2000 for more capacity, although WebPACK only supports up to S-3 1500. That means that GNU radio users who want to modify the FPGA already need the paid for Xilinx ISE tools... and I can tell you from experience that Xilinx holds its tools in high regard and charges accordingly. For these reasons -- not to mention competition from people like Lyrtech and Sora, maybe something NI guys pay more attention to than Matt -- a USRP2 with Virtex 5 or 6 starts to make sense. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Marcus- On 04/06/2010 09:44 PM, John Gilmore wrote: Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. Simple test. Core 2 Duo system, 2.33GHz, Fedora 11. A 1500 byte ping test to localhost yields an average RTT of about 33usecs. That tests most of the network stack except for hardware interfaces, and gives you some notion of best case for latency/turn-around time. If MACs have requirements that are more aggressive than 20-50usec turnaround time, then relying purely on software in a running general-purpose operating system, even on relatively-good hardware may be optimistic. I think there is no way to avoid that MAC-related processing has to be done prior to the server motherboard. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
John- Which part of the Linux issue... sustained throughput or latency? I wouldn't be surprised to find that latency hasn't improved substantially because it's not a priority for server software. Even VoIP applications are not concerned about a 1 msec improvement... whereas that makes or breaks a wireless MAC. I know that in the early days of Linux development, David Miller spent a lot of time making sure that the Ethernet layer could reliably send and receive more than 1 MByte/sec via TCP over 10 megabit Ethernet, and more than 10 MBytes/sec over TCP on 100 megabit Ethernet. I watched his measurements and his kernel evolve to make it happen (learning from and improving on Van Jacobson's early work making 68000-based Sun-2's move 1MByte/sec over TCP on original Ethernet). You might say, That's only 90%, surely he can do better, but that's 90% of the raw bit rate, delivered flow controlled and error-free at the TCP socket layer (all the overhead, from interframe spacing to preambles to CRCs to packet headers, goes in the 10%). As you might expect, pumping the data through required keeping all parts of both systems working in overlap. One packet being assembled to transmit, one received packet being picked apart, and one packet flying on the medium, at all times. If these two software jobs can both run in one packet time, you win (and don't need much if any buffering, keeping latency very low). These code paths were heavily scrutinized and optimized for the common cases. I haven't kept track of who's measuring Linux kernel GigE thruput recently. Here's a pointer to a 2001 study: http://www.csm.ornl.gov/~dunigan/netperf/bulk.html Most people care about TCP speed, but making fast paths for TCP usually makes even faster paths for the UDP packets that USRP2 will be using soon. I can believe Linux Ethernet handling is fast and gets faster all the time... but with most of the emphasis on throughput. I'm still looking for studies that focus on latency; i.e. turn-around time (or RTT), and use recent Linux and motherboards. Probably such data is harder to find becuase in most applications (over long routes), improving RTT at the motherboard + kernel level won't be worth the effort. -Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp issue
On Wed, Apr 7, 2010 at 8:03 AM, voipas voi...@gmail.com wrote: Hello, I've problem with USRP. Since I've upgraded my Ubuntu to 9.0.4 - usrp doesn't work: /usr/local/share/gnuradio/examples/usrp/usrp_benchmark_usb.py Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exceptions.AttributeError' ignored Testing 2MB/sec... usrp: failed to write fpga hash slot usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error usb_control_msg failed: error sending control message: Protocol error Protocol error from USB generally indicates a low level error. Do you have any other USB devices attached (hubs, webcams, etc.)? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
Dear All, Regarding MAC layer development I would like to empasize on the importance of time-stamps. With time-stamps we can at least do slotted schemes. Maybe non-slotted schemes can be approximated by slotted ones ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MAC layer development and USRP2
On Wed, Apr 7, 2010 at 4:54 PM, Per Zetterberg per.zetterb...@ee.kth.sewrote: Dear All, Regarding MAC layer development I would like to empasize on the importance of time-stamps. With time-stamps we can at least do slotted schemes. Maybe non-slotted schemes can be approximated by slotted ones ? Hi Per, I'm not sure what you're attempting to do, and if you're tried the USRP1 inband timestamps, but I do have a slotted scheme I am looking for someone to test: http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg23432.html While I say anyone interested in build? I have one ready for someone to help test: https://www.cgran.org/browser/projects/cmu_macs/trunk/src/lib/tmac.cc#L109 Imagine a basestation and a client in the network. Therefore you have 2 slots per round. With the MAC, you specify the slot time and the guard time, and then when you run it, the client uses the timestamp when the basestation's beacon was received to determine how to align its own slots. It uses a TX timestamp to align its transmissions very tightly. I was able to achieve microsecond level guard bands. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Not sure if this got through the first time, as I never received it
myself. Apologies if this is a double post.
-Original Message-
From: Ian Holland
Sent: Wednesday, 7 April 2010 1:51 PM
To: discuss-gnuradio@gnu.org
Subject: Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the referenced paper, where mm_error
corresponds to mu(k) in eqn. (8). However, if I have interpreted this
correctly, what is implemented is actually:
\mu(k) = Real{[p(k) - p(k-2)] \times \hat{c}^{*}(k-1) - [\hat{c}(k) -
\hat{c}(k-2)] \times p^{*}(k-1)},
whereas eqn. (8) in the referenced omMM paper, is actually:
\mu(k) = Real{[\hat{c}(k) - \hat{c}(k-2)] \times p^{*}(k-1) +
\hat{c}^{*}(k-1) \times [p(k) - p(k-2)]}
Have I missed something here? Are these lines of code not meant to
implement eqn (8) as I suspected?
Thanks
Ian.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question regarding gr_mpsk_receiver_cc::mm_error_tracking
Hi Ian,
I think the code is correct. Eqn. (8) in the referred paper is wrong.
However, Fig. 1 in the paper is right, and the gnuradio code is exactly
the same as Fig.1.
Kyle
Date: Wed, 7 Apr 2010 13:51:10 +0930
From: Ian Holland ian.holl...@rlmgroup.com.au
Subject: [Discuss-gnuradio] Question regarding
gr_mpsk_receiver_cc::mm_error_tracking
To: discuss-gnuradio@gnu.org
Message-ID:
993f95453ddc3643b662c62d8d2d4ed501946...@srv013.rlmgroup.com.au
Content-Type: text/plain; charset=us-ascii
Hi All
I am trying to understand how the optimised modified Mueller and Muller
algorithm is implemented in GNU Radio.
I had a look at the method gr_mpsk_reciever_cc::mm_error_tracking, to
see how this is done. As far as I can tell, lines 242-245 are intended
to implement equation (8) of the referenced paper, where mm_error
corresponds to mu(k) in eqn. (8). However, if I have interpreted this
correctly, what is implemented is actually:
\mu(k) = Real{[p(k) - p(k-2)] \times \hat{c}^{*}(k-1) - [\hat{c}(k) -
\hat{c}(k-2)] \times p^{*}(k-1)},
whereas eqn. (8) in the referenced omMM paper, is actually:
\mu(k) = Real{[\hat{c}(k) - \hat{c}(k-2)] \times p^{*}(k-1) +
\hat{c}^{*}(k-1) \times [p(k) - p(k-2)]}
Have I missed something here? Are these lines of code not meant to
implement eqn (8) as I suspected?
Thanks
Ian.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt, Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look at the right place. Could you please point me in the right direction ? From forum discussions over the past couple of months it appears that USRP2 does not support the 10/100 mode. Could you please help us understand the work effort involved in getting the 10/100 mode working ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark tx and rx help
Hi Merve, benchmark_rx.py only extracts the first two bytes of the received data payload[0:2], which contains the packet number (pktno) and ignores the rest. You need to insert some code into the function 'rx_callback' [line 61-70] in order to show or use the rest of data, payload[2:]. Kyle -- Hello.. I'm trying to make dbpsk modulation using benchmark tx/rx(two usrp1s(RFX 1800) and two computers).I set costas alpha to 0.05 and gain mu to 0.001 as advised here.When i run the codes i got ok=True for all packages and pktno increases one by one every packet is received properly.But i couldn't understand where can i see the bits that are received(1 or 0).Is the code writing received packages to a file? there is an option in benchmark_tx like --from-file but i couldn't decide how can i create a file that can be seen by code(what will be the extension of the file?) Best regards..Merve ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem in usrp2 reception in high non whole frequencies
I am trying to get GSM data at band 1800 (about 1800Mhz). and I discovered that something goes wrong when I use the USRP2 to down-convert at non whole frequencies. (eg 1810.2Mhz). It works only in whole ones (eg 1810Mhz) does any body else know this? I also want to ask if the complex samples are linear in range. because I saw that when you increase the gain, they don't go more than about 2, and reach there non linearly. If it's not linear, does anyone know the formula? -- View this message in context: http://old.nabble.com/problem-in-usrp2-reception-in-high-non-whole-frequencies-tp28173789p28173789.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] Overrun Underrun False packets issues on Gnuradio using Beagle Board
Hello, I have a Beagle Board running Gnuradio(3.2.1). I copied the gnuradio-examples folder from Gnuradio (3.2.2) on the Beagle Board (BB). When I run the usrp_benchmark_usb, I get a maximum throughput of 4MB/sec, instead of 32MB/sec on my regular Linux desktop. Here is my problem: On the Beagle Board, I am getting lots of dropped packets, most false packets, u0 and uU when running benchmark_tx/rx, and tunnel.py. My first assumption is that I have a USB bottleneck. Am I correct? I have tried to resolve these problems using a few options so far: Option 1. Reducing the rate (I modified the gnuradio examples files accordingly), so I am pretty sure I am reducing the rate of transmission. [The verbose statements for Requested bit rate and Actual bitrate are the same]. That did not resolve my problems. Why? Option 2. Changing buffer size. I am trying to tweak the buffer size(by modifying fusb_block_size and nblocks) , but I do not know how to check that the change actually occured in realtime. (a) Where can I find the real value of the realtime buffer size so I can print it in verbose. I tried to trace it down, but eventually hit a wall. (b) How do you think I can change the buffer size and rate in order to satisfy a maximum throughput of 2MB/sec and still get reliable data? (c) I know that buffer size is B*N, where B is a multiple of 512 bytes. I also know that a large N can cause latency, but I want to disregard any latency issues for now. Will I resolve anything by changing B and N? I have attempted a few combinations of B, N and rate, still no solutions. Any suggestions to resolve these issues are welcome. Thanks, Jeannette ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: interfacing a DSP array card to USRP2
Matt- About Vikram's 10/100 mode question, we were wondering if it's a design flaw; i.e. something wrong from the start in the original opencores.org source, or if it's fixable but hasn't been a high priority item given USRP2's high data rate requirements. But then I found this post: http://www.ruby-forum.com/topic/143084 So I guess the former. If there are any hints you can give on what's wrong, we can take a look. Maybe our guys can get it working. -Jeff Thank you for your email. The mac is all contained in simple_gemac, and above that in simple_gemac_wrapper: http://code.ettus.com/redmine/ettus/projects/fpga/repository/revisions/master/show/usrp2/simple_gemac simple_gemac_wrapper in the fifo_2clock_cascade files. which is instantiated in u2_core. Most of the buffering happens in I would just start with the u2_core and simple_gemac_wrapper. If you're not using the SERDES, that is a good place to start ripping out. Does this imply that we can pull out the aeMB core, the 32K RAM and the buffer pool under module u2_core ? To carry out preliminary testing we need to be able to pass data to the gemac and configure appropriate control registers. Could you please suggest what existing modules we could reuse to send data to the gemac ? 3) Do you have an FPGA internal achitecture block diagram of any type? Is there another group you're aware of doing such major modification FPGA work that we might talk to? There were some on the wiki at one time. If they're not still there I'll post a talk I did which covers the architecture. I have looked at the wiki (http://gnuradio.org/redmine/wiki/gnuradio), however i was not able to find any block diagrams for the internal architecture of the FPGA for USRP2. I still might not be look at the right place. Could you please point me in the right direction ? From forum discussions over the past couple of months it appears that USRP2 does not support the 10/100 mode. Could you please help us understand the work effort involved in getting the 10/100 mode working ? Thanks and Regards, Vikram. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Progress (NOT!) on Sheeva Plug Gnu Radio
I managed to get GRC up. But when I try to run an application that uses anything graphic, it segfaults, and dumps core, from deep within libdricore.so -- related to OpenGL, I think? So, rip out the GUI stuff. Use my 4-channel audio-type SID receiver without any GUI goop: Continuous aOaOaOaOaO until I interrupt it. The audio_to_file.py example seems to work, though :-) -- 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] Progress (NOT!) on Sheeva Plug Gnu Radio
On Wed, Apr 7, 2010 at 21:55, Marcus D. Leech mle...@ripnet.com wrote: But when I try to run an application that uses anything graphic, it segfaults, and dumps core, from deep within libdricore.so -- related to OpenGL, I think? So, rip out the GUI stuff. You can turn off OpenGL rendering by config file, see the README.gl in gr-wxgui. On your system it's probably just using libmesa, which is a pure host software based emulation of OpenGL anyway. As far as audio, check out what sample rates the ALSA driver supports on that hardware. It's probably substituting some other rate from what you asked for, and that's why you're getting audio overruns. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
