BER

[Jiya Johnson]

Greetings all,
 Need help to generate BER plot for CCSDS encoder-decoder with soft
decision(euclidean distance) decoding. I am getting constant BER throughout
the plot and sometimes more than 5.5dB is getting for soft decoding.

Re: CCSDS BER PLOT

[U L]

Import block: https://wiki.gnuradio.org/index.php?title=Import

On Sat, Aug 19, 2023 at 10:43 AM Jiya Johnson 
wrote:

> Thanks for the advice!
> Try to do but continuously it is showing error Param - Value(value):
> Value "numpy.sqrt((10.0**(-esno/10.0))/2.0)" cannot be evaluated:
> name 'numpy' is not defined
> how can i rectify this?
> is there any already done grc files for evaluating ccsds
>
> On Sat, Aug 19, 2023 at 9:55 PM U L  wrote:
>
>> I'd try this:
>> 1. Change the random source to a vector source with vector [ 0xFF, 0xFF,
>> 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ] (that's 4 x
>> 0xFF, 8 x 0x00)
>> 2. Encoder output can go to the map input, then map to a charToFloat.
>> CharToFloat to decoder.
>> 3. Remove the entire noise branch. It doesn't make sense to add noise
>> before the map anyways. Noise would normally be added as a float after
>> charToFloat.
>> 4. Vector source to a delay block, delay to one input of BER block.
>> Decoder output to pack8 to BER block.
>> 5. You'll have to experiment with the delay value. It's probably between
>> 2 and 8 bytes.
>> 6. If you want to try to observe the delay between the source and the
>> decoder, make a 2 input time sink and connect the unpack8 output after the
>> vector source to one time sink input, and the decoder output to the other
>> sink input. You should be able to see the sample delay between each block
>> of inputs and compute the right delay from the difference.
>>
>> Good luck,
>> Jared.
>>
>> On Sat, Aug 19, 2023 at 5:13 AM Jiya Johnson 
>> wrote:
>>
>>> Any suggestions
>>>
>>> On Sat, Aug 19, 2023, 9:15 AM Jiya Johnson 
>>> wrote:
>>>
>>>> But still  in  CCSDS case i am getting -0.3 only BER and not even
>>>> saturating in FEC extended CC case(as per CCSDS Standard book it is
>>>> dropping to 0 by 5dB)
>>>>
>>>> On Sat, Aug 19, 2023 at 8:54 AM U L  wrote:
>>>>
>>>>> Hmm, this has gotten more complicated since your original post. Why?
>>>>>
>>>>> A good place to start might be the example GRC as referenced on this
>>>>> page https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder.
>>>>> You can change the FEC definitions from LDPC to CC and add a BER block 
>>>>> with
>>>>> a delay b/w the input bytes and output bytes (bypass the char to float
>>>>> after the decoder). Once that's working, you can replace the FEC encoder
>>>>> with a CCSDS one.
>>>>>
>>>>> Jared.
>>>>>
>>>>> On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
>>>>> wrote:
>>>>>
>>>>>> I am getting need help pls look on the screenshot
>>>>>>
>>>>>> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>> I will try and let you know
>>>>>>>
>>>>>>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>>>>>>
>>>>>>>> Probably easier to use a vector source rather than text file.
>>>>>>>> Vector source lets you specify the bytes exactly. So you could put in [
>>>>>>>> 0xdd, ] and be assured that byte will be output.
>>>>>>>>
>>>>>>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson <
>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> What I tried is 11011101( by inputting a text file )it's hex
>>>>>>>>> version came in the output with (3131303131313031) like that with 
>>>>>>>>> encoding
>>>>>>>>> by left shifting I got the value theoretically and decode I got dd
>>>>>>>>> (11011101) bt this worked over windows not in ubuntu,this output I 
>>>>>>>>> have
>>>>>>>>> done using messag debug option I am not aware whether it is the 
>>>>>>>>> correct way.
>>>>>>>>>
>>>>>>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>>>>>>
>>>>>>>>>> I don't understand what this means. How do you interpret it?
>>>>>>>>>> Jared.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>&g

Re: CCSDS BER PLOT

[Jiya Johnson]

Thanks for the advice!
Try to do but continuously it is showing error Param - Value(value):
Value "numpy.sqrt((10.0**(-esno/10.0))/2.0)" cannot be evaluated:
name 'numpy' is not defined
how can i rectify this?
is there any already done grc files for evaluating ccsds

On Sat, Aug 19, 2023 at 9:55 PM U L  wrote:

> I'd try this:
> 1. Change the random source to a vector source with vector [ 0xFF, 0xFF,
> 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ] (that's 4 x
> 0xFF, 8 x 0x00)
> 2. Encoder output can go to the map input, then map to a charToFloat.
> CharToFloat to decoder.
> 3. Remove the entire noise branch. It doesn't make sense to add noise
> before the map anyways. Noise would normally be added as a float after
> charToFloat.
> 4. Vector source to a delay block, delay to one input of BER block.
> Decoder output to pack8 to BER block.
> 5. You'll have to experiment with the delay value. It's probably between 2
> and 8 bytes.
> 6. If you want to try to observe the delay between the source and the
> decoder, make a 2 input time sink and connect the unpack8 output after the
> vector source to one time sink input, and the decoder output to the other
> sink input. You should be able to see the sample delay between each block
> of inputs and compute the right delay from the difference.
>
> Good luck,
> Jared.
>
> On Sat, Aug 19, 2023 at 5:13 AM Jiya Johnson 
> wrote:
>
>> Any suggestions
>>
>> On Sat, Aug 19, 2023, 9:15 AM Jiya Johnson 
>> wrote:
>>
>>> But still  in  CCSDS case i am getting -0.3 only BER and not even
>>> saturating in FEC extended CC case(as per CCSDS Standard book it is
>>> dropping to 0 by 5dB)
>>>
>>> On Sat, Aug 19, 2023 at 8:54 AM U L  wrote:
>>>
>>>> Hmm, this has gotten more complicated since your original post. Why?
>>>>
>>>> A good place to start might be the example GRC as referenced on this
>>>> page https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder.
>>>> You can change the FEC definitions from LDPC to CC and add a BER block with
>>>> a delay b/w the input bytes and output bytes (bypass the char to float
>>>> after the decoder). Once that's working, you can replace the FEC encoder
>>>> with a CCSDS one.
>>>>
>>>> Jared.
>>>>
>>>> On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
>>>> wrote:
>>>>
>>>>> I am getting need help pls look on the screenshot
>>>>>
>>>>> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
>>>>> wrote:
>>>>>
>>>>>> I will try and let you know
>>>>>>
>>>>>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>>>>>
>>>>>>> Probably easier to use a vector source rather than text file. Vector
>>>>>>> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
>>>>>>> and be assured that byte will be output.
>>>>>>>
>>>>>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson <
>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>
>>>>>>>> What I tried is 11011101( by inputting a text file )it's hex
>>>>>>>> version came in the output with (3131303131313031) like that with 
>>>>>>>> encoding
>>>>>>>> by left shifting I got the value theoretically and decode I got dd
>>>>>>>> (11011101) bt this worked over windows not in ubuntu,this output I have
>>>>>>>> done using messag debug option I am not aware whether it is the 
>>>>>>>> correct way.
>>>>>>>>
>>>>>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>>>>>
>>>>>>>>> I don't understand what this means. How do you interpret it?
>>>>>>>>> Jared.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson <
>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson <
>>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I have tried to do with a simple input 11011101 without noise
>>>>>>>>

Re: CCSDS BER PLOT

[U L]

I'd try this:
1. Change the random source to a vector source with vector [ 0xFF, 0xFF,
0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ] (that's 4 x
0xFF, 8 x 0x00)
2. Encoder output can go to the map input, then map to a charToFloat.
CharToFloat to decoder.
3. Remove the entire noise branch. It doesn't make sense to add noise
before the map anyways. Noise would normally be added as a float after
charToFloat.
4. Vector source to a delay block, delay to one input of BER block. Decoder
output to pack8 to BER block.
5. You'll have to experiment with the delay value. It's probably between 2
and 8 bytes.
6. If you want to try to observe the delay between the source and the
decoder, make a 2 input time sink and connect the unpack8 output after the
vector source to one time sink input, and the decoder output to the other
sink input. You should be able to see the sample delay between each block
of inputs and compute the right delay from the difference.

Good luck,
Jared.

On Sat, Aug 19, 2023 at 5:13 AM Jiya Johnson 
wrote:

> Any suggestions
>
> On Sat, Aug 19, 2023, 9:15 AM Jiya Johnson 
> wrote:
>
>> But still  in  CCSDS case i am getting -0.3 only BER and not even
>> saturating in FEC extended CC case(as per CCSDS Standard book it is
>> dropping to 0 by 5dB)
>>
>> On Sat, Aug 19, 2023 at 8:54 AM U L  wrote:
>>
>>> Hmm, this has gotten more complicated since your original post. Why?
>>>
>>> A good place to start might be the example GRC as referenced on this
>>> page https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder.
>>> You can change the FEC definitions from LDPC to CC and add a BER block with
>>> a delay b/w the input bytes and output bytes (bypass the char to float
>>> after the decoder). Once that's working, you can replace the FEC encoder
>>> with a CCSDS one.
>>>
>>> Jared.
>>>
>>> On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
>>> wrote:
>>>
>>>> I am getting need help pls look on the screenshot
>>>>
>>>> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
>>>> wrote:
>>>>
>>>>> I will try and let you know
>>>>>
>>>>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>>>>
>>>>>> Probably easier to use a vector source rather than text file. Vector
>>>>>> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
>>>>>> and be assured that byte will be output.
>>>>>>
>>>>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>> What I tried is 11011101( by inputting a text file )it's hex version
>>>>>>> came in the output with (3131303131313031) like that with encoding by 
>>>>>>> left
>>>>>>> shifting I got the value theoretically and decode I got dd (11011101) bt
>>>>>>> this worked over windows not in ubuntu,this output I have done using 
>>>>>>> messag
>>>>>>> debug option I am not aware whether it is the correct way.
>>>>>>>
>>>>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>>>>
>>>>>>>> I don't understand what this means. How do you interpret it?
>>>>>>>> Jared.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson <
>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson <
>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> I have tried to do with a simple input 11011101 without noise and
>>>>>>>>>> with noise noise also
>>>>>>>>>>
>>>>>>>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>>>>>>>
>>>>>>>>>>> Some ideas:
>>>>>>>>>>>
>>>>>>>>>>> 1. Remove the noise completely. Also use a fixed, repeating
>>>>>>>>>>> input vector rather than random bytes. Look at the actual error 
>>>>>>>>>>> patterns
>>>>>>>>>>> between the input and output bits. Sometimes error patterns can 
>>>>>>>>&g

Re: CCSDS BER PLOT

[Jiya Johnson]

Any suggestions

On Sat, Aug 19, 2023, 9:15 AM Jiya Johnson  wrote:

