Thursday, April 30, 2020

Sample Rate & Hardware Considerations Tutorial: GNURadio.org

Morning All,

I have a question after following the sample rate tutorial and its implementation on the Guided Tutorial Hardware Considerations section on the official site: https://wiki.gnuradio.org/index.php/Guided_Tutorial_Hardware_Considerations

After the first portion of the lesson, one is asked to add new blocks shown below. 
  • 1x Rational Resampler
  • 1x WBFM Receiver
  • 1x Audio Sink
  • 2x Variable

For the Variable: samp_rate we are told to add the following:
  • ID: samp_rate
  • Value: 250e3

Now, I know the bandwidth of FM is 250 kHz. What I don't know is why we were asked to make this our sample rate. Coincidence? 
When I run the example (with a few changes for my hardware, and creating a few more variables) I get a signal stream that seems out of sync. 
The sound I hear is a constant drop or miss in signal about three times a second. Think waa-waa-waa, each second, in between the radio playing. 

I launched SDRSharp to compare output and noticed the sample rate is default at 2.4M 
I then changed this in my Variable samp_rate and low and behold, the stream is steady.

I have two questions. 
  1. Why was a sample rate of 250K chosen in the example?
  2. What is the goal of the multiplier?
    • In your (Barry Duggan's) example the multiplier helped to remove his static
    • In my file, setting this as a variable slider, and adjusting while playing, I see no difference to the sound

Below is my flowgraph, I also attached the .grc file. 




Any help is greatly appreciated. Thanks in advance! 

--
Thanks,
James G Hayek
Youtube.com/JamesHayek

Re: [gnu.org #1520212] Problem with hidden addresses

Dear Ms. Thérèse and Mr. Ian Kelling,

Thank you very much for the clarifications.

Best regards,
Artur

Em qui., 30 de abr. de 2020 às 09:58, Ian Kelling via RT <sysadmin@gnu.org> escreveu:
On Wed Apr 29 15:54:58 2020, artur.nogsj@gmail.com wrote:
> Dear GNU Radio webmasters,
>
> I am a GNU Radio user, currently subscribed on the <discuss-
> gnuradio@gnu.org>
> discussion list.
> While trying to find some specific topics on the
> <https://lists.gnu.org/>
> website, I realized that inside a given discussion history (e.g.
> https://lists.gnu.org/archive/html/qemu-devel/2020-04/index.html), the
> e-mail addresses are hidden (address@hidden).
> Nevertheless, if I type any name on the search engine here: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/>, then the
> complete
> e-mail address is available.
>
> Could you check that, please?
>
> Thanks in advance.
>
> Best regards,
> Artur

They are hidden only in the main html view, but have always been
visibile in the mbox archive. See the link to the mbox archives at
https://lists.gnu.org/archive/html/discuss-gnuradio/. The mbox archives
are necessary for people to fully participate in conversations that
happened before they were subscribed to the list, or who are not
subscribed. It used to be that hiding email addresses in the html view
was helpful against crawlers and spammers, but they have largely found
the mbox archives and we plan to stop hiding them in the html view as it
seems to mainly cause problems for normal people nowadays. If the list
administrators/owners wanted to fully hide people's email addresses,
they could turn on a setting for the list called anonymous_list. Note, I
don't know who the list admin/owners are for gnu-radio-discuss, FSF is whats
called the site administrators in GNU Mailman terms.

--
Ian Kelling | Senior Systems Administrator, Free Software Foundation
GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
https://fsf.org | https://gnu.org


Re: porting OOT to gr3.8 Make failure

Hi Ron,

On 30/04/2020 23.51, Ron Economos wrote:
> Just FYI, I tried the latest VOLK with your patch, but that doesn't help if VOLK is built with ORC. It looks like libvolk.so is required by libgnuradio-runtime.so (there's one volk_get_alignment() call in gnuradio-runtime) and libvolk.so requires liborc-0.4.so.

How did you tested it? Did you preform a clean rebuild of gnuradio?

Note that libgnuradio-runtime.so requires libvolk.so.2.2.1 (not libvolk.so) and when VOLK is built with ORC it requires liborc-0.4.so.0 (not liborc-0.4.so) and this is how it should be, there is no way around this.

$ ldd libgnuradio-runtime.so | grep orc
liborc-0.4.so.0 => /lib64/liborc-0.4.so.0 (0x00007f46d4f3a000)

$ objdump -p libgnuradio-runtime.so | grep NEEDED
NEEDED libgnuradio-pmt.so.3.8.1
NEEDED libvolk.so.2.2.1
NEEDED libboost_program_options.so.1.66.0
NEEDED libboost_filesystem.so.1.66.0
NEEDED libboost_system.so.1.66.0
NEEDED libboost_regex.so.1.66.0
NEEDED libboost_thread.so.1.66.0
NEEDED librt.so.1
NEEDED libboost_chrono.so.1.66.0
NEEDED libboost_date_time.so.1.66.0
NEEDED libboost_atomic.so.1.66.0
NEEDED libpthread.so.0
NEEDED liblog4cpp.so.5
NEEDED libdl.so.2
NEEDED libgmpxx.so.4
NEEDED libgmp.so.10
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libgcc_s.so.1
NEEDED libc.so.6

$ objdump -p libvolk.so.2.2 | grep NEEDED
NEEDED libdl.so.2
NEEDED liborc-0.4.so.0
NEEDED libm.so.6
NEEDED libc.so.6

To test whether this issue is fixed you need to try building an OOT module without having the liborc-0.4.so (the liborc-0.4-dev package) installed on your system.

Cheers,
Vasil

Re: porting OOT to gr3.8 Make failure

Just FYI, I tried the latest VOLK with your patch, but that doesn't help
if VOLK is built with ORC. It looks like libvolk.so is required by
libgnuradio-runtime.so (there's one volk_get_alignment() call in
gnuradio-runtime) and libvolk.so requires liborc-0.4.so.

Ron

On 4/30/20 04:02, Vasil Velichkov wrote:
> Hi Johannes, Ron,
>
> The liborc-0.4.so gets linked because it is in INTERFACE_LINK_LIBRARIES in VolkTargets.cmake. This should be fixed in https://github.com/gnuradio/volk/pull/367 but a volk version with this fix is still not released.
>
> Cheers,
> Vasil
>
> On 30/04/2020 13.32, Ron Economos wrote:
>> I don't exactly know why, but liborc-0.4.so gets linked into even the simplest of OOT modules. Here's an example:
>>
>>     linux-vdso.so.1 (0xbef7b000)
>>     libgnuradio-runtime.so.3.8.1 => /opt/gnuradio-3.7.12git/lib/libgnuradio-runtime.so.3.8.1 (0xb6eb0000)
>>     libgnuradio-pmt.so.3.8.1 => /opt/gnuradio-3.7.12git/lib/libgnuradio-pmt.so.3.8.1 (0xb6e61000)
>>     libboost_system.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_system.so.1.65.1 (0xb6e35000)
>>     libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6d22000)
>>     libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6cf9000)
>>     libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c01000)
>>     /lib/ld-linux-armhf.so.3 (0xb6f83000)
>>     libvolk.so.2.2.1 => /opt/gnuradio-3.7.12git/lib/libvolk.so.2.2.1 (0xb6b45000)
>>     libboost_program_options.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_program_options.so.1.65.1 (0xb6ade000)
>>     libboost_filesystem.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.65.1 (0xb6abc000)
>>     libboost_thread.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_thread.so.1.65.1 (0xb6a8f000)
>>     librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6a79000)
>>     libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6a54000)
>>     liblog4cpp.so.5 => /usr/lib/arm-linux-gnueabihf/liblog4cpp.so.5 (0xb6a1e000)
>>     libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb69c6000)
>>     libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6945000)
>>     liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0 (0xb68e7000)
>>
>> Ron
>>
>> On 4/30/20 02:46, Johannes Demel wrote:
>>> Hi Tom,
>>>
>>> ORC is a Tool that is used in VOLK to optimize some kernels. Though, this is an optional dependency. ORC kernels are not built if liborc etc is not found.
>>>
>>> I assume you can run example flowgraphs in GRC.
>>> In this case, you shouldn't need to worry about ORC at all. Though, somehow you try to link against it. Maybe it's worth a try to figure out how ORC ends up in your `target_link_libraries`?
>>>
>>> I know, you fixed your issue by installing liborc*-dev but this should not be necessary.
>>>
>>> Cheers
>>> Johannes
>>>
>>>
>>> On 30.04.20 09:37, Tom McDermott wrote:
>>>> Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
>>>> It is suggested by the make failure for the ported OOT module.
>>>>
>>>> Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
>>>> and make completed successfully.  Thanks for the suggestion Vasil.
>>>> Perhaps it's a dependency that is missing when installing grc on 20.04?
>>>>
>>>> With that, gr-hpsdr installed successfully on gr3.8, and the module instantiates
>>>> in the flowgraph.  Now to start testing to see if it works...
>>>>
>>>> -- Tom, N5EG
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org <mailto:mmueller@gnuradio.org>> wrote:
>>>>
>>>>     Hi Tom,
>>>>
>>>>     nice hearing from you! I didn't know that hpsdr needed orc?
>>>>
>>>>     Best regards,
>>>>     Marcus
>>>>
>>>>     On 29.04.20 22:46, Tom McDermott wrote:
>>>>      > I am porting an OOT from 3.7 to 3.8.
>>>>      > Ubuntu 20.04.  Gnuradio installed via apt install from the
>>>>      > gnuradio-releases PPA.  GR 3.8.1
>>>>      >
>>>>      > It looks like all the modules are compiling OK, but am getting an
>>>>     error.
>>>>      >
>>>>      > scanning dependencies of target gnuradio-hpsdr
>>>>      > [ 12%] Building CXX object
>>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
>>>>      > [ 25%] Building CXX object
>>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
>>>>      > [ 37%] Building CXX object
>>>>     lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
>>>>      > [ 50%] Building CXX object
>>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
>>>>      > [ 62%] Building CXX object
>>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
>>>>      > make[2]: *** No rule to make target
>>>>      > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>
>>>>     <http://liborc-0.4.so>', needed
>>>>      > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
>>>>      > make[1]: *** [CMakeFiles/Makefile2:248:
>>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
>>>>      > make: *** [Makefile:141: all] Error 2
>>>>      >
>>>>      >
>>>>      > Not sure what liborc is.   Is this what's missing, or is it
>>>>     something else?
>>>>      > liborc-dev is listed as having no installation candidate for 20.04
>>>>      >
>>>>      > $ apt-cache policy liborc-dev
>>>>      > liborc-dev:
>>>>      >   Installed: (none)
>>>>      >   Candidate: (none)
>>>>      >   Version table:
>>>>      >
>>>>      >
>>>>      >
>>>>      > -- Tom, N5EG
>>>>      >
>>>>      >
>>>>
>

Virtual GNU Radio Conference 2020 - Call for Participation

Virtual GRCon20 - Call for Participation

Greetings! I'm the chair of GNU Radio Conference 2020, starting 14 September 2020. This will be a fun, accessible, and exciting experience. All participants will be welcomed and supported.

We have your back!

What do we need in order to succeed? GNU Radio content.

Submit your work for presentation at https://www.gnuradio.org/grcon/grcon20/submit/

We are looking for papers, presentations, posters, workshops, and lightning talks.

Don't have time or energy for a complete submission? Don't let that stop you. If you have real interest in presenting in September 2020, start the process today. Enter in as much as you can about what you want to share with the community. The organizing team is here to help you make it happen and have fun doing it.

Need convincing, feel your work isn't good enough to share, or don't really know how things could possibly work for a virtual event?

Read on!

We have excellent professional support for this event from ConFreaks.
We have outstanding keynote speakers lined up.
We have numerous workshop proposals submitted from organizations you know and trust.

What do we need? You, sharing your work!

The barriers to participate at GRCon have never been lower. This gives us the best possible chance to raise expectations on what we can achieve with the event.

Traditional GRCon is expensive to attend. It's held during the work week in a US time zone. Virtual GRCon cannot replace everything we lose by not being able to have an in-person event, but we can make it radically affordable, inclusive, meaningful, and interactive for a large part of the globe.

I hear from many community members all year long that have doubts about their work being "good enough" to present at the conference. I want to make it clear that the conference team is here to help, support, and develop quality presentations, not just "review" and "judge" complete work. No, we can't do the engineering for you, but we can help you put your work in the best possible light with feedback and encouragement. That is, if you start now and submit your work.

Registration for presentation track is free. Workshop fee (covers all workshops) is $50. Students are completely free, including the workshops.

Register here: https://tickets.gnuradio.org/grcon20/

Questions? Comments? Want to volunteer? We need reviewers and people interested in gaining experience with running an online conference event. Write grcon@gnuradio.org or me directly.

Know someone that needs to know about GRCon20? Pass along the attached pdf.

-Michelle Thompson W5NYV
w5nyv@arrl.net

Re: Problems with combining UDP and GMSK with FEC

Hello, and sry for sending 2 mails after one another,

But just tested something when I run the flowgraph with the fec no output but when without the fec (and of course the throttle disabled) I get an output (tested it with vlc udp) but in here are frame drops or corrupted data as in the picture.



Do you know how to solve this problem? Is it in GNU or do you think in OBS / ffmpeg?

Op do 30 apr. 2020 om 13:56 schreef Quenten . <quentenswitten@gmail.com>:
Hello Müller,

Excuse me for sending the wrong picture of the flowgraph  but the throttle was disabled when I ran the program(so the problem is not here)
And what do you mean with: the source that streams UDP is inherently rate limited.

Best regards,

Quenten 

Op do 30 apr. 2020 om 11:55 schreef Marcus Müller <marcus.mueller@ettus.com>:
Hi Quenten,

your Throttle is highly counter-productive:

Either, the source that streams UDP is inherently rate limited, then the
throttle does nothing, or it's not, then the throttle will lead to the
buffer of the UDP Source filling at some point, forcing it to drop samples.

(told you exactly this before, see my mail "Re: Frame drop when Using
GMSK en UDP" from 2020-04-24)

Best regards,
Marcus

On 30.04.20 10:36, Quenten . wrote:
> Hello to all,
>
> First before I explain the problem a little backstory:
>
> I am using a windows 10 PC and GNU radio v3.7.11 because if I go higher
> the bladeRF support doesn't work very well. I am trying to get a 'live'
> stream trough GNU radio.How I get this stream in GNU radio is as followed:
> 1) Stream with OBS to RTMP server
> 2) Use ffmpeg to get this 'live' stream to UDP
> 3)Use UDP source to put this in GRC
>
> After this I modulate this with GSMK and 'send' it wireless with the use
> of an bladeRF x115. Then receive this with an another bladeRF x115 and
> demodulate it to play the videostream on vlc or an other mediaplayer.
> But first I try to get it working in a simulation program. 
> (for flowgraph picture see attached)
>
> But when I try to run this simulation there are problems. I don't get a
> signal out.(see result1 picture). I have also tried to switch the fec
> decoder and packet decoder from place but then I don't get any signal in
> the f spectrum not even a 'zero' line and just a flat line in the time
> spectrum.
>
> A fellow user of this platform advised me to use /_packets or frames and
> also said to use ?zero padding? because I use convolutional codes. But
> couldn't say how to use this._/
>
> If anyone knows how to do this pls help me and let me know.
>
> Best regards,
>
> Q
>
> P.S.: To see the Mails click link below:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00216.html  

Re: porting OOT to gr3.8 Make failure

aaaah.

Can we maybe do a

for lib in $(ldd oot-module.so|grep '=>'| sed 's/.* => \(.*\)$/\1/')
do
ldd $lib | grep orc && echo $lib
done

(this is as you can guess straight from the top of my head, and untested)

Cheers,
Marcus

On 30.04.20 12:32, Ron Economos wrote:
> I don't exactly know why, but liborc-0.4.so gets linked into even the
> simplest of OOT modules. Here's an example:
>
>     linux-vdso.so.1 (0xbef7b000)
>     libgnuradio-runtime.so.3.8.1 =>
> /opt/gnuradio-3.7.12git/lib/libgnuradio-runtime.so.3.8.1 (0xb6eb0000)
>     libgnuradio-pmt.so.3.8.1 =>
> /opt/gnuradio-3.7.12git/lib/libgnuradio-pmt.so.3.8.1 (0xb6e61000)
>     libboost_system.so.1.65.1 =>
> /usr/lib/arm-linux-gnueabihf/libboost_system.so.1.65.1 (0xb6e35000)
>     libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
> (0xb6d22000)
>     libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6cf9000)
>     libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c01000)
>     /lib/ld-linux-armhf.so.3 (0xb6f83000)
>     libvolk.so.2.2.1 => /opt/gnuradio-3.7.12git/lib/libvolk.so.2.2.1
> (0xb6b45000)
>     libboost_program_options.so.1.65.1 =>
> /usr/lib/arm-linux-gnueabihf/libboost_program_options.so.1.65.1
> (0xb6ade000)
>     libboost_filesystem.so.1.65.1 =>
> /usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.65.1 (0xb6abc000)
>     libboost_thread.so.1.65.1 =>
> /usr/lib/arm-linux-gnueabihf/libboost_thread.so.1.65.1 (0xb6a8f000)
>     librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6a79000)
>     libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0
> (0xb6a54000)
>     liblog4cpp.so.5 => /usr/lib/arm-linux-gnueabihf/liblog4cpp.so.5
> (0xb6a1e000)
>     libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb69c6000)
>     libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6945000)
>     liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0
> (0xb68e7000)
>
> Ron
>
> On 4/30/20 02:46, Johannes Demel wrote:
>> Hi Tom,
>>
>> ORC is a Tool that is used in VOLK to optimize some kernels. Though,
>> this is an optional dependency. ORC kernels are not built if liborc
>> etc is not found.
>>
>> I assume you can run example flowgraphs in GRC.
>> In this case, you shouldn't need to worry about ORC at all. Though,
>> somehow you try to link against it. Maybe it's worth a try to figure
>> out how ORC ends up in your `target_link_libraries`?
>>
>> I know, you fixed your issue by installing liborc*-dev but this should
>> not be necessary.
>>
>> Cheers
>> Johannes
>>
>>
>> On 30.04.20 09:37, Tom McDermott wrote:
>>> Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
>>> It is suggested by the make failure for the ported OOT module.
>>>
>>> Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
>>> and make completed successfully.  Thanks for the suggestion Vasil.
>>> Perhaps it's a dependency that is missing when installing grc on 20.04?
>>>
>>> With that, gr-hpsdr installed successfully on gr3.8, and the module
>>> instantiates
>>> in the flowgraph.  Now to start testing to see if it works...
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org
>>> <mailto:mmueller@gnuradio.org>> wrote:
>>>
>>>     Hi Tom,
>>>
>>>     nice hearing from you! I didn't know that hpsdr needed orc?
>>>
>>>     Best regards,
>>>     Marcus
>>>
>>>     On 29.04.20 22:46, Tom McDermott wrote:
>>>      > I am porting an OOT from 3.7 to 3.8.
>>>      > Ubuntu 20.04.  Gnuradio installed via apt install from the
>>>      > gnuradio-releases PPA.  GR 3.8.1
>>>      >
>>>      > It looks like all the modules are compiling OK, but am getting an
>>>     error.
>>>      >
>>>      > scanning dependencies of target gnuradio-hpsdr
>>>      > [ 12%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
>>>      > [ 25%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
>>>      > [ 37%] Building CXX object
>>>     lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
>>>      > [ 50%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
>>>      > [ 62%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
>>>      > make[2]: *** No rule to make target
>>>      > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>
>>>     <http://liborc-0.4.so>', needed
>>>      > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
>>>      > make[1]: *** [CMakeFiles/Makefile2:248:
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
>>>      > make: *** [Makefile:141: all] Error 2
>>>      >
>>>      >
>>>      > Not sure what liborc is.   Is this what's missing, or is it
>>>     something else?
>>>      > liborc-dev is listed as having no installation candidate for
>>> 20.04
>>>      >
>>>      > $ apt-cache policy liborc-dev
>>>      > liborc-dev:
>>>      >   Installed: (none)
>>>      >   Candidate: (none)
>>>      >   Version table:
>>>      >
>>>      >
>>>      >
>>>      > -- Tom, N5EG
>>>      >
>>>      >
>>>
>>
>

Re: porting OOT to gr3.8 Make failure

Hi Johannes, Ron,

The liborc-0.4.so gets linked because it is in INTERFACE_LINK_LIBRARIES in VolkTargets.cmake. This should be fixed in https://github.com/gnuradio/volk/pull/367 but a volk version with this fix is still not released.

Cheers,
Vasil

On 30/04/2020 13.32, Ron Economos wrote:
> I don't exactly know why, but liborc-0.4.so gets linked into even the simplest of OOT modules. Here's an example:
>
>     linux-vdso.so.1 (0xbef7b000)
>     libgnuradio-runtime.so.3.8.1 => /opt/gnuradio-3.7.12git/lib/libgnuradio-runtime.so.3.8.1 (0xb6eb0000)
>     libgnuradio-pmt.so.3.8.1 => /opt/gnuradio-3.7.12git/lib/libgnuradio-pmt.so.3.8.1 (0xb6e61000)
>     libboost_system.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_system.so.1.65.1 (0xb6e35000)
>     libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0xb6d22000)
>     libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6cf9000)
>     libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c01000)
>     /lib/ld-linux-armhf.so.3 (0xb6f83000)
>     libvolk.so.2.2.1 => /opt/gnuradio-3.7.12git/lib/libvolk.so.2.2.1 (0xb6b45000)
>     libboost_program_options.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_program_options.so.1.65.1 (0xb6ade000)
>     libboost_filesystem.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.65.1 (0xb6abc000)
>     libboost_thread.so.1.65.1 => /usr/lib/arm-linux-gnueabihf/libboost_thread.so.1.65.1 (0xb6a8f000)
>     librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6a79000)
>     libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6a54000)
>     liblog4cpp.so.5 => /usr/lib/arm-linux-gnueabihf/liblog4cpp.so.5 (0xb6a1e000)
>     libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb69c6000)
>     libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6945000)
>     liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0 (0xb68e7000)
>
> Ron
>
> On 4/30/20 02:46, Johannes Demel wrote:
>> Hi Tom,
>>
>> ORC is a Tool that is used in VOLK to optimize some kernels. Though, this is an optional dependency. ORC kernels are not built if liborc etc is not found.
>>
>> I assume you can run example flowgraphs in GRC.
>> In this case, you shouldn't need to worry about ORC at all. Though, somehow you try to link against it. Maybe it's worth a try to figure out how ORC ends up in your `target_link_libraries`?
>>
>> I know, you fixed your issue by installing liborc*-dev but this should not be necessary.
>>
>> Cheers
>> Johannes
>>
>>
>> On 30.04.20 09:37, Tom McDermott wrote:
>>> Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
>>> It is suggested by the make failure for the ported OOT module.
>>>
>>> Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
>>> and make completed successfully.  Thanks for the suggestion Vasil.
>>> Perhaps it's a dependency that is missing when installing grc on 20.04?
>>>
>>> With that, gr-hpsdr installed successfully on gr3.8, and the module instantiates
>>> in the flowgraph.  Now to start testing to see if it works...
>>>
>>> -- Tom, N5EG
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org <mailto:mmueller@gnuradio.org>> wrote:
>>>
>>>     Hi Tom,
>>>
>>>     nice hearing from you! I didn't know that hpsdr needed orc?
>>>
>>>     Best regards,
>>>     Marcus
>>>
>>>     On 29.04.20 22:46, Tom McDermott wrote:
>>>      > I am porting an OOT from 3.7 to 3.8.
>>>      > Ubuntu 20.04.  Gnuradio installed via apt install from the
>>>      > gnuradio-releases PPA.  GR 3.8.1
>>>      >
>>>      > It looks like all the modules are compiling OK, but am getting an
>>>     error.
>>>      >
>>>      > scanning dependencies of target gnuradio-hpsdr
>>>      > [ 12%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
>>>      > [ 25%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
>>>      > [ 37%] Building CXX object
>>>     lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
>>>      > [ 50%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
>>>      > [ 62%] Building CXX object
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
>>>      > make[2]: *** No rule to make target
>>>      > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>
>>>     <http://liborc-0.4.so>', needed
>>>      > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
>>>      > make[1]: *** [CMakeFiles/Makefile2:248:
>>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
>>>      > make: *** [Makefile:141: all] Error 2
>>>      >
>>>      >
>>>      > Not sure what liborc is.   Is this what's missing, or is it
>>>     something else?
>>>      > liborc-dev is listed as having no installation candidate for 20.04
>>>      >
>>>      > $ apt-cache policy liborc-dev
>>>      > liborc-dev:
>>>      >   Installed: (none)
>>>      >   Candidate: (none)
>>>      >   Version table:
>>>      >
>>>      >
>>>      >
>>>      > -- Tom, N5EG
>>>      >
>>>      >
>>>
>>
>

Re: porting OOT to gr3.8 Make failure

I don't exactly know why, but liborc-0.4.so gets linked into even the
simplest of OOT modules. Here's an example:

    linux-vdso.so.1 (0xbef7b000)
    libgnuradio-runtime.so.3.8.1 =>
/opt/gnuradio-3.7.12git/lib/libgnuradio-runtime.so.3.8.1 (0xb6eb0000)
    libgnuradio-pmt.so.3.8.1 =>
/opt/gnuradio-3.7.12git/lib/libgnuradio-pmt.so.3.8.1 (0xb6e61000)
    libboost_system.so.1.65.1 =>
/usr/lib/arm-linux-gnueabihf/libboost_system.so.1.65.1 (0xb6e35000)
    libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(0xb6d22000)
    libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6cf9000)
    libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6c01000)
    /lib/ld-linux-armhf.so.3 (0xb6f83000)
    libvolk.so.2.2.1 => /opt/gnuradio-3.7.12git/lib/libvolk.so.2.2.1
(0xb6b45000)
    libboost_program_options.so.1.65.1 =>
/usr/lib/arm-linux-gnueabihf/libboost_program_options.so.1.65.1 (0xb6ade000)
    libboost_filesystem.so.1.65.1 =>
/usr/lib/arm-linux-gnueabihf/libboost_filesystem.so.1.65.1 (0xb6abc000)
    libboost_thread.so.1.65.1 =>
/usr/lib/arm-linux-gnueabihf/libboost_thread.so.1.65.1 (0xb6a8f000)
    librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xb6a79000)
    libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0
(0xb6a54000)
    liblog4cpp.so.5 => /usr/lib/arm-linux-gnueabihf/liblog4cpp.so.5
(0xb6a1e000)
    libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb69c6000)
    libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xb6945000)
    liborc-0.4.so.0 => /usr/lib/arm-linux-gnueabihf/liborc-0.4.so.0
