Re: puncturing pattern used

[U L]

The delay before the decoder might be throwing off the alignment at the
output. Might consider setting to 0 or removing.

Generally If you use a test input vector like the block of 0xff and 0x00 I
mentioned before, you should be able to look at the relative delay between
input and output by putting the source output and decoder output into a
time sink and measuring the delay between the source signal being non 0 and
the decoder output being non 0.

Jared.

On Wed, Aug 23, 2023, 4:58 AM Jiya Johnson  wrote:

> I am getting constant BER through our the SNR ranges
>
>
>
>
> On Tue, Aug 22, 2023, 7:15 PM Jiya Johnson 
> wrote:
>
>> Ok, I will check.
>> I was confused with this stack input (
>> https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio
>> )
>> I will try with 1011 and delay blocks and will update you.
>>
>> On Tue, Aug 22, 2023, 7:12 PM U L  wrote:
>>
>>> The extended en/decoder does puncturing and zero stuffing internally so
>>> you don't need an extra puncturing block. Like I mentioned, the puncturing
>>> string can only have 0s and 1s so 13 is invalid. I'd try '1011' instead.
>>>
>>> Finally I think you still need some delay between your source and the
>>> ber block to align your input bytes with those from your output. The output
>>> does not start with the first decoded bit, but some number of 0s. In one of
>>> your prior flowgraphs you did have a delay. What happened to it?
>>>
>>> Jared.
>>>
>>>
>>> On Tue, Aug 22, 2023, 4:13 AM Jiya Johnson 
>>> wrote:
>>>
>>>> Hi Jared,
>>>>  Completed the flowgraph based on the inputs from you like i have
>>>> taken code rate :2/3 and pattern 1101(0xD)-puncture size-4 as reference
>>>> from (
>>>> https://stackoverflow.com/questions/54946638/punctured-convolutional-codes-in-gnu-radio)
>>>> bt still i am facing the issue.Always i am getting 10^-0.3 BER FROM 0 to 15
>>>> dB.
>>>>
>>>> [image: Screenshot from 2023-08-22 15-41-43.png]
>>>>
>>>>

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

[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

[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

[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

[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

[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: One Tagged Input Stream to Unequal Output Streams

[U L]

Alon,

Considering your sample ranges are contiguous you might be able to get away
with using the stream to streams block or stream demux block. Take a look
if one of those might suffice.

Jared.

On Tue, May 30, 2023, 2:28 PM Alon Simon Levin  wrote:

> Hi all,
>
> I have a tagged stream block that takes in a fixed number of samples and
> outputs a subset onto a single stream. I want to extend this functionality
> to output two subsets of the input stream to two separate outputs, with an
> unequal number on each one.
>
> For example, for an input stream of 5000 samples, I am currently routing
> samples 1000-1999 to the output. I would like to extend this so that I send
> samples 1000-1099 to Output 1 and samples 1100-1999 to Output 2.
>
> Is there an easy way to do this? I've looked through the blocks coding
> guide but am very confused about how noutput_items works in this scenario.
> I would appreciate any help on this matter!
>
> Best,
> Alon
>
> --
> *Alon S. Levin*
> Ph.D. Student
> Wireless & Mobile Networking Lab, Columbia University
> alon.s.le...@columbia.edu | (347) 225-7433
>

Re: Changing a QT GUI Range variable from a custom block

[U L]

It's been awhile since I've used gr so ymmv.

You could do something like the function probe block where you pass a block
Id and function name (say, the callback setter function) to your custom
block and call it when you want.

Jared.

On Sun, Apr 16, 2023, 6:53 AM DİREN ERDEM AYDIN  wrote:

> Guys,
>
> Any idea? sorry for bothering you again..
>
> On Thu, Apr 13, 2023 at 12:03 AM DİREN ERDEM AYDIN 
> wrote:
>
>> Dear all,
>>
>> I want to ask you that is it possible to change a QT GUI Range or Chooser
>> variable from a custom python block?
>>
>> I have inserted the flowgraph below. I can track the GUI variables by
>> giving their IDs to a constant source, which is then connected to the
>> python block. However, I would also like to adjust LO
>> frequency (lo_freq) in the custom block, I can define one more output but
>> have no idea how that output will affect the QT GUI Range variable..
>>
>> Regards,
>> dea
>>
>
> --
> *Yasal Uyarı: MEF ÜNİVERSİTESİ bu mesajın içeriği ile ilgili hiçbir yasal
> sorumluluk taşımaz.*
> *Legal Disclaimer: MEF UNIVERSITY does not accept any legal liability or
> responsibility for the content of this message.*
>

Re: Constellation Modulator delay calculation

[U L]

Ali,

I think the example uses the generic_mod block

inside. This block uses the polyphase arb resampler for antialiasing. The
line that computes the rrc delay is here
.
Briefly, for your example with sps = 2, it's (11 x 2 x 2 - 2) / 2 = 21. For
sps = 4, (11 x 4 x 4 - 4) / 2 = 86. I don't know if this helps.

Jared.

On Tue, Jan 10, 2023 at 6:08 PM Cinaed Simson 
wrote:

> Hi Ali - your flowchart has no device and no throttle. You need to add a
> throttle.
>
> And I don't the expertise or the time to look at the source code.
>
> So I'm punting back to the list.
>
> -- Cinaed
>
>
> On 1/10/23 03:10, Ali G. Dezfuli wrote:
> > Hi everybody,expertise
> >
> > I just want to know how the delay of the "Constellation Modulator"
> > block in GRC is calculated.
> > In fact, whether you set the block's last parameter "truncate filter
> > transient" or not, a delay of 86 samples could be generated, no matter
> > how many points are in the constellation.
> >
> > This magic number (i.e. 86) also appears in
> > "linear_equalizer_compare.grc" example (in
> > gr-digital/examples/equalizers in modulated_sync_word variable).
> >
> > I know this delay depends on the "samples per symbol" (sps) parameter
> > and comes from the built-in pulse shaping with its default taps equal:
> >firdes.root_raised_cosine(32, 32, 1.0, exess_bw, 32*11*sps)
> > and with the following sps to delay relation:
> > (sps=2, delay=21)
> > (sps=4, delay=86)
> > (sps=8, delay=348)
> > etc.
> >
> > my GR version is:   v3.11.0.0git-316-gc11667ef
> > thank you all!
>
>
>

Re: GNU Radio Companion N310 GPIO Sink/Source block

[U L]

Joshua,

Generally Fabien is right. To exercise the full feature set of the GPIO you
would likely need an OOT block. However, if only limited performance and
features are needed then you might get away with using the Python embedded
block or Python snippet in GRC to implement something quick and easy. This
was the route I took to control an external TX/RX switch. I imagine any
low-rate control would be feasible.

Jared.

On Tue, Jun 28, 2022 at 5:06 PM Fabien PELLET  wrote:

> Hi Joshua,
>
> I'm also using GPIO on LFTX and LFRX on a N210 and I can tell you that you
> will not find source or sink that deal with that IO as far as I know.
>
> The only way to use them is to write an OOT that uses the UHD methods.
>
> Best regards,
> Fabien, F4CTZ
>
>  White, Joshua J a écrit 
>
> (Cross-posted on usrp-users and discuss-gnuradio)
> For anyone who's familiar with using the USRP3 (specifically the N310)
> with GNU Radio:
>
> I'm trying to create a flowgraph in gnu radio companion that incorporates
> reading a value from one pin on the front panel GPIO of the N310 and
> writing a value to another pin. I'm looking for a source/sink block for
> GNU Radio companion that can accomplish this. Has anyone done this
> previously, or can anyone point me in the right direction? I have very
> little experience with GNU Radio and have no expertise in programming OOT
> modules. Thank you for any help you can provide.
>
>
>
> Very respectfully,
>
>
>
> *Joshua White *
>
> Precision Timing Systems Engineer
>
> Engineering & Support Solutions Directorate
>
> www.riversideresearch.org
>
> T: 937.986.3153 | F: 937.431.3811
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain proprietary, confidential or
> privileged information or otherwise be protected by law. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please notify the sender and destroy all copies and the
> original message.
>
>
>

Re: GNU Radio Companion N310 GPIO Sink/Source block

[U L]

Joshua,

I have not personally used the N3XX devices, but I did recently
successfully manipulate the GPIO on a N210 w/ LFXX daughtercards.

The relevant UHD manual section for you I think is
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_fpgio (but also see
the X310 section at https://files.ettus.com/manual/page_gpio_api.html which
I think is a much better exposition).

I also would recommend looking at the UHD gpio utility often installed to
/lib/uhd/examples. It's source is
https://github.com/EttusResearch/uhd/blob/master/host/examples/gpio.cpp.
This lets you manipulate some of the gpio directly from a CLI. I believe
most of the relevant UHD C/C++ API functions are available in Python.

Hope this helps,
Jared.

On Tue, Jun 28, 2022 at 2:41 PM White, Joshua J <
jjwh...@riversideresearch.org> wrote:

> (Cross-posted on usrp-users and discuss-gnuradio)
> For anyone who's familiar with using the USRP3 (specifically the N310)
> with GNU Radio:
>
> I'm trying to create a flowgraph in gnu radio companion that incorporates
> reading a value from one pin on the front panel GPIO of the N310 and
> writing a value to another pin. I'm looking for a source/sink block for
> GNU Radio companion that can accomplish this. Has anyone done this
> previously, or can anyone point me in the right direction? I have very
> little experience with GNU Radio and have no expertise in programming OOT
> modules. Thank you for any help you can provide.
>
>
>
> Very respectfully,
>
>
>
> *Joshua White *
>
> Precision Timing Systems Engineer
>
> Engineering & Support Solutions Directorate
>
> www.riversideresearch.org
>
> T: 937.986.3153 | F: 937.431.3811
>
>
>
> This e-mail message, including any attachments, is for the sole use of the
> intended recipient(s) and may contain proprietary, confidential or
> privileged information or otherwise be protected by law. Any unauthorized
> review, use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please notify the sender and destroy all copies and the
> original message.
>
>
>

Re: gnuradio-default with pybombs on opensuse

[U L]

Awesome! I encourage you to submit a MR with your updates. Us suse folks
have to help each other, too few.

Jared.

On Fri, Oct 9, 2020, 9:00 PM aardric  wrote:

> Jared,
>
>How did I miss that (rhetorical)? Thanks!
>
> Additional changes required for installation with opensuse leap 15.1:
>
> In qt5.lwr  rpm: (qt5-qtbase-devel && qt5-qtsvg-devel) || (devel_qt5 &&
> libqt5-qtsvg-devel) || (libqt5-qtbase-devel && libqt5-qtsvg-devel)
>
> In qt6.lwr  rpm: qwt-qt5-devel || qwt-devel >= 6.1 || qwt6-qt5-devel
>
> boost.lwr requires  rpm: libboost_headers1_66_0-devel to accommodate
> opensuse leap 15.1
>
> So far, so good. I can definitely see using PyBOMBS from now on.
>
>
> Rick
>
>
> On 2020-10-08 9:00 p.m., U L wrote:
>
> Rick,
>
> Most gr-recipes are not updated with openSUSE package names. For this
> package it's *python3-pyaml* (single y). If you modify the pyyaml.lwr
> recipe in gr-recipes to read:
>
> rpm: python3-pyyaml || python3-pyaml
>
> I would expect it to work. Caveat: untested.
>
> Jared.
>
> On Thu, Oct 8, 2020 at 2:56 PM aardric  wrote:
>
>> Hail,
>>
>> No urgency because I have been using gnuradio 3.8 built from source
>> and installed on the system. However, I am interested in trying out
>> PyBOMBS. I see some notes on opensuse requiring additional consideration
>> but PyBOMBS installed without a problem, python3-PyYAML and ruamel.yaml are
>> installed on the system. However, an attempt to install with
>> gnuradio-default recipe using:
>>
>> prefix/gr38> pybombs -r (...)/sdr/prefix/.pybombs/recipes/gr-recipes prefix 
>> init (...)/sdr/prefix/gr38 -a gr38  -R gnuradio-default
>>
>>
>> fails with the final messages below.  Is this anything mysterious or just
>> the need for more research on my part?
>>
>> Package 'python3-pyyaml' not found.
>> Install tree:
>> |
>> \- gnuradio
>>|
>>+- libvolk
>>|
>>+- qt5
>>|
>>+- uhd
>>|  |
>>|  \- boost
>>|
>>+- qwt6
>>|  |
>>|  \- qt5
>>|
>>+- boost
>>|
>>\- pyyaml
>> [INFO] Phase 1 complete: All binary dependencies installed.
>> [INFO] Phase 2: Recursively installing source packages to prefix:
>> [INFO] Installing package: pyyaml
>> 00254 kB / 00254 kB (100%)
>> Configuring: (100%) 
>> [=]
>> [WARNING] Configuration failed. Re-trying with higher verbosity.
>> /bin/sh: ./configure: No such file or directory
>> [ERROR] Configuration failed after running at least twice.
>> [ERROR] Problem occurred while building package pyyaml:
>> Configuration failed
>> [ERROR] Error installing package pyyaml. Aborting.
>>
>>
>> Rick
>>
>>
>>

Re: gnuradio-default with pybombs on opensuse

[U L]

Rick,

Most gr-recipes are not updated with openSUSE package names. For this
package it's *python3-pyaml* (single y). If you modify the pyyaml.lwr
recipe in gr-recipes to read:

rpm: python3-pyyaml || python3-pyaml

I would expect it to work. Caveat: untested.

Jared.

On Thu, Oct 8, 2020 at 2:56 PM aardric  wrote:

> Hail,
>
> No urgency because I have been using gnuradio 3.8 built from source
> and installed on the system. However, I am interested in trying out
> PyBOMBS. I see some notes on opensuse requiring additional consideration
> but PyBOMBS installed without a problem, python3-PyYAML and ruamel.yaml are
> installed on the system. However, an attempt to install with
> gnuradio-default recipe using:
>
> prefix/gr38> pybombs -r (...)/sdr/prefix/.pybombs/recipes/gr-recipes prefix 
> init (...)/sdr/prefix/gr38 -a gr38  -R gnuradio-default
>
>
> fails with the final messages below.  Is this anything mysterious or just
> the need for more research on my part?
>
> Package 'python3-pyyaml' not found.
> Install tree:
> |
> \- gnuradio
>|
>+- libvolk
>|
>+- qt5
>|
>+- uhd
>|  |
>|  \- boost
>|
>+- qwt6
>|  |
>|  \- qt5
>|
>+- boost
>|
>\- pyyaml
> [INFO] Phase 1 complete: All binary dependencies installed.
> [INFO] Phase 2: Recursively installing source packages to prefix:
> [INFO] Installing package: pyyaml
> 00254 kB / 00254 kB (100%)
> Configuring: (100%) 
> [=]
> [WARNING] Configuration failed. Re-trying with higher verbosity.
> /bin/sh: ./configure: No such file or directory
> [ERROR] Configuration failed after running at least twice.
> [ERROR] Problem occurred while building package pyyaml:
> Configuration failed
> [ERROR] Error installing package pyyaml. Aborting.
>
>
> Rick
>
>
>

Re: Thoughts on forming a GNU Radio Amateur Radio monthly meeting group

[U L]

GR HAM,

Apparently late to this thread, but I would also be interested in a monthly.

Jared (KM6MRG).

On Mon, Sep 28, 2020 at 11:07 AM Kristoff  wrote:

> Hi Markus, Edmar, Barry, all,
>
>
> Sorry for the late reply (you know .. weekend),
>
>
> Yes, I think it will be interesting do have a small video-chat on this
> subject.
>
> I have the impression that everybody who is looking into getting more
> radio-amateurs into SDR seams to have a similar issue.
> At first, it looks to be "doable" if you orient the classes towards the
> top 5 % hams that have a background that is compatible with looking at
> electronics as signals and as mathematical formulas, but -indeed- it
> becomes a lot more difficult to create a course for 'the average OM'
> especially as amateur-radio has always been a lot more about
> experimentation then 'detailed theory'.
>
> Perhaps the most easy option is  now to do something for the former
> group and work from there on.
>
> Concerning the difference between ham-radio courses and the academia. I
> agree with your analysis but I think we do need to keep in mind that not
> only the audience is very different, but also the goal. After all, our
> goal is (I think) to get more hams to understand SDR. It is not to train
> people to become telecom-engineers that are able to design 5G modems. :-)
>
>
>
> Two more remarks:
>
> - one think I do think that can help is a 'self-learning path' for
> people who want to learn by themself.
>
> There is a lot of information on the internet about signal-processing,
> DSP and SDR (free and paying), and -based on the answers I got on the
> questionnaire I did in the SDR Belgium list- people who do are
> interested in these subjects do find them quite useful. So there might
> be no need to 'reinvent the hot water' (as they say in Dutch)
>
>
> That's also how I got started.
> I wanted to understand the code of Jonathan G4KLX from his pcrepeater
> project, so I needed a book on DSP to understand the code for the LPFs.
> I started with the dspguide (http://dspguide.com) and then the RIchard
> Lyons book. Next up where the 'SDR with the HackRF' videos by Michael
> Ossman, and I now going through the 'wireless-pi' course by Qasim
> Chadhari (when I have time for it).
>
> I have a list of interesting resources (*), but I do think that a more
> structured 'path' can be quite useful for people.
> This applies for people starting out with SDR, or people who have done
> your 'hamradio course' of SDR and want to really go further in this topic.
>
>
> (*) https://github.com/on1arf/sdr/blob/master/links.md
>
>
> - another element that can help is getting more people to use GNU Radio,
> just as an educational tool.
>
> I once used GNU Radio to demonstrate how you can 'filter a signal out of
> noise' (like WSPR, FT8, ... do) by 'averaging out' the noise during out
> weekly jitsi-session of our local radioclub.
> There is a very good video of Tom Rondeau explaining convolution and
> matched filters at TAPR 2012, using GNU Radio as a visual educational
> tool (*)
> It's not about the visual / educational element itself. It also makes
> GNU Radio better known by both the students and the teachers (even
> outside the context of SDR), and let them appreciate the tool.
>
> So it might be just as important to teach the trainers of the
> amateur-radio courses to use the tools out there that can really help
> them to explain things to their students, including GNU Radio. (**)
>
>
> (*) https://youtu.be/cg3TA3EDx78?t=119
> (**) Note that this does only apply to GNU Radio, but also
> antenna-simulation / visualisation tools, math tools like
> octave/scilab/scipy/numpy, or the "falstad" online circuit analysis:
> https://www.falstad.com/circuit/
>
>
>
> Anycase,
> I am very interested in the details your course on SDR and your plans on
> how to do this practically.
> Is this a pure 'class' course or a workshop? How many hours of study
> would be needed for this?
>
> So, if you would plan to do a video-conference on this topic, I think
> there would be quite some interest by some people I know on this topic.
>
>
>
>
> 73
> kristoff - ON1ARF
>
>
>
> On 26/09/2020 12:17, Markus Heller wrote:
> > Dear list,
> >
> > here in Germany we've been working on a standard class to teach SDR to
> > radio amateurs. We see that the learning path is quite steep for the
> > ordinary OM.
> >
> > In the academa you have several semesters time to learn everything you
> > need, including complex maths. But the ordinary OM has very little time
> > compared to a student, and moreover, we don't want to forget those who
> > do not have an academic background. And yes, theree are many who are
> > interested in SDR but are not proficient in English (same in Belgium,
> > I've been discussing this with Kristoff). Probably this also applies to
> > many other countries. So generally I'm glad we have a common language
> > here.
> >
> > There is not much that speaks against preparing a standard class in
> > other 

Re: gr-tempest: an implementation of TempestSDR for GNU Radio

[U L]

Federico,

Well, I've been doing docker for a bit longer than you and I am impressed
with how quickly you got this up and running. Getting a reference GR docker
image defined has been a goal of mine and I'll see what I might change from
this point. I'll address in your github issues if I find something that
works better.

Well done,
Jared.

On Thu, May 14, 2020 at 4:25 PM Federico 'Larroca' La Rocca <
flarr...@gmail.com> wrote:

> Hi again,
> So I've learned some docker and prepared a couple of containers that may
> be useful for other people: one with the latest releases version of GNU
> Radio on the latest stable Ubuntu, and one with GNU Radio 3.7 on an Ubuntu
> 18.04. I share them in https://github.com/git-artes/docker-gnuradio. I
> provide there the run command that enables both sound and GUI (so as to run
> GNU Radio companion).
> Keep in mind that I'm a total newbie to docker. Feedback is always welcome.
> best
> Federico
>
> El vie., 8 may. 2020 a las 13:39, Federico 'Larroca' La Rocca (<
> flarr...@gmail.com>) escribió:
>
>> Thanks Marcus and Jared. Regarding the question of Jared, TEMPEST
>> definitely works on non-CRT monitors. However, since the signal is now
>> emitted only by the cable and the connectors, it will be much less
>> powerful. Note that the principle is the same as in osmo-fl2k [1], although
>> they avoid the nulls at the harmonics of the pixel rate, which complicates
>> TEMPEST (resulting in a sort of horizontal border detector). In my
>> experience, cheap cables and adapters (specially "splitters") generate
>> signals that are easy to spy on from some meters away.
>>
>> Regarding Docker, I'll give it a try. It's a great excuse to finally
>> learn how to use them.
>>
>> best
>> Federico
>>
>> [1] https://osmocom.org/projects/osmo-fl2k/wiki
>>
>> El vie., 8 may. 2020 a las 13:11, Marcus Müller ()
>> escribió:
>>
>>> Hi Federico,
>>>
>>> this is pretty awesome! Thanks for sharing it.
>>>
>>> You can actually install both, if you use separate installation prefixes
>>> for the two and make sure that the PYTHONPATH and LD_LIBRARY_PATH and
>>> GRC_BLOCKS_PATH environment only include one of these.
>>>
>>> Easier, and less error-prone, definitely, is just using a Linux
>>> container. (You could run debian buster in a podman- or docker-run
>>> container, for example. Debian buster comes with 3.8.1.0 out of the
>>> box.).
>>> For non-graphical stuff, that's relatively easy, for graphical (like
>>> yours), there's more fiddling involved until your containers can access
>>> your X server (don't know about Wayland, honestly).
>>>
>>> Best regards,
>>> Marcus
>>>
>>> El vie., 8 may. 2020 a las 1:13, U L () escribió:
>>>
>>>> Federico,
>>>>
>>>> This looks very impressive and I can't wait to play with it. This works
>>>> with non-CRT screens too?
>>>>
>>>> Without a whole lot of hassle you can install GNURadio 3.8 in a
>>>> container (e.g. docker) from an ubuntu or debian base image to avoid
>>>> dependency conflicts between 3.7 and 3.8.
>>>>
>>>> Jared.
>>>>
>>>
>>> On 07.05.20 23:50, Federico 'Larroca' La Rocca wrote:
>>> > Hi everyone,
>>> >
>>> > The last weeks I've been working on a little project I've had in mind
>>> > for a long time now: an implementation of Martin Marinov's excellent
>>> > TempestSDR [1] in GNU Radio. Although it's still work in progress, the
>>> > code is available at https://github.com/git-artes/gr-tempest and I've
>>> > tested it on several recordings I've kept from when we were testing
>>> > TempestSDR (which I share on the project's webpage).
>>> >
>>> > My idea with this re-implementation was to add another cool demo into
>>> > GNU Radio, plus making it easier to extend and maintain by piggybacking
>>> > on GNU Radio's development and using the companion (for instance, I've
>>> > included a channel simulation example). I've made some demos and a
>>> video
>>> > that show them in action: https://www.youtube.com/watch?v=oTCu8HTaN3Y.
>>> >
>>> > I have not yet tested it with hardware as the university is closed now,
>>> > so if anyone can test it I'd be more than glad! Any kind of feedback is
>>> > as usual welcome.
>>> >
>>> > Please note that it is currently built around GNU Radio 3.7 as I'm
>>> > currently in need of this version of GNU Radio for my classes. Is there
>>> > a safe way to install both 3.7 and 3.8?
>>> >
>>> > best
>>> > Federico
>>> >
>>> > [1] https://github.com/martinmarinov/TempestSDR
>>>
>>

Re: [Discuss-gnuradio] Need help with gr-eventstream

[U L]

Team Platypus ran into this precise problem at the DARPA Hackfest.  The
only solution was to code it up ourselves.  It's non-trivial, but not too
much code.

Jared.

On Thu, May 23, 2019 at 1:48 PM Chesir, Aaron M.  wrote:

> Folks,
>
>
>
> I am using the gr-eventstream package in GNUradio, and I need help with
> the EventStream Source block. This is a block that takes a PDU as a message
> input and produces a data stream as an output. My problem is this: I am
> trying to feed the data stream output to a USRP Sink as an input, such that
> the tags in the data that is part of the original PDU input to the
> EventStream Source block get propagated out of the EventStream Source
> output, so that the embedded tags, which change the center frequency of the
> USRP transmitter to effect frequency hopping, get propagated through. It is
> clear that the EventStream Source block is **not** propagating the tags
> through.
>
>
>
> Does anyone have a solution to this?
>
>
>
> Thanks,
>
>
>
> Aaron Chesir
>
>
> ___
> 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] [GREP] Remove log4cpp

[U L]

I think many users, myself included, use logs for debugging.  I would
hesitate to have the log messages propagate through the very system that
you are trying to debug with said messages.  I would rather the logs be
emitted from the system under test as simply and promptly as possible.  I
think that hierarchical organization within the logs should be handled by
log metadata.  It's not clear that one would want to impose the same naming
hierarchy on logs as you do your flowgraph, but one could do so if desired.

Jared.

On Fri, Dec 28, 2018 at 4:37 PM Kevin Reid  wrote:

> On Fri, Dec 28, 2018 at 2:43 PM Müller, Marcus (IEH) 
> wrote:
>
>> For them, that's very important, as they use that to supply resilient
>> infrastructure.  I hope I'm representing the idea kinda correctly here:
>> They might want to log system events ("SUPERVISOR: INFO system load
>> surpassing 75%") somewhere, and development info ("gr-6G: TRACE found a
>> preamble") on-screen, and critical messages ("gr-digital: FATAL run out of
>> developer coffee") everywhere.
>>
>> I want that too. I want this to be easily integratable into software that
>> uses GNU Radio as library. And if I'm already making wishes here,
>> I want loggers that interface to modern logging systems, be it journald,
>> graylog or SNMP. Something.
>>
>
> Speaking as someone who uses GNU Radio as a library, in an application
> where stderr is definitely not part of the user interface, I'd really like
> any logging that's done to be able to be directed to the (Python)
> application for further processing.
>
> I'd further suggest that, when a message identifiably comes from a
> particular block, it should be redirectable within the scope of any
> containing top block or hierarchical block. This way, a hierarchical block
> may have specific handling of messages produced by the primitive or
> sub-hierarchical blocks it uses — and if the hierarchical block is multiply
> instantiated, the application can annotate or process the messages in a way
> specific to the instance.
>
> One possible API for this that comes to mind would be for logging from
> blocks to be a special sort of message port, which propagates up the
> hier-block-archy if not otherwise connected.
> ___
> 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] Docker install recommendation

[U L]

I'm planning on installing the next branch (py3) for testing and potential
development. I'd like to do so in a docker container to isolate
dependencies.  There seems to be a number of starting points including
gnuradio-docker and pybombs-docker in the gnuradio repo.  There's also a
bunch of recipes (what's the docker term?) on hub.docker for various
versions.  Can someone recommend a good example dockerfile or starting
point for building the container?  This will be on a Linux box.
Appreciated.

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

Re: [Discuss-gnuradio] spectrum monitoring / very wide band scanning

[U L]

At my former employer we were using the HackRF in sweep mode to do I think
100 MHz to 6 GHz sweeps at 1 Hz (i.e. almost 6 GHz scanned each second).
For contiguous sweeps I think it used a non-configurable 7.5 MHz (RF tuned)
step or something like that, but gave you much better frequency resolution
as the waterfall was the output of a some FFT which was somewhat
configurable (so you could sort of set the resolution BW).  We did make use
of QSpectrumAnalyzer mentioned in a previous post and in combination with
the hackrf sweep-mode worked quite well.  I think the HackRF uses the same
driver as rtl-sdrs but a typical rtl does not support the sweep-mode of
operation.

On Wed, Mar 28, 2018 at 8:00 PM, Balthasar Indermuehle 
wrote:

> Thanks Marcus, indeed I'm using B200's for this project. X300's are
> slightly over my budget unfortunately... but I'm also interested in doing
> the same with RTL dongles.
> You mention 450ms for tuning a B200 - that seems rather longish?
>
> Cheers
>
> - Balt
>
> On 29 March 2018 at 06:04, Müller, Marcus (CEL)  wrote:
>
>> so, 60 steps in 3 Minutes… sounds absolutely doable with the Ettus B200
>> (you asked about UHD drivers, so I presume you mean USRPs – the RTL
>> dongle has nothing to do with UHD) and the usrp_spectrum_sense.py
>> script that comes with GNU Radio. Even if I do not endorse the
>> architecture of that script, and would recommend you reserve up to
>> 450ms for tuning, as the B200 can take a bit of time to tune over some
>> larger steps.
>> With the other USRPs, you'd be faster. With a X300+TwinRX, you'd be
>> able to do 80 MHz on each channel at once, and can tune the channels
>> independently, so that you can actually even interleave tuning and
>> receiving operation; realistically, that'd imply an effective
>> observable bandwidth of always at least 120 MHz; 3000 / 120, meaning
>> you only need 24 steps to cover all that bandwidth. With tuning delays
>> in single milliseconds (too lazy to look this up right now, so let's
>> say 1ms), that'd be 25ms tuning, roughly 2.999583 minutes of spectrum
>> observation for 3 minutes of operation.
>>
>> Stitching that together to a full spectrum is more of a challenge here,
>> but assuming you control the frequency hopping with commands to the
>> USRP Source block, and hence are in control of when which band appears
>> on the sample streams:
>> You could do something like have a fixed 13-frequency sequence that
>> each of the two receive channels hop along in fixed time intervals.
>> Convert to vectors of interval length, FFT+magnitude-square these, and
>> reassemble to a full spectrum vector (if your frequency sequence is
>> strictly ascending, and non-overlapping, then just leave them in the
>> order they are – all frequency bins should now be equidistantly
>> spaced).
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2018-03-28 at 12:19 +1100, Balthasar Indermuehle wrote:
>> > At my work we're using R EB500s for continuous spectrum monitoring at
>> our sites of interest. These machines step through the frequencies 70 -
>> 3000 MHz in about 3 minutes in chunks of 50 MHz (from memory), and then
>> assemble the fragments into a contiguous waterfall display.
>> >
>> > Is anyone aware of a wide band scanner software (that may or may not be
>> GNUradio based) that works with RTL-SDR dongles and with UHD drivers and
>> would allow to create a wide band spectrum sweep?
>> >
>> > I've built a raw IQ recorder that does just that, but it needs to be
>> wrapped into a decent GUI, showing some nice waterfall displays and needs
>> to be made pretty. Before I'm investing the time to build this I thought
>> I'd check if that's not effort already done and shared by someone else.
>> Google thinks no... anyone know differently?
>> >
>> > - Balt
>> > ___
>> > 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
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Getting signal from a LEO Satellite? ( Doppler shift handling)

[U L]

If you have a tracking dish, you might want to look at the FLL (freq lock
loop) band edge block.  There was a talk on it during GRCON17
https://drive.google.com/file/d/0B-CV_07uSBIuQUVlNDFUX1BqZk0/view

If you have a symmetric signal spectrum w/ a generally flat channel (which
tends to be satcom signals) then this might work as well.

Jared.

On Thu, Oct 26, 2017 at 5:02 AM, mehtap özkan 
wrote:

> Thank you.
> Should we adjust the Loop Bandwidth to track the signal correctly?
>
> 2017-10-26 14:20 GMT+03:00 Jean-Michel FRIEDT <
> jean-michel.fri...@femto-st.fr>:
>
>> costas will do the job as long as your measurement bandwidth includes
>> twice the expected frequency offset, see http://jmfriedt.free.fr/efts_g
>> ps.pdf
>> slide 13.
>>
>> JM
>>
>>
>> I am planning to track a signal from a LEO Satellite which transmits
>>> approx. 100 kbps BPSK.
>>> I wonder which blocks should I use since the carrier offset ranges are:
>>> around -50 kHz (beginning of the pass)
>>> around +50 kHz (at the endof the pass)
>>>
>>> Possible blocks are:
>>>
>>> PLL Carrier Tracking
>>> Costas Loop (using the frequency output port to get the carrier freq.
>>> error)
>>>
>>> Any other suggestions- Examples?
>>>
>>> Please don't offer manually shifting the frequency.(Using Gpredict)
>>>
>>>
>>
>>
>> --
>> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe, 25000
>> Besancon, France
>>
>> 
>> This message was sent using IMP, the Internet Messaging Program.
>>
>>
>
> ___
> 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] Gnu radio and IDEs

[U L]

I would recommend any IDE supported by cmake, as it is nice to have cmake
build the appropriate project files for the IDE.  I've personally used
codeblocks which I find acceptable.  I guess if the IDE has a sufficient
project import feature this might not be as important. On my system

$ cmake --help
...
Generators

The following generators are available on this platform:
  Unix Makefiles   = Generates standard UNIX makefiles.
  Ninja= Generates build.ninja files.
  Watcom WMake = Generates Watcom WMake makefiles.
  CodeBlocks - Ninja   = Generates CodeBlocks project files.
  CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
  CodeLite - Ninja = Generates CodeLite project files.
  CodeLite - Unix Makefiles= Generates CodeLite project files.
  Sublime Text 2 - Ninja   = Generates Sublime Text 2 project files.
  Sublime Text 2 - Unix Makefiles
   = Generates Sublime Text 2 project files.
  Kate - Ninja = Generates Kate project files.
  Kate - Unix Makefiles= Generates Kate project files.
  Eclipse CDT4 - Ninja = Generates Eclipse CDT 4.0 project files.
  Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.
  KDevelop3= Generates KDevelop 3 project files.
  KDevelop3 - Unix Makefiles   = Generates KDevelop 3 project files.



On Fri, Oct 13, 2017 at 4:55 PM, Martin Braun 
wrote:

> On 10/13/2017 02:27 PM, Andrej Rode wrote:
> > Hi,
> >
> >>> Does anyone have experience e using an idea integrated with gnu radio
> for
> >>> making c, c++ modules? Any recommendations? Eclipse? NetBeans? Don't
> do it?
> >
> > you can basically use any IDE which support C/C++ if you are into
> > hacking blocks together in C/C++. If you are using existing
> > blocks/create Python blocks you could get along with an IDE only
> > supporting Python.
> >
> > You can even work on GNU Radio just using an Editor. It really depends
> > on your personal preference.
>
> We've had some vague ideas about integrating gr_modtool into some IDE,
> but not much has come of it. That said, gr_modtool is pretty easy to use
> from the command line alongside the IDE of your choice.
>
> -- M
>
>
> ___
> 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] USRP tx_time tags and late packets

[U L]

I'm surprised no one responded to this.  My group has had some experience
with this.

We found latency can be extremely large for packetized transmits,
especially if the packets are small.  Without modification, there is a
minimum buffer size GNURadio sets regardless of the buffer size settings in
blocks (or top_block).  This means packets will build up in the output
buffers of every block b/w source and sink.  Even the solution collecting
packets will still have large latency because the output buffers are again
filled with packets before being sent out.

What you might be able to do.
1.  Modify the minimum buffer size.  This is non-trivial, the correct
implementation will maintain the minimum buffer size for efficiency but
essentially manage a sliding window across the larger buffer, whereby the
window size is the desired buffer size.  This is prob. the solution to #3.
2.  Use PDUs everywhere such that you can propagate packets at the
generation rate and not build up a queue before the sink.

We were able to get latency down with option 1.  I asked my colleague who
performed experiments with a USRP N210 on a moderately powerful laptop.
The flowgraph was usrp source to usrp sink and he correlated the signal
running into and out of the USRP.  With real-time scheduling and high
thread priorities and small buffer size he was able to get 1 ms in-to-out
latency @ 2 Msps sample rate.

One other tip: the PC clock and USRP clock are not in sync.  If you want
precisely timed transmissions, you need something monitoring the internal
clock of the USRP.  You may be able to do this by querying the time
periodically.  I believe you can do this through the command interface: you
request a time tag to be output on a usrp source stream.  You can then keep
time by counting samples from the source tag.

Good luck, I hope you make some progress and report it here.  I for one
would be very interested.
Jared.





On Tue, May 2, 2017 at 8:28 PM, Stephen Larew  wrote:

> Answering “question” #1 that I asked below: it looks like I can use
> gr::uhd::amsg_source to get the UHD async_metadata_t.  I will experiment
> with that for now, but questions #2 and #3 still stand for me.
>
> > On May 2, 2017, at 16:33, Stephen Larew  wrote:
> >
> > I am having trouble with late packets at the USRP.  I am working on a
> TDD system with GNU Radio and x310 radios.  I understand that I should use
> SOB and EOB tags to delimit a packet and add the tx_time tag to control
> transmission time.
> >
> > Current approach: In the source block, I set the tx_time tag to a point
> that is in the future relative to the host computer’s clock, which was
> synchronized with the USRP at program startup.  The samples flow through
> the graph and get to the usrp_sink block for transmission.  The latency in
> the flowgraph seems to vary enough such that some packets are late (UHD
> prints ‘L’) while other packets are not late.  I have set max_noutput_items
> when calling top_block.run() to try to bound the latency, but with limited
> improvements.
> >
> > 1. In GNU Radio using stock usrp_sink, is there a method of getting the
> late flag without having to monitor stdout and parse Ls? I recently read on
> USRP-users that the proper way to detect late packets is to look at the
> metadata returned from uhd’s send function. Does the usrp_sink block
> publish this in some way?
> >
> > 2. Any tips for doing *tightly timed* TDD in GNU Radio in general?  For
> example, we are experimenting with a) setting tx_time at the source block
> (requires predicting the flowgraph’s processing delays in order to not be
> late at the USRP) and b) setting tx_time at a custom block just before the
> usrp_sink so that most of the flowgraph processing delays are not a factor
> when computing a tx_time.  What approaches have been taken by others?
> >
> > 3. When or why would supplying a max_noutput_items to top_block.run()
> not be passed on to or respected by blocks in a flow graph?  My colleague
> observed that noutput_items given to work() was greater than what was given
> to top_block.run().  Do tagged stream blocks change the scheduler behavior
> w.r.t max_noutput_items?
> >
> > -Stephen
>
> ___
> 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] log4cpp library not found

[U L]

On opensuse tumbleweed I needed to install the log4cpp-devel package.  The
FindLog4cpp.cmake file looks for Category.hh and liblog4cpp.so.   The
log4cpp-devel has the files

/usr/include/log4cpp/Category.hh
/usr/lib64/liblog4cpp.so
/usr/lib64/pkgconfig/log4cpp.pc

Unfortunately it appears that the cmake script doesn't look in /usr/lib64
for the lib, that may be the problem.  I'm a little surprised my
CMakeCache.txt has HAVE_LOG4CPP=TRUE.  Perhaps there's another mechanism to
find the libs.

Jared.


On Sat, Apr 1, 2017 at 3:40 PM, li...@lazygranch.com 
wrote:

>
> find / -name "FindLog4cpp.cmake"
> /usr/local/src/gnuradio/cmake/Modules/FindLog4cpp.cmake
> /usr/local/lib/cmake/gnuradio/FindLog4cpp.cmake
>
> That file is found twice. Is that the problem? If not, which do I
> replace? Or perhaps both. Or does one file cause the other file to be
> updated?
>
>
> On Sat, 1 Apr 2017 19:03:52 +0200
> Marcus Müller  wrote:
>
> > That's very interesting, considering that I believe the CMake script
> > that looks for log4cpp uses the same pkg-command to look for it...
> >
> > Ok. So there's something strange going on with that
> > cmake/Modules/FindLog4cpp.cmake, probably.
> >
> > Can you replace that Find...cmake with the one I've attached and give
> > it a try?
> >
> > Cheers,
> >
> > Marcus
> >
> >
> > On 01.04.2017 18:27, li...@lazygranch.com wrote:
> > > Hyphen instead of underscore.
> > >
> > > pkg-config --libs log4cpp
> > > -L/usr/local/lib64 -llog4cpp
> > >
> > > So pkg-config finds the library. Note I got the same problem
> > > regarding not finding log4cpp when I used the opensuse package
> > > manager version instead of making my own in /usr/src.
> > >
> > >
> > >
> > >
> > > On Sat, 1 Apr 2017 11:19:14 +0200
> > > Marcus Müller  wrote:
> > >
> > >> Hi,
> > >>
> > >> if you've built it yourself, chances are that automatic tools like
> > >> CMake's find_package or the general pkg_config can't find it,
> > >> because you didn't put the right files in the distro-typical
> > >> places.
> > >>
> > >> Try running
> > >>
> > >> pkg_config --libs log4cpp
> > >>
> > >> If that fails: Please make sure the installation put the
> > >> packageconfig files in a place that packageconfig looks into.
> > >>
> > >> Best regards,
> > >> Marcus
> > >>
> > >> On 04/01/2017 11:13 AM, li...@lazygranch.com wrote:
> > >>> I built it myself in usr local.
> > >>>
> > >>> The source exists at github and sourceforge. Apparently SF is the
> > >>> original. I built both versions and neither is found by gnuradio
> > >>> in the build process.
> > >>>
> > >>> The contents /usr/local/include/log4cpp is at this pastebin.
> > >>> https://pastebin.com/fw6NUR6x
> > >>> This is the after the SF build.
> > >>>
> > >>>
> > >>>
> > >>> On Fri, 31 Mar 2017 22:07:59 -0400
> > >>> "Marcus D. Leech"  wrote:
> > >>>
> >  On 03/31/2017 09:13 PM, li...@lazygranch.com wrote:
> > > opensuse 42.2
> > >
> > > This is the only "missing" thing I can find in the cmake ..:
> > >
> > >
> > >
> > > -- Configuring volk support...
> > > --   Enabling volk support.
> > > --   Override with -DENABLE_VOLK=ON/OFF
> > > --   Override with -DENABLE_INTERNAL_VOLK=ON/OFF
> > > -- ENABLE_GR_LOG set to ON.
> > > -- HAVE_LOG4CPP set to False.
> > > -- LOG4CPP_LIBRARIES set to .
> > >
> > > Though the library is there. Perhaps it has a different name in
> > > other distributions? I can make symbolic links if need be.
> > >
> > > /usr/lib64 # ls
> > > liblog4cpp* liblog4cpp.so  liblog4cpp.so.5  liblog4cpp.so.5.0.6
> > >
> > >
> > >
> >  It may be the case that you don't have the matching #include
> >  files, which is what code being compiled needs in addition to the
> >  libraries.
> > 
> > 
> > 
> >  ___
> >  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
> > >
> > > ___
> > > 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

Re: [Discuss-gnuradio] installing a python package without elevated privileges

[U L]

Being all things to everyone is tough.  I recently contributed some code to
support the openSUSE package manager, zypper, in pybombs.  So universal
support is kind of an evolving feature.  Perhaps it would be a start to
simply limit the initial virtualenv support to python2.  I would suggest
that if one were in a virtualenv, you let that handle the pip version
(which should be referenced just by the pip command).  I would also submit
that python packages should not be added to the system via a package
manager if you're in a virtualenv.  This would alleviate some of the
package naming discrepancies between the versions.  I don't think
gr-recipes supports python3 packages right now for any packager.  Good
points nonetheless.

Jared.

On Fri, Mar 31, 2017 at 10:30 AM, Martin Braun <martin.br...@ettus.com>
wrote:

> Please note that there's an open issue on how PyBOMBS and venvs are
> effectively broken (https://github.com/gnuradio/pybombs/issues/363).
> There are also related issues regarding the fact that we don't know if
> we're running Python 2 or 3. So yeah, I know about this, and would love
> to see it fixed, but I'm not doing it myself anytime soon.
>
> For example, what if your system's default is Python 2, but your
> virtualenv is running Python 3. In that case, you would need to make
> sure that you don't accidentally check your system's package manager for
> python2-mako. pybombs itself may be running a different Python than is
> going to be executed in the prefix.
> The same holds for if we need pip, pip2, or pip3.
>
> I'm open for suggestions and pull requests, but keep in mind that I
> can't merge stuff if
>
> - It's based on personal preferences, e.g. the pip vs. apt discussion.
> Note that there's also different cases here, you might prefer apt over
> pip for system-wide installs, and pip over apt for your virtualenv install.
> - It hardcodes stuff where it shouldn't (e.g., having IF PKGR == PIP
> style code in the package_manager.py)
> - It makes assumptions about people's systems.
>
> Also, I should acknowledge that both Jared and Marcus have contributed
> to PyBOMBS, so this is not just an empty discussion here :)
>
> Cheers,
> Martin
>
> On 03/27/2017 08:14 PM, U L wrote:
> > This is a problem I have faced as well.  I have a number of projects at
> > various levels of modification of GR and various 3rd party python
> > packages being supported.  I find having virtualenvs to be very useful
> > in keeping python package versions, GR mods, and my own modules in
> > agreement.  I've been tinkering a bunch with getting venvs and pybombs
> > to work together and I think I've made some headway.  For example, the
> > elevated privileges for pip is (nominally) hardcoded in
> > packagers/pip.py.  I made a modification to condition elevation on the
> > presence of a virtualenv, which is detected in the config_manager.  This
> > is one way to perhaps get pybombs and virtualenvs to play nice.  I'll
> > hopefully be offering a pull request soon that incorporates a number of
> > changes.
> >
> > On Wed, Mar 22, 2017 at 12:30 PM, Naceur <naceur.elo...@nist.gov
> > <mailto:naceur.elo...@nist.gov>> wrote:
> >
> > You are right if they had access to it at first place. Anyhow I
> > fixed it.
> >
> >
> >
> > --
> > View this message in context:
> > http://gnuradio.4.n7.nabble.com/installing-a-python-
> package-without-elevated-privileges-tp63183p63258.html
> > <http://gnuradio.4.n7.nabble.com/installing-a-python-
> package-without-elevated-privileges-tp63183p63258.html>
> > Sent from the GnuRadio mailing list archive at Nabble.com.
> >
> > ___
> > 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
> > 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] installing a python package without elevated privileges

