Yes, just hackRF One plugged into the RPI...
===
Sent from my mind, some fingers and electronics helped.
Il giorno 13 feb 2021, alle ore 23:13, Fabian Schwartau < fabian@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 <stefanozorzanello@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 <
fabian@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
> <
fabian@opencode.eu <mailto:
fabian@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
> >
>
>
|