(0xb68e7000)

Ron

On 4/30/20 02:46, Johannes Demel wrote:
> Hi Tom,
>
> ORC is a Tool that is used in VOLK to optimize some kernels. Though,
> this is an optional dependency. ORC kernels are not built if liborc
> etc is not found.
>
> I assume you can run example flowgraphs in GRC.
> In this case, you shouldn't need to worry about ORC at all. Though,
> somehow you try to link against it. Maybe it's worth a try to figure
> out how ORC ends up in your `target_link_libraries`?
>
> I know, you fixed your issue by installing liborc*-dev but this should
> not be necessary.
>
> Cheers
> Johannes
>
>
> On 30.04.20 09:37, Tom McDermott wrote:
>> Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
>> It is suggested by the make failure for the ported OOT module.
>>
>> Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
>> and make completed successfully.  Thanks for the suggestion Vasil.
>> Perhaps it's a dependency that is missing when installing grc on 20.04?
>>
>> With that, gr-hpsdr installed successfully on gr3.8, and the module
>> instantiates
>> in the flowgraph.  Now to start testing to see if it works...
>>
>> -- Tom, N5EG
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org
>> <mailto:mmueller@gnuradio.org>> wrote:
>>
>>     Hi Tom,
>>
>>     nice hearing from you! I didn't know that hpsdr needed orc?
>>
>>     Best regards,
>>     Marcus
>>
>>     On 29.04.20 22:46, Tom McDermott wrote:
>>      > I am porting an OOT from 3.7 to 3.8.
>>      > Ubuntu 20.04.  Gnuradio installed via apt install from the
>>      > gnuradio-releases PPA.  GR 3.8.1
>>      >
>>      > It looks like all the modules are compiling OK, but am getting an
>>     error.
>>      >
>>      > scanning dependencies of target gnuradio-hpsdr
>>      > [ 12%] Building CXX object
>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
>>      > [ 25%] Building CXX object
>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
>>      > [ 37%] Building CXX object
>>     lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
>>      > [ 50%] Building CXX object
>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
>>      > [ 62%] Building CXX object
>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
>>      > make[2]: *** No rule to make target
>>      > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>
>>     <http://liborc-0.4.so>', needed
>>      > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
>>      > make[1]: *** [CMakeFiles/Makefile2:248:
>>      > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
>>      > make: *** [Makefile:141: all] Error 2
>>      >
>>      >
>>      > Not sure what liborc is.   Is this what's missing, or is it
>>     something else?
>>      > liborc-dev is listed as having no installation candidate for
>> 20.04
>>      >
>>      > $ apt-cache policy liborc-dev
>>      > liborc-dev:
>>      >   Installed: (none)
>>      >   Candidate: (none)
>>      >   Version table:
>>      >
>>      >
>>      >
>>      > -- Tom, N5EG
>>      >
>>      >
>>
>

Re: Problems with combining UDP and GMSK with FEC

Hi Quenten,

your Throttle is highly counter-productive:

Either, the source that streams UDP is inherently rate limited, then the
throttle does nothing, or it's not, then the throttle will lead to the
buffer of the UDP Source filling at some point, forcing it to drop samples.

(told you exactly this before, see my mail "Re: Frame drop when Using
GMSK en UDP" from 2020-04-24)

Best regards,
Marcus

On 30.04.20 10:36, Quenten . wrote:
> Hello to all,
>
> First before I explain the problem a little backstory:
>
> I am using a windows 10 PC and GNU radio v3.7.11 because if I go higher
> the bladeRF support doesn't work very well. I am trying to get a 'live'
> stream trough GNU radio.How I get this stream in GNU radio is as followed:
> 1) Stream with OBS to RTMP server
> 2) Use ffmpeg to get this 'live' stream to UDP
> 3)Use UDP source to put this in GRC
>
> After this I modulate this with GSMK and 'send' it wireless with the use
> of an bladeRF x115. Then receive this with an another bladeRF x115 and
> demodulate it to play the videostream on vlc or an other mediaplayer.
> But first I try to get it working in a simulation program. 
> (for flowgraph picture see attached)
>
> But when I try to run this simulation there are problems. I don't get a
> signal out.(see result1 picture). I have also tried to switch the fec
> decoder and packet decoder from place but then I don't get any signal in
> the f spectrum not even a 'zero' line and just a flat line in the time
> spectrum.
>
> A fellow user of this platform advised me to use /_packets or frames and
> also said to use ?zero padding? because I use convolutional codes. But
> couldn't say how to use this._/
>
> If anyone knows how to do this pls help me and let me know.
>
> Best regards,
>
> Q
>
> P.S.: To see the Mails click link below:
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00216.html  

Re: porting OOT to gr3.8 Make failure

Hi Tom,

ORC is a Tool that is used in VOLK to optimize some kernels. Though,
this is an optional dependency. ORC kernels are not built if liborc etc
is not found.

I assume you can run example flowgraphs in GRC.
In this case, you shouldn't need to worry about ORC at all. Though,
somehow you try to link against it. Maybe it's worth a try to figure out
how ORC ends up in your `target_link_libraries`?

I know, you fixed your issue by installing liborc*-dev but this should
not be necessary.

Cheers
Johannes


On 30.04.20 09:37, Tom McDermott wrote:
> Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
> It is suggested by the make failure for the ported OOT module.
>
> Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
> and make completed successfully.  Thanks for the suggestion Vasil.
> Perhaps it's a dependency that is missing when installing grc on 20.04?
>
> With that, gr-hpsdr installed successfully on gr3.8, and the module
> instantiates
> in the flowgraph.  Now to start testing to see if it works...
>
> -- Tom, N5EG
>
>
>
>
>
>
> On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@gnuradio.org>> wrote:
>
> Hi Tom,
>
> nice hearing from you! I didn't know that hpsdr needed orc?
>
> Best regards,
> Marcus
>
> On 29.04.20 22:46, Tom McDermott wrote:
> > I am porting an OOT from 3.7 to 3.8.
> > Ubuntu 20.04.  Gnuradio installed via apt install from the
> > gnuradio-releases PPA.  GR 3.8.1
> >
> > It looks like all the modules are compiling OK, but am getting an
> error.
> >
> > scanning dependencies of target gnuradio-hpsdr
> > [ 12%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
> > [ 25%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
> > [ 37%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
> > [ 50%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
> > [ 62%] Building CXX object
> > lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
> > make[2]: *** No rule to make target
> > '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>
> <http://liborc-0.4.so>', needed
> > by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
> > make[1]: *** [CMakeFiles/Makefile2:248:
> > lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
> > make: *** [Makefile:141: all] Error 2
> >
> >
> > Not sure what liborc is.   Is this what's missing, or is it
> something else?
> > liborc-dev is listed as having no installation candidate for 20.04
> >
> > $ apt-cache policy liborc-dev
> > liborc-dev:
> >   Installed: (none)
> >   Candidate: (none)
> >   Version table:
> >
> >
> >
> > -- Tom, N5EG
> >
> >
>

Problems with combining UDP and GMSK with FEC

Hello to all,

First before I explain the problem a little backstory:

I am using a windows 10 PC and GNU radio v3.7.11 because if I go higher the bladeRF support doesn't work very well. I am trying to get a 'live' stream trough GNU radio.How I get this stream in GNU radio is as followed:
1) Stream with OBS to RTMP server
2) Use ffmpeg to get this 'live' stream to UDP
3)Use UDP source to put this in GRC

After this I modulate this with GSMK and 'send' it wireless with the use of an bladeRF x115. Then receive this with an another bladeRF x115 and demodulate it to play the videostream on vlc or an other mediaplayer. But first I try to get it working in a simulation program. 
(for flowgraph picture see attached)

But when I try to run this simulation there are problems. I don't get a signal out.(see result1 picture). I have also tried to switch the fec decoder and packet decoder from place but then I don't get any signal in the f spectrum not even a 'zero' line and just a flat line in the time spectrum.

A fellow user of this platform advised me to use packets or frames and also said to use ?zero padding? because I use convolutional codes. But couldn't say how to use this.

If anyone knows how to do this pls help me and let me know.

Best regards,

Q

P.S.: To see the Mails click link below:

Re: porting OOT to gr3.8 Make failure

Hi Marcus, Vasil.   I have no idea what liborc is, nor why it is needed.
It is suggested by the make failure for the ported OOT module.

Focal Fossa had liborc-0.4 but not liborc-0.4-dev, so installed that
and make completed successfully.  Thanks for the suggestion Vasil.
Perhaps it's a dependency that is missing when installing grc on 20.04?

With that, gr-hpsdr installed successfully on gr3.8, and the module instantiates
in the flowgraph.  Now to start testing to see if it works...

-- Tom, N5EG






On Wed, Apr 29, 2020 at 2:58 PM Marcus Müller <mmueller@gnuradio.org> wrote:
Hi Tom,

nice hearing from you! I didn't know that hpsdr needed orc?

Best regards,
Marcus

On 29.04.20 22:46, Tom McDermott wrote:
> I am porting an OOT from 3.7 to 3.8.
> Ubuntu 20.04.  Gnuradio installed via apt install from the
> gnuradio-releases PPA.  GR 3.8.1
>
> It looks like all the modules are compiling OK, but am getting an error.
>
> scanning dependencies of target gnuradio-hpsdr
> [ 12%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
> [ 25%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
> [ 37%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
> [ 50%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
> [ 62%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
> make[2]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>', needed
> by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
> make[1]: *** [CMakeFiles/Makefile2:248:
> lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
> make: *** [Makefile:141: all] Error 2
>
>
> Not sure what liborc is.   Is this what's missing, or is it something else?
> liborc-dev is listed as having no installation candidate for 20.04
>
> $ apt-cache policy liborc-dev
> liborc-dev:
>   Installed: (none)
>   Candidate: (none)
>   Version table:
>
>
>
> -- Tom, N5EG
>
>

Wednesday, April 29, 2020

Re: gr3.8 gr_modtool lib/CmakeLists.txt error

Fixed by this commit:

https://github.com/gnuradio/gnuradio/commit/79ae0042ff0ec3c20f67820c11adae5442236274

That commit is included in GNU Radio 3.8.1.0

Ron

On 4/29/20 09:28, Tom McDermott wrote:
> Trying to port an OOT module to gr3.8.
>
> I generated a new 3.8 project from scratch using gr_modtool.
> Running cmake generates an error, and looking at the last mine of
> lib/CmakeLists.txt it appears that the
> generator may have incorrectly constructed the final line(s) of the
> file where it builds the qa files.
>
> Here's what was auto-generated by the tool:
>
> ...snip most...
>
> # If your unit tests require special include paths, add them here
> #include_directories()
> # List all files that contain Boost.UTF unit tests here
> list(APPEND test_hpsdr_sources
> )
> # Anything we need to link to for the unit tests go here
> list(APPEND GR_TEST_TARGET_DEPS gnuradio-hpsdr)
>
> if(NOT test_hpsdr_sources)
>     MESSAGE(STATUS "No C++ unit tests... skipping")
>     return()
> endif(NOT test_hpsdr_sources)
>
> foreach(qa_file ${test_hpsdr_sources})
>     GR_ADD_CPP_TEST("hpsdr_${qa_file}"
>         ${CMAKE_CURRENT_SOURCE_DIR}/${qa_file}
>     )
> endforeach(qa_file)
>     ${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesNB.cc
>  ${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesWB.cc
>
>
> Cmake is complaining about the last line not containing a command. 
> Note that the last line is also missing
> the trailing newline character. I added that, no change to the error.
>
> I resolved temporarily the problem by commenting out the very last
> line of the lib/CmakeLists.txt file, but then of course
> no tests get generated (but at least then the OOT Cmake completes).
>
> I'm not fluent in Cmake, so is it obvious how to fix?
>
> -- Tom, N5EG
>
>

Re: porting OOT to gr3.8 Make failure

Hi Tom,

nice hearing from you! I didn't know that hpsdr needed orc?

Best regards,
Marcus

On 29.04.20 22:46, Tom McDermott wrote:
> I am porting an OOT from 3.7 to 3.8.
> Ubuntu 20.04.  Gnuradio installed via apt install from the
> gnuradio-releases PPA.  GR 3.8.1
>
> It looks like all the modules are compiling OK, but am getting an error.
>
> scanning dependencies of target gnuradio-hpsdr
> [ 12%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
> [ 25%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
> [ 37%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
> [ 50%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
> [ 62%] Building CXX object
> lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
> make[2]: *** No rule to make target
> '/usr/lib/x86_64-linux-gnu/liborc-0.4.so <http://liborc-0.4.so>', needed
> by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
> make[1]: *** [CMakeFiles/Makefile2:248:
> lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
> make: *** [Makefile:141: all] Error 2
>
>
> Not sure what liborc is.   Is this what's missing, or is it something else?
> liborc-dev is listed as having no installation candidate for 20.04
>
> $ apt-cache policy liborc-dev
> liborc-dev:
>   Installed: (none)
>   Candidate: (none)
>   Version table:
>
>
>
> -- Tom, N5EG
>
>

Re: porting OOT to gr3.8 Make failure

Hi Tom,

On 29/04/2020 23.46, Tom McDermott wrote:
> $ apt-cache policy liborc-dev
> liborc-dev:
> Installed: (none)
> Candidate: (none)
> Version table:

The liborc-dev is a virtual package[1] and you can either install it or install liborc-4.0-dev.

$ apt-get install liborc-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'liborc-0.4-dev' instead of 'liborc-dev'


$ apt-cache policy liborc-0.4-dev
liborc-0.4-dev:
Installed: 1:0.4.31-1
Candidate: 1:0.4.31-1
Version table:
*** 1:0.4.31-1 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages
100 /var/lib/dpkg/status


[1] https://packages.ubuntu.com/focal/liborc-dev

Regards,
Vasil

porting OOT to gr3.8 Make failure

I am porting an OOT from 3.7 to 3.8.
Ubuntu 20.04.  Gnuradio installed via apt install from the gnuradio-releases PPA.  GR 3.8.1

It looks like all the modules are compiling OK, but am getting an error.

scanning dependencies of target gnuradio-hpsdr
[ 12%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/hermesNB_impl.cc.o
[ 25%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxy.cc.o
[ 37%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/metis.cc.o
[ 50%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/hermesWB_impl.cc.o
[ 62%] Building CXX object lib/CMakeFiles/gnuradio-hpsdr.dir/HermesProxyW.cc.o
make[2]: *** No rule to make target '/usr/lib/x86_64-linux-gnu/liborc-0.4.so', needed by 'lib/libgnuradio-hpsdr.so.1937293c'.  Stop.
make[1]: *** [CMakeFiles/Makefile2:248: lib/CMakeFiles/gnuradio-hpsdr.dir/all] Error 2
make: *** [Makefile:141: all] Error 2


Not sure what liborc is.   Is this what's missing, or is it something else?
liborc-dev is listed as having no installation candidate for 20.04

$ apt-cache policy liborc-dev
liborc-dev:
  Installed: (none)
  Candidate: (none)
  Version table:



-- Tom, N5EG


Problem with hidden addresses

Dear GNU Radio webmasters,

I am a GNU Radio user, currently subscribed on the <discuss-gnuradio@gnu.org> discussion list.
While trying to find some specific topics on the <https://lists.gnu.org/> website, I realized that inside a given discussion history (e.g. https://lists.gnu.org/archive/html/qemu-devel/2020-04/index.html), the e-mail addresses are hidden (address@hidden).
Nevertheless, if I type any name on the search engine here: <https://lists.gnu.org/archive/html/discuss-gnuradio/>, then the complete e-mail address is available.

Could you check that, please?

Thanks in advance.

Best regards,
Artur


Re: Hidden e-mail address

Sure, I'll do that. Shall I put this list in copy or it is not necessary?

Em qua., 29 de abr. de 2020 às 11:49, Andrej Rode <mail@andrejro.de> escreveu:
Good catch,

seems like the address scrubbing to reduce the amount of crawlable mail
addresses works for displaying single mails but is not done for
presenting the results of the search query.

Either a bug in mailman or in the GNU lists configuration. Worth
reporting, will you do that? (the correct mail address should be at the
bottom of the page)'

Cheers
Andrej

On Wed, 29 Apr 2020 10:34:28 -0300
Artur Nogueira <artur.nogsj@gmail.com> wrote:

> The problem is: when I type my name on the search engine here:
> https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is
> visible (I also typed other names and the same happens...)
>
> Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller
> <mmueller@gnuradio.org> escreveu:
>
> > Looks pretty hidden to me:
> >
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
> >
> > or am I misinterpreting this?
> >
> > On 29.04.20 04:06, Artur Nogueira wrote: 
> > > Hello all,
> > >
> > > I was recently looking for some specific topics
> > > on https://lists.gnu.org/ and I realized that many e-mail
> > > addresses appear like address@hidden <mailto:address@hidden>
> > > there. How do I do to get my e-mail address hidden in the same
> > > way?
> > >
> > > Best regards,
> > > Artur 
> > 


Re: R: Again on FCDPROPLUS

Dear Vincenzo,

copying and pasting correctly is necessary!

Best regards,
Marcus

On 28/04/2020 10.53, Vincenzo Mone wrote:
> Hello Barry,
> Thanks also to you for the help, but the problem is everyone is trying to
> help me
> Saying what to do as I know how Linux works.
> Unfortunately I am a beginner user and do not know anything about Linux.
> Just starting and following all you suggestions but the problem is I do not
> understand
> What to do if some says for example start as administrator as how I saw it
> is different from windows O.S.
>
> BTW I have tried how you suggested me but it did not work maybe because how
> I said before
> Did not do correctly the commands.
> Here is what I've done:
> I have opened the Terminal and typed gedit which is the editor.
> Pasted the 4 lines.
> Closed the file saving it in Enzo which is the folder I see on the Desktop
> Always in the terminal I have typed:
>
> sudo cp -v ~/Desktop/enzo/99-usb-serial.rules
>
> but after have inserted the requested password I got the error:
>
>
> cp: missing destination file operand after
> '/home/enzo/Desktop/enzo/99-usb-serial.rules'
>
> Where am I still missing?
>
> Finally you said to be sure to set the Device name; mine is
> "hw:CARD=V20,DEV=0"
> How to know the Device name?
> I can just say that it is a Funcube Dongle Pro Plus.
> Thanks to you and to everyone and please apologise if I am bothering
> somebody
>
>
> 73 de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
>
>
>
>
>       *********************************
>       ******  GSM  +39 328 7110193  ******
>       *****  SMS  +39 328 7110193   *****
>       *********************************
>
>> -----Messaggio originale-----
>> Da: Barry Duggan <barry@dcsmail.net>
>> Inviato: martedì 28 aprile 2020 01:48
>> A: vimone@alice.it
>> Cc: Discuss Gnuradio <discuss-gnuradio@gnu.org>
>> Oggetto: Re: Again on FCDPROPLUS
>>
>> Vincenzo,
>>
>> Here is what you need to do to set up udev rules:
>>
>> In any of your folders (<your folder>), create a file named '99-usb-
>> serial.rules' with the following content:
>>
>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb31"
>> MODE:="0666"
>>
>> Save the file. Then, in a Terminal screen:
>>
>> cd /etc/udev/rules.d
>> sudo cp -v ~/<your folder>/99-usb-serial.rules . # note the
>> period!
>> sudo udevadm trigger
>>
>> Be sure to set the Device name; mine is "hw:CARD=V20,DEV=0" (without the
>> quotes). If that doesn't work, follow the procedure in
>> https://wiki.gnuradio.org/index.php/Audio_Source#Device_Name starting
>> with "For Linux ALSA users...".
>>
>> Let me know how it works for you.
>> --
>> Barry Duggan KV4FV
>>
>> On Sun, 26 Apr 2020 18:29:17 +0200, Vincenzo Mone wrote:
>>
>> Hello,
>>
>> Please I have a doubt.
>>
>> Reading on the FCDPROPLUS site I read:
>>
>> Important
>> Don't forget the udev rules: For instance:
>>
>> Udev rules for the Funcube Dongle Pro (0xfb56) and Pro+ (0xfb31)
>>
>> HIDAPI/libusb:
>>
>> SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8" ATTRS{idProduct}=="fb56"
>> MODE:="0666" SUBSYSTEMS=="usb" ATTRS{idVendor}=="04d8"
>> ATTRS{idProduct}=="fb31" MODE:="0666"
>>
>> HIDAPI/hidraw:
>>
>> KERNEL=="hidraw*", ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
>> ATTRS{idProduct}=="fb56", MODE="0666" KERNEL=="hidraw*",
>> ATTRS{busnum}=="1", ATTRS{idVendor}=="04d8",
>> ATTRS{idProduct}=="fb31",
>> MODE="0666
>>
>> Please what does it means?
>>
>> Maybe I am missing something.
>>
>> Any help?
>>
>> Thanks
>>
>> 73 de Enzo IK8OZV
>> EasyLog 5 BetaTester
>> EasyLog PDA BetaTester
>> WinBollet BetaTester
>> D.C.I. CheckPoint Regione Campania
>> Skype: ik8ozv8520
>
>

Re: FCDPROPLUS Errors

Vincenzo,

you have complained multiple times that different people respond with
multiple things.

You will not improve your confusion if you start a new thread all the
time. That is **literally** asking for different people to look at your
email in isolation!

Best regards,
Marcus.

On 29/04/2020 14.39, Vincenzo Mone wrote:
> Hi Folks,
>
> It seems I got all OK since I do not try to install FCDPROPLUS.
>
> This is what I have done:
>
> git clone https://github.com/dl1ksv/gr-fcdproplus
>
> cd gr-fcdproplus/
>
> mkdir build
>
> cd build
>
> cmake -DCMAKE_INSTALL_PREFIX= \usr ../
>
> With the last command I got errors:
>
> -- The CXX compiler identification is GNU 7.5.0
>
> -- The C compiler identification is GNU 7.5.0
>
> -- Check for working CXX compiler: /usr/bin/c++
>
> -- Check for working CXX compiler: /usr/bin/c++ -- works
>
> -- Detecting CXX compiler ABI info
>
> -- Detecting CXX compiler ABI info - done
>
> -- Detecting CXX compile features
>
> -- Detecting CXX compile features - done
>
> -- Check for working C compiler: /usr/bin/cc
>
> -- Check for working C compiler: /usr/bin/cc -- works
>
> -- Detecting C compiler ABI info
>
> -- Detecting C compiler ABI info - done
>
> -- Detecting C compile features
>
> -- Detecting C compile features - done
>
> -- Build type not specified: defaulting to release.
>
> -- Found LOG4CPP: /usr/lib/x86_64-linux-gnu/liblog4cpp.so
>
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
>
> -- Checking for module 'gmp'
>
> --   Found gmp, version 6.2.0
>
> -- Found GMP: /usr/lib/x86_64-linux-gnu/libgmpxx.so
>
> -- Checking for module 'mpir >= 3.0'
>
> --   No package 'mpir' found
>
> -- Could NOT find MPIR (missing: MPIRXX_LIBRARY MPIR_INCLUDE_DIR)
>
> -- Found MPLIB: /usr/lib/x86_64-linux-gnu/libgmpxx.so
>
> -- Looking for pthread.h
>
> -- Looking for pthread.h - found
>
> -- Looking for pthread_create
>
> -- Looking for pthread_create - not found
>
> -- Looking for pthread_create in pthreads
>
> -- Looking for pthread_create in pthreads - not found
>
> -- Looking for pthread_create in pthread
>
> -- Looking for pthread_create in pthread - found
>
> -- Found Threads: TRUE
>
> -- Boost version: 1.65.1
>
> -- Found the following Boost libraries:
>
> --   date_time
>
> --   program_options
>
> --   filesystem
>
> --   system
>
> --   regex
>
> --   thread
>
> --   unit_test_framework
>
> --   chrono
>
> --   atomic
>
> -- Found VOLK: Volk::volk
>
> -- User set python executable /usr/bin/python3
>
> -- Found PythonInterp: /usr/bin/python3 (found version "3.6.9")
>
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found
> suitable exact version "3.6.9")
>
> -- Checking for module 'alsa'
>
> --   Found alsa, version 1.1.3
>
> -- Found ALSA 1.1.3
>
> -- Checking for module 'jack'
>
> --   Found jack, version 0.125.0rc1
>
> -- Found jack: /usr/lib/x86_64-linux-gnu/libjack.so
>
> -- Checking for module 'portaudio-2.0'
>
> --   Found portaudio-2.0, version 19
>
> -- Performing Test PORTAUDIO2_FOUND
>
> -- Performing Test PORTAUDIO2_FOUND - Success
>
> -- Found PORTAUDIO: /usr/include
>
> -- Found Git: /usr/bin/git
>
> -- Extracting version information from git describe...
>
> -- Checking for module 'libusb-1.0'
>
> --   Found libusb-1.0, version 1.0.21
>
> -- Found libusb-1.0: /usr/include/libusb-1.0,
> /usr/lib/x86_64-linux-gnu/libusb-1.0.so
>
> -- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") found
> components:  doxygen missing components:  dot
>
> --
>
> -- Checking for module SWIG
>
> -- Found SWIG version 3.0.12.
>
> -- Found SWIG: /usr/bin/swig3.0
>
> -- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found
> version "3.6.9")
>
> -- Doxxyfile found in DOXY_FILE_PATH-NOTFOUND
>
> CMake Error: File
> /home/enzo/gr-fcdproplus/swig/DOXY_FILE_PATH-NOTFOUND/Doxyfile.swig_doc.in
> does not exist.
>
> CMake Error at cmake/Modules/GrSwig.cmake:65 (configure_file):
>
>   configure_file Problem configuring file
>
> Call Stack (most recent call first):
>
>   cmake/Modules/GrSwig.cmake:121 (GR_SWIG_MAKE_DOCS)
>
>   swig/CMakeLists.txt:41 (GR_SWIG_MAKE)
>
> CMake Error: File
> /home/enzo/gr-fcdproplus/docs/doxygen/DOXY_FILE_PATH-NOTFOUND/Doxyfile.in does
> not exist.
>
> CMake Error at docs/doxygen/CMakeLists.txt:33 (configure_file):
>
>   configure_file Problem configuring file
>
> -- ================ Build Summary =========================
>
> -- Building gr-fcdproplus  : 3.8.0 for Linux
>
> -- Building for gnuradio   : 3.8.1.0
>
> -- Using CMAKE Module path :
> /home/enzo/gr-fcdproplus/cmake/Modules;/usr/lib/x86_64-linux-gnu/cmake/gnuradio
>
> -- CMake Modules Dir       : lib/cmake
>
> -- fcdproplus INCLUDES     : include/fcdproplus
>
> -- Using install prefix    :
>
> -- Installing grc files to : /share/gnuradio/grc/blocks
>
> -- Bundled hidapi is used
>
> -- ========================================================
>
> -- Configuring incomplete, errors occurred!
>
> See also "/home/enzo/gr-fcdproplus/build/CMakeFiles/CMakeOutput.log".
>
> See also "/home/enzo/gr-fcdproplus/build/CMakeFiles/CMakeError.log".
>
> If I understood it does'nt find the mpir but I have installed it with
> this procedure:
>
> git clone git://github.com/wbhart/mpir.git mpir
>
> cd mpir
>
> ./autogen.sh
>
> ./configure
>
> make
>
> sudo make install
>
> sudo ldconfig
>
> I can also read :
>
> Doxxyfile found in DOXY_FILE_PATH-NOTFOUND
>
> CMake Error: File
> /home/enzo/gr-fcdproplus/swig/DOXY_FILE_PATH-NOTFOUND/Doxyfile.swig_doc.in
> does not exist
>
> CMake Error at docs/doxygen/CMakeLists.txt:33 (configure_file):
>
> configure_file Problem configuring file
>
> But also here I have installed Doxygen with this procedure:
>
> sudo apt-get install doxygen
>
> Please what to do?
>
> Thanks for helps
>
> 73 de Enzo IK8OZV
> EasyLog 5 BetaTester
> EasyLog PDA BetaTester
> WinBollet BetaTester
> D.C.I. CheckPoint Regione Campania
> Skype: ik8ozv8520
>
>
>
>
>       *********************************
>
> ******   GSM  +39 328 7110193  ******
>
>       *****     SMS  +39 328 7110193    *****
>
>       *********************************
>

gr3.8 gr_modtool lib/CmakeLists.txt error

Trying to port an OOT module to gr3.8.

I generated a new 3.8 project from scratch using gr_modtool. 
Running cmake generates an error, and looking at the last mine of lib/CmakeLists.txt it appears that the
generator may have incorrectly constructed the final line(s) of the file where it builds the qa files.

Here's what was auto-generated by the tool:

...snip most...

# If your unit tests require special include paths, add them here
#include_directories()
# List all files that contain Boost.UTF unit tests here
list(APPEND test_hpsdr_sources
)
# Anything we need to link to for the unit tests go here
list(APPEND GR_TEST_TARGET_DEPS gnuradio-hpsdr)

if(NOT test_hpsdr_sources)
    MESSAGE(STATUS "No C++ unit tests... skipping")
    return()
endif(NOT test_hpsdr_sources)

foreach(qa_file ${test_hpsdr_sources})
    GR_ADD_CPP_TEST("hpsdr_${qa_file}"
        ${CMAKE_CURRENT_SOURCE_DIR}/${qa_file}
    )
endforeach(qa_file)
    ${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesNB.cc    ${CMAKE_CURRENT_SOURCE_DIR}/qa_hermesWB.cc


Cmake is complaining about the last line not containing a command.  Note that the last line is also missing
the trailing newline character. I added that, no change to the error.

I resolved temporarily the problem by commenting out the very last line of the lib/CmakeLists.txt file, but then of course
no tests get generated (but at least then the OOT Cmake completes).

I'm not fluent in Cmake, so is it obvious how to fix?

-- Tom, N5EG


Re: Hidden e-mail address

Fun fact: hiding works in qemu-devel's search

On 29/04/2020 16.46, Andrej Rode wrote:
> Good catch,
>
> seems like the address scrubbing to reduce the amount of crawlable mail
> addresses works for displaying single mails but is not done for
> presenting the results of the search query.
>
> Either a bug in mailman or in the GNU lists configuration. Worth
> reporting, will you do that? (the correct mail address should be at the
> bottom of the page)'
>
> Cheers
> Andrej
>
> On Wed, 29 Apr 2020 10:34:28 -0300
> Artur Nogueira <artur.nogsj@gmail.com> wrote:
>
>> The problem is: when I type my name on the search engine here:
>> https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is
>> visible (I also typed other names and the same happens...)
>>
>> Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller
>> <mmueller@gnuradio.org> escreveu:
>>
>>> Looks pretty hidden to me:
>>>
>>> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
>>>
>>> or am I misinterpreting this?
>>>
>>> On 29.04.20 04:06, Artur Nogueira wrote:
>>>> Hello all,
>>>>
>>>> I was recently looking for some specific topics
>>>> on https://lists.gnu.org/ and I realized that many e-mail
>>>> addresses appear like address@hidden <mailto:address@hidden>
>>>> there. How do I do to get my e-mail address hidden in the same
>>>> way?
>>>>
>>>> Best regards,
>>>> Artur
>>>
>
>

Re: Hidden e-mail address

Good catch,

seems like the address scrubbing to reduce the amount of crawlable mail
addresses works for displaying single mails but is not done for
presenting the results of the search query.

Either a bug in mailman or in the GNU lists configuration. Worth
reporting, will you do that? (the correct mail address should be at the
bottom of the page)'

Cheers
Andrej

On Wed, 29 Apr 2020 10:34:28 -0300
Artur Nogueira <artur.nogsj@gmail.com> wrote:

> The problem is: when I type my name on the search engine here:
> https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is
> visible (I also typed other names and the same happens...)
>
> Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller
> <mmueller@gnuradio.org> escreveu:
>
> > Looks pretty hidden to me:
> >
> > https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
> >
> > or am I misinterpreting this?
> >
> > On 29.04.20 04:06, Artur Nogueira wrote:
> > > Hello all,
> > >
> > > I was recently looking for some specific topics
> > > on https://lists.gnu.org/ and I realized that many e-mail
> > > addresses appear like address@hidden <mailto:address@hidden>
> > > there. How do I do to get my e-mail address hidden in the same
> > > way?
> > >
> > > Best regards,
> > > Artur
> >

Re: How to add fec in GMSK

Hello Quenten:


I am afraid that I do not know what is causing the problem that you are experienceing (regarding the text editor); sorry about that. It worked when I tried it on Windows before, so it may have to do with that particular version, or maybe your system environments.

Regards,
Kyeong Su Shin

보낸 사람: Quenten . <quentenswitten@gmail.com>
보낸 날짜: 2020년 4월 29일 수요일 오후 10:28
받는 사람: Kyeong Su Shin <ksshin@postech.ac.kr>; discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
제목: Re: How to add fec in GMSK
 
Hello,

Thank you for your reply. But if it is needed to make my own block then I am in trouble. This is because in the version of GRC I use (3.7.11) there is something wrong with opening the editor in the python block (I tried the default, notepad++, notepad, pyscripter ,.. => none will open)

But still thank for your useful advice I will try.

Best regards,

Q

Op wo 29 apr. 2020 om 15:06 schreef Kyeong Su Shin <ksshin@postech.ac.kr>:
Hello Quenten:

Hamming code is just an example, I am not suggesting you to implement it.  What I want to say is that, the decoder usually needs to know where the code block starts and where it ends in order to correctly decode it, just like in case of the Hamming code. That is why you need to use packets or frames in this situation. You need to align your data for the decoder before putting it in.

Since the whole point of using frames or packets (in this case) is to align your data for the FEC decoder, you want to make sure that each frame (or packet) contains nicely aligned encoded code blocks. If it doesn't, then it is pretty much useless. If the frame generator or packet generator requires zero paddings in order to achieve this, then you do the zero padding (you can strip the paddings before pusing the data to the decoder). Also, this generally means that you will want to fix the payload size of your packets or frames to some integer multiple of the code length (clearly, this is not about the UDP payload size).

Also, zero paddings are often necessary for convolutional codes, which you are using. I do not remember the exact math behind this, so you will have to rely on a textbook (or maybe someone else's reply).  GNU Radio's cc_encoder will help you with this, but I do not remember if it is sufficient. See: https://www.gnuradio.org/doc/doxygen/classgr_1_1fec_1_1code_1_1cc__encoder.html .

For packetized data, you can refer to example codes at https://github.com/gnuradio/gnuradio/tree/maint-3.7/gr-digital/examples/packet . You can also write your own GNU Radio blocks, as suggested in https://wiki.gnuradio.org/index.php/Tutorials . Writing blocks can be a bit difficult on a Windows system, however (works better on Linux). In that way, pretty much anything is possible (You can still write Embedded Python Blocks on Windows without much hassle).

Regards,
Kyeong Su Shin

보낸 사람: Quenten . <quentenswitten@gmail.com>
보낸 날짜: 2020년 4월 29일 수요일 오후 9:15
받는 사람: Kyeong Su Shin <ksshin@postech.ac.kr>
참조: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
제목: Re: How to add fec in GMSK
 
Hello,

Yes I know what hamming code is(I have had the theory but also only the theory, no real life experience). 
But I don't know any way how to add it in GNU radio (A lot of examples on the internet used a LP, and yeah i know not everything on the internet can be trusted). 
What I am doing here with this 'test' flowgraph is to try to solve the problem the I had in this post: https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00148.html. I also tested just the source and sink with the packet en-/decoder but there wasn't even a output signal (so I will not use these anymore unless suggested otherwise).

And you tals about :add paddings and tails on your packets and fix the paylod size to a certain number to get things working. Why Where and how  do you  do it.
Ps if you are talking about the payloadsize of the UDP I have already adjusted these so they work without the '(de)modulation techniques'(UDP source to sink).

Someone advised me that this could be  possibly solved with using FEC

Op wo 29 apr. 2020 om 10:44 schreef Kyeong Su Shin <ksshin@postech.ac.kr>:
Hello Quenten:

"Hamming Code" is a type of an forward-error correction code (FEC). See: https://en.wikipedia.org/wiki/Hamming_code . It is not related to low-pass filtering (you really should not have that there).  I mentioned Hamming Code because it is usually the first code that you learn in the school.

For an example, Hamming(7,4) takes a 4-bit data, and generates a 7-bit code. That means, if you use Hamming(7,4), the payload size of the "Oacket Encoder" (which you really shoudn't be using, but I guess you already know that) must be an integer multiple of 7 (bits). If you don't do that, you will need to implement additional handling processes to fix that.

In your flow graph, you are using Convolutional Code (which is not a linear code), instead of Hamming Code (which makes sense, as Hamming Code usually makes little sense on wireless communication system). Still, you have to take similar issues into your consideration. I don't remember the exact details (I didn't use Convolutional code much), but you may have to add paddings and tails on your packets and fix the paylod size to a certain number to get things working (go through WiFi OFDM PLCP and WiFi convolutional code tutorials, if you are sticking with Convolutional code).

Also, I do not see the "Packet Decoder" in your flowgraph.

WX GUI is no longer supported, and some error messages that you posted are about WX GUI, so consider using QT GUI instead.

Finally, please note that it will still miss some packets (mostly during the beginning of the transmission).

(I added discuss-gnuardio@gnu.org back to the recipant list.)

Regards,
Kyeong Su Shin

보낸 사람: Quenten . <quentenswitten@gmail.com>
보낸 날짜: 2020년 4월 29일 수요일 오후 4:57
받는 사람: Kyeong Su Shin <ksshin@postech.ac.kr>
제목: Re: How to add fec in GMSK
 
hello, Kyeong Su Shin,

I added hamming with a low pass filter(only way I know how to add Hamming in flowgraph) but when I run this is get the following results from GNU:

bits per symbol = 1
Gaussian filter bt = 0.35
bits per symbol = 1
M&M clock recovery omega = 4.000000
M&M clock recovery gain mu = 0.175000
M&M clock recovery mu = 0.500000
M&M clock recovery omega rel. limit = 0.005000
frequency error = 0.000000
Warning: the blks2.packet_encoder block is deprecated.        
(I know why these are here)  
Warning: the blks2.packet_decoder block is deprecated.        
(I know why these are here)
gr::pagesize: no info; setting pagesize = 4096
C:\Program Files\GNURadio-3.7\gr-python27\lib\site-packages\numpy-1.12.0-py2.7-win-amd64.egg\numpy\core\_methods.py:116: RuntimeWarning: overflow encountered in multiply
  x = um.multiply(x, x, out=x)
C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\wxgui\common.py:272: RuntimeWarning: invalid value encountered in add
  return mean - factor*ampl, mean + factor*ampl
C:\Program Files\GNURadio-3.7\lib\site-packages\gnuradio\wxgui\common.py:272: RuntimeWarning: invalid value encountered in subtract
  return mean - factor*ampl, mean + factor*ampl


For the result ofthe graphs see file attached.


I added the Low Pass in the original Grc before the Gmsk Demod, as can be seen below:



Best regards,


Q


Op ma 27 apr. 2020 om 17:50 schreef Kyeong Su Shin <ksshin@postech.ac.kr>:
Hello Quenten:

Just to elaborate a bit further:  If you did something that is suggested in the example files, and failed to get your flowgraph working, it is probably because your data is no longer frame-synchronized after the mod / demod blocks (yes, that happens, both in simulations and in real-world environments), and error correction codes usually require them to be frame-synchronized.  So, what you will have to look into is frame sync or packet design.

Also, you will have to design your frames with your FEC algorithm in your mind. Simple linear-algebraic algorithms, like Hamming code, will require you to set your frame length to a multiple of some integer. Convolutional code additionally requires you to pad some zeros to your frames, but I forgot the details about it. 

Regards,
Kyeong Su Shin


보낸 사람: Kyeong Su Shin <ksshin@postech.ac.kr>
보낸 날짜: 2020년 4월 28일 화요일 오전 12:23
받는 사람: Quenten . <quentenswitten@gmail.com>; discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
제목: Re: How to add fec in GMSK
 
Hello Quenten:

You may want to look at some example codes at https://github.com/gnuradio/gnuradio/tree/maint-3.7/gr-fec/examples  (from maint-3.7 branch since you are apparently using GR3.7).  

Please note that most error correction codes require frame synchronization (at least on real-world situations).

Regards,
Kyeong Su Shin

보낸 사람: Quenten . <quentenswitten@gmail.com> 대신 Discuss-gnuradio <discuss-gnuradio-bounces+ksshin=postech.ac.kr@gnu.org>
보낸 날짜: 2020년 4월 27일 월요일 오후 10:31
받는 사람: discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
제목: How to add fec in GMSK
 
Hello all,

I have previous posted a question concerning frame drops in GNU radio when using GMSK. (https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00148.html)
On this mail someone answered that I should use OFMD (what I normally should consider because this is better), but my prof told me to focus on GMSK and also told me to include FEC. I know with one I should use, it is either the FEC en-/decoder or the Extended FEC en-/decode, because I shall stream data cte. 
So my question is how do you include this because I have tried but didn't succeed.
In the file attached you will find the grc with the FEC en-/decoder. Help would be appreciated.

Best regards,

Q