Concerns about wrong BLER information.

25 views
Skip to first unread message

Raul Suarez

unread,
Oct 29, 2013, 6:35:44 AM10/29/13
to flex...@googlegroups.com
Hello,

We are students from UPC, we are working with ALOE++-0.2 and trying to improve it by using a higher bit/symbol modulation like QAM16 and QAM64 and also by using larger FFT sizes.

Now, our goal is to achieve a QAM16 modulation. We saw that PDCCH already implements the transmision of the used MCS so Rx knows how to demodulate the signal, but we got BLER=1. That being said, we investigated what was not implemented for this modulation in each block. We think the problem can be in the scrambling or the ratematching. However, we checked how the CRC module works and we find out something strange.

When working with the default configuration of osld.app (version provided at http://flexnets.github.io/aloe/) and changing a bit the code of gen_crc.c for printing the input and output of the CRC, we found out that when some bits are send (1001010101110) we receive only zeros (000000000) so the CRC return a n=0 meaning that there are no error, which is the problem, because all the bits are receive wrong.

Thanks for reading.

Best regards,
Raúl Suárez



We attach the configuration of the osld.app for a quick view of your part if it's possible.

ctrl:
    {
        binary="modrep_osld/liblte_
ctrl.so";   
        mopts=100;
        variables=(
            {name="nof_output_data_itf";value=0},
            {name="mode";value=2}, /* 0 tx, 1 rx, 2 both */
            {name="mcs_tx";value=20},{name="nof_rbg_tx";value=6},{name="rbg_mask_tx";value=0x3f},
            {name="nof_prb_tx";value=6},
           
            {name="cfi_tx";value=1},
            {name="divide";value=0},
           
            {name="cfi_rx";value=-1},
            {name="subframe_rx";value=-1},
            {name="mcs_rx";value=-1},
            {name="nof_rbg_rx";value=-1},
            {name="nof_prb_rx";value=-1},
            {name="sfn_rx";value=-1},
            {name="rbg_mask_rx";value=0},
           
            {name="nof_ports";value=1},
            {name="cell_id";value=0},{name="nof_osymb_x_subf";value=14},
           
           
            {name="delay_synchro_pss";value=0},
            {name="delay_synchro_sss";value=0},
            {name="delay_equalizer";value=0},           
            {name="delay_resdemapp_pbch";value=0},           
            {name="delay_pbch_rx_descrambling";value=0},           
            {name="delay_resdemapp_pcfich";value=0},           
            {name="delay_resdemapp_pdsch";value=0},           
            {name="delay_pcfich_rx_descrambling";value=0},
            {name="delay_resdemapp_pdcch";value=0},           
            {name="delay_pdcch_rx_descrambling";value=0},           
            {name="delay_pdsch_rx_demodulator";value=0},
            {name="delay_pdsch_rx_descrambling";value=0},
            {name="delay_pdsch_rx_unratematching";value=0},
            {name="delay_resdemapp_pdsch";value=0}           
        );
    };

We also attach what the selfmade debug code shows us ('n' in Rx is 0, but not because everything is OK but because all bits are 0):

Tx
111101111111000011010101001100
111000111000010010111101000000011111110011110101110010010010011111
000011101111010011011110110101001010100000101010110001101111010111001011000101000001111000001000
100001010000100101000101101001011100001001110100010101001100111001001111100111100010110001010000
100101011101011010001111011011011001000110010111100011010110011111111111010010100111010101100011
101000101000011010111101011010101011001001000101111001101000101000110011111110101010100011101001
010011101110100001000101011111010101011100111001101110011101010000100000110010110100111000111011
011011101100101110101101100000101010001111101110110001111011001100100011011101010010101000100110
111010111111010011010110111100111011110001000000001010001111001110001101001111111010010011110001
111001000111100001110111100111000100000000110111000101011100000011011001010110010000111001101100
000000111000000000111011001101001000001101001001010001100110010011011111011111011011111100100001
101010111000101001100010110111001101110011001010100111100111011011100111010011001010100001101100
0101110110101111101110111010100011100101
ESTADO2:0,
Rx
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000
ESTADO2:1, n=0

We also attach the code we used to print this. Note that we used an extra param that we get from the pdsch.app file.

param_get_int_name("debug", &soyyo);
            if (soyyo == 1) {
                if(mode==0)printf("Tx\n");
                if(mode==1)printf("Rx\n");
                for(i=1; i<(rcv_samples+1);i++){
                    if(i%96 != 0)printf("%d", *(input+i-1));
                    else printf("%d\n", *(input+i-1));
                }
                printf("\n");
            }
            n = icrc(0, input, rcv_samples, long_crc, poly, mode == MODE_ADD);
            if (soyyo == 1) printf("ESTADO2:%d, n=%d\n", mode, n);
           if (mode==MODE_CHECK) {

{default code here}

Ismael Gomez

unread,
Oct 29, 2013, 6:50:44 AM10/29/13
to flex...@googlegroups.com
Hi, 

Uncomment the line 35 in gen_crc.c:

#define CHECK_ZEROS

and rebuild. Then the crc module will check for an all-zero packet and print a message. 

Ismael


2013/10/29 Raul Suarez <raul.sua...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/flexnets/a829ed20-6280-4ebb-af6d-4b058f6066ac%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Raul Suarez

unread,
Oct 29, 2013, 10:29:54 AM10/29/13
to flex...@googlegroups.com
Hello Ismael,

Thanks for that fast response. We checked what you said, and now it prints the number of 0 each packet has. But the main problem is that we don't know why the input of the ICRC at the receiver is all zeros. What I mean is that the bits that we see should be the same because the sent bits should be the same as the received bits (start and end of the chain).

Thanks for reading,

Best regards,
Raúl Suárez

Ismael Gomez

unread,
Oct 29, 2013, 10:35:52 AM10/29/13
to flex...@googlegroups.com
Unfortunately only the QPSK modulation has been tested. We highly encourage you to try new modulations, fix what's missing and share your results with us. Your work would be highly appreciated. 

To debug the waveform, try connecting the output interface of a module in the middle of the chain to the sink, dumping the signal to a file. Then you can process that file with matlab, veryfing that the produced signal is what you expect. 

Hope that helps. Please don't hesitate to ask any question. 

Ismael


2013/10/29 Raul Suarez <raul.sua...@gmail.com>
Hello Ismael,

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.

Raul Suarez

unread,
Oct 29, 2013, 10:47:41 AM10/29/13
to flex...@googlegroups.com
Hi Ismael,

We are trying to make it for QAM16, but before that we checked how was QPSK working. The results that we showed you are from the default setup for QPSK (mcs=9) modulation, not QAM16 nor QAM64. That's why it's so strange for us that what we receive is all zeros for QPSK modulation since this is the setup that has been tested.


Best regards,
Raúl Suárez


On Tuesday, October 29, 2013 11:35:44 AM UTC+1, Raul Suarez wrote:

Ismael Gomez

unread,
Oct 29, 2013, 10:50:37 AM10/29/13
to flex...@googlegroups.com

Sorry I misunderstood you. Which app are you working with? It should be osld_tx_file.app for the transmitter and osld_rx_file.app for the receiver

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.

Raul Suarez

unread,
Oct 29, 2013, 11:20:14 AM10/29/13
to flex...@googlegroups.com
Hello Ismael,

We are working on osld.app, which includes transmitter and receiver. However, we will merge the files that you told us in one single file, so we can test it.

Sincerely,
Raúl Suárez

Ismael Gomez

unread,
Oct 29, 2013, 11:31:51 AM10/29/13
to flex...@googlegroups.com

You can test it without merging. The transmitter writes the samples to a file, which is the read by the receiver. Please take a look at the website's wiki pages for more help.

Thank you

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.
Message has been deleted

Raul Suarez

unread,
Oct 29, 2013, 12:00:06 PM10/29/13
to flex...@googlegroups.com
Hi Ismael,

We have already found the mistake. It was our mistake while debugging the values. Now we're getting the correct values, and we are going to try to make it work with QAM16 modulation. Thanks for helping.

Best regards,
Raúl Suárez

Ismael Gomez

unread,
Oct 29, 2013, 12:05:06 PM10/29/13
to flex...@googlegroups.com

I'm happy to hear this. Good luck

--
You received this message because you are subscribed to the Google Groups "ALOE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flexnets+u...@googlegroups.com.
To post to this group, send email to flex...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages