Re: Ubuntu 20.04 cannot find the Hackrf board?

[Cinaed Simson]

It sounds like you didn't

  apt install libhackrf-dev

If you did install the libraries, then you may have to update the firmware.

Post the entire results from

   apt list --installed | grep hackrf

so we can see the versions. There should be 2 entries.

Note the date of the firmware - 2014 - was  first year the hackrf was 
released via Kickstart.


-- Cinaed



On 8/3/22 05:15, George Edwards wrote:

Hello GNURadio Community,

I built a grc flowgraph in Gnuradio 3.9.5 on Ubuntu 20.04 inside 
Microsoft VirtualBox. I have a HackRF One radio hardware. I installed 
the hackrf drivers in Ubuntu with command: sudo apt-get install -y hackrf
and confirmed the installation. I connected the HackRF One board to my 
computer and in the Terminal prompt entered the command 
hackrf_info and received the response that it does not see the Hackrf 
board.


And true to form when I ran the flowgraph, I get the following error 
message:

RuntimeError: no hackrf device matches

Why is Ubuntu 20.04 running inside MS VirtualBox not seeing the HackRf 
board with the HackRf drivers installed. And, how do I resolve this issue?


Will appreciate any help to resolve this issue.

George

Re: Taylor detector

[david vanhorn]

Well, I'm sitting here recovering from open heart surgery for the next two
months, and I've always wanted to tackle this little problem.
Seems a bit scary though with all the moving parts.


On Fri, Aug 12, 2022 at 2:21 PM Nick Foster  wrote:

> David,
>
> OK, I see what you're after now. Gnuradio isn't a SPICE simulator, so
> getting it to fully represent your Tayloe mixer isn't really feasible.
> Maybe the easiest way to accomplish what you're looking to do would be to
> quantify the performance of your LTSpice simulation in a model of a
> quadrature mixer that incorporates error parameters corresponding to your
> mixer's simulated performance. In other words, make a Gnuradio block which
> performs the job of the mixer, while adding the noise and nonlinearities
> observed in your model -- conversion loss, thermal noise, and IQ imbalance,
> for example. What you'd be missing is the end-to-end loop closure that lets
> you make changes to the SPICE model and evaluate them easily.
>
> You could also use GR to construct a synthetic transmission, like you
> suggest, write it to disk, and convert it to a time series format that
> LTSpice can ingest. I know that LTSpice's RAW data format is documented,
> and it looks like there are a couple of Python packages which read and
> write it. Because you can run LTSpice in batch mode, it's conceivable that
> you could automate the whole process in Python -- generate a test signal,
> write it to RAW, run it through LTSpice in batch mode, convert the
> resulting RAW to a complex floating-point IQ signal Gnuradio can read, and
> process it to extract performance parameters in Gnuradio again. Supposedly
> there's also a Python LTSpice integration
> 
> that lets you do everything in Python, in which case you could make a
> Python GR block that would just execute LTSpice from within the block
> itself, in which case you could get really funky with parameter sweeps and
> such.
>
> Sounds like a fun project! If you do write such an integration, please
> consider releasing it to the community as well.
>
> Nick
>
> On Fri, Aug 12, 2022 at 12:14 PM david vanhorn  wrote:
>
>> I have built the detector in ltspice, but i was hoping to use gr to do a
>> "soup to nuts" sim with multiple transmitters and various noise sources,
>> feed that into the Tayloe, and then see what I could do downline from there
>> to recover my signals.
>>
>> On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
>> wrote:
>>
>>> On 2022-08-12 13:38, david vanhorn wrote:
>>> > Ive been wrestling with this for a while, and im not even seeing how
>>> > to get started implementing a Taylor detector in gr.
>>> >
>>> > Is it even possible?
>>> You mean a *Tayloe* Quadrature Sampling Detector?
>>>
>>> This is ordinarily a *hardware component* of certain types of HF
>>> direct-conversion receivers.
>>>
>>> Gnu Radio isn't, primarily, a hardware simulation environment, although
>>> it is the case that many DSP transforms
>>>have hardware analogues, it's not really a hardware simulator.
>>>
>>> It's probably best to tell us what you actually want to achieve, because
>>> unless it's really "simulate a Tayloe QSD",
>>>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
>>> to be that useful...
>>>
>>>
>>>
>>>

