On 05/31/2019 11:21 PM, Jiji Varghese wrote:
I am trying to store WiFi signals samples in a file using file sink
block, using GNU radio, for spectrum sensing. I know that a single
WiFi channel has a bandwidth of 20-22 MHz. So should I use the sample
rate in GNU radio block to 40e6 - 44e6 or
I am trying to store WiFi signals samples in a file using file sink block,
using GNU radio, for spectrum sensing. I know that a single WiFi channel
has a bandwidth of 20-22 MHz. So should I use the sample rate in GNU radio
block to 40e6 - 44e6 or can I use a lower value? Can I use 1e6 as sampling
==
*** Announcing Workshops in the Boston Area ***
Ettus Research will be running two free, hands-on, technical
workshops in the Boston area, and you are welcome to attend!
GNU
On 5/31/19 8:23 AM, Michael Dickens wrote:
> Hi Jerry - The GNU Radio live SDR environment might do what you want:
> < https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment >.
> Worth a look, if nothing else. That's the only one that comes to my
> mind; maybe others here have other
First of all, it's Ossmann. Second of all, if you have a pentoo bug
to report please report it: https://www.pentoo.ch/docs/support
Thanks,
Zero_Chaos
On Fri, May 31, 2019 at 11:19 AM geraldfenkell
wrote:
>
>
> 2019-05-31
>
> I am new to GNU radio and am following the Michael Osmond videos on
Hi Jerry - The GNU Radio live SDR environment might do what you want: <
https://wiki.gnuradio.org/index.php/GNU_Radio_Live_SDR_Environment >. Worth a
look, if nothing else. That's the only one that comes to my mind; maybe others
here have other ideas? - MLD
On Fri, May 31, 2019, at 11:19 AM,
2019-05-31
I am new to GNU radio and am following the Michael Osmond videos on
software defined radio.
In that series of videos he suggests downloading the Pentoo (kernel) and
using as a live usb hdd to experiement with GNU radio and Hackone RF (his
hardware device (which I do have))
Hi Tom - Glad to hear that reverting Boost did the trick! The list you note
doesn't really do anything these days; we might as well remove it, since we
then wouldn't need to pretend to maintain it. Hopefully next week I'll get a PR
in for GR to address the Boost 1.70.0 issue; I'm almost there,
Yes, 32i and 16i is probably the best since it avoids a lot of
confusion regarding fixed point. It's very intuitive that a full range
int gets compressed to +-1.0.
Let's see if there's any real world performance gain though, but at
least it's nice and clean using dedicated hardware instructions
Ah, I thought (hurrhurr, a pun) in Q1.15: 15 bits of -0.252525 and
+0.252525 are the same, just the sign bit flips. If it's really just an
interpretation of integers: well, call it 16i
On Fri, 2019-05-31 at 11:45 +0200, Albin Stigö wrote:
> > two's complement being the standard way of
> >
> two's complement being the standard way of
> dealing with numbers
Signed numbers at least...
Signed Q values are (at least in all cases I've seen) stored in two's
complement format. It's just like any other signed integer with an
implied comma.
The Wikipedia article is fairly good:
Hm, wait, realizing something:
Q1.31 differs from what a x86 CPU can reasonably deal with in that it's
not 2's complement for negative numbers; since I'd guess the same
situation applies to ARM (two's complement being the standard way of
dealing with numbers), maybe we should just have one VOLK
What about naming these functions... any ideas? Here are some
suggestions of the top of my head:
volk_32i_convert_32f
volk_q1.32_convert_32f
volk_q1_32_convert_32f
--Albin
On Fri, May 31, 2019 at 10:30 AM Albin Stigö wrote:
>
> Thanks for the feedback Marcus!
>
> Pretty much all SDRs I've
Thanks for the feedback Marcus!
Pretty much all SDRs I've seen use either 8, 16 or 32 bit full range
integers (or 24 bits packed in the most significant bits of a 32 bit
int so can use same conversion as 32 bit).
Yes Q1.15 means 1 sign bit and 15 fractional bits, in practice this
just means that
Hi Albin,
I'd love this, especially if we end up with a kernel that we can use to
build decimating FIR filters that inherently convert to higher-bitwidth
int or floating point.
I think this could be super useful in hardware flow graphs, where one
would get integer numbers from hardware anyway;
Hi,
the data rate of the PHY (derived from the encoding) is not similar to
link-level data rate. You would not reach the PHY data rate even if
frames would be sent back-to-back (overhead from preamble and signal
field). That being said, I'm not sure about your configuration. I don't
think there
Hi,
Volk has functions for converting between int and float by casting and
multiplying with a scalar. I'd like to purpose functions for the
special case where scalar is 1/INT32_MAX (and 1/INT16_MAX etc) as this
is a very common use case and might be available to an optimization.
Certain CPUs
Great to hear you've got it to work.
You might want to open a bug report at Ubuntu's Launchpad and/or at
gtk3-nocsd's github page – this really has not much to do with GNU
Radio, other than GRC using GTK3, which gets hotpatched by gtk3-nocsd.
Best regards,
Marcus
On Thu, 2019-05-30 at 16:42
18 matches
Mail list logo
