Hi Stefano, we should stay on the mailing list, so everyone can follow and contribute. Are you sure there are not other messages? Because those below are no error messages, just a warning and a bit of information, nothing to really worry about. One common problem (which I did not have) is missing permission on the hackrf. But then you should get an error message telling that he was not able to access the hackrf. Can you send the complete output of the program? Also try running it with sudo to check if it is a permission issue. Do you have multiple SDRs (you said something about an rtl-sdr?) attached to the Pi? Try adding "hackrf" (without the quotes) to the device arguments in the osmocom source. Also try hackrf_info in a terminal to see if the hackrf is detected properly. You can also try osmocom_siggen or osmocom_spectrum_sense and see if you can access the hackrf. What if you replace the osmocom source with a random source (also add a throttle block to limit cpu usage)? Does it work? Just to make sure: You are running a graphical environment and starting the script from there, not an ssh connection?
Best regards, Fabian Am 13.02.21 um 19:25 schrieb Stefano Zorzanello: > Hi Fabian, thank you very much for your reply. > > I'm using RPI 3b, with Debian 9.13. > I have just installed gnuradio-companion 3.7.10 again following the > terminal commands you wrote me > > $ sudo apt install gnuradio gr-osmosdr hackrf > > the software installation went fine but as I run the flowgraph I get no > window displaying any signal, and the same error message > > - - - > Warning: failed to XInitThreads() > linux; GNU C++ version 6.2.0 20161010; Boost_106100; > UHD_003.009.005-0-unknown > > gr-osmosdr 0.1.4 (0.1.4) gnuradio 3.7.10 > built-in source types: file osmosdr fcd rtl rtl_tcp uhd miri hackrf > bladerf rfspace airspy soapy redpitaya > > - - - > any other idea to make it working? > thanks again, > best regards > > Stefano > > Il giorno sab 13 feb 2021 alle ore 17:26 Fabian Schwartau > <fab...@opencode.eu <mailto:fab...@opencode.eu>> ha scritto: > > Hi Stefano, > > don't worry asking such questions here on the list. That's its purpose I > guess ;) > First of all: I was able to run both of your flowgraphs on my PC with a > HackRF One, so the problem lies somewhere else. > A small google search reavealed no perfect solution, but it indicated > that something may be wrong with your installation. Like gnuradio was > build against a certain library version but you are using a > different one. > How did you install gnuradio on the Pi? What Pi is it exactly? An > original Pi 1 (A/B)? You may have trouble feeding 10 Msps though that > old hardware. But it should start anyway. > What OS are you using? Which version? > I would recommend installing gnuradio from the distro repositories using > apt. If you did so, a very simple solution may be to try a different > distribution (or version), like Raspi OS (Raspbian), Ubuntu, Arch, ... > there are many for the Pi. This will likely be a straight forward > workaround for your problem. > Nevertheless, I just tried it on one of my Pi 3 with a fairly clean and > up-to-date Raspi OS. I installed the following stuff: > $ sudo apt install gnuradio gr-osmosdr hackrf > And both of your flow graphs worked like a charm with that. > > If you have any further questions, feel free to ask them :) > > Hope I could help, > Fabian > > > Am 13.02.21 um 15:04 schrieb Stefano Zorzanello: > > Dear list members, > > > > I’m sorry to bother you with the classic newbie stuff, but I’m stuck - > > since some days (the solutions found on the web didn't work for > me) - to > > this point: > > > > - gnuradio-companion RaspberryPi 3b + hackRF one with a very simple > > blocks flow doesn’t display any signal window; > > and the error message I get is the following one: > > > > - - - - > > > > Warning: failed toXInitThreads()linux; GNU C++version 6.2.0 20161010; > > Boost_106100; UHD_003.009.005-0-unknowngr-osmosdr 0.1.4(0.1.4) > gnuradio > > 3.7.10built-in sourcetypes: file osmosdr fcd rtl rtl_tcp uhd miri > hackrf > > bladerf rfspaceairspy soapy redpitaya *** Error in`/usr/bin/python': > > corrupted double-linked list: 0x01a81c08 *** > > > > - - - - > > > > I'm trying to follow some very nice youtube tutorial (Ossman, Hackaday > > etc. ) but I cannot proceed if I can't neither make grc working with a > > simple sketch. > > > > Any help is greatly appreciated. > > > > More, if you have any suggestion or advice, here it follows a general > > description of the process I want to develop for my sound-art / sdr > > based installation. > > > > The set up should be as follows: > > > > - a small robot(flor hover type) moves randomly in a restricted area > > (few sq meters)of a big room. > > On this device, an RPI(“A”) + [DVB-T+DAB+FM] usb dongle, > > battery-powered, is mounted to detect some RF activity in some rf > range. > > Some values should be extracted (intensity over time of a particular > > freq // and intensity of shifting detected frequencies). The movements > > of the robot in the room should cause different detected values. > > > > - these values should be shared or sent in real-time to an external > > software (PureData) that sends these values via OSC to another > RPI(“B”), > > which is steady, that will use the incoming values as a control signal > > for some audio DSP-treatments (sampling and granulation). The raw > audio > > material for dsp audio treatments will be just RF noise.- The audio > > treatments will be played inside the room via loudspeakers. > > > > - through a microphone and dsp, the live audio stream will be analyzed > > in PureData (intensity and spectrum-centroid) in real-time by the > steady > > RPI. The values extracted from the audio-domain should be sent to > > GNURADIO-COMPANION to transmit some signals via HackRF one in the very > > same frequency range which is detected by RPI(“A”). > > > > - the idea is to build a close circuit of information generation, > which > > should be modulated over time and ever-changing, due to the conversion > > of values between the domains radio/audio, and to the implication > of the > > room acoustic response analyzed and encoded to interfere in the > > radiowaves domain. > > > > The suggestion of this idea comes from the works of Agostino Di Scipio > > “Audible Ecosystemics” (2000-2005) which develop very deeply feedback > > network processes based in the pure audio/acoustic domain. My > purpose is > > to try to do something similar in a cross-domain set (Radio/Audio > > through Sonification and Dsp treatments) > > thank you very much for your kind attention and help, > > > > best > > > > Stefano Zorzanello > > > >