> But still  in  CCSDS case i am getting -0.3 only BER and not even
> saturating in FEC extended CC case(as per CCSDS Standard book it is
> dropping to 0 by 5dB)
>
> On Sat, Aug 19, 2023 at 8:54 AM U L  wrote:
>
>> Hmm, this has gotten more complicated since your original post. Why?
>>
>> A good place to start might be the example GRC as referenced on this page
>> https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder. You can
>> change the FEC definitions from LDPC to CC and add a BER block with a delay
>> b/w the input bytes and output bytes (bypass the char to float after the
>> decoder). Once that's working, you can replace the FEC encoder with a CCSDS
>> one.
>>
>> Jared.
>>
>> On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
>> wrote:
>>
>>> I am getting need help pls look on the screenshot
>>>
>>> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
>>> wrote:
>>>
>>>> I will try and let you know
>>>>
>>>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>>>
>>>>> Probably easier to use a vector source rather than text file. Vector
>>>>> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
>>>>> and be assured that byte will be output.
>>>>>
>>>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
>>>>> wrote:
>>>>>
>>>>>> What I tried is 11011101( by inputting a text file )it's hex version
>>>>>> came in the output with (3131303131313031) like that with encoding by 
>>>>>> left
>>>>>> shifting I got the value theoretically and decode I got dd (11011101) bt
>>>>>> this worked over windows not in ubuntu,this output I have done using 
>>>>>> messag
>>>>>> debug option I am not aware whether it is the correct way.
>>>>>>
>>>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>>>
>>>>>>> I don't understand what this means. How do you interpret it?
>>>>>>> Jared.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson <
>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I have tried to do with a simple input 11011101 without noise and
>>>>>>>>> with noise noise also
>>>>>>>>>
>>>>>>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>>>>>>
>>>>>>>>>> Some ideas:
>>>>>>>>>>
>>>>>>>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>>>>>>>> vector rather than random bytes. Look at the actual error patterns 
>>>>>>>>>> between
>>>>>>>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>>>>>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>>>>>>>> 3. Try the more general (non-CCSDS) extended encoder with the
>>>>>>>>>> same params as the decoder.
>>>>>>>>>> 4. Esp if 3 works, compare the output of CCSDS with general
>>>>>>>>>> extended encoder.
>>>>>>>>>>
>>>>>>>>>> Good luck.
>>>>>>>>>> Jared.
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson <
>>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>> Based on the given modifications still I am getting a -0.300
>>>>>>>>>>> range of BER constantly from 0 to 15 dB range of SNR values.No 
>>>>>>>>>>> variations
>>>>>>>>>>> are happening.
>>>>>>>>>>>
>>>>>>>>>>> How can I check the functionality of the block(encoder and
>>>>>>>>>

Re: CCSDS BER PLOT

[Jiya Johnson]

But still  in  CCSDS case i am getting -0.3 only BER and not even
saturating in FEC extended CC case(as per CCSDS Standard book it is
dropping to 0 by 5dB)

On Sat, Aug 19, 2023 at 8:54 AM U L  wrote:

> Hmm, this has gotten more complicated since your original post. Why?
>
> A good place to start might be the example GRC as referenced on this page
> https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder. You can
> change the FEC definitions from LDPC to CC and add a BER block with a delay
> b/w the input bytes and output bytes (bypass the char to float after the
> decoder). Once that's working, you can replace the FEC encoder with a CCSDS
> one.
>
> Jared.
>
> On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
> wrote:
>
>> I am getting need help pls look on the screenshot
>>
>> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
>> wrote:
>>
>>> I will try and let you know
>>>
>>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>>
>>>> Probably easier to use a vector source rather than text file. Vector
>>>> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
>>>> and be assured that byte will be output.
>>>>
>>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
>>>> wrote:
>>>>
>>>>> What I tried is 11011101( by inputting a text file )it's hex version
>>>>> came in the output with (3131303131313031) like that with encoding by left
>>>>> shifting I got the value theoretically and decode I got dd (11011101) bt
>>>>> this worked over windows not in ubuntu,this output I have done using 
>>>>> messag
>>>>> debug option I am not aware whether it is the correct way.
>>>>>
>>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>>
>>>>>> I don't understand what this means. How do you interpret it?
>>>>>> Jared.
>>>>>>
>>>>>>
>>>>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> I have tried to do with a simple input 11011101 without noise and
>>>>>>>> with noise noise also
>>>>>>>>
>>>>>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>>>>>
>>>>>>>>> Some ideas:
>>>>>>>>>
>>>>>>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>>>>>>> vector rather than random bytes. Look at the actual error patterns 
>>>>>>>>> between
>>>>>>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>>>>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>>>>>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>>>>>>>> params as the decoder.
>>>>>>>>> 4. Esp if 3 works, compare the output of CCSDS with general
>>>>>>>>> extended encoder.
>>>>>>>>>
>>>>>>>>> Good luck.
>>>>>>>>> Jared.
>>>>>>>>>
>>>>>>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson <
>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>> Based on the given modifications still I am getting a -0.300
>>>>>>>>>> range of BER constantly from 0 to 15 dB range of SNR values.No 
>>>>>>>>>> variations
>>>>>>>>>> are happening.
>>>>>>>>>>
>>>>>>>>>> How can I check the functionality of the block(encoder and
>>>>>>>>>> decoder to check whether it's encoding and decoding properly)with a 
>>>>>>>>>> sample
>>>>>>>>>> input.
>>>>>>>>>>
>>>>>>>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>>>>>>>
>>>>>>>>>>> One other thing I noticed is that the encode CCSDS, decode,
>>>>>>>>>&

Re: CCSDS BER PLOT

[U L]

Hmm, this has gotten more complicated since your original post. Why?

A good place to start might be the example GRC as referenced on this page
https://wiki.gnuradio.org/index.php?title=FEC_Extended_Decoder. You can
change the FEC definitions from LDPC to CC and add a BER block with a delay
b/w the input bytes and output bytes (bypass the char to float after the
decoder). Once that's working, you can replace the FEC encoder with a CCSDS
one.

Jared.

On Fri, Aug 18, 2023 at 9:05 PM Jiya Johnson 
wrote:

> I am getting need help pls look on the screenshot
>
> On Sat, Aug 19, 2023 at 8:23 AM Jiya Johnson 
> wrote:
>
>> I will try and let you know
>>
>> On Sat, Aug 19, 2023, 8:08 AM U L  wrote:
>>
>>> Probably easier to use a vector source rather than text file. Vector
>>> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
>>> and be assured that byte will be output.
>>>
>>> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
>>> wrote:
>>>
>>>> What I tried is 11011101( by inputting a text file )it's hex version
>>>> came in the output with (3131303131313031) like that with encoding by left
>>>> shifting I got the value theoretically and decode I got dd (11011101) bt
>>>> this worked over windows not in ubuntu,this output I have done using messag
>>>> debug option I am not aware whether it is the correct way.
>>>>
>>>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>>>
>>>>> I don't understand what this means. How do you interpret it?
>>>>> Jared.
>>>>>
>>>>>
>>>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>> I have tried to do with a simple input 11011101 without noise and
>>>>>>> with noise noise also
>>>>>>>
>>>>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>>>>
>>>>>>>> Some ideas:
>>>>>>>>
>>>>>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>>>>>> vector rather than random bytes. Look at the actual error patterns 
>>>>>>>> between
>>>>>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>>>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>>>>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>>>>>>> params as the decoder.
>>>>>>>> 4. Esp if 3 works, compare the output of CCSDS with general
>>>>>>>> extended encoder.
>>>>>>>>
>>>>>>>> Good luck.
>>>>>>>> Jared.
>>>>>>>>
>>>>>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson <
>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>> Based on the given modifications still I am getting a -0.300 range
>>>>>>>>> of BER constantly from 0 to 15 dB range of SNR values.No variations 
>>>>>>>>> are
>>>>>>>>> happening.
>>>>>>>>>
>>>>>>>>> How can I check the functionality of the block(encoder and decoder
>>>>>>>>> to check whether it's encoding and decoding properly)with a sample 
>>>>>>>>> input.
>>>>>>>>>
>>>>>>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>>>>>>
>>>>>>>>>> One other thing I noticed is that the encode CCSDS, decode,
>>>>>>>>>> CCSDS, and BER blocks all  operate on packed bytes. (See e.g.
>>>>>>>>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To
>>>>>>>>>> do this you would change your random source to output from 0 to 256 
>>>>>>>>>> byte
>>>>>>>>>> values. Also, considering the output of the decoder block are packed 
>>>>>>>>>> bytes
>>>>>>>>>> you should probably skip the byte->float and binary slicer after your
>>&g

Re: CCSDS BER PLOT

[Jiya Johnson]

I will try and let you know

On Sat, Aug 19, 2023, 8:08 AM U L  wrote:

> Probably easier to use a vector source rather than text file. Vector
> source lets you specify the bytes exactly. So you could put in [ 0xdd, ]
> and be assured that byte will be output.
>
> On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
> wrote:
>
>> What I tried is 11011101( by inputting a text file )it's hex version came
>> in the output with (3131303131313031) like that with encoding by left
>> shifting I got the value theoretically and decode I got dd (11011101) bt
>> this worked over windows not in ubuntu,this output I have done using messag
>> debug option I am not aware whether it is the correct way.
>>
>> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>>
>>> I don't understand what this means. How do you interpret it?
>>> Jared.
>>>
>>>
>>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
>>> wrote:
>>>
>>>>
>>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>>>> wrote:
>>>>
>>>>> I have tried to do with a simple input 11011101 without noise and with
>>>>> noise noise also
>>>>>
>>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>>
>>>>>> Some ideas:
>>>>>>
>>>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>>>> vector rather than random bytes. Look at the actual error patterns 
>>>>>> between
>>>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>>>>> params as the decoder.
>>>>>> 4. Esp if 3 works, compare the output of CCSDS with general extended
>>>>>> encoder.
>>>>>>
>>>>>> Good luck.
>>>>>> Jared.
>>>>>>
>>>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> Based on the given modifications still I am getting a -0.300 range
>>>>>>> of BER constantly from 0 to 15 dB range of SNR values.No variations are
>>>>>>> happening.
>>>>>>>
>>>>>>> How can I check the functionality of the block(encoder and decoder
>>>>>>> to check whether it's encoding and decoding properly)with a sample 
>>>>>>> input.
>>>>>>>
>>>>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>>>>
>>>>>>>> One other thing I noticed is that the encode CCSDS, decode, CCSDS,
>>>>>>>> and BER blocks all  operate on packed bytes. (See e.g.
>>>>>>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do
>>>>>>>> this you would change your random source to output from 0 to 256 byte
>>>>>>>> values. Also, considering the output of the decoder block are packed 
>>>>>>>> bytes
>>>>>>>> you should probably skip the byte->float and binary slicer after your
>>>>>>>> decoder and just input it's output directly into the BER block. 
>>>>>>>> Finally,
>>>>>>>> looking at the
>>>>>>>> https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>>>>>>>> seems the delay out of the decoder is 4 bytes, so you could add a 
>>>>>>>> delay of
>>>>>>>> 4 between your source and BER block to align the two streams.
>>>>>>>>
>>>>>>>> Jared.
>>>>>>>>
>>>>>>>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>>>>>>>
>>>>>>>>> One thing I think might be an issue is that you have no delay
>>>>>>>>> between your source reference and your BER block. Usually the FEC 
>>>>>>>>> decoders
>>>>>>>>> (and possibly the encoder?) may output blocks of 0s before they 
>>>>>>>>> output the
>>>>>>>>> samples that correspond to your inputs. I don't know much about those 
>>>>>>>>> FEC
>>>>>>>>> blocks specifically, but maybe the docs have some info on their 
>>>>>>>>> delays. You
>>>>>>>>> can just insert a delay block b/w your random source and the ber 
>>>>>>>>> block to
>>>>>>>>> align the input and output bits.
>>>>>>>>>
>>>>>>>>> Hope that helps,
>>>>>>>>> Jared.
>>>>>>>>>
>>>>>>>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson <
>>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [image: image.png]
>>>>>>>>>> Dear community
>>>>>>>>>>Need help for BER plot using the above flowgraph its always
>>>>>>>>>> coming 10^-1.17 and whenever I tried to change the noise voltage the 
>>>>>>>>>> values
>>>>>>>>>> are not changing.
>>>>>>>>>> Please find the attached GRC file for your reference.
>>>>>>>>>>
>>>>>>>>>> *Regards, JIYA JOHNSON*
>>>>>>>>>>
>>>>>>>>>>

Re: CCSDS BER PLOT

[U L]

Probably easier to use a vector source rather than text file. Vector source
lets you specify the bytes exactly. So you could put in [ 0xdd, ] and be
assured that byte will be output.

On Fri, Aug 18, 2023 at 8:32 PM Jiya Johnson 
wrote:

> What I tried is 11011101( by inputting a text file )it's hex version came
> in the output with (3131303131313031) like that with encoding by left
> shifting I got the value theoretically and decode I got dd (11011101) bt
> this worked over windows not in ubuntu,this output I have done using messag
> debug option I am not aware whether it is the correct way.
>
> On Sat, Aug 19, 2023, 7:58 AM U L  wrote:
>
>> I don't understand what this means. How do you interpret it?
>> Jared.
>>
>>
>> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
>> wrote:
>>
>>>
>>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>>> wrote:
>>>
>>>> I have tried to do with a simple input 11011101 without noise and with
>>>> noise noise also
>>>>
>>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>>
>>>>> Some ideas:
>>>>>
>>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>>> vector rather than random bytes. Look at the actual error patterns between
>>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>>>> params as the decoder.
>>>>> 4. Esp if 3 works, compare the output of CCSDS with general extended
>>>>> encoder.
>>>>>
>>>>> Good luck.
>>>>> Jared.
>>>>>
>>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>> Based on the given modifications still I am getting a -0.300 range of
>>>>>> BER constantly from 0 to 15 dB range of SNR values.No variations are
>>>>>> happening.
>>>>>>
>>>>>> How can I check the functionality of the block(encoder and decoder to
>>>>>> check whether it's encoding and decoding properly)with a sample input.
>>>>>>
>>>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>>>
>>>>>>> One other thing I noticed is that the encode CCSDS, decode, CCSDS,
>>>>>>> and BER blocks all  operate on packed bytes. (See e.g.
>>>>>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do
>>>>>>> this you would change your random source to output from 0 to 256 byte
>>>>>>> values. Also, considering the output of the decoder block are packed 
>>>>>>> bytes
>>>>>>> you should probably skip the byte->float and binary slicer after your
>>>>>>> decoder and just input it's output directly into the BER block. Finally,
>>>>>>> looking at the
>>>>>>> https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>>>>>>> seems the delay out of the decoder is 4 bytes, so you could add a delay 
>>>>>>> of
>>>>>>> 4 between your source and BER block to align the two streams.
>>>>>>>
>>>>>>> Jared.
>>>>>>>
>>>>>>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>>>>>>
>>>>>>>> One thing I think might be an issue is that you have no delay
>>>>>>>> between your source reference and your BER block. Usually the FEC 
>>>>>>>> decoders
>>>>>>>> (and possibly the encoder?) may output blocks of 0s before they output 
>>>>>>>> the
>>>>>>>> samples that correspond to your inputs. I don't know much about those 
>>>>>>>> FEC
>>>>>>>> blocks specifically, but maybe the docs have some info on their 
>>>>>>>> delays. You
>>>>>>>> can just insert a delay block b/w your random source and the ber block 
>>>>>>>> to
>>>>>>>> align the input and output bits.
>>>>>>>>
>>>>>>>> Hope that helps,
>>>>>>>> Jared.
>>>>>>>>
>>>>>>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson <
>>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> [image: image.png]
>>>>>>>>> Dear community
>>>>>>>>>Need help for BER plot using the above flowgraph its always
>>>>>>>>> coming 10^-1.17 and whenever I tried to change the noise voltage the 
>>>>>>>>> values
>>>>>>>>> are not changing.
>>>>>>>>> Please find the attached GRC file for your reference.
>>>>>>>>>
>>>>>>>>> *Regards, JIYA JOHNSON*
>>>>>>>>>
>>>>>>>>>

Re: CCSDS BER PLOT

[Jiya Johnson]

What I tried is 11011101( by inputting a text file )it's hex version came
in the output with (3131303131313031) like that with encoding by left
shifting I got the value theoretically and decode I got dd (11011101) bt
this worked over windows not in ubuntu,this output I have done using messag
debug option I am not aware whether it is the correct way.

On Sat, Aug 19, 2023, 7:58 AM U L  wrote:

> I don't understand what this means. How do you interpret it?
> Jared.
>
>
> On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
> wrote:
>
>>
>> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
>> wrote:
>>
>>> I have tried to do with a simple input 11011101 without noise and with
>>> noise noise also
>>>
>>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>>
>>>> Some ideas:
>>>>
>>>> 1. Remove the noise completely. Also use a fixed, repeating input
>>>> vector rather than random bytes. Look at the actual error patterns between
>>>> the input and output bits. Sometimes error patterns can clue you in.
>>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>>> params as the decoder.
>>>> 4. Esp if 3 works, compare the output of CCSDS with general extended
>>>> encoder.
>>>>
>>>> Good luck.
>>>> Jared.
>>>>
>>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> Based on the given modifications still I am getting a -0.300 range of
>>>>> BER constantly from 0 to 15 dB range of SNR values.No variations are
>>>>> happening.
>>>>>
>>>>> How can I check the functionality of the block(encoder and decoder to
>>>>> check whether it's encoding and decoding properly)with a sample input.
>>>>>
>>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>>
>>>>>> One other thing I noticed is that the encode CCSDS, decode, CCSDS,
>>>>>> and BER blocks all  operate on packed bytes. (See e.g.
>>>>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do
>>>>>> this you would change your random source to output from 0 to 256 byte
>>>>>> values. Also, considering the output of the decoder block are packed 
>>>>>> bytes
>>>>>> you should probably skip the byte->float and binary slicer after your
>>>>>> decoder and just input it's output directly into the BER block. Finally,
>>>>>> looking at the
>>>>>> https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>>>>>> seems the delay out of the decoder is 4 bytes, so you could add a delay 
>>>>>> of
>>>>>> 4 between your source and BER block to align the two streams.
>>>>>>
>>>>>> Jared.
>>>>>>
>>>>>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>>>>>
>>>>>>> One thing I think might be an issue is that you have no delay
>>>>>>> between your source reference and your BER block. Usually the FEC 
>>>>>>> decoders
>>>>>>> (and possibly the encoder?) may output blocks of 0s before they output 
>>>>>>> the
>>>>>>> samples that correspond to your inputs. I don't know much about those 
>>>>>>> FEC
>>>>>>> blocks specifically, but maybe the docs have some info on their delays. 
>>>>>>> You
>>>>>>> can just insert a delay block b/w your random source and the ber block 
>>>>>>> to
>>>>>>> align the input and output bits.
>>>>>>>
>>>>>>> Hope that helps,
>>>>>>> Jared.
>>>>>>>
>>>>>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson <
>>>>>>> jiyajohnso...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> [image: image.png]
>>>>>>>> Dear community
>>>>>>>>Need help for BER plot using the above flowgraph its always
>>>>>>>> coming 10^-1.17 and whenever I tried to change the noise voltage the 
>>>>>>>> values
>>>>>>>> are not changing.
>>>>>>>> Please find the attached GRC file for your reference.
>>>>>>>>
>>>>>>>> *Regards, JIYA JOHNSON*
>>>>>>>>
>>>>>>>>

Re: CCSDS BER PLOT

[U L]

I don't understand what this means. How do you interpret it?
Jared.


On Fri, Aug 18, 2023 at 8:25 PM Jiya Johnson 
wrote:

>
> On Sat, Aug 19, 2023, 7:54 AM Jiya Johnson 
> wrote:
>
>> I have tried to do with a simple input 11011101 without noise and with
>> noise noise also
>>
>> On Sat, Aug 19, 2023, 7:52 AM U L  wrote:
>>
>>> Some ideas:
>>>
>>> 1. Remove the noise completely. Also use a fixed, repeating input vector
>>> rather than random bytes. Look at the actual error patterns between the
>>> input and output bits. Sometimes error patterns can clue you in.
>>> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
>>> 3. Try the more general (non-CCSDS) extended encoder with the same
>>> params as the decoder.
>>> 4. Esp if 3 works, compare the output of CCSDS with general extended
>>> encoder.
>>>
>>> Good luck.
>>> Jared.
>>>
>>> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
>>> wrote:
>>>
>>>> Hi,
>>>> Based on the given modifications still I am getting a -0.300 range of
>>>> BER constantly from 0 to 15 dB range of SNR values.No variations are
>>>> happening.
>>>>
>>>> How can I check the functionality of the block(encoder and decoder to
>>>> check whether it's encoding and decoding properly)with a sample input.
>>>>
>>>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>>>
>>>>> One other thing I noticed is that the encode CCSDS, decode, CCSDS, and
>>>>> BER blocks all  operate on packed bytes. (See e.g.
>>>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do
>>>>> this you would change your random source to output from 0 to 256 byte
>>>>> values. Also, considering the output of the decoder block are packed bytes
>>>>> you should probably skip the byte->float and binary slicer after your
>>>>> decoder and just input it's output directly into the BER block. Finally,
>>>>> looking at the
>>>>> https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>>>>> seems the delay out of the decoder is 4 bytes, so you could add a delay of
>>>>> 4 between your source and BER block to align the two streams.
>>>>>
>>>>> Jared.
>>>>>
>>>>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>>>>
>>>>>> One thing I think might be an issue is that you have no delay between
>>>>>> your source reference and your BER block. Usually the FEC decoders (and
>>>>>> possibly the encoder?) may output blocks of 0s before they output the
>>>>>> samples that correspond to your inputs. I don't know much about those FEC
>>>>>> blocks specifically, but maybe the docs have some info on their delays. 
>>>>>> You
>>>>>> can just insert a delay block b/w your random source and the ber block to
>>>>>> align the input and output bits.
>>>>>>
>>>>>> Hope that helps,
>>>>>> Jared.
>>>>>>
>>>>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>> [image: image.png]
>>>>>>> Dear community
>>>>>>>Need help for BER plot using the above flowgraph its always
>>>>>>> coming 10^-1.17 and whenever I tried to change the noise voltage the 
>>>>>>> values
>>>>>>> are not changing.
>>>>>>> Please find the attached GRC file for your reference.
>>>>>>>
>>>>>>> *Regards, JIYA JOHNSON*
>>>>>>>
>>>>>>>

Re: CCSDS BER PLOT

[Jiya Johnson]

I have tried to do with a simple input 11011101 without noise and with
noise noise also

On Sat, Aug 19, 2023, 7:52 AM U L  wrote:

> Some ideas:
>
> 1. Remove the noise completely. Also use a fixed, repeating input vector
> rather than random bytes. Look at the actual error patterns between the
> input and output bits. Sometimes error patterns can clue you in.
> 2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
> 3. Try the more general (non-CCSDS) extended encoder with the same params
> as the decoder.
> 4. Esp if 3 works, compare the output of CCSDS with general extended
> encoder.
>
> Good luck.
> Jared.
>
> On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
> wrote:
>
>> Hi,
>> Based on the given modifications still I am getting a -0.300 range of BER
>> constantly from 0 to 15 dB range of SNR values.No variations are happening.
>>
>> How can I check the functionality of the block(encoder and decoder to
>> check whether it's encoding and decoding properly)with a sample input.
>>
>> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>>
>>> One other thing I noticed is that the encode CCSDS, decode, CCSDS, and
>>> BER blocks all  operate on packed bytes. (See e.g.
>>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do this
>>> you would change your random source to output from 0 to 256 byte values.
>>> Also, considering the output of the decoder block are packed bytes you
>>> should probably skip the byte->float and binary slicer after your decoder
>>> and just input it's output directly into the BER block. Finally, looking at
>>> the https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>>> seems the delay out of the decoder is 4 bytes, so you could add a delay of
>>> 4 between your source and BER block to align the two streams.
>>>
>>> Jared.
>>>
>>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>>
>>>> One thing I think might be an issue is that you have no delay between
>>>> your source reference and your BER block. Usually the FEC decoders (and
>>>> possibly the encoder?) may output blocks of 0s before they output the
>>>> samples that correspond to your inputs. I don't know much about those FEC
>>>> blocks specifically, but maybe the docs have some info on their delays. You
>>>> can just insert a delay block b/w your random source and the ber block to
>>>> align the input and output bits.
>>>>
>>>> Hope that helps,
>>>> Jared.
>>>>
>>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson 
>>>> wrote:
>>>>
>>>>>
>>>>> [image: image.png]
>>>>> Dear community
>>>>>Need help for BER plot using the above flowgraph its always coming
>>>>> 10^-1.17 and whenever I tried to change the noise voltage the values are
>>>>> not changing.
>>>>> Please find the attached GRC file for your reference.
>>>>>
>>>>> *Regards, JIYA JOHNSON*
>>>>>
>>>>>

Re: CCSDS BER PLOT

[U L]

Some ideas:

1. Remove the noise completely. Also use a fixed, repeating input vector
rather than random bytes. Look at the actual error patterns between the
input and output bits. Sometimes error patterns can clue you in.
2. Check symbol polarity (i.e. 0=>-1, 1=>1, or 0=>1, 1=>-1)
3. Try the more general (non-CCSDS) extended encoder with the same params
as the decoder.
4. Esp if 3 works, compare the output of CCSDS with general extended
encoder.

Good luck.
Jared.

On Fri, Aug 18, 2023 at 8:04 PM Jiya Johnson 
wrote:

> Hi,
> Based on the given modifications still I am getting a -0.300 range of BER
> constantly from 0 to 15 dB range of SNR values.No variations are happening.
>
> How can I check the functionality of the block(encoder and decoder to
> check whether it's encoding and decoding properly)with a sample input.
>
> On Sun, Aug 13, 2023, 8:11 PM U L  wrote:
>
>> One other thing I noticed is that the encode CCSDS, decode, CCSDS, and
>> BER blocks all  operate on packed bytes. (See e.g.
>> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do this
>> you would change your random source to output from 0 to 256 byte values.
>> Also, considering the output of the decoder block are packed bytes you
>> should probably skip the byte->float and binary slicer after your decoder
>> and just input it's output directly into the BER block. Finally, looking at
>> the https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
>> seems the delay out of the decoder is 4 bytes, so you could add a delay of
>> 4 between your source and BER block to align the two streams.
>>
>> Jared.
>>
>> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>>
>>> One thing I think might be an issue is that you have no delay between
>>> your source reference and your BER block. Usually the FEC decoders (and
>>> possibly the encoder?) may output blocks of 0s before they output the
>>> samples that correspond to your inputs. I don't know much about those FEC
>>> blocks specifically, but maybe the docs have some info on their delays. You
>>> can just insert a delay block b/w your random source and the ber block to
>>> align the input and output bits.
>>>
>>> Hope that helps,
>>> Jared.
>>>
>>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson 
>>> wrote:
>>>
>>>>
>>>> [image: image.png]
>>>> Dear community
>>>>Need help for BER plot using the above flowgraph its always coming
>>>> 10^-1.17 and whenever I tried to change the noise voltage the values are
>>>> not changing.
>>>> Please find the attached GRC file for your reference.
>>>>
>>>> *Regards, JIYA JOHNSON*
>>>>
>>>>

Re: CCSDS BER PLOT

[Jiya Johnson]

Hi,
Based on the given modifications still I am getting a -0.300 range of BER
constantly from 0 to 15 dB range of SNR values.No variations are happening.

How can I check the functionality of the block(encoder and decoder to check
whether it's encoding and decoding properly)with a sample input.

On Sun, Aug 13, 2023, 8:11 PM U L  wrote:

> One other thing I noticed is that the encode CCSDS, decode, CCSDS, and BER
> blocks all  operate on packed bytes. (See e.g.
> https://wiki.gnuradio.org/index.php?title=Encode_CCSDS_27). To do this
> you would change your random source to output from 0 to 256 byte values.
> Also, considering the output of the decoder block are packed bytes you
> should probably skip the byte->float and binary slicer after your decoder
> and just input it's output directly into the BER block. Finally, looking at
> the https://wiki.gnuradio.org/index.php?title=Decode_CCSDS_27 page it
> seems the delay out of the decoder is 4 bytes, so you could add a delay of
> 4 between your source and BER block to align the two streams.
>
> Jared.
>
> On Sat, Aug 12, 2023 at 9:58 PM U L  wrote:
>
>> One thing I think might be an issue is that you have no delay between
>> your source reference and your BER block. Usually the FEC decoders (and
>> possibly the encoder?) may output blocks of 0s before they output the
>> samples that correspond to your inputs. I don't know much about those FEC
>> blocks specifically, but maybe the docs have some info on their delays. You
>> can just insert a delay block b/w your random source and the ber block to
>> align the input and output bits.
>>
>> Hope that helps,
>> Jared.
>>
>> On Sat, Aug 12, 2023 at 4:28 AM Jiya Johnson 
>> wrote:
>>
>>>
>>> [image: image.png]
>>> Dear community
>>>Need help for BER plot using the above flowgraph its always coming
>>> 10^-1.17 and whenever I tried to change the noise voltage the values are
>>> not changing.
>>> Please find the attached GRC file for your reference.
>>>
>>> *Regards, JIYA JOHNSON*
>>>
>>>

CCSDS encoder-decoder BER Plot

[Jiya Johnson]

Hello GNU Radio community i tried to plot BER vs SNR by using the below
given GRC file ,I am not getting the results which is similar to the
conventional encoder/decoder ,CCSDS encoder/decoder in CCSDS standards .It
will be helpful for me to make suggestions to improve the same

options:
  parameters:
author: jiyaj
catch_exceptions: 'True'
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: CHECKCCSDS
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: 27-07-2023
window_size: (1000,1000)
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: noise_stdv
  id: variable_qtgui_range
  parameters:
comment: ''
gui_hint: ''
label: Noise Amplitude
min_len: '500'
orient: QtCore.Qt.Horizontal
rangeType: float
start: '0'
step: '.01'
stop: '40'
value: '0'
widget: counter_slider
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1488, 16.0]
rotation: 0
state: enabled
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: '32000'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [248, 16.0]
rotation: 0
state: enabled
- name: variable_cc_decoder_def_0
  id: variable_cc_decoder_def
  parameters:
comment: ''
dim1: '1'
dim2: '1'
framebits: '8'
k: '7'
mode: fec.CC_TERMINATED
ndim: '0'
padding: 'False'
polys: '[109,79]'
rate: '2'
state_end: '-1'
state_start: '0'
value: '"ok"'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1136, 12.0]
rotation: 0
state: true
- name: variable_ccsds_encoder_def_0
  id: variable_ccsds_encoder_def
  parameters:
comment: ''
dim1: '1'
dim2: '1'
framebits: '8'
mode: fec.CC_TERMINATED
ndim: '0'
state_start: '0'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [384, 12.0]
rotation: 0
state: enabled
- name: variable_constellation_0
  id: variable_constellation
  parameters:
comment: ''
const_points: '[ -1+1j, 1+1j]'
dims: '1'
normalization: digital.constellation.AMPLITUDE_NORMALIZATION
precision: '8'
rot_sym: '1'
soft_dec_lut: None
sym_map: '[1, -1]'
type: calcdist
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [760, 8.0]
rotation: 0
state: true
- name: analog_fastnoise_source_x_0
  id: analog_fastnoise_source_x
  parameters:
affinity: ''
alias: ''
amp: noise_stdv
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
noise_type: analog.GR_GAUSSIAN
samples: '8192'
seed: '0'
type: complex
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [656, 1364.0]
rotation: 0
state: enabled
- name: blocks_add_xx_0
  id: blocks_add_xx
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
num_inputs: '2'
type: complex
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1176, 1320.0]
rotation: 0
state: enabled
- name: blocks_char_to_float_0
  id: blocks_char_to_float
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
scale: '1'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [1680, 448.0]
rotation: 0
state: disabled
- name: blocks_char_to_float_0_0
  id: blocks_char_to_float
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
scale: '1'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [3768, 360.0]
rotation: 0
state: disabled
- name: blocks_char_to_float_0_1
  id: blocks_char_to_float
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
scale: '1'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [2552, 728.0]
rotation: 0
state: enabled
- name: blocks_char_to_float_1
  id: blocks_char_to_float
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
scale: '1'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [4320, 136.0]
rotation: 0
state: true
- name: blocks_char_

Having some basic trouble generating BER for GMSK

[Chris Devries]

It seems that the stream will slip and get out of sync with the slightest bit 
of noise added.  I've searched for a solution but how can one do a basic error 
rate simulation which seems that it would require the 2 streams to be some how 
synchronized.  I'm fairly new to gnuradio so not sure if there is a mechanism 
for synchronizing or if I should be doing something else to test my output 
stream to look for bit errors.

Or am I going about this the wrong way?  My goal is to build a GMSK receiver 
and test it will an ideal source and channel model, and then use it in a live 
scenario.

Chris


gmsk_demod_tb.grc
Description: gmsk_demod_tb.grc

Re: How to plot BER vs SNR in GNU Radio

[farhan pishe]

Thank you for your reply.

That is not the point! Because the BER should decrease by increasing the
SNR value for any modulation scheme, but it doesn't happen (even by
omitting the CRC).

Regards,
Farhan

On Sun, Oct 4, 2020 at 4:27 PM Tim Huggins 
wrote:

> The OFDM simulations as written in the examples contain CRCs. I’ve
> tinkered with the OFDM examples a bit lately and while I may be completely
> mistaken I. believe the examples as written will only pass data that passes
> CRC so you may not actually ever see but errors.
>
> Tim
>
> On Oct 3, 2020, at 9:57 AM, farhan pishe  wrote:
>
> 
> Barry, thank you so much for your time, but unfortunately, it wasn't
> helpful for me and still, I am seeking a way to plot the BER vs SNR. I
> don't know what is wrong with GNU Radio! Even it doesn't have complete
> documentation so that I can understand how to do things like this. I hope
> that someone guides me in a clear way. I want to plot a BER vs SNR for the
> OFDM simulation which already exists as one of the examples of GNU Radio,
> but it gives me constant line.
>
> On Tue, Sep 29, 2020 at 3:50 PM Barry Duggan  wrote:
>
>> Farhan,
>>
>> I don't know much about BER curves, but this example may help you some:
>>
>> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/examples/ber_curve_gen.grc
>>
>> Also search the archives of this newsletter. IIRC, there is a discussion
>> about the bus inputs.
>>
>> Remember to CC discuss-gnuradio in your reply. I forgot on the first
>> time for this!
>>
>> ---
>> Barry Duggan KV4FV
>> https://github.com/duggabe
>>
>> On Tue, 29 Sep 2020 00:00:51 +0330, farhan pishe wrote:
>>
>> Hello,
>>
>> I am trying to plot the BER vs Es/N0 using QT Bercurve Sink which has 16
>> inputs. But the result is always a constant line and I don't know the
>> reason and it is blowing my mind. Also, I don't know whether there is an
>> alternative way to plot BER vs SNR. I would really appreciate it if
>> anyone could help me in this regard. I just want to plot a simple bit
>> error rate curve.
>>
>> Regards,
>> Farhan
>>
>

Re: How to plot BER vs SNR in GNU Radio

[farhan pishe]

Barry, thank you so much for your time, but unfortunately, it wasn't
helpful for me and still, I am seeking a way to plot the BER vs SNR. I
don't know what is wrong with GNU Radio! Even it doesn't have complete
documentation so that I can understand how to do things like this. I hope
that someone guides me in a clear way. I want to plot a BER vs SNR for the
OFDM simulation which already exists as one of the examples of GNU Radio,
but it gives me constant line.

On Tue, Sep 29, 2020 at 3:50 PM Barry Duggan  wrote:

> Farhan,
>
> I don't know much about BER curves, but this example may help you some:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-fec/examples/ber_curve_gen.grc
>
> Also search the archives of this newsletter. IIRC, there is a discussion
> about the bus inputs.
>
> Remember to CC discuss-gnuradio in your reply. I forgot on the first
> time for this!
>
> ---
> Barry Duggan KV4FV
> https://github.com/duggabe
>
> On Tue, 29 Sep 2020 00:00:51 +0330, farhan pishe wrote:
>
> Hello,
>
> I am trying to plot the BER vs Es/N0 using QT Bercurve Sink which has 16
> inputs. But the result is always a constant line and I don't know the
> reason and it is blowing my mind. Also, I don't know whether there is an
> alternative way to plot BER vs SNR. I would really appreciate it if
> anyone could help me in this regard. I just want to plot a simple bit
> error rate curve.
>
> Regards,
> Farhan
>

Re: How to plot BER vs SNR in GNU Radio

[Barry Duggan]

Farhan,

I don't know much about BER curves, but this example may help you some: 
https://github.com/gnuradio/gnuradio/blob/master/gr-fec/examples/ber_curve_gen.grc


Also search the archives of this newsletter. IIRC, there is a discussion 
about the bus inputs.


Remember to CC discuss-gnuradio in your reply. I forgot on the first 
time for this!


---
Barry Duggan KV4FV
https://github.com/duggabe

On Tue, 29 Sep 2020 00:00:51 +0330, farhan pishe wrote:

Hello,

I am trying to plot the BER vs Es/N0 using QT Bercurve Sink which has 16 
inputs. But the result is always a constant line and I don't know the 
reason and it is blowing my mind. Also, I don't know whether there is an 
alternative way to plot BER vs SNR. I would really appreciate it if 
anyone could help me in this regard. I just want to plot a simple bit 
error rate curve.


Regards,
Farhan

How to plot BER vs SNR in GNU Radio

[farhan pishe]

Hello,

I am trying to plot the BER vs Es/N0 using QT Bercurve Sink which has 16
inputs. But the result is always a constant line and I don't know the
reason and it is blowing my mind. Also, I don't know whether there is an
alternative way to plot BER vs SNR. I would really appreciate it if anyone
could help me in this regard. I just want to plot a simple bit error rate
curve.

Regards,
Farhan

Re: Questions about how to observe BER using CPFSK modulation

[Christophe Seguinot]

  
  
Hi 


  -0.3 correspond to 0.5=10^-0.3 error rate which is the maximum
error rate obtained when demodulation is completely wrong. 
  
  You must use a delay in your input bytes (between throttle and
BER block) so that receives bytes are synchronized with emitted
bytes. 
  
  Since no synchronization is used here, even if bits are
decoded without error, there is absolutely no warranty that
unpacking one byte (give 8 bits), repacking 8 bits latter in the
freceiver give the same byte (because whitout synchronization,
the 8 repacked bits are no the same as the 8 unpacked bits) .

I would suggest: 


  add a delay on emitted bits (not bytes) 
  
  compare emitted and received bits (bit_stream QT time sink) to
find the delay between them
  compute BER from these 2 bit sstreams
  

On 10/09/2020 13:02, Hiroki Sagara
  wrote:


  
  Hello everyone!
I wanted to observe the error rate when using CPFSK modulation,
so I created a flow graph as shown in the figure.
As a result, the output of the "BER block" did not change from
-0.3 even if the noise increased or decreased.
(Voice communication using CVSD vocoder can be done without any
problem, so I think the error rate is not so high ...)

How can I observe it correctly?

Thank you.
  

  

BER calculation - GMSK Demod

[Artur Nogueira]

Hello,

I am simulating a simple GMSK modulation/demodulation process, without any
channel model, in order to evaluate the BER under normal conditions and
with noise. I would like to have your opinion about the way I calculate the
BER: is it correct? Is there a better way to do it?

Here a brief description of the problem:
I created the following input binary sequence: 1110011100 as a .bin file
and I loaded it in the File Source block. Then, I fed the GMSK Mod block
with this binary sequence, I added noise to it and then I sent the
resulting signal to a GMSK Demod unit. Finally, I saved the output sequence
in a .bin file by means of File Sink block.

Apparently, the GMSK Demod block creates 8-bit packets for each input bit,
by allocating them in the LSB position. In this case, instead of
calculating the BER, I am calculating the PER (Packet Error Rate), by
comparing the 0's with  and 1's with 0001. And when I add noise
to the model, the output sequence is modified (as expected).

In this case, I am proceeding with the same methodology for the PER
calculation so every time a non-zero bit appears between the 1st and 7th
position of a byte (ex: 0100), I suppose this is caused by noise and I
count it as a wrong packet.

Does my analysis make sense? Is there a more practical or correct way of
evaluating the BER/PER?

Thanks.

Best regards,
Artur

Re: BER Calculations with QPSK Modulation and USRP

[Derek Kozel]

Hi John,

You'll almost certainly need to add a header to your data so you can
synchronize the start of the transmission.

On 05/03/2020 20:20, John Bauer wrote:
> Hello,
>
> I followed the PSK Demodulation tutorial, verified the results then
> made some changes so I could use it with a USRP B210. To do this I
> removed the channel and throttle blocks, and replaced them with the
> USRP Source and Sink blocks. I now would like to use a file as the
> data source and use a file sink to compare bit error rates of the
> transmitted data. However, it seems like the data is being shifted and
> I am unable to make sense of the received data. What changes must be
> made to perform the BER calculations?
>
> Thanks for your help,
> John
>

BER Calculations with QPSK Modulation and USRP

[John Bauer]

Hello,

I followed the PSK Demodulation tutorial, verified the results then made
some changes so I could use it with a USRP B210. To do this I removed the
channel and throttle blocks, and replaced them with the USRP Source and
Sink blocks. I now would like to use a file as the data source and use a
file sink to compare bit error rates of the transmitted data. However, it
seems like the data is being shifted and I am unable to make sense of the
received data. What changes must be made to perform the BER calculations?

Thanks for your help,
John

Re: BER OF OFDM

[CEL]

Hi Madhan,
On Wed, 2020-01-29 at 06:13 -0800, Madhan TJ wrote:
> DEAR SIR,

several ladies on this mailing list, too!

> I am doing project on ofdm,so i need to calculate BER for different
> modulation techniques

Awesome, doing that sounds fine, because an OFDM system typically makes
it easy to find frames and thus achieve in- and output bitstream
synchronization so you can compare them

> While doing this i got Random values of BER for Modulation Techniques
> which is not relatable with theory

so, you've got a problem with your BER calculation

> PLS help me to figure out the error 
> The screenshot and grc file is attached with this mail.

So, you're using blocks from the "deprecated" category: the OFDM Mod
and OFDM Demod.

Those are broken. Use the modern OFDM infrastructure. Examples of that
are found in /usr/share/gnuradio/examples/digital/rx_ofdm.grc,
tx_ofdm.grc, ofdm_loopback.grc (or wherever these are installed to on
your machine). NO, there's no way around this.

Also, don't use WX GUI, it's not maintained anymore, use Qt.

You might also want to upgrade to a non-legacy GNU Radio:

https://launchpad.net/~gnuradio/+archive/ubuntu/gnuradio-releases

Best regards,
Marcus

Re: [Discuss-gnuradio] ber calculation

[CEL]

Hi Anubhav,

we have absolutely no idea what you're looking at. You'll have to
describe what you're doing in great detail.

Best regards,
Marcus

On Mon, 2019-04-22 at 12:29 +0530, ANUBHAV CHOUDHARY wrote:
> Can someone please help in calculating the ber?
> I think there Is delay mismatch in ref signal port and input signal
> port so how to calculate that delay?
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] ber calculation

[ANUBHAV CHOUDHARY]

Can someone please help in calculating the ber?

I think there Is delay mismatch in ref signal port and input signal port so
how to calculate that delay?

-- 

Thanx and regards,

Anubhav

M.tech(Telecommunications System Engineering)

E Department

IIT Kharagpur
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Packetloss and Ber simulation using OFDM

[Sai Parepalli Laxman]

Hmm I agree a cleanup is necessary.

Will get back.

Thank you guys.

On Wed, Feb 27, 2019 at 13:47 Michael Dickens 
wrote:

> I'll second what Marcus said: a little tidier GRC flowgraph would help.
>
> That said, it looks like you're using nice and simple GR OFDM for Tx and
> then you've expanded the GR OFDM Rx into its hier block equivalent form ...
> then connected the output to PER and BER blocks and output those results to
> the Qt GUI. I can't say for certain that all of the parameters are "stock",
> but those I can see look like they are. Is this correct?
>
> What I'm wondering is where you're seeing the "55db drop in the signal"
> you specifically note? GR's default OFDM has zeros in the frequency
> spectrum in some locations. I don't see anything specifically "wrong" nor
> "out of place" with the spectrum you posted, but since this is just a
> screenshot it's difficult to tell what's going on beyond that it's an OFDM
> waveform. Hence my query to what exactly you're referring.
>
> Hope this is useful! - MLD
>
> On Wed, Feb 27, 2019, at 1:32 PM, Müller, Marcus (CEL) wrote:
>
> Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph.
> I've been staring at it for a while, and it's just too confusing.
>
> Best regards,
> Marcus
>
> On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote:
> > Hello,
> >
> > This is Nishant.
> >
> > I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter
> boards. I have an unexplained 55db  drop in the signal where a signal with
> amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB
> peak on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong
> or something that I am not doing right.
> >
> > I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000
> >
> > I have attached the flowgraph and the transmitter output below.
>
>
> ___
> 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] Packetloss and Ber simulation using OFDM

[Michael Dickens]

I'll second what Marcus said: a little tidier GRC flowgraph would help.

That said, it looks like you're using nice and simple GR OFDM for Tx and then 
you've expanded the GR OFDM Rx into its hier block equivalent form ... then 
connected the output to PER and BER blocks and output those results to the Qt 
GUI. I can't say for certain that all of the parameters are "stock", but those 
I can see look like they are. Is this correct?

What I'm wondering is where you're seeing the "55db drop in the signal" you 
specifically note? GR's default OFDM has zeros in the frequency spectrum in 
some locations. I don't see anything specifically "wrong" nor "out of place" 
with the spectrum you posted, but since this is just a screenshot it's 
difficult to tell what's going on beyond that it's an OFDM waveform. Hence my 
query to what exactly you're referring.

Hope this is useful! - MLD

On Wed, Feb 27, 2019, at 1:32 PM, Müller, Marcus (CEL) wrote:
> Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph.
> I've been staring at it for a while, and it's just too confusing.
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote:
> > Hello,
> > 
> > This is Nishant. 
> > 
> > I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter 
> > boards. I have an unexplained 55db drop in the signal where a signal with 
> > amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB 
> > peak on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong 
> > or something that I am not doing right. 
> > 
> > I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000
> > 
> > I have attached the flowgraph and the transmitter output below.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Packetloss and Ber simulation using OFDM

[CEL]

Hi Nishant, I'm afraid you'll have to first tidy up your flowgraph.
I've been staring at it for a while, and it's just too confusing.

Best regards,
Marcus

On Wed, 2019-02-27 at 11:41 -0500, Sai Parepalli Laxman wrote:
> Hello,
> 
> This is Nishant. 
> 
> I have a pair of N210 USRP modules and two pairs of LFTX/LFRX daughter 
> boards. I have an unexplained 55db  drop in the signal where a signal with 
> amplitude bounded between -1 to 1, shows a -30db peak rather than a 0 dB peak 
> on Qt GUI Frequency Sink and I am wondering if the amplifier is wrong or 
> something that I am not doing right.  
> 
> I am using Ubuntu 18.04.1 gnuradio version 3.7.11 and UHD_003.010.003.000
> 
> I have attached the flowgraph and the transmitter output below.
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

On 1/28/19 8:49 AM, Luis Felipe Albarracin Sanchez wrote:
> Hello Cinaed,
> 
> Thank you for the response,
> 
> I have detailed your Flowgraph, and I placed a "QT GUI Constellation
> Sink" after the chunks to symbols block, and what I found is that the
> modulation part only modulates in B-PSK, and this is beacuse you set it 
> in the "Chunks to symbol block" with a dimension of "1", once I placed
> different "Symbol Table" and a "dimension" of 2 in the "Chunk to symbol
> block" the correct modulation appeared, but the BER gave really high
> values (even if in the "Constellation Decoder" is set to  QPSK or DQPSK).

I already answered this - it's documented on the flowgraph - and I
answered it in a previous email.

BER only has 2 points - 0,1 - the constellation points aren't used.

The 8PSK decoder outputs 1,0 which creates an inverted pulse relative to
the reference input to the BER - the random number generator - and the
BER sky rockets.

So instead of using -1,1 in the chunks to symbols, I had to use 1,-1.

Is my flowgraph the correct way to calculate the BER? I have no idea.
The only thing I can say about it is the BER is 0 without white noise.

I've never done a BER calculation. When the BER is high on physical
MODEM I buy a new one.

The only thing I know is if you want to calculated bit error rate on the
order of ppm after adding white noise, and the computational error
without adding white noise is on the order percent, then the BER after
adding white noise would be impossible to detect.

And I know very little about QT - I just use the QT GUI blocks for
debugging.

But my intuition tells me you can't change the modulation object on the
fly while the flowgraph is running - but don't let that stop you from
trying.

> 
> I believe you only modulated in BPSK and in the decoder it matched the
> constellation points for -1 and 1, but not for any other constellation
> points, I would appreciate if you correct me if i am wrong.
> 
> Kind regards.
> 
> On Mon, Jan 28, 2019 at 5:12 AM Cinaed Simson  <mailto:cinaed.sim...@gmail.com>> wrote:
> 
>     On 1/27/19 7:03 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed,
> >
> > Thank you so much for all the work in the BER, i tested both of the
> > flowgraphs and they are very accurate regarding the BER
> measurements, i
> > have a couple of questions if you don´t mind:
> >
> > 1- In the latest flowgraph you sent (my-ber-test.grc from Jan
> 25th) how
> > do you change the modulations in the chunks to symbols block, in the
> > flowgraph you sent me the flowgraph table was fixed with the values of
> > "-1, 1", what line of commands should be place there to switch to
> other
> > modulations?
> 
> Correct - I already explain why.
> >
> > 2- The BER measurements you sent me seem so accurate,
> 
> As I already indicated, you still need to add a complex gaussian noise
> source.
> 
>  I wonder if you
> > could take a look at the flowgraph i sent you
> 
> No, use the last flowgraph I sent you.
> 
> 
> > (my_ber_simulation_LFA.grc), what i did there was connecting a QT GUI
> > Chooser to the functions i thougth would change the constellation
> > selected,  do you have any ideas why  my change is not working, when i
> > change in the QT GUI Chooser?, i would appreciate your help
> regarding this.
> >
> > 3- Attached is a flowgraph i have devloped for doing modulations up to
> > 64 QAM, please take a look at it, and if you have any ideas on how i
> > would make a good BER measurement of higher modulations (32 -QAM and
> > 64-QAM) please let me know. To select the modulatios, the easiest
> way is
> > to define in the default value of the QT GUI chooser the value of
> 3 (for
> > 32-QAM) and the value of 4 (for 64 QAM).
> 
> I not going to look your flowgraph - you should be able to add the QAM
> constellations to the last flowgraph I sent you.
> 
> And to be clear, I don't believe can change the modulation of the
> flowgraph with QT. Since you're the believer, the burden of proof is on
> you.
> 
> You need to first demonstrate you can add the 64QAM, and 32QAM to the
> last flowgraph I sent you with DER 0.
> 
> Then add whatever QT modifications you need to make QT change the
> modulation and demonstrate the BER is 0.
> 
> Or just demonstrate you can add QT code which changes the modulation to
> last flowgraph I set you. If can't make the changes so it has BER of 0,
> adding differ

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Luis Felipe Albarracin Sanchez]

Hello Cinaed,

Thank you for the response,

I have detailed your Flowgraph, and I placed a "QT GUI Constellation Sink"
after the chunks to symbols block, and what I found is that the modulation
part only modulates in B-PSK, and this is beacuse you set it  in the
"Chunks to symbol block" with a dimension of "1", once I placed different
"Symbol Table" and a "dimension" of 2 in the "Chunk to symbol block" the
correct modulation appeared, but the BER gave really high values (even if
in the "Constellation Decoder" is set to  QPSK or DQPSK).

I believe you only modulated in BPSK and in the decoder it matched the
constellation points for -1 and 1, but not for any other constellation
points, I would appreciate if you correct me if i am wrong.

Kind regards.

On Mon, Jan 28, 2019 at 5:12 AM Cinaed Simson 
wrote:

> On 1/27/19 7:03 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed,
> >
> > Thank you so much for all the work in the BER, i tested both of the
> > flowgraphs and they are very accurate regarding the BER measurements, i
> > have a couple of questions if you don´t mind:
> >
> > 1- In the latest flowgraph you sent (my-ber-test.grc from Jan 25th) how
> > do you change the modulations in the chunks to symbols block, in the
> > flowgraph you sent me the flowgraph table was fixed with the values of
> > "-1, 1", what line of commands should be place there to switch to other
> > modulations?
>
> Correct - I already explain why.
> >
> > 2- The BER measurements you sent me seem so accurate,
>
> As I already indicated, you still need to add a complex gaussian noise
> source.
>
>  I wonder if you
> > could take a look at the flowgraph i sent you
>
> No, use the last flowgraph I sent you.
>
>
> > (my_ber_simulation_LFA.grc), what i did there was connecting a QT GUI
> > Chooser to the functions i thougth would change the constellation
> > selected,  do you have any ideas why  my change is not working, when i
> > change in the QT GUI Chooser?, i would appreciate your help regarding
> this.
> >
> > 3- Attached is a flowgraph i have devloped for doing modulations up to
> > 64 QAM, please take a look at it, and if you have any ideas on how i
> > would make a good BER measurement of higher modulations (32 -QAM and
> > 64-QAM) please let me know. To select the modulatios, the easiest way is
> > to define in the default value of the QT GUI chooser the value of 3 (for
> > 32-QAM) and the value of 4 (for 64 QAM).
>
> I not going to look your flowgraph - you should be able to add the QAM
> constellations to the last flowgraph I sent you.
>
> And to be clear, I don't believe can change the modulation of the
> flowgraph with QT. Since you're the believer, the burden of proof is on
> you.
>
> You need to first demonstrate you can add the 64QAM, and 32QAM to the
> last flowgraph I sent you with DER 0.
>
> Then add whatever QT modifications you need to make QT change the
> modulation and demonstrate the BER is 0.
>
> Or just demonstrate you can add QT code which changes the modulation to
> last flowgraph I set you. If can't make the changes so it has BER of 0,
> adding different of more modulations isn't going to help.
>
> -- Cinaed
>
>
> >
> >
> > Once again thanks a lot for all the help.
> >
> > Kind regards.
> >
> > On Fri, Jan 25, 2019 at 3:20 PM Cinaed Simson  > <mailto:cinaed.sim...@gmail.com>> wrote:
> >
> > It bothered me that the random source wasn't working.
> >
> > So I took at it again last night and discovered I needed to unpack a
> bit
> > from the random source stream.
> >
> > Using the random source, the following work:
> >
> >   BPSK
> >   QPSK
> >   8PSK
> >   16QAM
> >
> > using the pull down menu.
> >
> > There is, however, one caveat: for 8PSK you have to enable the
> complex
> > Multiply Const by -1 block after the Chunks to Symbols block.
> >
> > Alternatively, you could change Chunks to Symbols from -1,1 to 1,-1 -
> > but that's many more key strokes then just enabling and disabling the
> > Multiply Const block.
> >
> > They all work with the GLFSR source too and with the same caveat.
> >
> > And you were right you don't need the PSK symbol table - you can use
> > Chunks to Symbols -1,1 (except for 8PKS.)
> >
> > Also, I had to add a unpack k=1 block after the decoder - otherwise
> for
> > DPSK, 8PSK and 16QAM there was a vertical offset and BER sky rockets.
>

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

On 1/27/19 7:03 PM, Luis Felipe Albarracin Sanchez wrote:
> Hello Cinaed,
> 
> Thank you so much for all the work in the BER, i tested both of the
> flowgraphs and they are very accurate regarding the BER measurements, i
> have a couple of questions if you don´t mind:
> 
> 1- In the latest flowgraph you sent (my-ber-test.grc from Jan 25th) how
> do you change the modulations in the chunks to symbols block, in the
> flowgraph you sent me the flowgraph table was fixed with the values of
> "-1, 1", what line of commands should be place there to switch to other
> modulations?

Correct - I already explain why.
> 
> 2- The BER measurements you sent me seem so accurate, 

As I already indicated, you still need to add a complex gaussian noise
source.

 I wonder if you
> could take a look at the flowgraph i sent you

No, use the last flowgraph I sent you.


> (my_ber_simulation_LFA.grc), what i did there was connecting a QT GUI
> Chooser to the functions i thougth would change the constellation
> selected,  do you have any ideas why  my change is not working, when i
> change in the QT GUI Chooser?, i would appreciate your help regarding this.
> 
> 3- Attached is a flowgraph i have devloped for doing modulations up to
> 64 QAM, please take a look at it, and if you have any ideas on how i
> would make a good BER measurement of higher modulations (32 -QAM and
> 64-QAM) please let me know. To select the modulatios, the easiest way is
> to define in the default value of the QT GUI chooser the value of 3 (for
> 32-QAM) and the value of 4 (for 64 QAM).

I not going to look your flowgraph - you should be able to add the QAM
constellations to the last flowgraph I sent you.

And to be clear, I don't believe can change the modulation of the
flowgraph with QT. Since you're the believer, the burden of proof is on
you.

You need to first demonstrate you can add the 64QAM, and 32QAM to the
last flowgraph I sent you with DER 0.

Then add whatever QT modifications you need to make QT change the
modulation and demonstrate the BER is 0.

Or just demonstrate you can add QT code which changes the modulation to
last flowgraph I set you. If can't make the changes so it has BER of 0,
adding different of more modulations isn't going to help.

-- Cinaed


> 
> 
> Once again thanks a lot for all the help.
> 
> Kind regards.
> 
> On Fri, Jan 25, 2019 at 3:20 PM Cinaed Simson  <mailto:cinaed.sim...@gmail.com>> wrote:
> 
> It bothered me that the random source wasn't working.
> 
> So I took at it again last night and discovered I needed to unpack a bit
> from the random source stream.
> 
> Using the random source, the following work:
> 
>   BPSK
>   QPSK
>   8PSK
>   16QAM
> 
> using the pull down menu.
> 
> There is, however, one caveat: for 8PSK you have to enable the complex
> Multiply Const by -1 block after the Chunks to Symbols block.
> 
> Alternatively, you could change Chunks to Symbols from -1,1 to 1,-1 -
> but that's many more key strokes then just enabling and disabling the
> Multiply Const block.
> 
> They all work with the GLFSR source too and with the same caveat.
> 
> And you were right you don't need the PSK symbol table - you can use
> Chunks to Symbols -1,1 (except for 8PKS.)
> 
> Also, I had to add a unpack k=1 block after the decoder - otherwise for
> DPSK, 8PSK and 16QAM there was a vertical offset and BER sky rockets.
> 
> The unpack k=1 is not needed for BPSK and QPSK - but it doesn't create
> any problems so I left it enabled.
> 
> You just need to add the complex noise source
> 
> Have fun with QT.
> 
> Actually, there is already a QT menu - the properties of Constellation
> Object. You might want to look at the source - just figure what you need
> to do to keep it open.
> 
> -- Cinaed
> 
> 
> 
> -- 
> Eng. Luis Felipe Albarracin
> Msc. Telematics / MBA
> PMP
> CCNA/CCDA/CCNP/CCDP/CCIP
> ITIL v3 Foundation
> "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Luis Felipe Albarracin Sanchez]

Hello Cinaed,

Thank you so much for all the work in the BER, i tested both of the
flowgraphs and they are very accurate regarding the BER measurements, i
have a couple of questions if you don´t mind:

1- In the latest flowgraph you sent (my-ber-test.grc from Jan 25th) how do
you change the modulations in the chunks to symbols block, in the flowgraph
you sent me the flowgraph table was fixed with the values of "-1, 1", what
line of commands should be place there to switch to other modulations?

2- The BER measurements you sent me seem so accurate,  I wonder if you
could take a look at the flowgraph i sent you (my_ber_simulation_LFA.grc),
what i did there was connecting a QT GUI Chooser to the functions i thougth
would change the constellation selected,  do you have any ideas why  my
change is not working, when i change in the QT GUI Chooser?, i would
appreciate your help regarding this.

3- Attached is a flowgraph i have devloped for doing modulations up to 64
QAM, please take a look at it, and if you have any ideas on how i would
make a good BER measurement of higher modulations (32 -QAM and 64-QAM)
please let me know. To select the modulatios, the easiest way is to define
in the default value of the QT GUI chooser the value of 3 (for 32-QAM) and
the value of 4 (for 64 QAM).


Once again thanks a lot for all the help.

Kind regards.

On Fri, Jan 25, 2019 at 3:20 PM Cinaed Simson 
wrote:

> It bothered me that the random source wasn't working.
>
> So I took at it again last night and discovered I needed to unpack a bit
> from the random source stream.
>
> Using the random source, the following work:
>
>   BPSK
>   QPSK
>   8PSK
>   16QAM
>
> using the pull down menu.
>
> There is, however, one caveat: for 8PSK you have to enable the complex
> Multiply Const by -1 block after the Chunks to Symbols block.
>
> Alternatively, you could change Chunks to Symbols from -1,1 to 1,-1 -
> but that's many more key strokes then just enabling and disabling the
> Multiply Const block.
>
> They all work with the GLFSR source too and with the same caveat.
>
> And you were right you don't need the PSK symbol table - you can use
> Chunks to Symbols -1,1 (except for 8PKS.)
>
> Also, I had to add a unpack k=1 block after the decoder - otherwise for
> DPSK, 8PSK and 16QAM there was a vertical offset and BER sky rockets.
>
> The unpack k=1 is not needed for BPSK and QPSK - but it doesn't create
> any problems so I left it enabled.
>
> You just need to add the complex noise source
>
> Have fun with QT.
>
> Actually, there is already a QT menu - the properties of Constellation
> Object. You might want to look at the source - just figure what you need
> to do to keep it open.
>
> -- Cinaed
>


-- 
Eng. Luis Felipe Albarracin
Msc. Telematics / MBA
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"


Mod_Simple.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

It bothered me that the random source wasn't working.

So I took at it again last night and discovered I needed to unpack a bit
from the random source stream.

Using the random source, the following work:

  BPSK
  QPSK
  8PSK
  16QAM

using the pull down menu.

There is, however, one caveat: for 8PSK you have to enable the complex
Multiply Const by -1 block after the Chunks to Symbols block.

Alternatively, you could change Chunks to Symbols from -1,1 to 1,-1 -
but that's many more key strokes then just enabling and disabling the
Multiply Const block.

They all work with the GLFSR source too and with the same caveat.

And you were right you don't need the PSK symbol table - you can use
Chunks to Symbols -1,1 (except for 8PKS.)

Also, I had to add a unpack k=1 block after the decoder - otherwise for
DPSK, 8PSK and 16QAM there was a vertical offset and BER sky rockets.

The unpack k=1 is not needed for BPSK and QPSK - but it doesn't create
any problems so I left it enabled.

You just need to add the complex noise source

Have fun with QT.

Actually, there is already a QT menu - the properties of Constellation
Object. You might want to look at the source - just figure what you need
to do to keep it open.

-- Cinaed



  Wed Jan 23 13:59:42 2019
  
options

  author
  


  window_size
  


  category
  [GRC Hier Blocks]


  comment
  


  description
  


  _enabled
  True


  _coordinate
  (8, 8)


  _rotation
  0


  generate_options
  qt_gui


  hier_block_src_path
  .:


  id
  top_block


  max_nouts
  0


  qt_qss_theme
  


  realtime_scheduling
  


  run_command
  {python} -u {filename}


  run_options
  prompt


  run
  True


  sizing_mode
  fixed


  thread_safe_setters
  


  title
  


  placement
  (0,0)

  
  
variable_constellation

  comment
  


  const_points
  digital.psk_2()[0]


  type
  16qam


  dims
  digital.bpsk_constellation().dimensionality()


  _enabled
  1


  _coordinate
  (16, 492)


  _rotation
  0


  id
  constel


  rot_sym
  digital.bpsk_constellation().rotational_symmetry()


  soft_dec_lut
  'auto'


  precision
  0


  sym_map
  digital.psk_2()[1]

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (16, 76)


  _rotation
  0


  id
  samp_rate


  value
  32000

  
  
analog_random_source_x

  alias
  


  comment
  


  affinity
  


  _enabled
  1


  _coordinate
  (184, 40)


  _rotation
  0


  id
  analog_random_source_x_0


  maxoutbuf
  0


  max
  255


  minoutbuf
  0


  min
  0


  num_samps
  1000


  type
  byte


  repeat
  True

  
  
blocks_char_to_float

  alias
  


  comment
  


  affinity
  


  _enabled
  1


  _coordinate
  (488, 524)


  _rotation
  180


  id
  blocks_char_to_float_0


  maxoutbuf
  0


  minoutbuf
  0


  scale
  1


  vlen
  1

  
  
blocks_char_to_float

  alias
  


  comment
  


  affinity
  


  _enabled
  1


  _coordinate
  (536, 372)


  _rotation
  0


  id
  blocks_char_to_float_1


  maxoutbuf
  0


  minoutbuf
  0


  scale
  1


  vlen
  1

  
  
blocks_multiply_const_vxx

  alias
  


  comment
  Enable Multiply Const block for 8PSK only.
Otherwise, set Multiply Const block to Bypass.


  const
  -1


  affinity
  


  _enabled
  2


  _coordinate
  (192, 388)


  _rotation
  0


  id
  blocks_multiply_const_vxx_0


  type
  complex


  maxoutbuf
  0


  minoutbuf
  0


  vlen
  1

  
  
blocks_throttle

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (272, 188)


  _rotation

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

Okay, I was really trying to get you do a BER calculation just once -
without getting distracted by QT.

If you look at the output of the random number generator, it's output
appears to be unsigned bytes.

But the output of Constellation decoder, appears to be signed bytes.

At the BER inputs, you're comparing unsigned bytes to signed bytes.

Also, you don't know if the byte streams at the BER terminals are in sync.

The actually BER of your flowgraph is on the order of 30%. A signed byte
maybe 14% of the error (1/7)?

It's impossible to compare the output of the random number generator to
the output of the constellation decoder - 4 bytes of the decoder creates
a float which has a magnitude of roughly 100 - which 100 times large
then the random number.

So I replaced replaced the random source with a GLFSR source and the
inputs to the BER line up nicely in the time sink. The BER is 0x10**-6.

And one last point the symbols for bpsk are 0,1 - not -1,1 - the latter
are the constellation points for bpsk.

Just needs some random noise source.

Note, I'm just making this up as I go along - I've never done a BER
calculation.

-- Cinaed


On 1/22/19 8:29 PM, Luis Felipe Albarracin Sanchez wrote:
> Hello Cinaed and all,
> 
> Thanks for the response.
> 
> Mainly I want to change the modulation directly while running the
> flowgraph (either by QT GUI Chooser or other switch), without having
> others in parallel for future control systems implementations.´
> 
> I don´t know if  you have any ideas or guidelines for this.
> 
> Once again thank you.
> 
> Kind Regards.
> 
> On Tue, Jan 22, 2019 at 9:22 PM Cinaed Simson  <mailto:cinaed.sim...@gmail.com>> wrote:
> 
> On 1/22/19 1:54 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed, Discussion List,
> >
> > Once again thank you for the response,
> >
> > Please believe me that i have gone through tutorials, and i have
> > understood that in the python Top block i could enable/disable
> blocks, i
> > also went through this specific one for modulations:
> >
> > https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
> >
> > An you are totally correct regarding how to modulate properly, 
> > nevertheless what i am trying to do is that while the flowgraph is
> > running, to switch the modulation (even if is not totally tuned) and
> > that i can see that modulation in the QT  GUI.
> >
> > That´s why, if you take a look at my flowgraph you see how I
> create a QT
> > Chooser so I can select the modulation.
> >
> > My main problem is that i can not get it to work, it does not
> switch to
> > other modulation when I switch in the QT Gui while I run the
> flowgraph.>
> > I would appreciate any ideas regarding this, and also i f you (Cianed)
> > could describe me a little more how a Hierarchical Block could help me
> > in this.
> 
> For hierarchical Block - see the tutorials and Google.
> 
> I use QT for passing variables and parameters - but I mainly use the
> command line. So I can't help you with QT.
> 
> See if you can actually calculate BER for a single psk - say BPSK -
> configure by a Constellation Object.
> 
> If that works, then add another Constellation Object - say for QPSK -
> configured - only for QPSK - so now you have 2 Constellation Objects in
> the flowgraph.
> 
> Now run them in parallel using BER Curve.
> 
> -- Cinaed
> 
> 
> 
> >
> > Once again thank you all.
> >
> > Kind regards.
> >
> > On Tue, Jan 22, 2019 at 3:51 PM Cinaed Simson
> mailto:cinaed.sim...@gmail.com>
> > <mailto:cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>>>
> wrote:
> >
> >     On 1/22/19 8:51 AM, Luis Felipe Albarracin Sanchez wrote:
> >     > Hello Cinaed,
> >     >
> >     > Thank you for the quick response,
> >     >
> >     > I look at your flowgraph, and i appreciate al the
> corrections you
> >     told me.
> >     >
> >     > I must just say that i was guiding myself through the examples
> >     that are
> >     > under the folder digital when you install GNU Radio.
> >
> >     Those examples presume you have already gone through the
> tutorials.
> >
> >     >
> >     > I took your model, and did some changes to mine (attached my
> new file)
> >     > but i still can´t get in the QT GUI to switch between 

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Luis Felipe Albarracin Sanchez]

Hello Cinaed and all,

Thanks for the response.

Mainly I want to change the modulation directly while running the flowgraph
(either by QT GUI Chooser or other switch), without having others in
parallel for future control systems implementations.´

I don´t know if  you have any ideas or guidelines for this.

Once again thank you.

Kind Regards.

On Tue, Jan 22, 2019 at 9:22 PM Cinaed Simson 
wrote:

> On 1/22/19 1:54 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed, Discussion List,
> >
> > Once again thank you for the response,
> >
> > Please believe me that i have gone through tutorials, and i have
> > understood that in the python Top block i could enable/disable blocks, i
> > also went through this specific one for modulations:
> >
> > https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
> >
> > An you are totally correct regarding how to modulate properly,
> > nevertheless what i am trying to do is that while the flowgraph is
> > running, to switch the modulation (even if is not totally tuned) and
> > that i can see that modulation in the QT  GUI.
> >
> > That´s why, if you take a look at my flowgraph you see how I create a QT
> > Chooser so I can select the modulation.
> >
> > My main problem is that i can not get it to work, it does not switch to
> > other modulation when I switch in the QT Gui while I run the flowgraph.>
> > I would appreciate any ideas regarding this, and also i f you (Cianed)
> > could describe me a little more how a Hierarchical Block could help me
> > in this.
>
> For hierarchical Block - see the tutorials and Google.
>
> I use QT for passing variables and parameters - but I mainly use the
> command line. So I can't help you with QT.
>
> See if you can actually calculate BER for a single psk - say BPSK -
> configure by a Constellation Object.
>
> If that works, then add another Constellation Object - say for QPSK -
> configured - only for QPSK - so now you have 2 Constellation Objects in
> the flowgraph.
>
> Now run them in parallel using BER Curve.
>
> -- Cinaed
>
>
>
> >
> > Once again thank you all.
> >
> > Kind regards.
> >
> > On Tue, Jan 22, 2019 at 3:51 PM Cinaed Simson  > <mailto:cinaed.sim...@gmail.com>> wrote:
> >
> > On 1/22/19 8:51 AM, Luis Felipe Albarracin Sanchez wrote:
> > > Hello Cinaed,
> > >
> > > Thank you for the quick response,
> > >
> > > I look at your flowgraph, and i appreciate al the corrections you
> > told me.
> > >
> > > I must just say that i was guiding myself through the examples
> > that are
> > > under the folder digital when you install GNU Radio.
> >
> > Those examples presume you have already gone through the tutorials.
> >
> > >
> > > I took your model, and did some changes to mine (attached my new
> file)
> > > but i still can´t get in the QT GUI to switch between different
> > > modulations, if i start with 8-QAM  it does not switch to QPSK
> when i
> > > choose QPSK in the  QT Chooser, i would appreciate if you can give
> me
> > > any ideas regarding this.
> >
> > Right click on the Constellation Object, and there's a pull down menu
> > under Constellation Type  - select the one you want.
> >
> > If that's not what you're looking for then you have to figure out
> how to
> > do whatever it is you want to do. And it may require creating a
> > hierarchical block.
> >
> > My advice is to work through the tutorials.
> >
> > -- Cinaed
> >
> >
> > >
> > > Kind regards.
> > >
> > >
> > >
> > > On Tue, Jan 22, 2019 at 1:00 AM Cinaed Simson
> > mailto:cinaed.sim...@gmail.com>
> > > <mailto:cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>>>
> > wrote:
> > >
> > > On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> > > > Hello all,
> > > >
> > > > I am exploring  the BER measurements in GNU Radio for
> different
> > > > modulations (I know Error Rate is deprecated) but i tried
> > the example
> > > > under the digital folder for BER measurement and I
> > understood all the
> > > > flowgraph.
> > > >
> > > > After this i wanted to change the modulation in the QT GUI
>

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

On 1/22/19 1:54 PM, Luis Felipe Albarracin Sanchez wrote:
> Hello Cinaed, Discussion List,
> 
> Once again thank you for the response,
> 
> Please believe me that i have gone through tutorials, and i have
> understood that in the python Top block i could enable/disable blocks, i
> also went through this specific one for modulations:
> 
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation
> 
> An you are totally correct regarding how to modulate properly, 
> nevertheless what i am trying to do is that while the flowgraph is
> running, to switch the modulation (even if is not totally tuned) and
> that i can see that modulation in the QT  GUI.
> 
> That´s why, if you take a look at my flowgraph you see how I create a QT
> Chooser so I can select the modulation.
> 
> My main problem is that i can not get it to work, it does not switch to
> other modulation when I switch in the QT Gui while I run the flowgraph.>
> I would appreciate any ideas regarding this, and also i f you (Cianed)
> could describe me a little more how a Hierarchical Block could help me
> in this.

For hierarchical Block - see the tutorials and Google.

I use QT for passing variables and parameters - but I mainly use the
command line. So I can't help you with QT.

See if you can actually calculate BER for a single psk - say BPSK -
configure by a Constellation Object.

If that works, then add another Constellation Object - say for QPSK -
configured - only for QPSK - so now you have 2 Constellation Objects in
the flowgraph.

Now run them in parallel using BER Curve.

-- Cinaed



> 
> Once again thank you all.
> 
> Kind regards.
> 
> On Tue, Jan 22, 2019 at 3:51 PM Cinaed Simson  <mailto:cinaed.sim...@gmail.com>> wrote:
> 
> On 1/22/19 8:51 AM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed,
> >
> > Thank you for the quick response,
> >
> > I look at your flowgraph, and i appreciate al the corrections you
> told me.
> >
> > I must just say that i was guiding myself through the examples
> that are
> > under the folder digital when you install GNU Radio.
> 
> Those examples presume you have already gone through the tutorials.
> 
> >
> > I took your model, and did some changes to mine (attached my new file)
> > but i still can´t get in the QT GUI to switch between different
> > modulations, if i start with 8-QAM  it does not switch to QPSK when i
> > choose QPSK in the  QT Chooser, i would appreciate if you can give me
> > any ideas regarding this.
> 
> Right click on the Constellation Object, and there's a pull down menu
> under Constellation Type  - select the one you want.
> 
> If that's not what you're looking for then you have to figure out how to
> do whatever it is you want to do. And it may require creating a
> hierarchical block.
> 
> My advice is to work through the tutorials.
> 
> -- Cinaed
> 
> 
> >
> > Kind regards.
> >
> >
> >
> > On Tue, Jan 22, 2019 at 1:00 AM Cinaed Simson
> mailto:cinaed.sim...@gmail.com>
> > <mailto:cinaed.sim...@gmail.com <mailto:cinaed.sim...@gmail.com>>>
> wrote:
> >
>     >     On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> >     > Hello all,
> >     >
> >     > I am exploring  the BER measurements in GNU Radio for different
> >     > modulations (I know Error Rate is deprecated) but i tried
> the example
> >     > under the digital folder for BER measurement and I
> understood all the
> >     > flowgraph.
> >     >
> >     > After this i wanted to change the modulation in the QT GUI so i
> >     added a
> >     > QT Gui Chooser as seen in the flowgraph below:
> >     >
> >     > Captura de pantalla de 2019-01-21 18-37-34.png
> >     >
> >     >
> >     > Attached is the flowgraph for reference.
> >     >
> >     > When i add this i expected that the Constellation would change
> >     > accordingly, but it does not  when i choose a different
> constellation
> >     > with the chooser, for instance if the default value in the
> chooser is
> >     > QPSK it shows at the beginning:
> >     >
> >     > Captura de pantalla de 2019-01-21 18-44-25.png
> >     >
> >     > But  If i switch in the same running time to 8-PSKn it shows:
> >
> >     Everything - I mean 

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Luis Felipe Albarracin Sanchez]

Hello Cinaed, Discussion List,

Once again thank you for the response,

Please believe me that i have gone through tutorials, and i have understood
that in the python Top block i could enable/disable blocks, i also went
through this specific one for modulations:

https://wiki.gnuradio.org/index.php/Guided_Tutorial_PSK_Demodulation

An you are totally correct regarding how to modulate properly,
nevertheless what i am trying to do is that while the flowgraph is running,
to switch the modulation (even if is not totally tuned) and that i can see
that modulation in the QT  GUI.

That´s why, if you take a look at my flowgraph you see how I create a QT
Chooser so I can select the modulation.

My main problem is that i can not get it to work, it does not switch to
other modulation when I switch in the QT Gui while I run the flowgraph.

I would appreciate any ideas regarding this, and also i f you (Cianed)
could describe me a little more how a Hierarchical Block could help me in
this.

Once again thank you all.

Kind regards.

On Tue, Jan 22, 2019 at 3:51 PM Cinaed Simson 
wrote:

> On 1/22/19 8:51 AM, Luis Felipe Albarracin Sanchez wrote:
> > Hello Cinaed,
> >
> > Thank you for the quick response,
> >
> > I look at your flowgraph, and i appreciate al the corrections you told
> me.
> >
> > I must just say that i was guiding myself through the examples that are
> > under the folder digital when you install GNU Radio.
>
> Those examples presume you have already gone through the tutorials.
>
> >
> > I took your model, and did some changes to mine (attached my new file)
> > but i still can´t get in the QT GUI to switch between different
> > modulations, if i start with 8-QAM  it does not switch to QPSK when i
> > choose QPSK in the  QT Chooser, i would appreciate if you can give me
> > any ideas regarding this.
>
> Right click on the Constellation Object, and there's a pull down menu
> under Constellation Type  - select the one you want.
>
> If that's not what you're looking for then you have to figure out how to
> do whatever it is you want to do. And it may require creating a
> hierarchical block.
>
> My advice is to work through the tutorials.
>
> -- Cinaed
>
>
> >
> > Kind regards.
> >
> >
> >
> > On Tue, Jan 22, 2019 at 1:00 AM Cinaed Simson  > <mailto:cinaed.sim...@gmail.com>> wrote:
> >
> > On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> > > Hello all,
> > >
> > > I am exploring  the BER measurements in GNU Radio for different
> > > modulations (I know Error Rate is deprecated) but i tried the
> example
> > > under the digital folder for BER measurement and I understood all
> the
> > > flowgraph.
> > >
> > > After this i wanted to change the modulation in the QT GUI so i
> > added a
> > > QT Gui Chooser as seen in the flowgraph below:
> > >
> > > Captura de pantalla de 2019-01-21 18-37-34.png
> > >
> > >
> > > Attached is the flowgraph for reference.
> > >
> > > When i add this i expected that the Constellation would change
> > > accordingly, but it does not  when i choose a different
> constellation
> > > with the chooser, for instance if the default value in the chooser
> is
> > > QPSK it shows at the beginning:
> > >
> > > Captura de pantalla de 2019-01-21 18-44-25.png
> > >
> > > But  If i switch in the same running time to 8-PSKn it shows:
> >
> > Everything - I mean everything - was configured with 8PSK
> constellation
> > data- and incorrectly - even the random number generator!
> >
> > I'm surprise you could see anything!
> >
> > Enclosed is the proper way to create a QPSK constellation.
> >
> > Work through the tutorials at
> >
> >   https://wiki.gnuradio.org/index.php/Tutorials
> >
> >
> > -- Cinaed
> >
> >
> > >
> > > Captura de pantalla de 2019-01-21 18-44-44.png
> > >
> > >
> > > Which is not an 8-PSK modulation scheme.
> > >
> > > I would appreciate some help,. regarding what i am doing wrong  for
> > > choosing a Modulation through the QT GUI.
> > >
> > > Thanks in advance.
> > >
> > > Kind Regards.
> > >
> > > ___
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org <mailto:Discuss-

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

On 1/22/19 8:51 AM, Luis Felipe Albarracin Sanchez wrote:
> Hello Cinaed,
> 
> Thank you for the quick response,
> 
> I look at your flowgraph, and i appreciate al the corrections you told me.
> 
> I must just say that i was guiding myself through the examples that are
> under the folder digital when you install GNU Radio.

Those examples presume you have already gone through the tutorials.

> 
> I took your model, and did some changes to mine (attached my new file)
> but i still can´t get in the QT GUI to switch between different
> modulations, if i start with 8-QAM  it does not switch to QPSK when i
> choose QPSK in the  QT Chooser, i would appreciate if you can give me
> any ideas regarding this.

Right click on the Constellation Object, and there's a pull down menu
under Constellation Type  - select the one you want.

If that's not what you're looking for then you have to figure out how to
do whatever it is you want to do. And it may require creating a
hierarchical block.

My advice is to work through the tutorials.

-- Cinaed


> 
> Kind regards.
> 
> 
> 
> On Tue, Jan 22, 2019 at 1:00 AM Cinaed Simson  <mailto:cinaed.sim...@gmail.com>> wrote:
> 
> On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello all,
> >
> > I am exploring  the BER measurements in GNU Radio for different
> > modulations (I know Error Rate is deprecated) but i tried the example
> > under the digital folder for BER measurement and I understood all the
> > flowgraph.
> >
> > After this i wanted to change the modulation in the QT GUI so i
> added a
> > QT Gui Chooser as seen in the flowgraph below:
> >
> > Captura de pantalla de 2019-01-21 18-37-34.png
> >
> >
> > Attached is the flowgraph for reference.
> >
> > When i add this i expected that the Constellation would change
> > accordingly, but it does not  when i choose a different constellation
> > with the chooser, for instance if the default value in the chooser is
> > QPSK it shows at the beginning:
> >
> > Captura de pantalla de 2019-01-21 18-44-25.png
> >
> > But  If i switch in the same running time to 8-PSKn it shows:
> 
> Everything - I mean everything - was configured with 8PSK constellation
> data- and incorrectly - even the random number generator!
> 
> I'm surprise you could see anything!
> 
> Enclosed is the proper way to create a QPSK constellation.
> 
> Work through the tutorials at
> 
>   https://wiki.gnuradio.org/index.php/Tutorials
> 
> 
> -- Cinaed
> 
> 
> >
> > Captura de pantalla de 2019-01-21 18-44-44.png
> >
> >
> > Which is not an 8-PSK modulation scheme.
> >
> > I would appreciate some help,. regarding what i am doing wrong  for
> > choosing a Modulation through the QT GUI.
> >
> > Thanks in advance.
> >
> > Kind Regards.
> >
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> -- 
> Eng. Luis Felipe Albarracin
> Msc. Telematics / MBA
> PMP
> CCNA/CCDA/CCNP/CCDP/CCIP
> ITIL v3 Foundation
> "Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Luis Felipe Albarracin Sanchez]

Hello Cinaed,

Thank you for the quick response,

I look at your flowgraph, and i appreciate al the corrections you told me.

I must just say that i was guiding myself through the examples that are
under the folder digital when you install GNU Radio.

I took your model, and did some changes to mine (attached my new file) but
i still can´t get in the QT GUI to switch between different modulations, if
i start with 8-QAM  it does not switch to QPSK when i choose QPSK in the
QT Chooser, i would appreciate if you can give me any ideas regarding this.

Kind regards.



On Tue, Jan 22, 2019 at 1:00 AM Cinaed Simson 
wrote:

> On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> > Hello all,
> >
> > I am exploring  the BER measurements in GNU Radio for different
> > modulations (I know Error Rate is deprecated) but i tried the example
> > under the digital folder for BER measurement and I understood all the
> > flowgraph.
> >
> > After this i wanted to change the modulation in the QT GUI so i added a
> > QT Gui Chooser as seen in the flowgraph below:
> >
> > Captura de pantalla de 2019-01-21 18-37-34.png
> >
> >
> > Attached is the flowgraph for reference.
> >
> > When i add this i expected that the Constellation would change
> > accordingly, but it does not  when i choose a different constellation
> > with the chooser, for instance if the default value in the chooser is
> > QPSK it shows at the beginning:
> >
> > Captura de pantalla de 2019-01-21 18-44-25.png
> >
> > But  If i switch in the same running time to 8-PSKn it shows:
>
> Everything - I mean everything - was configured with 8PSK constellation
> data- and incorrectly - even the random number generator!
>
> I'm surprise you could see anything!
>
> Enclosed is the proper way to create a QPSK constellation.
>
> Work through the tutorials at
>
>   https://wiki.gnuradio.org/index.php/Tutorials
>
>
> -- Cinaed
>
>
> >
> > Captura de pantalla de 2019-01-21 18-44-44.png
> >
> >
> > Which is not an 8-PSK modulation scheme.
> >
> > I would appreciate some help,. regarding what i am doing wrong  for
> > choosing a Modulation through the QT GUI.
> >
> > Thanks in advance.
> >
> > Kind Regards.
> >
> > ___
> > 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
>


-- 
Eng. Luis Felipe Albarracin
Msc. Telematics / MBA
PMP
CCNA/CCDA/CCNP/CCDP/CCIP
ITIL v3 Foundation
"Die Grenzen meiner Sprache bedeuten die Grenzen meiner Welt"


my-ber_simulation_LFA.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER Example - With QT Gui Chooser for Different Modulations Issue

[Cinaed Simson]

On 1/21/19 3:47 PM, Luis Felipe Albarracin Sanchez wrote:
> Hello all,
> 
> I am exploring  the BER measurements in GNU Radio for different
> modulations (I know Error Rate is deprecated) but i tried the example
> under the digital folder for BER measurement and I understood all the
> flowgraph.
> 
> After this i wanted to change the modulation in the QT GUI so i added a
> QT Gui Chooser as seen in the flowgraph below:
> 
> Captura de pantalla de 2019-01-21 18-37-34.png
> 
> 
> Attached is the flowgraph for reference.
> 
> When i add this i expected that the Constellation would change
> accordingly, but it does not  when i choose a different constellation
> with the chooser, for instance if the default value in the chooser is
> QPSK it shows at the beginning:
> 
> Captura de pantalla de 2019-01-21 18-44-25.png
> 
> But  If i switch in the same running time to 8-PSKn it shows:

Everything - I mean everything - was configured with 8PSK constellation
data- and incorrectly - even the random number generator!

I'm surprise you could see anything!

Enclosed is the proper way to create a QPSK constellation.

Work through the tutorials at

  https://wiki.gnuradio.org/index.php/Tutorials


-- Cinaed


> 
> Captura de pantalla de 2019-01-21 18-44-44.png
> 
> 
> Which is not an 8-PSK modulation scheme.
> 
> I would appreciate some help,. regarding what i am doing wrong  for
> choosing a Modulation through the QT GUI.
> 
> Thanks in advance.
> 
> Kind Regards.
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




  Sat Jul 12 13:50:53 2014
  
options

  author
  Example


  window_size
  1280, 1024


  category
  Custom


  comment
  


  description
  Adjust the noise and constellation... see what happens!


  _enabled
  True


  _coordinate
  (16, 10)


  _rotation
  0


  generate_options
  qt_gui


  hier_block_src_path
  .:


  id
  ber_simulation


  max_nouts
  0


  qt_qss_theme
  


  realtime_scheduling
  


  run_command
  {python} -u {filename}


  run_options
  prompt


  run
  True


  sizing_mode
  fixed


  thread_safe_setters
  


  title
  BER Simulation


  placement
  (0,0)

  
  
variable_qtgui_range

  comment
  


  value
  10


  _enabled
  0


  _coordinate
  (317, 281)


  gui_hint
  


  _rotation
  0


  id
  EbN0


  label
  Eb / N0 (dB)


  min_len
  200


  orient
  Qt.Horizontal


  start
  -10


  step
  1


  stop
  200


  rangeType
  float


  widget
  counter

  
  
variable_qtgui_chooser

  comment
  


  value
  2


  _enabled
  0


  _coordinate
  (152, 404)


  gui_hint
  


  _rotation
  0


  id
  Option1


  label0
  BPSK


  label1
  QPSK


  label2
  8PSK


  label3
  


  label4
  


  label
  


  labels
  []


  num_opts
  3


  option0
  0


  option1
  1


  option2
  2


  option3
  3


  option4
  4


  options
  [0, 1, 2]


  orient
  Qt.QVBoxLayout


  type
  int


  widget
  combo_box

  
  
variable

  comment
  


  _enabled
  0


  _coordinate
  (116, 310)


  _rotation
  0


  id
  const


  value
  (digital.constellation_bpsk(), digital.constellation_qpsk(), digital.constellation_8psk())

  
  
variable_constellation

  comment
  


  const_points
  digital.psk_4()[0]


  type
  calcdist


  dims
  digital.qpsk_constellation().dimensionality()


  _enabled
  1


  _coordinate
  (328, 8)


  _rotation
  0


  id
  qpsk


  rot_sym
  digital.qpsk_constellation().rotational_symmetry()


  soft_dec_lut
  'auto'


  precision
  8


  sym_map
  digital.psk_4()[1]
  

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

> I have no idea what the KISS to PDU is doing.

I expected it to be a convert from Integer 8 to Async Message

> Check the README - it said somewhere about 3.7.11 and 3.7.12 - since I'm
> using 3.7.13 I ignored it.

I managed to finally install Version 3.7.13.4

> First, you shouldn't have 2 versions of gnuradio installed at the same
> time. You will have problems.

Now I only have GNU Radio version 3.7.13.4

> Which OS and what version are you running?

Ubuntu 18.04 inside a Oracle VM VirtualBox

> Second, I don't think you need to upgrade.
>
> The error message with "233-32" in it suggests your packet length is to
> large for RS(223,255).

I will work on that now

> If you didn't uninstall the previous version of gnuradio, you need to
> back out of the version you're currently installing.

I have done that (Or at least, I think I managed to uninstall it completely)
And now it workds

> Type
>
>   echo $PYTHONPATH
>   echo $LD_LIBRARY_PATH
>
> to see the values and compare the values to the installation in question.

I finally installed the latest version building it from the source
The last command I needed was
sudo ldconfig

After that, the error of $PYTHONPATH and $LD_LIBRARY_PATH did not show
up and the GNU Radio Companion launched

Again, thank you for your Time and your support



--

Christian Sêngir Busquiel Sanz

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

On 10/25/2018 03:35 PM, Christian BusquielSanz wrote:
>> It runs without error for me under version 3.7.13.4.
>>
>> That is, it generates 3 windows each with a single straight line of
>> amplitude 0.
>>
>> -- Cinaed
>>
> 
> That is not the output I expected
> So I am doing something wrong, since I was using the blocks
> "KISS to PDU"
> "PDU to Tagged Stream"
> to be able to encode the bit stream using CCSDS Reed-Solomon Encoder and 
> Decoder
> So I expected to have the same result as earlier, but just adding a
> codification; to compare the BER of both systems

I have no idea what the KISS to PDU is doing.

> 
> I do not know why I am having an error with my version

Check the README - it said somewhere about 3.7.11 and 3.7.12 - since I'm
using 3.7.13 I ignored it.
> 
> I am trying to update from version 3.7.11 to 3.7.13 from the command
> line, but I am having issues
> I downloaded the gnuradio-3.7.13.4.tar.gz from
> https://github.com/gnuradio/gnuradio/releases/tag/v3.7.13.4
> I extracted the files, and proceeded from the
> ~/GNURadio/gnuradio-3.7.13.4/
> folder to use these commands:
> mkdir build
> cd build
> cmake ../
> make

First, you shouldn't have 2 versions of gnuradio installed at the same
time. You will have problems.

Which OS and what version are you running?

Second, I don't think you need to upgrade.

The error message with "233-32" in it suggests your packet length is to
large for RS(223,255).

> 
> I had an issue and it was because I did not have enough Memory Ram in
> my Virtual Machine when it was building the source code on 61%
> Now, I managed to make it compile and install, but I have this error
> when I try to run the new version:
> "
> Cannot import gnuradio.

If you didn't uninstall the previous version of gnuradio, you need to
back out of the version you're currently installing.

> 
> Is the model path environment variable set correctly?
> All OS: PYTHONPATH

Type

  echo $PYTHONPATH
  echo $LD_LIBRARY_PATH

to see the values and compare the values to the installation in question.

> 
> Is the library path environment variable set correctly?
> Linux: LD_LIBRARY_PATH
> Windows: PATH
> MacOSX: DYLD_LIBRARY_PATH
> 
> 
> (No module named _runtime_swig)
> "
> So, I cannot try your flowgraph until I manage to fix it and run GNU
> Radio Companion again
> I will keep you informed on my progress
> Thank you so much for taking care about my issue
> 
> 
> Christian Sêngir Busquiel Sanz
> 
> ___
> 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] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

> It runs without error for me under version 3.7.13.4.
>
> That is, it generates 3 windows each with a single straight line of
> amplitude 0.
>
> -- Cinaed
>

That is not the output I expected
So I am doing something wrong, since I was using the blocks
"KISS to PDU"
"PDU to Tagged Stream"
to be able to encode the bit stream using CCSDS Reed-Solomon Encoder and Decoder
So I expected to have the same result as earlier, but just adding a
codification; to compare the BER of both systems

I do not know why I am having an error with my version

I am trying to update from version 3.7.11 to 3.7.13 from the command
line, but I am having issues
I downloaded the gnuradio-3.7.13.4.tar.gz from
https://github.com/gnuradio/gnuradio/releases/tag/v3.7.13.4
I extracted the files, and proceeded from the
~/GNURadio/gnuradio-3.7.13.4/
folder to use these commands:
mkdir build
cd build
cmake ../
make

I had an issue and it was because I did not have enough Memory Ram in
my Virtual Machine when it was building the source code on 61%
Now, I managed to make it compile and install, but I have this error
when I try to run the new version:
"
Cannot import gnuradio.

Is the model path environment variable set correctly?
All OS: PYTHONPATH

Is the library path environment variable set correctly?
Linux: LD_LIBRARY_PATH
Windows: PATH
MacOSX: DYLD_LIBRARY_PATH


(No module named _runtime_swig)
"
So, I cannot try your flowgraph until I manage to fix it and run GNU
Radio Companion again
I will keep you informed on my progress
Thank you so much for taking care about my issue


Christian Sêngir Busquiel Sanz

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

Opps - I meant 223 bytes of information - not 233 bytes.

-- Cinaed


On 10/25/2018 02:50 PM, Cinaed Simson wrote:
> Here's my Reed-Solomon.
> 
> Note, a symbol for Reed-Solomon is 255 bytes. Of that, 233 bytes is
> information and 32 bytes parity information.
> 
> So I set the byte packet length for the tagged stream to be 233.
> 
> Note, when I tried to add a Qt Time Sink my GRC and it hung - I suspect
> there might be a problem with the Throttle.
> 
> I didn't play with the Qt Time Sink since it doesn't add any useful
> information.
> 
> But I did disable the Throttle and it ran better on my i7.
> 
> Your mileage may vary.
> 
> -- Cinaed
> 
> 
> 
> 
> On 10/23/2018 08:28 PM, Christian BusquielSanz wrote:
>> I am having this output with my Reed Solomon test:
>>
>> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>>
>> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>>
>> Executing: /usr/bin/python -u
>> /home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py
>>
>> Traceback (most recent call last):
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 283, in 
>> main()
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 271, in main
>> tb = top_block_cls()
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 87, in __init__
>> self.satellites_encode_rs_0 = satellites.encode_rs(0)
>> AttributeError: 'module' object has no attribute 'encode_rs'
>>
> Done (return code 1)
>>
>>
>>
>>
>> It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon 
>> Encoder"
>>
>> I am attaching the flowgraph, the GRC file
>>
>> I have not found information about this issue
>>
>> What am I doing wrong?
>> Thank you
>>
>>
>>
>> Christian Sêngir Busquiel Sanz
>>
>>
>>
>> ___
>> 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] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

Also, in the Options block, I set it to "No GUI" so it would send the
output of the Message Debug to a terminal windows instead of the window
in the GRC.

Otherwise it overloads the GRC window.

Once you're convinced RS(223,255) is working, you can disable Message
Debug and enable the the QT GUI, and should be able to pipe the results
to some other block.

-- Cinaed


On 10/25/2018 02:50 PM, Cinaed Simson wrote:
> Here's my Reed-Solomon.
> 
> Note, a symbol for Reed-Solomon is 255 bytes. Of that, 233 bytes is
> information and 32 bytes parity information.
> 
> So I set the byte packet length for the tagged stream to be 233.
> 
> Note, when I tried to add a Qt Time Sink my GRC and it hung - I suspect
> there might be a problem with the Throttle.
> 
> I didn't play with the Qt Time Sink since it doesn't add any useful
> information.
> 
> But I did disable the Throttle and it ran better on my i7.
> 
> Your mileage may vary.
> 
> -- Cinaed
> 
> 
> 
> 
> On 10/23/2018 08:28 PM, Christian BusquielSanz wrote:
>> I am having this output with my Reed Solomon test:
>>
>> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>>
>> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>>
>> Executing: /usr/bin/python -u
>> /home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py
>>
>> Traceback (most recent call last):
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 283, in 
>> main()
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 271, in main
>> tb = top_block_cls()
>>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> line 87, in __init__
>> self.satellites_encode_rs_0 = satellites.encode_rs(0)
>> AttributeError: 'module' object has no attribute 'encode_rs'
>>
> Done (return code 1)
>>
>>
>>
>>
>> It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon 
>> Encoder"
>>
>> I am attaching the flowgraph, the GRC file
>>
>> I have not found information about this issue
>>
>> What am I doing wrong?
>> Thank you
>>
>>
>>
>> Christian Sêngir Busquiel Sanz
>>
>>
>>
>> ___
>> 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] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

Here's my Reed-Solomon.

Note, a symbol for Reed-Solomon is 255 bytes. Of that, 233 bytes is
information and 32 bytes parity information.

So I set the byte packet length for the tagged stream to be 233.

Note, when I tried to add a Qt Time Sink my GRC and it hung - I suspect
there might be a problem with the Throttle.

I didn't play with the Qt Time Sink since it doesn't add any useful
information.

But I did disable the Throttle and it ran better on my i7.

Your mileage may vary.

-- Cinaed




On 10/23/2018 08:28 PM, Christian BusquielSanz wrote:
> I am having this output with my Reed Solomon test:
> 
> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
> 
> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
> 
> Executing: /usr/bin/python -u
> /home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py
> 
> Traceback (most recent call last):
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 283, in 
> main()
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 271, in main
> tb = top_block_cls()
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 87, in __init__
> self.satellites_encode_rs_0 = satellites.encode_rs(0)
> AttributeError: 'module' object has no attribute 'encode_rs'
> 
 Done (return code 1)
> 
> 
> 
> 
> It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon 
> Encoder"
> 
> I am attaching the flowgraph, the GRC file
> 
> I have not found information about this issue
> 
> What am I doing wrong?
> Thank you
> 
> 
> 
> Christian Sêngir Busquiel Sanz
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 




  Wed Oct 24 19:12:43 2018
  
options

  author
  


  window_size
  


  category
  [GRC Hier Blocks]


  comment
  


  description
  


  _enabled
  True


  _coordinate
  (8, 8)


  _rotation
  0


  generate_options
  no_gui


  hier_block_src_path
  .:


  id
  top_block


  max_nouts
  0


  qt_qss_theme
  


  realtime_scheduling
  


  run_command
  {python} -u {filename}


  run_options
  run


  run
  True


  sizing_mode
  fixed


  thread_safe_setters
  


  title
  


  placement
  (0,0)

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (328, 4)


  _rotation
  0


  id
  packet_len


  value
  223

  
  
variable

  comment
  


  _enabled
  True


  _coordinate
  (216, 4)


  _rotation
  0


  id
  samp_rate


  value
  2**15

  
  
blocks_float_to_char

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (200, 132)


  _rotation
  0


  id
  blocks_float_to_char_0


  maxoutbuf
  0


  minoutbuf
  0


  scale
  1


  vlen
  1

  
  
blocks_message_debug

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (912, 264)


  _rotation
  0


  id
  blocks_message_debug_0_0

  
  
blocks_stream_to_tagged_stream

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (552, 124)


  _rotation
  0


  id
  blocks_stream_to_tagged_stream_0


  len_tag_key
  "packet_len"


  maxoutbuf
  0


  minoutbuf
  0


  packet_len
  packet_len


  type
  byte


  vlen
  1

  
  
blocks_tagged_stream_to_pdu

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (776, 132)


  _rotation
  0


  id
  blocks_tagged_stream_to_pdu_0


  type
  byte


  tag
  packet_len


  maxoutbuf
  0


  minoutbuf
  0

  
  
blocks_throttle

  alias
  


  comment
  


  affinity
  


  _enabled
  True


  _coordinate
  (360, 132)

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

On 10/23/2018 08:28 PM, Christian BusquielSanz wrote:
> I am having this output with my Reed Solomon test:
> 
> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
> 
> Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
> 
> Executing: /usr/bin/python -u
> /home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py
> 
> Traceback (most recent call last):
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 283, in 
> main()
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 271, in main
> tb = top_block_cls()
>   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
> line 87, in __init__
> self.satellites_encode_rs_0 = satellites.encode_rs(0)
> AttributeError: 'module' object has no attribute 'encode_rs'
> 
 Done (return code 1)
> 
> 
> 
> 
> It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon 
> Encoder"
> 
> I am attaching the flowgraph, the GRC file
> 
> I have not found information about this issue
> 
> What am I doing wrong?
> Thank you

It runs without error for me under version 3.7.13.4.

That is, it generates 3 windows each with a single straight line of
amplitude 0.

-- Cinaed

> 
> 
> 
> Christian Sêngir Busquiel Sanz
> 
> 
> 
> ___
> 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] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

I am having this output with my Reed Solomon test:

Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'

Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'

Executing: /usr/bin/python -u
/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py

Traceback (most recent call last):
  File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
line 283, in 
main()
  File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
line 271, in main
tb = top_block_cls()
  File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
line 87, in __init__
self.satellites_encode_rs_0 = satellites.encode_rs(0)
AttributeError: 'module' object has no attribute 'encode_rs'

>>> Done (return code 1)




It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon Encoder"

I am attaching the flowgraph, the GRC file

I have not found information about this issue

What am I doing wrong?
Thank you



Christian Sêngir Busquiel Sanz


Reed-Solomon_Test_001.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

> Sorry, I didn't look at the image.

No problem, I appreciate the Time that you have spent helping me, I
know that everyone is busy and sometimes we look at this in a hurry



> Ah, that's most likely the issue. I'm running Debian on bare metal with
> an i7 and I don't have any problems.
>
> -- Cinaed

Maybe that is what it was...
I just wanted to make note of it in case someone has the same
behaviour in their simulations so they can find the problem easily



I will keep trying to convert Bytes into Async Messages and vice versa
For now, I found a block that apparently has that behaviour, but I
have not managed to use it properly:
A) KISS to PDU
B) PDU to Tagged Stream
(From GR-Satellites https://github.com/daniestevez/gr-satellites)

I will let you know if I get any positive results



Christian Sêngir Busquiel Sanz

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

On 10/22/2018 01:10 PM, Christian BusquielSanz wrote:
> On Sat, 20 Oct 2018 at 08:00, Cinaed Simson  wrote:
>> Maybe you removed the Delay slider? The default value is 0 - try setting
>> it to 2 in the Qt GUI Range.
>>
>> -- Cinaed
> 
> No, I did not remove the slider (It shows in the picture that the
> slider is there, on top)
> 
> I changed the default value to 2, because that is how it synchronizes
> in my computer
> 
> I was just pointing out that the BER does not plot straight away if
> the default value is different from 0
> If the delay value is set to 0, it starts plotting it right away
> If it is different than 0, I need to click on the slide or click the
> arrows to change the value so it starts plotting,
> then click again to switch it back to 2 so the two signals are synchronized

Sorry, I didn't look at the image.

> 
> I am using Ubuntu 18.04 in Oracle VM Virtual Box in a Windows 10 Pro
> 64 bit operating system, in case that the issue comes from there
> 

Ah, that's most likely the issue. I'm running Debian on bare metal with
an i7 and I don't have any problems.

-- Cinaed

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

On Sat, 20 Oct 2018 at 08:00, Cinaed Simson  wrote:
> Maybe you removed the Delay slider? The default value is 0 - try setting
> it to 2 in the Qt GUI Range.
>
> -- Cinaed

No, I did not remove the slider (It shows in the picture that the
slider is there, on top)

I changed the default value to 2, because that is how it synchronizes
in my computer

I was just pointing out that the BER does not plot straight away if
the default value is different from 0
If the delay value is set to 0, it starts plotting it right away
If it is different than 0, I need to click on the slide or click the
arrows to change the value so it starts plotting,
then click again to switch it back to 2 so the two signals are synchronized

I am using Ubuntu 18.04 in Oracle VM Virtual Box in a Windows 10 Pro
64 bit operating system, in case that the issue comes from there

-- 

Christian Sêngir Busquiel Sanz

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

On 10/18/2018 04:26 PM, Christian BusquielSanz wrote:
>> If the BER icon is grey, you need to put your cursor on the BER icon,
>> right click, and select enable.
>>
>> And you need to do the same thing for the two yellow icons for the CRC32
>> if you haven't already done so.
>>
>> All the icons in the flowgraph should have a white background.
> 
> I did not mean that
> I saw that the flowgraph that you sent me had several blocks in grey and
> several blocks in yellow
> I researched what it meant, since it did not show up in any tutorial,
> and I noticed that feature
> "Enable" (Light purple): block working
> "Disabled" (Dark Grey): block does not exist for the flowgraph, but its
> connections are still there. (Useful for sinks)
> "Bypass" (Yellow): block behaves as it is only a connection between blocks
> 
> What I meant is what I see as an attached picture No_BER_Shown_001.png
> I have to click on the Range value, change it from 2 to another value
> (Either clicking the arrow up or down) and then the BER starts to being
> plotted
> When I do that, results are shown in the BER graph

Maybe you removed the Delay slider? The default value is 0 - try setting
it to 2 in the Qt GUI Range.

-- Cinaed

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

On 10/17/2018 07:20 PM, Christian BusquielSanz wrote:
> Good day again
> 
> First of all, thank you very much, Mr Simson
> Seeing a graph working doing what I wanted to do helped me a lot on
> how to solve the problem that I had with mine
> I actually expected a reply in one week and I got it in a couple of
> days, so it was of great help and I wanted to thank you for that
> 
> Second of all
> Since I am writing long E-Mails... Should I delete the previous
> E-Mails appended to this message after the signature to clean the
> mailing list?
> Also to free some weight from the messages
> 
> I have been working on the flowgraph these days too
> 
> I was using "Pack K bits" and I should have used "Unpack K Bits", as
> you showed me,
> because GMSK Demodulator demodulates each symbol providing one bit of
> the result on consecutive bytes,
> so I need to use only the last bits of each output to generate back the data
> So that was my mistake
> 
> Since the delay that works for me is 2, I set it as a variable so I
> already have the proper value when running the flowgraph
> But...
> 
> A thing that I have noticed is that, when I run the flowgraph, I need
> to click on the arrows of the delay,
> change it and return it to the value 2,
> to get the BER plotted on the QT GUI Time Sink

If the BER icon is grey, you need to put your cursor on the BER icon,
right click, and select enable.

And you need to do the same thing for the two yellow icons for the CRC32
if you haven't already done so.

All the icons in the flowgraph should have a white background.

> 
> I have this Modulation/Demodulation flowgraph working
> 
> Now I want to add an encoder, Reed-Solomon or Convolutional Coding
> One at a Time
> And later on, both of them
> 
> But, as I stated earlier, I would like to ask for a way to convert
> "Integer 8"/"Char" outputs from blocks into "Async Message"
> to be able to use CCSDS Reed-Solomon Encoder/Decoder from "\Satellites\FEC"

In the search box, enter "Async" and see pops up.

Also, see the examples in the source code directory for gr-satellites.

> 
> I have also found another Reed-Solomonn Encoder/Decoder here:
> https://github.com/gnuradio/gnuradio/tree/master/gr-fec/lib/reed-

That code is from the core source code for gnuradio - you already have
it installed on your computer.



> But I do not know how to install it, since I cannot find a way to
> download the whole library and install it using the standard block
> procedure:

Don't even try to install it.

> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.2.6._Installing_Python_Blocks
> mkdir build
> cmake ../
> make
> sudo make install
> sudo ldconfig
> 
> If I do this downloading all the files in a separate folder, I am
> getting this output when runing the command "cmake ../":
> "
> CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:174
> (file):
>   file failed to open for writing (No such file or directory):
> 
> 
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/CMakeOutput.log
> Call Stack (most recent call first):
>   CMakeLists.txt
> 
> 
> CMake Error: Could not open file for write in copy operation
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CMakeSystem.cmake.tmp
> CMake Error: : System Error: No such file or directory
> CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:186
> (configure_file):
>   configure_file Problem configuring file
> Call Stack (most recent call first):
>   CMakeLists.txt
> 
> 
> CMake Error at 
> /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
> (file):
>   file problem creating directory:
>   
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
> Call Stack (most recent call first):
>   /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
> (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt
> 
> 
> CMake Error at 
> /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
> (file):
>   file problem creating directory:
>   
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
> Call Stack (most recent call first):
>   /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
> (CMAKE_DETERMINE_COMPILER_ID_BUILD)
>   /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
> (CMAKE_DETERMINE_COMPILER_ID)
>   CMakeLists.txt
> 
> 
> CMake Error at 
> /usr/share/cmake-3.10/Modules/CMakeDete

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

Sorry for Re-Posting

I just realized looking at the output that I might needed to run the
"cmake ../" as superuser, so I did:

"
~/GNURadio/work/Reed-Solomon/build$ sudo cmake ../
[sudo] password for cbusquielsanz:
-- The C compiler identification is GNU 7.3.0
-- The CXX compiler identification is GNU 7.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning (dev) in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

cmake_minimum_required(VERSION 3.10)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP".
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to:
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build
"

Then I run the following commands, but no feedback is given for the
"make" command:
"
cbusquielsanz@cbusquielsanz-Ubuntu:~/GNURadio/work/Reed-Solomon/build$ make
cbusquielsanz@cbusquielsanz-Ubuntu:~/GNURadio/work/Reed-Solomon/build$
sudo make install
make: *** No rule to make target 'install'.  Stop.
"

So I believe I might be lacking a file to install this, because I
updated CMake to install GNU Radio Companion two weeks ago
On Thu, 18 Oct 2018 at 15:20, Christian BusquielSanz
 wrote:
>
> Good day again
>
> First of all, thank you very much, Mr Simson
> Seeing a graph working doing what I wanted to do helped me a lot on
> how to solve the problem that I had with mine
> I actually expected a reply in one week and I got it in a couple of
> days, so it was of great help and I wanted to thank you for that
>
> Second of all
> Since I am writing long E-Mails... Should I delete the previous
> E-Mails appended to this message after the signature to clean the
> mailing list?
> Also to free some weight from the messages
>
> I have been working on the flowgraph these days too
>
> I was using "Pack K bits" and I should have used "Unpack K Bits", as
> you showed me,
> because GMSK Demodulator demodulates each symbol providing one bit of
> the result on consecutive bytes,
> so I need to use only the last bits of each output to generate back the data
> So that was my mistake
>
> Since the delay that works for me is 2, I set it as a variable so I
> already have the proper value when running the flowgraph
> But...
>
> A thing that I have noticed is that, when I run the flowgraph, I need
> to click on the arrows of the delay,
> change it and return it to the value 2,
> to get the BER plotted on the QT GUI Time Sink
>
> I have this Modulation/Demodulation flowgraph working
>
> Now I want to add an encoder, Reed-Solomon or Convolutional Coding
> One at a Time
> And later on, both of them
>
> But, as I stated earlier, I would like to ask for a way to convert
> "Integer 8"/"Char" outputs from blocks into "Async Message"
> to be able to use CCSDS Reed-Solomon Encoder/Decoder from "\Satellites\FEC"
>
> I have also found another Reed-Solomonn Encoder/Decoder here:
> https://github.com/gnuradio/gnuradio/tree/master/gr-fec/lib/reed-solomon
> But I do not know how to install it, since I cannot find a way to
> download the whole library and install it using the standard block
> procedure:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.2.6._Installing_Python_Blocks
> mkdir build
> cmake ../
> make
> sudo make install
> sudo ldconfig
>
> If I do this downloading all the files in a separate folder, I am
> getting this output when runing the command "cmake ../":
> "
> CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:174
> (file):
>   file failed to open for writing (No such file or directory):
>
> 
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/CMakeOutput.log
> Call Stack (most recent call first):
>   CMakeLists.txt
>
>
> CMake Error: Could not open file for write in copy operation
> /home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CMakeSystem.cmake.tmp
> CMake Error: : System Error: No such file or directory
> CMake Error at /usr/share/cmake-3.10/Modules/CMakeDe

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

Good day again

First of all, thank you very much, Mr Simson
Seeing a graph working doing what I wanted to do helped me a lot on
how to solve the problem that I had with mine
I actually expected a reply in one week and I got it in a couple of
days, so it was of great help and I wanted to thank you for that

Second of all
Since I am writing long E-Mails... Should I delete the previous
E-Mails appended to this message after the signature to clean the
mailing list?
Also to free some weight from the messages

I have been working on the flowgraph these days too

I was using "Pack K bits" and I should have used "Unpack K Bits", as
you showed me,
because GMSK Demodulator demodulates each symbol providing one bit of
the result on consecutive bytes,
so I need to use only the last bits of each output to generate back the data
So that was my mistake

Since the delay that works for me is 2, I set it as a variable so I
already have the proper value when running the flowgraph
But...

A thing that I have noticed is that, when I run the flowgraph, I need
to click on the arrows of the delay,
change it and return it to the value 2,
to get the BER plotted on the QT GUI Time Sink

I have this Modulation/Demodulation flowgraph working

Now I want to add an encoder, Reed-Solomon or Convolutional Coding
One at a Time
And later on, both of them

But, as I stated earlier, I would like to ask for a way to convert
"Integer 8"/"Char" outputs from blocks into "Async Message"
to be able to use CCSDS Reed-Solomon Encoder/Decoder from "\Satellites\FEC"

I have also found another Reed-Solomonn Encoder/Decoder here:
https://github.com/gnuradio/gnuradio/tree/master/gr-fec/lib/reed-solomon
But I do not know how to install it, since I cannot find a way to
download the whole library and install it using the standard block
procedure:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.2.6._Installing_Python_Blocks
mkdir build
cmake ../
make
sudo make install
sudo ldconfig

If I do this downloading all the files in a separate folder, I am
getting this output when runing the command "cmake ../":
"
CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:174
(file):
  file failed to open for writing (No such file or directory):


/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/CMakeOutput.log
Call Stack (most recent call first):
  CMakeLists.txt


CMake Error: Could not open file for write in copy operation
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CMakeSystem.cmake.tmp
CMake Error: : System Error: No such file or directory
CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineSystem.cmake:186
(configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
(file):
  file problem creating directory:
  
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt


CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
(file):
  file problem creating directory:
  
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt


CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
(file):
  file problem creating directory:
  
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt


CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
(file):
  file problem creating directory:
  
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
Call Stack (most recent call first):
  /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:31
(CMAKE_DETERMINE_COMPILER_ID_BUILD)
  /usr/share/cmake-3.10/Modules/CMakeDetermineCCompiler.cmake:112
(CMAKE_DETERMINE_COMPILER_ID)
  CMakeLists.txt


CMake Error at /usr/share/cmake-3.10/Modules/CMakeDetermineCompilerId.cmake:145
(file):
  file problem creating directory:
  
/home/cbusquielsanz/GNURadio/work/Reed-Solomon/build/CMakeFiles/3.10.2/CompilerIdC
Call Stack (most recent cal

Re: [Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Cinaed Simson]

Hi Christian - start simple.

First prove to yourself you can modulate/demodulate a random source.

Enclosed is an example.

You can replace the GLFSR source and Float To Char blocks with a Random
Source block - but it doesn't really matter.

Adjust the Delay block until the 2 curves in the Qt GUI Time Sink block
line up,

This will depend upon the speed of your machine.

Then enable the 2 CRC32 blocks.

You may have to adjust the delay again.

Then enable the blocks to calculate BER.

-- Cinaed


On 10/14/2018 07:05 PM, Christian BusquielSanz wrote:
> Good day
> How are you?
> I am a new user to GNU Radio Companion
> I am using version 3.7.11
> I have read, followed and finished the exercises/examples in the
> tutorials of Working with "GNU Radio Companion"
> (https://wiki.gnuradio.org/index.php/Guided_Tutorial_GRC) and
> "Programming GNU Radio in Python"
> (https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python)
> -
> I have been working on designing a whole system to compute the BER of
> different encoders using GMSK:
> 1.- Reed Solomon
> 2.- Convolutional Coding
> 3.- CRC
> 
> I have also installed GR Satellites by Daniel Estévez
> (https://github.com/daniestevez/gr-satellites) to help me with this
> task
> 
> I started building the whole system using GNU Radio Companion to build
> the blocks, but I had many problems with the input and output of
> blocks, since there were no transformations to adapt all the blocks
> among them, and I tried several of the blocks provided with each
> Encoder/Decoder to make it fit
> -
> Once I had an idea of how it should work, I tried to start with a
> simple system only with one of the 'encoders' which was CRC (Stream
> CRC32)
> 
> The Block Diagram would look like this (See attached "CRC_Test.grc" file):
> (Random Source) => (Throttle) => (Stream to Tagged Stream) => (Stream
> CRC32[Generate CRC]) =>A) B) C)
> A) => (Char to Float) => (QT GUI Timer Sink)
> B) => (GMSK Mod [S/S=10]) => (GMSK Demod [S/S=10]) => (Pack K Bits
> [K=8]) => C) D)
> C) 2x=> (BER) => (QT GUI Timer Sink)
> D) => (Char to Float) => (QT GUI Timer Sink)
> 
> And also adding noise:
> The Block Diagram would look like this (See attached
> "CRC_Test_with_noise.grc" file):
> (Random Source) => (Throttle) => (Stream to Tagged Stream) => (Stream
> CRC32[Generate CRC]) =>A) B) C)
> (Noise Source [Gaussian]) => D)
> A) => (Char to Float) => (QT GUI Timer Sink)
> B) => (GMSK Mod [S/S=10]) => D)
> C) 2x=> (BER) => (QT GUI Timer Sink)
> D) 2x=> (Add) => (GMSK Demod [S/S=10]) => (Pack K Bits [K=8]) => C) E)
> E) => (Char to Float) => (QT GUI Timer Sink)
> 
> If I add another "Stream CRC32" block with [Check CRC]; I have three 
> situations:
> a) I add a "Stream to Tagged Stream" block before the (Stream CRC
> [Check CRC]) with the same 'Length Tag Name' as the one after the
> Throttle
> b) I add a "Stream to Tagged Stream" block before the (Stream CRC
> [Check CRC]) with a different 'Length Tag Name' as the one after the
> Throttle and change the "Length Tag Key" of the "Stream CRC32" block
> c) I do not add a "Stream to Tagged Stream" block before the (Stream
> CRC [Check CRC])
> I get these outputs:
> a) It provides no output, and an error is shown up:
> gr::log :FATAL: crc32_bb0 - Missing a required length tag on port 0 at item 
> #14
> thread[thread-per-block[16]: ]: Missing length tag.
> b) No output
> c) It provides an output, but there is no block that removes the CRC
> bytes, so from my point of view, the BER rate should be higher even if
> I am using the block "Pack K Bits" with K=8, to recover the bytes
> after the modulation (Since "GMSK Demod" returns one bit of each byte
> in separate bytes and I need to reconstruct the signal)
> 
> I cannot find where I am making the mistake and I would like to ask if
> someone could point out where I am wrong so I can fix it. Thank you.
> -
> I tried to do also a simple test of Reed-Solomon encoding
> But I could not match any Reed-Solomon pair of coder & decoder that
> were paired together. Only the DVB-T one has, in the same section of
> the Companion, both the Encoder and the Decoder
> (If you use the magnifying glass search in the Companion, you find
> these Reed Solomon results)
> If you search for "Reed":
> 1.- ATSC only has a decoder, but I do not want to use a specific
> implementation; I want to use a general implementation for satellite
> applications
> 2.- ITU-T has only an encod

