**16 January 2021 16:00 UTC**
Subject: Using GRC to build radios: Make the flow graph work for you
Presenter: John Petrich W7FU
Agenda:
* Getting started with GRC
* Basic flow graph workspace organization
* Flow graph details
* Data flow problem solving
* Practical odds and ends for real radios
* Group discussion
See the details at
https://wiki.gnuradio.org/index.php/Talk:HamRadio#16_January_2021_16:00_UTC
No registration required.
73,
---
Barry Duggan KV4FV
https://github.com/duggabe
Thursday, December 31, 2020
Sunday, December 27, 2020
Re: Tag or message to GUI indicator
Thank you for your help.
With the mentioned settings it signals well and provides better automation of measurements.
Kind regards,
Marcin Wachowiak
On Thu, 24 Dec 2020 at 04:39, Jacob Gilbert <mrjacobagilbert@gmail.com> wrote:
Hi MarcinYou can use the QT Edit Box Message block to display the contents of a message on a GR GUI, there are some limitations but it might fit your need.Use the block with string type input, not in pair mode, not in static mode. You can publish a message consisting of just a PMT string and that string will show up in the box. It's not perfect, and the user can modify the contents of the box but might work for you.JacobOn Tue, Dec 22, 2020, 06:29 Marcin Wachowiak <marcin.r.wachowiak@gmail.com> wrote:Hello,May I ask what is the best way to visualize tags or messages in GR GUI?For example: there is a head block with reset function that each time it has processed specified number of samples sends tag or message "FINISHED".I am looking for a way this tag or message would affect a variable or some GUI element. Dumping tags or messages to terminal via debug block is quite neat , but is there any possibility to show all information in GUI (in a form of simple indicator: True/False or value)?.I didn't wanted to employ any streams or sources triggered by tag or message to reduce resources utilization.Kind regards,Marcin Wachowiak
Saturday, December 26, 2020
Re: Error when compiling gr-soapy and gr-osmosdr
Hi Bernt - you should probably be using 3.8 if you're just starting to
test the water.
See
https://wiki.gnuradio.org/index.php/InstallingGR
under
For GNU Radio 3.8 or Earlier
using git.
-- Cinaed
On 12/26/20 7:11 AM, Bernt Hustad Hembre wrote:
> Hi all,
>
> I'm new here, so I apologize for not beeing fully up to speed on all
> aspects of gnuradio.
>
> I'm trying to compile gnuradio and modules/libraries I need to play
> around with it.
>
> So far I have compiled gnuradio from source (master branch).And it
> works as expected.
> I'm now trying to get mye RTL-SDR dongle to work. I've tried to
> compile both Soapy and gr-osmosdr. But both attempts fails the same way.
>
> This is the error I get while running cmake on gr-soapy:
>
> CMake Error at swig/CMakeLists.txt:37 (include):
> include could not find load file:
>
> GrSwig
>
>
> CMake Error at swig/CMakeLists.txt:54 (GR_SWIG_MAKE):
> Unknown CMake command "GR_SWIG_MAKE".
>
> And simile when running cmake in the build dir of gr-osmosdr:
> CMake Error at swig/CMakeLists.txt:28 (include):
> include could not find load file:
>
> GrSwig
>
>
> CMake Error at swig/CMakeLists.txt:42 (GR_SWIG_MAKE):
> Unknown CMake command "GR_SWIG_MAKE".
>
> swig is installed (SWIG Version 4.0.1)
>
> Do I need to get the .cmake files for gr-swig from som other source,
> like the gnuradio source folder?
> Can anyone point me in the right direction here?
>
> Cheers!
> Bernie
>
>
>
test the water.
See
https://wiki.gnuradio.org/index.php/InstallingGR
under
For GNU Radio 3.8 or Earlier
using git.
-- Cinaed
On 12/26/20 7:11 AM, Bernt Hustad Hembre wrote:
> Hi all,
>
> I'm new here, so I apologize for not beeing fully up to speed on all
> aspects of gnuradio.
>
> I'm trying to compile gnuradio and modules/libraries I need to play
> around with it.
>
> So far I have compiled gnuradio from source (master branch).And it
> works as expected.
> I'm now trying to get mye RTL-SDR dongle to work. I've tried to
> compile both Soapy and gr-osmosdr. But both attempts fails the same way.
>
> This is the error I get while running cmake on gr-soapy:
>
> CMake Error at swig/CMakeLists.txt:37 (include):
> include could not find load file:
>
> GrSwig
>
>
> CMake Error at swig/CMakeLists.txt:54 (GR_SWIG_MAKE):
> Unknown CMake command "GR_SWIG_MAKE".
>
> And simile when running cmake in the build dir of gr-osmosdr:
> CMake Error at swig/CMakeLists.txt:28 (include):
> include could not find load file:
>
> GrSwig
>
>
> CMake Error at swig/CMakeLists.txt:42 (GR_SWIG_MAKE):
> Unknown CMake command "GR_SWIG_MAKE".
>
> swig is installed (SWIG Version 4.0.1)
>
> Do I need to get the .cmake files for gr-swig from som other source,
> like the gnuradio source folder?
> Can anyone point me in the right direction here?
>
> Cheers!
> Bernie
>
>
>
Re: Error when compiling gr-soapy and gr-osmosdr
gr-soapy has not yet been ported to GNU Radio 3.9. There is a partial gr-osmosdr port for GNU Radio 3.9 (gr3.9 branch at https://github.com/fventuri/gr-osmosdr). Python support is not complete.
On Sat, Dec 26, 2020 at 10:13 AM Bernt Hustad Hembre <bernthustadhembre@gmail.com> wrote:
Hi all,I'm new here, so I apologize for not beeing fully up to speed on all aspects of gnuradio.I'm trying to compile gnuradio and modules/libraries I need to play around with it.So far I have compiled gnuradio from source (master branch).And it works as expected.I'm now trying to get mye RTL-SDR dongle to work. I've tried to compile both Soapy and gr-osmosdr. But both attempts fails the same way.This is the error I get while running cmake on gr-soapy:CMake Error at swig/CMakeLists.txt:37 (include):
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:54 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".And simile when running cmake in the build dir of gr-osmosdr:CMake Error at swig/CMakeLists.txt:28 (include):
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:42 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".swig is installed (SWIG Version 4.0.1)Do I need to get the .cmake files for gr-swig from som other source, like the gnuradio source folder?Can anyone point me in the right direction here?Cheers!Bernie
Error when compiling gr-soapy and gr-osmosdr
Hi all,
I'm new here, so I apologize for not beeing fully up to speed on all aspects of gnuradio.
I'm trying to compile gnuradio and modules/libraries I need to play around with it.
So far I have compiled gnuradio from source (master branch).And it works as expected.
I'm now trying to get mye RTL-SDR dongle to work. I've tried to compile both Soapy and gr-osmosdr. But both attempts fails the same way.
This is the error I get while running cmake on gr-soapy:
CMake Error at swig/CMakeLists.txt:37 (include):
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:54 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:54 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
And simile when running cmake in the build dir of gr-osmosdr:
CMake Error at swig/CMakeLists.txt:28 (include):
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:42 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
include could not find load file:
GrSwig
CMake Error at swig/CMakeLists.txt:42 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
swig is installed (SWIG Version 4.0.1)
Do I need to get the .cmake files for gr-swig from som other source, like the gnuradio source folder?
Can anyone point me in the right direction here?
Cheers!
Bernie
Wednesday, December 23, 2020
Re: Tag or message to GUI indicator
Hi Marcin
You can use the QT Edit Box Message block to display the contents of a message on a GR GUI, there are some limitations but it might fit your need.
Use the block with string type input, not in pair mode, not in static mode. You can publish a message consisting of just a PMT string and that string will show up in the box. It's not perfect, and the user can modify the contents of the box but might work for you.
Jacob
On Tue, Dec 22, 2020, 06:29 Marcin Wachowiak <marcin.r.wachowiak@gmail.com> wrote:
Hello,May I ask what is the best way to visualize tags or messages in GR GUI?For example: there is a head block with reset function that each time it has processed specified number of samples sends tag or message "FINISHED".I am looking for a way this tag or message would affect a variable or some GUI element. Dumping tags or messages to terminal via debug block is quite neat , but is there any possibility to show all information in GUI (in a form of simple indicator: True/False or value)?.I didn't wanted to employ any streams or sources triggered by tag or message to reduce resources utilization.Kind regards,Marcin Wachowiak
Re: Question on Gnuradio Polyphase Channelizer Block?
Hello Joao,
I may have to write one, which I was not planning on doing.
It works (caveat to a point)!
I have tested it with QPSK Modulated signals. It works to a point, but the Channelized output is not completely correct. Channel-0 time series (real and imaginary components) are good, but the time series from the other channels are a little distorted. I have written the code for a channelizer in Matlab and the output modulated time series is perfect on all channels.
George
On Tue, Dec 22, 2020 at 10:18 AM <joao@phygitall.rio> wrote:
Here you are!I just downloaded the .xml file and renamed it to .grc. It seems to work, but I am using GNU Radio 3.8.2.0. See if it works for you.Cordially,JoãoOn December 22, 2020 at 1:35:29 pm -03:00, George Edwards <gedwards.eng@gmail.com> wrote:Hi Ron,That is good! I have Gnuradio 3.7.13.4 on one of my computers. Please send me the grc file as an attachment as soon as you can.This way, I can learn how to use the Gnuradio Polyphase Channelizer block.Thank you!Respectfully,GeorgeOn Tue, Dec 22, 2020 at 8:58 AM Ron Economos <w6rz@comcast.net> wrote:It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:Hi Ron,Thanks again for your help.When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.Thank you!Regards,GeorgeOn Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:You should probably use an add block instead of Streams to Stream.Here's an example flow graph.RonOn 12/21/20 11:20, George Edwards wrote:> Hello,>> I have three signals routed to the Gnuradio Polyphase Channelizer> Block. The system operates at a sample rate of 90 kHz with 3 channels> spaced 25 kHz apart. One channel is centered around DC and the other> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams> to Stream Block, so that a simple concatenated stream flows into the> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to> use 120 Taps and provide 3-outputs. Here are my questions on observing> the outputs>> Q1. I was expecting each output (block set to 3 outputs) to be at the> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show> a sample rate based on the original rate of 90 kHz. Why is this?>> Q2. I expected each output waveform to be centered around DC, but they> were instead centered around -25 kHz. Why?>> Q3. The output bandwidth for each waveform seems a little bigger than> the input, why?>> I will appreciate any help that assists to point me in the right> direction.>> Regards,> George
Re: Stop making unneeded improvements
On Tue, 22 Dec 2020 20:21:42 -0500
Glen Langston <glen.i.langston@gmail.com> wrote:
[snip]
> I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
> existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
> easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
> modules copy something or other. This is for no good reason that I'm aware of.
> Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
I use SDRPlay with gnuradio-3.8 with linux and it works fine. The
gr-soapy backend works better than the gr-osmosdr one however.
In my case I use sdrplay-2.13.1, soapy-sdr (git master branch as at
2020-07-13), soapy-sdrplay (git master branch as at 2020-06-29),
gnuradio-3.8.2.0 and gr-soapy (git master branch as at 2020-06-07).
In addition, to use SDRPlay with gqrx, I use gr-iqbal (git master
branch as at 2019-12-01) and gr-osmosdr (git master branch as at
2020-08-05). However, you should use the gr-osmosdr block's soapy
backend with soapy's sdrplay driver (pass the arguments
"soapy=0,driver=sdrplay" to the gr-osmosdr block), and not the sdrplay
backend which no longer works properly.
Glen Langston <glen.i.langston@gmail.com> wrote:
[snip]
> I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
> existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
> easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
> modules copy something or other. This is for no good reason that I'm aware of.
> Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
I use SDRPlay with gnuradio-3.8 with linux and it works fine. The
gr-soapy backend works better than the gr-osmosdr one however.
In my case I use sdrplay-2.13.1, soapy-sdr (git master branch as at
2020-07-13), soapy-sdrplay (git master branch as at 2020-06-29),
gnuradio-3.8.2.0 and gr-soapy (git master branch as at 2020-06-07).
In addition, to use SDRPlay with gqrx, I use gr-iqbal (git master
branch as at 2019-12-01) and gr-osmosdr (git master branch as at
2020-08-05). However, you should use the gr-osmosdr block's soapy
backend with soapy's sdrplay driver (pass the arguments
"soapy=0,driver=sdrplay" to the gr-osmosdr block), and not the sdrplay
backend which no longer works properly.
Re: Stop making unneeded improvements
Glen - which of your modules do you need to port? Maybe one or more of us can give you a hand, since this is for education and RA.
SDRPlay went through the same thing. They revamped their entire API recently to support newer products, and now even require a service to be running on Linux in order to use it. Fortunately, there are Soapy modules for the new and old API, and there is a gr-soapy (for 3.8).
On Tue, Dec 22, 2020 at 8:28 PM Glen Langston <glen.i.langston@gmail.com> wrote:
Hello GNuradio Superheros,
I have to say, after 5 years with gnu radio, I'm either tool old or
something has to change.
I've been trying to produce some tools for High School teacher to do radio astronomy.
and for that gnuradio 3.7 was perfectly fine. However some people are continuing
to make "improvements" that break everything. I used to really like gnuradio.
I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
modules copy something or other. This is for no good reason that I'm aware of.
Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
Stop making useless changes that break all code!
We do NOT need these changes. The advice on the web, after I've spent 2 days building 3.9
on a Raspberry pi is use 3.8. This is frustrating.
The documentation is falling apart because of all these variants.
It is good to make changes that ADD tool capabilities. It is NOT good to make changes that
make small improvements and break such large fractions of the code.
Sorry for the Rant.
Best regards Glen
> On Dec 22, 2020, at 3:43 PM, Adam Gorski <Adam.Gorski@vt-arc.org> wrote:
>
> Marcus,
>
> Thank you for the detailed response! This enriches my understanding of the demod process as well as the knobs involved; looks like I'll have to go back to the drawing board to implement something similar using non-deprecated blocks.
>
> Thanks,
>
> Adam Gorski
> Virginia Tech Applied Research Corporation (VT-ARC)
> Lead Communications Engineer
> 410-818-3188
>
> -----Original Message-----
> From: Discuss-gnuradio <discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus Müller
> Sent: Tuesday, December 22, 2020 8:11 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Setting DPSK Demod Block Parameters
>
> Hi Adam,
>
> I'm very sorry, you **really** really shouldn't be using that block (and that's the reason it's deprecated): it has bugs that just lose data. So, it's not really all that useful if I spend time reading old GNU Radio's source code to figure out what /exactly/ you want: You'll have to use a different block, sorry. Can't offer you to fix that block, we've tried and decided against it.
>
> Since you'll need to know the answers to these even if you implement this differently, let me quickly answer in-text:
>
> On 22/12/2020 02.13, Adam Gorski wrote:
>> * Excess bandwidth: I've read that in general the more excess
>> bandwidth supplied the better you can expect your synchronization
>> algorithm to perform. This is [0,1], and when I set it to 1 it's
>> noise resilience appreciably increases.
>
> That's the parameter of the pulse shaping; it defines the roll-off factor of the RRC:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
>
>> * FLL Bandwidth (assuming this is the same as filter lock-in
>> bandwidth): This and the two subsequent values default to 6.28/100.
>> I believe the higher this bandwidth is the faster the phase locked
>> loop can adjust the output of the frequency. This leads me to
>> believe I want this as high as possible, however I don't know where
>> 6.28 and 100 come from.
>
> As in any control loop: When making the feedback loop's bandwidth large you gain speed, but you lose stability and resilience against noise.
> In this case, that means your frequency correction will jump around.
> You'll really want to keep this small.
>
> 6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth of 1/100. This is a large value for a "locked in" loop!
>
>> * Phase Loop Bandwidth: I know that lower values lead to reduced
>> levels of phase noise and refence spurs at the expense of longer
>> lock times and less phase margin.
>
> Exactly!
>
>> I'm assuming I want the least
>> phase noise possible, however I don't know where 6.28 and 100 come from.
>
> See above.
>
>> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
>> bandwidth is usually somewhere between R/100 and R/20, where R is
>> the symbol clock rate being recovered. My symbol rate is 2 due to it
>> being BPSK,
>
> hm, not sure what symbol rate and constellation would have to do with another - symbol rate is the number of symbols you send per second.
>
>> is this the same as symbol clock rate?
>
> Yes.
>
>> Where do the 100
>> or 20 denominators come from?
>
> Largely: trial and error. The idea is that you usually need to average quite some symbols' timing error estimates to get a low-variance estimate of the actual error with less influence of the data on it; much lower than 20 won't work, because you don't get sufficiently equal numbers of different symbol transitions.
> Larger than 100 becomes problematic as you might be too slow.
>
>> Should this value mirror the values of
>> FLL and Phase Loop bandwidths?
>
> Kind of, yes! If your timing drifts, that probably means that your whole system is slightly off in frequency - making the same linear degradation phenomenon happen to the phase (if we ignore the existence of the FLL).
>
> The phase might, however, be also shifting due to channel influences, so you'd typically would want your phase loop to be slightly more agile than your timing loop, but these are, say, tunable screws for a fine adjustment. Keeping the factor of 2 pi in the PLL and the relative bandwidth here roughly equal does sound like an excellent starting point.
>
>> My end goal is being able to identify the Mode S message preambles
>> within the demodulated bitstream. Any help is appreciated, thank you!
>
> This sounds very cool!
>
> Best regards,
> Marcus
Tuesday, December 22, 2020
Re: Stop making unneeded improvements
On 12/22/2020 08:21 PM, Glen Langston wrote:
> Hello GNuradio Superheros,
>
> I have to say, after 5 years with gnu radio, I'm either tool old or
> something has to change.
>
> I've been trying to produce some tools for High School teacher to do radio astronomy.
> and for that gnuradio 3.7 was perfectly fine. However some people are continuing
> to make "improvements" that break everything. I used to really like gnuradio.
>
> I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
> existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
> easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
> modules copy something or other. This is for no good reason that I'm aware of.
> Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
>
> Stop making useless changes that break all code!
>
> We do NOT need these changes. The advice on the web, after I've spent 2 days building 3.9
> on a Raspberry pi is use 3.8. This is frustrating.
>
> The documentation is falling apart because of all these variants.
>
> It is good to make changes that ADD tool capabilities. It is NOT good to make changes that
> make small improvements and break such large fractions of the code.
>
> Sorry for the Rant.
>
> Best regards Glen
>
>
Glen, I sympathize. But compared to the 3.6-->3.7 debacle, the changes
have been easier, in my experience.
The switch to pybind11 was because SWIG is no longer a supported
subsystem, from what I understand.
The change from XML to YAML for .grc files and .grc block descriptions
is a bit more gratuitous, IMHO, but there may be subtle
improvements in YAML compared to XML (apart from the easier syntax)
that I'm not aware of.
MOST of my own library of radio astronomy code is still stuck at GR 3.7
-- because of the pain you note. I did manage to get
stupid_simple_pulsar working on GR3.9, but it required some patches
to be applied to the underlying code-base because certain
*crucial* setters for frequently-used blocks like multiply_const and
add_const and subtract_const hadn't actually had
pybind11 bindings produced for them. Which lead to silent and
very-perplexing failure. It may be the case that there is no
automated tooling to go from SWIG to PyBind11, which means that it's
easy to miss stuff. Dunno.
The GR developers, per se, cannot be blamed for things like
hardware-specific drivers not being available--those are the clear
responsibility
of the purveyors of those drivers. Now, granted, the lack of
availability may be BECAUSE of the "pain" factor. Similarly, the particular
configurations of GR in *specific* Linux distributions is NOT the
mandate of the GR project, per se. If your fave Linux distro happens
to package GR in a way that is unpleasant in your particular
circumstance, that isn't, generally, the fault of the GR team here.
I've been a C/C++/Python developer now for just over 4 decades, and the
modern "let a thousand flowers bloom" nature of Linux is
**daunting** not just for *users*, but for *developers* as well. I
get grief for my own code because someone wants to build/install
it on some version of Linux with which I am utterly unfamiliar. If I
had to become intimately familiar with the machinations of every
single Linux variant out there (in the multiple dimensions of
version, hardware platform, package-management-framework, etc), I'd
only be able to produce perhaps 1 piece of software every 5 years or so.
> Hello GNuradio Superheros,
>
> I have to say, after 5 years with gnu radio, I'm either tool old or
> something has to change.
>
> I've been trying to produce some tools for High School teacher to do radio astronomy.
> and for that gnuradio 3.7 was perfectly fine. However some people are continuing
> to make "improvements" that break everything. I used to really like gnuradio.
>
> I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
> But the web indicates it might be usable in 3.9
> So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
> existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
> easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
> modules copy something or other. This is for no good reason that I'm aware of.
> Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
>
> Stop making useless changes that break all code!
>
> We do NOT need these changes. The advice on the web, after I've spent 2 days building 3.9
> on a Raspberry pi is use 3.8. This is frustrating.
>
> The documentation is falling apart because of all these variants.
>
> It is good to make changes that ADD tool capabilities. It is NOT good to make changes that
> make small improvements and break such large fractions of the code.
>
> Sorry for the Rant.
>
> Best regards Glen
>
>
Glen, I sympathize. But compared to the 3.6-->3.7 debacle, the changes
have been easier, in my experience.
The switch to pybind11 was because SWIG is no longer a supported
subsystem, from what I understand.
The change from XML to YAML for .grc files and .grc block descriptions
is a bit more gratuitous, IMHO, but there may be subtle
improvements in YAML compared to XML (apart from the easier syntax)
that I'm not aware of.
MOST of my own library of radio astronomy code is still stuck at GR 3.7
-- because of the pain you note. I did manage to get
stupid_simple_pulsar working on GR3.9, but it required some patches
to be applied to the underlying code-base because certain
*crucial* setters for frequently-used blocks like multiply_const and
add_const and subtract_const hadn't actually had
pybind11 bindings produced for them. Which lead to silent and
very-perplexing failure. It may be the case that there is no
automated tooling to go from SWIG to PyBind11, which means that it's
easy to miss stuff. Dunno.
The GR developers, per se, cannot be blamed for things like
hardware-specific drivers not being available--those are the clear
responsibility
of the purveyors of those drivers. Now, granted, the lack of
availability may be BECAUSE of the "pain" factor. Similarly, the particular
configurations of GR in *specific* Linux distributions is NOT the
mandate of the GR project, per se. If your fave Linux distro happens
to package GR in a way that is unpleasant in your particular
circumstance, that isn't, generally, the fault of the GR team here.
I've been a C/C++/Python developer now for just over 4 decades, and the
modern "let a thousand flowers bloom" nature of Linux is
**daunting** not just for *users*, but for *developers* as well. I
get grief for my own code because someone wants to build/install
it on some version of Linux with which I am utterly unfamiliar. If I
had to become intimately familiar with the machinations of every
single Linux variant out there (in the multiple dimensions of
version, hardware platform, package-management-framework, etc), I'd
only be able to produce perhaps 1 piece of software every 5 years or so.
Stop making unneeded improvements
Hello GNuradio Superheros,
I have to say, after 5 years with gnu radio, I'm either tool old or
something has to change.
I've been trying to produce some tools for High School teacher to do radio astronomy.
and for that gnuradio 3.7 was perfectly fine. However some people are continuing
to make "improvements" that break everything. I used to really like gnuradio.
I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
modules copy something or other. This is for no good reason that I'm aware of.
Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
Stop making useless changes that break all code!
We do NOT need these changes. The advice on the web, after I've spent 2 days building 3.9
on a Raspberry pi is use 3.8. This is frustrating.
The documentation is falling apart because of all these variants.
It is good to make changes that ADD tool capabilities. It is NOT good to make changes that
make small improvements and break such large fractions of the code.
Sorry for the Rant.
Best regards Glen
> On Dec 22, 2020, at 3:43 PM, Adam Gorski <Adam.Gorski@vt-arc.org> wrote:
>
> Marcus,
>
> Thank you for the detailed response! This enriches my understanding of the demod process as well as the knobs involved; looks like I'll have to go back to the drawing board to implement something similar using non-deprecated blocks.
>
> Thanks,
>
> Adam Gorski
> Virginia Tech Applied Research Corporation (VT-ARC)
> Lead Communications Engineer
> 410-818-3188
>
> -----Original Message-----
> From: Discuss-gnuradio <discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus Müller
> Sent: Tuesday, December 22, 2020 8:11 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Setting DPSK Demod Block Parameters
>
> Hi Adam,
>
> I'm very sorry, you **really** really shouldn't be using that block (and that's the reason it's deprecated): it has bugs that just lose data. So, it's not really all that useful if I spend time reading old GNU Radio's source code to figure out what /exactly/ you want: You'll have to use a different block, sorry. Can't offer you to fix that block, we've tried and decided against it.
>
> Since you'll need to know the answers to these even if you implement this differently, let me quickly answer in-text:
>
> On 22/12/2020 02.13, Adam Gorski wrote:
>> * Excess bandwidth: I've read that in general the more excess
>> bandwidth supplied the better you can expect your synchronization
>> algorithm to perform. This is [0,1], and when I set it to 1 it's
>> noise resilience appreciably increases.
>
> That's the parameter of the pulse shaping; it defines the roll-off factor of the RRC:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
>
>> * FLL Bandwidth (assuming this is the same as filter lock-in
>> bandwidth): This and the two subsequent values default to 6.28/100.
>> I believe the higher this bandwidth is the faster the phase locked
>> loop can adjust the output of the frequency. This leads me to
>> believe I want this as high as possible, however I don't know where
>> 6.28 and 100 come from.
>
> As in any control loop: When making the feedback loop's bandwidth large you gain speed, but you lose stability and resilience against noise.
> In this case, that means your frequency correction will jump around.
> You'll really want to keep this small.
>
> 6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth of 1/100. This is a large value for a "locked in" loop!
>
>> * Phase Loop Bandwidth: I know that lower values lead to reduced
>> levels of phase noise and refence spurs at the expense of longer
>> lock times and less phase margin.
>
> Exactly!
>
>> I'm assuming I want the least
>> phase noise possible, however I don't know where 6.28 and 100 come from.
>
> See above.
>
>> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
>> bandwidth is usually somewhere between R/100 and R/20, where R is
>> the symbol clock rate being recovered. My symbol rate is 2 due to it
>> being BPSK,
>
> hm, not sure what symbol rate and constellation would have to do with another - symbol rate is the number of symbols you send per second.
>
>> is this the same as symbol clock rate?
>
> Yes.
>
>> Where do the 100
>> or 20 denominators come from?
>
> Largely: trial and error. The idea is that you usually need to average quite some symbols' timing error estimates to get a low-variance estimate of the actual error with less influence of the data on it; much lower than 20 won't work, because you don't get sufficiently equal numbers of different symbol transitions.
> Larger than 100 becomes problematic as you might be too slow.
>
>> Should this value mirror the values of
>> FLL and Phase Loop bandwidths?
>
> Kind of, yes! If your timing drifts, that probably means that your whole system is slightly off in frequency - making the same linear degradation phenomenon happen to the phase (if we ignore the existence of the FLL).
>
> The phase might, however, be also shifting due to channel influences, so you'd typically would want your phase loop to be slightly more agile than your timing loop, but these are, say, tunable screws for a fine adjustment. Keeping the factor of 2 pi in the PLL and the relative bandwidth here roughly equal does sound like an excellent starting point.
>
>> My end goal is being able to identify the Mode S message preambles
>> within the demodulated bitstream. Any help is appreciated, thank you!
>
> This sounds very cool!
>
> Best regards,
> Marcus
I have to say, after 5 years with gnu radio, I'm either tool old or
something has to change.
I've been trying to produce some tools for High School teacher to do radio astronomy.
and for that gnuradio 3.7 was perfectly fine. However some people are continuing
to make "improvements" that break everything. I used to really like gnuradio.
I like the SDRPlay device, but it can not be used in gnuradio 3.8. According to the web.
But the web indicates it might be usable in 3.9
So I installed 3.9 only to find that swig has been replace by pybind. This breaks all my
existing C++ modules. The modules worked fine, but if using ubuntu 20.40 the students can not
easily install gnuradio 3.7. The pybind instructions are puzzling. gr-modtool all the
modules copy something or other. This is for no good reason that I'm aware of.
Either make the equivalent of pythons "2to3" or do not make the gnuradio fundamental changes.
Stop making useless changes that break all code!
We do NOT need these changes. The advice on the web, after I've spent 2 days building 3.9
on a Raspberry pi is use 3.8. This is frustrating.
The documentation is falling apart because of all these variants.
It is good to make changes that ADD tool capabilities. It is NOT good to make changes that
make small improvements and break such large fractions of the code.
Sorry for the Rant.
Best regards Glen
> On Dec 22, 2020, at 3:43 PM, Adam Gorski <Adam.Gorski@vt-arc.org> wrote:
>
> Marcus,
>
> Thank you for the detailed response! This enriches my understanding of the demod process as well as the knobs involved; looks like I'll have to go back to the drawing board to implement something similar using non-deprecated blocks.
>
> Thanks,
>
> Adam Gorski
> Virginia Tech Applied Research Corporation (VT-ARC)
> Lead Communications Engineer
> 410-818-3188
>
> -----Original Message-----
> From: Discuss-gnuradio <discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus Müller
> Sent: Tuesday, December 22, 2020 8:11 AM
> To: discuss-gnuradio@gnu.org
> Subject: Re: Setting DPSK Demod Block Parameters
>
> Hi Adam,
>
> I'm very sorry, you **really** really shouldn't be using that block (and that's the reason it's deprecated): it has bugs that just lose data. So, it's not really all that useful if I spend time reading old GNU Radio's source code to figure out what /exactly/ you want: You'll have to use a different block, sorry. Can't offer you to fix that block, we've tried and decided against it.
>
> Since you'll need to know the answers to these even if you implement this differently, let me quickly answer in-text:
>
> On 22/12/2020 02.13, Adam Gorski wrote:
>> * Excess bandwidth: I've read that in general the more excess
>> bandwidth supplied the better you can expect your synchronization
>> algorithm to perform. This is [0,1], and when I set it to 1 it's
>> noise resilience appreciably increases.
>
> That's the parameter of the pulse shaping; it defines the roll-off factor of the RRC:
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
>
>> * FLL Bandwidth (assuming this is the same as filter lock-in
>> bandwidth): This and the two subsequent values default to 6.28/100.
>> I believe the higher this bandwidth is the faster the phase locked
>> loop can adjust the output of the frequency. This leads me to
>> believe I want this as high as possible, however I don't know where
>> 6.28 and 100 come from.
>
> As in any control loop: When making the feedback loop's bandwidth large you gain speed, but you lose stability and resilience against noise.
> In this case, that means your frequency correction will jump around.
> You'll really want to keep this small.
>
> 6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth of 1/100. This is a large value for a "locked in" loop!
>
>> * Phase Loop Bandwidth: I know that lower values lead to reduced
>> levels of phase noise and refence spurs at the expense of longer
>> lock times and less phase margin.
>
> Exactly!
>
>> I'm assuming I want the least
>> phase noise possible, however I don't know where 6.28 and 100 come from.
>
> See above.
>
>> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
>> bandwidth is usually somewhere between R/100 and R/20, where R is
>> the symbol clock rate being recovered. My symbol rate is 2 due to it
>> being BPSK,
>
> hm, not sure what symbol rate and constellation would have to do with another - symbol rate is the number of symbols you send per second.
>
>> is this the same as symbol clock rate?
>
> Yes.
>
>> Where do the 100
>> or 20 denominators come from?
>
> Largely: trial and error. The idea is that you usually need to average quite some symbols' timing error estimates to get a low-variance estimate of the actual error with less influence of the data on it; much lower than 20 won't work, because you don't get sufficiently equal numbers of different symbol transitions.
> Larger than 100 becomes problematic as you might be too slow.
>
>> Should this value mirror the values of
>> FLL and Phase Loop bandwidths?
>
> Kind of, yes! If your timing drifts, that probably means that your whole system is slightly off in frequency - making the same linear degradation phenomenon happen to the phase (if we ignore the existence of the FLL).
>
> The phase might, however, be also shifting due to channel influences, so you'd typically would want your phase loop to be slightly more agile than your timing loop, but these are, say, tunable screws for a fine adjustment. Keeping the factor of 2 pi in the PLL and the relative bandwidth here roughly equal does sound like an excellent starting point.
>
>> My end goal is being able to identify the Mode S message preambles
>> within the demodulated bitstream. Any help is appreciated, thank you!
>
> This sounds very cool!
>
> Best regards,
> Marcus
Re: [VOLK] Release v2.4.1
Hi Ron - that worked - thanks!
-- Cinaed
On 12/21/20 4:51 PM, Ron Economos wrote:
> It's a submodule, so "git pull" gives you the latest submodule
> pointer, not the latest commit.
>
> To get the latest:
>
> cd gnuradio/volk
>
> git checkout v2.4.1
>
> git submodule update --init
>
> Ron
>
> On 12/21/20 16:33, Cinaed Simson wrote:
>> Hi Johannes - I'm running gnuradio 3.8.2.0.
>>
>> I did a
>>
>> git pull
>>
>> in the source for gnuradio, rebuilt and -re-installed gnuradio.
>>
>> When I run
>>
>> volk-config-info -v
>>
>> it returns 2.0.
>>
>> Did I mess up some where?
>>
>> -- Cinaed
>>
>> On 12/17/20 8:59 AM, Johannes Demel wrote:
>>> Hi everyone!
>>>
>>> We have a new VOLK bugfix release! We are happy to announce VOLK
>>> v2.4.1! We want to thank all contributors. This release wouldn't
>>> have been possible without them.
>>>
>>> Our v2.4.0 release introduced quite a lot of changes under the hood.
>>> With this bugfix release, we want to make sure that everything works
>>> as expected again.
>>>
>>> You can find the release news on
>>> [libvolk.org](https://www.libvolk.org/category/news.html)
>>>
>>> ### Contributors
>>>
>>> * A. Maitland Bottoms <bottoms@debian.org>
>>> * Johannes Demel <demel@uni-bremen.de>
>>> * Michael Dickens <michael.dickens@ettus.com>
>>> * Philip Balister <philip@balister.org>
>>> * Ron Economos <w6rz@comcast.net>
>>> * Ryan Volz <ryan.volz@gmail.com>
>>>
>>>
>>> ### Changes
>>>
>>> * Build
>>> - cpu_features CMake option
>>> - Add cpu_features to static library build.
>>> - Use static liborc-0.4 library for static library build.
>>> - cmake: Detect if cpu_features submodule is present.
>>>
>>> * Install
>>> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>>>
>>> * CI
>>> - Add CI test for static library build.
>>>
>>> * Releases
>>> - project: Include git submodules (i.e. cpu_features) in release
>>> tarball.
>>> - scripts: Add GPG signature to release script
>>>
>>> * Other
>>> - readme: Update TravisCI status badge
>>>
>>
>>
>
-- Cinaed
On 12/21/20 4:51 PM, Ron Economos wrote:
> It's a submodule, so "git pull" gives you the latest submodule
> pointer, not the latest commit.
>
> To get the latest:
>
> cd gnuradio/volk
>
> git checkout v2.4.1
>
> git submodule update --init
>
> Ron
>
> On 12/21/20 16:33, Cinaed Simson wrote:
>> Hi Johannes - I'm running gnuradio 3.8.2.0.
>>
>> I did a
>>
>> git pull
>>
>> in the source for gnuradio, rebuilt and -re-installed gnuradio.
>>
>> When I run
>>
>> volk-config-info -v
>>
>> it returns 2.0.
>>
>> Did I mess up some where?
>>
>> -- Cinaed
>>
>> On 12/17/20 8:59 AM, Johannes Demel wrote:
>>> Hi everyone!
>>>
>>> We have a new VOLK bugfix release! We are happy to announce VOLK
>>> v2.4.1! We want to thank all contributors. This release wouldn't
>>> have been possible without them.
>>>
>>> Our v2.4.0 release introduced quite a lot of changes under the hood.
>>> With this bugfix release, we want to make sure that everything works
>>> as expected again.
>>>
>>> You can find the release news on
>>> [libvolk.org](https://www.libvolk.org/category/news.html)
>>>
>>> ### Contributors
>>>
>>> * A. Maitland Bottoms <bottoms@debian.org>
>>> * Johannes Demel <demel@uni-bremen.de>
>>> * Michael Dickens <michael.dickens@ettus.com>
>>> * Philip Balister <philip@balister.org>
>>> * Ron Economos <w6rz@comcast.net>
>>> * Ryan Volz <ryan.volz@gmail.com>
>>>
>>>
>>> ### Changes
>>>
>>> * Build
>>> - cpu_features CMake option
>>> - Add cpu_features to static library build.
>>> - Use static liborc-0.4 library for static library build.
>>> - cmake: Detect if cpu_features submodule is present.
>>>
>>> * Install
>>> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>>>
>>> * CI
>>> - Add CI test for static library build.
>>>
>>> * Releases
>>> - project: Include git submodules (i.e. cpu_features) in release
>>> tarball.
>>> - scripts: Add GPG signature to release script
>>>
>>> * Other
>>> - readme: Update TravisCI status badge
>>>
>>
>>
>
RE: Setting DPSK Demod Block Parameters
Marcus,
Thank you for the detailed response! This enriches my understanding of the demod process as well as the knobs involved; looks like I'll have to go back to the drawing board to implement something similar using non-deprecated blocks.
Thanks,
Adam Gorski
Virginia Tech Applied Research Corporation (VT-ARC)
Lead Communications Engineer
410-818-3188
-----Original Message-----
From: Discuss-gnuradio <discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus Müller
Sent: Tuesday, December 22, 2020 8:11 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Setting DPSK Demod Block Parameters
Hi Adam,
I'm very sorry, you **really** really shouldn't be using that block (and that's the reason it's deprecated): it has bugs that just lose data. So, it's not really all that useful if I spend time reading old GNU Radio's source code to figure out what /exactly/ you want: You'll have to use a different block, sorry. Can't offer you to fix that block, we've tried and decided against it.
Since you'll need to know the answers to these even if you implement this differently, let me quickly answer in-text:
On 22/12/2020 02.13, Adam Gorski wrote:
> * Excess bandwidth: I've read that in general the more excess
> bandwidth supplied the better you can expect your synchronization
> algorithm to perform. This is [0,1], and when I set it to 1 it's
> noise resilience appreciably increases.
That's the parameter of the pulse shaping; it defines the roll-off factor of the RRC:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
> * FLL Bandwidth (assuming this is the same as filter lock-in
> bandwidth): This and the two subsequent values default to 6.28/100.
> I believe the higher this bandwidth is the faster the phase locked
> loop can adjust the output of the frequency. This leads me to
> believe I want this as high as possible, however I don't know where
> 6.28 and 100 come from.
As in any control loop: When making the feedback loop's bandwidth large you gain speed, but you lose stability and resilience against noise.
In this case, that means your frequency correction will jump around.
You'll really want to keep this small.
6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth of 1/100. This is a large value for a "locked in" loop!
> * Phase Loop Bandwidth: I know that lower values lead to reduced
> levels of phase noise and refence spurs at the expense of longer
> lock times and less phase margin.
Exactly!
> I'm assuming I want the least
> phase noise possible, however I don't know where 6.28 and 100 come from.
See above.
> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
> bandwidth is usually somewhere between R/100 and R/20, where R is
> the symbol clock rate being recovered. My symbol rate is 2 due to it
> being BPSK,
hm, not sure what symbol rate and constellation would have to do with another - symbol rate is the number of symbols you send per second.
> is this the same as symbol clock rate?
Yes.
> Where do the 100
> or 20 denominators come from?
Largely: trial and error. The idea is that you usually need to average quite some symbols' timing error estimates to get a low-variance estimate of the actual error with less influence of the data on it; much lower than 20 won't work, because you don't get sufficiently equal numbers of different symbol transitions.
Larger than 100 becomes problematic as you might be too slow.
> Should this value mirror the values of
> FLL and Phase Loop bandwidths?
Kind of, yes! If your timing drifts, that probably means that your whole system is slightly off in frequency - making the same linear degradation phenomenon happen to the phase (if we ignore the existence of the FLL).
The phase might, however, be also shifting due to channel influences, so you'd typically would want your phase loop to be slightly more agile than your timing loop, but these are, say, tunable screws for a fine adjustment. Keeping the factor of 2 pi in the PLL and the relative bandwidth here roughly equal does sound like an excellent starting point.
> My end goal is being able to identify the Mode S message preambles
> within the demodulated bitstream. Any help is appreciated, thank you!
This sounds very cool!
Best regards,
Marcus
Thank you for the detailed response! This enriches my understanding of the demod process as well as the knobs involved; looks like I'll have to go back to the drawing board to implement something similar using non-deprecated blocks.
Thanks,
Adam Gorski
Virginia Tech Applied Research Corporation (VT-ARC)
Lead Communications Engineer
410-818-3188
-----Original Message-----
From: Discuss-gnuradio <discuss-gnuradio-bounces+adam.gorski=vt-arc.org@gnu.org> On Behalf Of Marcus Müller
Sent: Tuesday, December 22, 2020 8:11 AM
To: discuss-gnuradio@gnu.org
Subject: Re: Setting DPSK Demod Block Parameters
Hi Adam,
I'm very sorry, you **really** really shouldn't be using that block (and that's the reason it's deprecated): it has bugs that just lose data. So, it's not really all that useful if I spend time reading old GNU Radio's source code to figure out what /exactly/ you want: You'll have to use a different block, sorry. Can't offer you to fix that block, we've tried and decided against it.
Since you'll need to know the answers to these even if you implement this differently, let me quickly answer in-text:
On 22/12/2020 02.13, Adam Gorski wrote:
> * Excess bandwidth: I've read that in general the more excess
> bandwidth supplied the better you can expect your synchronization
> algorithm to perform. This is [0,1], and when I set it to 1 it's
> noise resilience appreciably increases.
That's the parameter of the pulse shaping; it defines the roll-off factor of the RRC:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FRaised-cosine_filter%23Roll-off_factor&data=04%7C01%7Cadam.gorski%40vt-arc.org%7Ce1e6e318da38469ebcf508d8a67b3b24%7C2440d112656a4c20b3b18fea5501bc48%7C0%7C0%7C637442395509539324%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vCJKutbjZvguhVlZWh51W3Ovmv8EmurtuTiYlUDmfIw%3D&reserved=0
> * FLL Bandwidth (assuming this is the same as filter lock-in
> bandwidth): This and the two subsequent values default to 6.28/100.
> I believe the higher this bandwidth is the faster the phase locked
> loop can adjust the output of the frequency. This leads me to
> believe I want this as high as possible, however I don't know where
> 6.28 and 100 come from.
As in any control loop: When making the feedback loop's bandwidth large you gain speed, but you lose stability and resilience against noise.
In this case, that means your frequency correction will jump around.
You'll really want to keep this small.
6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop bandwidth of 1/100. This is a large value for a "locked in" loop!
> * Phase Loop Bandwidth: I know that lower values lead to reduced
> levels of phase noise and refence spurs at the expense of longer
> lock times and less phase margin.
Exactly!
> I'm assuming I want the least
> phase noise possible, however I don't know where 6.28 and 100 come from.
See above.
> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
> bandwidth is usually somewhere between R/100 and R/20, where R is
> the symbol clock rate being recovered. My symbol rate is 2 due to it
> being BPSK,
hm, not sure what symbol rate and constellation would have to do with another - symbol rate is the number of symbols you send per second.
> is this the same as symbol clock rate?
Yes.
> Where do the 100
> or 20 denominators come from?
Largely: trial and error. The idea is that you usually need to average quite some symbols' timing error estimates to get a low-variance estimate of the actual error with less influence of the data on it; much lower than 20 won't work, because you don't get sufficiently equal numbers of different symbol transitions.
Larger than 100 becomes problematic as you might be too slow.
> Should this value mirror the values of
> FLL and Phase Loop bandwidths?
Kind of, yes! If your timing drifts, that probably means that your whole system is slightly off in frequency - making the same linear degradation phenomenon happen to the phase (if we ignore the existence of the FLL).
The phase might, however, be also shifting due to channel influences, so you'd typically would want your phase loop to be slightly more agile than your timing loop, but these are, say, tunable screws for a fine adjustment. Keeping the factor of 2 pi in the PLL and the relative bandwidth here roughly equal does sound like an excellent starting point.
> My end goal is being able to identify the Mode S message preambles
> within the demodulated bitstream. Any help is appreciated, thank you!
This sounds very cool!
Best regards,
Marcus
Re: Question on Gnuradio Polyphase Channelizer Block?
Hello Joao,
Thank you very much!
I will test it.
Regards,
George
On Tue, Dec 22, 2020 at 10:18 AM <joao@phygitall.rio> wrote:
Here you are!I just downloaded the .xml file and renamed it to .grc. It seems to work, but I am using GNU Radio 3.8.2.0. See if it works for you.Cordially,JoãoOn December 22, 2020 at 1:35:29 pm -03:00, George Edwards <gedwards.eng@gmail.com> wrote:Hi Ron,That is good! I have Gnuradio 3.7.13.4 on one of my computers. Please send me the grc file as an attachment as soon as you can.This way, I can learn how to use the Gnuradio Polyphase Channelizer block.Thank you!Respectfully,GeorgeOn Tue, Dec 22, 2020 at 8:58 AM Ron Economos <w6rz@comcast.net> wrote:It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:Hi Ron,Thanks again for your help.When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.Thank you!Regards,GeorgeOn Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:You should probably use an add block instead of Streams to Stream.Here's an example flow graph.RonOn 12/21/20 11:20, George Edwards wrote:> Hello,>> I have three signals routed to the Gnuradio Polyphase Channelizer> Block. The system operates at a sample rate of 90 kHz with 3 channels> spaced 25 kHz apart. One channel is centered around DC and the other> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams> to Stream Block, so that a simple concatenated stream flows into the> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to> use 120 Taps and provide 3-outputs. Here are my questions on observing> the outputs>> Q1. I was expecting each output (block set to 3 outputs) to be at the> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show> a sample rate based on the original rate of 90 kHz. Why is this?>> Q2. I expected each output waveform to be centered around DC, but they> were instead centered around -25 kHz. Why?>> Q3. The output bandwidth for each waveform seems a little bigger than> the input, why?>> I will appreciate any help that assists to point me in the right> direction.>> Regards,> George
Re: Question on Gnuradio Polyphase Channelizer Block?
Here you are!
I just downloaded the .xml file and renamed it to .grc. It seems to work, but I am using GNU Radio 3.8.2.0. See if it works for you.
Cordially,
João
On December 22, 2020 at 1:35:29 pm -03:00, George Edwards <gedwards.eng@gmail.com> wrote:
Hi Ron,That is good! I have Gnuradio 3.7.13.4 on one of my computers. Please send me the grc file as an attachment as soon as you can.This way, I can learn how to use the Gnuradio Polyphase Channelizer block.Thank you!Respectfully,GeorgeOn Tue, Dec 22, 2020 at 8:58 AM Ron Economos <w6rz@comcast.net> wrote:It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:Hi Ron,Thanks again for your help.When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.Thank you!Regards,GeorgeOn Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:You should probably use an add block instead of Streams to Stream.Here's an example flow graph.RonOn 12/21/20 11:20, George Edwards wrote:> Hello,>> I have three signals routed to the Gnuradio Polyphase Channelizer> Block. The system operates at a sample rate of 90 kHz with 3 channels> spaced 25 kHz apart. One channel is centered around DC and the other> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams> to Stream Block, so that a simple concatenated stream flows into the> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to> use 120 Taps and provide 3-outputs. Here are my questions on observing> the outputs>> Q1. I was expecting each output (block set to 3 outputs) to be at the> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show> a sample rate based on the original rate of 90 kHz. Why is this?>> Q2. I expected each output waveform to be centered around DC, but they> were instead centered around -25 kHz. Why?>> Q3. The output bandwidth for each waveform seems a little bigger than> the input, why?>> I will appreciate any help that assists to point me in the right> direction.>> Regards,> George
Re: Question on Gnuradio Polyphase Channelizer Block?
Hi Ron,
That is good! I have Gnuradio 3.7.13.4 on one of my computers. Please send me the grc file as an attachment as soon as you can.
This way, I can learn how to use the Gnuradio Polyphase Channelizer block.
Thank you!
Respectfully,
George
On Tue, Dec 22, 2020 at 8:58 AM Ron Economos <w6rz@comcast.net> wrote:
It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:
Hi Ron,
Thanks again for your help.
When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.
Thank you!
Regards,George
On Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Re: Question on Gnuradio Polyphase Channelizer Block?
Maybe I misunderstood your issue. Right click on the link and select "Save Link As".
Ron
On 12/22/20 07:56, Ron Economos wrote:
It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:
Hi Ron,
Thanks again for your help.
When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.
Thank you!
Regards,George
On Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Re: Question on Gnuradio Polyphase Channelizer Block?
It's a GNU Radio 3.7 flow graph. It can be converted by GNU Radio 3.8.
Ron
On 12/22/20 07:47, George Edwards wrote:
Hi Ron,
Thanks again for your help.
When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.
Thank you!
Regards,George
On Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Re: Question on Gnuradio Polyphase Channelizer Block?
Hi Ron,
Thanks again for your help.
When I click on the link you provided, I get the XML file. Please send me the actual grc file as a standalone.
Thank you!
Regards,
George
On Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Re: Question on Gnuradio Polyphase Channelizer Block?
Hi Ron,
Thank you very much!
Happy Holiday Season!
George
On Mon, Dec 21, 2020 at 2:47 PM Ron Economos <w6rz@comcast.net> wrote:
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Tag or message to GUI indicator
Hello,
May I ask what is the best way to visualize tags or messages in GR GUI?
For example: there is a head block with reset function that each time it has processed specified number of samples sends tag or message "FINISHED".
I am looking for a way this tag or message would affect a variable or some GUI element. Dumping tags or messages to terminal via debug block is quite neat , but is there any possibility to show all information in GUI (in a form of simple indicator: True/False or value)?.
I didn't wanted to employ any streams or sources triggered by tag or message to reduce resources utilization.
Kind regards,
Marcin Wachowiak
Re: Setting DPSK Demod Block Parameters
Hi Adam,
I'm very sorry, you **really** really shouldn't be using that block (and
that's the reason it's deprecated): it has bugs that just lose data. So,
it's not really all that useful if I spend time reading old GNU Radio's
source code to figure out what /exactly/ you want: You'll have to use a
different block, sorry. Can't offer you to fix that block, we've tried
and decided against it.
Since you'll need to know the answers to these even if you implement
this differently, let me quickly answer in-text:
On 22/12/2020 02.13, Adam Gorski wrote:
> * Excess bandwidth: I've read that in general the more excess
> bandwidth supplied the better you can expect your synchronization
> algorithm to perform. This is [0,1], and when I set it to 1 it's
> noise resilience appreciably increases.
That's the parameter of the pulse shaping; it defines the roll-off
factor of the RRC:
https://en.wikipedia.org/wiki/Raised-cosine_filter#Roll-off_factor
> * FLL Bandwidth (assuming this is the same as filter lock-in
> bandwidth): This and the two subsequent values default to 6.28/100.
> I believe the higher this bandwidth is the faster the phase locked
> loop can adjust the output of the frequency. This leads me to
> believe I want this as high as possible, however I don't know where
> 6.28 and 100 come from.
As in any control loop: When making the feedback loop's bandwidth large
you gain speed, but you lose stability and resilience against noise.
In this case, that means your frequency correction will jump around.
You'll really want to keep this small.
6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop
bandwidth of 1/100. This is a large value for a "locked in" loop!
> * Phase Loop Bandwidth: I know that lower values lead to reduced
> levels of phase noise and refence spurs at the expense of longer
> lock times and less phase margin.
Exactly!
> I'm assuming I want the least
> phase noise possible, however I don't know where 6.28 and 100 come from.
See above.
> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
> bandwidth is usually somewhere between R/100 and R/20, where R is
> the symbol clock rate being recovered. My symbol rate is 2 due to it
> being BPSK,
hm, not sure what symbol rate and constellation would have to do with
another - symbol rate is the number of symbols you send per second.
> is this the same as symbol clock rate?
Yes.
> Where do the 100
> or 20 denominators come from?
Largely: trial and error. The idea is that you usually need to average
quite some symbols' timing error estimates to get a low-variance
estimate of the actual error with less influence of the data on it; much
lower than 20 won't work, because you don't get sufficiently equal
numbers of different symbol transitions.
Larger than 100 becomes problematic as you might be too slow.
> Should this value mirror the values of
> FLL and Phase Loop bandwidths?
Kind of, yes! If your timing drifts, that probably means that your whole
system is slightly off in frequency - making the same linear degradation
phenomenon happen to the phase (if we ignore the existence of the FLL).
The phase might, however, be also shifting due to channel influences, so
you'd typically would want your phase loop to be slightly more agile
than your timing loop, but these are, say, tunable screws for a fine
adjustment. Keeping the factor of 2 pi in the PLL and the relative
bandwidth here roughly equal does sound like an excellent starting point.
> My end goal is being able to identify the Mode S message preambles
> within the demodulated bitstream. Any help is appreciated, thank you!
This sounds very cool!
Best regards,
Marcus
I'm very sorry, you **really** really shouldn't be using that block (and
that's the reason it's deprecated): it has bugs that just lose data. So,
it's not really all that useful if I spend time reading old GNU Radio's
source code to figure out what /exactly/ you want: You'll have to use a
different block, sorry. Can't offer you to fix that block, we've tried
and decided against it.
Since you'll need to know the answers to these even if you implement
this differently, let me quickly answer in-text:
On 22/12/2020 02.13, Adam Gorski wrote:
> * Excess bandwidth: I've read that in general the more excess
> bandwidth supplied the better you can expect your synchronization
> algorithm to perform. This is [0,1], and when I set it to 1 it's
> noise resilience appreciably increases.
That's the parameter of the pulse shaping; it defines the roll-off
factor of the RRC:
https://en.wikipedia.org/wiki/Raised-cosine_filter#Roll-off_factor
> * FLL Bandwidth (assuming this is the same as filter lock-in
> bandwidth): This and the two subsequent values default to 6.28/100.
> I believe the higher this bandwidth is the faster the phase locked
> loop can adjust the output of the frequency. This leads me to
> believe I want this as high as possible, however I don't know where
> 6.28 and 100 come from.
As in any control loop: When making the feedback loop's bandwidth large
you gain speed, but you lose stability and resilience against noise.
In this case, that means your frequency correction will jump around.
You'll really want to keep this small.
6.28/100 means "we do 2 pi in 100 samples", i.e. this means a loop
bandwidth of 1/100. This is a large value for a "locked in" loop!
> * Phase Loop Bandwidth: I know that lower values lead to reduced
> levels of phase noise and refence spurs at the expense of longer
> lock times and less phase margin.
Exactly!
> I'm assuming I want the least
> phase noise possible, however I don't know where 6.28 and 100 come from.
See above.
> * Timing Bandwidth: A dsp exchange question mentions that optimum loop
> bandwidth is usually somewhere between R/100 and R/20, where R is
> the symbol clock rate being recovered. My symbol rate is 2 due to it
> being BPSK,
hm, not sure what symbol rate and constellation would have to do with
another - symbol rate is the number of symbols you send per second.
> is this the same as symbol clock rate?
Yes.
> Where do the 100
> or 20 denominators come from?
Largely: trial and error. The idea is that you usually need to average
quite some symbols' timing error estimates to get a low-variance
estimate of the actual error with less influence of the data on it; much
lower than 20 won't work, because you don't get sufficiently equal
numbers of different symbol transitions.
Larger than 100 becomes problematic as you might be too slow.
> Should this value mirror the values of
> FLL and Phase Loop bandwidths?
Kind of, yes! If your timing drifts, that probably means that your whole
system is slightly off in frequency - making the same linear degradation
phenomenon happen to the phase (if we ignore the existence of the FLL).
The phase might, however, be also shifting due to channel influences, so
you'd typically would want your phase loop to be slightly more agile
than your timing loop, but these are, say, tunable screws for a fine
adjustment. Keeping the factor of 2 pi in the PLL and the relative
bandwidth here roughly equal does sound like an excellent starting point.
> My end goal is being able to identify the Mode S message preambles
> within the demodulated bitstream. Any help is appreciated, thank you!
This sounds very cool!
Best regards,
Marcus
Monday, December 21, 2020
Setting DPSK Demod Block Parameters
Hello community,
I am working on demodulating 1030 MHz Mode S traffic. As this signal uses DBPSK demodulation I’m using the deprecated GNU radio block ‘DPSK Demod’. However, there are a few parameters within this block that I can’t figure out how to set:
- Excess bandwidth: I’ve read that in general the more excess bandwidth supplied the better you can expect your synchronization algorithm to perform. This is [0,1], and when I set it to 1 it’s noise resilience appreciably increases.
- FLL Bandwidth (assuming this is the same as filter lock-in bandwidth): This and the two subsequent values default to 6.28/100. I believe the higher this bandwidth is the faster the phase locked loop can adjust the output of the frequency. This leads me to believe I want this as high as possible, however I don’t know where 6.28 and 100 come from.
- Phase Loop Bandwidth: I know that lower values lead to reduced levels of phase noise and refence spurs at the expense of longer lock times and less phase margin. I’m assuming I want the least phase noise possible, however I don’t know where 6.28 and 100 come from.
- Timing Bandwidth: A dsp exchange question mentions that optimum loop bandwidth is usually somewhere between R/100 and R/20, where R is the symbol clock rate being recovered. My symbol rate is 2 due to it being BPSK, is this the same as symbol clock rate? Where do the 100 or 20 denominators come from? Should this value mirror the values of FLL and Phase Loop bandwidths?
My end goal is being able to identify the Mode S message preambles within the demodulated bitstream. Any help is appreciated, thank you!
Adam Gorski
Virginia Tech Applied Research Corporation (VT-ARC)
Lead Communications Engineer
410-818-3188
Re: [VOLK] Release v2.4.1
It's a submodule, so "git pull" gives you the latest submodule pointer,
not the latest commit.
To get the latest:
cd gnuradio/volk
git checkout v2.4.1
git submodule update --init
Ron
On 12/21/20 16:33, Cinaed Simson wrote:
> Hi Johannes - I'm running gnuradio 3.8.2.0.
>
> I did a
>
> git pull
>
> in the source for gnuradio, rebuilt and -re-installed gnuradio.
>
> When I run
>
> volk-config-info -v
>
> it returns 2.0.
>
> Did I mess up some where?
>
> -- Cinaed
>
> On 12/17/20 8:59 AM, Johannes Demel wrote:
>> Hi everyone!
>>
>> We have a new VOLK bugfix release! We are happy to announce VOLK
>> v2.4.1! We want to thank all contributors. This release wouldn't have
>> been possible without them.
>>
>> Our v2.4.0 release introduced quite a lot of changes under the hood.
>> With this bugfix release, we want to make sure that everything works
>> as expected again.
>>
>> You can find the release news on
>> [libvolk.org](https://www.libvolk.org/category/news.html)
>>
>> ### Contributors
>>
>> * A. Maitland Bottoms <bottoms@debian.org>
>> * Johannes Demel <demel@uni-bremen.de>
>> * Michael Dickens <michael.dickens@ettus.com>
>> * Philip Balister <philip@balister.org>
>> * Ron Economos <w6rz@comcast.net>
>> * Ryan Volz <ryan.volz@gmail.com>
>>
>>
>> ### Changes
>>
>> * Build
>> - cpu_features CMake option
>> - Add cpu_features to static library build.
>> - Use static liborc-0.4 library for static library build.
>> - cmake: Detect if cpu_features submodule is present.
>>
>> * Install
>> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>>
>> * CI
>> - Add CI test for static library build.
>>
>> * Releases
>> - project: Include git submodules (i.e. cpu_features) in release
>> tarball.
>> - scripts: Add GPG signature to release script
>>
>> * Other
>> - readme: Update TravisCI status badge
>>
>
>
not the latest commit.
To get the latest:
cd gnuradio/volk
git checkout v2.4.1
git submodule update --init
Ron
On 12/21/20 16:33, Cinaed Simson wrote:
> Hi Johannes - I'm running gnuradio 3.8.2.0.
>
> I did a
>
> git pull
>
> in the source for gnuradio, rebuilt and -re-installed gnuradio.
>
> When I run
>
> volk-config-info -v
>
> it returns 2.0.
>
> Did I mess up some where?
>
> -- Cinaed
>
> On 12/17/20 8:59 AM, Johannes Demel wrote:
>> Hi everyone!
>>
>> We have a new VOLK bugfix release! We are happy to announce VOLK
>> v2.4.1! We want to thank all contributors. This release wouldn't have
>> been possible without them.
>>
>> Our v2.4.0 release introduced quite a lot of changes under the hood.
>> With this bugfix release, we want to make sure that everything works
>> as expected again.
>>
>> You can find the release news on
>> [libvolk.org](https://www.libvolk.org/category/news.html)
>>
>> ### Contributors
>>
>> * A. Maitland Bottoms <bottoms@debian.org>
>> * Johannes Demel <demel@uni-bremen.de>
>> * Michael Dickens <michael.dickens@ettus.com>
>> * Philip Balister <philip@balister.org>
>> * Ron Economos <w6rz@comcast.net>
>> * Ryan Volz <ryan.volz@gmail.com>
>>
>>
>> ### Changes
>>
>> * Build
>> - cpu_features CMake option
>> - Add cpu_features to static library build.
>> - Use static liborc-0.4 library for static library build.
>> - cmake: Detect if cpu_features submodule is present.
>>
>> * Install
>> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>>
>> * CI
>> - Add CI test for static library build.
>>
>> * Releases
>> - project: Include git submodules (i.e. cpu_features) in release
>> tarball.
>> - scripts: Add GPG signature to release script
>>
>> * Other
>> - readme: Update TravisCI status badge
>>
>
>
Re: [VOLK] Release v2.4.1
Hi Johannes - I'm running gnuradio 3.8.2.0.
I did a
git pull
in the source for gnuradio, rebuilt and -re-installed gnuradio.
When I run
volk-config-info -v
it returns 2.0.
Did I mess up some where?
-- Cinaed
On 12/17/20 8:59 AM, Johannes Demel wrote:
> Hi everyone!
>
> We have a new VOLK bugfix release! We are happy to announce VOLK
> v2.4.1! We want to thank all contributors. This release wouldn't have
> been possible without them.
>
> Our v2.4.0 release introduced quite a lot of changes under the hood.
> With this bugfix release, we want to make sure that everything works
> as expected again.
>
> You can find the release news on
> [libvolk.org](https://www.libvolk.org/category/news.html)
>
> ### Contributors
>
> * A. Maitland Bottoms <bottoms@debian.org>
> * Johannes Demel <demel@uni-bremen.de>
> * Michael Dickens <michael.dickens@ettus.com>
> * Philip Balister <philip@balister.org>
> * Ron Economos <w6rz@comcast.net>
> * Ryan Volz <ryan.volz@gmail.com>
>
>
> ### Changes
>
> * Build
> - cpu_features CMake option
> - Add cpu_features to static library build.
> - Use static liborc-0.4 library for static library build.
> - cmake: Detect if cpu_features submodule is present.
>
> * Install
> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>
> * CI
> - Add CI test for static library build.
>
> * Releases
> - project: Include git submodules (i.e. cpu_features) in release
> tarball.
> - scripts: Add GPG signature to release script
>
> * Other
> - readme: Update TravisCI status badge
>
I did a
git pull
in the source for gnuradio, rebuilt and -re-installed gnuradio.
When I run
volk-config-info -v
it returns 2.0.
Did I mess up some where?
-- Cinaed
On 12/17/20 8:59 AM, Johannes Demel wrote:
> Hi everyone!
>
> We have a new VOLK bugfix release! We are happy to announce VOLK
> v2.4.1! We want to thank all contributors. This release wouldn't have
> been possible without them.
>
> Our v2.4.0 release introduced quite a lot of changes under the hood.
> With this bugfix release, we want to make sure that everything works
> as expected again.
>
> You can find the release news on
> [libvolk.org](https://www.libvolk.org/category/news.html)
>
> ### Contributors
>
> * A. Maitland Bottoms <bottoms@debian.org>
> * Johannes Demel <demel@uni-bremen.de>
> * Michael Dickens <michael.dickens@ettus.com>
> * Philip Balister <philip@balister.org>
> * Ron Economos <w6rz@comcast.net>
> * Ryan Volz <ryan.volz@gmail.com>
>
>
> ### Changes
>
> * Build
> - cpu_features CMake option
> - Add cpu_features to static library build.
> - Use static liborc-0.4 library for static library build.
> - cmake: Detect if cpu_features submodule is present.
>
> * Install
> - Check for lib64 versus lib and set LIB_SUFFIX accordingly.
>
> * CI
> - Add CI test for static library build.
>
> * Releases
> - project: Include git submodules (i.e. cpu_features) in release
> tarball.
> - scripts: Add GPG signature to release script
>
> * Other
> - readme: Update TravisCI status badge
>
Re: Question on Gnuradio Polyphase Channelizer Block?
You should probably use an add block instead of Streams to Stream.
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Here's an example flow graph.
http://www.w6rz.net/pfb-filter-10.grc
Ron
On 12/21/20 11:20, George Edwards wrote:
> Hello,
>
> I have three signals routed to the Gnuradio Polyphase Channelizer
> Block. The system operates at a sample rate of 90 kHz with 3 channels
> spaced 25 kHz apart. One channel is centered around DC and the other
> two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams
> to Stream Block, so that a simple concatenated stream flows into the
> Gnuradio Polyphase Channelizer. I also set the Channelizer Block to
> use 120 Taps and provide 3-outputs. Here are my questions on observing
> the outputs
>
> Q1. I was expecting each output (block set to 3 outputs) to be at the
> sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show
> a sample rate based on the original rate of 90 kHz. Why is this?
>
> Q2. I expected each output waveform to be centered around DC, but they
> were instead centered around -25 kHz. Why?
>
> Q3. The output bandwidth for each waveform seems a little bigger than
> the input, why?
>
> I will appreciate any help that assists to point me in the right
> direction.
>
> Regards,
> George
Question on Gnuradio Polyphase Channelizer Block?
Hello,
I have three signals routed to the Gnuradio Polyphase Channelizer Block. The system operates at a sample rate of 90 kHz with 3 channels spaced 25 kHz apart. One channel is centered around DC and the other two at +/-25 kHz. The 3 waveforms are routed into a Gnuradio Streams to Stream Block, so that a simple concatenated stream flows into the Gnuradio Polyphase Channelizer. I also set the Channelizer Block to use 120 Taps and provide 3-outputs. Here are my questions on observing the outputs
Q1. I was expecting each output (block set to 3 outputs) to be at the sample rate (90 kHz/3 =) 30 kz in each of the 3-plots. The plots show a sample rate based on the original rate of 90 kHz. Why is this?
Q2. I expected each output waveform to be centered around DC, but they were instead centered around -25 kHz. Why?
Q3. The output bandwidth for each waveform seems a little bigger than the input, why?
I will appreciate any help that assists to point me in the right direction.
Regards,
George
Re: qt gui frequency sink in frequency hopping
Hi
Without a flowgraph anyone can help.
The first thing I would check : verify the sampling rate used in each
block. When using several sampling rate, when one is uncorrectly set it
can stop your simulation and freeze time or frequency sink.
Sincerely, Christophe
On 21/12/2020 11:50, Ali G. Dezfuli wrote:
> Hi all,
> I work on a Frequency Hopping (FH) Tx and Rx in the same grc flowchart
> in 3.7.13.4 in Ubuntu 16.04.
> At the end of the Tx chain, I put a "Qt GUI Frequency Sink", but it
> just shows part of subchannels in the spectrum!!!
> I changed its parameters especially "Update Period" but no change.
> The very interesting point is that when I remove the Rx chain (lessen
> the complexity), it shows the spectrum of FH correctly!
> I really wonder why.
>
> Thanks,
> AGD
Without a flowgraph anyone can help.
The first thing I would check : verify the sampling rate used in each
block. When using several sampling rate, when one is uncorrectly set it
can stop your simulation and freeze time or frequency sink.
Sincerely, Christophe
On 21/12/2020 11:50, Ali G. Dezfuli wrote:
> Hi all,
> I work on a Frequency Hopping (FH) Tx and Rx in the same grc flowchart
> in 3.7.13.4 in Ubuntu 16.04.
> At the end of the Tx chain, I put a "Qt GUI Frequency Sink", but it
> just shows part of subchannels in the spectrum!!!
> I changed its parameters especially "Update Period" but no change.
> The very interesting point is that when I remove the Rx chain (lessen
> the complexity), it shows the spectrum of FH correctly!
> I really wonder why.
>
> Thanks,
> AGD
qt gui frequency sink in frequency hopping
Hi all,
I work on a Frequency Hopping (FH) Tx and Rx in the same grc flowchart in 3.7.13.4 in Ubuntu 16.04.
At the end of the Tx chain, I put a "Qt GUI Frequency Sink", but it just shows part of subchannels in the spectrum!!!
I changed its parameters especially "Update Period" but no change.
The very interesting point is that when I remove the Rx chain (lessen the complexity), it shows the spectrum of FH correctly!
I really wonder why.
Thanks,
AGD
Sunday, December 20, 2020
Re: FOSDEM 2021: Free Software Radio Devroom CfP
Dear friends and fans of software-defined radio,
the Free Software Radio DevRoom track at next year's FOSDEM still has some slots left! We already have
some submissions and we are in the process of ranking those, but we will gladly
add YOUR presentation to the list!
If you have anything related to the field of free software radio, please
head to:
https://penta.fosdem.org/submission/FOSDEM21
and submit your short abstract! We're looking very much forward to your
submission.
For the committee,
Nicolas
the Free Software Radio DevRoom track at next year's FOSDEM still has some slots left! We already have
some submissions and we are in the process of ranking those, but we will gladly
add YOUR presentation to the list!
If you have anything related to the field of free software radio, please
head to:
https://penta.fosdem.org/submission/FOSDEM21
and submit your short abstract! We're looking very much forward to your
submission.
For the committee,
Nicolas
On Sat, Dec 5, 2020 at 11:36 AM Nicolas Cuervo Benavides <cuervonicolas@gmail.com> wrote:
Dear friends and fans of software-defined radio and free/open-source radio topics in general,
FOSDEM 2021 (the free and open-source developer's meeting usually in Brussels, Europe but **this time virtually**) will again feature a track on Software Defined Radio and any other radio-related topics in the Free Software Radio devroom. Therefore, we invite developers and users from the free software radio community to join us for this track and present your talks or demos.
Given the current circumstances and the virtual nature of this event in 2021, we are asking the presenters to pre-record the talks, which will then be gathered by us and streamed during the event. Presenters are also asked to be present online during their timeslot for live Q&A.
Software Radio has become an important tool to allow anyone to access the EM spectrum. Using free software radio libraries and applications and cheap hardware, anyone can now start hacking on wireless communications, remote sensing, radar, fun hacks of all sorts, or other applications. At FOSDEM, we hope to network all these projects, and improve collaboration, bring new ideas forward and get more people involved.
The track's website resides at the link below. The final schedule will be available through Pentabarf and the official FOSDEM website. Notice that the reference time will be Brussels local time (CET).
https://fosdem.org/2021/schedule/track/free_software_radio/
Additional Information will be also available at:
https://wiki.gnuradio.org/index.php/FOSDEM_2021
** Submit your presentations
To suggest a talk, go to https://penta.fosdem.org/submission/FOSDEM21 and follow the instructions (you need an account, but can use your account from last year if you have one. Please do NOT create a new account if you already have one). You need to create an 'Event'; make sure it's in the Free Software Radio track! Your submission should have the following information:
* Your contact Email
* A descriptive title and subtitle of your talk
* A short abstract
* Links related to the project
* [Optional] A longer description of the content of your talk.
Lengths aren't fixed, but give a realistic estimate, and please don't exceed 30 minutes unless you have something special planned (in that case, contact one of us). We will typically go for 30-minute slots -- shorter talks, unless they're really short, usually tend to screw up the schedule too much.
You aren't limited to slide presentations, of course. Be creative. However, FOSDEM is an open-source conference, therefore we ask you to stay clear of marketing presentations and present something relevant to free/open software. We like nitty-gritty technical stuff.
Topics discussed in this devroom include:
* SDR Frameworks + Tools
* Cellular/telecoms software
* Free/Open SDR hardware
* Wireless security
* Random fun wireless hacks
* SDR in education
* Satellite/spacecraft communication
* Ham radio related topics
** Important Dates
* Submission deadline: 26 December 2020
* Announcement of selected talks: 31 December 2020
* Conference dates 6 & 7 February 2021 online
* Free software radio devroom date: Sunday 7 February 2021 online
In the last years we were always full to the brim with presentations, so if you want to present, please make sure to submit your abstracts soon!
** Following steps for accepted talks
When your talk is accepted, you will be contacted by a deputy who will help you with the pre-recording of your talk. Together you will make sure that the content has the required quality and is stream-ready. When complete, the recording will be located into the streaming system, and Bob's your uncle.
Don't forget that you **must** be available during the allocated timeslot of your talk for live Q&A.
** Steering Committee
The track committee consists of:
* Phil Balister - "Crofton"
* Derek Kozel - "dkozel"
* Nicolas Cuervo - "primercuervo"
* Martin Braun - "mbr0wn"
Hope to hear from you soon! And please forward this announcement.- Nicolas
Saturday, December 19, 2020
Re: PNG image sink error
Hey Steffen,
it was just pointed out to me that you might be using the Graphics Item
block. Ooops! Sorry for the confusion.
Best regards,
Marcus
On 14.12.20 10:40, Steffen Kiel wrote:
> Hi Marcus.
>
> I am trying to use the "PNG Image Sink" QT block, with an "Image file
> source" as input for it.
>
> Am I not understanding this correctly?
>
>
>
> //Steffen
>
>
> This email has been scanned by BullGuard antivirus protection.
> For more info visit www.bullguard.com
> <http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/>
it was just pointed out to me that you might be using the Graphics Item
block. Ooops! Sorry for the confusion.
Best regards,
Marcus
On 14.12.20 10:40, Steffen Kiel wrote:
> Hi Marcus.
>
> I am trying to use the "PNG Image Sink" QT block, with an "Image file
> source" as input for it.
>
> Am I not understanding this correctly?
>
>
>
> //Steffen
>
>
> This email has been scanned by BullGuard antivirus protection.
> For more info visit www.bullguard.com
> <http://www.bullguard.com/tracking.aspx?affiliate=bullguard&buyaffiliate=smtp&url=/>
Subscribe to:
Posts (Atom)