Re: [Discuss-gnuradio] Simple Frame Detection
Hello Daniel, Are you using OFDM? If so, read on, otherwise disregard the rest of the email. Please look at the Schmidl-Cox synchronization method (Robust Frequency and Timing Synchronization for OFDM). In a nutshell, the frame detection works like this: At the transmitter, the packet is created such that the first ODFM symbol has only the even numbered subcarriers filled up (with some random PN sequence) and the odd subcarriers are set to 0. When this sequence is passed through the IFFT block, the symbol (in the time domain) has its first half identical to the second half. For example, if the FFT size is 1024, then in the time domain, the symbol has its first 512 samples identical to the next 512 samples. Therefore at the receiver, the detection becomes rather simple. The incoming stream (in the time domain) is correlated against a 512-sample delayed version of itself. A peak in this correlater output will indicate the boundary of the first symbol in the packet. Hope this helps. On Sun, Feb 8, 2015 at 10:21 AM, Richard Bell richard.be...@gmail.com wrote: I'm very interested to learn the answer to this. I'm trying to do the same thing right now. Rich On Feb 7, 2015, at 10:16 AM, Daniel Franch dfran...@gmail.com wrote: Hello, I have been searching for a simple frame detection scheme for GNURadio for a while, but everything I've found either doesn't work or it is more complicated than I expected. What I needed was a block that would be searching for a predetermined sequence used by the transmitter. While it doesn't find this sequence, it should give no output. Once it is found, it should output everything that came after the sequence and discard the rest as garbage. I tried using the simple framer and simple correlator. I created a simple example that just took a random source, created a frame, converted it to float, added some delay and then the correlator would try to find the sequence. But this didn't work. I got a constant zero signal as output. The documentation on these blocks is really poor and I couldn't find any good example to clarify its usage. On the other hand, I found plenty of examples of the header/payload demux. But it seems more complicated than what I need. I don't quite understand the tags and streams portion of GNURadio and I am not sure on what I should use as header data. I have been trying to create a block that will try to check for a known sequence in the incoming stream. Once it is detected, it will read the next L samples (L will be the message length defined by the user) and create a frame, which will be sent as a message. Everything before the detection of the known sequence will be ignored. The message will then be read by further blocks as the received frame. Unfortunately, creating a message passing block from scratch is turning out to be way harder than I expected. Is there any easier way to do this? Thanks in advance, Dan Franch ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about the synchronization symbol used in ofdm example
Hello Kun, Could you please verify whether the input to the FFT call are supposed to be shifted or not? Best, Aditya On Sun, Nov 2, 2014 at 10:44 AM, xianda wangxianda920...@163.com wrote: Hello all: Thank you in advance.I have two questions about the symbol used in ofdm example. 1.The first synchronization symbol is: n1=0 0 0 0 0 0 0 1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 -1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 -1.41421353816986 0 -1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 -1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 1.41421353816986 0 0 0 0 0 0 As the algorithm said,the first half of the symbol is same to the second half of the symbol. But i do ifft(n1) in matlab,and the result is 0.0441941730678082 + 0.00i 0.0644254533894132 + 0.175326551876726i -0.0367461119467220 - 0.0453679674017572i 0.0265416620395810 + 0.0320366536443552i -0.0985725617473446 - 0.0915672254739864i -0.0570202679872770 + 0.0717009594634221i 0.00862185545503520 - 0.0331748224844260i 0.0431267759560735 - 0.101430672698735i 0.0937499983955371 + 0.062489303581i -0.116910980048072 + 0.0875939237146428i 0.0433449944244991 + 0.0065988824708i 0.0708002546250446 - 0.00739045916472342i 0.00700533627335824 - 0.105577898020703i -0.0292347816053780 + 0.0541379637893818i 0.0245529670293908 - 0.0678979614538899i -0.237561871221452 + 0.0681675029413550i 0.00 + 0.00i 0.237561871221452 + 0.0681675029413550i -0.0245529670293908 - 0.0678979614538899i 0.0292347816053780 + 0.0541379637893818i -0.00700533627335823 - 0.105577898020703i -0.0708002546250446 - 0.00739045916472342i -0.0433449944244991 + 0.0065988824708i 0.116910980048072 + 0.0875939237146428i -0.0937499983955371 + 0.062489303581i -0.0431267759560735 - 0.101430672698735i -0.00862185545503520 - 0.0331748224844260i 0.0570202679872771 + 0.0717009594634221i 0.0985725617473446 - 0.0915672254739864i -0.0265416620395810 + 0.0320366536443552i 0.0367461119467220 - 0.0453679674017572i -0.0644254533894132 + 0.175326551876726i -0.0441941730678082 + 0.00i -0.0644254533894132 - 0.175326551876726i 0.0367461119467220 + 0.0453679674017572i -0.0265416620395810 - 0.0320366536443552i 0.0985725617473446 + 0.0915672254739864i 0.0570202679872770 - 0.0717009594634221i -0.00862185545503520 + 0.0331748224844260i -0.0431267759560735 + 0.101430672698735i -0.0937499983955371 - 0.062489303581i 0.116910980048072 - 0.0875939237146428i -0.0433449944244991 - 0.0065988824708i -0.0708002546250446 + 0.00739045916472342i -0.00700533627335824 + 0.105577898020703i 0.0292347816053780 - 0.0541379637893818i -0.0245529670293908 + 0.0678979614538899i 0.237561871221452 - 0.0681675029413550i 0.00 + 0.00i -0.237561871221452 - 0.0681675029413550i 0.0245529670293908 + 0.0678979614538899i -0.0292347816053780 - 0.0541379637893818i 0.00700533627335823 + 0.105577898020703i 0.0708002546250446 + 0.00739045916472342i0.0433449944244991 - 0.0065988824708i -0.116910980048072 - 0.0875939237146428i 0.0937499983955371 - 0.062489303581i 0.0431267759560735 + 0.101430672698735i 0.00862185545503520 + 0.0331748224844260i -0.0570202679872771 - 0.0717009594634221i -0.0985725617473446 + 0.0915672254739864i 0.0265416620395810 - 0.0320366536443552i -0.0367461119467220 + 0.0453679674017572i 0.0644254533894132 - 0.175326551876726i The first half of the symbol in time domain isn't same to the second half of the symbol.It is a fault? 2.I read the document fft_vcc_fftw.cc gr_complex *dst = d_fft-get_inbuf(); unsigned int len = (unsigned int)(floor(d_fft_size/2.0)); // half length of complex array memcpy(dst[0], in[len], sizeof(gr_complex)*(d_fft_size - len)); memcpy(dst[d_fft_size - len], in[0], sizeof(gr_complex)*len); Before doing the ifft operation,should I first do this? Thank you very much. Best regards, kun ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 回复： references using in ofdm_equalizer_simpledfe
Hi Tiankun,
To add on to what Martin said: In DFE, the channel state H_I on subcarrier
i is updated everytime it receives a new symbol on that subcarrier. It
doesn't really care of that symbol is a pilot or a data symbol. If it is a
pilot, the channel estimate H_i is trivially calculated and updated. If it
is a data symbol, then the nearest constellation point is found, and is
then used to update H_i.
And as Martin mentioned, the pilot placement pattern in the packet is
important to note. If I remember correctly, the reference implementation
uses the comb type pilot patter. Look at Figure 1(b) in the link below.
In the comb pilot pattern, the pilots are useless, as the subcarriers
that contain the pilot symbols do not carry data symbols. You will need to
use the block pilot pattern (look at Figure 1(a) below, and you will
immediately see how DFE is applicable in this case.
http://scialert.net/fulltext/?doi=itj.2011.914.926org=11
Of course, there are other types of pilot patterns, but you can ignore them
for now. Good luck!
best,
aditya
On Fri, Sep 5, 2014 at 12:15 PM, Martin Braun martin.br...@ettus.com
wrote:
It uses them. It will reset the channel state estimate every time it
encounters a pilot symbol. See eg the qa codes for examples. If you want to
make use of them in your modem, you need to put pilots on the same carriers
as the data.
M
On 5 Sep 2014 11:01, Tiankun Hu tiankun...@foxmail.com wrote:
Hi Aditya,
Thanks your time!
But how to use pilotes symbol's channel state to update data symbol's?
ofdm_equalizer_simpledfe is so simple, so it didn't realize that,
right?
Is there any example or paper can be for reference?
Thanks
Tiankun
-- 原始邮件 --
*发件人:* Aditya Dhananjay;adi...@cs.nyu.edu;
*发送时间:* 2014年9月4日(星期四) 晚上11:45
*收件人:* Tiankun Hutiankun...@foxmail.com;
*抄送:* discuss-gnuradio@gnu.orgdiscuss-gnuradio@gnu.org;
*主题:* Re: [Discuss-gnuradio] references using in ofdm_equalizer_simpledfe
On Thu, Sep 4, 2014 at 11:29 AM, Tiankun Hu tiankun...@foxmail.com
wrote:
Hi Aditya,
What's use of pilot symbols in ofdm_equalizer_simpledfe ?
I just found pilot symbols update their carrier's channel state, but
didn't find what's the use of these pilot channel state, seems them has no
relate with data symbol, data symbol also only use themselves to update
channel state.
for (int i = 0; i n_sym; i++) {
for (int k = 0; k d_fft_len; k++) {
if (!d_occupied_carriers[k]) {
continue;
}
if (!d_pilot_carriers.empty()
d_pilot_carriers[d_pilot_carr_set][k]) {
== //didn't find any use of these channel state in pilot
carriers =
//seems has not relate with data symbol
d_channel_state[k] = d_alpha *
d_channel_state[k]
+ (1-d_alpha) * frame[i*d_fft_len +
k]
/ d_pilot_symbols[d_pilot_carr_
set][k];
frame[i*d_fft_len+k] =
d_pilot_symbols[d_pilot_carr_set][k];
} else {
sym_eq = frame[i*d_fft_len+k] /
d_channel_state[k];
d_constellation-
map_to_points(d_constellation-
decision_maker(sym_eq),
sym_est);
d_channel_state[k] = d_alpha *
d_channel_state[k]
+ (1-d_alpha) * frame[i*d_fft_len + k] /
sym_est;
frame[i*d_fft_len+k] = sym_est;
}
}
if (!d_pilot_carriers.empty()) {
d_pilot_carr_set = (d_pilot_carr_set + 1) %
d_pilot_carriers.size();
}
}
Hello Tiankun,
That's a good question. The answer depends on how you want to implement
DFE -- and there are a couple of options.
a) Ignore pilots altogether. This is what I had described in my earlier
email.
b) Since pilots are known symbols, if a pilot is encountered, the new
channel estimate will always be correct. We know the received symbol r_i
and the expected symbol E_i, so it is trivial to calculate the channel
estimate H_i. However if you ignore the pilots, then Doppler or residual
CFO can make the decoding on a non-pilot symbol incorrect, leading to an
incorrect estimate of H_i propagating to all subsequent symbol indices on
that subcarrier 'i'.
Hope that helps.
Best,
Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss
Re: [Discuss-gnuradio] references using in ofdm_equalizer_simpledfe
On Thu, Sep 4, 2014 at 9:04 AM, Tiankun Hu tiankun...@foxmail.com wrote: Hi Martin, Could you tell me the reference paper that you used in ofdm_equalizer_simpledfe? Hello Tiankun, A decision feedback equalizer (DFE) works like this: The equalizer keeps track of the channel estimate on every subcarrier i. Call this estimate H_i. The initial values of H_i are provided by the Schmidl-Cox block, and these values are calculated from the SYNC symbols present in every packet. Now, when a symbol r_i is received on subcarrier i, it is equalized using the estimate H_i. The equalized symbol is matched to the nearest constellation point. Let this symbol be R_i. Now, the new estimate of H_i is calculated from r_i and R_i. This new value of H_i is then used for the next symbol on subcarrier i. DFE works well when the channel changes slowly across time. However, if there is substantial residual CFO (carrier frequency offset) or Doppler, then errors are possible. Substantial channel variations across subcarrier indices is irrelevant, because DFE maintains an independent channel estimate H_i for each subcarrier i. Good luck with GNU Radio. :) Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] references using in ofdm_equalizer_simpledfe
On Thu, Sep 4, 2014 at 11:29 AM, Tiankun Hu tiankun...@foxmail.com wrote:
Hi Aditya,
What's use of pilot symbols in ofdm_equalizer_simpledfe ?
I just found pilot symbols update their carrier's channel state, but
didn't find what's the use of these pilot channel state, seems them has no
relate with data symbol, data symbol also only use themselves to update
channel state.
for (int i = 0; i n_sym; i++) {
for (int k = 0; k d_fft_len; k++) {
if (!d_occupied_carriers[k]) {
continue;
}
if (!d_pilot_carriers.empty()
d_pilot_carriers[d_pilot_carr_set][k]) {
== //didn't find any use of these channel state in pilot
carriers =
//seems has not relate with data symbol
d_channel_state[k] = d_alpha *
d_channel_state[k]
+ (1-d_alpha) * frame[i*d_fft_len + k]
/ d_pilot_symbols[d_pilot_carr_
set][k];
frame[i*d_fft_len+k] =
d_pilot_symbols[d_pilot_carr_set][k];
} else {
sym_eq = frame[i*d_fft_len+k] /
d_channel_state[k];
d_constellation-
map_to_points(d_constellation-
decision_maker(sym_eq),
sym_est);
d_channel_state[k] = d_alpha *
d_channel_state[k]
+ (1-d_alpha) * frame[i*d_fft_len + k] /
sym_est;
frame[i*d_fft_len+k] = sym_est;
}
}
if (!d_pilot_carriers.empty()) {
d_pilot_carr_set = (d_pilot_carr_set + 1) %
d_pilot_carriers.size();
}
}
Hello Tiankun,
That's a good question. The answer depends on how you want to implement DFE
-- and there are a couple of options.
a) Ignore pilots altogether. This is what I had described in my earlier
email.
b) Since pilots are known symbols, if a pilot is encountered, the new
channel estimate will always be correct. We know the received symbol r_i
and the expected symbol E_i, so it is trivial to calculate the channel
estimate H_i. However if you ignore the pilots, then Doppler or residual
CFO can make the decoding on a non-pilot symbol incorrect, leading to an
incorrect estimate of H_i propagating to all subsequent symbol indices on
that subcarrier 'i'.
Hope that helps.
Best,
Aditya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question regarding frequency offset correction
On Mon, Jul 14, 2014 at 12:14 PM, Perper per...@o2.pl wrote: Hi all, In many applications very good synchronization of carrier and sampling frequencies is required. Available sources of signal not always have good clock reference. One of the examples is cheap RTL SDR receiver based on a DVB-T dongle. Without any additional effort to correct frequency offset it is impossible to decode GPS or GSM transmissions with such receivers. The frequency offset cannot be calibrated once as it changes with time and temperature. Good way to fight with it is to implement some correction algorithm that continuously computes frequency offset estimates and applies correction by: - performing frequency shifting and re-sampling in software, - or changing some hardware parameter that enables tuning of the frequency of an internal oscillator (like 'ppm' option in RTL SDR source). My question: is it possible to build working frequency correction with available GNU Radio blocks? Can you point some successful example? Or if not - can you share some ideas how it can be done? I'm especially interested in situations where frequency offset correction and estimation are in separate blocks i.e: __freq. offset_ | | v | |sig.source|--|freq.offset|--(processing)--|freq. offset| |correction | |estimation | -- Best Regards, Piotr Krysik Hello Piotr, You could take a look at the OFDM RX example. Look at the Schmidl-Cox block. It performs timing as well as coarse-grained frequency offset estimation. Once this estimation is done, correction is a simple matter of derotation. The OFDM RX example has all of this. Good luck. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using the USRP B200 with debian
Sorry, I do not. On Thu, Mar 20, 2014 at 6:23 AM, Ingmar Splitt ingmar.spl...@eas.iis.fraunhofer.de wrote: Hi Aditya, Thanks for your reply. Today I got the chance to measure the lower samplerates and here are the results: I measured the writingspeed on disk and the number of the Os for 1 minute runtime. Running X and iotop in the back has nearly no impact. MHz Mb/sO-count 32 310 350 16 180 107 8106 32 4 53 6 2 27 3 Do you have a hint for me for fixing this problem? regards, Ingmar *Von:* Aditya Dhananjay [mailto:adi...@cs.nyu.edu] *Gesendet:* Mittwoch, 19. März 2014 16:09 *An:* Ingmar Splitt *Cc:* discuss-gnuradio@gnu.org *Betreff:* Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using the USRP B200 with debian Hello Ingmar, Can you please repeat the experiment with lower sampling rates (say, 10 Mhz)? Thanks. best, aditya On Wed, Mar 19, 2014 at 8:42 AM, Ingmar Splitt ingmar.spl...@eas.iis.fraunhofer.de wrote: Hi developers, I have a fresh gnu radio installed with pybombs for my usrp B200. It runs on a Lenovo X230 with debian testing x64. When I use uhd_rx_cfile i get constant O-overruns (output given below). The uhd-benchmark runs without problems: sudo ./benchmark_rate --duration 600 --rx_rate 3200 So the USB3-Port isn't the Problem. Storing in ram is also fine: sudo ./uhd_rx_cfile -f 244500 --samp-rate=3000 /tmp/test.cfile I use a Samsung Evo 840 1TB (newest firmware) and did the SSD-Optimizations (https://wiki.debian.org/SSDOptimization) while searching for the error. HDPerm-, DD- and copy-benchmarks give 500mb/s for the first seconds, later constant ~400mb/s writing speed. Debugging with iotop brings (output below) 90% io-call-workload for the benchmarks, but 0% for the uhd_rx_cfile which writes only with 240mb/s. So everything should work as expected. Btw: I also get overruns (at a lower rate) when sampling with lower sample rate and try to change the nice number. Have you got any idea how to find and fix the bottleneck? ## user@debian:~/tools/grc/target/bin$ sudo ./uhd_rx_cfile -f 244500 --samp-rate=3000 /test/test.cfile -v linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.000-1-ga8caec5f -- Operating over USB 3. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 30.00 MSps Actual sample rate: 32.00 MSps Using mid-point gain of 36.5 ( 0.0 - 73.0 ) Motherboard: B200 (E6R04Z7B2) Daughterboard: B200 (RX2, A:A) Rx gain: 36.5 Rx baseband frequency: 2.445G Rx DDC frequency: -596.046m Rx Sample Rate: 32M Receiving samples until Ctrl-C Writing 32-bit complex floats Output filename: /test/test.cfile # iotop TID PRIO USER DISK READ DISK WRITE SWAPIN IOCOMMAND 171 be/4 root3.91 K/s0.00 B/s 0.00 % 6.63 % [kworker/u16:3] 2656 be/4 root0.00 B/s0.00 B/s 0.00 % 0.04 % X :0 -auth /var/run/lightdm~olisten tcp vt7 -novtswitch 3502 be/4 root0.00 B/s 236.78 M/s 0.00 % 0.00 % python2 ./uhd_rx_cfile -f 2~000 /test/test.cfile -v messung@debian:~/tools/grc/target/bin$ sudo hdparm -tT /dev/sda /dev/sda: Timing cached reads: 17832 MB in 2.00 seconds = 8921.71 MB/sec Timing buffered disk reads: 1526 MB in 3.00 seconds = 508.55 MB/sec ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] VOLK - vector multiplication
I had the same question. Thanks! :) On Thu, Mar 20, 2014 at 10:07 AM, Tom Rondeau t...@trondeau.com wrote: On Thu, Mar 20, 2014 at 7:05 AM, Nasi nesaz...@mail.ru wrote: Hi all, I am using ubuntu 13.04, GNUradio 3.7. I have a question related to VOLK library. When I create a vector, lets say: vectorgr_complex y1; Can I multiply this vector to another vector using VOLK? Is there any good documentation for this? -- NE Myself and Nick McCarthy have published and presented on VOLK. Here's a pretty good overview video of using it: http://www.trondeau.com/blog/2013/6/12/nearly-50-minutes-of-volk.html To answer your question, yes, building a vector like that is acceptable for use with volk kernels as long as you are using the correct data types. Be aware of alignment requirements, though, which the link above explains. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_rx_cfile: getting constant O-overflows using the USRP B200 with debian
Hello Ingmar, Can you please repeat the experiment with lower sampling rates (say, 10 Mhz)? Thanks. best, aditya On Wed, Mar 19, 2014 at 8:42 AM, Ingmar Splitt ingmar.spl...@eas.iis.fraunhofer.de wrote: Hi developers, I have a fresh gnu radio installed with pybombs for my usrp B200. It runs on a Lenovo X230 with debian testing x64. When I use uhd_rx_cfile i get constant O-overruns (output given below). The uhd-benchmark runs without problems: sudo ./benchmark_rate --duration 600 --rx_rate 3200 So the USB3-Port isn't the Problem. Storing in ram is also fine: sudo ./uhd_rx_cfile -f 244500 --samp-rate=3000 /tmp/test.cfile I use a Samsung Evo 840 1TB (newest firmware) and did the SSD-Optimizations (https://wiki.debian.org/SSDOptimization) while searching for the error. HDPerm-, DD- and copy-benchmarks give 500mb/s for the first seconds, later constant ~400mb/s writing speed. Debugging with iotop brings (output below) 90% io-call-workload for the benchmarks, but 0% for the uhd_rx_cfile which writes only with 240mb/s. So everything should work as expected. Btw: I also get overruns (at a lower rate) when sampling with lower sample rate and try to change the nice number. Have you got any idea how to find and fix the bottleneck? ## user@debian:~/tools/grc/target/bin$ sudo ./uhd_rx_cfile -f 244500 --samp-rate=3000 /test/test.cfile -v linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.007.000-1-ga8caec5f -- Operating over USB 3. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 32 MHz -- Actually got clock rate 32 MHz -- Performing timer loopback test... pass UHD Warning: The hardware does not support the requested RX sample rate: Target sample rate: 30.00 MSps Actual sample rate: 32.00 MSps Using mid-point gain of 36.5 ( 0.0 - 73.0 ) Motherboard: B200 (E6R04Z7B2) Daughterboard: B200 (RX2, A:A) Rx gain: 36.5 Rx baseband frequency: 2.445G Rx DDC frequency: -596.046m Rx Sample Rate: 32M Receiving samples until Ctrl-C Writing 32-bit complex floats Output filename: /test/test.cfile # iotop TID PRIO USER DISK READ DISK WRITE SWAPIN IOCOMMAND 171 be/4 root3.91 K/s0.00 B/s 0.00 % 6.63 % [kworker/u16:3] 2656 be/4 root0.00 B/s0.00 B/s 0.00 % 0.04 % X :0 -auth /var/run/lightdm~olisten tcp vt7 -novtswitch 3502 be/4 root0.00 B/s 236.78 M/s 0.00 % 0.00 % python2 ./uhd_rx_cfile -f 2~000 /test/test.cfile -v messung@debian:~/tools/grc/target/bin$ sudo hdparm -tT /dev/sda /dev/sda: Timing cached reads: 17832 MB in 2.00 seconds = 8921.71 MB/sec Timing buffered disk reads: 1526 MB in 3.00 seconds = 508.55 MB/sec ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_ofdm Does Not Work Past Synchronizer
Hi Jon, Disclaimer: I haven't run your code, but based on eyeballing the png file: It looks like your delay block is not configured properly. The delay should be fft_len + cp_len which is 80 (instead of 72). Best, Aditya On Tue, Mar 18, 2014 at 7:25 PM, Jonathan Fox 31...@cardinalmail.cua.eduwrote: So I have the stock python scripts (tx_ofdm and rx_ofdm) located in the gr-digital examples and put USRP sources and sinks in the appropriate spots. I left sampling alone (100K for TX, 3.2M for RX) and had the TX/RX frequency at 500 MHz. The USRPs used are N210s with WBX daughterboards. I tested the USRP used for TX out by outputting a signal to another and looking at it on the GNU Radio spectrum analyzer. Also, this is through SMA cables and a 30 dB attenuator, no over the air transmission. I placed file sinks after each block in the process; each file is a binary file. After multiple runs I felt like something wasn't working after looking at the binary files. When I execute, only the file sinks placed after the Schmidl Cox OFDM Synchronizer freq_offset and detect have data in them, at least their files have some size to them, implying something has been written. The file sinks after FFT (or the header/payload demux) have no data, 0 KB. When I discovered that the receive didn't work, I took the grc file another user made back in October with both TX mod and RX demod in the same flowgraph to see if that would work (files attached). Again same issue, all the binary files after the FFT have no data so something is getting screwed up in my demod. Has any user on this list run into this issue before or can offer some insight to why the receiver is failing? Thank you, Jon Attached is the python script, grc file, and screen shot of the TXRX combo in GRC. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] rx_ofdm Does Not Work Past Synchronizer
And if you are running over the air, try setting the TX and RX sampling rate to have the same value. In any case, I would first run in loopback mode (as shown in your png file) and save the over-the-air transmissions for later. On Tue, Mar 18, 2014 at 7:51 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: Hi Jon, Disclaimer: I haven't run your code, but based on eyeballing the png file: It looks like your delay block is not configured properly. The delay should be fft_len + cp_len which is 80 (instead of 72). Best, Aditya On Tue, Mar 18, 2014 at 7:25 PM, Jonathan Fox 31...@cardinalmail.cua.eduwrote: So I have the stock python scripts (tx_ofdm and rx_ofdm) located in the gr-digital examples and put USRP sources and sinks in the appropriate spots. I left sampling alone (100K for TX, 3.2M for RX) and had the TX/RX frequency at 500 MHz. The USRPs used are N210s with WBX daughterboards. I tested the USRP used for TX out by outputting a signal to another and looking at it on the GNU Radio spectrum analyzer. Also, this is through SMA cables and a 30 dB attenuator, no over the air transmission. I placed file sinks after each block in the process; each file is a binary file. After multiple runs I felt like something wasn't working after looking at the binary files. When I execute, only the file sinks placed after the Schmidl Cox OFDM Synchronizer freq_offset and detect have data in them, at least their files have some size to them, implying something has been written. The file sinks after FFT (or the header/payload demux) have no data, 0 KB. When I discovered that the receive didn't work, I took the grc file another user made back in October with both TX mod and RX demod in the same flowgraph to see if that would work (files attached). Again same issue, all the binary files after the FFT have no data so something is getting screwed up in my demod. Has any user on this list run into this issue before or can offer some insight to why the receiver is failing? Thank you, Jon Attached is the python script, grc file, and screen shot of the TXRX combo in GRC. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM link simulation
Hi Sara, Please look at the OFDM TX/RX examples in GNU Radio Companion. It's already there for you. :) best, aditya On Tue, Mar 18, 2014 at 8:44 PM, Sara Chérif saracheri...@gmail.com wrote: I want to simulate an OFDM link to carry 214 bytes per Ethernet packet implement it using 2 laptops running GNU 2 USRPs. Each USRP is a TX RX .(FULL-DUPLEX) I calculated all OFDM parameters needed. total BW=200KHz sample Rate=240k symbol time including CP=5ms= 8-burst gsm ( one burst is 0.6ms) T guard= CP =625u T data=4.375ms 2 bits/subcarrier (QPSK) number of bits/ ofdm symbol =440 bits 256 subcarriers per symbol , 224 subcarriers used for data , 2 subcarriers for pilots. FFT size =256. I want to use constitutional coding. I don't know how to start , and what to write in ofdm blocks (what to write in occupied carriers in ofdm transmitter for ex. , .. ) I don't know which blocks can be used what to write in each field in the blocks. And how to apply constitutional code , do I have to use specific block?! I am new to Ubuntu GNU. I found in GNU folders , Python and c++ codes , I don't know if I have to change in any of these files? Do I have to read them to understand ? Do I have to write a code to make a TX/RX block ? (As I need full duplex link) Anyone can help me how to start?? As I installed GNU a month ago , I tried to read tutorials and search in doxygen , but till now , I am so confused don't know how to fill the fields in the blocks!! Thanks :) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GSoC 2014 project Wireless Networks In-the-Loop and Channel Sounder
Hi Achuth, Channel sounding with USRP radios and GNU Radio has been done by some folks at Rutgers and ATT Labs. http://arxiv.org/pdf/1211.4940v1.pdf It might be a good idea to contact Nazmul Islam (CCed) about this project. Good luck. best, aditya On Mon, Mar 3, 2014 at 3:05 PM, achuth pv achut...@gmail.com wrote: Hi everyone, My name is Achuth PV, first year Master of Technology student in Communication and Signal Processing, Indian Institute of Technology, Bombay, India. I am really interested to work in the GSoC project Wireless Networks In-the-Loop and Channel Sounder( proposed in 2012 ). = *Wireless Networks In-the-Loop* The basic idea behind Wireless Networks In-the-Loop (WiNeLo) is to build a GR-based network emulator. This implies the modeling of the underlying SDR hardware, the individual channels interference characteristics, as well as the timing behavior (produce correct amount of noise samples if no node is transmitting). The project already started in 2011 and as a outcome, the basic functionality -- the framework with client-server based sample dispatcher as well as some example hardware channel models -- has already been implemented in the gr-winelo OOT, which will be published on github soon. See http://video.fosdem.org/2014/AW1125/Sunday/Wireless_Networks_IntheLoop.webm for a quick introdcution to Wireless Networks In-the-Loop. ObjectivesThere are various tasks covering several areas. Possible (sub-)projects are: - (Signal Processing) Implementation of new hardware/channel models like a SDR platform/specific daughterboards or reference channels. - (Optimization Performance) Improve performance of existing implementation (port python code to C/C++, develop new mechanisms to collect distribute samples between several nodes). - (Signal Processing Development Tools) Implementation of new development tools like breakpoints on the air link (pause the entire emulation if certain criteria (BER, SNR, interference/collisions) is fulfilled on the virtual channel/at single nodes). Potential mentor(s) Nico Otterbach = *Channel Sounder (Proposed in 2012)* *Details*: Channel sounding describes the process of measuring a multipath propagation channel and obtain information about excess delay, Doppler spread and fading properties. The final product should make use of USRPs for channel sounding (the high timing constraints require use of the FPGA) and provide a complete measurement tool which can be used to gather statistics about mobile communication channels. *Knowledge prerequisite:* Digital signal processing basics, FPGA basics *Access to USRPs required.* *=* My fields of interest are signal processing, wireless and digital communication, hardware and software programming and data networks. I am really comfortable in programming using C/C++, java, matlab, assembly language, VHDL and I have understanding of Python, CUDA, git. I am also comfortable in working in Linux. I am a team player and a fast learner and has got good commitment. My B Tech final year project was Implementation and comparison of various DCT architectures on FPGA using VHDL I got exposed to GnuRadio for the first time as a part of a course project in Wireless and Mobile Communication taken as a part of my masters. I want to contribute a lot to the open source world and I want GSoC to be the stepping stone for that. Can any one please tell me how to start working on these projects. Thanks in Advance Achuth ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The GMSK demodulation
As I have known, GSM uses GMSK modulation which BT = 0.3 and it uses Viterbi algorithm for demodulation. And I took a look at the code of GMSK demod code in GNU Radio, it use quadrature_demod but not Viterbi as demodulation method. So which one is better in doing demodulating GMSK? Moreover, GSM uses Viterbi algorithm to decode the convolution encoding. Would it be possible to use quadrature_demod to demodulate GSM signal instead of Viterbi? What about the convolution decoding part (maybe by some other method)? I think you are mixing up the modulation and coding components. At the transmitter, you first code (convolutional code), and then you modulate (GMSK). At the receiver, you first demodulate (quadrature demodulate) and then you decode (Viterbi). Coding takes a stream of bits and converts it to another stream of bits. Modulation refers to the process of converting the post-coded bits into symbols that you will then send over-the-air. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Loopback flowgraph
Remove the printf. Put in tag debug blocks at different points in your flowgraph to see what's going on. On Wed, Feb 26, 2014 at 8:34 AM, raf raf raf...@hotmail.fr wrote: Hello all GnuRadio users, I wanted to have a flowgraph without an USRP source and USRP sink, only by using the software blocks. The objective is to transmit and receive the BPSK modulated packets. I attached a thread at the receiver to watch if the packets are demodulated. When I run my flowgraph no packet has been received. After that, to see if the packets have been decoded in my packet sink, I changed a CC code by adding a fprintf function. When i launched the python flow graph, I started to print a received packets. Can you explain me why I have got this probleme ? Is it a packet queue of my watcher in python or there are a specific problem ? Thank you for your replay. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Message API questions
On Wed, Feb 26, 2014 at 8:45 AM, Nowlan, Sean sean.now...@gtri.gatech.eduwrote: I have a few questions regarding messages in GR. 1) Is it possible to mix-and-match the old style message sink/source blocks with the new style message passing API? Any guidance on how to make the connections? I didn't have much luck with msg_connect. I don't think the message sink/source blocks have an associated port name to make this possible. Perhaps that's something worth adding internally? I'm not sure I completely understand your question. Have you looked at the OFDM Tx/Rx examples in PATH/gr-digital/examples/ofdm? The flowgraph is a combination of standard connections within blocks, along with a message passing connection (look at the header/payload demux block). 2) I see 2 implementations of msg_queue, one in gr namespace and one in gr::messages namespace. What are the differences between these? 3) How does one achieve flow control with the new style message passing API? I have a use case in which I'm generating packets in one flowgraph and pushing them through a pdu_to_tagged_stream (P2TS) block to be modulated in another flowgraph. I believe I'm overwhelming the P2TS block's queue because I get warnings about dropped messages. One hack I made was to insert a throttle block into the packet generating flowgraph. This helped a bit, but I have to guess the magic throttle rate at which I don't fill up the queue. Is there a way to have P2TS block when its queue is full and therefore generate backpressure on the upstream flowgraph? Are you using actual hardware or is this a software only simulation? Thanks! Sean ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QPSK over air
Hi Mark, The problem is that GNU Radio does not have equalizers that can perform sufficiently well for constellations such as 64-QAM. As far as I know, the only one present is a simple decision feedback equalizer. I'm working on implementing a few equalizers: a) 2D Triangulation, and b) Whittaker-Shannon Sinc interpolator, and c) one of my own. These aren't yet ready to share, but once they are, I will send out an email to the list. Best, Aditya On Tue, Feb 25, 2014 at 1:11 PM, SOUTHCOTT, MARK A CIV USAF AFMC AFRL/RITC mark.southcot...@us.af.mil wrote: I'm looking for an example of a higher-order modulation implemented successfully in GNU Radio with an SDR frontend. I've seen bpsk, GMSK, etc. implemented over a wireless channel, but I've only seen simulations of higher-order modulations. Could someone point me towards one or confirm that there's no examples? Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Different sensing results with same hypothesis
On Wed, Feb 19, 2014 at 6:26 AM, Lebowski80 ale.rasche...@gmail.com wrote: Hello everyone, Before to explain my problem I give some technical information about my hardaware. I'm using USRPs v1 and the boards integrated are XCVR2450 Transceivers. I'm using the script usrp_spectrum_sense.py in a USRP to detect a signal in a ISM channel. To have a signal expressed in db I did this simple operation to the received signal: signal_db = 20*(math.log10(math.sqrt(m.data[0]/tb.slot_number))) I can control the signal transmitted in the ISM channel; so, I know exactly the time when there is a signal to be detected in the channel. During the first hours the USRP detects the signal giving me a value of around 40 db but after some hours such a detected signal decreases up to roughly 10 db and it does not change anymore regardless of the signal transmitted in the ISM channel. Only if I kill the process running the usrp_spectrum_sense.py script and execute it again, the USRP starts to detect again the 40 db value. The signal to be detected in the ISM channel is always the same. Can anyone tell me which is the problem? Thanks in advance. I have no clue, but my first (and only) guess would be the automatic gain control (AGC) on the USRP hardware. If you figure it out, please let us know! best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Different sensing results with same hypothesis
I don't think there is any AGC on USRP hardware... Hi Dan, You are correct; I stand corrected. The XVCR2450 does not have an AGC. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LPF in FM receiver
In the FM receiver: Why a LPF is used instead of a BPF in order to select the Radio channel that we want to hear? That is the only part I don't understand. Hello Pablo, Let's say you are trying to receive an FM signal centered around 100MHz. In other words, the signal of interest is from (100-delta)MHz through (100+delta)MHz. My understanding is that at the receiver, you are first demodulating the signal by multiplying the incoming signal with the carrier frequency of 100MHz. This leads to two bands: a) Centered around 0: (-delta through +delta) b) Centered around 200MHz: (200-delta) Mhz through (200+delta) MHz. Signal (a) is what you are interested in, while signal (b) needs to be eliminated. This is where the LPF comes in. Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] LPF in FM receiver
To continue: It is always easier to process signals in baseband (centered around 0) than it is to process RF signals (due to the high sampling rates required). Given that the bandwidth you are interested in is in the order of 100kHz (typical of FM radio signals), it is easy to see why radio receivers are designed the way they are. On Tue, Feb 11, 2014 at 11:31 AM, Aditya Dhananjay adi...@cs.nyu.eduwrote: In the FM receiver: Why a LPF is used instead of a BPF in order to select the Radio channel that we want to hear? That is the only part I don't understand. Hello Pablo, Let's say you are trying to receive an FM signal centered around 100MHz. In other words, the signal of interest is from (100-delta)MHz through (100+delta)MHz. My understanding is that at the receiver, you are first demodulating the signal by multiplying the incoming signal with the carrier frequency of 100MHz. This leads to two bands: a) Centered around 0: (-delta through +delta) b) Centered around 200MHz: (200-delta) Mhz through (200+delta) MHz. Signal (a) is what you are interested in, while signal (b) needs to be eliminated. This is where the LPF comes in. Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] .so: undefined symbol: _ZN2gr6blocks12count_bits16E
You could also try sudo ldconfig. It looks like the linker can't find
some required symbols.
Happy hacking!
On Mon, Feb 10, 2014 at 12:59 PM, Nick Foster bistrom...@gmail.com wrote:
Usually a make clean will solve this.
--n
On Mon, Feb 10, 2014 at 9:57 AM, raf raf raf...@hotmail.fr wrote:
Hi all gnuradio users,
I have an error when I try to execute a python script after adding a new
block.
My block is add to a gnuradio 3.7 with gr_modtool with a command :
gr_modtool add -t sync packet_sink
The module containing a blocks is ieee_868_915. The error is :
Traceback (most recent call last):
File ./qa_symbols_to_chips_bs.py, line 25, in module
import ieee_868_915
File /usr/local/lib/python2.7/dist-packages/ieee_868_915/__init__.py,
line 45, in module
from ieee_868_915_swig import *
File
/usr/local/lib/python2.7/dist-packages/ieee_868_915/ieee_868_915_swig.py,
line 26, in module
_ieee_868_915_swig = swig_import_helper()
File
/usr/local/lib/python2.7/dist-packages/ieee_868_915/ieee_868_915_swig.py,
line 22, in swig_import_helper
_mod = imp.load_module('_ieee_868_915_swig', fp, pathname,
description)
ImportError: /usr/local/lib/libgnuradio-ieee_868_915.so: undefined
symbol: _ZN2gr6blocks12count_bits16Ej
I tried to delete a lib file libgnuradio-ieee_868_915.so and reinstall
all a block, but it didn't give a result.
Please help me to fix this error.
Thank you.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] psk mod and channel model
Hi Marco, Could you please attach your GRC file? Thanks, Aditya On Sat, Feb 8, 2014 at 6:32 AM, Marco Bosco marco.bos...@unibo.it wrote: Hi! I am trying to do a simple simulation in GRC: Signal source -- Packet encoder -- PSK mod -- Channel model -- PSK demod -- Packet decoder -- Scope sink The problem is that it works only if I enable differential encoding. How can I make it works without using a differential encoding? (I don't want to remove the channel model) Thanks, Marco. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Possible bug with PATH/gr-channels/lib/cfo_model_impl.h
Nope, not a bug. You're reducing the standard deviation, but the actual CFO value is not this value but is adjusted based on it. I think more of what you are looking for is a direct way to set the value of the CFO (or something like a reset() function). Hi Tom, thanks for the clarification! best regards, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Possible bug with PATH/gr-channels/lib/cfo_model_impl.h
Dear All, I suspect there is a bug in cfo_model_impl.h, where calling set_std_dev to set the std_dev back to 0 causes undesirable effects. How to reproduce the bug: a) Standard OFDM TX-RX example in GRC. Connect the TX block to the RX block through this channel model block. b) Use a variable slider to control the std_dev of the CFO model block. c) Start the flowgraph, with 0 as the initial value of the std_dev. All should be fine. d) Bump up the std_dev and observe high packet errors. e) Drop the std_dev back to 0. While we expect the packet error rate to drop back to 0, but that does not happen. Reason: The value of d_cfo might be a high non-zero value. Even though we drop std_dev back to 0, d_cfo remains high, and continues to create CFO. How to fix it: In the function set_std_dev, reset the value of d_cfo to 0. If someone could verify that this is indeed a bug, that would be very helpful. Thank you in advance for your help. Best regards, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Buffer too small for min_noutput_items (ofdm_carrier_allocator_cvc)
We recently discussed this problem, I think it was the January dev call. Currently, we don't want to fix this, as it would require too many changes to our architecture. If a streamed PDU is too large for tagged stream blocks, you'll just have to use message passing. That makes perfect sense. Thanks, Martin and Bastian. I'll try both your suggestions and take it from there. Thanks again. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM Packet lost
Hi Piotr, I was facing the same issue, and the issue is caused by Schmidl-Cox sometimes detecting the packet boundaries a little late. This cannot really be helped, as channel noise may force the correlator to detect a peak/plateau later than it should. I have found a couple of ways to overcome this problem: a) After every packet, send a stream of maybe 10 0s. This ensures that even if one packet is detected a symbol late, the subsequent packet has enough room to be detected. The way to implement this is by having another tagged stream of 0s, the tag being packet_length. At the transmitter side, pass the symbols from the TX block into one input of a tagged-stream-mux, and the tagged stream of 0s into the other input of the tagged stream mux. b) In the header-payload demux, 'consume' a few symbols lesser than you need to. That way, you won't accidentally eat up the peak trigger from the next packet. As was discussed in a different thread, this is an unclean solution -- a hack! Hope that helps, and happy hacking! Best regards, Aditya On Wed, Jan 29, 2014 at 8:24 AM, Piotr Potocki piotr.l.poto...@gmail.comwrote: Hi all, I am trying to create OFDM transmission on USRP 2. I am using two URSP's (XVCR 2450) which are close to each other. To do that I am using Gnu radio 3.7.2 with slightly modify OFDM_benchmark_receiver (see img 1) and transmitter. But the problem is that I am still receiving packet lost around 1.73 - 2.2 %. Even when I am using direct cable between USRP's the packet lost is the same (around 1.73 - 2.0 % newer below). I don't think it can be frequency offset (I checked exactly what offset i have and corrected it manually). 1) So my first question is how to improve packet lost (my guess is the timing synchronization) and is this packet lost a normal thing in this scenario (without FEC) ? 2) Second question is what methods of timing synchronization (auto correlation function, ?) are used in this OFDM example and where to find them ? My specs of system: FFT length = 64 Sample rate = 2M Packet length = 40 ( i tried with different packet length and 40 gave the best results) Modulation = BPSK Carrier frequency = 2.4 Ghz Occupied carriers = 52 Best regards, Piotr Potocki ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Buffer too small for min_noutput_items (ofdm_carrier_allocator_cvc)
Dear All, Here's a little update: Changing GR_FIXED_BUFFER_SIZE from 32k to 128k solved the problem, but at the cost of quite a slowdown. The problem was, in hindsight, quite obvious. Not a bug, most definitely. My OFDM implementation just needed way too much memory. Thanks, and happy hacking to all. best, aditya On Wed, Jan 29, 2014 at 12:19 PM, Aditya Dhananjay adi...@cs.nyu.eduwrote: Dear All, I am running OFDM TX-RX in GRC. The parameters used are very similar to those in the TXRX example, with a few differences: - FFT size changed to 1024 - Pilots aren't placed on fixed subcarriers on every symbol index. Every third symbol index has pilots. - I've updated sync_word1, sync_word2, occupied_carriers, pilot_carriers, and pilot_symbols to reflect these changes. I've pasted these values at the end of the email for your reference. When I run the flowgraph, it crashed with: thread[thread-per-block[14]: block ofdm_carrier_allocator_cvc (13)]: Buffer too small for min_noutput_items The value of best_n is 4, and the value of min_noutput_items is 6. I had also experimented with a similar pilot placement scheme, but with fft_len = 64. That works fine with no issues. Any pointers on how to fix this problem? Thanks! best, aditya PARAMETERS USED: sync_word1: 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., -1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., 1.41421356, 0., -1.41421356, 0
Re: [Discuss-gnuradio] how to use FFT without grc block
Hi Nasi, And the problem is in that input part. It is not clear what is inbuf... I create gr_complex vector and want to input it into fft. It does not work in any way. There are alot of questions are still open. You can look at fft.cc and fft_vcc_fftw.cc. It is quite clear how the FFTW library is called by GNU Radio. The documentation of FFTW is also quite good. You can look up how to use a plan to calculate forward/reverse FFTs. Coder is a good coder if his code is readable first. Anyone one can design a confusing language. With all due respect, Nasi, please refrain from biting the hand that feeds, and then asking for more. Happy hacking! best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about Frequency Selective Fading Model
Dear All, I have an OFDM TX block connected to an OFDM RX block through a 'Frequency Selective Fading Model' block, implemented in GRC. The parameters used in the model are: Num sinusoids (for sum of sinusoids): 8 Max Doppler: 0 LOS Model: NLOS PDP Delays: (0, 1.6, 2.8) PDP Magnitudes: (0.4, 0.4, 0.2) Num Taps: 100 When a packet is received by the channel payload equalizer block, I simply print out the Initial Taps, which are the initial channel estimated, and plot the channel as a function of subcarrier index. I observe that at subcarrier 0 (the midpoint, since subcarrier indices are centered around 0), there is a large phase shift. In my experiment, the fft_len is 64, used as follows: Subcarrier (-32 through -27): Unused Subcarrier (-26 through -1) : Carry data/pilots Subcarrier 0: Unused Subcarrier (+1 through +26) : Carry data/pilots Subcarrier (+27 through +31): Unused What is the cause of this large discontinuity between subcarriers (-1 and +1)? Obviously, ignore subcarrier 0 since it is unused. I've pasted the 'Initial Taps' below. The columns are: subcarrier index, real part, imag part, magnitude of channel, respectively. -32 0 0 0 -31 0 0 0 -30 0 0 0 -29 0 0 0 -28 0 0 0 -27 0 0 0 -26 -0.241 -0.245 0.343 -25 -0.164 -0.203 0.261 -24 -0.08 -0.183 0.199 -23 0.006 -0.185 0.185 -22 0.087 -0.21 0.228 -21 0.157 -0.255 0.3 -20 0.212 -0.318 0.382 -19 0.247 -0.391 0.463 -18 0.262 -0.47 0.538 -17 0.254 -0.549 0.605 -16 0.225 -0.622 0.662 -15 0.178 -0.683 0.706 -14 0.117 -0.728 0.737 -13 0.046 -0.754 0.755 -12 -0.028 -0.758 0.758 -11 -0.099 -0.741 0.748 -10 -0.163 -0.706 0.724 -9 -0.211 -0.653 0.686 -8 -0.244 -0.589 0.638 -7 -0.255 -0.519 0.578 -6 -0.246 -0.448 0.511 -5 -0.213 -0.381 0.437 -4 -0.165 -0.327 0.366 -3 -0.098 -0.289 0.306 -2 -0.016 -0.265 0.266 -1 0.079 -0.264 0.275 0 0 0 0 1 0.232 -0.506 0.557 2 0.191 -0.587 0.617 3 0.143 -0.654 0.67 4 0.079 -0.7 0.704 5 0.01 -0.727 0.727 6 -0.065 -0.729 0.732 7 -0.135 -0.712 0.724 8 -0.199 -0.675 0.703 9 -0.25 -0.62 0.669 10 -0.282 -0.552 0.62 11 -0.295 -0.478 0.561 12 -0.285 -0.401 0.492 13 -0.254 -0.329 0.416 14 -0.204 -0.268 0.337 15 -0.138 -0.221 0.26 16 -0.06 -0.195 0.204 17 0.022 -0.189 0.191 18 0.105 -0.207 0.232 19 0.181 -0.246 0.306 20 0.245 -0.306 0.392 21 0.29 -0.38 0.478 22 0.316 -0.465 0.562 23 0.318 -0.554 0.639 24 0.296 -0.641 0.706 25 0.253 -0.72 0.763 26 0.189 -0.786 0.808 27 0 0 0 28 0 0 0 29 0 0 0 30 0 0 0 31 0 0 0 Why is there such a large phase shift taking place around 0? Any pointers would be greatly appreciated. This effect does not show up with a standard frequency xlating fir filter used instead of this frequency selective fading model block. Nor does the problem show up when the experiment is run over USRP hardware instead of the channel model block. Thanks in advance! Best regards, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Dear Martin, Thanks for the ideas. Two ideas: - You could remove the sync block and sync your rx/tx paths with other means (e.g. MIMO connector, it depends on your hardware). This makes the sync influence independent of the noise. Good idea, I will try it out once I get the cables. - Reconsider if the phase rotation really makes your measurements invalid. You'll have a phase rotation in any case (due to channel, propagation time etc.). The timing-related phase offset is constant, after all, and the phase difference between sub-carriers depends on the sub-carrier distance, too. Perhaps it doesn't matter all that much? That makes sense. I want to study the different phenomena that affect phase rotations in the channel. By eliminating the USRP hardware (by connecting the TX and RX blocks to each other through a channel model block), I can control the PDP of the simulated channel, for example. Thank you for your inputs. This is very useful to me. best regards, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detailed Analysis
I am looking to do some detailed analysis of my recorded data. I have been trying to look at the data in GNURadio using the FFT Plot, but I am having a hard time discerning things. Specifically, I am trying to see if a signal persists over a period of time. I am going to try and look at things with the Waterfall, but I am not sure that will be much better. I am open to using another tool, such as Octave, if need be. Any ideas? Hi Paul, What problems are you facing with the FFT plot? How much data are you trying to analyze? If the problem is that the FFT plot exhausts data too quickly, you can add a throttle block to slow things down. Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Detailed Analysis
On Wed, Jan 22, 2014 at 7:26 PM, Paul B. Huter paul.b.hu...@gmail.comwrote: Aditya: I am looking at sections of my data, one-M at a time - that is, from 0 MHz to 1 MHz, 1 MHz to 2 MHz, etc. So, for example, when I look at 0-to-1 MHz, I am using an FFT set to FFT-size of 1000. My data is about 13 seconds long, and I am looking at it at a rate of 1 Hz (so I see about 13 updates). What I am trying to see is if the data at about nine seconds persists to the end of the data at 13 seconds. I have tried holding the data at nine seconds and seeing if things keep matching up, but that is really not working out for me. I have yet to look at it from a Waterfall perspective, which may yield better results. However, in experimenting with the Waterfall, I am unable to get the window to be set the way I can set it with the FFT plot. I am getting ready to grab another data set tomorrow, but I would like to do some analysis prior to getting another data file. Hi Paul, I'm not sure I understand what you're trying to get to work. Let's say you want to examine the signal over N buckets of bandwidth 1MHz each. Can you stream your data into a bank of N band-pass filters in parallel, and then examine the FFT output through N FFT plots? (Sorry, but I don't think I'm being of much help here.) Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz carrier freq: centered around 2.437GHz It is easier to reproduce if I replace the noise block with one that adds CFO errors. a) Increase this CFO error until header CRCs fail. Let this stand for a few seconds. b) Reduce CFO offset errors to 0. c) Go to step a and repeat a few times. I observe that after doing this a few times, the RX path freezes up. In any case, thank you very much for trying to reproduce this error. I really appreciate your help. :) best regards, aditya On Thu, Jan 16, 2014 at 10:11 AM, Martin Braun martin.br...@ettus.comwrote: On Wed, Jan 15, 2014 at 07:55:45PM -0500, Aditya Dhananjay wrote: There is a variant of this issue that I discovered and would like to point it out to the community. Synopsis: After the first time the header CRC fails, *all* subsequent packets fail. Setup: - GRC examples of Tx/Rx OFDM - Noise source with a variable slider to control the amount of noise. The output of the Tx block is added with the output of the noise source. - The output of this adder is connected to the Rx block. Procedure: - Start the experiment with 0 noise. We see that the packets are successfully decoded. - Increase the noise, and we observe that the packet success rate begins to drop (payload CRC failures) - Further increase the noise to force a header CRC failure. - Decrease the noise back to 0. Notice that the packet success rate remains 0, even though the noise is 0. This is highly repeatable. Any help would be greatly appreciated. Hm, can't repeat it. I used the loopback example. Increasing noise does make packets drop (as expected), but setting it back makes them come again. A noise amplitude of ~2 causes most packets to fail, but some come through. What are your OFDM specs? MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Hello David, I was facing the exact same issue, and the fix I use is identical to yours. I consume 4 symbols less than I need to, so the subsequent packet is not lost. Best, Aditya On Tue, Jan 21, 2014 at 11:14 AM, David Halls david.ha...@toshiba-trel.comwrote: Hi Martin, Making good progress with the relay but on another topic, I find if I use a random data source (rather than the 1...range in the original example) the trigger signal arrives occasionally one or two samples earlier than expected. Say we have 96B data this gives 768/48 = 16 data symbols. Adding 3 preamble gives 19×80 samples = 1520. Sometimes there are only 1519 or 1518 samples between triggers. This means that in the HPD code, too many items are consumed by the processing of the previous packet and thus the next trigger = 1 item is consumed in error so it is never found. A simple hack is to consume 'x' fewer samples in the HPD code I.e. In the line consume_each (d_header_len * (d_items_per_symbol + d_gi)); And the equivalent in the payload case, we can append ' - 3' A slightly more robust way would be to check where the next trigger occurs and remove the corresponding number of times. Are you able to recreate this issue? I realise that the problem only occurs when using a different data source than the standard demo, so of course it's not a bug as such at all. Many thanks, David NOTE: The information in this email and any attachments may be confidential and/or legally privileged. This message may be read, copied and used only by the intended recipient. If you are not the intended recipient, please destroy this message, delete any copies held on your system and notify the sender immediately. Toshiba Research Europe Limited, registered in England and Wales (2519556). Registered Office 208 Cambridge Science Park, Milton Road, Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl -- This email has been scanned for email related threats and delivered safely by Mimecast. For more information please visit http://www.mimecast.com -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Oops, that was a typo. Sorry. I meant 200KHz. On Tue, Jan 21, 2014 at 12:17 PM, Martin Braun martin.br...@ettus.comwrote: On 01/21/2014 04:23 PM, Aditya Dhananjay wrote: Thanks for trying, Martin. My OFDM Specs are: FFT size = 64 CP length = 16 bandwidth = 2KHz Sure you don't mean 2 MHz? At this BW, I'm surprised if it worked at all. MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Your solution will work, but you have to admit it's a hack. Who says my payload is 3 or 4 symbols long? I'm currently working on the HPD, and I'll figure out a way to get this in. Absolutely; this is an unclean hack. I guess not consuming the last symbol would be sufficient in most cases, and since a payload must have at least one, this would be OK. For OFDM, this must work since one OFDM symbol is longer than the detection timing ambiguity. Assume that the FFT size is 64 and the CP length is 16. As long as the trigger comes within the first 16 time-domain samples, we should be fine. The following applies probably to my unique problem domain (which is to design a better channel interpolation technique): I would like the trigger to come in at exactly at the end of the CP, as this would eliminate spurious channel rotations. If the trigger comes in during the CP, we will see rotations in the frequency domain (the channel changes very quickly across subcarriers). To eliminate this, I would like the trigger to come in exactly at the end of the CP. In this case, a trigger offset of 1-4 can cause the subsequent packet to not be detected by the HPD. If your channel interpolation method is DFE, then these rotations are irrelevant. best, aditya MB ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
For the record: The default is 8 bits CRC, so there's a 1/256th chance a packet will fail and pass. But then there's also the payload CRC, which has 32 bits. Unlikely they'll both pass. I agree. While false positives in the header CRC so happen from time to time, I've never noticed a false positive with payload CRC. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
On Tue, Jan 21, 2014 at 1:03 PM, David Halls david.ha...@toshiba-trel.comwrote: Ah, I see. You want to isolate the effect of the channel. I believe it will be difficult, if not impossible, to remove the slight jitter of the trigger, even in very high SNR - perhaps others can comment/help? Yes, that is correct. It is impossible to *eliminate* the jitter in triggers from Schmidl-Cox. But I want to minimize it, and have edited the plaueau/peak detector code to do just that. (all in a hackish manner!) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] header_payload_demux_impl.cc - problem when using random bit stream (variable trigger location)
Aditya - am I to understand that you want to have perfect timing sync? Correct. This is because I want to study how the channel changes across OFDM subcarriers (caused due to multi-path). Having rotations in the channel across subcarriers caused by trigger timing offsets is what I want to eliminate. best, aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
I've opened http://gnuradio.org/redmine/issues/611 and will try and figure this out. Hello Martin, I am still facing a problem here. (I have pulled the newest sources from GIT). First, let me describe the environment. I have connected the transmitter side to a channel model that introduces frequency and timing offsets (so that I have control over how dirty the channel is). From this channel model block, I feed it into the receiver blocks. I am not using any USRP or real hardware as of now. Issue A: I notice that when the header CRC check fails, the entire receive path soon freezes up. Issue B: Additionally, I notice that sometimes the header gets so corrupted that the CRC check passes (I suppose these false positives cannot be helped, unless we have a longer CRC for the header, but that's probably a waste). Issue A is the main problem for me. :) Thank you! Best regards, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Hello Martin, I am still facing a problem here. (I have pulled the newest sources from GIT). First, let me describe the environment. I have connected the transmitter side to a channel model that introduces frequency and timing offsets (so that I have control over how dirty the channel is). From this channel model block, I feed it into the receiver blocks. I am not using any USRP or real hardware as of now. Issue A: I notice that when the header CRC check fails, the entire receive path soon freezes up. Issue B: Additionally, I notice that sometimes the header gets so corrupted that the CRC check passes (I suppose these false positives cannot be helped, unless we have a longer CRC for the header, but that's probably a waste). Issue A is the main problem for me. :) Dear All, Please accept my sincere apologies. Regarding issue A: The *payload* path freezes up, and this is the expected behavior since there are no valid headers that can be decoded. I had erroneously stated that the *entire* receive path freezes up, which I just realized, is not the case. Apologetically, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
Dear All, There is a variant of this issue that I discovered and would like to point it out to the community. Synopsis: After the first time the header CRC fails, *all* subsequent packets fail. Setup: - GRC examples of Tx/Rx OFDM - Noise source with a variable slider to control the amount of noise. The output of the Tx block is added with the output of the noise source. - The output of this adder is connected to the Rx block. Procedure: - Start the experiment with 0 noise. We see that the packets are successfully decoded. - Increase the noise, and we observe that the packet success rate begins to drop (payload CRC failures) - Further increase the noise to force a header CRC failure. - Decrease the noise back to 0. Notice that the packet success rate remains 0, even though the noise is 0. This is highly repeatable. Any help would be greatly appreciated. Best, Aditya On Wed, Jan 15, 2014 at 4:34 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: Hello Martin, I am still facing a problem here. (I have pulled the newest sources from GIT). First, let me describe the environment. I have connected the transmitter side to a channel model that introduces frequency and timing offsets (so that I have control over how dirty the channel is). From this channel model block, I feed it into the receiver blocks. I am not using any USRP or real hardware as of now. Issue A: I notice that when the header CRC check fails, the entire receive path soon freezes up. Issue B: Additionally, I notice that sometimes the header gets so corrupted that the CRC check passes (I suppose these false positives cannot be helped, unless we have a longer CRC for the header, but that's probably a waste). Issue A is the main problem for me. :) Dear All, Please accept my sincere apologies. Regarding issue A: The *payload* path freezes up, and this is the expected behavior since there are no valid headers that can be decoded. I had erroneously stated that the *entire* receive path freezes up, which I just realized, is not the case. Apologetically, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 3/4 and 5/6 Convolutional Codes
Dear All, Here is my .fsm file for 5/6 rate convolutional coding. The two generators are: 1+D2 and 1+D+D2. The puncturing pattern is: 10101 and 11010. I'm sending this email in case anyone else needed the .fsm for a 5/6 rate code. If you find any errors, please let me know. Thanks. best, Aditya -- 32 8 64 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 4 2 6 1 5 3 7 0 1 3 2 5 4 6 7 14 15 13 12 11 10 8 9 52 53 55 54 49 48 50 51 58 59 57 56 63 62 60 61 0 1 3 2 5 4 6 7 14 15 13 12 11 10 8 9 52 53 55 54 49 48 50 51 58 59 57 56 63 62 60 61 48 49 51 50 53 52 54 55 62 63 61 60 59 58 56 57 4 5 7 6 1 0 2 3 10 11 9 8 15 14 12 13 48 49 51 50 53 52 54 55 62 63 61 60 59 58 56 57 4 5 7 6 1 0 2 3 10 11 9 8 15 14 12 13 40 41 43 42 45 44 46 47 38 39 37 36 35 34 32 33 28 29 31 30 25 24 26 27 18 19 17 16 23 22 20 21 40 41 43 42 45 44 46 47 38 39 37 36 35 34 32 33 28 29 31 30 25 24 26 27 18 19 17 16 23 22 20 21 24 25 27 26 29 28 30 31 22 23 21 20 19 18 16 17 44 45 47 46 41 40 42 43 34 35 33 32 39 38 36 37 24 25 27 26 29 28 30 31 22 23 21 20 19 18 16 17 44 45 47 46 41 40 42 43 34 35 33 32 39 38 36 37 On Mon, Jan 6, 2014 at 7:25 PM, Aditya Dhananjay adi...@courant.nyu.eduwrote: Dear All, Does anyone have .fsm files for 3/4 and 5/6 rate convolutional codes? (Or alternatively, the state transition matrix and output matrix for these codes?) Thanks for your help in advance! Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] HELP! - Problem with radio application deploy
Tom, that was a very useful explanation. Thanks! On Tue, Nov 19, 2013 at 7:29 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Nov 19, 2013 at 7:19 PM, Paul B. Huter paul.b.hu...@gmail.com wrote: I recall that that was what you had mentioned yesterday, but could you explain why setting it to 15M will allow me to grab 30M? Sure. We're working at complex baseband. The signal you capture at 50 Msps will be observable from -25 MHz to +25 MHz. Because it's a complex signal, we have both sides around 0 Hz; also, it means that for a 50 Msps sampling rate, we can see 50 MHz of bandwidth. So to get the middle 30 MHz, you want to define a filter that extends from -15 to +15 MHz. A low pass filter is a real-valued signal. We define it from 0 to 15 MHz, but because it's real, it's symmetric around 0 and thus extends from -15 to +15 MHz. Also, be careful about using 1000 Hz as your transition band. That's still going to generate a gigantic filter. Using a 100 kHz transition band with a 50 Msps sampling rate produces a filter 909 taps long, which is very, very long. Use gr_filter_design (launched from the command line) to design a filter that's suitable. You can probably get away with a transition band of 1 MHz. Tom On Tue, Nov 19, 2013 at 6:17 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Nov 19, 2013 at 6:35 PM, Paul B. Huter paul.b.hu...@gmail.com wrote: I am trying to deploy my radio application (using GRC), and I am running into a problem. I am sampling at 50MHz and trying to pare things down to 30MHz using a Low Pass Filter, defined as follows: Decimation = 50 Gain = 1 Sample Rate = samp_rate (50M) Cutoff Freq = 3000 (30M) Transition Width = 1000 (1k) I get an error telling me cutoff frequency is greater than sample rate / 2 (30 50/2). How can I get down to 30MHz? I do intend to look at smaller chunks of data at a time, so I am perfectly okay with taking data at 50MHz and cutting it down later, I just wanted to avoid gather unnecessary data. Thanks! Set the cutoff freq to 15M, not 30M. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
I've opened http://gnuradio.org/redmine/issues/611 and will try and figure this out. Thanks, Martin. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
1. I tried checking for the average power but that doesn't work. Even with two transmitters transmitting at the same time the energy detected by the receiver doesn't change much. It remains in the same order. It is expected behavior to be in the same order. Try looking at the received power in absolute (not dB) scale. 2. Is there any other simpler way of detecting collisions other than the mentioned paper? Not that I am aware of. Sorry! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
Fundamentally a very hard problem. Yes, this is a very hard problem. Sumedha, you are implementing a TDMA scheme right? In a correctly implemented TDMA, there shouldn't be any collisions between transmitters that are using your TDMA protocol. If you are using a probabilistic TDMA (like Slotted Aloha), then I suppose the best protocol is transmit and pray. If the CRC check fails, simply retransmit. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to collect the complex data of a dpsk modulator in a text file
I am experimenting with the one of the flowgraph examples uhd_tx_dpsk.grc. I am able to see the complex number output in WX GUI NUMBER SINK block but I want to collect this output in a text file. If I use a FILE SINK block, it shows some symbols but nothing in the form of x+jy. Kindly suggest some technique to do this. You need to use Matlab/Octave to read these files. http://gnuradio.org/redmine/projects/gnuradio/wiki/Octave ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to detect collision when two packets are transmitted simultaneously from two transmitters.
Hi Sumedha, 1. You could perhaps look at the average power received over that time slot. If there is a collision, the receive power would ostensibly be higher. 2. Traditionally, a collision implied that nothing could be done, and the data was lost (unless one transmitter overwhelmed the other transmitter's signal, leading to the capture effect). However over the past couple of years, there have been techniques developed to recover packets from collisions. You could read the Zig-Zag decoding paper by Shyamnath Gollakota and Dina Katabi from SIGCOMM 2008. http://groups.csail.mit.edu/netmit/wordpress/wp-content/themes/netmit/papers/ZigZag.pdf Aditya On Fri, Nov 8, 2013 at 8:44 AM, Sumedha Goyal sumedha1...@gmail.com wrote: I have a setup of one receiver and two transmitters. I am implementing a TDMA structure (using USRPs and GNURADIO) where only one packet is sent in each slot. When both transmitters try to transmit in the same slot, collision occurs. I would like to know 1. How can the receiver detect whether a collision has occurred or not? 2. What happens to the collided packets? Regards, Sumedha ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
On Thu, Nov 7, 2013 at 7:57 AM, Martin Braun (CEL) martin.br...@kit.eduwrote: On Wed, Nov 06, 2013 at 06:27:40PM -0500, Aditya Dhananjay wrote: I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio reference GRC implementation), where the TX goes out to a USRP UHD sink, and the RX reads from a USRP UHD source. As long as the receive SNR is high enough, the problem does not show up. However, as I gradually reduce the RX gain, at some point, the entire thing crashes with the Buffer too small for min_noutput_items error. Are you using a current version? This problem was caused by bit errors creating incorrect, but validated headers. In the current header, we have an 8 Bit CRC check, which is pretty unlikely to cause this. Hi Martin, Thanks for your response. Yes, I am using the current version pulled from the git sources. To clarify, this is not a rare occurrence. With a 50% probability, when I reduce the TX/RX gain, the problem shows up. The header/payload demux is always the offending block. Also, once this problem shows up, the entire RX path freezes up, and needs to be restarted. Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC | Block to Variable
Hello! In GRC, is it possible to store the latest output of a block into a variable? Let's say I have a block A that is outputting floats. I want to save the latest output of block A into a variable var such that a block B can read var asynchronously if it needs to. Thanks! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC | Block to Variable
Update: I had tried to use Function Probe to accomplish this task, but couldn't get it to work. After the latest pull from the git repo, it works! Best, Aditya On Wed, Nov 6, 2013 at 2:54 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: Hello! In GRC, is it possible to store the latest output of a block into a variable? Let's say I have a block A that is outputting floats. I want to save the latest output of block A into a variable var such that a block B can read var asynchronously if it needs to. Thanks! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Questions on rx_ofdm example in GR 3.7.1
With this fix, now I see a new error: INFO: Detected an invalid packet at item 0 INFO: Parser returned #f thread[thread-per-block[18]: block header_payload_demux (24)]: Buffer too small for min_noutput_items I'll look into this, but just in case this is familiar to anyone... I face the same problem. I created an OFDM TX/RX flowgraph (mostly copying stuff out from the GNU Radio reference GRC implementation), where the TX goes out to a USRP UHD sink, and the RX reads from a USRP UHD source. As long as the receive SNR is high enough, the problem does not show up. However, as I gradually reduce the RX gain, at some point, the entire thing crashes with the Buffer too small for min_noutput_items error. Any help would be greatly appreciated. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why the Qam modulation cannot work well in ofdm benchmark example?
On Sun, Nov 3, 2013 at 5:09 AM, Martin Braun (CEL) martin.br...@kit.eduwrote: On Fri, Nov 01, 2013 at 07:23:33PM -0700, Yingjie Chen wrote: Recently, I have conducted a project based on ofdm benchmark. However, when I use the high modulation rate like qam16 and qam64, the packet error rate increase significantly. I guess the reason is that the preamble in gunradio is too weak to do channel estimation, thereby raising the packet error rate. Furthermore, even though I test the example offline without going through the channel, the packet error rate still very high, which make me feel confused. It is supposed to perform normally offline, without any decoding error right? In order to do QAM over OFDM, you will need a good equalizer; we currently don't have good ones implemented. MB Thanks for the clarification. I've been grappling with the high packet error rates for a while now. :) Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sampling with multiple USRP N210s with one host computer
On Thu, Oct 31, 2013 at 4:54 PM, rmsrms1987 rmsrms1...@gmail.com wrote: Hi Everyone, I recently discovered that Ettus offer a way of synchronizing up the eight USRPs with the following clock distribution system: https://www.ettus.com/product/details/OctoClock-G https://www.ettus.com/product/details/OctoClock-G Out of curiosity, how would one be able to connect and sample with eight separate USRPs with one host computer. Would you need eight separate ethernet ports? That seems like more than what a typical motherboard would be able to handle. Or can the USRPs all be connected to a server, which can be individually accessed through the host computer? Understanding how to do this will be extremely beneficial in order to gather some ideas for a project. Thank you very much in advance, Rob Hi Rob, I am not sure about eight, but my setup has 3 USRPs. All the USRPs and my host are connected to the same Gig-Ethernet switch. If you feel that your USRP-to-Host networking bandwidth is the bottleneck, maybe you could try running your wireless experiments over a thinner channel to reduce the sampling rate, and hence, the data transmitted between the USRP and host. Good luck. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx
On Wed, Oct 16, 2013 at 10:29 PM, Aditya Dhananjay adi...@cs.nyu.eduwrote: On Wed, Oct 16, 2013 at 10:22 PM, Aditya Dhananjay adi...@cs.nyu.eduwrote: Hi All, I have two USRP N210 devices connected by an attenuator cable. I set up the following experiments. -- BEGIN EXPERIMENT 1 Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the receiver, I simply record the incoming samples and save them into a file called samples1.dat. This file is static and does not change from now on. Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The other parameters (modulation, fft-length, occupied-tones, etc) are identical to those I used at the transmitter in Step 1. Measure the packet delivery rate. Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences in the packet delivery ratios, even though all runs of the experiment use the identical 'samples1.dat' file and an identical set of parameters These differences are small (1-2 packet difference), but I don't understand why they exist. Is this normal behavior? If so, could someone please let me know what the probable causes are? -- END EXPERIMENT 1 The next experiment does not use either of the USRP devices. -- BEGIN EXPERIMENT 2 1) Use benchmark_tx to generate 100 packets, and write the samples into a file (samples2.dat) using the --to-file option. 2) Use benchmark_rx with the --from-file=samples2.dat option and check the packet delivery rate. The parameters used (fft-length, etc) are obviously identical to those used to generate the samples in Step 1. I observe that the delivery rate is never even close to 100%. 3) Change to a different parameter set and repeat steps 1 and 2. Across different runs, I observe that the delivery rate is anywhere between 30% and 85%. This cannot be the expected behavior. Any pointers on what I'm doing wrong would be much appreciated! -- END EXPERIMENT 2 Thanks! Aditya I should have made a brief mention of my environment: GNU Radio 3.7.1 installed from source Ubuntu 12.04 LTS (64-bit) Thanks! Aditya Update: In experiment 1, I began to notice large variations in packet delivery ratios across different runs of step 3. If I modified benchmark_rx to just sleep for a few seconds between tb.start() and tb.wait(), these large variations disappeared. It seems like once the EOF is reached, it simply kills all threads that run inside the flow graph. However, even with the sleep, there are small variations (~1-2 packets) in an experiment with a total of 1000 packets being generated. Could anyone please give me a little hint on why this might be the case? Thanks. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx
Hi All, I have two USRP N210 devices connected by an attenuator cable. I set up the following experiments. -- BEGIN EXPERIMENT 1 Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the receiver, I simply record the incoming samples and save them into a file called samples1.dat. This file is static and does not change from now on. Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The other parameters (modulation, fft-length, occupied-tones, etc) are identical to those I used at the transmitter in Step 1. Measure the packet delivery rate. Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences in the packet delivery ratios, even though all runs of the experiment use the identical 'samples1.dat' file and an identical set of parameters These differences are small (1-2 packet difference), but I don't understand why they exist. Is this normal behavior? If so, could someone please let me know what the probable causes are? -- END EXPERIMENT 1 The next experiment does not use either of the USRP devices. -- BEGIN EXPERIMENT 2 1) Use benchmark_tx to generate 100 packets, and write the samples into a file (samples2.dat) using the --to-file option. 2) Use benchmark_rx with the --from-file=samples2.dat option and check the packet delivery rate. The parameters used (fft-length, etc) are obviously identical to those used to generate the samples in Step 1. I observe that the delivery rate is never even close to 100%. 3) Change to a different parameter set and repeat steps 1 and 2. Across different runs, I observe that the delivery rate is anywhere between 30% and 85%. This cannot be the expected behavior. Any pointers on what I'm doing wrong would be much appreciated! -- END EXPERIMENT 2 Thanks! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Repeatability of delivery ratios using benchmark_tx/rx
On Wed, Oct 16, 2013 at 10:22 PM, Aditya Dhananjay adi...@cs.nyu.eduwrote: Hi All, I have two USRP N210 devices connected by an attenuator cable. I set up the following experiments. -- BEGIN EXPERIMENT 1 Step 1) Use benchmark_tx on one of the USRPs and send 100 packets. At the receiver, I simply record the incoming samples and save them into a file called samples1.dat. This file is static and does not change from now on. Step 2) Run benchmark_rx with the --from-file=samples1.dat option. The other parameters (modulation, fft-length, occupied-tones, etc) are identical to those I used at the transmitter in Step 1. Measure the packet delivery rate. Step 3) Repeat Step 2 a bunch of times. Sometimes, I notice differences in the packet delivery ratios, even though all runs of the experiment use the identical 'samples1.dat' file and an identical set of parameters These differences are small (1-2 packet difference), but I don't understand why they exist. Is this normal behavior? If so, could someone please let me know what the probable causes are? -- END EXPERIMENT 1 The next experiment does not use either of the USRP devices. -- BEGIN EXPERIMENT 2 1) Use benchmark_tx to generate 100 packets, and write the samples into a file (samples2.dat) using the --to-file option. 2) Use benchmark_rx with the --from-file=samples2.dat option and check the packet delivery rate. The parameters used (fft-length, etc) are obviously identical to those used to generate the samples in Step 1. I observe that the delivery rate is never even close to 100%. 3) Change to a different parameter set and repeat steps 1 and 2. Across different runs, I observe that the delivery rate is anywhere between 30% and 85%. This cannot be the expected behavior. Any pointers on what I'm doing wrong would be much appreciated! -- END EXPERIMENT 2 Thanks! Aditya I should have made a brief mention of my environment: GNU Radio 3.7.1 installed from source Ubuntu 12.04 LTS (64-bit) Thanks! Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] recv and send frame size
On Tue, Oct 15, 2013 at 7:00 AM, Baier ba...@irt.de wrote: Hi all, is there any possibilty to increase the send frame size ans recv frame size of the USRP from the host? Thanks AB What are you using to transmit and receive? Are you using the benchmark_tx and benchmark_rx files? (I assume that frame size and packet size are synonymous). If so, you can use the -s 500 option to set the frame size to 500 bytes in benchmark_tx. There is no need to set the frame size in the receiver. The frame size is encoded by the transmitter into the header, and the receiver reads it off that. Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURADIO.org down???
It's still working for me. http://www.downforeveryoneorjustme.com/gnuradio.org Down for me. I see the advert for domains priced right. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Summary of desires for GRC, just discuss on the #ghuradio channel
On Wed, Oct 2, 2013 at 3:16 PM, Ethan Trewhitt gnura...@potophobia.netwrote: On Wed, Oct 2, 2013 at 3:03 PM, Marcus Leech mle...@ripnet.com wrote: Just a quick summary of the things people would like to see in GRC: o off-page connectors -- for managing large flow-graphs o better-handling of GRC-produced hier-blocks o allow blocks to be in more than one category o make searching easier o integrate Doxygen block documentation better o provide a safe method for blocks object handle to be passed into helper code o some kind of organizer for parameters and variables o A way to make Note blocks lar ger and maybe multi-line I'd like to add a couple requests for GRCC as well: - The --directory parameter should be respected for even for hier blocks. Right now it's ignored for hier blocks and they're put into ~/.grc_gnuradio no matter what. - Should work without an accessible X display (I think there's a bug tracker entry for this already) - Some mechanism that allows compiled .py files to avoid having hard-coded references to the /home//.grc_gnuradio/ directory when referring to custom hier blocks. A combined feature request for both: - (Modeled like a modern programming IDE) GRC has the concept of projects - Projects can contain any number of top blocks and hier blocks - GRC generates a Makefile when building, then runs that Makefile, which calls GRCC This would allow someone to build an entire app ecosystem inside one GRC window, complete with a build process that allows later users to compile the .grc files into .py simply by calling make on a headless machine. The goal is to support the paradigm of committing only .grc files to version control, then treating the .py files as derived source code not to be committed. Oh, and finally ... snap to grid :D Some more, if I may: Make sure the 'wires' are always visible, and are not hidden behind blocks. And that two or more wires cannot 'overlap' on the screen. When two blocks are connected using a 'wire', and the wire needs to bend, display the bend in the wire in a rounded manner. This way, it is easily distinguishable from two wires that merely cross over. When the screen is tightly packet with blocks, it gets visually confusing. Thanks! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I/Q samples and Analytic Signals
Perhaps, Chapter 2 of Digital Communications by John Proakis? best, aditya On Mon, Sep 30, 2013 at 10:26 AM, Lucas Ingles lucas.lore...@gmail.comwrote: Hello to all, I am using GNU Radio to study digital communications systems. I have been working on the basic FM receiver with RTL-SDR for a while. I was trying to find out what is the theory behind the complex I/Q samples. What I discovered is that I/Q samples are first related to analytic signals (the pre envelope) and then to the complex envelope of the signal (the complex signal in base band). In fact, what RTL-SDR outputs to the flow graph is the complex base band signal, in other words, the signal translated to base band with just the positive or negative portion of the spectrum. Please, can someone with more experience confirm to me if I am correct? Can someone please recommend me some reference books about the theory of I/Q samples? Thanks very much in advance, Lucas Lorenzi Ingles ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Endianness in OFDM Implementation
Hello All, I have a question about the implementation of the mapping from an incoming bit-stream to generate an output of frequency-domain OFDM symbols (ofdm_mapper_bcv_impl.cc). Let's say that the incoming bit-stream is '0x00', '0x36', '0x00', '0x36', '0xff', '0x3f', '0x37', '0x27' '0x37'. Converting this from a hex to binary representation, this stream is: 0011 0110 0011 0110 0011 0011 0111 0010 0111 0011 0111. Assuming that we use QAM64, this stream should be broken up into chunks of 6 bits each, to give us: 00 11 011000 00 001101 10 00 11 001101 110010 011100 110111. Once the mapping is done, this should correspond to (at least, in my head) the frequency-domain representation of the 6-bit chunks (shown in Hex below): 0 3 28 0 0d 2f 3c 3f 0d 32 1c 37. But the output from the stock implementation (ofdm_mapper_bcv_impl.cc) is: 1 18 3 0 36 3c 3f f 37 1c 32 d. I know my question has to do with endianness: Is the reference implementation correct? If so, how does one interpret the endianness of the incoming bit-stream? Thanks! Best, Aditya Upon further examination, this does seem like classic little-endianness. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio did not install gnuradio-runtime
On Tue, Sep 17, 2013 at 12:18 PM, Dincer Beken dbe...@blackned.de wrote: Hi, so i installed a Fedora 19 with build-gnuradio -m. (Yes I used the official GnuRadio :(( ). I ran a cmake .. with Bastians new cmake files (both for gr-foo gr-ieee802-15-4). It did not work. So it really does not work with the official repo, even if you change FindGnuRadioRuntime.cmake with the original (I tried it twice): http://gnuradio.org/cgit/gnuradio.git/tree/gr-utils/python/modtool/gr-newmod/cmake/Modules/FindGnuradioRuntime.cmake?id=3.7.2git Error: [dbeken@localhost build]$ cmake ../ -- Build type not specified: defaulting to release. -- Boost version: 1.53.0 -- Found the following Boost libraries: -- filesystem -- system -- Found PkgConfig: /usr/bin/pkg-config (found version 0.27.1) -- checking for module 'gnuradio-runtime' -- package 'gnuradio-runtime' not found -- Could NOT find GNURADIO_RUNTIME (missing: GNURADIO_RUNTIME_LIBRARIES) -- checking for module 'cppunit' -- found cppunit, version 1.12.1 -- Found CPPUNIT: /usr/lib64/libcppunit.so;dl CMake Error at CMakeLists.txt:87 (message): GnuRadio Runtime required to compile ieee802-11 -- Configuring incomplete, errors occurred! [dbeken@localhost build]$ I will try (for the last time) to run on a new and different Fedora Bastian's GnuRadio. Regards, Dincer -Ursprüngliche Nachricht- Von: Bastian Bloessl [mailto:bastian.bloe...@uibk.ac.at] Gesendet: Dienstag, 17. September 2013 16:19 An: Dincer Beken Cc: Nick Foster; discuss-gnuradio@gnu.org Betreff: Re: [Discuss-gnuradio] build-gnuradio did not install gnuradio-runtime On 09/17/2013 10:19 AM, Dincer Beken wrote: root@openwns-desktop:/home/openwns/GnuRadioBastian/gr-foo/build# make [ 4%] Building CXX object lib/CMakeFiles/gnuradio-foo.dir/packet_dropper_impl.cc.o In file included from /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc:18: /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.h:28: error: 'default_random_engine' in namespace 'std' does not name a type /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.h:29: error: ISO C++ forbids declaration of 'uniform_real_distribution' with no type /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.h:29: error: invalid use of '::' /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.h:29: error: expected ';' before '' token /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc: In constructor 'gr::foo::packet_dropper_impl::packet_dropper_impl(double, long unsigned int)': /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc:28: error: class 'gr::foo::packet_dropper_impl' does not have any field named 'd_generator' /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc:29: error: class 'gr::foo::packet_dropper_impl' does not have any field named 'd_distribution' /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc: In member function 'void gr::foo::packet_dropper_impl::msg_handler(pmt::pmt_t)': /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc:42: error: 'd_generator' was not declared in this scope /home/openwns/GnuRadioBastian/gr-foo/lib/packet_dropper_impl.cc:42: error: 'd_distribution' was not declared in this scope make[2]: *** [lib/CMakeFiles/gnuradio-foo.dir/packet_dropper_impl.cc.o] Fehler 1 make[1]: *** [lib/CMakeFiles/gnuradio-foo.dir/all] Fehler 2 make: *** [all] Fehler 2 Meanwhile we figured out its a compile problem... I use some C++11 stuff and this does not work with g++ v4.4 :-/ Hi All, I was facing a similar same issue (tests failing). I used to run 32-bit Ubuntu Linux (13.04) on 64-bit hardware. I ran the stock unmodified gnuradio that was installed from source, which was in turn downloaded from the GIT repo. I tried everything that was suggested on the mailing list archives -- including running volk_profile, etc, but the tests kept failing. I then installed 64-bit Linux (Ubuntu 12.04 LTS), installed the latest version of ORC (0.4.18), re-installed gnuradio and tried again. *All tests now pass* (other than vocoder). Just thought I'd let you know in case anyone is facing the same issue. Best regards, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Working example of rx_ofdm and rx_ofdm with Gnuradio Companion
T hanks! On Thu, Sep 19, 2013 at 1:13 AM, Martin Braun (CEL) martin.br...@kit.eduwrote: Hi Aditya, there's a ticket on this (see our issue tracker) and I'm on it. tx_ofdm.grc should work, though. MB On Wed, Sep 18, 2013 at 01:13:11PM -0400, Aditya Dhananjay wrote: Hello All, Reviving an older discussion (from what I gather from the list archives). Does anyone have a working example of rx_ofdm.grc and tx_ofdm.grc? Or in the minimum, a working example of rx_ofdm.grc that plays with benchmark_tx, and/or a working example of tx_ofdm.grc that plays with benchmark_rx? Thank you very much! Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Gnuradio disabled components
Could you please post the entire output from cmake? Thanks On Thu, Sep 19, 2013 at 7:26 PM, Mauricio Olivera m.olivera.go...@gmail.com wrote: Hi all, I have recently installed GNU radio 3.7.1 in Manjaro (Distro based in Arch). While building some components where disable. I am interested in having some of them like gnuradio-companion and gr-wxgui, how can I enable them Many thanks, ## -- # Gnuradio disabled components -- ## -- * doxygen -- * sphinx -- * gr-ctrlport -- * gnuradio-companion -- * gr-comedi -- * gr-qtgui -- * gr-wxgui -- -- Using install prefix: /usr -- Building for version: 3.7.1 / 3.7.1 -- Configuring done -- Generating done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Gnuradio disabled components
Have you installed all the dependencies? Which Linux are you running? http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Install-Dependencies On Thu, Sep 19, 2013 at 8:02 PM, Mauricio Olivera m.olivera.go...@gmail.com wrote: Here is the complete installation process... https://www.dropbox.com/s/md5v8pr0iyllm8f/gnuradio_inst Many thanks. 2013/9/19 Aditya Dhananjay adi...@cs.nyu.edu Could you please post the entire output from cmake? Thanks On Thu, Sep 19, 2013 at 7:26 PM, Mauricio Olivera m.olivera.go...@gmail.com wrote: Hi all, I have recently installed GNU radio 3.7.1 in Manjaro (Distro based in Arch). While building some components where disable. I am interested in having some of them like gnuradio-companion and gr-wxgui, how can I enable them Many thanks, ## -- # Gnuradio disabled components -- ## -- * doxygen -- * sphinx -- * gr-ctrlport -- * gnuradio-companion -- * gr-comedi -- * gr-qtgui -- * gr-wxgui -- -- Using install prefix: /usr -- Building for version: 3.7.1 / 3.7.1 -- Configuring done -- Generating done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Fwd: Gnuradio disabled components
Oops, sorry, I missed those details in your previous email. On Thu, Sep 19, 2013 at 8:10 PM, Aditya Dhananjay adi...@cs.nyu.edu wrote: Have you installed all the dependencies? Which Linux are you running? http://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall#Install-Dependencies On Thu, Sep 19, 2013 at 8:02 PM, Mauricio Olivera m.olivera.go...@gmail.com wrote: Here is the complete installation process... https://www.dropbox.com/s/md5v8pr0iyllm8f/gnuradio_inst Many thanks. 2013/9/19 Aditya Dhananjay adi...@cs.nyu.edu Could you please post the entire output from cmake? Thanks On Thu, Sep 19, 2013 at 7:26 PM, Mauricio Olivera m.olivera.go...@gmail.com wrote: Hi all, I have recently installed GNU radio 3.7.1 in Manjaro (Distro based in Arch). While building some components where disable. I am interested in having some of them like gnuradio-companion and gr-wxgui, how can I enable them Many thanks, ## -- # Gnuradio disabled components -- ## -- * doxygen -- * sphinx -- * gr-ctrlport -- * gnuradio-companion -- * gr-comedi -- * gr-qtgui -- * gr-wxgui -- -- Using install prefix: /usr -- Building for version: 3.7.1 / 3.7.1 -- Configuring done -- Generating done ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Working example of rx_ofdm and rx_ofdm with Gnuradio Companion
Hello All, Reviving an older discussion (from what I gather from the list archives). Does anyone have a working example of rx_ofdm.grc and tx_ofdm.grc? Or in the minimum, a working example of rx_ofdm.grc that plays with benchmark_tx, and/or a working example of tx_ofdm.grc that plays with benchmark_rx? Thank you very much! Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio did not install gnuradio-runtime
On Tue, Sep 17, 2013 at 10:13 AM, Tom Rondeau t...@trondeau.com wrote: On Tue, Sep 17, 2013 at 3:43 AM, Dincer Beken dbe...@blackned.de wrote: Hi all, so I have installed Bastian's Gnu Radio and could build the files. I have not changed the FindGnuradioRuntime.cmake, because when I ran the cmake with Bastian's Project there were no errors, and to be honest, I don't know if I need to overwrite it still (although Make for gr-ieee802-15-14 crashed). Right now, I don't have anything to do with Bastian's Projekt but still having trouble with the Gnuradio Code. When I run a make test I got a %2 error rate with - qa_fir_filter_test - qa_freq_xlating_fir_filter_test - qa_ctcss_squelch - qa_codec2_covocoder Hi Dincer, Ignore the CTCSS and CODEC2 problems. There's some architecture issues involved there that we haven't been able to track down, but the QA code failing isn't a problem unless you are specifically using those blocks. The FIR filter tests are likely VOLK related. Again, this seems to be an architecture thing. Though I think if we plotted the histograms, there is only a partial overlap between these failures and the other two. I've never been able to generate these errors on any of my machines of VMs and so haven't had a chance to look into what's going on here. Try running 'volk_profile' and waiting for that to complete. You should be ok running applications after that, at least. Hi All, volk_profile writes a file volk_config to a directory that isn't the path for the gnuradio installation. Should this file be copied elsewhere? The qa_volk_test_all fails on volk_32fc_s32f_magnitude_16i_test even after running volk_profile. Should I create a separate thread with all the information related to my failing tests, and post all the information (environment, etc) there? Best, Aditya ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