[Discuss-gnuradio] Simulation to compute BER of a Modulator/Demodulator Encoding/Decoding system

[Christian BusquielSanz]

Good day
How are you?
I am a new user to GNU Radio Companion
I am using version 3.7.11
I have read, followed and finished the exercises/examples in the
tutorials of Working with "GNU Radio Companion"
(https://wiki.gnuradio.org/index.php/Guided_Tutorial_GRC) and
"Programming GNU Radio in Python"
(https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python)
-
I have been working on designing a whole system to compute the BER of
different encoders using GMSK:
1.- Reed Solomon
2.- Convolutional Coding
3.- CRC

I have also installed GR Satellites by Daniel Estévez
(https://github.com/daniestevez/gr-satellites) to help me with this
task

I started building the whole system using GNU Radio Companion to build
the blocks, but I had many problems with the input and output of
blocks, since there were no transformations to adapt all the blocks
among them, and I tried several of the blocks provided with each
Encoder/Decoder to make it fit
-
Once I had an idea of how it should work, I tried to start with a
simple system only with one of the 'encoders' which was CRC (Stream
CRC32)

The Block Diagram would look like this (See attached "CRC_Test.grc" file):
(Random Source) => (Throttle) => (Stream to Tagged Stream) => (Stream
CRC32[Generate CRC]) =>A) B) C)
A) => (Char to Float) => (QT GUI Timer Sink)
B) => (GMSK Mod [S/S=10]) => (GMSK Demod [S/S=10]) => (Pack K Bits
[K=8]) => C) D)
C) 2x=> (BER) => (QT GUI Timer Sink)
D) => (Char to Float) => (QT GUI Timer Sink)