-- 
K1FZY (WA4TPW) SK  9/29/37-4/13/15

Re: Taylor detector

[Nick Foster]

David,

OK, I see what you're after now. Gnuradio isn't a SPICE simulator, so
getting it to fully represent your Tayloe mixer isn't really feasible.
Maybe the easiest way to accomplish what you're looking to do would be to
quantify the performance of your LTSpice simulation in a model of a
quadrature mixer that incorporates error parameters corresponding to your
mixer's simulated performance. In other words, make a Gnuradio block which
performs the job of the mixer, while adding the noise and nonlinearities
observed in your model -- conversion loss, thermal noise, and IQ imbalance,
for example. What you'd be missing is the end-to-end loop closure that lets
you make changes to the SPICE model and evaluate them easily.

You could also use GR to construct a synthetic transmission, like you
suggest, write it to disk, and convert it to a time series format that
LTSpice can ingest. I know that LTSpice's RAW data format is documented,
and it looks like there are a couple of Python packages which read and
write it. Because you can run LTSpice in batch mode, it's conceivable that
you could automate the whole process in Python -- generate a test signal,
write it to RAW, run it through LTSpice in batch mode, convert the
resulting RAW to a complex floating-point IQ signal Gnuradio can read, and
process it to extract performance parameters in Gnuradio again. Supposedly
there's also a Python LTSpice integration

that lets you do everything in Python, in which case you could make a
Python GR block that would just execute LTSpice from within the block
itself, in which case you could get really funky with parameter sweeps and
such.

Sounds like a fun project! If you do write such an integration, please
consider releasing it to the community as well.

Nick

On Fri, Aug 12, 2022 at 12:14 PM david vanhorn  wrote:

> I have built the detector in ltspice, but i was hoping to use gr to do a
> "soup to nuts" sim with multiple transmitters and various noise sources,
> feed that into the Tayloe, and then see what I could do downline from there
> to recover my signals.
>
> On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
> wrote:
>
>> On 2022-08-12 13:38, david vanhorn wrote:
>> > Ive been wrestling with this for a while, and im not even seeing how
>> > to get started implementing a Taylor detector in gr.
>> >
>> > Is it even possible?
>> You mean a *Tayloe* Quadrature Sampling Detector?
>>
>> This is ordinarily a *hardware component* of certain types of HF
>> direct-conversion receivers.
>>
>> Gnu Radio isn't, primarily, a hardware simulation environment, although
>> it is the case that many DSP transforms
>>have hardware analogues, it's not really a hardware simulator.
>>
>> It's probably best to tell us what you actually want to achieve, because
>> unless it's really "simulate a Tayloe QSD",
>>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
>> to be that useful...
>>
>>
>>
>>

Re: Taylor detector

[david vanhorn]

I have built the detector in ltspice, but i was hoping to use gr to do a
"soup to nuts" sim with multiple transmitters and various noise sources,
feed that into the Tayloe, and then see what I could do downline from there
to recover my signals.

On Fri, Aug 12, 2022, 12:43 PM Marcus D. Leech 
wrote:

> On 2022-08-12 13:38, david vanhorn wrote:
> > Ive been wrestling with this for a while, and im not even seeing how
> > to get started implementing a Taylor detector in gr.
> >
> > Is it even possible?
> You mean a *Tayloe* Quadrature Sampling Detector?
>
> This is ordinarily a *hardware component* of certain types of HF
> direct-conversion receivers.
>
> Gnu Radio isn't, primarily, a hardware simulation environment, although
> it is the case that many DSP transforms
>have hardware analogues, it's not really a hardware simulator.
>
> It's probably best to tell us what you actually want to achieve, because
> unless it's really "simulate a Tayloe QSD",
>it's unlikely that building a Tayloe QSD in Gnu Radio is really going
> to be that useful...
>
>
>
>

Re: Taylor detector

[Marcus D. Leech]

On 2022-08-12 13:38, david vanhorn wrote:
Ive been wrestling with this for a while, and im not even seeing how 
to get started implementing a Taylor detector in gr.