[U L]

This is a problem I have faced as well.  I have a number of projects at
various levels of modification of GR and various 3rd party python packages
being supported.  I find having virtualenvs to be very useful in keeping
python package versions, GR mods, and my own modules in agreement.  I've
been tinkering a bunch with getting venvs and pybombs to work together and
I think I've made some headway.  For example, the elevated privileges for
pip is (nominally) hardcoded in packagers/pip.py.  I made a modification to
condition elevation on the presence of a virtualenv, which is detected in
the config_manager.  This is one way to perhaps get pybombs and virtualenvs
to play nice.  I'll hopefully be offering a pull request soon that
incorporates a number of changes.

On Wed, Mar 22, 2017 at 12:30 PM, Naceur  wrote:

> You are right if they had access to it at first place. Anyhow I fixed it.
>
>
>
> --
> View this message in context: http://gnuradio.4.n7.nabble.
> com/installing-a-python-package-without-elevated-
> privileges-tp63183p63258.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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to properly add a pybombs packager

[U L]

All,

Thanks for the help, I think I found my problem.  For searching installed
packages, zypper is quite slow.  I have an alternative using the rpm
command but the arguments were wrong, causing the version parsing to fail.
That's been fixed and it seems that packages are now properly installed
(and not) as necessary.  However, it still doesn't help with the virtualenv
installation.  Seems that the pip packager uses distutils for a number of
packages that fail (wxpython, pycairo, pygobject, pygtk) in some cases b/c
they state explicitly that they can't use distutils for installation on
linux.  I can also try to forcebuild all of those.  I'll have to
investigate further.  Perhaps I'll try an install in the system python of a
openSUSE VM to see if it succeeds using zypper.  If so perhaps I could
submit a pull request.