And also adding noise:
The Block Diagram would look like this (See attached
"CRC_Test_with_noise.grc" file):
(Random Source) => (Throttle) => (Stream to Tagged Stream) => (Stream
CRC32[Generate CRC]) =>A) B) C)
(Noise Source [Gaussian]) => D)
A) => (Char to Float) => (QT GUI Timer Sink)
B) => (GMSK Mod [S/S=10]) => D)
C) 2x=> (BER) => (QT GUI Timer Sink)
D) 2x=> (Add) => (GMSK Demod [S/S=10]) => (Pack K Bits [K=8]) => C) E)
E) => (Char to Float) => (QT GUI Timer Sink)

If I add another "Stream CRC32" block with [Check CRC]; I have three situations:
a) I add a "Stream to Tagged Stream" block before the (Stream CRC
[Check CRC]) with the same 'Length Tag Name' as the one after the
Throttle
b) I add a "Stream to Tagged Stream" block before the (Stream CRC
[Check CRC]) with a different 'Length Tag Name' as the one after the
Throttle and change the "Length Tag Key" of the "Stream CRC32" block
c) I do not add a "Stream to Tagged Stream" block before the (Stream
CRC [Check CRC])
I get these outputs:
a) It provides no output, and an error is shown up:
gr::log :FATAL: crc32_bb0 - Missing a required length tag on port 0 at item #14
thread[thread-per-block[16]: ]: Missing length tag.
b) No output
c) It provides an output, but there is no block that removes the CRC
bytes, so from my point of view, the BER rate should be higher even if
I am using the block "Pack K Bits" with K=8, to recover the bytes
after the modulation (Since "GMSK Demod" returns one bit of each byte
in separate bytes and I need to reconstruct the signal)

I cannot find where I am making the mistake and I would like to ask if
someone could point out where I am wrong so I can fix it. Thank you.
-
I tried to do also a simple test of Reed-Solomon encoding
But I could not match any Reed-Solomon pair of coder & decoder that
were paired together. Only the DVB-T one has, in the same section of
the Companion, both the Encoder and the Decoder
(If you use the magnifying glass search in the Companion, you find
these Reed Solomon results)
If you search for "Reed":
1.- ATSC only has a decoder, but I do not want to use a specific
implementation; I want to use a general implementation for satellite
applications
2.- ITU-T has only an encoder
3.- Satellites (By Dani Estévez) has both an encoder and a decoder;
but its input/output is async messages, and I want to test BER, so I
need a random source of bits. I do not know how to convert those bits
into messages to use these blocks.
If you search for "RS":
1.- ATSC shows both an Encoder as "ATSC RS Encoder" and an Decoder as
"ATSC Reed-Solomon Decoder" (Why do they have different titles?)
2.- Satellites (By Dani Estévez) has 15 entries, but all of them use
messages as input/output and I have the same problem with the Random
Source

So, I have not been able to build a proper block diagram and test it
to get any results

I believe that the best approach would be using the FEC Enconder and
Decoder from Satellites (By Dani Estévez); but I do not know how to
use the Async Message type with the Byte output from Random Source,
although I have sought for examples on type conversion, but I could
not find any

Could you point me in the right direction

[Discuss-gnuradio] BER calculation on GNU radio companion

[Linda20071]

Is there a box that can do the BER calculation given the clean input data
bit stream directly from the source and the demodulated data bit stream on
the receiver side?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Calculate BER in WIFI 802.11p standards !

[Bastian Bloessl]

Hi,


On 07/17/2017 11:06 AM, Mériem Saïdi wrote:

Hi,

I use 802.11 IEEE standards to code and decode a PMT message and i would 
like to calculate the BER between the source of information I want to 
encode and the same source after decoding. (see attached screen-shots below)
Except that I have all time a null BER ! however the "channel model" 
block introduce noise so the BER can't be null!
I've tried with a Random Source instead of Message Strobe but always the 
same result !
I don't know if the problem comes from one of the encoding/decoding 
flowgraph, or from the position of outputs i took to calculate BER ??!!

