[Discuss-gnuradio] libvolk NEON support progress update

[Albin Stigö]

Hi,

Just a quick progress update. I have completed NEON support for 34 out
of 74 libvolk kernels that were missing NEON implementations.

Average speedup is around 4x depending on kernel, not very surprising
since NEON SIMD vector size for float32 is 4...

Biggest surprise was volk_32fc_s32fc_x2_rotator_32fc that now is 14x
faster on Raspberry Pi 3b. This is nice because this kernel is used in
the frequently used (pun intended) Frequency Xlating FIR Filter.

https://github.com/gnuradio/volk/issues/243

So far kernels are only available in my (messy) branch but I will
gradually create pull requests into libvolk.


--Albin

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

Re: [Discuss-gnuradio] Getting "Environment Error" when trying to use USRP X310

[Marcus D. Leech]

On 05/07/2019 02:23 AM, Jose Ruvalcaba wrote:

Hello,

I recently installed GNU Radio 3.7.13.4 with UHD 3.14 ,using PyBOMBS, 
and tried to use my X310 radio with it. It asked me to update its FPGA 
image, and after updating it, I began to see an error whenever I tried 
using the USRP sink and source block In GNU Radio. The error reads:


/Executing: /usr/bin/python2 -u 
/home/satrnground/Downloads/simple_xponder.py//
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0; Boost_106501; 
UHD_3.14.0.0-110-g6af6ac32

[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz*
[31;0m[ERROR] [UHD] [39;0mException caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with 
uhd::endianness_t _endianness = (uhd::endianness_t)0]

  at /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block 
ctrl (CE_00_Port_30) no response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) 
[with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = 
long unsigned int]

  at /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155*/
/*
*/
Note that I am NOT trying to use RFNOC, which I think this issue is 
related too, I am just trying to use the x310 with regular USRP blocks 
in GNU radio.If it helps to know, I am running UBuntu 18.04 and the 
FPGA image I downloaded on my X310 was the default HG one. Can anyone 
shine some light into how to get rid of this issue?


Thanks,
Jose R


What sample rate are you using?  Do you happen to know what type of 
Ethernet controller your PC has?



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

Re: [Discuss-gnuradio] libvolk NEON support progress update

[Martin Braun]

Very cool! Looking forward to your PR!

On Tue, May 7, 2019 at 7:04 AM Albin Stigö  wrote:

> Hi,
>
> Just a quick progress update. I have completed NEON support for 34 out
> of 74 libvolk kernels that were missing NEON implementations.
>
> Average speedup is around 4x depending on kernel, not very surprising
> since NEON SIMD vector size for float32 is 4...
>
> Biggest surprise was volk_32fc_s32fc_x2_rotator_32fc that now is 14x
> faster on Raspberry Pi 3b. This is nice because this kernel is used in
> the frequently used (pun intended) Frequency Xlating FIR Filter.
>
> https://github.com/gnuradio/volk/issues/243
>
> So far kernels are only available in my (messy) branch but I will
> gradually create pull requests into libvolk.
>
>
> --Albin
>
> ___
> 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 "Environment Error" when trying to use USRP X310

[Jose Ruvalcaba]

Hi Marcus,

I was using a 1 Msps sample rate in my flowgraph. As for the Ethernet
controller, I was currently using my standard 1 GigE Ethernet port on my
PC, however, this issue also shows up when using a 10GigE connection. If it
helps, the 10 GigE Ethernet card I have is the desktop card sold by Ettus
Research.

Thanks,
Jose

On Tue, May 7, 2019 at 8:07 AM Marcus D. Leech 
wrote:

> On 05/07/2019 02:23 AM, Jose Ruvalcaba wrote:
>
> Hello,
>
> I recently installed GNU Radio 3.7.13.4 with UHD 3.14 ,using PyBOMBS, and
> tried to use my X310 radio with it. It asked me to update its FPGA image,
> and after updating it, I began to see an error whenever I tried using the
> USRP sink and source block In GNU Radio. The error reads:
>
> *Executing: /usr/bin/python2 -u
> /home/satrnground/Downloads/simple_xponder.py*
>
>
>
>
>
>
>
>
>
> * [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.14.0.0-110-g6af6ac32 [32;1m[INFO] [X300] [39;0mX300 initialization
> sequence... [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
> [32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz [31;0m[ERROR] [UHD]
> [39;0mException caught in safe-call.   in
> ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with uhd::endianness_t
> _endianness = (uhd::endianness_t)0]   at
> /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_00_Port_30) no response packet - AssertionError: bool(buff)   in
> uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long
> unsigned int]   at
> /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155*
>
> Note that I am NOT trying to use RFNOC, which I think this issue is
> related too, I am just trying to use the x310 with regular USRP blocks in
> GNU radio.If it helps to know, I am running UBuntu 18.04 and the FPGA image
> I downloaded on my X310 was the default HG one. Can anyone shine some light
> into how to get rid of this issue?
>
> Thanks,
> Jose R
>
>
> What sample rate are you using?  Do you happen to know what type of
> Ethernet controller your PC has?
>
>
> ___
> 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 "Environment Error" when trying to use USRP X310

[Marcus D Leech]

If you use one of the test tools like uhd_fft or any of the purely UHD tools do 
you see the same issue?

Sent from my iPhone

> On May 7, 2019, at 1:14 PM, Jose Ruvalcaba  wrote:
> 
> Hi Marcus,
> 
> I was using a 1 Msps sample rate in my flowgraph. As for the Ethernet 
> controller, I was currently using my standard 1 GigE Ethernet port on my PC, 
> however, this issue also shows up when using a 10GigE connection. If it 
> helps, the 10 GigE Ethernet card I have is the desktop card sold by Ettus 
> Research.
> 
> Thanks,
> Jose
> 
>> On Tue, May 7, 2019 at 8:07 AM Marcus D. Leech  
>> wrote:
>>> On 05/07/2019 02:23 AM, Jose Ruvalcaba wrote:
>>> Hello,
>>> 
>>> I recently installed GNU Radio 3.7.13.4 with UHD 3.14 ,using PyBOMBS, and 
>>> tried to use my X310 radio with it. It asked me to update its FPGA image, 
>>> and after updating it, I began to see an error whenever I tried using the 
>>> USRP sink and source block In GNU Radio. The error reads: 
>>> 
>>> Executing: /usr/bin/python2 -u /home/satrnground/Downloads/simple_xponder.py
>>> [32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0; Boost_106501; 
>>> UHD_3.14.0.0-110-g6af6ac32
>>> [32;1m[INFO] [X300] [39;0mX300 initialization sequence...
>>> [32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
>>> [32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz
>>> [31;0m[ERROR] [UHD] [39;0mException caught in safe-call.
>>>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with 
>>> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>>>   at /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
>>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl 
>>> (CE_00_Port_30) no response packet - AssertionError: bool(buff)
>>>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) 
>>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0; uint64_t = long 
>>> unsigned int]
>>>   at /home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>>> 
>>> Note that I am NOT trying to use RFNOC, which I think this issue is related 
>>> too, I am just trying to use the x310 with regular USRP blocks in GNU 
>>> radio.If it helps to know, I am running UBuntu 18.04 and the FPGA image I 
>>> downloaded on my X310 was the default HG one. Can anyone shine some light 
>>> into how to get rid of this issue?
>>> 
>>> Thanks,
>>> Jose R
>>> 
>>> 
>> What sample rate are you using?  Do you happen to know what type of Ethernet 
>> controller your PC has?
>> 
>> 
>> ___
>> 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] [GSoC19] Accepted student projects announced!

[Wunsch, Felix (CEL)]

Hi all,


Google has announced the accepted student projects for GSoC 2019: Arpit Gupta 
and Bowen Hu will be contributing to GNU Radio during the summer - 
congratulations to both of them! Arpit will work on a tool for parsing GNU 
Radio header files to create YAML descriptions that can be used for GRC. His 
mentors are Nicolas Cuervo and Sebastian Koslowski. Marcus Müller will support 
Bowen who will work on cycle-accurate simulation of Verilog code.


Both are exciting projects that will bring new functionality to GNU Radio. 
Bowen and Arpit will keep you up-to-date about their progress in weekly blog 
posts. Expect the first posts later this week. Please welcome them in the 
community and give them feedback!


Arpit and Bowen, we are really happy to work with you and we are looking 
forward to seeing your contributions!


To all students who unfortunately could not be selected: Thank you for applying 
to GNU Radio and please try again next year! :)


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

Re: [Discuss-gnuradio] Getting "Environment Error" when trying to use USRP X310

[Marcus D. Leech]

On 05/07/2019 02:30 PM, Jose Ruvalcaba wrote:
Yes I do. However, I've noticed that when I reboot the radio, the 
issue does not appear. However, after I switch to another flowgraph, 
the issue shows up and I need to reboot the radio again. I've attached 
a screenshot of the issue after trying the test tools in case it helps.
Ah, OK.  So, you stop a flow-graph, which apparently leaves the USRP in 
a weird state, and then when you run a "fresh" graph, it produces

  this error?

Is it possible for you to try the current UHD master, rather than the 
3.14 tagged release?





On Tue, May 7, 2019 at 10:41 AM Marcus D Leech 
mailto:patchvonbr...@gmail.com>> wrote:


If you use one of the test tools like uhd_fft or any of the purely
UHD tools do you see the same issue?

Sent from my iPhone

On May 7, 2019, at 1:14 PM, Jose Ruvalcaba mailto:joruv...@gmail.com>> wrote:


Hi Marcus,

I was using a 1 Msps sample rate in my flowgraph. As for the
Ethernet controller, I was currently using my standard 1 GigE
Ethernet port on my PC, however, this issue also shows up when
using a 10GigE connection. If it helps, the 10 GigE Ethernet card
I have is the desktop card sold by Ettus Research.

Thanks,
Jose

On Tue, May 7, 2019 at 8:07 AM Marcus D. Leech
mailto:patchvonbr...@gmail.com>> wrote:

On 05/07/2019 02:23 AM, Jose Ruvalcaba wrote:

Hello,

I recently installed GNU Radio 3.7.13.4 with UHD 3.14 ,using
PyBOMBS, and tried to use my X310 radio with it. It asked me
to update its FPGA image, and after updating it, I began to
see an error whenever I tried using the USRP sink and source
block In GNU Radio. The error reads:

/Executing: /usr/bin/python2 -u
/home/satrnground/Downloads/simple_xponder.py//
[32;1m[INFO] [UHD] [39;0mlinux; GNU C++ version 7.3.0;
Boost_106501; UHD_3.14.0.0-110-g6af6ac32
[32;1m[INFO] [X300] [39;0mX300 initialization sequence...
[32;1m[INFO] [X300] [39;0mMaximum frame size: 1472 bytes.
[32;1m[INFO] [X300] [39;0mRadio 1x clock: 200 MHz*
[31;0m[ERROR] [UHD] [39;0mException caught in safe-call.
  in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
uhd::endianness_t _endianness = (uhd::endianness_t)0]
  at
/home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60
this->send_cmd_pkt(0, 0, true); -> EnvironmentError:
IOError: Block ctrl (CE_00_Port_30) no response packet -
AssertionError: bool(buff)
  in uint64_t
ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
[with uhd::endianness_t _endianness = (uhd::endianness_t)0;
uint64_t = long unsigned int]
  at
/home/satrnground/prefix/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155*/
/*
*/
Note that I am NOT trying to use RFNOC, which I think this
issue is related too, I am just trying to use the x310 with
regular USRP blocks in GNU radio.If it helps to know, I am
running UBuntu 18.04 and the FPGA image I downloaded on my
X310 was the default HG one. Can anyone shine some light
into how to get rid of this issue?

Thanks,
Jose R



What sample rate are you using?  Do you happen to know what
type of Ethernet controller your PC has?


___
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] [GSoC19] Accepted student projects announced!

[Ben Hilburn]

Congratulations, Arpit and Bowen! I look forward to tracking your
development this Summer and working with you in the community!

Cheers,
Ben

On Tue, May 7, 2019 at 2:27 PM Wunsch, Felix (CEL) 
wrote:

> Hi all,
>
>
> Google has announced the accepted student projects for GSoC 2019: Arpit
> Gupta and Bowen Hu will be contributing to GNU Radio during the summer
> - congratulations to both of them! Arpit will work on a tool for parsing
> GNU Radio header files to create YAML descriptions that can be used for
> GRC. His mentors are Nicolas Cuervo and Sebastian Koslowski. Marcus Müller
> will support Bowen who will work on cycle-accurate simulation of Verilog
> code.
>
>
> Both are exciting projects that will bring new functionality to GNU Radio.
> Bowen and Arpit will keep you up-to-date about their progress in weekly
> blog posts. Expect the first posts later this week. Please welcome them in
> the community and give them feedback!
>
>
> Arpit and Bowen, we are really happy to work with you and we are looking
> forward to seeing your contributions!
>
>
> To all students who unfortunately could not be selected: Thank you for
> applying to GNU Radio and please try again next year! :)
>
>
> Cheers,
> Felix
> ___
> 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] libvolk NEON support progress update

[Ben Hilburn]

This really is great work, Albin! Thanks so much for sharing your work and
keeping the community posted on your progress!

And wow, the speedup on the rotator is impressive. I'm really looking
forward to your work getting upstreamed =)

Cheers,
Ben

On Tue, May 7, 2019 at 12:50 PM Martin Braun  wrote:

> Very cool! Looking forward to your PR!
>
> On Tue, May 7, 2019 at 7:04 AM Albin Stigö  wrote:
>
>> Hi,
>>
>> Just a quick progress update. I have completed NEON support for 34 out
>> of 74 libvolk kernels that were missing NEON implementations.
>>
>> Average speedup is around 4x depending on kernel, not very surprising
>> since NEON SIMD vector size for float32 is 4...
>>
>> Biggest surprise was volk_32fc_s32fc_x2_rotator_32fc that now is 14x
>> faster on Raspberry Pi 3b. This is nice because this kernel is used in
>> the frequently used (pun intended) Frequency Xlating FIR Filter.
>>
>> https://github.com/gnuradio/volk/issues/243
>>
>> So far kernels are only available in my (messy) branch but I will
>> gradually create pull requests into libvolk.
>>
>>
>> --Albin
>>
>> ___
>> 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] New/Updated GPredict Interfacing Blocks

[Ben Hilburn]

Congrats on the awesome work, Mike! This is really cool. The auto trigger &
close for file recordings is a nice touch.

You know this could be part of a pretty awesome GRCon talk ;)

Cheers,
Ben





On Mon, May 6, 2019 at 9:17 PM GhostOp14  wrote:

> Hi everyone,
>
> I've been doing a good bit of satellite work and had the need to blow the
> dust off of a discontinued gr-gpredict-doppler  OOT module and enhance it.
> The goal was to have a state value to pass in and key off of gpredict's
> perspective of if the satellite was visible or not for recording purposes
> (better yet preventing huge blind-saving files), and to better pass the
> doppler frequency through to GNURadio.  So I've forked it (
> https://github.com/ghostop14/gr-gpredict-doppler.git)  and added a bunch
> of new features:
>
> doppler block:
>   -  Now adds freq output block to make it compatible with other message
> blocks like the USRP source
> - Now supports AOS / LOS commands from gpredict - a state output message
> block compatible with all of the state inputs in the gr-filerepeater block
> is also produced.  Result: A file record can be triggered to start when a
> satellite is in range, then automatically closed when it goes out of range.
>  -  Enhanced the gqrx / gpredict radio control command handling to handle
> additional messages and correctly handle exit
>
> [new] rotor block:
>   - Accepts inputs from  rotctl / gpredict's rotor control.
>   - Az/El are passed in, interpreted, and packed in an output message with
> 'az' and 'el' meta keys
>   - A basic minimum elevation is added to the block where if the elevation
> is > min, an optional state output is produced (1= >= min, 0 is below
> min).  Again this can be used with the gr-filerepeater adv sink
>
> [new] az el limit block:
>   - Allows az/el min/max values to be set.  If the rotor block output
> az_el is fed into this block, an output state message is produced for
> "inside the az/el limits" / outside the az/el limits.  Again, this can
> interface with the file blocks
>
> gr-filerepeater (https://github.com/ghostop14/gr-filerepeater.git) has
> also gotten a lot of enhancements to help with controlling unsupervised
> file writes.  The concept of this state 1/0 has worked its way through for
> easy file write control.  The file sink can also now extract/save
> message-based data in exactly the same way streaming data was handled.
>
> Anyway let me know if there's any other enhancement requests or if you run
> into any new issues.
>
> Enjoy!
>
> ___
> 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] Software Defined Radio Academy: Programme is ready

[Ben Hilburn]

That's quite the program, Markus! I can't make the event, but I'm really
looking forward to the recordings!

Cheers,
Ben

On Thu, May 2, 2019 at 6:58 PM Markus Heller  wrote:

> Dear community,
>
> please see our programme web site.
>
> The programme of the Software Defined Radio Academy 2019 on June 22 in
> Friedrichshafen is ready:
>
> http://2019.sdra.io/pages/programme.html
>
> Please note that we are looking forward to a distinguished talk from
> Nobel Price winner and radio astronomer Prof. Dr. Joe H. Taylor K1JT
> around 1300 hrs. Title yet to be announced.
>
> Besides that, this year's SDRA has a focus on space-related topics. We
> will be enthusiastic to listen to talks from Alex Csete OZ9AEC and his
> colleagues Sheila Christiansen, Manolis Surligas SV9SFC, Pierros
> Papadeas, on SDR Makerspace, Mario Lorenz DL5MLO from AMSAT on the new
> geo-stationary QC-100 Amateur Radio satellite and Carles Fernandez on
> Open Source GNSS systems.
>
> We will also listen to talks about the Charly25 RedPitaya based
> transceiver, and on latest developments from FLEXRADIO.
>
> And we'll listen to Christoph Mayer DL1CH on KiwiSDR as a new GNURadio
> source, and Prof. Dr. Michael Hartje DK5HH on how to measure the
> development of background noise levels in Germany.
>
> Since we're celebrating our SDRA's fifth anniversary this year, we'll
> have a short key note by the President of the German Amateur Radio Club
> DARC, Christian Entsfellner DL3MBG.
>
>
> We will inform you on this list a couple of days before about recent
> developments and how to join us through our Youtube live stream. As in
> past years, all talks will be recorded and made available on our
> channel: http://youtube.sdra.io
>
> Please feel invited to attend in person or online. If you have
> questions, please feel free to ask. Please feel free to share our
> programme.
>
> BR / vy73
> Markus
> DL8RDS
>
>
> ___
> 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] FEC Examples with Modulators

[Ben Hilburn]

Hi Alex -

Have you tried any of the examples in gr-fec/examples? If so and they
didn't work for you, what issues have you encountered?

Cheers,
Ben

On Sat, May 4, 2019 at 9:20 PM Alex Roberts  wrote:

> Hello GNURadio Users,
>
> I'm learning about convolutional encoders in school and would like to
> demonstrate their use in gnuradio for a presentation. The examples
> appear useful for showing BER and Encoding -> decodng, but I'm
> struggling to implement a signal chain
>
> tx_bytes --> unpacked to packed -> FEC_ENCODE -> modulation -> AWGN
> channel -> demod -> FEC_DECODE -> received_bytes
>
> I'm not sure where to put the fec_decode on receiver side or how the
> bytes need to packed to use it. Are there some tutorials or examples
> that FEC with tx to rx (either w/ hardware or loopback)?
>
> Thanks
> Alex.
>
> ___
> 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 get precise time tag from blocks_meta_data_sink

[Ben Hilburn]

Hi Ziang -

I'm not sure I completely follow your system set-up, so I'm not sure how to
answer all of your questions, exactly. There are almost certainly a couple
of things at play here, including the source of your time (is it on the
radio? your PC?), and the data representation of the time tag itself.

The `rx_time` field of the file meta sink block uses UHD's tuple
representation for time, with an integer number of full seconds and then a
fractional second component. See more here:
https://github.com/EttusResearch/uhd/blob/master/host/lib/types/time_spec.cpp

So, concatenating them as `full.frac seconds` is correct, but it's
important to keep in mind the limitations of data representation in terms
of the fractional portion. Having 20 digits of "value" in your float
doesn't mean they are significant - you need to be aware of the limitations
and accuracy of your hardware to whatever degree it matters in your
application.

Does that help?

Cheers,
Ben

On Tue, Apr 30, 2019 at 4:13 PM Ziang Gao 
wrote:

> Hi,
>
> I'm trying to use blocks_file_meta_sink to record data with tags, and then
> use gr_read_file_metadata.py to read .hdr file, and I got this output:
> " " "
> HEADER 30
> Version Number: 0
> Sample Rate: 2000.00 sps
> Seconds: 1556652948.179670
> Item size: 8
> Data Type: float (5)
> Complex? True
> Header Length: 171 bytes
> Extra Length:  22
> Extra Header?  True
> Size of Data: 800 bytes
>   100 items
>
> Extra Header:
> rx_freq: 2.4205e+09
> " " "
> It looks like the time in seconds only has 6 floating points, however, it
> supposes to be double.
> I thought it was caused by string formatting so I went to
> parse_file_metadata.py and modified line 94 from "print "Seconds:
> {0:6f}".format(t)" to "print "Seconds: {0:20f}".format(t)", then I got:
> " " "
> Seconds: 1556652948.17966961860656738281
> " " "
> Is this the correct way to solve this problem? Is GNUradio's time tag
> actually precise to nanosecond? I want to use a PC with GPS time module and
> sync a B200mini with it, can I actually get the correct GPS time tag in
> this way?
>
>  Thanks
>
> Best regards,
> Ziang
> ___
> 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] Question on PMT boolean messages

[Ben Hilburn]

Excellent! So glad you got it working, Ali, and thanks for sharing the
solution to your issue!

Cheers,
Ben

On Wed, May 1, 2019 at 3:45 PM Ali Dormiani  wrote:

> I figured this out today. I used a handle_msg and simply connected a
> message strobe to the 'junk' msg input. My custom block works as expected
> now.
>
> On Tue, Apr 30, 2019 at 12:56 PM Ali Dormiani 
> wrote:
>
>> Hello,
>>
>> Thank you for the advice. I went back to the tutorials and now I have a
>> better grasp of what is going on.
>>
>> Regarding 'work' vs 'handle_msg', which situations fit each of these?
>>
>> Is 'handle_msg' supposed to be for passing messages through multiple
>> internal msg ports?
>>
>> Is 'work' for dealing with streams or can I do message related things in
>> 'work'?
>>
>> It appears that handle_msg is for passing from inputs to outputs (which I
>> do not need as I want a block with only a message out).
>>
>>
>> In short, if one wants to make a block with a single msg output and
>> nothing else, should s/he use a message handler (and leave work empty with
>> a pass) or use work? If so, what should work return, given there are no
>> data-streams involved?
>>
>> Thank you for your time,
>>
>> Ali
>>
>> On Mon, Apr 29, 2019 at 2:49 PM Marcus Müller 
>> wrote:
>>
>>> Hi Ali,
>>> causality, our old foe, strikes again!
>>>
>>> You're trying to emit a message in the constructor.  Messages will be
>>> delivered to all message acceptors connected to that message port.
>>> However, you can't possibly connect the block before the block-holding
>>> object exists, i.e. before the constructor returns.
>>>
>>> So, necessarily, the messages are sent before anything is connected to
>>> the msg_out port, and thus into the void and simply get dropped by the
>>> scheduler.
>>>
>>> Best regards,
>>> Marcus
>>>
>>> PS: I'd strongly recommend having a `self.port = pmt.intern('msg_out')`
>>> in the constructor and using that whenever you need the port if you're
>>> doing that within the work() function often. Constructing PMT interns
>>> is relatively expensive.
>>>
>>> On Mon, 2019-04-29 at 14:39 -0700, Ali Dormiani wrote:
>>> > Hello everyone,
>>> >
>>> > I have been attempting to make my own block that sends out a boolean
>>> > message if certain time related conditions are met.
>>> >
>>> > I am unable to figure out why my block does not work. This seems to
>>> > be the line of interest:
>>> >
>>> > self.message_port_pub(pmt.intern('msg_out'), pmt.PMT_T)
>>> >
>>> > This line should cause the block to output a PMT true through port
>>> > msg_out right?
>>> >
>>> > My full block is attached bellow. Any help would be greatly
>>> > appreciated.
>>> >
>>> > Thank you all for your time,
>>> >
>>> > Ali
>>> >
>>> > ==
>>> > import numpy as np
>>> > from gnuradio import gr
>>> > import pmt
>>> > import datetime
>>> >
>>> > class msg_block(gr.basic_block):  # other base classes are
>>> > basic_block, decim_block, interp_block
>>> > """This block checks time and sends true or false if capture
>>> > period is desired"""
>>> >
>>> > def __init__(self, minutes=15, seconds=10):  # only default
>>> > arguments here
>>> > """arguments to this function show up as parameters in GRC"""
>>> > gr.basic_block.__init__(
>>> > self,
>>> > name='Time Enable',   # will show up in GRC
>>> > in_sig=None,
>>> > out_sig=None
>>> > )
>>> > self.message_port_register_out(pmt.intern('msg_out'))
>>> > now = datetime.datetime.now()
>>> > #P_true = pmt.PMT_T
>>> > #P_false = pmt.PMT_F
>>> > if ((now.minute % minutes) == 0): #check if minute is ok
>>> > if (now.second < seconds): #check if capture period is ok
>>> > self.message_port_pub(pmt.intern('msg_out'),
>>> > pmt.PMT_T)
>>> > else:
>>> > self.message_port_pub(pmt.intern('msg_out'),
>>> > pmt.PMT_F)
>>> > else:
>>> > self.message_port_pub(pmt.intern('msg_out'), pmt.PMT_F)
>>> >
>>> > def work(self, input_items, output_items):
>>> > pass
>>> > =
>>> > ___
>>> > 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] Data loss during transmission (OFDM .bmp file)

[Ben Hilburn]

Hey Simran -

All of this is to say that your communications system design does not
appear to be robust to the impairments and complexities of wireless
channels, some of which Marcus mentioned. Can you share what your specific
goal is or why you're undertaking this work? Depending on what you are
trying to achieve, you might not need something quite so complex.

Cheers,
Ben



On Sun, May 5, 2019 at 2:11 PM Kevin McQuiggin  wrote:

> Read, read read!  Simple questions often lead to very complex answers.
>
> You might start your studies with "The Scientist & Engineer's Guide to
> Digital Signal Processing” by S. Smith.
>
> Kevin
>
> > On May 5, 2019, at 9:46 AM, Marcus Müller 
> wrote:
> >
> > Well, noise happens, and synchronization isn't instantaneous. Things
> > that aren't detected can't be received, and bit errors that the FEC
> > can't correct are bit errors in the received data.
> >
> > That's the beauty and the curse of wireless communications.
> >
> > Best regards,
> > Marcus
> >
> > On Sat, 2019-05-04 at 20:26 -0400, Simran Kaur wrote:
> >> Hello All,
> >> We are trying to transmit a .bmp file using USRP Tx/Rx. However, I am
> >> getting bogus header data at the receiving end. I tried transmitting
> >> a text file also which clips my starting text and also it inserts
> >> some invalid/unknown characters. We are losing some of the bytes for
> >> e.g, the transmitted file size is of 426316 bytes, but receiving file
> >> size is of 4,264,224 bytes.
> >> Can somebody explain what we are doing wrong here. I have attached my
> >> Tx and Rx .grc and snapshots for the reference.
> >>
> >> Best,
> >> Simran Kaur
> >> ___
> >> 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] [GSoC19] Accepted student projects announced!

[Arpit Gupta]

Hi everyone,

I am really excited about doing some awesome work with GNU Radio this
summer and I hope that my work will be a nice extension to the GNU Radio
project.

I'll be posting weekly blogs about the current state of my project and will
also remain in frequent touch with the mentors throughout the program.

Congratulations Bowen for selection in GSoC. I wish you all the best for
your project.

Thank you, everyone, for your constant support throughout the selection
procedure.

Regards,
Arpit Gupta
Indian Institute of Technology Roorkee

On Wed, May 8, 2019 at 12:46 AM Ben Hilburn  wrote:

> Congratulations, Arpit and Bowen! I look forward to tracking your
> development this Summer and working with you in the community!
>
> Cheers,
> Ben
>
> On Tue, May 7, 2019 at 2:27 PM Wunsch, Felix (CEL) 
> wrote:
>
>> Hi all,
>>
>>
>> Google has announced the accepted student projects for GSoC 2019: Arpit
>> Gupta and Bowen Hu will be contributing to GNU Radio during the summer
>> - congratulations to both of them! Arpit will work on a tool for parsing
>> GNU Radio header files to create YAML descriptions that can be used for
>> GRC. His mentors are Nicolas Cuervo and Sebastian Koslowski. Marcus Müller
>> will support Bowen who will work on cycle-accurate simulation of Verilog
>> code.
>>
>>
>> Both are exciting projects that will bring new functionality to GNU
>> Radio. Bowen and Arpit will keep you up-to-date about their progress in
>> weekly blog posts. Expect the first posts later this week. Please welcome
>> them in the community and give them feedback!
>>
>>
>> Arpit and Bowen, we are really happy to work with you and we are looking
>> forward to seeing your contributions!
>>
>>
>> To all students who unfortunately could not be selected: Thank you for
>> applying to GNU Radio and please try again next year! :)
>>
>>
>> Cheers,
>> Felix
>> ___
>> 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] Audio source cannot use 2 outputs (Stereo) in windows

[Ben Hilburn]

Sounds like you got your issue resolved, Gary? This one was a doozy to
follow, and I'm glad you got it sorted.

And thanks to Marcus for helping sort through it!

Cheers,
Ben

On Mon, May 6, 2019 at 7:17 AM Gary.Simpkins 
wrote:

> Hi Marcus.
>
> It was late last night and I missed the errors in the
> grnradio-config-info -- prefsdir response.
>
> It had the dirs twice. So I changed the Prefix in windows to be just
> GNUradio-3.7, and the tried again.
>
> The prefs now has details includng portaudio.
>
> When I start gnuradio companion  I now see lots of warnings about files
> already existing.
>
> When try to generate with the audio source I get a lot of audio config
> lines. all to do with portaudio
>
> BUT  --IT Looks like portaudio is working for me on windows.
>
> Certainly I get two outputs. If they are the I and Q Ioutputs t is my
> next test, but looking very good.
>
> Many Many thanks.
>
> Regards
>
> Gary
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 05/05/2019 17:43, Marcus Müller wrote:
> > Hi Gary,
> >
> >> This confuses simple folk like me.
> > this confuses simple folks such as me, too!
> >
> > That --prefsdir output is most defintely bogus. I can speculate what
> > happened there, however:
> >
> >> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> > That --prefsdir value is part of the source code that gets compiled
> > into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
> > "hardwiring" a directory path into a library, but write it in a
> > configuration file or something.
> >
> > However, in this case, that's the place we start looking into to find
> > the configuration files. So, that's the one thing that actually need to
> > hardwire.
> >
> > So, there's a text string "Z:\gr-build\src-
> > stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
> > probably a remnant of the machine that your GNU Radio got built on
> > (again, how did you install that?).
> > Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
> > so that you can have things like "\n" for newline in strings. Luckily,
> > none of the first letters of directory names combined with "\" give a
> > valid escape sequence, so the compiler just silently drops the "\" and
> > this is the string you end up with.
> >
> > I'll admit it: that's funky, and I didn't know that happened. We'll
> > most definitely will have to rewrite something to make this work under
> > windows (which uses backslashes for directory separation, unlike
> > unixoids, which use forward slashes).
> >
> > So, why does --userprefsdir work, but --prefsdir not?
> >
> > Well, --userprefsdir is built from environment variables at runtime, so
> > it's correct, not mangled by a compiler.
> >
> > I hear you say, that's fine and all, and now?
> >
> > Welll! I thought it strange that, although your userprefsdir seems
> > correct, GNU Radio didn't read the configuration file you modified. So,
> > down the rabbit hole it goes. Here's our culprit, in prefs.cc:
> >
> >std::vector
> >prefs::_sys_prefs_filenames()
> >{
> >  std::vector fnames;
> >
> >  fs::path dir = prefsdir();
> >  if(!fs::is_directory(dir))
> >return fnames; // >
> >   […]
> >
> >  // Find if there is a ~/.gnuradio/config.conf file and add this to
> >  // the end of the file list to override any preferences in the
> >  // installed path config files.
> >  fs::path userconf = fs::path(gr::userconf_path()) / "config.conf";
> >  if(fs::exists(userconf)) {
> >fnames.push_back(userconf.string());
> >  }
> >
> >  return fnames;
> >}
> >
> > So what happens here is that if the prefsdir isn't a proper directory,
> > and Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d bloody
> > well excels at not being a proper directory, it just throws the towel
> > and doesn't try to scan the userprefsdir things for configuration
> > files.
> >
> > I'm fully away of the irony saying the following in a > 10 emails
> > thread that started with a sound card problem:
> >
> > The solution should be simple.
> >
> > There's a way of overriding the hardwired prefsdir! We don't even have
> > to set it to the *right* directory, just any path that is actually a
> > directory. The way to do that would be setting an environment variable
> > "GR_PREFIX" that leads to the right place.
> >
> > So, I don't actually know where these things get installed to on
> > Windows, or on your individual machine, but: Can you look for a
> > directory "conf.d" in a path ending in etc\gnuradio\conf.d?
> >
> > Let's say it's C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d .
> >
> > then, you'd have to do something like
> >
> > set GR_PREFIX=C:\Programs\gnuradio\dragonsbehere
> > gnuradio-config-info --prefsdir
> >
> > If that now prints
> > C:\Progams\gnuradio\dragonsbehere\etc\gnuradio\conf.d, we're almost
> > there. Try, from the same command window,
> >
> > gnuradio-config-

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Ben Hilburn]

Hey Brad - just checking in! This is an interesting experiment, and I would
love to hear how it went!

Big thanks to Kevin and JMF for providing very helpful guidance, here, too
=)

Cheers,
Ben

On Thu, May 2, 2019 at 7:12 PM Kevin Reid  wrote:

> On Thu, May 2, 2019 at 1:22 PM Brad Hein  wrote:
>
>> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
>> magnetic loop antenna fed into the mic. A little cheesy? yes! But I'd like
>> to try and see if I can receive VLF. It's in a remote location with little
>> to no interference so I'm thinking my chances should be good. The challenge
>> I'm facing is that I need to write the SDR logic to "tune" throughout the
>> 0-24KHz tuning range.
>>
>> My question is, being that a sound card source presents samples in float
>> and not the usual complex data type, can I still apply the same SDR logic
>> that we use for SSB/FM/AM demodulation such as those presented in the
>> Gnuradio tutorials (eg.
>> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf)
>> and if not, how do I go about translating the float input into something I
>> can use to feed existing AM/FM/SSB demodulator flowgraphs?
>>
>
> The first thing you need to do is a "float to complex" operation (which
> will leave the imaginary/Q part zero). If you were to plot the spectrum of
> the resulting you would see that it is symmetric around 0 Hz, containing an
> extra copy of all the signals you're receiving, but that is no worse than a
> more typical received spectrum where the other half contains unrelated
> signals.
>
> After that, the approach is exactly the same as any other receiver
> flowgraph that supports receiving at an offset from the hardware
> center/zero frequency. You can use either the "Frequency Xlating FIR
> Filter" block (which combines a frequency shift and a low pass filter) or
> the "Rotator" block (which performs a frequency shift and would usually be
> followed by a separate filter), and the frequency shift of that block
> should be under user control for "tuning". Then you have a baseband signal
> that you can demodulate.
> ___
> 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] PhD Position in Wireless Communication Systems

[Bogale, Tadilo Endeshaw]

Apologies if you receive multiple copies of this posting?!

There are openings for highly motivated and energetic MSc/PhD students to work 
in my research group. The ideal candidate must have a strong mathematical 
background, very good knowledge of wireless communication systems, and good 
software programming skill.

Areas of research topics will includ, but not limited to, vehicle to everything 
(V2X) system, millimeter wave (massive MIMO) system, and intelligent (machine 
learning) techniques for wireless system design. Interested applicants can send 
me CV, transcript and other relevant documents all COMBINED in one PDF file to 
tebog...@ncat.edu or tadilo.bog...@gmail.com.

More information about the position can be found in

http://tadilo-bogale.com/ALLDocuments/Bogale-NCAT-Openings.pdf

I would appreciate if you can share to potential candidates!

Best Regards

Tadilo Endeshaw Bogale

-

Tadilo Endeshaw Bogale, PhD
Assistant Professor
North Carolina A&T State University

McNair Hall: 533

Greensboro, NC, USA
E-mail : tebog...@ncat.edu
   tadilo.bog...@gmail.com (private)
Personal: http://tadilo-bogale.com
LinkEdin: https://ca.linkedin.com/in/tadilo-endeshaw-bogale
G-Scholar: https://scholar.google.ca/citations?user=KVujBDsJ&hl=en
Youtube: https://www.youtube.com/channel/UC27HXaVxXlKk88Vujkccwwg
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Ben Hilburn]

Hey Moses -

This is really cool work! Thanks so much for sharing it. Michael's
suggestion of pushing it was a good one. I haven't looked at the code yet,
but:

The code was able to run smoothly in a C++ application but experienced
> memory leaks in GNU Radio.
>

I'm curious how confident you are in this? It might be worthwhile to
run the pure-C++ version through Valgrind just to double-check, if you
haven't already.

I also have one question regarding buffering in GNU Radio. Since iterative
> decoding with a large number of iterations and large block sizes takes time
> to complete, the input pmt data that is not consumed immediately will have
> to be stored somewhere. Is that the case? Could that be the reason for the
> memory leak?
>

Things do get stored until buffers and full, and then backpressure builds
up through the flowgraph. This shouldn't cause memory leaks.

For a more thorough explanation of this, check out this excellent blog post
from Marcus Mueller!

https://www.gnuradio.org/blog/2017-01-05-buffers/

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

Re: [Discuss-gnuradio] Tuning in VLF with a sound card

[Brad Hein]

Yes I am very eager and hankful for the suggestions. Trying to make time to
build out the flow graph and give it a go. Hopefully tonight!

[Sent from mobile device]

On Tue, May 7, 2019, 4:06 PM Ben Hilburn  Hey Brad - just checking in! This is an interesting experiment, and I
> would love to hear how it went!
>
> Big thanks to Kevin and JMF for providing very helpful guidance, here, too
> =)
>
> Cheers,
> Ben
>
> On Thu, May 2, 2019 at 7:12 PM Kevin Reid  wrote:
>
>> On Thu, May 2, 2019 at 1:22 PM Brad Hein  wrote:
>>
>>> I took a Raspberry Pi and attached a 48KHz USB sound card, with a big
>>> magnetic loop antenna fed into the mic. A little cheesy? yes! But I'd like
>>> to try and see if I can receive VLF. It's in a remote location with little
>>> to no interference so I'm thinking my chances should be good. The challenge
>>> I'm facing is that I need to write the SDR logic to "tune" throughout the
>>> 0-24KHz tuning range.
>>>
>>> My question is, being that a sound card source presents samples in float
>>> and not the usual complex data type, can I still apply the same SDR logic
>>> that we use for SSB/FM/AM demodulation such as those presented in the
>>> Gnuradio tutorials (eg.
>>> http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf)
>>> and if not, how do I go about translating the float input into something I
>>> can use to feed existing AM/FM/SSB demodulator flowgraphs?
>>>
>>
>> The first thing you need to do is a "float to complex" operation (which
>> will leave the imaginary/Q part zero). If you were to plot the spectrum of
>> the resulting you would see that it is symmetric around 0 Hz, containing an
>> extra copy of all the signals you're receiving, but that is no worse than a
>> more typical received spectrum where the other half contains unrelated
>> signals.
>>
>> After that, the approach is exactly the same as any other receiver
>> flowgraph that supports receiving at an offset from the hardware
>> center/zero frequency. You can use either the "Frequency Xlating FIR
>> Filter" block (which combines a frequency shift and a low pass filter) or
>> the "Rotator" block (which performs a frequency shift and would usually be
>> followed by a separate filter), and the frequency shift of that block
>> should be under user control for "tuning". Then you have a baseband signal
>> that you can demodulate.
>> ___
>> 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] Tuning in VLF with a sound card

[Marcus D. Leech]

On 05/07/2019 04:05 PM, Ben Hilburn wrote:
Hey Brad - just checking in! This is an interesting experiment, and I 
would love to hear how it went!


Big thanks to Kevin and JMF for providing very helpful guidance, here, 
too =)


Cheers,
Ben
I should perhaps have entered this discussion earlier, and pointed out 
one of my early applications using a sound-card for VLF work:


https://github.com/patchvonbraun/SIDSuite

It's OLD now--I don't think it was ever converted to GR 3.7

One of the problems with mag-loop antenna is that they're very high Q, 
and thus have very small fractional bandwidths, which means that
  they're wildly inefficient at all but the resonant frequency.  I made 
up for that using a Behringer microphone pre-amp using the balanced input.
  That meant I could use a fairly "random" multi-turn mag-loop and not 
worry about efficiency very much.





On Thu, May 2, 2019 at 7:12 PM Kevin Reid > wrote:


On Thu, May 2, 2019 at 1:22 PM Brad Hein mailto:linuxb...@gmail.com>> wrote:

I took a Raspberry Pi and attached a 48KHz USB sound card,
with a big magnetic loop antenna fed into the mic. A little
cheesy? yes! But I'd like to try and see if I can receive VLF.
It's in a remote location with little to no interference so
I'm thinking my chances should be good. The challenge I'm
facing is that I need to write the SDR logic to "tune"
throughout the 0-24KHz tuning range.

My question is, being that a sound card source presents
samples in float and not the usual complex data type, can I
still apply the same SDR logic that we use for SSB/FM/AM
demodulation such as those presented in the Gnuradio tutorials
(eg.
http://www.csun.edu/~skatz/katzpage/sdr_project/sdr/grc_tutorial3.pdf

)
and if not, how do I go about translating the float input into
something I can use to feed existing AM/FM/SSB demodulator
flowgraphs?


The first thing you need to do is a "float to complex" operation
(which will leave the imaginary/Q part zero). If you were to plot
the spectrum of the resulting you would see that it is symmetric
around 0 Hz, containing an extra copy of all the signals you're
receiving, but that is no worse than a more typical
received spectrum where the other half contains unrelated signals.

After that, the approach is exactly the same as any other receiver
flowgraph that supports receiving at an offset from the hardware
center/zero frequency. You can use either the "Frequency Xlating
FIR Filter" block (which combines a frequency shift and a low pass
filter) or the "Rotator" block (which performs a frequency shift
and would usually be followed by a separate filter), and the
frequency shift of that block should be under user control for
"tuning". Then you have a baseband signal that you can demodulate.
___
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 GNURadio On Raspberry Pi

[Ben Hilburn]

Hi Pete -

Yes, I personally know of multiple. Albin's work of implementing volk
kernels for TujaSDR , shared here on the list with
some regularity, is an excellent example.

On Wed, May 1, 2019 at 5:32 PM P C  wrote:

> Problem Solved! .NOT!
> Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
> RTL-SDR dongle?
> I thought I cured my problems then the next day, more problems.
> This is what I thought fixed my problem (but later, didn't).
>

This kind of thing can be difficult to debug, but please refrain from
cynical sarcasm here - especially if you want help and support.

If you're willing to share your progress and current issues, I'm sure there
are people willing to provide some thoughts.

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

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[Marcus D. Leech]

On 05/07/2019 04:20 PM, Ben Hilburn wrote:

Hi Pete -

Yes, I personally know of multiple. Albin's work of implementing volk 
kernels for TujaSDR , shared here on the list 
with some regularity, is an excellent example.


On Wed, May 1, 2019 at 5:32 PM P C > wrote:


Problem Solved! .NOT!
Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
RTL-SDR dongle?
I thought I cured my problems then the next day, more problems.
This is what I thought fixed my problem (but later, didn't).


This kind of thing can be difficult to debug, but please refrain from 
cynical sarcasm here - especially if you want help and support.


If you're willing to share your progress and current issues, I'm sure 
there are people willing to provide some thoughts.


Cheers,
Ben


Is there not an Ubuntu image for the rPi?

I used a stock Ubuntu image for the Odroid C1 and just used the 
GnuRadio+friends from the repos, which included gr-osmosdr support for

  a number of different devices.

I did end up doing a source build later, but that was for device support 
for "newer stuff".




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

Re: [Discuss-gnuradio] FEC Examples with Modulators

[Alex Roberts]

Hi Ben,

 I have looked at them, I recreated the fecapi_tagged_decoders example and
switched to file source and file sink to send Hello World.  I got that
working today.

I then tried to add OFDM TX --> OFDM RX (see attached grc flow diagram),
but can't get a balance between encoder frame size and number of noutput
items. I either get the error "gr::log :INFO: cc_encoder1 - tried to set
frame to XXX; max possible is YYY" or "thread[thread-per-block[13]: ]: Buffer too small for min_noutput_items.
I've tried increasing the minimum buffer size for the OFDM TX block, but
then I get the error "gr::log :INFO: header_payload_demux0 - Detected a
packet larger than max frame size"

I'm going to try with a more simplistic modulation scheme like PSK or FSK
when I get the chance.

Thanks,
Alex.

On Tue, May 7, 2019 at 2:48 PM Ben Hilburn  wrote:

> Hi Alex -
>
> Have you tried any of the examples in gr-fec/examples? If so and they
> didn't work for you, what issues have you encountered?
>
> Cheers,
> Ben
>
> On Sat, May 4, 2019 at 9:20 PM Alex Roberts  wrote:
>
>> Hello GNURadio Users,
>>
>> I'm learning about convolutional encoders in school and would like to
>> demonstrate their use in gnuradio for a presentation. The examples
>> appear useful for showing BER and Encoding -> decodng, but I'm
>> struggling to implement a signal chain
>>
>> tx_bytes --> unpacked to packed -> FEC_ENCODE -> modulation -> AWGN
>> channel -> demod -> FEC_DECODE -> received_bytes
>>
>> I'm not sure where to put the fec_decode on receiver side or how the
>> bytes need to packed to use it. Are there some tutorials or examples
>> that FEC with tx to rx (either w/ hardware or loopback)?
>>
>> Thanks
>> Alex.
>>
>> ___
>> 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
>


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

Re: [Discuss-gnuradio] Data loss during transmission (OFDM .bmp file)

[Simran Kaur]

Hi Ben,
I am trying to transmit an image using USRP Tx/RX by implementing OFDM in
GNU Radio. I am losing one offset of 96 bytes. I am suspecting there is
problem with my synchronization which is not detecting that offset
(packet_len = 96 bytes) or probably discarding it. I also tried inserting
padding using burst shaper and removing those bits using correlator. But
that is not working either. Can you suggest something how to make this
right?


Best,

Simran Kaur

On Tue, May 7, 2019 at 3:33 PM Ben Hilburn  wrote:

> Hey Simran -
>
> All of this is to say that your communications system design does not
> appear to be robust to the impairments and complexities of wireless
> channels, some of which Marcus mentioned. Can you share what your specific
> goal is or why you're undertaking this work? Depending on what you are
> trying to achieve, you might not need something quite so complex.
>
> Cheers,
> Ben
>
>
>
> On Sun, May 5, 2019 at 2:11 PM Kevin McQuiggin  wrote:
>
>> Read, read read!  Simple questions often lead to very complex answers.
>>
>> You might start your studies with "The Scientist & Engineer's Guide to
>> Digital Signal Processing” by S. Smith.
>>
>> Kevin
>>
>> > On May 5, 2019, at 9:46 AM, Marcus Müller 
>> wrote:
>> >
>> > Well, noise happens, and synchronization isn't instantaneous. Things
>> > that aren't detected can't be received, and bit errors that the FEC
>> > can't correct are bit errors in the received data.
>> >
>> > That's the beauty and the curse of wireless communications.
>> >
>> > Best regards,
>> > Marcus
>> >
>> > On Sat, 2019-05-04 at 20:26 -0400, Simran Kaur wrote:
>> >> Hello All,
>> >> We are trying to transmit a .bmp file using USRP Tx/Rx. However, I am
>> >> getting bogus header data at the receiving end. I tried transmitting
>> >> a text file also which clips my starting text and also it inserts
>> >> some invalid/unknown characters. We are losing some of the bytes for
>> >> e.g, the transmitted file size is of 426316 bytes, but receiving file
>> >> size is of 4,264,224 bytes.
>> >> Can somebody explain what we are doing wrong here. I have attached my
>> >> Tx and Rx .grc and snapshots for the reference.
>> >>
>> >> Best,
>> >> Simran Kaur
>> >> ___
>> >> 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] Recurring memory leak problems with iterative decoding [ GNU Radio 3.7.11.1]

[Moses Browne Mwakyanjala]

Hello Ben,
Thanks.
For LDPC, the executable can be found at
*gr-ccsds/examples/LDPC/ldpc_2/build-ldpc_decoder-Desktop-Debug/ldpc_decoder.*
The C++ executable for Turbo code can be found at
*gr-ccsds/lib/fec/turbo/deepspace-turbo/bin/deepspace_turbo*

I'm not very familiar with Valgrind so I monitored the memory usage by
looking at system monitor on my Ubuntu laptop. The memory usage is almost
constant, at around 17.1 Mbs for the ldpc_decoder executable. On GNU Radio,
the memory usage jumps by huge steps (100Mb) in a matter of seconds until
all the memory (the ram is around 8 gigs) is fully consumed.

Thanks for links to the memory buffer blog post. I will have a look.
Regards,
Moses.

On Tue, May 7, 2019 at 10:13 PM Ben Hilburn  wrote:

> Hey Moses -
>
> This is really cool work! Thanks so much for sharing it. Michael's
> suggestion of pushing it was a good one. I haven't looked at the code yet,
> but:
>
> The code was able to run smoothly in a C++ application but experienced
>> memory leaks in GNU Radio.
>>
>
> I'm curious how confident you are in this? It might be worthwhile to run the 
> pure-C++ version through Valgrind just to double-check, if you haven't 
> already.
>
> I also have one question regarding buffering in GNU Radio. Since iterative
>> decoding with a large number of iterations and large block sizes takes time
>> to complete, the input pmt data that is not consumed immediately will have
>> to be stored somewhere. Is that the case? Could that be the reason for the
>> memory leak?
>>
>
> Things do get stored until buffers and full, and then backpressure builds
> up through the flowgraph. This shouldn't cause memory leaks.
>
> For a more thorough explanation of this, check out this excellent blog
> post from Marcus Mueller!
>
> https://www.gnuradio.org/blog/2017-01-05-buffers/
>
> Cheers,
> Ben
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windows

[gary.simpk...@gdscs.co.uk]

Yes all sorted. What I wanted to do was simple. To have two stereo  actually IQ inputs and a single 4 channel output Now I have MAP65 working with adaptive phasing using the SDRPlay Uno software with and RSP Duo SDR.Brilliant. Portaudio solved the problem. Marcus stuck with me to get it working. I am really grateful.GarySent from my Huawei Mobile Original Message Subject: Re: [Discuss-gnuradio] Audio source cannot use 2 outputs (Stereo) in windowsFrom: Ben Hilburn To: "Gary.Simpkins" CC: Marcus M黮ler ,GNURadio Discussion List Sounds like you got your issue resolved, Gary? This one was a doozy to follow, and I'm glad you got it sorted.And thanks to Marcus for helping sort through it!Cheers,BenOn Mon, May 6, 2019 at 7:17 AM Gary.Simpkins  wrote:Hi Marcus.

It was late last night and I missed the errors in the 
grnradio-config-info -- prefsdir response.

It had the dirs twice. So I changed the Prefix in windows to be just 
GNUradio-3.7, and the tried again.

The prefs now has details includng portaudio.

When I start gnuradio companion  I now see lots of warnings about files 
already existing.

When try to generate with the audio source I get a lot of audio config 
lines. all to do with portaudio

BUT  --IT Looks like portaudio is working for me on windows.

Certainly I get two outputs. If they are the I and Q Ioutputs t is my 
next test, but looking very good.

Many Many thanks.

Regards

Gary


















On 05/05/2019 17:43, Marcus Müller wrote:
> Hi Gary,
>
>> This confuses simple folk like me.
> this confuses simple folks such as me, too!
>
> That --prefsdir output is most defintely bogus. I can speculate what
> happened there, however:
>
>> Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d
> That --prefsdir value is part of the source code that gets compiled
> into the tool/the GNU Radio libraries. Normally, you wouldn't do that,
> "hardwiring" a directory path into a library, but write it in a
> configuration file or something.
>
> However, in this case, that's the place we start looking into to find
> the configuration files. So, that's the one thing that actually need to
> hardwire.
>
> So, there's a text string "Z:\gr-build\src-
> stage3\staged_install\Release\etc\gnuradio\conf.d" in there, which is
> probably a remnant of the machine that your GNU Radio got built on
> (again, how did you install that?).
> Sadly, the "\" gets interpreted by the compiler to be "escape symbol",
> so that you can have things like "\n" for newline in strings. Luckily,
> none of the first letters of directory names combined with "\" give a
> valid escape sequence, so the compiler just silently drops the "\" and
> this is the string you end up with.
>
> I'll admit it: that's funky, and I didn't know that happened. We'll
> most definitely will have to rewrite something to make this work under
> windows (which uses backslashes for directory separation, unlike
> unixoids, which use forward slashes).
>
> So, why does --userprefsdir work, but --prefsdir not?
>
> Well, --userprefsdir is built from environment variables at runtime, so
> it's correct, not mangled by a compiler.
>
> I hear you say, that's fine and all, and now?
>
> Welll! I thought it strange that, although your userprefsdir seems
> correct, GNU Radio didn't read the configuration file you modified. So,
> down the rabbit hole it goes. Here's our culprit, in prefs.cc:
>
>    std::vector
>    prefs::_sys_prefs_filenames()
>    {
>      std::vector fnames;
>
>      fs::path dir = prefsdir();
>      if(!fs::is_directory(dir))
>        return fnames; //
>   […]
>
>      // Find if there is a ~/.gnuradio/config.conf file and add this to
>      // the end of the file list to override any preferences in the
>      // installed path config files.
>      fs::path userconf = fs::path(gr::userconf_path()) / "config.conf";
>      if(fs::exists(userconf)) {
>        fnames.push_back(userconf.string());
>      }
>
>      return fnames;
>    }
>
> So what happens here is that if the prefsdir isn't a proper directory,
> and Z:gr-buildsrc-stage3staged_installReleaseetcgnuradioconf.d bloody
> well excels at not being a proper directory, it just throws the towel
> and doesn't try to scan the userprefsdir things for configuration
> files.
>
> I'm fully away of the irony saying the following in a > 10 emails
> thread that started with a sound card problem:
>
> The solution should be simple.
>
> There's a way of overriding the hardwired prefsdir! We don't even have
> to set it to the *right* directory, just any path that is actually a
> directory. The way to do that would be setting an environment variable
> "GR_PREFIX" that leads to the right place.
>
> So, I don't actually know where these things get installed to on
> Windows, or on your individual machine, but: C

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[P C]

Ben,

I am sorry if I came across as cynical and sarcastic.  I didn't mean 
to.  I really wanted to know if anyone could make GNURadio work on a RPi.


I'll be the first to say I know nothing about Linux and Python. However, 
I created the flow graph I need on my windows computer months ago and 
have been trying ever since to get it to work reliably on my RPi.  I 
experienced repeated segment faults, malloc faults, failure to have the 
osmocom block I needed, etc.


Since I asked the question here I have gotten help, very good help and  
still no luck.  In addition I did so many installs and removes my SD 
card is to the point it just needs to be reformatted and rebuilt.


But I did discover during the process that the culprit is the 
osmocom/rtlsdr block.   No matter how I install it, my flow graph just 
won't run when it is enabled.


Luckily during this process, last night, I discovered that I don't need 
the osmocom/rtlsdr block.  I can get the stream from my rtlsdr using the 
command:

rtl-sdr -f  -s  /tmp/aFIFO
where a FIFO is created with mkfifo aFIFO.  Then read the FIFO with a 
file source block.


It might not have as good a SNR as on windows but I think I can adjust 
some filtering and move some gains around and it will be acceptable.


So, I'm off and running to complete my project and I'm not looking back 
(I hope).


Maybe if I need to do this for another project I'll start over. It looks 
like Glen and Marcus are using Ubuntu where as I have been using 
Raspbian.  I'll go that route next time.


Thanks,

Pete



On 5/7/2019 3:20 PM, Ben Hilburn wrote:

Hi Pete -

Yes, I personally know of multiple. Albin's work of implementing volk 
kernels for TujaSDR , shared here on the list 
with some regularity, is an excellent example.


On Wed, May 1, 2019 at 5:32 PM P C > wrote:


Problem Solved! .NOT!
Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
RTL-SDR dongle?
I thought I cured my problems then the next day, more problems.
This is what I thought fixed my problem (but later, didn't).


This kind of thing can be difficult to debug, but please refrain from 
cynical sarcasm here - especially if you want help and support.


If you're willing to share your progress and current issues, I'm sure 
there are people willing to provide some thoughts.


Cheers,
Ben



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

Re: [Discuss-gnuradio] Installing GNURadio On Raspberry Pi

[P C]

Glen,

Beautiful job.  Very impressive.
It may be that using Raspbian not Ubuntu is my problem.
It would be interesting to know if other have success with Raspbian.

Thanks,

Pete

On 5/7/2019 5:44 PM, Glen I Langston wrote:

Hi

We’ve put our event detection on three Raspberry Pi 3B +
for confirming events in the forward direction (not side lobes).

I have a 8 GB image .iso that I could put on line this weekend.
Where is appropriate for such large files?  We installed everything
on one Pi then just copied the image to the other SD cards.

This is setup for Ubuntu with Gnuradio for use with Airspys and
RTL-SDR dongles.

The Pi 3B+ can just about eat all 6 MHz of event samples without
loosing many samples.  The Pi can not FFT the samples to make spectra
without loosing a large fraction of the samples.

Probably the 3B+ could deal with 2.4 MHz of bandwidth, but not
much more.

The band pass spectra still look good, but a large fraction of the
samples are lost (at 6 MHz bandwidth, 12 MHz samples).

We have these in boxes near our telescopes.

Image attached.

regards

Glen



On May 7, 2019, at 4:39 PM, Marcus D. Leech  wrote:

On 05/07/2019 04:20 PM, Ben Hilburn wrote:

Hi Pete -

Yes, I personally know of multiple. Albin's work of implementing volk kernels 
for TujaSDR, shared here on the list with some regularity, is an excellent 
example.

On Wed, May 1, 2019 at 5:32 PM P C  wrote:
Problem Solved! .NOT!
Tell me, is anyone running GNURadio on a Raspberry Pi (3-B) using an
RTL-SDR dongle?
I thought I cured my problems then the next day, more problems.
This is what I thought fixed my problem (but later, didn't).

This kind of thing can be difficult to debug, but please refrain from cynical 
sarcasm here - especially if you want help and support.

If you're willing to share your progress and current issues, I'm sure there are 
people willing to provide some thoughts.

Cheers,
Ben


Is there not an Ubuntu image for the rPi?

I used a stock Ubuntu image for the Odroid C1 and just used the 
GnuRadio+friends from the repos, which included gr-osmosdr support for
   a number of different devices.

I did end up doing a source build later, but that was for device support for "newer 
stuff".



___
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] Tuning in VLF with a sound card

[Brad Hein]

On Tue, May 7, 2019 at 4:19 PM Marcus D. Leech 
wrote:

> On 05/07/2019 04:05 PM, Ben Hilburn wrote:
>
> Hey Brad - just checking in! This is an interesting experiment, and I
> would love to hear how it went!
>
> Big thanks to Kevin and JMF for providing very helpful guidance, here, too
> =)
>
> Cheers,
> Ben
>
> I should perhaps have entered this discussion earlier, and pointed out one
> of my early applications using a sound-card for VLF work:
>
> https://github.com/patchvonbraun/SIDSuite
>
> It's OLD now--I don't think it was ever converted to GR 3.7
>
> One of the problems with mag-loop antenna is that they're very high Q, and
> thus have very small fractional bandwidths, which means that
>   they're wildly inefficient at all but the resonant frequency.  I made up
> for that using a Behringer microphone pre-amp using the balanced input.
>   That meant I could use a fairly "random" multi-turn mag-loop and not
> worry about efficiency very much.
>
>
Thanks Marcus - I'll see if I can get it to compile again. In the meantime
I have put together an AM receiver flowgraph using recommendations from
this thread, along with what I remembered from the gnuradio tutorials and
Mike Osman's video tutorials.

https://github.com/regulatre/vlfCoilEperiment

Given a 5-minute recording, which I included in the repo, I quickly found
that QRM interference will be a hurdle and as you pointed out Marcus, my
coil (an old VGA degaussing coil) seems to be resonant at undesirable
frequencies. In its current installation it's getting overwhelmed by a
steady interference source that sounds like ripples coming from a 60Hz
half-wave rectifier. There are some gaps in the noise, and as I tuned
around within the baseband using my flowgraph (in the repo above), I was
able to tune to various parts of the baseband, but in all cases I had too
much interference noise.

I have a Focusrite Si2 I could use instead, which would have more gain
potential and a very low noise floor, but first I think I'll need to find a
way to get away from the noise sources.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio