Re: [Discuss-gnuradio] Viterbi--OFDM
Hello Achilleas, I tried out your idea and added an interleaver. While doing this, I got the error that really caused my trouble. I splited the coded sequenceinto 2 packets. And as I changed this, I worked fine, even better after adding an interleaver. So thanks for your idea. But that brought up another question. Although my working with gnu radio, I'm not really sure if I understud the output of the viterbi_combined right. The input in case is one bit per byte. I'm using the pack_to_unpack block. For trellis coding I'm using the trellis_encoder_bs. With the awgn1o2_4.fsm fsm. So what exactly is me output. Is it a short with two valid bits each? So if I use a unpack_to_pack block afterwards, I would get as much shorts as the number of chars before entering the pack_to_unpack block. Is that right? So after packing the fsmsymbols into shorts, I catch them with am message sink to get the whole coded sequence and hand it over as a payload for the ofdm_mod. So me next question is, while catching the items in that queue, do I have to count the incoming bytes or the number of incoming samples? Thanks for your help Tobias Am 11.09.2010 20:18, schrieb Tobias Schmid: Hello Achilleas, that's exactly what I thought abaout as well. Because the part I discribed as channel in my last mail is a wireless transmission using usrp2. Not using channel coding, I have packet error rates of 1 to 2 % using bpsk subcarrier constellation and abaout 18 % using qpsk. And if I evaluate the packet error rates not as a mean value, but in smaller periodes, there are periodes where the viterbi correcty almost every error, but there are also periodes in which there are just erroneus packets produced. So as you said, I thought about using an interveaver to reduce the problem of burst errors. If that doesn't work, it's no bigger problem, because I've implemented a selective repeat arq as well, so using this protocol, I'm getting good or even better performances, due to the reduced amount of data to transmit. So thanks for your quick help, I'll try this out, when I'm back a university on monday. Tobias Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos: My guess is that the inner channel (ie the combination of OFDM modulator/channel/OFDM demodulator) is producing big bursts of errors. Essentially either the packet is correctly received or completely erroneously received. In that case the outer Convolutional code cannot do much; on the contrary it deteriorates performance because of the SNR loss due to coding. One way to verify this hypothesis is to measure the error statistics of the inner channel. The way to improve is to interleave before the inner channel with sufficient depth (multiple OFDM symbols). Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard
Am 16.09.2010 07:49, schrieb Eric Blossom:
On Wed, Sep 15, 2010 at 05:55:12PM +0200, Matthias Schäfer wrote:
Hi List,
I'm currently working on a standalone firmware app for USRP2. My
goal is to send a constant signal with the xcvr2450 dboard. I
skipped the tuning via firmware by doing this prior from a host
using the simple_usrp c++ interface:
uhd::usrp::simple_usrp::sptr sdev = uhd::usrp::simple_usrp::make(args);
uhd::device::sptr dev = sdev-get_device();
sdev-set_tx_rate(rate);
sdev-set_tx_freq(freq);
sdev-set_tx_gain(gain);
===
So back to the firmware. Assuming the tuning of the dboard is
properly done from host, I basically understood the way sending is
done as follows:
1. Wait for the buffer pool to become idle:
while((buffer_pool_status-status BPS_IDLE(DSP_TX_BUF_0)) == 0)
;
2. Copy the data which should be send to the DSP into the DSP tx-buffer:
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t sample = (32000 16) | 0; // for example
for (i = 0; i BP_NLINE; i++) {
p[i] = sample;
}
3. Send the data to the DSP:
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
4. Wait until transaction is done or an error occured
while((buffer_pool_status-status (BPS_DONE(DSP_TX_BUF_0) |
BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
5. Clear the status flags and redo the whole procedure
bp_clear_buf(DSP_TX_BUF_0);
// goto 1.
===
Unfortunately this doesn't work for me like expected. I tried it in
several variations and listened with another usrp2 for a signal but
nothing happens. I think I understood something wrong and forgot
something but it's hard for me to see the problem.
So maybe you guys can help me out with that.
Thanks in advance!
Cheers,
Matthias
A couple of things. 32000 is likely to be too big and will probably
result in clipping. Try 3200 to start with.
It's unlikely that f/w can write samples to the buffer fast enough to
keep the data streaming. However in your case, you only need to
initialize the samples in the buffer once, then you can just keep
sending it over and over.
Do (2) once.
// Start in known good state (IDLE)
bp_clear_buf(DSP_TX_BUF_0);
// start first buffer xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
while (1){
// wait for xfer to complete
while ((buffer_pool_status-status
(BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
// Reset flags
bp_clear_buf(DSP_TX_BUF_0);
// start next xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}
Eric
Hi Eric,
thank for your fast reply. I tried the things you told me but it doesn't
work nevertheless. I'm using the txrx_uhd f/w with the additional void
SEND_DATA() (see below). After tuning the USRP2 with the mentioned
host-app (see above), I'm sending a UDP packet to the USRP2 with a
special port which becomes filtered by the eth_pkt_inspector which then
invokes SEND_DATA(). The serial port then tells me the following:
Waiting for the buffer pool.
Buffer pool idles. Filling buffer.
Filled buffer. Start sending.
Done.
Done.
and than the USRP2 stucks in the inner waiting-loop until I restart it.
If the debug-symbols (putstr) make any problems here, I tried it several
times without serial port but it didn't have any effect. The H/W seems
to be okay, because sending and receiving with grc works fine.
Do I maybe have to set some dboard/buffer pool flags before sending?
Does my tuning procedure maybe leave the dboard in a no-sending-state?
static void SEND_DATA () {
putstr(Waiting for the buffer pool.\n);
while((buffer_pool_status-status BPS_IDLE(DSP_TX_BUF_0)) == 0)
;
putstr(Buffer pool idles. Filling buffer.\n);
// fill buffer
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t i;
uint32_t sample = (3200 16) | 0;
for (i = 0; i BP_NLINES; i++) {
p[i] = sample;
}
putstr(Filled buffer. Start sending\n);
bp_clear_buf(DSP_TX_BUF_0);
// first xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
while (1) {
// wait for xfer to complete
while ((buffer_pool_status-status
(BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
putstr(Done.\n);
bp_clear_buf(DSP_TX_BUF_0);
// fire it off
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}
}
Cheers,
Matthias
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Viterbi--OFDM
On 9/16/2010 2:41 AM, Tobias Schmid wrote: Hello Achilleas, I tried out your idea and added an interleaver. While doing this, I got the error that really caused my trouble. I splited the coded sequenceinto 2 packets. And as I changed this, I worked fine, even better after adding an interleaver. So thanks for your idea. But that brought up another question. Although my working with gnu radio, I'm not really sure if I understud the output of the viterbi_combined right. The input in case is one bit per byte. I'm using the pack_to_unpack block. For trellis coding I'm using the trellis_encoder_bs. With the awgn1o2_4.fsm fsm. So what exactly is me output. Is it a short with two valid bits each? YES So if I use a unpack_to_pack block afterwards, I would get as much shorts as the number of chars before entering the pack_to_unpack block. Is that right? You confused me here... Let's say you have N input (uncoded) bits. These appear at the input of the trellis_encoder as N bytes (each with 1 bit info). The encoder outputs N shorts (each with 2 bits info) If you want to pack those the most economic way then you can fit 4 output symbols in a single byte. I think the best way to do this is to use trellis_encoder_bb and then unpack_to_pack to pack every 4 symbols into a byte. Then you can use the block of N/4 bytes as your payload for the OFDM modulator. Does that make sense? So after packing the fsmsymbols into shorts, I catch them with am message sink to get the whole coded sequence and hand it over as a payload for the ofdm_mod. So me next question is, while catching the items in that queue, do I have to count the incoming bytes or the number of incoming samples? not sure i understand this question...there are no samples in the transmission side of things and before the OFDM modulation. Maybe i missed something. Achilleas Thanks for your help Tobias Am 11.09.2010 20:18, schrieb Tobias Schmid: Hello Achilleas, that's exactly what I thought abaout as well. Because the part I discribed as channel in my last mail is a wireless transmission using usrp2. Not using channel coding, I have packet error rates of 1 to 2 % using bpsk subcarrier constellation and abaout 18 % using qpsk. And if I evaluate the packet error rates not as a mean value, but in smaller periodes, there are periodes where the viterbi correcty almost every error, but there are also periodes in which there are just erroneus packets produced. So as you said, I thought about using an interveaver to reduce the problem of burst errors. If that doesn't work, it's no bigger problem, because I've implemented a selective repeat arq as well, so using this protocol, I'm getting good or even better performances, due to the reduced amount of data to transmit. So thanks for your quick help, I'll try this out, when I'm back a university on monday. Tobias Am 10.09.2010 20:47, schrieb Achilleas Anastasopoulos: My guess is that the inner channel (ie the combination of OFDM modulator/channel/OFDM demodulator) is producing big bursts of errors. Essentially either the packet is correctly received or completely erroneously received. In that case the outer Convolutional code cannot do much; on the contrary it deteriorates performance because of the SNR loss due to coding. One way to verify this hypothesis is to measure the error statistics of the inner channel. The way to improve is to interleave before the inner channel with sufficient depth (multiple OFDM symbols). Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems adding a new configuration variable to an existing block
Hi All, I've tried to add a new variable to an existing block, gr-noaa/noaa_hrpt_deframer, and hoped it would show up in GRC. I've modded the noaa_hrpt_deframer.cc and noaa_hrpt_deframer.h in directory lib, noaa_hrpt_deframer.i in directory swig and added the new variable + callback into grc/noaa_hrpt_deframer.xml All modifications compiles. I now uninstall and run ./bootstrap, ./configure, make and make install. All still seems still to be OK. When I launch GRC I can see that the modified block is missing. It seems that also some other files must be modded? The simple mod I made to noaa_hrpt_deframer can be viewed at http://www.poes-weather.com/~patrik/usrp/gr-noaa/ Regards, Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware issue: Send a constant signal with the xcvr2450 dboard
On Thu, Sep 16, 2010 at 03:26:17PM +0200, Matthias Schäfer wrote:
Am 16.09.2010 07:49, schrieb Eric Blossom:
A couple of things. 32000 is likely to be too big and will probably
result in clipping. Try 3200 to start with.
It's unlikely that f/w can write samples to the buffer fast enough to
keep the data streaming. However in your case, you only need to
initialize the samples in the buffer once, then you can just keep
sending it over and over.
Do (2) once.
// Start in known good state (IDLE)
bp_clear_buf(DSP_TX_BUF_0);
// start first buffer xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
while (1){
// wait for xfer to complete
while ((buffer_pool_status-status
(BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
// Reset flags
bp_clear_buf(DSP_TX_BUF_0);
// start next xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}
Eric
Hi Eric,
thank for your fast reply. I tried the things you told me but it doesn't
work nevertheless. I'm using the txrx_uhd f/w with the additional void
SEND_DATA() (see below). After tuning the USRP2 with the mentioned
host-app (see above), I'm sending a UDP packet to the USRP2 with a
special port which becomes filtered by the eth_pkt_inspector which then
invokes SEND_DATA(). The serial port then tells me the following:
Waiting for the buffer pool.
Buffer pool idles. Filling buffer.
Filled buffer. Start sending.
Done.
Done.
and than the USRP2 stucks in the inner waiting-loop until I restart it.
If the debug-symbols (putstr) make any problems here, I tried it several
times without serial port but it didn't have any effect. The H/W seems
to be okay, because sending and receiving with grc works fine.
Do I maybe have to set some dboard/buffer pool flags before sending?
Does my tuning procedure maybe leave the dboard in a no-sending-state?
static void SEND_DATA () {
putstr(Waiting for the buffer pool.\n);
while((buffer_pool_status-status BPS_IDLE(DSP_TX_BUF_0)) == 0)
;
putstr(Buffer pool idles. Filling buffer.\n);
// fill buffer
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t i;
uint32_t sample = (3200 16) | 0;
for (i = 0; i BP_NLINES; i++) {
p[i] = sample;
}
putstr(Filled buffer. Start sending\n);
bp_clear_buf(DSP_TX_BUF_0);
// first xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
while (1) {
// wait for xfer to complete
while ((buffer_pool_status-status
(BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) == 0)
;
putstr(Done.\n);
bp_clear_buf(DSP_TX_BUF_0);
// fire it off
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);
}
}
Cheers,
Matthias
Matthias,
I'm not familiar with the changes that were made for the UDH fpga
image. It may be that the timestamp checking is being done in the DSP
path. If so, raw samples won't have the (possibly) required header.
I assume that there's a NOW flag that can be set in the header, but
I don't know the details. Looking at the UHD host code should show
you how the packet is built. Looking at the UDH firwmare will show
you which part of the header (UDP) is stripped off (probably by
adjusting the starting line number, passing on the VRT (or whatever)
header to the DSP pipe.
I believe the code above will work if you add the possibly required
header when you initialize the buffer.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] about file source block
Hi everyone, I want to ask a question about the file source block on GRC. It reads the .bin files and takes them as input. But Should that .bin files be in a fixed format. I mean is there a fixed format for this block to read or does it reads any kind of .bin files. I am trying to set a .bin file on matlab and trying to read and see the output on GRC. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] about file source block
The file source reads binary data out of a file and writes it into a gnuradio stream. So, if your data stream is floats, the file should be filled with floats, as it would be in your computer's memory. -josh On 09/16/2010 09:02 AM, mehmet kabasakal wrote: Hi everyone, I want to ask a question about the file source block on GRC. It reads the .bin files and takes them as input. But Should that .bin files be in a fixed format. I mean is there a fixed format for this block to read or does it reads any kind of .bin files. I am trying to set a .bin file on matlab and trying to read and see the output on GRC. Thanks. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-companion error
Hi Guys, I have done the following steps on my Ubuntu10.04: git clone http://gnuradio.org/git/gnuradio.git ./bootstrap, ./configure, make and sudo make install. All still seems to be OK. However, I run $ gnuradio-companion Traceback (most recent call last): File /usr/local/bin/gnuradio-companion, line 45, in module %gr.version() AttributeError: 'module' object has no attribute 'version' There is not the old version of gnuradio in my system. Who can help me? Thanks, Cliff Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-companion error
Hello Zhang, export PYTHONPATH=$PYTHONPATH:/usr/local/lib/python2.6/dist-packages should probably fix the error. Make sure the path specified above exists and contains the python gnuradio packages. Cheers, Rakesh On Fri, Sep 17, 2010 at 8:01 AM, zhang wei weizh...@rdamicro.com wrote: Hi Guys, I have done the following steps on my Ubuntu10.04: git clone http://gnuradio.org/git/gnuradio.git ./bootstrap, ./configure, make and sudo make install. All still seems to be OK. However, I run $ gnuradio-companion Traceback (most recent call last): File /usr/local/bin/gnuradio-companion, line 45, in module %gr.version() AttributeError: 'module' object has no attribute 'version' There is not the old version of gnuradio in my system. Who can help me? Thanks, Cliff Zhang ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