any ideas please ?!


If you want to see errors, you have to change the SNR (lower it) or 
switch to higher modulation and coding schemes.


Apart from that, it is currently not out of the box possible to measure 
the BER, just the FER. An example simulation can be found in the 
simulations/awgn folder of the project. It produces this plot


https://github.com/bastibl/gr-ieee802-11/blob/next/simulations/awgn/pdr.pdf

Best,
Bastian

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Calculate BER in WIFI 802.11p standards

[Meriem]

Hi,

I use 802.11 IEEE standards to code and decode a PMT message and i would
like to calculate the BER between the source of information I want to encode
and the same source after decoding. (see attached screen-shots below)
Except that I have all time a null BER ! however the "channel model" block
introduce noise so the BER can't be null!
I've tried with a Random Source instead of Message Strobe but always the
same result !
I don't know if the problem comes from one of the encoding/decoding
flow-graph, or from the position of outputs i took to calculate BER ??!!
any ideas please ?!

Cheers,
Meriem.
<http://gnuradio.4.n7.nabble.com/file/n64525/encoding.png> 
<http://gnuradio.4.n7.nabble.com/file/n64525/decoding.png> 
<http://gnuradio.4.n7.nabble.com/file/n64525/wifi_phy_hier.png> 
<http://gnuradio.4.n7.nabble.com/file/n64525/BER.png> 
<http://gnuradio.4.n7.nabble.com/file/n64525/result.png> 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Calculate-BER-in-WIFI-802-11p-standards-tp64525.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER & SNR

[Rafik ZITOUNI]

Thank you so match for your detailed and accurate answers.

I received a second answer from Phil Frost in which he explained my result.
So now i am doing same thing with QPSK and 8PSK.


Cheers,


2017-07-04 14:25 GMT+02:00 Phil Frost <ind...@bitglue.com>:

> On Tue, Jul 4, 2017 at 6:30 AM Rafik ZITOUNI <rzito...@gmail.com> wrote:
>
>> Could you give me an explanation how it was possible to obtain a good snr
>> and ber with a wrong constellation with  good SNR and BER?
>>
>
> for BPSK the value of the bit is determined only by examining the sign of
> the real part. There will be errors only when the cluster of points
> approaches the imaginary axis, where the sign of the real point changes. If
> the frequency offset it small (it rotates slowly) and the SNR high, then
> for most rotations there will be negligible errors.
>
> In practice you will probably have great difficulty tuning the receiver
> accurately enough for this to work. Furthermore, doppler shift in the
> channel may make the frequency change over time. Thus, the need for the
> Costas loop or some other frequency synchronization.
>
> Alternately, you can compare the phase of the current signal to the
> previous symbol: https://en.wikipedia.org/wiki/Phase-shift_keying#
> Demodulation
>



for BPSK the value of the bit is determined only by examining the sign of
the real part. There will be errors only when the cluster of points
approaches the imaginary axis, where the sign of the real point changes. If
the frequency offset it small (it rotates slowly) and the SNR high, then
for most rotations there will be negligible errors.

In practice you will probably have great difficulty tuning the receiver
accurately enough for this to work. Furthermore, doppler shift in the
channel may make the frequency change over time. Thus, the need for the
Costas loop or some other frequency synchronization.

Alternately, you can compare the phase of the current signal to the
previous symbol: https://en.wikipedia.org/wiki/Phase-shift_keying#
Demodulation


2017-07-04 12:48 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:

> BER is an observation, a count, not an estimation – it only makes sense to
> talk about a Bit Error Rate (BER) after a complete physical layer receiver,
> i.e. at the bit level. You can estimate the BER of a whole system if you
> know how it reacts to noise – but that's typically not what you do.
> Instead, you just simulate with various noise/distortion levels, measure
> for each of these and write down the number of wrong bits. A good receiver
> will make more of a noisy signal (lower BER) than a bad receiver for the
> same modulation. So, BER depends on your receiver implementation.
>
> SNR, on the other hand, the Signal-to-noise-ratio, is not something that
> depends on your implementation – it's really just the ratio of Signal power
> to noise power. Since we're looking at a noise reception, one can only
> write an estimator for these powers – and thus, SNR is a measure relative
> to a mathematical model of your reception, and not something that indicated
> demodulability. It's very important to say *where* in the signal chain
> you look at the SNR – is it directly at the antenna? After mixing to
> baseband? After filtering to a channel bandwidth? It's equally important to
> explicitly specify what you consider signal and what you consider noise
> power – for example, one might say "OK, after my timing recovery, I still
> have a bit of phase offset, but that's OK, I just declare the difference
> between perfect constellation point and actual recovered point "noise" and
> be done with it". That's a very practical thing to look at – and, indeed,
> for the decider, which has to convert complex numbers to bits, it just
> looks like a random addition to the perfect signal, but that power didn't
> come in as noise power – it's just an error we introduced by not being able
> to perfectly synchronize.
>
> As another example, if you take any signal, and shift it in frequency,
> then that doesn't change its power at all! So, a reception with a terribly
> bad frequency offset still has the same SNR as a perfectly synchronized
> one. UNLESS, that is, that you declare the phase offset between recovered
> symbols and perfect constellation points "noise".
>
> Now, depending on what you declare to be noise and what you declare to be
> signal, you'd define different SNR estimators. I constantly repeat this (I
> don't mind, someone has to):
>
> *There's no single "right" SNR estimator. Everything depends on what you
> define to be noise and what you define to be signal. One man's noise is
> another man's signal.*
>
> Coming back to your original question:
> > How Is it possible to get a good 

Re: [Discuss-gnuradio] BER & SNR

[Marcus Müller]

BER is an observation, a count, not an estimation – it only makes sense
to talk about a Bit Error Rate (BER) after a complete physical layer
receiver, i.e. at the bit level. You can estimate the BER of a whole
system if you know how it reacts to noise – but that's typically not
what you do. Instead, you just simulate with various noise/distortion
levels, measure for each of these and write down the number of wrong
bits. A good receiver will make more of a noisy signal (lower BER) than
a bad receiver for the same modulation. So, BER depends on your receiver
implementation.

SNR, on the other hand, the Signal-to-noise-ratio, is not something that
depends on your implementation – it's really just the ratio of Signal
power to noise power. Since we're looking at a noise reception, one can
only write an estimator for these powers – and thus, SNR is a measure
relative to a mathematical model of your reception, and not something
that indicated demodulability. It's very important to say /where/ in the
signal chain you look at the SNR – is it directly at the antenna? After
mixing to baseband? After filtering to a channel bandwidth? It's equally
important to explicitly specify what you consider signal and what you
consider noise power – for example, one might say "OK, after my timing
recovery, I still have a bit of phase offset, but that's OK, I just
declare the difference between perfect constellation point and actual
recovered point "noise" and be done with it". That's a very practical
thing to look at – and, indeed, for the decider, which has to convert
complex numbers to bits, it just looks like a random addition to the
perfect signal, but that power didn't come in as noise power – it's just
an error we introduced by not being able to perfectly synchronize.

As another example, if you take any signal, and shift it in frequency,
then that doesn't change its power at all! So, a reception with a
terribly bad frequency offset still has the same SNR as a perfectly
synchronized one. UNLESS, that is, that you declare the phase offset
between recovered symbols and perfect constellation points "noise".

Now, depending on what you declare to be noise and what you declare to
be signal, you'd define different SNR estimators. I constantly repeat
this (I don't mind, someone has to):

*There's no single "right" SNR estimator. Everything depends on what you
define to be noise and what you define to be signal. One man's noise is
another man's signal.*

Coming back to your original question:

> How Is it possible to get a good estimation of the BER without a
costas loop?

It's not an estimate. If you get BER of 0, then your receiver did not
make a single bit error, if you get BER=0.5, then every second bit is
wrong. So, that estimator is pretty much perfect.

If you remove the phase synchronization (i.e. the costas loop) from your
receiver, you make it a worse receiver. Then, your BER increases, if
your receiver gets sufficiently bad.

I hope that answers your question!

If not, please don't hesitate to elaborate (in length!)

Best regards,

Marcus


On 07/04/2017 11:49 AM, Rafik ZITOUNI wrote:
> My question is: 
>
> How Is it possible to get a good estimation of the BER without a
> costas loop? 
>
>
>
>
> 2017-07-04 11:39 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>>:
>
> You're still not explaining what your question is – I really don't
> know what to answer.
>
> What is wrong?
>
>
> On 07/04/2017 11:31 AM, Rafik ZITOUNI wrote:
>> Sorry I missed to add the flow graph. 
>> Here is attached. 
>>
>> 2017-07-04 11:29 GMT+02:00 Rafik ZITOUNI <rzito...@gmail.com
>> <mailto:rzito...@gmail.com>>:
>>
>> Marcus, 
>>
>> You find attached my flow graph with  Tx and Rx. I know that
>> it is not recommended to have TX and RX in the same flow
>> graph but i did it just to obtain one view for my Tx and Rx. 
>>
>> Thanks,  
>>
>> 2017-07-04 11:23 GMT+02:00 Marcus Müller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>:
>>
>> Dear Rafik,
>>
>> I think we're approaching this from the wrong side: I
>> don't think that I should be explaining why you get a
>> good BER and SNR estimate, it is you who should explain
>> why you're expecting something different, and then we can
>> discuss! I'm not quite sure what I could be explaining at
>> this point :)
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 07/04/2017 11:20 AM, Rafik ZITOUNI wrote:
>>> Thank 

Re: [Discuss-gnuradio] BER & SNR

[Rafik ZITOUNI]

My question is:

How Is it possible to get a good estimation of the BER without a costas
loop?




2017-07-04 11:39 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:

> You're still not explaining what your question is – I really don't know
> what to answer.
>
> What is wrong?
>
> On 07/04/2017 11:31 AM, Rafik ZITOUNI wrote:
>
> Sorry I missed to add the flow graph.
> Here is attached.
>
> 2017-07-04 11:29 GMT+02:00 Rafik ZITOUNI <rzito...@gmail.com>:
>
>> Marcus,
>>
>> You find attached my flow graph with  Tx and Rx. I know that it is not
>> recommended to have TX and RX in the same flow graph but i did it just to
>> obtain one view for my Tx and Rx.
>>
>> Thanks,
>>
>> 2017-07-04 11:23 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:
>>
>>> Dear Rafik,
>>>
>>> I think we're approaching this from the wrong side: I don't think that I
>>> should be explaining why you get a good BER and SNR estimate, it is you who
>>> should explain why you're expecting something different, and then we can
>>> discuss! I'm not quite sure what I could be explaining at this point :)
>>>
>>> Best regards,
>>>
>>> Marcus
>>>
>>> On 07/04/2017 11:20 AM, Rafik ZITOUNI wrote:
>>>
>>> Thank you Marcus for your answer !
>>>
>>> My BER and SNR are calculated and obtained using MPSK SNR Estimator
>>> Probe and Error Rate blocks. I obtained  two points, which rotate in the qt
>>> gui constellation sink despite the BER and SNR have been obtained as
>>> expected. Could you give me an explanation how it was possible to obtain a
>>> good snr and ber with a wrong constellation with  good SNR and BER?
>>>
>>> I found the  presentation of Tom Rondeau useful, since he explained the
>>> function of the costas loop block.  https://static.squares
>>> pace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08
>>> 633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf
>>>
>>>
>>> This morning I add a Costas loop after a Polyphase Clock Syncronisation
>>> block, and it s going well. You find attached a screenshot of my
>>> constellation for a DBPSK of my receiver/transmitter. I propose to add
>>> a grc to gnuradio/gr-digital for MPSK since grc is more easy to understand
>>> than python source code.
>>>
>>>
>>> Now I am trying to send and receive data files such as videos or images
>>> (bmp). Do you have an example with a file exchange implemented in .py or
>>> grc?
>>>
>>> Best,
>>>
>>>
>>> 2017-07-04 9:44 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:
>>>
>>>> Hi Rafik!
>>>>
>>>> So, what's wrong with the BER and the SNR estimate?
>>>>
>>>> Best regards,
>>>>
>>>> Marcus
>>>>
>>>> On 07/03/2017 11:29 PM, Rafik ZITOUNI wrote:
>>>>
>>>> Dear all,
>>>>
>>>> I translate the /gr-digital/examples/narrowband/digital_bert_tx.py and
>>>> the /gr-digital/examples/narrowband/digital_bert_rx.py python source
>>>> codes to GRC flow graphs. The objective is to get more graphical
>>>> possibilities with a GRC.  My flow graph gives a fine result of BER and SNR
>>>> for DBPSK modulation.
>>>> The problem is with the rotating points of my constellation. I think
>>>> that the rotation of my view comes from a lack of frequency
>>>> synchronization, but why I obtained a correct BER and SNR?
>>>>
>>>> You find attached to this message a constellation view obtained by my
>>>> flow graph.
>>>>
>>>> Please could you explain me this  result or give an advice to improve
>>>> the obtained result?
>>>>
>>>> Regards,
>>>>
>>>>
>>>> --
>>>> <http://www.ece.fr/>Rafik
>>>>
>>>>
>>>>
>>>> ___
>>>> Discuss-gnuradio mailing 
>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>> ___ Discuss-gnuradio
>>>> mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/
>>>> listinfo/discuss-gnuradio
>>>
>>> --
>>> <http://www.ece.fr/>Rafik
>>>
>>> --
>> <http://www.ece.fr/>Rafik
>>
> --
> <http://www.ece.fr/>Rafik
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


-- 
<http://www.ece.fr/>Rafik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER & SNR

[Marcus Müller]

You're still not explaining what your question is – I really don't know
what to answer.

What is wrong?


On 07/04/2017 11:31 AM, Rafik ZITOUNI wrote:
> Sorry I missed to add the flow graph. 
> Here is attached. 
>
> 2017-07-04 11:29 GMT+02:00 Rafik ZITOUNI <rzito...@gmail.com
> <mailto:rzito...@gmail.com>>:
>
> Marcus, 
>
> You find attached my flow graph with  Tx and Rx. I know that it is
> not recommended to have TX and RX in the same flow graph but i did
> it just to obtain one view for my Tx and Rx. 
>
> Thanks,  
>
> 2017-07-04 11:23 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>>:
>
> Dear Rafik,
>
> I think we're approaching this from the wrong side: I don't
> think that I should be explaining why you get a good BER and
> SNR estimate, it is you who should explain why you're
> expecting something different, and then we can discuss! I'm
> not quite sure what I could be explaining at this point :)
>
> Best regards,
>
> Marcus
>
>
>     On 07/04/2017 11:20 AM, Rafik ZITOUNI wrote:
>> Thank you Marcus for your answer !
>>
>> My BER and SNR are calculated and obtained using MPSK SNR
>> Estimator Probe and Error Rate blocks. I obtained  two
>> points, which rotate in the qt gui constellation sink despite
>>     the BER and SNR have been obtained as expected. Could you
>> give me an explanation how it was possible to obtain a good
>> snr and ber with a wrong constellation with  good SNR and BER?
>>
>> I found the  presentation of Tom Rondeau useful, since he
>> explained the function of the costas loop
>> block.  
>> https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf
>> 
>> <https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf>
>>
>>
>> This morning I add a Costas loop after a Polyphase Clock
>> Syncronisation block, and it s going well. You find attached
>> a screenshot of my constellation for a DBPSK of
>> my receiver/transmitter. I propose to add a grc to
>> gnuradio/gr-digital for MPSK since grc is more easy to
>> understand than python source code.
>>
>>
>> Now I am trying to send and receive data files such as videos
>> or images (bmp). Do you have an example with a file
>> exchange implemented in .py or grc?
>>
>> Best,  
>>
>>
>> 2017-07-04 9:44 GMT+02:00 Marcus Müller
>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>:
>>
>> Hi Rafik!
>>
>> So, what's wrong with the BER and the SNR estimate?
>>
>> Best regards,
>>
>> Marcus
>>
>>
>> On 07/03/2017 11:29 PM, Rafik ZITOUNI wrote:
>>> Dear all, 
>>>
>>> I translate the
>>> /gr-digital/examples/narrowband/digital_bert_tx.py and
>>> the /gr-digital/examples/narrowband/digital_bert_rx.py
>>> python source codes to GRC flow graphs. The objective is
>>> to get more graphical possibilities with a GRC.  My flow
>>> graph gives a fine result of BER and SNR for DBPSK
>>> modulation. 
>>> The problem is with the rotating points of my
>>> constellation. I think that the rotation of my view
>>> comes from a lack of frequency synchronization, but why
>>> I obtained a correct BER and SNR?
>>>
>>> You find attached to this message a constellation view
>>> obtained by my flow graph. 
>>>
>>> Please could you explain me this  result or give an
>>> advice to improve the obtained result? 
>>>
>>> Regards, 
>>>
>>>
>>> -- 
>>> **<http://www.ece.fr/>Rafik
>>>
>>>
>>>
>>> ___
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>>> https://lists.gnu.org/mailman/listinfo/discu

Re: [Discuss-gnuradio] BER & SNR (was: Re: (no subject))

[Rafik ZITOUNI]

Marcus,

You find attached my flow graph with  Tx and Rx. I know that it is not
recommended to have TX and RX in the same flow graph but i did it just to
obtain one view for my Tx and Rx.

Thanks,

2017-07-04 11:23 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:

> Dear Rafik,
>
> I think we're approaching this from the wrong side: I don't think that I
> should be explaining why you get a good BER and SNR estimate, it is you who
> should explain why you're expecting something different, and then we can
> discuss! I'm not quite sure what I could be explaining at this point :)
>
> Best regards,
>
> Marcus
>
> On 07/04/2017 11:20 AM, Rafik ZITOUNI wrote:
>
> Thank you Marcus for your answer !
>
> My BER and SNR are calculated and obtained using MPSK SNR Estimator Probe
> and Error Rate blocks. I obtained  two points, which rotate in the qt gui
> constellation sink despite the BER and SNR have been obtained as expected.
> Could you give me an explanation how it was possible to obtain a good snr
> and ber with a wrong constellation with  good SNR and BER?
>
> I found the  presentation of Tom Rondeau useful, since he explained the
> function of the costas loop block.  https://static.squares
> pace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08
> 633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf
>
>
> This morning I add a Costas loop after a Polyphase Clock Syncronisation
> block, and it s going well. You find attached a screenshot of my
> constellation for a DBPSK of my receiver/transmitter. I propose to add a
> grc to gnuradio/gr-digital for MPSK since grc is more easy to understand
> than python source code.
>
>
> Now I am trying to send and receive data files such as videos or images
> (bmp). Do you have an example with a file exchange implemented in .py or
> grc?
>
> Best,
>
>
> 2017-07-04 9:44 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com>:
>
>> Hi Rafik!
>>
>> So, what's wrong with the BER and the SNR estimate?
>>
>> Best regards,
>>
>> Marcus
>>
>> On 07/03/2017 11:29 PM, Rafik ZITOUNI wrote:
>>
>> Dear all,
>>
>> I translate the /gr-digital/examples/narrowband/digital_bert_tx.py and
>> the /gr-digital/examples/narrowband/digital_bert_rx.py python source
>> codes to GRC flow graphs. The objective is to get more graphical
>> possibilities with a GRC.  My flow graph gives a fine result of BER and SNR
>> for DBPSK modulation.
>> The problem is with the rotating points of my constellation. I think that
>> the rotation of my view comes from a lack of frequency synchronization, but
>> why I obtained a correct BER and SNR?
>>
>> You find attached to this message a constellation view obtained by my
>> flow graph.
>>
>> Please could you explain me this  result or give an advice to improve the
>> obtained result?
>>
>> Regards,
>>
>>
>> --
>> <http://www.ece.fr/>Rafik
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing 
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>> ___ Discuss-gnuradio mailing
>> list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/
>> listinfo/discuss-gnuradio
>
> --
> <http://www.ece.fr/>Rafik
>
>


-- 
<http://www.ece.fr/>Rafik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] BER & SNR (was: Re: (no subject))

[Marcus Müller]

Dear Rafik,

I think we're approaching this from the wrong side: I don't think that I
should be explaining why you get a good BER and SNR estimate, it is you
who should explain why you're expecting something different, and then we
can discuss! I'm not quite sure what I could be explaining at this point :)

Best regards,

Marcus


On 07/04/2017 11:20 AM, Rafik ZITOUNI wrote:
> Thank you Marcus for your answer !
>
> My BER and SNR are calculated and obtained using MPSK SNR Estimator
> Probe and Error Rate blocks. I obtained  two points, which rotate in
> the qt gui constellation sink despite the BER and SNR have been
> obtained as expected. Could you give me an explanation how it was
> possible to obtain a good snr and ber with a wrong constellation with
>  good SNR and BER?
>
> I found the  presentation of Tom Rondeau useful, since he explained
> the function of the costas loop
> block.  
> https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf
> <https://static.squarespace.com/static/543ae9afe4b0c3b808d72acd/543aee1fe4b09162d08633fc/543aee1fe4b09162d0863402/1392309732018/mpsk.pdf>
>
>
> This morning I add a Costas loop after a Polyphase Clock
> Syncronisation block, and it s going well. You find attached a
> screenshot of my constellation for a DBPSK of
> my receiver/transmitter. I propose to add a grc to gnuradio/gr-digital
> for MPSK since grc is more easy to understand than python source code.
>
>
> Now I am trying to send and receive data files such as videos or
> images (bmp). Do you have an example with a file exchange implemented
> in .py or grc?
>
> Best,  
>
>
> 2017-07-04 9:44 GMT+02:00 Marcus Müller <marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>>:
>
> Hi Rafik!
>
> So, what's wrong with the BER and the SNR estimate?
>
> Best regards,
>
> Marcus
>
>
> On 07/03/2017 11:29 PM, Rafik ZITOUNI wrote:
>> Dear all, 
>>
>> I translate the
>> /gr-digital/examples/narrowband/digital_bert_tx.py and the
>> /gr-digital/examples/narrowband/digital_bert_rx.py python source
>> codes to GRC flow graphs. The objective is to get more graphical
>> possibilities with a GRC.  My flow graph gives a fine result of
>> BER and SNR for DBPSK modulation. 
>> The problem is with the rotating points of my constellation. I
>> think that the rotation of my view comes from a lack of frequency
>> synchronization, but why I obtained a correct BER and SNR?
>>
>> You find attached to this message a constellation view obtained
>> by my flow graph. 
>>
>> Please could you explain me this  result or give an advice to
>> improve the obtained result? 
>>
>> Regards, 
>>
>>
>> -- 
>> **<http://www.ece.fr/>Rafik
>>
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>
> ___ Discuss-gnuradio
> mailing list Discuss-gnuradio@gnu.org
> <mailto:Discuss-gnuradio@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> 
>
> -- 
> **<http://www.ece.fr/>Rafik
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Eb/ No, BER and Doppler Shift display

[Mehmeto]

Hi All,
 We do have a signal generator in the LAB that can take a BPSK modulated
signal (at 2 MSPS) and add some Doppler Shift (from - 50 to 50 kHz) at 2
GHz.
 On the receiving end we have a downconverter and a  professional modem that
can display;
Eb/ No
BER
Doppler Shift
Frame (ASM) Lock Display

 We want to replicate the system in GNU Radio/ LimeSDR but need your advice
first for Block selection.

1.PSK demodulator that can demodulate under Doppler Shift.(No manual Doppler
shift correction needed like GPredict output)

2. Display of BER and Doppler Shift

3. Frame (ASM-Sync Word) Lock Display

4. A block for simulating the Doppler Shift?? Is the Channel Model Block
suitable??

Thanks for your time in advance




--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Eb-No-BER-and-Doppler-Shift-display-tp63116.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Flowgraph with BER Block freezing

[adrian . perez . portero]

I have been trying to incorporate BER measures in a more complex  
flowgraph that includes OFDM.
I created a basic example to understand it better, but to my surprise  
when I run it, it stops after 2 seconds approximately. The interface  
is working, but the FFT Sink and BER Number Sink are stopped. If I  
disable the BER block and the Virtual Source and Number Sink, and  
instead enable the Tag Debug, the flowgraph keeps running indefinitely.

I attached bertest.grc to this message.


bertest.grc
Description: application/gnuradio-grc
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trying to get ber graph right ?

[AzieRis]

Ah yeah right i did a wrong connection after adding error rate block to my
flow graph !
But still i don't get the graph from scope sink is there so special way to
display it ?

Thanks for response,
Adrian



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Trying-to-get-ber-graph-right-tp62365p62369.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Trying to get ber graph right ?

[Marcus Müller]

Should you not be comparing the bits that go into the encoder to the received 
bits, and not the ones coming out of the encoder?

Best regards,
Marcus

Am 22. Dezember 2016 05:31:52 MEZ, schrieb AzieRis <ardian.ziem...@gmail.com>:
>Hello everyone,
>I would like to ask if there is something i am doing wrong with my flow
>graph or is it wrong usage of blocks in my project. 
>So here it is: http://screenshot.sh/ovZAMj1uo6w1k (uploading .grc and
>.fsm
>files also)
>Turbocoding.grc
><http://gnuradio.4.n7.nabble.com/file/n62365/Turbocoding.grc>   , 
>fsm1.fsm
><http://gnuradio.4.n7.nabble.com/file/n62365/fsm1.fsm>  
>There is just a window poping out for a second and disappearing - no
>idea
>why ?
>I am trying to get graph of BER performance of this coding after
>modulation
>and changing noise value.
>Maybe there is a simpler way to do it right. 
>
>Thanks in advance for every response to this post.
>Regards
>Adrian
>
>
>
>--
>View this message in context:
>http://gnuradio.4.n7.nabble.com/Trying-to-get-ber-graph-right-tp62365.html
>Sent from the GnuRadio mailing list archive at Nabble.com.
>
>___
>Discuss-gnuradio mailing list
>Discuss-gnuradio@gnu.org
>https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Trying to get ber graph right ?

[AzieRis]

Hello everyone,
I would like to ask if there is something i am doing wrong with my flow
graph or is it wrong usage of blocks in my project. 
So here it is: http://screenshot.sh/ovZAMj1uo6w1k (uploading .grc and .fsm
files also)
Turbocoding.grc
<http://gnuradio.4.n7.nabble.com/file/n62365/Turbocoding.grc>   ,  fsm1.fsm
<http://gnuradio.4.n7.nabble.com/file/n62365/fsm1.fsm>  
There is just a window poping out for a second and disappearing - no idea
why ?
I am trying to get graph of BER performance of this coding after modulation
and changing noise value.
Maybe there is a simpler way to do it right. 

Thanks in advance for every response to this post.
Regards
Adrian



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/Trying-to-get-ber-graph-right-tp62365.html
Sent from the GnuRadio mailing list archive at Nabble.com.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Synchronization for BER calculation

[Tech]

The manual bitstream alignment as described in:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation

is fine when the source bits and recovered bits are in the same
flowgraph but I have a situation where I'm reading from a file so the
synchronization is unknown. In the past I was able to seed a LFSR with
a block of recovered bits and (as long as none are in error) each
subsequent bit should be in sync with the source bits.

The other possibility is just to search all possible alignments but
that can be time consuming for lengthy PN sequences.

Anyway, I figured this is probably a solved problem in gnuradio and
somebody might have suggestions?

Thanks

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [Re: BER value]

[Marcus Müller]

Hi Antonio,

> Could you tell me how can I solve the problem with the offset between
> the DPSK mod and demod?
Use a BER analysator with some kind of large window. In effect, I'd just
write the raw send symbol stream to a file, do the same with the receive
symbol stream, and calculate the error offline, if I hadn't had packets.

