Re: [Discuss-gnuradio] [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Martin Braun]

On Wed, Feb 13, 2019 at 11:58:41AM -0800, Nick Foster wrote:
>Any plans to update to the latest API? Won't compile with anything after
>17.05.

UHD only works with DPDK 17.11. DPDK changes APIs quite often, so we've
decided to lock it down.

-- M
> 
>On Wed, Feb 13, 2019, 11:33 AM Michael West 
>wrote:
> 
>  Hi Nick,
>  Information on using DPDK can be found here: 
>  http://files.ettus.com/manual/page_dpdk.html
>  DPDK can be used with any example.  Think of it as an accelerator for
>  Ethernet transports if using Intel NICs.
>  Regards,
>  Michael
>  On Thu, Feb 7, 2019 at 10:29 AM Nick Foster 
>  wrote:
> 
>Great news! DPDK support is an interesting development. Is there any
>documentation or examples which show this capability?
>Nick
>On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
> wrote:
> 
>  The release candidate of UHD version 3.14.0.0 has been tagged and is
>  available for testing.  This API release introduces support for the
>  N320 and N321 USRPs soon to be released (watch for the announcement
>  on ettus.com!), a DPDK-based transport, and several other features
>  and bug fixes.  This release includes all bug fixes and
>  enhancements in the 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance
>  releases.
>  The tag for this release candidate:
>  https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> 
>  There have been 406 commits since the last API release (3.13.0.0)
>  which can be viewed here:
>  
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
>  Please report any bugs found on the UHD issue tracker:
>  http://github.com/EttusResearch/uhd/issues
>  * Please do not use the issue tracker for help or support.
>  Pull requests for direct code changes may be submitted to the UHD or
>  FPGA repositories:
>  http://github.com/EttusResearch/uhd/pulls
>  http://github.com/EttusResearch/fpga/pulls
>  CHANGELOG:
>  ## 003.014.000.000
>  * N320: Add N320 and N321
>  * Test: Add Python API test
>  * Device3: Move from packet-based to byte-based flow control
>  * X300: Reduce default send_frame_size to 4000 over Ethernet
>  * UHD: Release recv buffers earlier in rx_streamer
>  * Device3: Constrain send_buff_size to input fifo size
>  * X300: Change Ethernet buffering
>  * MPMD: Parallelize broadcast-finding
>  * Device: Parallelize device discovery
>  * Docs: Fix Doxygen warnings
>  * B100: Move fifo_ctrl_excelsior to b100 subdir
>  * B100: Fix fifo_ctrl_excelsior not exiting
>  * B100: Remove all Boostisms from fifo_ctrl_excelsior
>  * B100: Demote some clocking-related log messages to trace
>  * X300: Log git hash and compat number as debug message
>  * N310: Modify AD9371 reset function to keep it in reset
>  * N3xx: clocking API changes for transitioning clock and time
>  sources
>  * E320: bist: Fix ref_clock lock test implementation
>  * UHD: Fix ADF400x driver for ref counter and charge pump mode
>  * E320: bist: Add link_up test
>  * MPM: Get list of temperatures from all thermal zones
>  * E320: Add all 5 temp sensors, fan sensor and rssi sensors per
>  channel
>  * E320: Fix tx/rx atr - antenna and frequency settings
>  * E320: Enable devtest for E320
>  * X300: Move defaults to their own header
>  * UHD: Improve constrained_device_args_t
>  * X300: Use constrained_args
>  * X300: Enable clock_source and time_source device args
>  * Test: Integrate Python API Tester into Devtest
>  * N3xx: Bump max rev to G/6
>  * N3xx: Improve error messages for invalid clock/time settings
>  * E320: images: Separate images package for Aurora image
>  * B200: Remove superfluous fake lambda
>  * B200: Add support for user regs
>  * Docs: Add info on how to implement user regs on B200
>  * UHD API: Add multi_usrp::get_user_settings_iface()
>  * N310: move init_rf_cal before JESD de/framer bringup
>  * UHD: Remove usage of time_t (except when required)
>  * NIRIO: Demote RPC client cancel/abort to TRACE
>  * RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes
>  * Utils: Add Zip test to downloader
>  * Utils: Factor wait_for_lo_lock() out of cal utils
>  * DPDK: Add DPDK-based sockets-like library
>  * MPMD: add option to enum rfnoc blocks from args
>  * E320: Get RFNoC crossbar baseport from FPGA
>  * N3xx: Get RFNoC crossbar baseport from FPGA
>  * UHD: add default xport params to udp_zero_copy
>  * MPM: add 

[Discuss-gnuradio] GFSK + STREAM MUX working wrong

[Horký Petr]

Hello everyone,

I am creating signal with use of STREAM MUX. I want 128 samples of constant = 0 
and two bytes modulated with GFSK mod. 2 bytes and 8 samples/bit 2*8*8 = 
128.
(128, 128) these are the two values in the STREAM MUX.

https://ctrlv.cz/XR97

[https://ctrlv.cz/shots/2019/02/14/XR97.fb.png]

CtrlV.cz | Nejrychlejší ScreenShot a PrintScreen online
ctrlv.cz
CtrlV.cz nabízí nejrychlejší ScreenShot a PrintScreen online jen pomocí 
webového prohlížeče a to bez doplňků.

As you can see I modulate vector 255 and 0. Binary it is  .
But after quadrature demod (picture 2 - top graph). I get 0011 1100 as 
a result.

https://ctrlv.cz/9vgX


Do you have any idea what is wrong? And how to solve this problem?

Thank you.

Petr

[https://ctrlv.cz/shots/2019/02/14/9vgX.fb.png]

CtrlV.cz | Nejrychlejší ScreenShot a PrintScreen online
ctrlv.cz
CtrlV.cz nabízí nejrychlejší ScreenShot a PrintScreen online jen pomocí 
webového prohlížeče a to bez doplňků.






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

Re: [Discuss-gnuradio] Testers needed: Updated CMake syntax

[Andrej Rode]

Hi, 

On Thu, 14 Feb 2019 17:44:26 +0100
Volker Schroer  wrote:

> Hi,
> I tried [1] on Ubuntu 18.10 and it build without problems.
> Starting to build some of mine OOT's I found, that FindUSB.cmake is 
> missing. I think this was used to build gr-fcd which is not part of 
> gnuradio 3.8.

Thanks a lot for trying out! Indeed FindUSB has went away together with
the fcd component. I time allows it someone (maybe be) has time to pull
it into it's own module so at leaste the fcd support won't be lost.

> But that's no problem.
> Will the new cmake be part of gnuradio-3.8 ?

If all goes well I think so, it's not really on the features list of
the feature freeze, but still.
> 
> I'll keep on testing some more OOT's

Great, keep me/the list in the loop on any success or issues you
encounter.

Cheers
Andrej



pgp1ohh5F24fM.pgp
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nate Temple]

Hi Andre,

The one example I can give at this time is limited and semi-anecdotal as
I've only tested it on a single machine.

With an i7-4790k / Intel x520-DA2 and N310, to stream at full duplex, over
two channels at 125 MS/s, the lowest I can run my CPU clock freq at without
flow control errors is 3.8 GHz using benchmark_rate and the native
networking stack. Using DPDK I can run 2x2 @ 125 MS/s with my CPU freq
locked at 1.5 GHz with no flow control errors.

Regards,
Nate Temple

On Thu, Feb 14, 2019 at 3:57 AM Andre Puschmann <
andre.puschm...@tu-ilmenau.de> wrote:

> Hey guys,
>
> any idea or numbers on the performance improvement using DPDK, e.g. CPU
> usage during rx/tx streaming, when compared to the legacy approach?
> Would be great to get a feeling for the achievable gains.
>
> Thanks
> Andre
>
>
> On 13/2/19 20:58, Nick Foster via USRP-users wrote:
> > Any plans to update to the latest API? Won't compile with anything after
> > 17.05.
> >
> > On Wed, Feb 13, 2019, 11:33 AM Michael West
> >  > > wrote:
> >
> > Hi Nick,
> >
> > Information on using DPDK can be found here:
> > http://files.ettus.com/manual/page_dpdk.html
> >
> > DPDK can be used with any example.  Think of it as an accelerator
> > for Ethernet transports if using Intel NICs.
> >
> > Regards,
> > Michael
> >
> > On Thu, Feb 7, 2019 at 10:29 AM Nick Foster
> >  > > wrote:
> >
> > Great news! DPDK support is an interesting development. Is there
> > any documentation or examples which show this capability?
> >
> > Nick
> >
> >
> > On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
> >  > > wrote:
> >
> > The release candidate of UHD version 3.14.0.0 has been
> > tagged and is available for testing.  This API release
> > introduces support for the N320 and N321 USRPs soon to be
> > released (watch for the announcement on ettus.com
> > !), a DPDK-based transport, and several
> > other features and bug fixes.  This release includes all bug
> > fixes and enhancements in the 3.13.0.1, 3.13.0.2, and
> > 3.13.1.0 maintenance releases.
> >
> > The tag for this release candidate:
> >
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> >
> > There have been 406 commits since the last API release
> > (3.13.0.0)which can be viewed here:
> >
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
> >
> > Please report any bugs found on the UHD issue tracker:
> > http://github.com/EttusResearch/uhd/issues
> > * Please do not use the issue tracker for help or support.
> >
> > Pull requests for direct code changes may be submitted to
> > the UHD or FPGA repositories:
> > http://github.com/EttusResearch/uhd/pulls
> > http://github.com/EttusResearch/fpga/pulls
> >
> > CHANGELOG:
> > ## 003.014.000.000
> > * N320: Add N320 and N321
> > * Test: Add Python API test
> > * Device3: Move from packet-based to byte-based flow control
> > * X300: Reduce default send_frame_size to 4000 over Ethernet
> > * UHD: Release recv buffers earlier in rx_streamer
> > * Device3: Constrain send_buff_size to input fifo size
> > * X300: Change Ethernet buffering
> > * MPMD: Parallelize broadcast-finding
> > * Device: Parallelize device discovery
> > * Docs: Fix Doxygen warnings
> > * B100: Move fifo_ctrl_excelsior to b100 subdir
> > * B100: Fix fifo_ctrl_excelsior not exiting
> > * B100: Remove all Boostisms from fifo_ctrl_excelsior
> > * B100: Demote some clocking-related log messages to trace
> > * X300: Log git hash and compat number as debug message
> > * N310: Modify AD9371 reset function to keep it in reset
> > * N3xx: clocking API changes for transitioning clock and
> > time sources
> > * E320: bist: Fix ref_clock lock test implementation
> > * UHD: Fix ADF400x driver for ref counter and charge pump
> mode
> > * E320: bist: Add link_up test
> > * MPM: Get list of temperatures from all thermal zones
> > * E320: Add all 5 temp sensors, fan sensor and rssi sensors
> > per channel
> > * E320: Fix tx/rx atr - antenna and frequency settings
> > * E320: Enable devtest for E320
> > * X300: Move defaults to their own header
> > * UHD: Improve constrained_device_args_t
> > * X300: Use constrained_args
> > * X300: Enable clock_source and time_source device 

Re: [Discuss-gnuradio] Testers needed: Updated CMake syntax

[Volker Schroer]

Hi,
I tried [1] on Ubuntu 18.10 and it build without problems.
Starting to build some of mine OOT's I found, that FindUSB.cmake is 
missing. I think this was used to build gr-fcd which is not part of 
gnuradio 3.8.

But that's no problem.
Will the new cmake be part of gnuradio-3.8 ?

I'll keep on testing some more OOT's

-- Volker



Hi all,

in the last weeks I have been pursuing the quest of reworking the
current CMake build tooling in GNU Radio to use "modern CMake" syntax.
This work has mainly completed and now is the time to fix bugs you
encounter.

The work on the updated CMake can be found here
[0]/[1] and should compile just fine using the cmake & make/ninja
commands you are used to.
Support for static libraries might be still broken, but static linking
can be enabled using `-DBUILD_SHARED_LIBS=OFF` on the command line. No
shared library will be built using that flag.

Linking Out-of-Tree modules should be way easier using the new syntax
(but still old modules have to be updated). Mainly the `find_package`
call now follows the convention of specifying components in the
function call e.g. `find_package(Gnuradio COMPONENTS fft audio)`. After
the correct components are specified on in the `find_package` call the
corresponding build targets are available in your CMake project.  e.g.
you can `target_link_libraries(foo gnuradio::gnuradio-fft)`. Several
core build targets are always available (gnuradio::gnuradio-runtime,
gnuradio::gnuradio-pmt).

Instead of linking to all GNU Radio libraries in the
`target_link_libraries` call in `lib/CMakeLists.txt` now only the
targets needed should be linked with. An example for changes needed in
a OOT can be found at [2].
Mostly removing almost everything from `cmake/Modules` and removing a
lot of manual dependency finding from your own `CMakeLists.txt` is a
good step forward.
Necessary changes to `gr_modtool` have been incorporated to work with
the new CMake syntax.

If you encounter bugs or have suggestions for further improvements do
not hesitate to contact me through the pull request [0] or email. I'll
help with build problems updating your OOT as well.

Cheers
Andrej

[0] https://github.com/gnuradio/gnuradio/pull/2230
[1] https://github.com/noc0lour/gnuradio/tree/update_cmake
[2] https://github.com/noc0lour/gr-grnet/tree/3.8


___
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] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Andre Puschmann]