Is it even possible?

You mean a *Tayloe* Quadrature Sampling Detector?

This is ordinarily a *hardware component* of certain types of HF 
direct-conversion receivers.


Gnu Radio isn't, primarily, a hardware simulation environment, although 
it is the case that many DSP transforms

  have hardware analogues, it's not really a hardware simulator.

It's probably best to tell us what you actually want to achieve, because 
unless it's really "simulate a Tayloe QSD",
  it's unlikely that building a Tayloe QSD in Gnu Radio is really going 
to be that useful...

Re: Taylor detector

[Nick Foster]

David,

A Tayloe detector is of great utility in the "real world" of hardware as a
way to get a quadrature baseband signal from a real passband signal. In the
DSP world things are much easier!

If you have a real-valued signal (i.e., an audio stream), you first convert
it to a complex (quadrature) signal. You can do this in two ways. The first
way is more obvious: use a float-to-complex block and feed the real part
into the real input. Put a constant "0" into the imaginary input. The
result will have both positive and negative frequencies in it -- plot it on
a spectrogram! You can then filter out the negative frequencies with a
complex bandpass filter. Or don't, if they don't bother you: you can always
filter them out with a lowpass after mixing.

More simply, but less obviously, you can use a Hilbert filter to create a
quadrature signal from a real one while eliminating (most of) the negative
frequencies.

Once you have a complex signal, then you mix it with a complex sine wave at
the center frequency of your signal of interest. Mixing is just
multiplication, so use a multiply block with one input as your signal, and
one input the complex sine wave (i.e., from a "Signal Source" block).
Remember to mix with a *negative* frequency, as you're moving your signal
*down*. No NE602 needed! You'll have your complex signal at baseband and
can now filter, demodulate, or do whatever you want to it.

Nick

On Fri, Aug 12, 2022 at 10:43 AM david vanhorn  wrote:

> Ive been wrestling with this for a while, and im not even seeing how to
> get started implementing a Taylor detector in gr.
>
> Is it even possible?
>

Taylor detector

[david vanhorn]

Ive been wrestling with this for a while, and im not even seeing how to get
started implementing a Taylor detector in gr.

Is it even possible?

Problem seeing Hackrf One Hardware properly going through VirtualBox

[George Edwards]

Hello GNURadio Community,

I designed an FM receiver in Gnuradio-Companion to receive an FM broadcast
signal from the Hackrf One. I am running Gnuradio-Companion 3.9 on Ubuntu
20.04 inside VirtualBox 6.1. I installed the Hackrf software on Ubuntu and
set VirtualBox USB port to see the Scott Gadget Hackrf One. Problem is:
when I execute the command "hackrf_info" in the Ubuntu Terminal, it reads
the Board ID, Firmware Version, and Part Number, but says the hackrf_info
version and libhackrf version are "unknown". This is a snapshot of the
terminal response from executing the hackrf_info query:
[image: image.png]

I cannot find any info online to solve this problem (allow the Terminal
query “hackrf_info” to return all the board information). As a result when
I run the GRC flow graph, it fails because it cannot open hackrf. I would
appreciate any suggestions.

Thank you!
George

Re: EXTERNAL: Re: GNU Radio on Mac M1

[Michael Dickens]

I don't know if we'll have GNU Radio 3.10 as the default in MacPorts by
GRCon22. Lots of work to do there, mostly getting GR OOT modules updated to
compatible versions or removed if there isn't such a version. We'll see how
much progress we can make ... 6.5 weeks away, so not impossible ... - MLD

On Fri, Aug 12, 2022 at 10:26 AM Royce Connerley 
wrote:

> Michael:
>
> I would second the vote for 3.10.  Do you think this will be ready by GR
> Con22?
>
> Royce
>
> On May 25, 2022, at 10:52 AM, Price, Rodney D. 
> wrote:
>
> About the version of gnuradio: speaking only for myself, I would prefer to
> see the 3.10 version packaged. I don’t use many OOT blocks. Others may have
> a different opinion. I’m not that set on 3.10, however. Packaging 3.9 would
> be fine by me if others prefer it.
>
> Thanks for doing this,
> -Rod
>
> *From:* Michael Dickens [mailto:michael.dick...@ettus.com
> ]
> *Sent:* Tuesday, May 24, 2022 1:55 PM
> *To:* Ryan Volz
> *Cc:* Price, Rodney D.; discuss-gnuradio@gnu.org
> *Subject:* EXTERNAL: Re: GNU Radio on Mac M1
>
> Related to this general topic -- GR on ARM64:
>
> The MacPorts maintainers of GR are soon going to update the main
> "gnuradio" port ... we're proposing to the current 3.10 release. It is a
> pain to maintain more than 1 related port, and we were waiting for many GR
> OOT modules to be updated before we did this main update. Would folks
> prefer GR 3.9 instead of GR 3.10? I think most GR OOT are ported to GR 3.9
> by now ... more than for 3.10, but I'm sure not all have been ported yet.
> I'm curious folks thoughts here.
>
> Also: Can someone provide more details of the CMake install issue? I
> thought all of the required files were installed into the correct directory
> for CMake to find them.
> ---
> Dr Michael L Dickens
> Principal NI/Ettus Technical Support Engineer
>
>
> On Tue, May 24, 2022 at 3:23 PM Ryan Volz  wrote:
>
> Hi Rod,
>
> I have a positive report from a colleague who is running radioconda on
> an M1 through rosetta with the non-arm64 build. He also reports
> instability with GRC when trying to run the native arm64 packages, so I
> think your best shot might be trying the former with rosetta. (Another
> thing to consider is that gr-qtgui does not exist yet for arm64, since
> conda-forge is still struggling to get the Qt ecosystem built. It has
> been seemingly imminent for 6 months now, so I've stopped holding my
> breath.) Miniconda vs. radioconda should not matter, except for
> convenience in reinstalling if you want to wipe away your whole conda
> installation. I'm not sure in what ways the various packaging methods
> would interfere with each other's Python installations, but removing
> anything you don't need and keeping things minimal is always a good plan.
>
> Cheers,
> Ryan
>
> On 5/24/22 12:19 PM, Price, Rodney D. wrote:
> > Ryan,
> >
> > Thanks for your reply. I looked through the Mac OS X bug reports and
> didn't see anything that looked relevant to my case. The problem isn't
> necessarily connected to GRC. The Macports install seems to be missing some
> essential cmake files (i.e. GrSwig and dependencies). The conda install
> would be preferable, anyway. I'm beginning to wonder about m=y miniconda
> install: I have found multiple Python installs around my system, and after
> removing all my homebrew packages and replacing some with macports
> versions, I wonder if the Python libraries that GNU Radio uses might not be
> the ones that GNU Radio expects. I'm considering removing miniconda and
> replacing it with radioconda. What do you think? Is that likely to work on
> a Mac?
> >
> > Thanks,
> > -Rod
> >
> > -Original Message-
> > From: Ryan Volz [mailto:ryan.v...@gmail.com]
> > Sent: Monday, May 23, 2022 11:21 AM
> > To: Price, Rodney D.; discuss-gnuradio@gnu.org
> > Subject: EXTERNAL: Re: GNU Radio on Mac M1
> >
> > Hi Rod,
> >
> > I think your experience is common, unfortunately, and part of the
> > problem is that there are multiple bugs to work through and not all of
> > them are necessarily with GRC itself. There are multiple dimensions in
> > which things are failing (new vs. old macOS version, switch to arm64,
> > standard DPI display vs. high DPI [Retina] display), so providing as
> > many details about your system as you can would be helpful. As the
> > person putting out the conda packages, it saddens me that I haven't been
> > able to sort through enough of the bugs to get something working for
> people.
> >
> > So, what particular issues are you seeing with the conda install? There
> > are a few bugs tagged for "Mac OS X" on the GNU Radio Github: do any of
> > those apply?
> >
> > One thing a recent report has brought to my attention is a possible bug
> > in conda-forge's cairo package. If you're seeing crashes that might have
> > to do with cairo (e.g. GRC crashes), you could try installing a patched
> > cairo package that I have available on my channel:
> >
> > conda install -c ryanvolz/label/bigsur-patch cairo
> >
> >