Yes, just hackRF One plugged into the RPI... === Sent from my mind, some fingers and electronics helped.
Il giorno 13 feb 2021, 23:13, alle ore 23:13, Fabian Schwartau <fab...@opencode.eu> ha scritto: >You are welcome :) >I can't actually explain why it is working with the hackrf argument. If >you have only one sdr connected, it should work without it. >Anyway, I'm glad it works now. > >Am 13. Februar 2021 22:54:32 MEZ schrieb Stefano Zorzanello ><stefanozorzane...@gmail.com>: >>please apologize, I didn't realize to have replied just to you. >> >>about hackrf recognition, this is the terminal report: >> >>- - - - >> >>$ hackrf_info >>Found HackRF board 0: >>USB descriptor string: 0000000000000000088869dc3326571b >>Board ID Number: 2 (HackRF One) >>Firmware Version: 2017.02.1 >>Part ID Number: 0xa000cb3c 0x005d4f64 >>Serial Number: 0x00000000 0x00000000 0x088869dc 0x3326571b >> >>- - - - >> >>in GRC after an initial alert window >>"The xterm executable '' is missing. >>You can change this setting in your gnuradio.conf, in section [grc], >>'xterm_executable'. >>(This message is shown only once)" >> >>I have change the permissions of grc.conf to set the file like this: >> >>xterm_executable = /usr/bin/xterm >> >>after this change the alert hasn't appeared anymore. >> >>*And finally adding "hackrf" in the device argument in osmocom source >>did >>the trick! * >> >>So I thank you very much, you could not believe but I spent a couple >of >>week about this silly thing, beating my head on the wall (with the >risk >>to >>break at least one of the two) >> >>So it's quite likely that I'll be back with other newbie issues... but >>in >>the meantime I thank you very much for your support, >>all best >>Stefano >> >> >> >>Il giorno sab 13 feb 2021 alle ore 20:47 Fabian Schwartau < >>fab...@opencode.eu> ha scritto: >> >>> 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 >>> > > >>> > >>> > >>> >>> >>>