Hey guys,

any idea or numbers on the performance improvement using DPDK, e.g. CPU
usage during rx/tx streaming, when compared to the legacy approach?
Would be great to get a feeling for the achievable gains.

Thanks
Andre


On 13/2/19 20:58, Nick Foster via USRP-users wrote:
> Any plans to update to the latest API? Won't compile with anything after
> 17.05.
> 
> On Wed, Feb 13, 2019, 11:33 AM Michael West
>  > wrote:
> 
> Hi Nick,
> 
> Information on using DPDK can be found here: 
> http://files.ettus.com/manual/page_dpdk.html
> 
> DPDK can be used with any example.  Think of it as an accelerator
> for Ethernet transports if using Intel NICs.
> 
> Regards,
> Michael
> 
> On Thu, Feb 7, 2019 at 10:29 AM Nick Foster
>  > wrote:
> 
> Great news! DPDK support is an interesting development. Is there
> any documentation or examples which show this capability?
> 
> Nick
> 
> 
> On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
>  > wrote:
> 
> The release candidate of UHD version 3.14.0.0 has been
> tagged and is available for testing.  This API release
> introduces support for the N320 and N321 USRPs soon to be
> released (watch for the announcement on ettus.com
> !), a DPDK-based transport, and several
> other features and bug fixes.  This release includes all bug
> fixes and enhancements in the 3.13.0.1, 3.13.0.2, and
> 3.13.1.0 maintenance releases.
> 
> The tag for this release candidate:
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> 
> There have been 406 commits since the last API release
> (3.13.0.0)which can be viewed here:
> 
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
> 
> Please report any bugs found on the UHD issue tracker:
> http://github.com/EttusResearch/uhd/issues
> * Please do not use the issue tracker for help or support.
> 
> Pull requests for direct code changes may be submitted to
> the UHD or FPGA repositories:
> http://github.com/EttusResearch/uhd/pulls
> http://github.com/EttusResearch/fpga/pulls
> 
> CHANGELOG:
> ## 003.014.000.000
> * N320: Add N320 and N321
> * Test: Add Python API test
> * Device3: Move from packet-based to byte-based flow control
> * X300: Reduce default send_frame_size to 4000 over Ethernet
> * UHD: Release recv buffers earlier in rx_streamer
> * Device3: Constrain send_buff_size to input fifo size
> * X300: Change Ethernet buffering
> * MPMD: Parallelize broadcast-finding
> * Device: Parallelize device discovery
> * Docs: Fix Doxygen warnings
> * B100: Move fifo_ctrl_excelsior to b100 subdir
> * B100: Fix fifo_ctrl_excelsior not exiting
> * B100: Remove all Boostisms from fifo_ctrl_excelsior
> * B100: Demote some clocking-related log messages to trace
> * X300: Log git hash and compat number as debug message
> * N310: Modify AD9371 reset function to keep it in reset
> * N3xx: clocking API changes for transitioning clock and
> time sources
> * E320: bist: Fix ref_clock lock test implementation
> * UHD: Fix ADF400x driver for ref counter and charge pump mode
> * E320: bist: Add link_up test
> * MPM: Get list of temperatures from all thermal zones
> * E320: Add all 5 temp sensors, fan sensor and rssi sensors
> per channel
> * E320: Fix tx/rx atr - antenna and frequency settings
> * E320: Enable devtest for E320
> * X300: Move defaults to their own header
> * UHD: Improve constrained_device_args_t
> * X300: Use constrained_args
> * X300: Enable clock_source and time_source device args
> * Test: Integrate Python API Tester into Devtest
> * N3xx: Bump max rev to G/6
> * N3xx: Improve error messages for invalid clock/time settings
> * E320: images: Separate images package for Aurora image
> * B200: Remove superfluous fake lambda
> * B200: Add support for user regs
> * Docs: Add info on how to implement user regs on B200
> * UHD API: Add multi_usrp::get_user_settings_iface()
> * N310: move init_rf_cal before JESD de/framer bringup
> * UHD: Remove usage of time_t (except when required)
> * NIRIO: Demote RPC client cancel/abort to TRACE
> * RFNoC: Convert 

[Discuss-gnuradio] Testers needed: Updated CMake syntax

[Andrej Rode]

Hi all, 

in the last weeks I have been pursuing the quest of reworking the
current CMake build tooling in GNU Radio to use "modern CMake" syntax.
This work has mainly completed and now is the time to fix bugs you
encounter. 

The work on the updated CMake can be found here
[0]/[1] and should compile just fine using the cmake & make/ninja
commands you are used to. 
Support for static libraries might be still broken, but static linking
can be enabled using `-DBUILD_SHARED_LIBS=OFF` on the command line. No
shared library will be built using that flag.

Linking Out-of-Tree modules should be way easier using the new syntax
(but still old modules have to be updated). Mainly the `find_package`
call now follows the convention of specifying components in the
function call e.g. `find_package(Gnuradio COMPONENTS fft audio)`. After
the correct components are specified on in the `find_package` call the
corresponding build targets are available in your CMake project.  e.g.
you can `target_link_libraries(foo gnuradio::gnuradio-fft)`. Several
core build targets are always available (gnuradio::gnuradio-runtime,
gnuradio::gnuradio-pmt). 

Instead of linking to all GNU Radio libraries in the
`target_link_libraries` call in `lib/CMakeLists.txt` now only the
targets needed should be linked with. An example for changes needed in
a OOT can be found at [2].
Mostly removing almost everything from `cmake/Modules` and removing a
lot of manual dependency finding from your own `CMakeLists.txt` is a
good step forward.
Necessary changes to `gr_modtool` have been incorporated to work with
the new CMake syntax.

If you encounter bugs or have suggestions for further improvements do
not hesitate to contact me through the pull request [0] or email. I'll
help with build problems updating your OOT as well.

Cheers
Andrej 

[0] https://github.com/gnuradio/gnuradio/pull/2230
[1] https://github.com/noc0lour/gnuradio/tree/update_cmake
[2] https://github.com/noc0lour/gr-grnet/tree/3.8


pgpsMxtci1w0P.pgp
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "gnuradio challenges" (for learning GNU Radio)

[Jean-Michel FRIEDT]

if there can be any interest, I try to gradually go from basics (using
GNU Radio to introduce such topics as decimating, aliasing and the need
for low pass filtering) to more applied topics (of course FM radio  
demodulation,

then POCSAG) and BPSK demodulation (Costas loop) and finally multichannel
analysis (Xlating FIR) in my lab sessions at
http://jmfriedt.free.fr/tp_sdr_eng.pdf
(or for the French speaking part of Belgium,  
http://jmfriedt.free.fr/tp_sdr.pdf)


More challenging signal demodulations such as GPS and RDS are discussed
separately (eg http://jmfriedt.free.fr/lm_rds_eng.pdf &
http://jmfriedt.free.fr/sdr_gps_eng.pdf)

JM


Hi all,


After the GNU Radio workshop at hsbxl two weeks ago, a number of  
people of the Belgian amateur-radio community who where at the  
workshop have shown interest in continuing to learn more about GNU  
Radio.


However, one of the main issues we have noticed that we kind-of lack  
a good "application" to use GNU Radio for, and -as we all known- you  
only learn something by using it.



So, based on the idea used in cybersecurity training, I would like  
to see if it not possible to create a number of "GNU Radio  
challenges", either decoding radio-signals or creating an encoder  
that produces a desired signal.



I know Ben Hilburn created the challenge (found on the GNU Radio  
website) but that one is way above what most people are able to  
decode (let alone people just starting out with GNU Radio).
Again, looking at the cybersecurity-scene: If you look at a website  
like "root me" (https://www.root-me.org/?lang=en), it provides a  
number of challenges with an increasing degree of difficulty, which  
allow people to build up their skills step by step. And -as I see  
it- this "step by step" approach is the most important element in a  
educational project.


So, does anybody know if there are, or is anybody interested to help  
create, more GNU Radio challenges that can be used for an  
educational purpose, to provide people with a "learning path" to  
really start to learn and use GNU Radio?


Are there people who use GNU Radio as part of teaching  
radio-communication? What topics do you teach and in what order? How  
do you get the students to understand radio-communication and GNU  
Radio?


Cheerio! Kr. Bonne.



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





--
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] "gnuradio challenges" (for learning GNU Radio)

[Kristoff]

Hi all,


After the GNU Radio workshop at hsbxl two weeks ago, a number of people 
of the Belgian amateur-radio community who where at the workshop have 
shown interest in continuing to learn more about GNU Radio.


However, one of the main issues we have noticed that we kind-of lack a 
good "application" to use GNU Radio for, and -as we all known- you only 
learn something by using it.



So, based on the idea used in cybersecurity training, I would like to 
see if it not possible to create a number of "GNU Radio challenges", 
either decoding radio-signals or creating an encoder that produces a 
desired signal.



I know Ben Hilburn created the challenge (found on the GNU Radio 
website) but that one is way above what most people are able to decode 
(let alone people just starting out with GNU Radio).
Again, looking at the cybersecurity-scene: If you look at a website like 
"root me" (https://www.root-me.org/?lang=en), it provides a number of 
challenges with an increasing degree of difficulty, which allow people 
to build up their skills step by step. And -as I see it- this "step by 
step" approach is the most important element in a educational project.


So, does anybody know if there are, or is anybody interested to help 
create, more GNU Radio challenges that can be used for an educational 
purpose, to provide people with a "learning path" to really start to 
learn and use GNU Radio?


Are there people who use GNU Radio as part of teaching 
radio-communication? What topics do you teach and in what order? How do 
you get the students to understand radio-communication and GNU Radio?


Cheerio! Kr. Bonne.



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