> Likewise, as you say, I am using a packet-based transmission.
That makes BER a bit of a "secondary issue", doesn't it? Packets have
checksums, and for all packets that contain bit errors, there's
(hopefully) a high probability the checksum will be wrong, and the whole
packet needs to be considered lost. Also, assuming symbol errors are
equally likely for all symbols in a packet, you should be able to derive
a PDF for the number of wrong bits per wrong packet, based on AWGN –
yeah, it's that stuff from digital comm basics :)

Anyway, having packets makes the whole measuring a lot easier; you'll
need to write a block that buffers both the send packets and the receive
packets. I don't know your packet format, but it possibly has a packet
number. Use that packet number to delete received packets from the send
packet buffer. If a packet is broken, reconstruct its number from the
next/previous successfully received packet. Note down the correct
received packets as successfull bits, and count the missing and broken
packets.

Best regards,
Marcus

On 17.07.2016 21:33, ANTONIO TAMAYO wrote:
> Hello Martin,
>
> Thank you for your response. 
> Could you tell me how can I solve the problem with the offset between
> the DPSK mod and demod?
> In the same way, how can I garantee that I am comparing the correct
> bits? Using another block?
> Likewise, as you say, I am using a packet-based transmission. For this
> reason I need to perform more sophisticated comparisons to calculate
> the BER, what do you recommend me to calculate BER?
>
> Thank you all,
>
> Antonio
>
> On 06/13/2016 09:46 AM, MARTIN BRAUN wrote:
> >Antonio,
> >
> >I'm not sure why it's telling you 'no BER', but your setup is not
> >suitable to test BER anyway. Your DPSK demod will always be offset w.r.t
> >the DPSK mod input (because of sync delays etc.).
> >
> >Such BER measurements only work well if you can guarantee you're
> >comparing the right bits.
> >
> >Since you're doing packet-based transmission, you'll need to come up
> >with something more sophisticated comparison.
> >
> >Cheers,
> >Martin
> >
> >On 06/12/2016 12:22 PM, ANTONIO TAMAYO wrote:
> >> Hello all,
> >>
> >> I'm trying to calculate de BER value of the comunications system of the
> >> image attached. I'm using a DQPSK modulator and demodulator. I think
> >> that I have made mistakes in the configuration of my sistem because the
> >> BER value always is "none", but I can't solve them. Somebody could help me?
> >>
> >> Regards,
> >>
> >> Antonio.
> >>
> >>
> >> ___
> >> Discuss-gnuradio mailing list
> >> Discuss-gnuradio@gnu.org <mailto: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] [Re: BER value]

[ANTONIO TAMAYO]

Hello Martin,

Thank you for your response.
Could you tell me how can I solve the problem with the offset between the
DPSK mod and demod?
In the same way, how can I garantee that I am comparing the correct bits?
Using another block?
Likewise, as you say, I am using a packet-based transmission. For this
reason I need to perform more sophisticated comparisons to calculate the
BER, what do you recommend me to calculate BER?

Thank you all,

Antonio

On 06/13/2016 09:46 AM, MARTIN BRAUN wrote:
>Antonio,
>
>I'm not sure why it's telling you 'no BER', but your setup is not
>suitable to test BER anyway. Your DPSK demod will always be offset w.r.t
>the DPSK mod input (because of sync delays etc.).
>
>Such BER measurements only work well if you can guarantee you're
>comparing the right bits.
>
>Since you're doing packet-based transmission, you'll need to come up
>with something more sophisticated comparison.
>
>Cheers,
>Martin
>
>On 06/12/2016 12:22 PM, ANTONIO TAMAYO wrote:
>> Hello all,
>>
>> I'm trying to calculate de BER value of the comunications system of the
>> image attached. I'm using a DQPSK modulator and demodulator. I think
>> that I have made mistakes in the configuration of my sistem because the
>> BER value always is "none", but I can't solve them. Somebody could help
me?
>>
>> Regards,
>>
>> Antonio.
>>
>>
>> ___
>> 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] Scale ESN0 on BER Curve Gen when using codes of different rates?

[Sean Nowlan]

I'd like to use BER Curve Gen and QT BER Sink to simulate some FEC schemes
that have different code rates. I'm wondering about the right way to do
this so that the plots are w.r.t. EBN0 as opposed to ESN0.

For example, in gr-fec/examples/ber_curve_gen.grc, plots are w.r.t ESN0. In
order to make them plot w.r.t. EBN0, I imagine I'd want to scale the
"esno_0" vector by the code rate for each FEC scheme and feed each to its
BER Curve Gen block. This would be something like:

esno_0 - 10.0*numpy.log10(.rate())

Then I would pass esno_0 unmodified to QT GUI Bercurve Sink. Does this
sound reasonable?

Thanks,
Sean
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] BER value

[Martin Braun]

Antonio,

I'm not sure why it's telling you 'no BER', but your setup is not
suitable to test BER anyway. Your DPSK demod will always be offset w.r.t
the DPSK mod input (because of sync delays etc.).

Such BER measurements only work well if you can guarantee you're
comparing the right bits.

Since you're doing packet-based transmission, you'll need to come up
with something more sophisticated comparison.

Cheers,
Martin

On 06/12/2016 12:22 PM, ANTONIO TAMAYO wrote:
> Hello all,
> 
> I'm trying to calculate de BER value of the comunications system of the
> image attached. I'm using a DQPSK modulator and demodulator. I think
> that I have made mistakes in the configuration of my sistem because the
> BER value always is "none", but I can't solve them. Somebody could help me?
> 
> Regards,
> 
> Antonio.
> 
> 
> ___
> 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] BER & constellation plot for OFDM transmit/receive

[Martin Braun]

On 04/21/2016 10:02 PM, Jingyi Sun wrote:
> Constellation Diagram:
> As you mentioned, Martin, it was the hard decision that was forcing the
> output to just four dots. We wired the constellation diagram up to the
> output of the OFDM receiver FFT, but before the equalizer, and the
> constellation diagram became a fairly neat circle. I suspect that the
> diagram is a circle because the frequency/time synchronization, which is
> usually performed in the OFDM equalizer, is now missing. We will work on
> implementing an equalizer without the hard decision, and will ask if we
> have any questions.

Jenny,

synchronization and equalization are *not* done by the same block.
However, the ofdm_frame_equalizer *does* correct coarse frequency
offset, but it needs to know the value of that offset coming in.

Something like a 2D-Wiener-Filter or derived would be a great addition.
It would be a great extension for GNU Radio if you could upstream your
changes once you've finalized them.

> Bit Error Rate:
> We found a helpful post online that indicated that perhaps the BER only
> works if the number of samples = the payload length of the OFDM process,
> which I believe is 64. After setting the random source number of samples
> to 64 (repeat = yes), we also added a variable 1-64 sample delay before
> the BER block’s reference input. We then ran the program, and varied the
> delay between 1-64 to see if the BER would drop. Unfortunately, we had
> no luck. 

Do you have any packet loss in your system? If so, you'll never be able
to correctly compare things with a static delay.

> To debug, we sent the two signals going into the BER block into two QT
> time sinks to do a visual comparison. What we found was that the signals
> were clearly identical. However, the signal going into the BER reference
> input (which came from the random source) was static, while the signal
> going into the BER data input was streaming. We were wondering if this
> had any affect on the measurement? I’ve linked to a video showing what I
> mean in the following dropbox link:

I'm not sure that's what's happening. Note that you're producing 64
"random" bits, and then repeat them. How would you know if the screen is
constantly updated with the same data?
On the receive side, that's not necessarily true, since the channel can
cause packet loss.


M
> 
> https://www.dropbox.com/s/usx2hx5uuhogxbi/Video%20Apr%2021%2C%205%2038%2047%20PM.mov?dl=0
> 
> In addition, I’ve attached two screenshots showing our flow diagram,
> with the relevant parts related to the BER highlighted. The two
> screenshots come from the same flow diagram, it’s just too large to fit
> on one screen.
> 
> Thanks again for all your help! Let us know if you have any ideas and
> we’ll give it go in the lab.
> 
> Best,
> Jenny & Team
> 
> 
> ​
> 
> On Thu, Apr 21, 2016 at 2:11 PM, Jingyi Sun <sunjing...@gmail.com
> <mailto:sunjing...@gmail.com>> wrote:
> 
> What do you mean by "hard-decision" equalizer, and "drop them down"?
> 
> Thanks so much!!
> 
> On Thu, Apr 21, 2016 at 2:01 PM, Martin Braun
> <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
> 
> That's because the equalizer used is a hard-decision equalizer.
> You can
> write your own equalizers and drop them down for better results;
> that's
> something I've been meaning to do for a while, but haven't found the
> time yet.
> 
> Cheers,
> M
> 
> On 04/20/2016 09:56 PM, Jingyi Sun wrote:
> > Hope pictures below give more context.   Has anyone seen this 
> happen before?
> >
> > To reword the part of our question about constellation plots a 
> little,
> > does anyone know when the constellation block would output just four
> > single points?
> >
> > The problem we’re currently facing is that the constellation plot 
> does
> > not even really show up -/there’s not even a giant blob to
> indicate
> > noise/. Instead, we get only 4 points, one in each of the four
> locations
> > you’d expect for a QPSK signal - but only those 4 points./It
> almost
> > feels like the constellation plot stops triggering after these first
> > four points/, and that’s why we don’t receive anymore data.
> *We’re using
> > a free trigger on the positive slope, centered at 0, *which I feel
> > should trigger at least something even if it’s just noise.  We have 
> also
> > tried other trigger methods, which output either 4 points, 5 points 
> (1
>   

Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive

[Jingyi Sun]

What do you mean by "hard-decision" equalizer, and "drop them down"?

Thanks so much!!

On Thu, Apr 21, 2016 at 2:01 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> That's because the equalizer used is a hard-decision equalizer. You can
> write your own equalizers and drop them down for better results; that's
> something I've been meaning to do for a while, but haven't found the
> time yet.
>
> Cheers,
> M
>
> On 04/20/2016 09:56 PM, Jingyi Sun wrote:
> > Hope pictures below give more context.   Has anyone seen this happen
> before?
> >
> > To reword the part of our question about constellation plots a little,
> > does anyone know when the constellation block would output just four
> > single points?
> >
> > The problem we’re currently facing is that the constellation plot does
> > not even really show up -/there’s not even a giant blob to indicate
> > noise/. Instead, we get only 4 points, one in each of the four locations
> > you’d expect for a QPSK signal - but only those 4 points./It almost
> > feels like the constellation plot stops triggering after these first
> > four points/, and that’s why we don’t receive anymore data. *We’re using
> > a free trigger on the positive slope, centered at 0, *which I feel
> > should trigger at least something even if it’s just noise.  We have also
> > tried other trigger methods, which output either 4 points, 5 points (1
> > additional point in the center), or just 1 center point.
> >
> >
> > ​
> > ​
> > ​
> >
> > On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun <sunjing...@gmail.com
> > <mailto:sunjing...@gmail.com>> wrote:
> >
> > We are not compensating for any lost packets, although we would be
> > aware of them thanks to the packet number. Could you tell us if
> > there’s a block to do this, or would we need a custom block?
> >
> >
> > Also, could you tell us why the constellation diagram is not
> > displaying properly?
> >
> >
> > Thanks,
> >
> > Jenny
> >
> >
> >
> > On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun
> > <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
> >
> > Are you comparing the correct packets? E.g., if packets get
> > lost, do you
> > take that into account?
> >
> > M
> >
> > On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > > Hi everyone,
> > >
> > > We are working on an experiment for a conference paper
> deadline in two
> >     > weeks, and need to transmit and receive OFDM packets and want
> to study
> > > the constellation diagram and BER.
> > >
> > > I put together a flow graph consisting of an *OFDM transmitter
> > block*
> > > and an *unpacked OFDM receiver* based on the online example
> > rx_ofdm.grc.
> > > Here's how I'm trying to measure constellation diagram and BER:
> > >
> > >   * I inserted a QT constellation sink right before the
> > constellation
> > > decoder on the payload IQ stream, but it does not seem to
> output
> > > anything meaningful. The plot just shows single, clean
> points, which
> > > I am pretty sure does not correspond to real data. I
> suspect that
> > > the plots are not triggering properly, but am not sure.
> > >
> > >   * For BER, we tried several different configurations, and
> > they mostly
> > > give BER = 0.5 (i.e. random).  Our leading theory is that
> we're not
> > > comparing the data at the correct points in the flow
> graph. Any
> > > suggestions as to what the BER inputs should be would be
> helpful.
> > >
> > > We've been running some diagnostics that seem to eliminate our
> > > communication channel as the problem:
> > >
> > >   * We are transmitting the data over-the-air at 915 MHz using
> > > two omnidirectional antennas, placed roughly 1 meter
> apart. The
> > > output spectra at the transmitter output and receiver
> input are
> > > attached - all signals are comfortably above the noise
> floor.
> > >   * From the tag debug output, we see that the OFDM packet
> > headers are
> > > be

Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive

[Martin Braun]

That's because the equalizer used is a hard-decision equalizer. You can
write your own equalizers and drop them down for better results; that's
something I've been meaning to do for a while, but haven't found the
time yet.

Cheers,
M

On 04/20/2016 09:56 PM, Jingyi Sun wrote:
> Hope pictures below give more context.   Has anyone seen this happen before?
> 
> To reword the part of our question about constellation plots a little,
> does anyone know when the constellation block would output just four
> single points? 
> 
> The problem we’re currently facing is that the constellation plot does
> not even really show up -/there’s not even a giant blob to indicate
> noise/. Instead, we get only 4 points, one in each of the four locations
> you’d expect for a QPSK signal - but only those 4 points./It almost
> feels like the constellation plot stops triggering after these first
> four points/, and that’s why we don’t receive anymore data. *We’re using
> a free trigger on the positive slope, centered at 0, *which I feel
> should trigger at least something even if it’s just noise.  We have also
> tried other trigger methods, which output either 4 points, 5 points (1
> additional point in the center), or just 1 center point.
> 
> 
> ​
> ​
> ​
> 
> On Mon, Apr 18, 2016 at 5:01 PM, Jingyi Sun <sunjing...@gmail.com
> <mailto:sunjing...@gmail.com>> wrote:
> 
> We are not compensating for any lost packets, although we would be
> aware of them thanks to the packet number. Could you tell us if
> there’s a block to do this, or would we need a custom block? 
> 
> 
> Also, could you tell us why the constellation diagram is not
> displaying properly?
> 
> 
> Thanks,
> 
> Jenny
> 
> 
> 
> On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun
> <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
> 
> Are you comparing the correct packets? E.g., if packets get
> lost, do you
> take that into account?
> 
> M
> 
> On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > Hi everyone,
> >
> > We are working on an experiment for a conference paper deadline in 
> two
> > weeks, and need to transmit and receive OFDM packets and want to 
> study
> > the constellation diagram and BER.
> >
> > I put together a flow graph consisting of an *OFDM transmitter
> block*
> > and an *unpacked OFDM receiver* based on the online example
> rx_ofdm.grc.
> > Here's how I'm trying to measure constellation diagram and BER:
> >
> >   * I inserted a QT constellation sink right before the
> constellation
> > decoder on the payload IQ stream, but it does not seem to output
> >     anything meaningful. The plot just shows single, clean points, 
> which
> > I am pretty sure does not correspond to real data. I suspect 
> that
> > the plots are not triggering properly, but am not sure.
> >
> >   * For BER, we tried several different configurations, and
> they mostly
> > give BER = 0.5 (i.e. random).  Our leading theory is that we're 
> not
> > comparing the data at the correct points in the flow graph. Any
> > suggestions as to what the BER inputs should be would be 
> helpful.
> >
> > We've been running some diagnostics that seem to eliminate our
> > communication channel as the problem:
> >
> >   * We are transmitting the data over-the-air at 915 MHz using
> > two omnidirectional antennas, placed roughly 1 meter apart. The
> > output spectra at the transmitter output and receiver input are
> > attached - all signals are comfortably above the noise floor.
> >   * From the tag debug output, we see that the OFDM packet
> headers are
> > being received. For example, we can see when the packets are
> > received, the packet numbers, as well as the channel estimation 
> tap
> > values. We take this to mean that we are receiving data
> > successfully, and that our difficulties regarding BER and
> > constellation diagram are something we're executing incorrectly 
> in
> > the software.
> >
> >
> > The relevant annotated GRC block diagrams are attached.
> >
> > Thanks so much,
> > Jenny
> >
> >
>

Re: [Discuss-gnuradio] BER & constellation plot for OFDM transmit/receive

[Jingyi Sun]

We are not compensating for any lost packets, although we would be aware of
them thanks to the packet number. Could you tell us if there’s a block to
do this, or would we need a custom block?


Also, could you tell us why the constellation diagram is not displaying
properly?


Thanks,

Jenny



On Mon, Apr 18, 2016 at 1:26 PM, Martin Braun <martin.br...@ettus.com>
wrote:

> Are you comparing the correct packets? E.g., if packets get lost, do you
> take that into account?
>
> M
>
> On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> > Hi everyone,
> >
> > We are working on an experiment for a conference paper deadline in two
> > weeks, and need to transmit and receive OFDM packets and want to study
> > the constellation diagram and BER.
> >
> > I put together a flow graph consisting of an *OFDM transmitter block*
> > and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc.
> > Here's how I'm trying to measure constellation diagram and BER:
> >
> >   * I inserted a QT constellation sink right before the constellation
> > decoder on the payload IQ stream, but it does not seem to output
> > anything meaningful. The plot just shows single, clean points, which
> > I am pretty sure does not correspond to real data. I suspect that
> > the plots are not triggering properly, but am not sure.
> >
> >   * For BER, we tried several different configurations, and they mostly
> > give BER = 0.5 (i.e. random).  Our leading theory is that we're not
> > comparing the data at the correct points in the flow graph. Any
> > suggestions as to what the BER inputs should be would be helpful.
> >
> > We've been running some diagnostics that seem to eliminate our
> > communication channel as the problem:
> >
> >   * We are transmitting the data over-the-air at 915 MHz using
> > two omnidirectional antennas, placed roughly 1 meter apart. The
> > output spectra at the transmitter output and receiver input are
> > attached - all signals are comfortably above the noise floor.
> >   * From the tag debug output, we see that the OFDM packet headers are
> > being received. For example, we can see when the packets are
> > received, the packet numbers, as well as the channel estimation tap
> > values. We take this to mean that we are receiving data
> > successfully, and that our difficulties regarding BER and
> > constellation diagram are something we're executing incorrectly in
> > the software.
> >
> >
> > The relevant annotated GRC block diagrams are attached.
> >
> > Thanks so much,
> > Jenny
> >
> >
> > ___
> > 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] BER & constellation plot for OFDM transmit/receive

[Martin Braun]

Are you comparing the correct packets? E.g., if packets get lost, do you
take that into account?

M

On 04/16/2016 02:38 PM, Jingyi Sun wrote:
> Hi everyone,
> 
> We are working on an experiment for a conference paper deadline in two
> weeks, and need to transmit and receive OFDM packets and want to study
> the constellation diagram and BER. 
> 
> I put together a flow graph consisting of an *OFDM transmitter block*
> and an *unpacked OFDM receiver* based on the online example rx_ofdm.grc.
> Here's how I'm trying to measure constellation diagram and BER:
> 
>   * I inserted a QT constellation sink right before the constellation
> decoder on the payload IQ stream, but it does not seem to output
> anything meaningful. The plot just shows single, clean points, which
> I am pretty sure does not correspond to real data. I suspect that
> the plots are not triggering properly, but am not sure. 
> 
>   * For BER, we tried several different configurations, and they mostly
> give BER = 0.5 (i.e. random).  Our leading theory is that we're not
> comparing the data at the correct points in the flow graph. Any
> suggestions as to what the BER inputs should be would be helpful.
> 
> We've been running some diagnostics that seem to eliminate our
> communication channel as the problem:
> 
>   * We are transmitting the data over-the-air at 915 MHz using
> two omnidirectional antennas, placed roughly 1 meter apart. The
> output spectra at the transmitter output and receiver input are
> attached - all signals are comfortably above the noise floor. 
>   * From the tag debug output, we see that the OFDM packet headers are
> being received. For example, we can see when the packets are
> received, the packet numbers, as well as the channel estimation tap
> values. We take this to mean that we are receiving data
> successfully, and that our difficulties regarding BER and
> constellation diagram are something we're executing incorrectly in
> the software. 
> 
> 
> The relevant annotated GRC block diagrams are attached.
> 
> Thanks so much,
> Jenny
> 
> 
> ___
> 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] EVM, BER, CFO plots in OFDM system

[nahla ali]

 Dears
Hope you are all doing well,

I have a project on ofdm using usrp in gnuradio-companion,
Is there a tool to plot , Bit Error Rate, Error Vector Magnitude and
Carrier Frequency Offset, if not what are the other alternatives
regards

Nahla
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] EVM, BER, CFO plots in OFDM system

[Marcus Müller]

Hi Nahla,

have you looked around in the GNU Radio companion? There's a lot of
tools there, and if you know what these measurements mean, it's pretty
easy to implement the missing ones.

Best regards,
Marcus

On 11/03/2015 04:22 PM, nahla ali wrote:
>
>  Dears
> Hope you are all doing well,
>
> I have a project on ofdm using usrp in gnuradio-companion,
> Is there a tool to plot , Bit Error Rate, Error Vector Magnitude and
> Carrier Frequency Offset, if not what are the other alternatives
> regards
>
> Nahla
>  
>
>
> ___
> 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] BER calculation using digital_bert_tx.py and digital_bert_rx.py

[Hitesh Kasera]

Hi..

I found the mistake which i was doing in digital_bert_tx.py file.
i was always transmitting 1 but after scrambling when we do packing then
according to this statement
self._pack = blocks.unpacked_to_packed_bb(self._mod.bits_per_symbol(),
gr.GR_MSB_FIRST) in qpsk modulation in place of 1 it will take 2 bits 0 and
1 so in receiver there will be two bits in place of only 1 thats why the
error is >10%.
i tried to correct it by replacing self._mod.bits_per_symbol() to a
constant 1 both in qpsk and bpsk and calculated BER for both. For bpsk i
used bit rate 250kbits/second and for qpsk i used 500kbits/second. By
setting these data rates i am getting same SNR for Both but not same BER.
Do i need to change any other parameter for qpsk? if any one has any idea
about it please tell me.

Best Regards,
Hitesh


On Tue, Oct 13, 2015 at 12:13 AM, Hitesh Kasera <hiteshkase...@gmail.com>
wrote:

> Hi everyone,
> I am trying to calculate BER for bpsk and qpsk using digital_bert_tx.py
> and digital_bert_rx.py. i want to compare BER of qpsk and bpsk. At same SNR
> around 20db i am getting constant .16 BER for qpsk and for bpsk it is
> 1e-12. when i change the SNR using gain of Transmitter and Receiving end
> there is no change in BER for qpsk, for bpsk its changes. I am not able to
> understand why with qpsk its not working. if anyone has any idea or anyone
> who has calculated BER previously please help me.
>
> Best Regards,
> Hitesh
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] BER calculation using digital_bert_tx.py and digital_bert_rx.py

[Hitesh Kasera]

Hi everyone,
I am trying to calculate BER for bpsk and qpsk using digital_bert_tx.py and
digital_bert_rx.py. i want to compare BER of qpsk and bpsk. At same SNR
around 20db i am getting constant .16 BER for qpsk and for bpsk it is
1e-12. when i change the SNR using gain of Transmitter and Receiving end
there is no change in BER for qpsk, for bpsk its changes. I am not able to
understand why with qpsk its not working. if anyone has any idea or anyone
who has calculated BER previously please help me.

Best Regards,
Hitesh
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[Marcus Müller]

Hi Antonio,

I think this is a revival of an older thread.

I still can't execute your flow graph, because it seems to be built with
an old version of GNU Radio (probably 3.6.X?).
Using that really doesn't make sense for OFDM experimentation, because
the new, much cooler and better-working OFDM blocks are not available there.
I *strongly* recommend updating your GNU Radio installation.

Also, I think all information you gave in this mail was already there in
previous mails of you. Don't write such emails; people will start
considering you as spammer if you don't include what you've tried since
the last time you've got responses to your mails. Always try to
represent the latest state. For example, I already told you that your
GNU Radio is too old and we can't work with your flow graphs. You did
not even react to that...

Best regards,
Marcus

On 09.09.2015 20:28, ANTONIO TAMAYO wrote:
> Hello,
>
>  I'm doing my College final project about gnuradio companion. I have
> to calculate the BER with OFDM using different modulations to the
> subcarriers. After that, I have to do a graphic with the BER numbers.
> The configuration I use is in the images attached.
> Specifically, I have to send an image and after that I have to
> calculate the BER. Also, I need to send an random vector and calculate
> the BER in the same way as with the image. The image that I send in
> the example is called "imagen" and it's attached in this email.
>
> When I'm using GRC to calculate BER I always have the same problem.
> First I try to simulate without introducing any noise and get a BER
> data. Then I try to introduce AWGN noise and the BER data is the same.
> Clearly I'm making a mistake, but I'm not able to identify what it is.
> In view of the configuration used, someone could tell me which are my
> mistakes?
>
>
> Also, I would like to know how to configure the block Channel Model
> correctly.
>
> Thank you all.
>
>
> ___
> 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] How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello,

 I'm doing my College final project about gnuradio companion. I have to
calculate the BER with OFDM using different modulations to the subcarriers.
After that, I have to do a graphic with the BER numbers. The configuration
I use is in the images attached.
Specifically, I have to send an image and after that I have to calculate
the BER. Also, I need to send an random vector and calculate the BER in the
same way as with the image. The image that I send in the example is called
"imagen" and it's attached in this email.

When I'm using GRC to calculate BER I always have the same problem. First I
try to simulate without introducing any noise and get a BER data. Then I
try to introduce AWGN noise and the BER data is the same. Clearly I'm
making a mistake, but I'm not able to identify what it is. In view of the
configuration used, someone could tell me which are my mistakes?


Also, I would like to know how to configure the block Channel Model
correctly.

Thank you all.


Sistema_OFDM_Pruebas.grc
Description: Binary data


Sistema_OFDM_Pruebas1.grc
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello Jawad,

Today I send the same message that I sent a few days ago because I realized
I did not include GRC code files. Those files are necessary to detect
errors.

I've made the changes you said. As you say, when I assign the Payload
parameter to the number of samples of the block Random Source without
introducing Delay, I get a BER value equal to 0. But what I need to
introduce a noise source so that when I increase the power noise, also
increase the BER. This doesn't happen making the changes that you say, when
I introduce a noise source and the noise power is increasing the value of
BER remains 0. This is incorrect. As you can see in the spectrum received,
the signal contains errors that they aren't appreciated by the block Error
Rate. (SistemasOFDM_prueba.grc)
Also, I need to send an image and calculate the BER in the same way as with
the random vector. When I use the block File Source and calculate the BER,
I have the same problem, the BER remains constant at 0.51 and although the
noise power increases, the BER remains unchanged. (SistemaOFDM_Pruebas1.grc)
The image that I send in the previos example is called "imagen"
Thank you.

Regards,
Antonio


Date: Tue, 1 Sep 2015 15:04:26 +0200
From: Jawad Seddar <jawad.sed...@gmail.com>
To: gnuradio mailing list <discuss-gnuradio@gnu.org>
Cc: ANTONIO TAMAYO <atamayo2...@gmail.com>
Subject: Re: [Discuss-gnuradio] How to calculate BER in different
modulations with OFDM using GNURadio Companion
Message-ID:
<cae9wgf_jenf_bobnrsq4i9z2ppgyy63du6wchs+jc6bdbsx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hello Antonio,