Anyways, that's the story.

Jared.


On Wed, Sep 21, 2016 at 10:38 PM, Andrej Rode  wrote:

> Hey Jared,
>
> nice you want to add another package manager to PyBOMBS. I recently
> added portage package manager  to PyBOMBS.
>
> Based on your output these lines [0] give a clue what's happening.
> I'd guess your functions do not properly report the installation status
> back to PyBOMBS.Therefore PyBOMBS keeps trying to install wget with
> every possible package manager left.
>
> Cheers,
> Andrej
>
>
> [0]
> ```
> PyBOMBS.PackageManager - DEBUG -  [1m [35mUsing packager zypper [0m
> PyBOMBS.Packager.zypper - OBNOXIOUS -  [1m [90minstall(wget,
> static=False) [0m
> PyBOMBS.ReqScanner - OBNOXIOUS -  [1m [90mAdding package with name wget [0m
> PyBOMBS.ReqScanner - OBNOXIOUS -  [1m [90mEnd of requirements list [0m
> PyBOMBS.ReqScanner - OBNOXIOUS -  [1m [90mDone parsing requirements
> string `wget` [0m
> PyBOMBS.Packager.zypper - OBNOXIOUS -  [1m [90mCalling ev for recursive
> satisfier rule evaluation [0m
> PyBOMBS.Packager.zypper - DEBUG -  [1m [35mPackage wget has version
> 1.18-2.2  in zypper [0m
> PyBOMBS.monitor_process() - DEBUG -  [1m [35mRunning with elevated
> privileges. [0m
> PyBOMBS._process_thread() - DEBUG -  [1m [35mExecuting command `['sudo',
> '-H', 'zypper', 'install', '-y', 'wget']' [0m
> Loading repository data...
> Reading installed packages...
> 'wget' is already installed.
> No update candidate for 'wget-1.18-2.2.x86_64'. The highest available
> version is already installed.
> Resolving package dependencies...
>
> Nothing to do.
> PyBOMBS.monitor_process() - DEBUG -  [1m [35mThread signaled termination
> or returned [0m
> PyBOMBS.monitor_process() - DEBUG -  [1m [35mReturn value: 0 [0m
> PyBOMBS.PackageManager - INFO -  [1m [32mgetattr(zypper,
> install)(Recipe: wget
> category: baseline
> ```
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio