Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

[Cinaed Simson]

Hi Vasil - when I checked out gr-fosphor from

  https://github.com/osmocom/gr-fosphor.git

it appeared the only versions supported using were

  3.7, 3.8

It's possible it's supported under under master - I didn't try.

Or maybe you have different author.

-- Cinaed


On 10/28/22 06: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
--
Ville Eerola
ville.eer...@iki.fi
050-4804435

Re: burst mode for hackrf one

[Jeff Long]

We are missing the "Length Tag" param in the yml for the newer gr-soapy
blocks. I updated the issue
.

On Sat, Nov 5, 2022 at 4:53 PM Adrian Musceac  wrote:

> On Saturday, 5 November 2022 22:39:13 EET Marcus D. Leech wrote:
>
> >One technique that likely works OK is "zero stuffing".  You send a
> > constant stream of 0s in "idle" state, and when a PDU comes
> >along it interrupts the otherwise-boring stream of 0s.
>
> That's not good if the TX path includes an RF switch, like the TX/RX port
> on
> the B200 family. IIRC without using tags on a semi-duplex device a
> constant
> stream will keep the TX path on as long as samples are flowing. There must
> be
> an end of burst flag that tells the device to empty the buffer and switch
> on the
> RX path. The LMS api has such a flag, but I'm not familiar with the
> HackRF. I
> suggest digging into libhackrf code to check if it does.
>
> Adrian
>
>
>
>
>
>

When I try to run test block receive this

[robin ivetic]

File "/home/otpisani/Downloads/top_block.py", line 139
self.filter_fft_low_pass_filter_0 = filter.fft_filter_ccc(1, 
firdes.low_pass(1, 15.0, 10.0M, 2.5M, window.WIN_HAMMING, 0), 1)

 ^
SyntaxError: invalid decimal literal

>>> Done (return code 1)

What am'I doing wrong. using Python 3.10.8, and companion 3.10.4.0

Robin

Re: Running flowfraph dies with segfault with GR 3.10.4 (gr-fosphor)

[Sylvain Munaut]

> > 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.

The 'master' branch should work for 3.9 and 3.10
The 'gr-3.7' and 'gr-3.8' branches are historical branch for those
specific versions of

But I haven't personally tested with 3.10.4 ...

Doing CL / GL in multithread application always requires quite a bit
of care and it's possible a recent version of GR broke one of the
assumption made ...

Cheers,

   Sylvain