Please take the habit of replying to the list. People might get into the
same problems or someone might have some knowledge to share.

Also, try to provide a flowgraph (.grc file) to make testing easier for the
people helping you out.

That said, I did some testing and it looks like I was wrong. The delay
isn't the problem here (at least not on my machine).
But I think I figured out the problem. It looks like you provided a Payload
length of 0 in your OFDM modulator block.
If I set the payload length to 100 and then the random source Num. samples
to the same value, the BER goes to 0 without adding delay. And you can see
the BER moving when you change the delay.

There is one problem though, it doesn't seem to work when the payload
length and the Num. samples are not set to the same value.


Regards,
Jawad

2015-09-01 13:50 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:

> Hello Jawad,
>
> I have tried to use the delay block but I keep having the same problem. I
> have attached an image of how I used the block. I also attached an image
of
> the value of BER obtained, whenever I make changes to the delay block I
get
> the value of 0.1251. So the problem is not resolved. Also, I tried change
> the paremeter simbol per bit in the Error Rate block, but the problem
> persists. What is the optimal value for this parameter? Regarding the use
> of the throttle block I tried to run this diagram without him and the
value
> BER is the same.
> Thank you for answering my emails, your answers are very useful.
> I've included our previous emails in the end of this email. Thank you.
>
> Regards,
> Antonio
>
>
>
> 
---
> > Hello,
> >
> > I'm doing my College final project about gnuradio companion.
Specifically
> > I have to calculate the BER with OFDM using different modulations to the
> > subcarriers. After that, I have to do a graphic with the BER numbers.
The
> > configuration I use is in the image attached.
> > When I'm using GRC to calculate BER I always have the same problem.
First
> > I try to simulate without introducing any noise and get a BER data. Then
> I
> > try to introduce AWGN noise and the BER data is the same. Clearly I'm
> > making a mistake, but I'm not able to identify what it is. In view of
the
> > configuration used, someone could tell me which are my mistakes?
> > Also, I would like to know how to configure the block Channel Model
> > correctly.
> >
> > Thank you all.
> >
>
> Date: Mon, 31 Aug 2015 14:41:10 +0200
> From: Jawad Seddar <jawad.sed...@gmail.com>
> To: gnuradio mailing list <discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] How to calculate BER in different
> modulations with OFDM using GNURadio Companion
> Message-ID:
> <
> cae9wgf80dwtktgo0tuq4p4nreihpnprxjdcvh7g5feusmds...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antonio,
>
> The problem might be due to delay introduced by the processing blocks.
> Your OFDM modulator and demodulator don't work insta

[Discuss-gnuradio] Fwd: How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello Jawad,

I've made the changes you said. As you say, when I assign the Payload
parameter to the number of samples of the block Random Source without
introducing Delay, I get a BER value equal to 0. But what I need to
introduce a noise source so that when I increase the power noise, also
increase the BER. This doesn't happen making the changes that you say, when
I introduce a noise source and the noise power is increasing the value of
BER remains 0. This is incorrect. As you can see in the spectrum received,
the signal contains errors that they aren't appreciated by the block Error
Rate. (SistemasOFDM_prueba.grc)
Also, I need to send an image and calculate the BER in the same way as with
the random vector. When I use the block File Source and calculate the BER,
I have the same problem, the BER remains constant at 0.51 and although the
noise power increases, the BER remains unchanged. (SistemaOFDM_Pruebas1.grc)
The image that I send in the previos example is called "imagen"
Thank you.

Regards,
Antonio

2015-09-01 15:04 GMT+02:00 Jawad Seddar <jawad.sed...@gmail.com>:

> Hello Antonio,
>
> Please take the habit of replying to the list. People might get into the
> same problems or someone might have some knowledge to share.
>
> Also, try to provide a flowgraph (.grc file) to make testing easier for
> the people helping you out.
>
> That said, I did some testing and it looks like I was wrong. The delay
> isn't the problem here (at least not on my machine).
> But I think I figured out the problem. It looks like you provided a
> Payload length of 0 in your OFDM modulator block.
> If I set the payload length to 100 and then the random source Num. samples
> to the same value, the BER goes to 0 without adding delay. And you can see
> the BER moving when you change the delay.
>
> There is one problem though, it doesn't seem to work when the payload
> length and the Num. samples are not set to the same value.
>
>
> Regards,
> Jawad
>
>
> 2015-09-01 13:50 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:
>
>> Hello Jawad,
>>
>> I have tried to use the delay block but I keep having the same problem. I
>> have attached an image of how I used the block. I also attached an image of
>> the value of BER obtained, whenever I make changes to the delay block I get
>> the value of 0.1251. So the problem is not resolved. Also, I tried change
>> the paremeter simbol per bit in the Error Rate block, but the problem
>> persists. What is the optimal value for this parameter? Regarding the use
>> of the throttle block I tried to run this diagram without him and the value
>> BER is the same.
>> Thank you for answering my emails, your answers are very useful.
>> I've included our previous emails in the end of this email. Thank you.
>>
>> Regards,
>> Antonio
>>
>>
>>
>> -------
>> > Hello,
>> >
>> > I'm doing my College final project about gnuradio companion.
>> Specifically
>> > I have to calculate the BER with OFDM using different modulations to the
>> > subcarriers. After that, I have to do a graphic with the BER numbers.
>> The
>> > configuration I use is in the image attached.
>> > When I'm using GRC to calculate BER I always have the same problem.
>> First
>> > I try to simulate without introducing any noise and get a BER data.
>> Then I
>> > try to introduce AWGN noise and the BER data is the same. Clearly I'm
>> > making a mistake, but I'm not able to identify what it is. In view of
>> the
>> > configuration used, someone could tell me which are my mistakes?
>> > Also, I would like to know how to configure the block Channel Model
>> > correctly.
>> >
>> > Thank you all.
>> >
>>
>> Date: Mon, 31 Aug 2015 14:41:10 +0200
>> From: Jawad Seddar <jawad.sed...@gmail.com>
>> To: gnuradio mailing list <discuss-gnuradio@gnu.org>
>> Subject: Re: [Discuss-gnuradio] How to calculate BER in different
>> modulations with OFDM using GNURadio Companion
>> Message-ID:
>> <
>> cae9wgf80dwtktgo0tuq4p4nreihpnprxjdcvh7g5feusmds...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Antonio,
>>
>> The problem might be due to delay introduced by the processing blocks.
>> Your OFDM modulator and demodulator don't work instantaneously, they take
>> some time to do their processing and forward their outputs to the next
>> block in line. Therefore, there is a de

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello Jawad,

I've made the changes you said. As you say, when I assign the Payload
parameter to the number of samples of the block Random Source without
introducing Delay, I get a BER value equal to 0. But what I need to
introduce a noise source so that when I increase the power noise, also
increase the BER. This doesn't happen making the changes that you say, when
I introduce a noise source and the noise power is increasing the value of
BER remains 0. This is incorrect. As you can see in the spectrum received,
the signal contains errors that they aren't appreciated by the block Error
Rate. (SistemasOFDM_prueba.grc)
Also, I need to send an image and calculate the BER in the same way as with
the random vector. When I use the block File Source and calculate the BER,
I have the same problem, the BER remains constant at 0.51 and although the
noise power increases, the BER remains unchanged. (SistemaOFDM_Pruebas1.grc)
The image that I send in the previos example is called "imagen"
Thank you.

Regards,
Antonio

2015-09-01 15:04 GMT+02:00 Jawad Seddar <jawad.sed...@gmail.com>:

> Hello Antonio,
>
> Please take the habit of replying to the list. People might get into the
> same problems or someone might have some knowledge to share.
>
> Also, try to provide a flowgraph (.grc file) to make testing easier for
> the people helping you out.
>
> That said, I did some testing and it looks like I was wrong. The delay
> isn't the problem here (at least not on my machine).
> But I think I figured out the problem. It looks like you provided a
> Payload length of 0 in your OFDM modulator block.
> If I set the payload length to 100 and then the random source Num. samples
> to the same value, the BER goes to 0 without adding delay. And you can see
> the BER moving when you change the delay.
>
> There is one problem though, it doesn't seem to work when the payload
> length and the Num. samples are not set to the same value.
>
>
> Regards,
> Jawad
>
>
> 2015-09-01 13:50 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:
>
>> Hello Jawad,
>>
>> I have tried to use the delay block but I keep having the same problem. I
>> have attached an image of how I used the block. I also attached an image of
>> the value of BER obtained, whenever I make changes to the delay block I get
>> the value of 0.1251. So the problem is not resolved. Also, I tried change
>> the paremeter simbol per bit in the Error Rate block, but the problem
>> persists. What is the optimal value for this parameter? Regarding the use
>> of the throttle block I tried to run this diagram without him and the value
>> BER is the same.
>> Thank you for answering my emails, your answers are very useful.
>> I've included our previous emails in the end of this email. Thank you.
>>
>> Regards,
>> Antonio
>>
>>
>>
>> -------
>> > Hello,
>> >
>> > I'm doing my College final project about gnuradio companion.
>> Specifically
>> > I have to calculate the BER with OFDM using different modulations to the
>> > subcarriers. After that, I have to do a graphic with the BER numbers.
>> The
>> > configuration I use is in the image attached.
>> > When I'm using GRC to calculate BER I always have the same problem.
>> First
>> > I try to simulate without introducing any noise and get a BER data.
>> Then I
>> > try to introduce AWGN noise and the BER data is the same. Clearly I'm
>> > making a mistake, but I'm not able to identify what it is. In view of
>> the
>> > configuration used, someone could tell me which are my mistakes?
>> > Also, I would like to know how to configure the block Channel Model
>> > correctly.
>> >
>> > Thank you all.
>> >
>>
>> Date: Mon, 31 Aug 2015 14:41:10 +0200
>> From: Jawad Seddar <jawad.sed...@gmail.com>
>> To: gnuradio mailing list <discuss-gnuradio@gnu.org>
>> Subject: Re: [Discuss-gnuradio] How to calculate BER in different
>> modulations with OFDM using GNURadio Companion
>> Message-ID:
>> <
>> cae9wgf80dwtktgo0tuq4p4nreihpnprxjdcvh7g5feusmds...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi Antonio,
>>
>> The problem might be due to delay introduced by the processing blocks.
>> Your OFDM modulator and demodulator don't work instantaneously, they take
>> some time to do their processing and forward their outputs to the next
>> block in line. Therefore, there is a de

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[Marcus Müller]

Hi Antonio,
I tried to open your GRC file. This must have been with a pretty old
version of GNU Radio (which version are you using?).
I strongly recommend getting a newer version of GNU Radio, because
especially the OFDM code has improved a lot.

By the way, a BER of about ~0.5 means that as many bits are right as
there are wrong bits, which means that you get absolutely no information
through (if there were more wrong than right bits, you could just toggle
the bits and get more information); this means that the input and output
streams are not related, or have an offset relative to each other that
doesn't get corrected; increase the BER window size (you don't need the
delay if you've got a bigger window).

Best regards,
Marcus


On 01.09.2015 19:12, ANTONIO TAMAYO wrote:
> Hello Jawad,
>
> I've made the changes you said. As you say, when I assign the Payload
> parameter to the number of samples of the block Random Source without
> introducing Delay, I get a BER value equal to 0. But what I need to
> introduce a noise source so that when I increase the power noise, also
> increase the BER. This doesn't happen making the changes that you say,
> when I introduce a noise source and the noise power is increasing the
> value of BER remains 0. This is incorrect. As you can see in the
> spectrum received, the signal contains errors that they aren't
> appreciated by the block Error Rate. (SistemasOFDM_prueba.grc)
> Also, I need to send an image and calculate the BER in the same way as
> with the random vector. When I use the block File Source and calculate
> the BER, I have the same problem, the BER remains constant at 0.51 and
> although the noise power increases, the BER remains unchanged.
> (SistemaOFDM_Pruebas1.grc)
> The image that I send in the previos example is called "imagen"
> Thank you.
>
> Regards,
> Antonio
>
> 2015-09-01 15:04 GMT+02:00 Jawad Seddar <jawad.sed...@gmail.com
> <mailto:jawad.sed...@gmail.com>>:
>
> Hello Antonio,
>
> Please take the habit of replying to the list. People might get
> into the same problems or someone might have some knowledge to share.
>
> Also, try to provide a flowgraph (.grc file) to make testing
> easier for the people helping you out.
>
> That said, I did some testing and it looks like I was wrong. The
> delay isn't the problem here (at least not on my machine).
> But I think I figured out the problem. It looks like you provided
> a Payload length of 0 in your OFDM modulator block.
> If I set the payload length to 100 and then the random source Num.
> samples to the same value, the BER goes to 0 without adding delay.
> And you can see the BER moving when you change the delay.
>
> There is one problem though, it doesn't seem to work when the
> payload length and the Num. samples are not set to the same value.
>
>
> Regards,
> Jawad
>
>
> 2015-09-01 13:50 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com
> <mailto:atamayo2...@gmail.com>>:
>
> Hello Jawad,
>
> I have tried to use the delay block but I keep having the same
> problem. I have attached an image of how I used the block. I
> also attached an image of the value of BER obtained, whenever
> I make changes to the delay block I get the value of 0.1251.
> So the problem is not resolved. Also, I tried change the
> paremeter simbol per bit in the Error Rate block, but the
> problem persists. What is the optimal value for this
> parameter? Regarding the use of the throttle block I tried to
> run this diagram without him and the value BER is the same.
> Thank you for answering my emails, your answers are very useful.
> I've included our previous emails in the end of this email.
> Thank you.
>
> Regards,
> Antonio
>
>
> 
> -------
> > Hello,
> >
> > I'm doing my College final project about gnuradio companion.
> Specifically
> > I have to calculate the BER with OFDM using different
> modulations to the
> > subcarriers. After that, I have to do a graphic with the BER
> numbers. The
>         > configuration I use is in the image attached.
> > When I'm using GRC to calculate BER I always have the same
> problem. First
> > I try to simulate without introducing any noise and get a
> BER data. Then I
> > try to introduce AWGN noise and the BER data is the same.
> Clearly I'

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[Jawad Seddar]

Hello Antonio,

Please take the habit of replying to the list. People might get into the
same problems or someone might have some knowledge to share.

Also, try to provide a flowgraph (.grc file) to make testing easier for the
people helping you out.

That said, I did some testing and it looks like I was wrong. The delay
isn't the problem here (at least not on my machine).
But I think I figured out the problem. It looks like you provided a Payload
length of 0 in your OFDM modulator block.
If I set the payload length to 100 and then the random source Num. samples
to the same value, the BER goes to 0 without adding delay. And you can see
the BER moving when you change the delay.

There is one problem though, it doesn't seem to work when the payload
length and the Num. samples are not set to the same value.


Regards,
Jawad

2015-09-01 13:50 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:

> Hello Jawad,
>
> I have tried to use the delay block but I keep having the same problem. I
> have attached an image of how I used the block. I also attached an image of
> the value of BER obtained, whenever I make changes to the delay block I get
> the value of 0.1251. So the problem is not resolved. Also, I tried change
> the paremeter simbol per bit in the Error Rate block, but the problem
> persists. What is the optimal value for this parameter? Regarding the use
> of the throttle block I tried to run this diagram without him and the value
> BER is the same.
> Thank you for answering my emails, your answers are very useful.
> I've included our previous emails in the end of this email. Thank you.
>
> Regards,
> Antonio
>
>
>
> ---
> > Hello,
> >
> > I'm doing my College final project about gnuradio companion. Specifically
> > I have to calculate the BER with OFDM using different modulations to the
> > subcarriers. After that, I have to do a graphic with the BER numbers. The
> > configuration I use is in the image attached.
> > When I'm using GRC to calculate BER I always have the same problem. First
> > I try to simulate without introducing any noise and get a BER data. Then
> I
> > try to introduce AWGN noise and the BER data is the same. Clearly I'm
> > making a mistake, but I'm not able to identify what it is. In view of the
> > configuration used, someone could tell me which are my mistakes?
> > Also, I would like to know how to configure the block Channel Model
> > correctly.
> >
> > Thank you all.
> >
>
> Date: Mon, 31 Aug 2015 14:41:10 +0200
> From: Jawad Seddar <jawad.sed...@gmail.com>
> To: gnuradio mailing list <discuss-gnuradio@gnu.org>
> Subject: Re: [Discuss-gnuradio] How to calculate BER in different
> modulations with OFDM using GNURadio Companion
> Message-ID:
> <
> cae9wgf80dwtktgo0tuq4p4nreihpnprxjdcvh7g5feusmds...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Antonio,
>
> The problem might be due to delay introduced by the processing blocks.
> Your OFDM modulator and demodulator don't work instantaneously, they take
> some time to do their processing and forward their outputs to the next
> block in line. Therefore, there is a delay between the output of the OFDM
> demod block and the original signal.
> What you need to do is add a delay block between your Random source and the
> BER block and set the delay properly.
> When you're not adding any noise, your BER should be 0. So you can try to
> find the delay value this way.
> Then add noise and see how your BER evolves.
>
> I hope this helps.
>
> Regards,
> Jawad
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[ANTONIO TAMAYO]

Hello,

 I'm doing my College final project about gnuradio companion. Specifically
I have to calculate the BER with OFDM using different modulations to the
subcarriers. After that, I have to do a graphic with the BER numbers. The
configuration I use is in the image attached.
When I'm using GRC to calculate BER I always have the same problem. First I
try to simulate without introducing any noise and get a BER data. Then I
try to introduce AWGN noise and the BER data is the same. Clearly I'm
making a mistake, but I'm not able to identify what it is. In view of the
configuration used, someone could tell me which are my mistakes?
Also, I would like to know how to configure the block Channel Model
correctly.

Thank you all.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to calculate BER in different modulations with OFDM using GNURadio Companion

[Jawad Seddar]

Hi Antonio,

The problem might be due to delay introduced by the processing blocks.
Your OFDM modulator and demodulator don't work instantaneously, they take
some time to do their processing and forward their outputs to the next
block in line. Therefore, there is a delay between the output of the OFDM
demod block and the original signal.
What you need to do is add a delay block between your Random source and the
BER block and set the delay properly.
When you're not adding any noise, your BER should be 0. So you can try to
find the delay value this way.
Then add noise and see how your BER evolves.

I hope this helps.

Regards,
Jawad


2015-08-31 13:21 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:

> The configuration to which I refer in the previous email is the
> corresponding to the image attached
>
> 2015-08-31 13:18 GMT+02:00 ANTONIO TAMAYO <atamayo2...@gmail.com>:
>
>> Hello,
>>
>>  I'm doing my College final project about gnuradio companion.
>> Specifically I have to calculate the BER with OFDM using different
>> modulations to the subcarriers. After that, I have to do a graphic with the
>> BER numbers. The configuration I use is in the image attached.
>> When I'm using GRC to calculate BER I always have the same problem. First
>> I try to simulate without introducing any noise and get a BER data. Then I
>> try to introduce AWGN noise and the BER data is the same. Clearly I'm
>> making a mistake, but I'm not able to identify what it is. In view of the
>> configuration used, someone could tell me which are my mistakes?
>> Also, I would like to know how to configure the block Channel Model
>> correctly.
>>
>> Thank you all.
>>
>
>
> ___
> 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] QT Blocks causing BER errors?

[Tom Rondeau]

On Thu, Jul 23, 2015 at 10:54 AM, Nick Foster bistrom...@gmail.com wrote:

 My guess, educated only in that I've seen it happen before, is that one of
 the blocks in your flowgraph exhibits behavior which is dependent on the
 number of samples per work call. Loading the machine down with GUI blocks
 will change the number of samples GR doles out during each work call.

 Timing synchronizers would be the first place I'd look.

 --n



Hey guys,

I just replied to bob wole on another thread with a bug that I think is
related to this issue, too. To quote myself:

The problem isn't with the GUI sinks; you can replace them with null sinks
and you get the same problem. It's a race condition in our tag pruning
method that was changed in 3.7.6. We have a patch that we're putting in now
that will be part of 3.7.8.

The patch goes backwards a bit to how tag pruning was originally done.
However, with the map, we no longer have to restart the iterator at begin()
like we used to, and we can terminate early, so this should still be much
faster than the original.

Hope this solves others' problems as well!

Tom






On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller marcus.muel...@ettus.com
 wrote:

 Hi Rich,

 being really surprised:
 I think it would be nice if we knew a bit more about the signal
 processing part of your flow graph.
 What does it rely on? Pure Sample Streams? Stream Tags? Message Passing?
 Old-Style Message queues?

 Best regards,
 Marcus


 On 22.07.2015 20:11, Richard Bell wrote:

 I've come across a really unexpected correlation this morning that I'm
 hoping someone has an explanation for. I have a large flow graph with many
 QT GUI blocks because I'm debugging a design. Mostly Time Sinks and
 Constellations plots with a couple of Frequency Sinks thrown in. The number
 of points in some of the time sinks is rather large, on the order of 30k,
 which allows me to see several packets of data at once.

 What I noticed this morning, while debugging a BPSK loopback BER tester,
 is by disabling a number of Constellation plots which were fed by RRC
 filters to make the plot pretty, errors went away. The system works as you
 would expect a simulation with no noise or channel effects to work,
 perfectly. When I enable those GUI blocks, the system looses packet
 synchronization within the first minute consistently. Nothing is changed in
 the data stream between these tests.

 So the question is, is there a known cap on GUI plots? Like I said, I
 have a lot of them and some of them are plotting a large number of points.
 Could this be causing buffers overruns into data spaces or something scary
 like that?

 Another thought I had, could there be an identity problem in which GNU
 Radio at some point can't uniquely identify blocks with the same name apart
 from each other and thus chooses one in some default manner? I'm imagining
 a plotting stream getting crossed with a data stream in some way.

 The bottom line is all I need to do to make this system work is disable
 some plotting only related blocks. Is there a known plotting cap issue that
 I should be aware of?

 Thanks,
 Rich


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Blocks causing BER errors?

[Tom Rondeau]

On Wed, Jul 22, 2015 at 2:11 PM, Richard Bell richard.be...@gmail.com
wrote:

 I've come across a really unexpected correlation this morning that I'm
 hoping someone has an explanation for. I have a large flow graph with many
 QT GUI blocks because I'm debugging a design. Mostly Time Sinks and
 Constellations plots with a couple of Frequency Sinks thrown in. The number
 of points in some of the time sinks is rather large, on the order of 30k,
 which allows me to see several packets of data at once.

 What I noticed this morning, while debugging a BPSK loopback BER tester,
 is by disabling a number of Constellation plots which were fed by RRC
 filters to make the plot pretty, errors went away. The system works as you
 would expect a simulation with no noise or channel effects to work,
 perfectly. When I enable those GUI blocks, the system looses packet
 synchronization within the first minute consistently. Nothing is changed in
 the data stream between these tests.

 So the question is, is there a known cap on GUI plots? Like I said, I have
 a lot of them and some of them are plotting a large number of points. Could
 this be causing buffers overruns into data spaces or something scary like
 that?

 Another thought I had, could there be an identity problem in which GNU
 Radio at some point can't uniquely identify blocks with the same name apart
 from each other and thus chooses one in some default manner? I'm imagining
 a plotting stream getting crossed with a data stream in some way.

 The bottom line is all I need to do to make this system work is disable
 some plotting only related blocks. Is there a known plotting cap issue that
 I should be aware of?

 Thanks,
 Rich



Rich,

That is really surprising. As sinks, those blocks shouldn't be affecting
anything in the data stream at all. They might back up the flow of the
system if things are running too hard on your processor, but you said you
were running a loopback test, so there shouldn't be any hardware I/O
causing problems.

I'm not sure what to make of this right now.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] QT Blocks causing BER errors?

[Nick Foster]

My guess, educated only in that I've seen it happen before, is that one of
the blocks in your flowgraph exhibits behavior which is dependent on the
number of samples per work call. Loading the machine down with GUI blocks
will change the number of samples GR doles out during each work call.

Timing synchronizers would be the first place I'd look.

--n

On Thu, Jul 23, 2015 at 7:26 AM Marcus Müller marcus.muel...@ettus.com
wrote:

  Hi Rich,

 being really surprised:
 I think it would be nice if we knew a bit more about the signal processing
 part of your flow graph.
 What does it rely on? Pure Sample Streams? Stream Tags? Message Passing?
 Old-Style Message queues?

 Best regards,
 Marcus


 On 22.07.2015 20:11, Richard Bell wrote:

I've come across a really unexpected correlation this morning that I'm
 hoping someone has an explanation for. I have a large flow graph with many
 QT GUI blocks because I'm debugging a design. Mostly Time Sinks and
 Constellations plots with a couple of Frequency Sinks thrown in. The number
 of points in some of the time sinks is rather large, on the order of 30k,
 which allows me to see several packets of data at once.

  What I noticed this morning, while debugging a BPSK loopback BER tester,
 is by disabling a number of Constellation plots which were fed by RRC
 filters to make the plot pretty, errors went away. The system works as you
 would expect a simulation with no noise or channel effects to work,
 perfectly. When I enable those GUI blocks, the system looses packet
 synchronization within the first minute consistently. Nothing is changed in
 the data stream between these tests.

  So the question is, is there a known cap on GUI plots? Like I said, I
 have a lot of them and some of them are plotting a large number of points.
 Could this be causing buffers overruns into data spaces or something scary
 like that?

  Another thought I had, could there be an identity problem in which GNU
 Radio at some point can't uniquely identify blocks with the same name apart
 from each other and thus chooses one in some default manner? I'm imagining
 a plotting stream getting crossed with a data stream in some way.

  The bottom line is all I need to do to make this system work is disable
 some plotting only related blocks. Is there a known plotting cap issue that
 I should be aware of?

  Thanks,
  Rich


 ___
 Discuss-gnuradio mailing 
 listDiscuss-gnuradio@gnu.orghttps://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] QT Blocks causing BER errors?

[Marcus Müller]

Hi Rich,

being really surprised:
I think it would be nice if we knew a bit more about the signal 
processing part of your flow graph.
What does it rely on? Pure Sample Streams? Stream Tags? Message Passing? 
Old-Style Message queues?


Best regards,
Marcus

On 22.07.2015 20:11, Richard Bell wrote:
I've come across a really unexpected correlation this morning that I'm 
hoping someone has an explanation for. I have a large flow graph with 
many QT GUI blocks because I'm debugging a design. Mostly Time Sinks 
and Constellations plots with a couple of Frequency Sinks thrown in. 
The number of points in some of the time sinks is rather large, on the 
order of 30k, which allows me to see several packets of data at once.


What I noticed this morning, while debugging a BPSK loopback BER 
tester, is by disabling a number of Constellation plots which were fed 
by RRC filters to make the plot pretty, errors went away. The system 
works as you would expect a simulation with no noise or channel 
effects to work, perfectly. When I enable those GUI blocks, the system 
looses packet synchronization within the first minute consistently. 
Nothing is changed in the data stream between these tests.


So the question is, is there a known cap on GUI plots? Like I said, I 
have a lot of them and some of them are plotting a large number of 
points. Could this be causing buffers overruns into data spaces or 
something scary like that?


Another thought I had, could there be an identity problem in which GNU 
Radio at some point can't uniquely identify blocks with the same name 
apart from each other and thus chooses one in some default manner? I'm 
imagining a plotting stream getting crossed with a data stream in some 
way.


The bottom line is all I need to do to make this system work is 
disable some plotting only related blocks. Is there a known plotting 
cap issue that I should be aware of?


Thanks,
Rich


___
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