Re: Help Needed for "firdes.root_raised_cosine"
Hi Shuvodip - if the blocks have the same color, then they have the same data type - but not necessarily the same value. What version of gnuradio are you using? -- Cinaed On 10/31/22 21:41, Shuvodip Majumdar wrote: Dear all, I am currently going through the tutorials of GNU Radio. Here I have doubts on "firdes.root_raised_cosine". For example, in the "QPSK Mod and Demod" chapter, "firdes.root_raised_cosine" has been used where there are five types of data inside the bracket after "firdes.root_raised_cosine". What do these data fields mean? Thanks in advance. With regards, Shuvodip
Re: Help Needed for "firdes.root_raised_cosine"
Hello Cinaed, My doubt is not about the data types. It's about what the fields signify, e.g. symbol rate, sampling rate, excess bandwidth etc. Regards, Shuvodip On Tue, Nov 1, 2022 at 12:49 PM Cinaed Simson wrote: > Hi Shuvodip - if the blocks have the same color, then they have the > same data type - but not necessarily the same value. > > What version of gnuradio are you using? > > -- Cinaed > > > On 10/31/22 21:41, Shuvodip Majumdar wrote: > > Dear all, > > > > I am currently going through the tutorials of GNU Radio. Here I have > > doubts on "firdes.root_raised_cosine". > > > > For example, in the "QPSK Mod and Demod" chapter, > > "firdes.root_raised_cosine" has been used where there are five types > > of data inside the bracket after "firdes.root_raised_cosine". What do > > these data fields mean? > > > > Thanks in advance. > > > > With regards, > > Shuvodip > > >
Re: Help Needed for "firdes.root_raised_cosine"
See https://wiki.gnuradio.org/index.php?title=SuggestedReading -- CInaed On 11/1/22 00:35, Shuvodip Majumdar wrote: Hello Cinaed, My doubt is not about the data types. It's about what the fields signify, e.g. symbol rate, sampling rate, excess bandwidth etc. Regards, Shuvodip On Tue, Nov 1, 2022 at 12:49 PM Cinaed Simson wrote: Hi Shuvodip - if the blocks have the same color, then they have the same data type - but not necessarily the same value. What version of gnuradio are you using? -- Cinaed On 10/31/22 21:41, Shuvodip Majumdar wrote: > Dear all, > > I am currently going through the tutorials of GNU Radio. Here I have > doubts on "firdes.root_raised_cosine". > > For example, in the "QPSK Mod and Demod" chapter, > "firdes.root_raised_cosine" has been used where there are five types > of data inside the bracket after "firdes.root_raised_cosine". What do > these data fields mean? > > Thanks in advance. > > With regards, > Shuvodip
Re: Help Needed for "firdes.root_raised_cosine"
Dear all, This issue has been resolved through a chat at https://chat.gnuradio.orgwith funkylab and drmpeg in the time interval: Indian Standard Time 14:24 to 16:38 dated 1st November 2022. Please have a look if you are interested. Thank you. With regards, Shuvodip On Tue, Nov 1, 2022 at 10:11 AM Shuvodip Majumdar wrote: > Dear all, > > I am currently going through the tutorials of GNU Radio. Here I have > doubts on "firdes.root_raised_cosine". > > For example, in the "QPSK Mod and Demod" chapter, > "firdes.root_raised_cosine" has been used where there are five types of > data inside the bracket after "firdes.root_raised_cosine". What do these > data fields mean? > > Thanks in advance. > > With regards, > Shuvodip >
Some example designs fail to open with 'BadAlloc' from X Window System
I'm running gnuradio 10 in conda. When I try to open an example design such as "./share/gnuradio/examples/digital/demod/test_corr_est.gr" I get the following error: Gdk-WARNING **: 09:16:17.517: The program 'gnuradio-companion' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 1794 error_code 11 request_code 131 (MIT-SHM) minor_code 5) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)
Hi Ville, Try running your reduced testcase under gdb and take a backtrace. First open your flowgraph in gnuradio companion, generate (F5) python script and then in the terminal execute. gdb -ex=run --args python3 testcase.py when it stops in execute the "bt" command and provide the full output (gdb) bt Best Regards, Vasil On 28/10/2022 16.24, Ville Eerola wrote: > Hi all, > > I used to have a working flowgraph developed with GR 3.10.2, but after update > to GR 3.10.4 it just ends with a segmentation fault. > > Now some details: > - I'm running Ubuntu 22.04, which is kept up to date. > - GR is installed from PPA > https://ppa.launchpadcontent.net/gnuradio/gnuradio-releases/ubuntu/ jammy main > - GR was automatically updated with Software Updater (from 3.10.2 -> 3.10.4) > - The flowgraph is using a gr-fosphor (Osmosdr) spectrum display > (fosphor_qt_sink) (Two of them) > - The data comes from a Soapy BladeRF Source, which seems to initialize > correctly > - If I disable the Fosphor displays (using "Disable" in GRC), the flowgraph > runs just fine > - With the Fosphor displays enabled, the Flowgraph prints out the normal > BladeRF initialization messages, and then "Done (return code -11)". When > running the Python code from command line, instead of "Done", it prints out > "Segmentation fault (core dumped)" > > - In order to rectify this I have updated all the OOT modules from Osmocom, > which I had previously installed with: > $ cd / > $ rm -rf build; > $ git fetch > $ git pull > $ mkdir build; cd build > $ cmake -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_SHARED_LIBS=true ../ > $ make > $ sudo make install; sudo ldconfig > > But, this did not help > > I was able to make a reduced testcase with just a Signal Source connected to > the Fosphor Sink (Qt), and this segfaults in similar fashion to my full model. > > > Regards, Ville >
