Re: encode and modulation

[Nick Foster]

Among other things, the GMSK Mod block expects packed bytes. Remove the Map
block and add an Unpacked to Packed block in its place. The filter
parameters on the receiver are also incorrect and will filter out most of
your signal.

In general, every time you make a change you must view the baseband
spectrum and time domain signal (at least) to confirm that the change you
expect is the change you see.

Nick


On Wed, Feb 3, 2021 at 7:26 AM kaihua cheng  wrote:

> Hello, I want to build a transceiver by using CCSDS and GMSK.  I have no
> problem with running CCSDS alone.  But once I add GMSK, the decoding is
> completely off.  can someone help me with it?  below is the attachment!
> thank you
>

How to set variable number of inputs/outputs in Python OOT modules

[George Edwards]

Hello,

I wish to build an OOT module in Python which can take a variable number of
inputs and outputs. In C++ OOT, there are the io signatures <+min_in+>,
<+max_in+>, etc. which can be set to 1 and -1 to mean the input can be any
number. Python does not have these, it has the in_sig and out_sig which do
not offer the flexibility as the C++ OOT. How can I get a variable number
of inputs/outputs that is user defined in a Python OOT?

Also, how do I set the parameters in yml file for variable inputs and
outputs?

I will appreciate any help.

Thank you!

Regards,
George

Re: How to set variable number of inputs/outputs in Python OOT modules

[Jeff Long]

`gr.io_signature()` in Python works exactly the same as it does in C++. The
legacy Python way (list of types) is still used in most places, but you
have the option.

On Wed, Feb 3, 2021 at 3:17 PM George Edwards 
wrote:

> Hello,
>
> I wish to build an OOT module in Python which can take a variable number
> of inputs and outputs. In C++ OOT, there are the io signatures <+min_in+>,
> <+max_in+>, etc. which can be set to 1 and -1 to mean the input can be any
> number. Python does not have these, it has the in_sig and out_sig which do
> not offer the flexibility as the C++ OOT. How can I get a variable number
> of inputs/outputs that is user defined in a Python OOT?
>
> Also, how do I set the parameters in yml file for variable inputs and
> outputs?
>
> I will appreciate any help.
>
> Thank you!
>
> Regards,
> George
>

Re: Jamming the WiFi channel

[Christophe Seguinot]

  
  
Not used to the waterfall QT GUI but it would have properties
  derived from FFT: 


  total span  is equal to sampling_rate
  "resolution" is equal to df=sampling_rate/FFT size (one
frequency point at each df)
  not to be confused with : resolution bandwith which  is only
defined in real spectrum analyser (however, I think for FFT
resolution bandwith equal df BUT can not be adjusted)
  
  sweep time is not defined however, you can adjust update
period (to be verify but 1 FFT will be plotted at each update
period)



On 03/02/2021 17:09,
  paulles...@mailo.com wrote:


  
  Hello,
  
  
  I have successfully build a jamming signal for a WI-FI
channel and I am able to transmit it using the hackrf.
  
  
  It is a 10us jamming signal as shown in the picture from a
lab spectrum analyser. However, I am trying to have the same
visualisation on gnuradio using a waterfall block (I am planning
to use this jamming signal in a simulation experiment and I am
to be sure that the hackrf does not transform in any way the
baseband signal) but I cannot find parameters such as sweep
time, bandwidth resolution, span... are there equivalents
parameters in gnuradio's QT visualizations blocks ? 
  
  
  
  Thanking you in advance,
  
  
  PL
  
  
  
  From: Cinaed Simson

To: discuss-gnuradio@gnu.org
Subject: Re: Jamming the WiFi channel
Date: 17/01/2021 22:38:36 Europe/Paris

Hi JM - I agree.  And typically with knowing very little about 
anything,  one can jam WIFI using aircrack-ng.

But I would argue the SDR doesn't have to handshake with the
receiver or 
scan the network, so it may be more efficient.

But on the other hand, you may need more computing power then
Raspberry Pi.

-- Cinaed

On 1/17/21 9:51 AM, jean-michel.fri...@femto-st.fr wrote:
> We might hide or we might discuss ... jamming systems are
less than 10 euros on amazon [0]
> for any script-kiddie to play with including myself [1].
Why anyone one would want to
> implement this in SDR rather than a NE555+VCO is beyond my
understanding by why not ...
> we even got to reverse engineer such a device to check its
performance. The military
> will pay you for doing this [2] (and a bit more) so rather
than hiding from the real
> world we might as well face it and educate users.
>
> My (useless) 2 cents, but thank you for the most
informative reference and its introductory
> citation
> JM
>
> [0] https://www.amazon.fr/IrahdBowen-Bloqueur-Bouclier-Brouilleur-Disjoncteur/dp/B07KSC5LLD
> [1] http://jmfriedt.free.fr/misc_deleurrage.pdf
[in French] on GPS jamming and jamming cancellation
> [2] https://www.defense.gouv.fr/aid/appels-a-projets/appel-a-projets-pour-une-mini-charge-utile-d-appui-electronique-sur-drones
[in French]
>
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de
l'Epitaphe, 25000 Besancon, France
>
> January 17, 2021 6:24 PM, "Aditya Arun Kumar"
 wrote:
>
>> Hi Derek,
>> Yeah, I accept all the things, after all, I have to, as
I tend to wireless systems and their
>> security and some more stuff with regards to radios and
SDR and things. But what I suggest is that
>> we guys start a separate application/discussion area
for these kinds of things (because I
>> personally as well to some extent historically believe[
https://doi.org/10.1080/03071847709428739
>> ]) that this must be an integral part of the ecosystem.
I accept the part where one needs to have
>> proper RF enclosures or a SCIF to conduct these
emission experiments (unless it a wide range of
>> open testing).
>>
>> I propose that we have a separate discussion for things
like this, just for educational purposes,
>> because I feel that there is too much
"Telecommunications" research happening, but very quiet a
>> limited discussion regarding "What is the best way to
build a signal for a jammer from its spectra"
>> or "What happens in spatial resolution compromise in a
RADAR system and how this can be a problem".
>> Basically, I am trying to say let's break the taboo
about the discussion about EW and SIGINT and
>> ELINT using SDR and GRC. After all, radios are fun.
>>
>> This part goes to Mr.Robert
>> In my humble opinion sir, I don't agree with yo

Re: Jamming the WiFi channel

[Christophe Seguinot]

  
  
Oups
I've seen your flowgraph 

Sawtooth generator frequency can not exceed sampling_rate/2, but
  it's set to 1 THz !!!  Should be 100kHz (for 10 µs)
The waterfall can not be used to obtain the measurements you get
  with a spectrum analyzer. 


  with 20 Mhz sampling_rate , each sawtooth period (10µs / 0.1
MhZfrequency) correspond to 20M/0.1M= 200 samples / period.
  when the fft is calculated, is uses fft_size point. 
  
  So when a fft is calculated, even with as low as 128 FFT size,
it cover a half the sawtooth period and cover approximately half
the frequency range of the VCO output. 
  
  So to obtain a waterfall one would at least increase
sampling_rate to its maximum, while decreasing fft_size. Even if
that was possible, the resolution would be too low
  

In fact, a spectrum analyzer is far more performant than any
  simulator. 





On 03/02/2021 17:09,
  paulles...@mailo.com wrote:


  
  Hello,
  
  
  I have successfully build a jamming signal for a WI-FI
channel and I am able to transmit it using the hackrf.
  
  
  It is a 10us jamming signal as shown in the picture from a
lab spectrum analyser. However, I am trying to have the same
visualisation on gnuradio using a waterfall block (I am planning
to use this jamming signal in a simulation experiment and I am
to be sure that the hackrf does not transform in any way the
baseband signal) but I cannot find parameters such as sweep
time, bandwidth resolution, span... are there equivalents
parameters in gnuradio's QT visualizations blocks ? 
  
  
  
  Thanking you in advance,
  
  
  PL
  
  
  
  From: Cinaed Simson

To: discuss-gnuradio@gnu.org
Subject: Re: Jamming the WiFi channel
Date: 17/01/2021 22:38:36 Europe/Paris

Hi JM - I agree.  And typically with knowing very little about 
anything,  one can jam WIFI using aircrack-ng.

But I would argue the SDR doesn't have to handshake with the
receiver or 
scan the network, so it may be more efficient.

But on the other hand, you may need more computing power then
Raspberry Pi.

-- Cinaed

On 1/17/21 9:51 AM, jean-michel.fri...@femto-st.fr wrote:
> We might hide or we might discuss ... jamming systems are
less than 10 euros on amazon [0]
> for any script-kiddie to play with including myself [1].
Why anyone one would want to
> implement this in SDR rather than a NE555+VCO is beyond my
understanding by why not ...
> we even got to reverse engineer such a device to check its
performance. The military
> will pay you for doing this [2] (and a bit more) so rather
than hiding from the real
> world we might as well face it and educate users.
>
> My (useless) 2 cents, but thank you for the most
informative reference and its introductory
> citation
> JM
>
> [0] https://www.amazon.fr/IrahdBowen-Bloqueur-Bouclier-Brouilleur-Disjoncteur/dp/B07KSC5LLD
> [1] http://jmfriedt.free.fr/misc_deleurrage.pdf
[in French] on GPS jamming and jamming cancellation
> [2] https://www.defense.gouv.fr/aid/appels-a-projets/appel-a-projets-pour-une-mini-charge-utile-d-appui-electronique-sur-drones
[in French]
>
> --
> JM Friedt, FEMTO-ST Time & Frequency, 26 rue de
l'Epitaphe, 25000 Besancon, France
>
> January 17, 2021 6:24 PM, "Aditya Arun Kumar"
 wrote:
>
>> Hi Derek,
>> Yeah, I accept all the things, after all, I have to, as
I tend to wireless systems and their
>> security and some more stuff with regards to radios and
SDR and things. But what I suggest is that
>> we guys start a separate application/discussion area
for these kinds of things (because I
>> personally as well to some extent historically believe[
https://doi.org/10.1080/03071847709428739
>> ]) that this must be an integral part of the ecosystem.
I accept the part where one needs to have
>> proper RF enclosures or a SCIF to conduct these
emission experiments (unless it a wide range of
>> open testing).
>>
>> I propose that we have a separate discussion for things
like this, just for educational purposes,
>> because I feel that there is too much
"Telecommunications" research happening, but very quiet a
>> limited discussion regarding "What is the best way to
build a signal for a jammer from its spectra"
>> or "What happe

Re: How to set variable number of inputs/outputs in Python OOT modules

[Gavin Jacobs]

In 3.7, you would use the  tag, but in 3.8 the trick to setting 
multiple ins/outs in the YML file, is the keyword "multiplicity". You can see 
the details of how to configure here:
https://wiki.gnuradio.org/index.php/YAML_GRC

YAML GRC - GNU Radio
Starting with release 3.8, YAML replaces XML as the file format for GNU Radio 
Companion. This is triggered by switching from Cheetah to Mako as the 
templating engine, since Cheetah does not support Python 3.
wiki.gnuradio.org

Re: New Raspberry PI Complete OS release

[Gavin Jacobs]

Glen,
I'm going through a pain similar to yours.
For working examples, you can look at the source for the blocks that are part 
of GNU Radio. For example, the Multiply Constant block shows how to do a 
callback, and the Add block shows how to do variable number of inputs. 
Unfortunately, these blocks also have the complexity of allowing Vector inputs, 
and different types of inputs, so you have to dig through that to get at the 
parts you want.

The closest thing I found for a working OOT module, is documented here:
https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B
It only applies to 3.7 & 3.8, so you still have to sleuth out the differences 
for 3.9.  Also, it does not show how to do variable # of inputs, nor a 
parameter callback. I'm working on a block that needs those; so as soon as I 
have it sorted out, I'll put the sources on Github.
Guided Tutorial GNU Radio in C++ - GNU 
Radio
Note: the get_minimum_distances function declaration also needs to be added to 
the class header (my_qpsk_demod_cb_impl.h).The function get_minimum_distances 
is a maximum likelihood decoder for the QPSK demodulater. Theoretically, the 
function should compute the distance from each ideal QPSK symbol to the 
received symbol (It is mathematically equivalent to determining the Voronoi 
regions of the ...
wiki.gnuradio.org




Date: Tue, 2 Feb 2021 21:19:32 -0500
From: Glen Langston 
To: Marcus Müller 
Cc: discuss-gnuradio@gnu.org
Subject: Re: New Raspberry PI Complete OS release

I appreciate gr-modtool, but it is frustrating that modtool does not generate
working code.   There really, really, really needs to be an ultra-simple working
example of C++ code for 3.8 and 3.9 that actually build.

The code could do anything, but just allow us to use it as the basis for
creating YAML and SWIG/PYBIND code based on the new requirements.

Re: New Raspberry PI Complete OS release

[Glen Langston]

Thanks Gavin

I’ll take a look.

Best regards

Glen

> On Feb 3, 2021, at 6:17 PM, Gavin Jacobs  wrote:
> 
> Glen,
> I'm going through a pain similar to yours.
> For working examples, you can look at the source for the blocks that are part 
> of GNU Radio. For example, the Multiply Constant block shows how to do a 
> callback, and the Add block shows how to do variable number of inputs. 
> Unfortunately, these blocks also have the complexity of allowing Vector 
> inputs, and different types of inputs, so you have to dig through that to get 
> at the parts you want. 
> 
> The closest thing I found for a working OOT module, is documented here:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B
> It only applies to 3.7 & 3.8, so you still have to sleuth out the differences 
> for 3.9.  Also, it does not show how to do variable # of inputs, nor a 
> parameter callback. I'm working on a block that needs those; so as soon as I 
> have it sorted out, I'll put the sources on Github.
> Guided Tutorial GNU Radio in C++ - GNU Radio
> Note: the get_minimum_distances function declaration also needs to be added 
> to the class header (my_qpsk_demod_cb_impl.h).The function 
> get_minimum_distances is a maximum likelihood decoder for the QPSK 
> demodulater. Theoretically, the function should compute the distance from 
> each ideal QPSK symbol to the received symbol (It is mathematically 
> equivalent to determining the Voronoi regions of the ...
> wiki.gnuradio.org
> 
> 
> 
> Date: Tue, 2 Feb 2021 21:19:32 -0500
> From: Glen Langston 
> To: Marcus Müller 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New Raspberry PI Complete OS release
> 
> I appreciate gr-modtool, but it is frustrating that modtool does not generate
> working code.   There really, really, really needs to be an ultra-simple 
> working
> example of C++ code for 3.8 and 3.9 that actually build.
> 
> The code could do anything, but just allow us to use it as the basis for
> creating YAML and SWIG/PYBIND code based on the new requirements.

Re: New Raspberry PI Complete OS release

[Glen Langston]

Hi Gavin,

Thanks again.

What I need is a simple function that is -not- a standard part of Gnuradio
but rather can be built in 3.7, 3.8 or 3.9. that includes a c++ module

I’d prefer these to not be identically named but rather be tagged with gnuradio 
versions,
so that I can compare the differences.  I’m working with vectors. 
This probably already exists, but it is not clear to me what is a good example.

ie I’d like:

git clone http://www.github.com/gnuradio/examplev38
cd examplev38
mkdir build
cd build
cmake ../
make -j 3 (for raspberry pi 4)
sudo make install
sudo ldconfig

then allow me to look at this code and compare it with vector
code in 3.7 and 3.9, so there would need to be

git clone http://www.github.com/gnuradio/examplev37

and 

git clone http://www.github.com/gnuradio/examplev39

These should do exactly the same thing in each of the gnuradio versions.
I’d be calling the same “examplev” block in a .grc file that would show that the
build was successful.   That is what our simple vmedian_impl.cc, vmedian_impl.h
and vectordemo_c2.grc code must do.  (in WVURAIL/gr-radio_astro)

It is just not easy to get from 3.7 to 3.8 or 3.9.   Our code is not tagged
by gnuradio version numbers, but this example code must be, so we can compare 
one
version to another (I hope we don’t need to go to sub-versions, ie 3.8.2 etc).

Again this must already exist somewhere.  I am completely perplexed by CMAKE and
XML/YAML and SWIG/PYBIND differences.

Thanks
Glen



> On Feb 3, 2021, at 6:17 PM, Gavin Jacobs  wrote:
> 
> Glen,
> I'm going through a pain similar to yours.
> For working examples, you can look at the source for the blocks that are part 
> of GNU Radio. For example, the Multiply Constant block shows how to do a 
> callback, and the Add block shows how to do variable number of inputs. 
> Unfortunately, these blocks also have the complexity of allowing Vector 
> inputs, and different types of inputs, so you have to dig through that to get 
> at the parts you want. 
> 
> The closest thing I found for a working OOT module, is documented here:
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_C%2B%2B
> It only applies to 3.7 & 3.8, so you still have to sleuth out the differences 
> for 3.9.  Also, it does not show how to do variable # of inputs, nor a 
> parameter callback. I'm working on a block that needs those; so as soon as I 
> have it sorted out, I'll put the sources on Github.
> Guided Tutorial GNU Radio in C++ - GNU Radio
> Note: the get_minimum_distances function declaration also needs to be added 
> to the class header (my_qpsk_demod_cb_impl.h).The function 
> get_minimum_distances is a maximum likelihood decoder for the QPSK 
> demodulater. Theoretically, the function should compute the distance from 
> each ideal QPSK symbol to the received symbol (It is mathematically 
> equivalent to determining the Voronoi regions of the ...
> wiki.gnuradio.org
> 
> 
> 
> Date: Tue, 2 Feb 2021 21:19:32 -0500
> From: Glen Langston 
> To: Marcus Müller 
> Cc: discuss-gnuradio@gnu.org
> Subject: Re: New Raspberry PI Complete OS release
> 
> I appreciate gr-modtool, but it is frustrating that modtool does not generate
> working code.   There really, really, really needs to be an ultra-simple 
> working
> example of C++ code for 3.8 and 3.9 that actually build.
> 
> The code could do anything, but just allow us to use it as the basis for
> creating YAML and SWIG/PYBIND code based on the new requirements.

Re: How to set variable number of inputs/outputs in Python OOT modules

[George Edwards]

Hi Jeff,

Thanks for your response!

If you can write a short code snippet to show me how to do this I would
appreciate it very much. For instance, I am making an OOT Python
Interpolator block which takes a number of inputs and I would like to be
able to set a parameter value to tell the block how many input ports are
needed. Currently, my design is static, in that if I want to run an
experiment with 4- complex input ports, then in a static manner, I set:

 in_sig = [numpy.complex64,  numpy.complex64,  numpy.complex64,
numpy.complex64]

The question is: how do I set "in_sig" in a non-static manner, so even if I
wanted 4 inputs, I would not need to explicitly write it out as above and
of course if I wanted 20 inputs, I just set a parameter to 20 and the grc
block will show 20 inputs for signal connection?

The followup question to this is, how do I set up the "yml" file
accordingly?

Thanks again for your help.

Regards,
George

On Wed, Feb 3, 2021 at 2:57 PM Jeff Long  wrote:

> `gr.io_signature()` in Python works exactly the same as it does in C++.
> The legacy Python way (list of types) is still used in most places, but you
> have the option.
>
> On Wed, Feb 3, 2021 at 3:17 PM George Edwards 
> wrote:
>
>> Hello,
>>
>> I wish to build an OOT module in Python which can take a variable number
>> of inputs and outputs. In C++ OOT, there are the io signatures <+min_in+>,
>> <+max_in+>, etc. which can be set to 1 and -1 to mean the input can be any
>> number. Python does not have these, it has the in_sig and out_sig which do
>> not offer the flexibility as the C++ OOT. How can I get a variable number
>> of inputs/outputs that is user defined in a Python OOT?
>>
>> Also, how do I set the parameters in yml file for variable inputs and
>> outputs?
>>
>> I will appreciate any help.
>>
>> Thank you!
>>
>> Regards,
>> George
>>
>

Re: How to set variable number of inputs/outputs in Python OOT modules

[George Edwards]

Hi Gavin,

Thanks for the information!

Does this mean that if I wanted 3 inputs and 5 outputs and all floating
point values, then inside the Python code, I simply set
 in_sig = [numpy.float32]
 out_sign = [numpy.float32]

And, in the yml file I set:
inputs:
-  domain:  stream
   dtype:  float
   multiplicity:  '3'

outputs:
-domain:  stream
 dtype:  float
 multiplicity:  '5'

Would this be correct?
Thanks again for your help!

Regards,
George

On Wed, Feb 3, 2021 at 5:26 PM Gavin Jacobs 
wrote:

> In 3.7, you would use the  tag, but in 3.8 the trick to setting
> multiple ins/outs in the YML file, is the keyword "multiplicity". You can
> see the details of how to configure here:
> https://wiki.gnuradio.org/index.php/YAML_GRC
>
> YAML GRC - GNU Radio 
> Starting with release 3.8, YAML replaces XML as the file format for GNU
> Radio Companion. This is triggered by switching from Cheetah to Mako as the
> templating engine, since Cheetah does not support Python 3.
> wiki.gnuradio.org
>
>