Re: [Discuss-gnuradio] Native Interface between MATLAB/Simulink and USRP available
Hi Enno, If somebody wants to maintain a Linux-Version of simulink-usrp, we could add this as a project on e.g. SourceForge (see below). So if anybody is interested in porting this to Linux _and_ maintaining the Linux-specific parts, please let us know. I already ported it to linux today, however don't want to maintain it. The main change was to use a Makefile (which ideally will be generated by Automake, but isn't till now) and to note that matlab under linux passes strings as characters, not wide characters (to whatever reason). There were a few M$-specific code parts, too. Though no big change was necessary. Thanks for the great program! Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Native Interface between MATLAB/Simulink and USRP available
Hello Enno, Great work! Did you test this with Linux? Are there any plans to support Linux/GCC etc.? Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] update: new FX2 firmware / boosted USB bandwidth
This is a great achievement. I tested it with an old 2GHz P4 laptop (but with good USB controller) and was able to reach about 41MB/sec. The tests were with/without FPGA HB filter in one direction using your pre-built images. Could you try to set different fusb parameters? I observed that, since the FX2 is less likely to be a bottleneck, tuning of these parameters may have greater impact than before. E.g. my laptop did an additional 2 MB/s with B = 16384 and N = 1000 (test_usrp_standard_rx -B 16384 -N 1000 etc.). Thank you for sharing it with us. Thanks for the feedback. Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] update: new FX2 firmware / boosted USB bandwidth
Hi! Well, as I promised, I am going to share my results with the community. So here it is: http://www.dominikauras.de/gnuradio/usrp_fx2.html Condensed into a patch file. I have uploaded a few bitstreams and a binary of the firmware, too. There is some documentation on the site that is mainly intended for people who already have a knowledge of the FX2 etc. I spent much time on verifying, but of course can't promise it is bugfree. So I invite you to review and test it and share your experience. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
It is a saw wave (0-255 per packet, upper 8 bits of each short are zero). Thanks for the info! I will try sending different data this evening. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
Hi! Hmmm. My application is RX-only. Using 8-bit samples, that 45Mb/s gives about 20Msps.I have a QX9770 system running at 3.7GHz, but *still* get overruns at two channels, 8Msps per (complex) channel. I also get overruns at 16Msps, single-channel. You mean, your system doesn't even sustain 32 Mb/s? At 8Msps dual-channel, my application (an all-mode radio astronomy receiver system) burns up about 2.75CPU on the above-mentioned qx9...@3.7ghz (with slower memory that will get upgraded soon!). I get overruns a couple of times per minute with this setup. Could be a problem of your CPU, too. In our lab, our eightcore machine has overruns, while my notebook with a core 2 duo does not. I have figured out that this is because of multiprocessor communication, the eight cores are composed of two quadcore processors, which are themself two dualcores on one die. Restricting the scheduler (taskset 0x11 app) to two cores which reside in the same dual core, it was fine, no overrun. Adding one core, whatever location, and there were overruns. However, before noticing this fact, I had already turned down cpu usage of that specific app (the transmitter) down to two cores by aggressive optimization. What type of system are you getting reliable 45Mb/s receive throughput on, and how complicated is your signal processing flowgraph? C2D E6750, 4 Gb RAM, ICH9 USB Controller I am using test_usrp_standard_rx, no signal processing. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
Hi Eric, Thanks for the answer. It's hard to say. If you've got a logic analyzer you can instrument the inner loop of the firmware and see if that's the bottleneck or not. Unfortunately, I don't have a access to a logic analyer :( However, I made progress that I am going to share once it is tested and cleaned up. Short summary: When doing RX only, I am at 45 Mb/s (yes! decim=6 works without underruns). On the TX side, I can't get above 32.7 Mb/s. Now I suspect that this is a host side bottleneck. On the FX2, if using only one direction, I am setting the GPIF to loop infinitely. With GPIFABORT=0xFF to switch if the state changes. Hence there is no main loop left that could be a bottleneck. The TX state machine now consists of 2 states, where state one is the idle state, and state 2 transferring data (one word per clock, as before). The 8051 core is completely out of the data path. (Auto commit etc.) Same for RX, except that a few more states were needed. When RX and TX are needed, the firmware is still faster, though the same TX bottleneck appears (which is, of course, no big problem because we already share USB bandwidth). Do you have, maybe, an idea why TX bandwidth is limited? Interestingly enough, 32.7 Mb/s is the limit on my computer and my notebook. Of course, I made the tx loop on the host as short as possible, set SCHED_FIFO and rtprio to 49, and played with fusb_nblock/size etc. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] flowstates - FX2
If I have reengineered this correctly (gpif.gpf crashes the current GPIF Designer, importing gpif.c skips the flow states), you set to transfer data at rising AND falling edge while in flow state. Is this correct? I can give the answer to myself ;-) Took a while ... So, data is transferred on the falling and rising edge of master strobe (which is not connected to the FPGA). The half period of MSTB is 1 IFCLK cycle (which is the minimum). Hence, data is actually transferred once per IFCLK cycle (twice per MSTB cycle). MSTB is toggling at 24 Mhz. This gives a data rate of 96 Mb/s (16 bit per IFCLK cycle, which runs at 48 Mhz). IFCLK is generated internally, and output inverted to the FPGA. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
Hi Philip, > http://gnuradio.org/trac/wiki/UsrpFAQ/Gen#USB:480MBitsec32MBytesec http://gnuradio.org/trac/wiki/UsrpFAQ/FX2 We can get beyond. See http://lists.gnu.org/archive/html/discuss-gnuradio/2006-10/msg00340.html Larry achieved 35Mb/s. I got 40Mb/s when receiving. The SSRP sustains more than 40Mb/s on receiver side http://oscar.dcarr.org/ssrp/software/firmware/firmware.php . Also: http://lists.gnu.org/archive/html/discuss-gnuradio/2004-08/msg00011.html So, there are demo firmwares for the FX2 sustaining 50Mb/s (though, I didn't find them, yet). Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FX2 firmware
Hello, I was able to increase the USB bandwidth of the rx chain to 40Mb/s if tx is completely turned off (test_usrp_standard_rx -D 4). However, with test_usrp_standard_tx -i 8, it won't get beyond 32.7 Mb/s. I am ignoring under/overruns for now. Is there a way test wether this is a limitation of my mainboard, the program or the USRP? Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] flowstates - FX2
Hi!
A more specific question on the FX2:
do {\
FLOWSTATE = 0x81; \
FLOWLOGIC = 0x2d; \
FLOWEQ0CTL = 0x26; \
FLOWEQ1CTL = 0x00; \
FLOWHOLDOFF = 0x04; \
FLOWSTB = 0x04; \
FLOWSTBEDGE = 0x03; \
FLOWSTBHPERIOD = 0x02; \
GPIFHOLDAMOUNT = 0x00; \
} while (0)
If I have reengineered this correctly (gpif.gpf crashes the current GPIF
Designer, importing gpif.c skips the flow states), you set to transfer
data at rising AND falling edge while in flow state. Is this correct?
What I have found is:
state 1 is flow state (for both waveforms)
for flowstates:
for fifowr:
if TCXpire and TCXpire then - else WEN, BOGUS
Master Strobe Pin "unused", Half Period 2 (=1 clock)
Holdoff pin ="unused",but holdoff not asserted
for fiford:
if TCXpire and TCXpire then - else REN, OE, BOGUS
everything else not changed from fifowr
DP:
fiford:
if TCXpire and TCXpire then S2 else S1
etc
Btw. there is an application note on flow states (I saw that someone
stated that these are barely documented):
http://www.cypress.com/?rID=12951
Best regards
Dominik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FX2 firmware
Hi all! I am studying the FX2 firmware provided by the USRP package, just to "get a feeling" for this. There are a few very old mails on the mail archive stating that an improvement of the USB bandwidth could be possible if the FX2 timing is tuned. Does anyone know where the current bottleneck is? Is it the main loop, or the GPIF state machine? There was an idea about moving the loop invariant, e.g. one loop only for tx if only tx chain is enabled. However, my first quick'n dirty trial didn't change anything (test_usrp_standard_tx to test). At least it still works :) It will do to point me in a good direction, I'll find out the rest. However, it would be faster if someone can direct me. Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Halfband interpolator stages for FPGA transmit chain of USRP1
Hi GNU Radio community! Because the halfband interpolators are disabled in the current USRP1, I have investigated to reactivate these. However it turned out that it was easier to integrate the new implementation I have found in the USRP2. So I have added the USRP2 halfband interpolators to the USRP1 fpga code base. The result is a new transmit chain with 2 cascaded halfband interpolator stages, each of them using the 31-tap halfband interpolators from USRP2. The included configuration gives an FPGA bitstream that supports one receive chain (w/hb) and one transmit chain with halfband filters. About 96% of the FPGA resources are in use. I have tested the transmit chain with my USRP1s and it worked fine. Please note that all I have done was to merge part of the USRP2 verilog code into USRP1. Except for a few adjustments, there were no big changes. These excellent modules I have reused have been created by Matt et al.!! You find some documentation and the downloads at my site: http://www.dominikauras.de/gnuradio/usrp_txhb.html Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SoftDVB
Hi Vincenzo, May I ask: What is the current state of SoftDVB publishing, is there progress or will this be delayed? Is it still correct that you plan to publish the code of your great implementation that achieves realtime? Thanks in advance for providing the information. Your code will be an excellent inspiration to many people. Best regards, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_siggen.py underruns
Hi! Thanks for your answer. And thanks Frank Brickle, too! Uhh, 12.5 MS/s is 50MB/s (16-bit I&Q across the wire). Sorry, my fault. Yes, there are lots of ways to do this. In this particular case, you're going to want to keep track of the worst case and average run times. Hm run times may not be the appropriate performance measure in my case. The transmitter is of course designed to run continuously (until I interrupt him). What about interarrival times? I once had the idea to record every buffer update with a timestamp, the difference in the number of samples and the current processor the task is running on. Do you think that these samples may help to reveal the reason for the underruns in my transmitter code? Are you really trying to use the Gaussian PRNG? If so you'll have to fix it. If you look at the code for it, you'll see that it samples a distribution until it gets something it likes. The worst case time can be huge. The difference between the USRP1 and the USRP2 is the amount of buffering available in the Tx path in the kernel and on the board. No. Just for the case someone tries to reproduce the odd behavior, usrp_siggen is widely available. You may understand that I can't hand out my transmitter code. I could strip it down to the relevant parts, that reproduce the behavior, but since I don't know what could be the reason, this becomes an undirected search. Simply I hoped that the underruns of the Gaussian PRNG are caused by the same problem. Will a big buffer in the USRP1 probably change the behavior? Am I right that with setting fusb_nblocks etc., the buffer size changes? I have just confirmed that the Gaussian PRNG can't send at a bandwidth of near 8 MHz with the USRP2. That was definitely a bad example. I will try to perform some measurements in the next week. Are there any gnuradio blocks, gnuradio utils available to find the average and worst cases? Oprofile will sample the whole application, not only the link between my last block and the USRP1 sink. For your interest, I was measuring the throughput with a modified gr.throttle block. Instead of delaying the stream, I compute the momentaneous rate/throughput and average with a simple IIR (the rate estimate). Thank you for your help. Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_siggen.py underruns
Hi! An additional note: using usrp_siggen.py with sine, const and uniform at 8 MHz bandwidth actually works. It is unlikely that my EHCI controller does not support 32 MB/s on transmit. Could this be a timing problem? I mean, that the data is generated very fast, but then the generator waits, e.g. because the buffer is full. Does the double buffering of the TPB scheduler work as supposed? Using STS scheduler with usrp_siggen didn't change anything. Summary: The application supports 12.5 complex MS/s (100 MB/s) if using USRP2, but can't sustain 8 complex MS/s with USRP1, even though usrp_siggen.py does support 8 MS/s with the generators sine,const and uniform on the USRP1 (and test_usrp_standard_tx estimates an achievable rate of 32 MB/s). Furthermore, this behavior shows up on 2 different machines. Do you have an idea how I could benchmark the application, e.g. to characterize the stream timing in front of the USRP? Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_siggen.py underruns
Hi! What kind of an EHCI controller do you have? We've come across some that won't support 32MB/s on transmit. http://www.asus.com/products.aspx?modelmenu=1&model=2593&l1=3&l2=179&l3=815&l4=0 Intel X58 chipset on an Asus P6 Deluxe. We are using the onboard controller. test_usrp_standard_tx reports xfered 1.34e+08 bytes in 4.19 seconds. 3.2e+07 bytes/sec. cpu time = 0 0 underruns Identical behavior on another machine, which has Athlon 64 X2 and hence different mainboard and chipset, definitely no Intel chipset. But I am not at the institute and can't tell you the controller name at the moment (but tomorrow, if you need it). Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] usrp_siggen.py underruns
Hi! That won't help. The problem is that the gaussian RNG is really slow. You'll need to figure out how to make it faster. I am sorry. This was an example and I hoped that the RNG is fast enough. Actually, I have observed this behavior with my transmitter. As I described, it doesn't send with 8 MHz bandwidth on USRP1. Before we received the new USRP2s, I have thought that this is a problem of my application. Even though with a nullsink, I have measured a throughput in front of the nullsink of more than 30 MSamples per second. Now with the USRP2, my transmitter is streaming continuously, sending at 12.5 Mhz bandwidth. It keeps up with this rate. There was no change in the transmitter, except for using the USRP2. Conclusion: my code can send with at least 12.5 complex MSamples per second (equal to 12.5 MHz bandwidth), but using USRP1, I can't send with 8 Mhz? Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_siggen.py underruns
Hi! I am currently observing an odd behavior of usrp_siggen.py. When I start the program as follows ./usrp_siggen.py -f 2.40G -i 16 --gaussian there are a lot of underruns (uU). However, for all other signal generation options except gaussian, it works fine (i.e. const, sine, uniform). Just to see, I have modified usrp_siggen to enable realtime scheduling. It didn't make the underruns go away. My /etc/security/limits.conf contains the line @usrp - rtprio 90 as suggested by a recent post to mailing list (though I increased the maximum priority). libgruel realtime functions sets the priority -30 (checked with top). CPU usage is ~ 103%. I have observed a similar behavior with my transmitter system, if I set the bandwidth to 8 MHz, which should be the maximum. To me, it seems like the GnuRadio USRP driver can hardly keep up with this rate (it should be the maximum supported). Measurements without the USRP sink revealed that my transmitter actually sustains rates over 30 MS/s. Though I didn't test what rate the gaussian noise source in usrp_siggen achieves if connected to a nullsink. Further, with the USRP2, my transmitter sends continuously at a bandwidth of 12.5 MHz, no problem. However I need the USRP1 too. My gnuradio version is from the svn trunk, but it's not the latest one. Some revision above 1. If necessary, I could do a test with the latest revision. The program test_usrp_standard_tx reports xfered 1.34e+08 bytes in 4.19 seconds. 3.2e+07 bytes/sec. cpu time = 0 0 underruns My machine is a Core i7 940, 3 Gb RAM. I am using a fresh install of Ubuntu 8.10. The USRP owns his proper USB root hub, i.e. no other devices connected. Hence I think it is unlikely to be caused by the machine. Best regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Improvement to OFDM receiver synchronization code (ofdm_sync_pn)
Hi Kylie, This has also been proposed by Minn et. al in their paper "On timing offset estimation for OFDM systems". They showed that this method also improves the variance of the estimator. The modification is quite simple: R(d) = 0.5 * sum over full window |r(d+m)|^2. I think, normally the correlation power should always be less or equal to the signal power. But if you have very small powers near zero that can't be precisely described with your current operands' bitwidth, the calculated power value may become smaller which yields a ratio greater than 1.0. However, we have never experienced such problems with our OFDM system except for offline debugging scenarios. Over the air, the presence of noise will probably avoid this problem. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Multi-processor scheduler now available for testing
Hi Eric! Very nice work! I have run the synthetic benchmark program on our machine. The scaling is wonderful. It is running almost 8x faster. If you like, I can send you some reports. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiplie top blocks
Hello, This is definitely a defect, I think. It is obstructing useful ways to use GNU Radio for. I did it as said, allowing only one instance to be running, but several to be created. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multiplie top blocks
Hi! During the buildup phase of my gnuradio scripts (in __init__ of classes that inherit from top_block or some classes that are initialized from a topblock instance), I try to use gnuradio to convert some data. E.g. I use gr.fft to do FFT on some constant data, or apply the function of some special blocks to other constant data. With the old hierblock2 etc., that worked fine for me. We've been working with an old gnuradio revision to not break up the system upon changes to the trunk. But now, it is time to get to a newer revision (skipping about 2000 revisions). After porting everything to your new top_block structure, now I encounter the problem that creation of several top blocks is not allowed. Actually, the second or later created topblock should be terminated before the first will be started, but I use the other blocks during setup of the "main" topblock. How can I solve this problem? I don't like to recode so that every initialization is done before creating the main block, since this forces me to have knowledge of internals outside this block. Is there any smart way to have the signal interrupt handler for example just tied to the currently running block, e.g. allowing several top blocks to be created, but only one to be running? Maybe to defer the registering of the handler until start of the implementation. Any suggestions are welcome! Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Writing SIMD code with sse
Hi! I am currently struggling with the memory/cache performance of the most used inner loops in my code. For my code, I am pretty sure that most clock cycles it spends are related to cache miss. I used VTune and Cachegrind to analyze the code. But all I got was the information THAT I frequently miss the cache. They don't give a reason. So, maybe you can point me to a good website, or give me a hint? Is there a program that can tell me why this happens? E.g. for the Cell processor, there is a static analysis tool that tells you everything about your code. When did it stall, why did it stall, how many stall cycles etc. Thanks Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Writing SIMD code with sse
Hi, Just found a small error. You should exchange __builtin_ia32_punpcklwd128(x,x)),16)); __builtin_ia32_punpckhwd128(x,x)),16)); (note the h/l). First ..hwd, then ..lwd. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Writing SIMD code with sse
Hi!
The intrinsics are more or less C wrapper functions for assembler
commands. You can find a detailed description here:
http://www.intel.com/products/processor/manuals/index.htm
SSE1-3 is supported by modern AMD and Intel processors.
There are many possible improvements, but you need to have
processor-specific selection of code.
An example for intrinsics:
typedef float v4sf __attribute__ ((vector_size(16)));
typedef short int v8hi __attribute__ ((vector_size(16)));
typedef int v4si __attribute__ ((vector_size(16)));
v4sf * o = static_cast(buffer->write_pointer());
const v8hi * in = reinterpret_cast(usrp_buffer);
for(i = 0; i < nbytes; i+=16, o+=2, ++in){
const v8hi x = *in;
o[0] = __builtin_ia32_cvtdq2ps(
__builtin_ia32_psradi128(
reinterpret_cast(
__builtin_ia32_punpcklwd128(x,x)),16));
o[1] = __builtin_ia32_cvtdq2ps(
__builtin_ia32_psradi128(
reinterpret_cast(
__builtin_ia32_punpckhwd128(x,x)),16));
}
The code snippet fastly converts the shorts the usrp delivers to floats,
using SSE. Actually, it ignores the endian-order and assumes
little-endian. The buffer size is supposed to be a multiple of 16 bytes.
Dominik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Contribution: ofdm system
Hi, | Is it published anywhere else? No, it is not published. And I have got the permission to publish parts of the code. I.e. if you want to see the code, I will need to move the needed parts into a new project/makefile structure. As we don't use your normal packet transmission scheme (ofdm mod/demod in python etc.), I also need to put the code into that framework. So, as you say that there is chance that you will accept it, I will start to move the code. It will take me some time, since I am going to do this after work and studies. | All of the host code in GNU Radio is copyrighted by FSF, so | if we do incorporate it, there is a copyright assignment | process you'll have to go through. I think this will be possible. Any preferences for the system? Should it use a similar framework as your ofdm example? Directory outside the gnuradio tree, or inside the gnuradio-examples directory? Greetings, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Contribution: ofdm system
Hello, In the last months, we have developed an ofdm system using your gnuradio architecture as part of a research on dynamic resource allocation. Now we like to contribute parts of our code to the gnuradio project. We think that it will be useful to you since it partially employs more advanced techniques than in your example. If you like it, I suggest to add it as an alternative ofdm system. We are using this system on USRPs at revision 4 with daughterboards RFX2400. It is tested, stable and has a good performance in BER and SNR. All hierarchical blocks are using the new style blocks. Here are some facts about the receiver and transmitter: - preamble based timing synchronization The modified Schmidl & Cox algorithm is used to position the sampling window at the first preamble. Only coarse timing synchronization is done. - preamble based frequency offset synchronization Before FFT, the frequency offset, divided into a fractional part and an integer part, will be estimated based on the S&C preamble (also used for timing sync) and a second preamble. Therefore both fine and coarse frequency offset estimation is performed. - preamble based channel estimation The second preamble, used for frequency offset estimation, will be exploited to give an estimate of the current channel state. The fine timing synchronization is absorbed into the channel transfer function (as phase rotation), i.e. compensated for at this place. - pilot tone based sampling frequency offset estimation We insert 8 pilot tones (or subcarriers) to ofdm data blocks. The sampling frequency offset (as phase rotation) and the residual carrier frequency offset is estimated and compensated for. Without SFO compensation, we observed a severe drop of SNIR using the USRPs, especially between two different charges we bought. The current algorithm acquires and tracks the SFO and RCFO within an ofdm frame. - flexible channel estimator The estimator block can easily use several ofdm blocks to estimate the channel transfer function. It will output both the inverse ctf to be fed to the equalizer and the ctf. It uses a simple zero-forcing criteria. The known blocks' positions within the ofdm frame can be freely chosen. For example, we used a midamble in our experiments to mitigate some special problems. - flexible mapper/demapper We created a new ofdm mapper/demapper that allows to assign different signal constellations on different subcarriers. This can be either static or dynamically changed. Please let me know if you want to have more details. If you accept our contribution, I will port the system to use your packet utils and to have it behave like your systems. Please note that the system has a modular design and uses simple gnuradio blocks if possible and useful. Additionally, I personally want to thank you for your great work at the gnuradio project. It is definitely one of the best SDR environments. Greetings, Dominik Auras Chair of Theoretical Information Technology RWTH Aachen University http://www.ti.rwth-aachen.de ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Contribute to the in-band project: profile the code
Hi! Please inform me when you fixed the problem. Then I will retry the profiling. Unfortunately this week I am very occupied. My CPU-type is a Xeon. I am running Linux 2.6.22-14-generic. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Contribute to the in-band project: profile the code
Hi! I have tried to profile your code. First thing I noted: The PMT library from your svn branch had to be installed with sudo make install. Now I installed the whole branch. Next thing: When I run test_usrp_inband_rx, it takes very long time and produces messages: fusb: (rd status -2) No such file or directory These appear after "Closing the USRP". There is cpu usage only after this message, and only one core is used (is that right?). It takes more than 8 minutes, not 40s as in your example in the wiki. Since it appeared to hang, I have interrupted the execution. I followed all instructions, from retrieving the branch up to getting the new RBF file. My USRPs are from revision 4.2. My linux is Ubuntu Gutsy Gibbon. Instead of the linux kernel you specified, I downloaded the source of my kernel. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
AW: [Discuss-gnuradio] oprofile inband code results
Hi! I wonder what PMT is and what is the benefit of PMT? I am not familiar with your current development, except that it will support MAC-layers and stuff like that. It seems very interesting. And it sounds like we will certainly upgrade our system to your mblocks. Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_* not working correctly
Hi! Does "make check" pass on your system when you set it to use SIMD? It would be interesting to know if this error is not found with the standard tests. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RedHat Compatibility
Hi! Does anyone have experiences with GNU Radio and Red Hat Linux? Are there any known problems? Thank you for your answers in advance Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
WG: [Discuss-gnuradio] rev 6467 make problem
Sorry, this should have gone to the list ... | -Ursprüngliche Nachricht- | Von: Dominik Auras [mailto:[EMAIL PROTECTED] | Gesendet: Mittwoch, 19. September 2007 09:10 | An: 'Hans Glitsch' | Betreff: AW: [Discuss-gnuradio] rev 6467 make problem | | Hi! | | Have you fixed your libtool? | I don't know if this applies to the server version, but you | can give it a try. | | http://gnuradio.org/trac/wiki/UbuntuInstall#BrokenlibtoolonDeb | ianandUbuntu | | Greetings | Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Flex2400 AGC
Alright, that means I can read the analog RSSI indicator with the auxialiary ADCs, but it is not connected to the gain control. Instead, an auxialiary DAC controls the gain control, right? Thank you for the answer Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Flex2400 AGC
Hi! The AGC that is theoretically available at the analog devices chip on the Flex2400 boards, is it turned on? Or is it even wired? The datasheet says that there outputs and inputs, a simple rms detector and the agc input. And if these are connected, you have an AGC. Are they connected at sold boards? It's not because I want to have it turned on, but just to know. Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] can our USRP do this? --Help really needed from fellows gnuradioers :)
Hi! If you experience strong distortions in your signal, then this could be related to the cic interpolator and decimator in the usrp. I am transmitting ofdm signals. When those signals occupy the whole sample bandwidth, or a greater part of it, the frequency band at the border is greatly attenuated. Especially when the complete bandwidth is used (i.e. in your case 8 Mhz), the received signal looks similar to a gaussian distribution. At the moment, I bypass this problem by using filters on transmission and receiving side. They interpolate/decimate by a constant factor, for example 2x. The data rate sent to usrp is therefore doubled. To test the filter and run some experiments, I have modified usrp_fft.py and usrp_siggen.py. Maybe you want to have a look at these. My hardware are two usrp's, revision 4.2, with Flex2400 daughterboard installed. Greetings Dominik patch_usrp_utils.tar.gz Description: application/compressed-tar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FIR filter design function
Hi! If I design filters, what gnuradio module do I prefer: - optfir - gr.firdes ? It seems to me that you use gr.firdes in newer code, but optfir allows me to specify more filter parameters. Thanks for your help Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] python exception
Hi! Any idea where this exception can come from? Exception exceptions.ReferenceError: 'weakly-referenced object no longer exists' in > ignored The code does not explicitly delete the subdevice. I instantiate the usrp object, then I retrieve a handle to the subdev to set gain etc. Handles to usrp and subdev are stored in class members. The object holding these handles is not destroyed before program end. Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FPGA firmware
Hi! Am I right to state that the fpga firmware is configured as followed: Tx chain (0 to 2 possible) - NCO fine+coarse on Analog Devices Chip - low-pass 4x interpolation on AD-Chip - CIC interpolation filters, separate for I- and Q-Data Especially: Cordic turned off, internal DUC (duc.v) turned off? And RX Chain (0 to 4 possible) - Cordic for downconversion - CIC decimator per I- and Q-Stream - Halfbandfilter, after CIC, per I/Q-Stream Also: DDC not used? (I mean, ddc.v) Low-pass decimation filter on AD-Chip disabled. I wonder if http://gnuradio.org/trac/wiki/UsrpRfxDiagrams is still correct. Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
AW: AW: [Discuss-gnuradio] Hier-Block2: Infinite streams (in/out)
Hi! I think that you can reproduce this behaviour easily by creating a hierblock2 without connecting the input port. Dominik start: entered flattening ofdm_rx Flattening edge file_source(1):0->throttle(75):0 Flattening edge throttle(75):0->receive_path(2):0 Resolving endpoint receive_path(2):0 as an input, recursing Resolving port 0 as an input of receive_path Traceback (most recent call last): File "../../src/python/rx.py", line 262, in ? main() File "../../src/python/rx.py", line 246, in main runtime.run() File "d:/python24/Lib/site-packages/gnuradio/gr\hier_block2.py", line 98, in run runtime_run_unlocked(self._r) File "d:/python24/Lib/site-packages/gnuradio/gr\gnuradio_swig_py_runtime.py", line 1477, in runtime_run_unlocked return _gnuradio_swig_py_runtime.runtime_run_unlocked(*args) RuntimeError: block is not a valid gr_block or gr_hier_block2! -- class receive_path(gr.hier_block2): def __init__(self, options): gr.hier_block2.__init__(self, "receive_path", gr.io_signature(1,1,gr.sizeof_gr_complex), gr.io_signature(0,0,0)) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
AW: [Discuss-gnuradio] Hier-Block2: Infinite streams (in/out)
Hi! If I forget to connect a port of an hierblock2, I will get a confusing error message: RuntimeError: block is not a valid gr_block or gr_hier_block2! It would be useful if you check this upon entering the flattening process for example and give a more useful message. The debug trace finally pointed me to my mistake. The error message didn't help at all. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hier-Block2: Infinite streams (in/out)
Hi! If I were to have an hier-block2 with an infinite number of input and/or output streams: gr.hier_block2.__init__(self, "vma", gr.io_signature(1,-1,gr.sizeof_gr_complex*subcarriers), gr.io_signature(1,1,gr.sizeof_gr_complex*subcarriers)) # max streams = -1 How would I connect inner basic blocks to my input ports? E.g. let's assume the simplest case, where I like to connect all input streams to a basic block that also supports an infinite stream number. Maybe I don't see the obvious solution. If so, please point me in the right direction. Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GPL/Makefile
Hi! First of all, excuse me for this beginner's question. Furthermore this is a little bit offtopic. I have copied gr-howto-write-a-block and adapted everything to my needs. Now, in the Makefiles, it says "This file is part of GNU Radio". But my project is not part of the GNU Radio framework, and I don't think that I should claim it is. Do I have to keep the copyright notice in the Makefile, since it has been there, and add a note that there are changes? I mean, it is clear that there are changes. A Makefile has to be modified, sources added etc. Or do I put my own GPL-Note with my applications name? It's only about the Makefiles (.am etc.). (I tried to google for it, but my keywords are not that precise) Thank you very much Great work! Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] probable bug in simple_flowgraph
Hi! There is a new ticket regarding this issue. http://gnuradio.org/trac/ticket/164 Greetings, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] probable bug in simple_flowgraph
Hi! Probably, I have found a bug in the way you create buffers for outgoing block connections. First, this is what I have: A hier-block2, with a gr_block inside, encapsulating some computations. Inner connections: self.connect(self, ofdm_preamble, self) where ofdm_preamble is a gr_block of mine. ofdm_preamble uses set_output_multiple (set to 12) and set_relative_rate (value: 1.2). The streamsize is 512. It takes 10 vectors, and outputs 12 vectors of size 512 each. The preceding block is an instance of gr.fft_vcc(). Streamsize is the same. The IFFT block is connected to the hierarchical block. Running the system, I get the following: sched: is requesting more input data than we can provide. ninput_items_required = 10 max_possible_items_available = 7 If this is a filter, consider reducing the number of taps. With max_possible_items_available = buf_size-1, the allocated output buffer of the ifft-block can contain 8 items (vectors). Now, in gr_simple_flowgraph_detail::allocate_buffer(..) you go through each downstream block to ensure that the output buffer is "at least twice their decimation factor*output_multiple". In my situation, ofdm_preamble is the downstream block of ifft-block, which results in a buffer size of at least 20 (2 * output_multiple * decimation_factor = 2 * 12 * (1/1.2)). But, and that's the bug I suppose (I am not sure about that, since I didn't go through all your code), the warning indicates the buffer size to be 8 items. I am using Debian. Under Windows/MinGW, everything is fine (I think it's due to memory allocation granularity). Greetings Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] hierblock2
Hello, Currently, I am cleaning up my receiver's code. Therefore I thought using the new style hierarchical blocks. With the old blocks, there were these "kludge copy" blocks at the input of an hierarchical block in the case that the input stream was spreaded among several blocks in the inside. I saw this workaround in your examples with a note that it will be obsolete when the new blocks are implemented. This does not seem to work. I still need an input block as "kludge copy". Actually, I do not know if you already completed the work on the new blocks. So, is it a feature or a bug? Thanks Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM status
Hi! > I kicked the can down the road with Matt Ettus and Tom Rondeau. We have > spent two weeks on this total and others are welcome to contribute. We > need to have the argument: How do we specify the constellations? How do > we map carrier usage (which are pilots, clocks, etc.)? To open a discussion on that topic, here is my first proposition: We create a generic OFDM mapper block. It should treat every occupied carrier as a proper channel. I think of something like: gr_make_io_signature (nchannels, nchannels, sizeof(unsigned char)) The input streams are unpacked bytes, containing 1 to 8 bits. In front of the mapper, connect several packed_to_unpacked blocks and some stream_to_streams. A parameter to the mapper block is a channel list that assigns a modulation type to every subchannel. The mapper's task is, in this model, to map chunks to symbols independently for each subchannel. Additionally, it periodically outputs known symbols that help synchronisation in the receiver(s). Maybe a new packed_to_unpacked block can be created that fulfills two tasks; to unpack and to split the input. I think of a block taking a packed byte stream as input and outputting several unpacked byte streams with different pack-sizes per output stream. In the receiver, we do the inverse thing. Information exchange transmitter <-> receiver could be done through a network (for a testing platform). By this, we can benefit of the OFDM's main advantage - to use the optimal modulation to every subchannel. In the background, there can be a control application that evaluates SNRs, receives them from the clients (for first try: through network) and assigns modulation etc. We can also insert pilot channels - simply connect a "pilot block" to a subchannel input. This may help on synchronization and channel estimation. And it allows a new use case: 1 to N transmission, with one transmitter and several receivers. This system will allow to evaluate new algorithms for subcarrier assignment, channel estimation, synchronization etc. Greetings, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with gr_head in simple graph
Hi! > This is the first odd thing, and I believe the cause of the problem. > Your source does not block until it receives something. > Generally speaking, returning 0 is a bad idea. > > In the case of sources, you should block until you get something, then > return whatever you got. The source receives data from time to time. If I return -1 if there is no new data, the scheduler marks my source as "done" and skips it forever. How should I block? > What happens when any block declares that it is done, is that > everything is allowed to run until no further progress can be made. > In your case, the upstream block, the tcp_source, will run until it's > finally "output blocked" because of "back pressure" that results > because gr.head is done. Given that your source produces 0 output, > it'll never see any back pressure and thus will never end. Ok. I understand that there should be some back pressure. But in this case, back pressure is predictable. It is just a question of the buffer size. gr.head owns more buffer space than it will ever process. > Philosophically, we don't stop everything as soon as any block says > it's done, because other blocks may have side effects that we are > still interested in (e.g., logging results), or are still able to make > progress. How will a block make progress, especially a source, if his outputs are blocked? If all outputs of the source are blocked because they are done, I think it is a good indication that signal processing is completed. I do not really need this outside my testcase, since in a real application, it should not quit when the graph stops. > Outside of your test case, what are you really trying to do? Transferring status information in an evaluation system from a receiver to the transmitter. Thanks for your reply, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem with gr_head in simple graph
Hi! I am encountering a problem with gr_head. For my testcase, I set up a flow graph: (...) tcp_src = qtblocks.tcp_source (gr.sizeof_char, "127.0.0.1", ) head = gr.head(gr.sizeof_char, 4) vector_sink = gr.vector_sink_b() self.fg.connect (tcp_src, head, vector_sink) (...) The logging in the single threaded scheduler is active. It outputs the following: --- snip --- source noutput_items = 32767 general_work: noutput_items = 32767 result = 0 regular 1:1 max_items_avail = 0 noutput_items = 32767 BLKD_IN sink max_items_avail = 0 noutput_items = 0 BLKD_IN source noutput_items = 32767 general_work: noutput_items = 32767 result = 12 regular 1:1 max_items_avail = 12 noutput_items = 32767 general_work: noutput_items = 12 result = 4 sink max_items_avail = 4 noutput_items = 4 general_work: noutput_items = 4 result = 4 Skipping source regular 1:1 max_items_avail = 8 noutput_items = 32767 general_work: noutput_items = 8 result = -1 were_done sink were_done source noutput_items = 32759 general_work: noutput_items = 32759 result = 0 source noutput_items = 32759 general_work: noutput_items = 32759 result = 0 --- snip --- The problem is that the graph does not stop. The source still outputs items though its destination signaled done. Greetings, Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
AW: [Discuss-gnuradio] gr-buffer - threadsafe?
Hi! I am designing a block, owning an inner object, and now both will need a communication way. Since it's just one way, your buffer fulfills all my need. Do you think I should use a synchronisation object (e.g. mutex)? The inner object could possibly have an own event processing loop, i.e. can be a separate thread, and the outer block will be in a flow graph. I know that they are implementation details, but I thought it's better to reuse them instead of writing a new implementation. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-buffer - threadsafe?
Hi! Can I assume gr_buffer + gr_buffer_reader to be thread-safe? Regards Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] OFDM - on air?
Hi! Just curious on the channel transfer function, I did some modification on the ofdm simulation to see the magnitude and the argument. I am inverting your equalizer coefficients (and actually scaling them down). The coefficients of the region of interest in frequency domain are sent out through a new vector stream. In order to have it visual, the simulation script now is a class derived from stdgui. Maybe you are interested in that, e.g. for some demo purposes. I attached a patch. Dominik ofdm_gui.tar.gz Description: application/compressed-tar ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] OFDM - on air?
Hi! So there is no obvious fault, e.g. that I set the wrong decimation/interpolation rate? (the samplerate should be 400kS/s?) I just compared "tx_ofdm.dat", recorded in your simulation, to my recorded file. Therefore I modified usrp_fft.py. In tx_ofdm.dat, it shows a large frequency band in use, as expected. Unfortunately, my file does not show the same behavior :-( It looks like gaussian noise with a small carrier in the middle. Maybe I did not setup correctly the transmit path. The first few seconds while recording, there were no signal transmission. This stage can be recognized in a waterfall diagram. It seems to me that "the gaussian noise" I saw could be the transmitted OFDM signal. > If you want to start playing around with it, benchmark_ofdm.py does a > loopback simulation with optional AWGN and multipath channels between the Tx > and Rx blocks. We're hoping to inject some quiet time into this simulation > to test the signal acquisition capabilities. That is, we know that under > steady-state conditions we synchronize pretty well, but we don't know the > transient behavior when we first get s signal into the receiver. Good work! I studied the simulation for some hours, before I started to port the sim to use the usrp. > Yes, we've injected a lot of debug information here, but I thought the code > checked in had that output turned off. Are you using the newest code (and > yes, I did just check a few new things in that we didn't do before Matt > left). The debug information appear because I turned it on. I am working on the latest copy. > Thanks! It's a bit premature still, but I'm sure we'll all be glad for more > feedback as it comes together. If you like, I can give you further feedback from time to time. Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OFDM - on air?
Hello, I'm currently trying to make your ofdm simulation work with two usrp rev4. The scripts benchmark_ofdm_tx.py and ...rx.py are modified in order to send (I looked on the examples in the directory "examples/python/digital/"). Decimation rate ist 160, interpolation rate 320. Frequency 2.4G, two Flex2400RF boards used. (Maybe my first faults lay here) I also recorded some seconds to a file so I can now replay the same scenario. The first thing I observe is that the synchronisation needs to know a value for the SNR. Fiddling around with that, the synchronizer starts the sampler even if no signal present (at high SNR-value), but no samples get through it if the value is lower than 8. The correlator block thinks to have found the known symbols sometimes in the noise. And, very confusing to me, the first ofdm symbol, after the correlation found a peak, is always the first known symbol - even in absence of a signal. The message "found at search delta..." appears very often, compared to your simulation. It looks like the following lines (I also edited some blocks to output debug info): found at search delta: 1, demod out: 38 e6 55 d1 21 93 6f d4 2b ea 3a e3 41 4f d2 9 bf f9 f5 16 73 45 9c a e2 len: 25 bin 1 h_sqrd = ( 37442.839844, 1714.728149 ) power = 42633.847656 real(h)/p = 0.878242angle = 0.045764 This is repeated until I kill the process. There are also other outputs, with more "demod out" lines grouped together etc. e.g. the first lines after the gr_buffer warning bin 0 h_sqrd = ( 2.125927, 1.626051 ) power = 2.299746 real(h)/p = 0.924418angle = 0.652948 found at search delta: 0, demod out: 38 e6 55 d1 21 93 6f d4 2b ea 3a e3 41 4f d2 9 bf f9 f5 16 73 45 9c a e2 len: 25 demod out: 18 3c 8d b3 e7 9 5b cf f4 d6 52 3d a0 d2 be 1a a8 9c 4a a7 a1 36 9a 85 19 len: 25 demod out: e9 9c 88 d9 c4 93 db c7 c6 9d 87 49 21 b1 3a 40 12 6f 27 30 de a5 c8 97 f2 len: 25 demod out: 7f a5 bb 14 54 b4 84 e5 e9 3f e9 9d f5 a5 44 54 0 fb 6 21 0 44 49 9f fa len: 25 Thank you very much in advance You did a great work on gnuradio!! Dominik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
