[Discuss-gnuradio] Trying to build gr-fcdproplus for GR 3.8

[Barry Duggan]

Hi,

I'm trying to build gr-fcdproplus for GR 3.8

since 'libusb-1.0' was missing, I did:
   "sudo apt-get install libusb-1.0"

to load hidapi, I did 'sudo pip3 install hidapi'

the cmake summary is:
--  Build Summary =
-- Building gr-fcdproplus  : .. for Linux
-- Building for gnuradio   : 3.8.0.0
-- Using CMAKE Module path : 
/home/pi/gr-fcdproplus/cmake/Modules;/usr/local/lib/cmake/gnuradio

-- CMake Modules Dir   : lib/cmake
-- fcdproplus INCLUDES : include/fcdproplus
-- Using install prefix: /usr/local
-- Installing grc files to : /usr/local/share/gnuradio/grc/blocks
-- Bundled hidapi is used
-- 
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/gr-fcdproplus/build

the make produced (second try):
pi@raspberrypi:~/gr-fcdproplus/build $ make -j3
[ 11%] Built target _fcdproplus_swig_doc_tag
[ 23%] Built target pygen_python_34b56
[ 29%] Building CXX object 
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcdpp_control_impl.cc.o
[ 41%] Building CXX object 
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_control_impl.cc.o
[ 41%] Building CXX object 
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_impl.cc.o

In file included from /home/pi/gr-fcdproplus/lib/fcd_control_impl.cc:26:
/home/pi/gr-fcdproplus/lib/fcd_control_impl.h:29:10: fatal error: 
hidapi.h: No such file or directory

 #include "hidapi.h"
  ^~
compilation terminated.
make[2]: *** [lib/CMakeFiles/gnuradio-fcdproplus.dir/build.make:89: 
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcd_control_impl.cc.o] Error 1

make[2]: *** Waiting for unfinished jobs
In file included from 
/home/pi/gr-fcdproplus/lib/fcdpp_control_impl.cc:23:
/home/pi/gr-fcdproplus/lib/fcdpp_control_impl.h:29:10: fatal error: 
hidapi.h: No such file or directory

 #include "hidapi.h"
  ^~
compilation terminated.
[ 47%] Built target doxygen_target
make[2]: *** [lib/CMakeFiles/gnuradio-fcdproplus.dir/build.make:76: 
lib/CMakeFiles/gnuradio-fcdproplus.dir/fcdpp_control_impl.cc.o] Error 1

[ 58%] Built target fcdproplus_swig_swig_doc
[ 64%] Built target fcdproplus_swig_swig_compilation
make[1]: *** [CMakeFiles/Makefile2:141: 
lib/CMakeFiles/gnuradio-fcdproplus.dir/all] Error 2

make: *** [Makefile:130: all] Error 2

What do I need to do to resolve the missing "hidapi.h"? I found a HIDAPI 
package on Git. Is is better / different?


Thanks for your help.
--
Barry Duggan

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.11a capture with HackRF - Why am I not receiving signals anymore?

[Eamon Heaney]

Pic of the output from the QT GUI Frequency sink is shown below. I didn't
see anything significantly different from this, even when I put the radio
right up next to my home router.

I've been told that it would be a good idea to set a DC offset for my
source, but I'm unsure how to calculate that, and it was working without an
offset before.

[image: image.png]

On Mon, Aug 12, 2019 at 8:20 PM Müller, Marcus (CEL) 
wrote:

> Ah OK, but then it's *barely* enough for wifi.
>
> I meant that you attach a visual sink, for example the "Qt GUI
> frequency sink" in GNU Radio directly to your HackRF-interfacing source
> (probably the osmocom source?).
>
> Best regards,
> Marcus
>
> On Mon, 2019-08-12 at 15:27 -0400, Eamon Heaney wrote:
> > Do you mean with a spectrum analyzer? Forgive me if that's a dumb
> > question, I'm a bit new to this.
> >
> > The max bandwidth of the HackRF One is 20MHz, so I should be able to
> > receive data.
> >
> > On Mon, Aug 12, 2019 at 3:13 PM Müller, Marcus (CEL)  > > wrote:
> > > I'd recommend looking at the spectrum you receive. Also, how does
> > > receiving a 20 MHz wide channel with a HackRF work? Wasn't the
> > > maximum
> > > bandwidth of that lower?
> > >
> > > On Mon, 2019-08-12 at 15:10 -0400, Eamon Heaney wrote:
> > > > Last week, I was able to capture wifi packets in the 2.4 GHz band
> > > > (using a modified example from this repo), but now I am unable
> > > to.
> > > > I'm using the same .grc flowchart, with the sample rate and
> > > bandwidth
> > > > both set to 20 MHz, and the channel frequency of 2.412 GHz.
> > > >
> > > > Any idea why that might be? I was previously only able to receive
> > > > signals with my phone right next to the HackRF antenna, but now
> > > even
> > > > that won't help. I tried putting it right next to my router, too,
> > > but
> > > > it still isn't getting anything.
> > > >
> > > > Thanks!
> > > >
> > > > ___
> > > > Discuss-gnuradio mailing list
> > > > Discuss-gnuradio@gnu.org
> > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> >
>


-- 
Eamon Heaney
*Fleet Commander*
*President, Model UN at Virginia Tech*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] GNU Radio Project Call Today!

[Martin Braun]

Hi all,

we have the monthly project call for GNU Radio on today, at the usual time
(10 AM Pacific, 19:00 EU, 1 PM Eastern, other timezones please do your own
math).

Please join us on IRC or Slack where we'll post the link to the call
shortly before it starts.

-- M
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio Runtime buffers and latency

[Wheberth Damascena Dias]

Thank you for your insight Michael.
My block must always produce a fixed size chunk of data, so it is not
directly applicable, but I could use a similar parameter to decide if I
would produce stuffing in the current call to work or not.
Then I could query the status of the output buffer to do so.
I will try that.

Thank you
Wheberth


Em qui, 15 de ago de 2019 às 10:29, Michael Dickens <
michael.dick...@ettus.com> escreveu:

> Hi Wheberth - In a similar block I've created in the past, I include a
> parameter, let's call it "stuffing_size", that is the number of items to
> stuff when stuffing occurs. If this value is small, then there is "small"
> latency between when the PDU comes in and its data is output ... but, the
> block uses a lot of CPU time spinning checking whether it should do "work".
> If this value is large, then the block uses very little CPU time but the
> latency between PDU reception and output is "large". You have to play
> around to find the sweet spot trading off latency and CPU use, but that's
> not too difficult. Maybe this is the way to go for your situation? Hope
> this is useful! - MLD
>
> On Wed, Aug 14, 2019, at 10:56 PM, Wheberth Damascena Dias wrote:
>
> Hi all, I have created an OOT block that receives PDUs as input, stores
> the data in a FIFO buffer and generates a stream as output. Case no data is
> available at the FIFO, stuffing data is generated.
> The block (kind of) works as intended, but when it is on the system with
> no data PDUS being received it does its job and generates stuffing. The
> problem is that, if I understood correctly, the rate of generation is
> controlled by the blocks downstream (via backpressure) meaning it fills all
> buffers of the blocks downstream up to the USRP.
> This makes the next PDUs that arrive to suffer a very high latency.
> I am trying to find a way to limit the buffer of the blocks downstream,
> but it doesn't feel like the right way to deal with this. Another idea is
> to query the status of the output buffer (via pc_output_buffers_full()) and
> generate stuffing data just when it is empty.
> Anyone have faced similar issue? Am I in the right direction?
> Any comments are appreciated.
>
> Best Regards
> --
> *Wheberth Damascena Dias*
> ___ _ _ __ ___ __ _ _ _  _
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Gnuradio Runtime buffers and latency

[Michael Dickens]

Hi Wheberth - In a similar block I've created in the past, I include a 
parameter, let's call it "stuffing_size", that is the number of items to stuff 
when stuffing occurs. If this value is small, then there is "small" latency 
between when the PDU comes in and its data is output ... but, the block uses a 
lot of CPU time spinning checking whether it should do "work". If this value is 
large, then the block uses very little CPU time but the latency between PDU 
reception and output is "large". You have to play around to find the sweet spot 
trading off latency and CPU use, but that's not too difficult. Maybe this is 
the way to go for your situation? Hope this is useful! - MLD

On Wed, Aug 14, 2019, at 10:56 PM, Wheberth Damascena Dias wrote:
> Hi all, I have created an OOT block that receives PDUs as input, stores the 
> data in a FIFO buffer and generates a stream as output. Case no data is 
> available at the FIFO, stuffing data is generated. 
> The block (kind of) works as intended, but when it is on the system with no 
> data PDUS being received it does its job and generates stuffing. The problem 
> is that, if I understood correctly, the rate of generation is controlled by 
> the blocks downstream (via backpressure) meaning it fills all buffers of the 
> blocks downstream up to the USRP.
> This makes the next PDUs that arrive to suffer a very high latency.
> I am trying to find a way to limit the buffer of the blocks downstream, but 
> it doesn't feel like the right way to deal with this. Another idea is to 
> query the status of the output buffer (via pc_output_buffers_full()) and 
> generate stuffing data just when it is empty.
> Anyone have faced similar issue? Am I in the right direction?
> Any comments are appreciated.
> 
> Best Regards 
> -- 
> *Wheberth Damascena Dias*
> ___ _ _ __ ___ __ _ _ _ _ 
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem installing Gnuradio3.8

[Michael Dickens]

Hi Al - I can't speak to PyBOMBS specifically, but the error message shows that 
GMP or MPIR isn't working correctly: "/usr/include/gmpxx.h" should "#include" 
the file "/usr/include/gmp.h", which should contain the function "mpf_cmp_z" 
... just checked my system & this is indeed the case. Maybe somehow the header 
"/usr/include/gmp.h" didn't get installed & you could do that manually? Hope 
this is useful! - MLD

On Thu, Aug 15, 2019, at 7:05 AM, LiverPudd wrote:
> Hi All
> 
> I cannot get gnuradio 3.8 to install. 
> 
> I have installed a clean copy of Ubuntu Mate 18.04 and pybombs on my machine 
> and installed all the pre-requisites required for gnuradio.
> 
> What I have done thus far is;
> 
> 1) Modify gnuradio-default.lwr to point to gnuradio38(.lwr)
> 2) Modify gnuradio38.lwr to include -DENABLE_CTRLPORT_THRIFT=OFF in the 
> config_opt line
> 3) Run "pybombs prefix init ~/src/gr -a gr -R gnuradio-default"
> 
> UHD installed OK without any errors, but the remaining outbut from the build 
> is shown below. 
> 
> Anyone got any ideas how to fix this before I pull out any remaining hair I 
> haved left?
> 
> =
> 
> Cloning into 'gnuradio38'...
> remote: Enumerating objects: 1164, done.
> remote: Counting objects: 100% (1164/1164), done.
> remote: Total 2892 (delta 1164), reused 1164 (delta 1164), pack-reused 1728
> Receiving objects: 100% (2892/2892), 1.28 MiB | 370.00 KiB/s, done.
> Resolving deltas: 100% (2315/2315), completed with 322 local objects.
> Submodule 'volk' (https://github.com/gnuradio/volk.git) registered for path 
> 'volk'
> submodule 'volk' cannot add alternate: path 
> '/home/gonzo/.pybombs/gitcache/modules/volk/' does not existCloning into 
> '/home/gonzo/src/gr/src/gnuradio38/volk'...
> remote: Enumerating objects: 33, done. 
> remote: Counting objects: 100% (33/33), done. 
> remote: Compressing objects: 100% (28/28), done. 
> remote: Total 7961 (delta 8), reused 17 (delta 4), pack-reused 7928 
> Receiving objects: 100% (7961/7961), 2.17 MiB | 332.00 KiB/s, done.
> Resolving deltas: 100% (5522/5522), done.
> Submodule path 'volk': checked out '1299d72c396a88fd2679adfd7a919ac00d2cf678'
> Configuring: (100%) 
> [===]
> Building: (100%) 
> [===]
> [ 6%] Built target volk_obj
> [ 6%] Built target volk
> [ 6%] Built target volk_test_all
> [ 7%] Built target volk-config-info
> [ 8%] Built target volk_profile
> [ 8%] Built target pygen_volk_python_volk_modtool_9770a
> [ 9%] Built target pygen_volk_python_volk_modtool_4d1e3
> [ 9%] Built target doxygen_target
> [ 9%] Built target gnuradio-pmt
> [ 9%] Building CXX object 
> gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o
> In file included from 
> /home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/../include/gnuradio/block.h:34:0,
>  from /home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/block.cc:27:
> /usr/include/gmpxx.h: In static member function ‘static int 
> __gmp_cmp_function::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:912:12: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return mpf_cmp_z(f, z); }
>  ^
> /usr/include/gmpxx.h:912:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z); }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static int 
> __gmp_cmp_function::eval(mpz_srcptr, mpf_srcptr)’:
> /usr/include/gmpxx.h:914:13: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return -mpf_cmp_z(f, z); }
>  ^
> /usr/include/gmpxx.h:914:13: note: suggested alternative: ‘mpf_cmp_d’
>  { return -mpf_cmp_z(f, z); }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_equal::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:980:12: error: ‘mpf_cmp_z’ was not declared in this scope
>  { return mpf_cmp_z(f, z) == 0; }
>  ^
> /usr/include/gmpxx.h:980:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z) == 0; }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_less::eval(mpf_srcptr, mpz_srcptr)’:
> /usr/include/gmpxx.h:1040:12: error: ‘mpf_cmp_z’ was not declared in this 
> scope
>  { return mpf_cmp_z(f, z) < 0; }
>  ^
> /usr/include/gmpxx.h:1040:12: note: suggested alternative: ‘mpf_cmp_d’
>  { return mpf_cmp_z(f, z) < 0; }
>  ^
>  mpf_cmp_d
> /usr/include/gmpxx.h: In static member function ‘static bool 
> __gmp_binary_less::eval(mpz_srcptr, mpf_srcptr)’:
> /usr/include/gmpxx.h:1042:12: error: ‘mpf_cmp_z’ was not declared in this 
> scope
>  { return mpf_cmp_z(f, z) > 0; }
>  ^
> /usr/include/gmpxx.h:1042:12: note: suggested alternative: 

[Discuss-gnuradio] Problem installing Gnuradio3.8

[LiverPudd]

Hi All

I cannot get gnuradio 3.8 to install.

I have installed a clean copy of Ubuntu Mate 18.04 and pybombs on my
machine and installed all the pre-requisites required for gnuradio.

What I have done thus far is;

1) Modify gnuradio-default.lwr to point to gnuradio38(.lwr)
2) Modify gnuradio38.lwr to include -DENABLE_CTRLPORT_THRIFT=OFF in the
config_opt line
3) Run "pybombs prefix init ~/src/gr -a gr -R gnuradio-default"

UHD installed OK without any errors, but the remaining outbut from the
build is shown below.

Anyone got any ideas how to fix this before I pull out any remaining hair I
haved left?

=

Cloning into 'gnuradio38'...
remote: Enumerating objects: 1164, done.
remote: Counting objects: 100% (1164/1164), done.
remote: Total 2892 (delta 1164), reused 1164 (delta 1164), pack-reused 1728
Receiving objects: 100% (2892/2892), 1.28 MiB | 370.00 KiB/s, done.
Resolving deltas: 100% (2315/2315), completed with 322 local objects.
Submodule 'volk' (https://github.com/gnuradio/volk.git) registered for path
'volk'
submodule 'volk' cannot add alternate: path
'/home/gonzo/.pybombs/gitcache/modules/volk/' does not existCloning into
'/home/gonzo/src/gr/src/gnuradio38/volk'...
remote: Enumerating objects: 33, done.
remote: Counting objects: 100% (33/33), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 7961 (delta 8), reused 17 (delta 4), pack-reused 7928
Receiving objects: 100% (7961/7961), 2.17 MiB | 332.00 KiB/s, done.
Resolving deltas: 100% (5522/5522), done.
Submodule path 'volk': checked out
'1299d72c396a88fd2679adfd7a919ac00d2cf678'
Configuring: (100%)
[===]
Building:(100%)
[===]
[  6%] Built target volk_obj
[  6%] Built target volk
[  6%] Built target volk_test_all
[  7%] Built target volk-config-info
[  8%] Built target volk_profile
[  8%] Built target pygen_volk_python_volk_modtool_9770a
[  9%] Built target pygen_volk_python_volk_modtool_4d1e3
[  9%] Built target doxygen_target
[  9%] Built target gnuradio-pmt
[  9%] Building CXX object
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o
In file included from
/home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/../include/gnuradio/block.h:34:0,
 from
/home/gonzo/src/gr/src/gnuradio38/gnuradio-runtime/lib/block.cc:27:
/usr/include/gmpxx.h: In static member function ‘static int
__gmp_cmp_function::eval(mpf_srcptr, mpz_srcptr)’:
/usr/include/gmpxx.h:912:12: error: ‘mpf_cmp_z’ was not declared in this
scope
   { return mpf_cmp_z(f, z); }
^
/usr/include/gmpxx.h:912:12: note: suggested alternative: ‘mpf_cmp_d’
   { return mpf_cmp_z(f, z); }
^
mpf_cmp_d
/usr/include/gmpxx.h: In static member function ‘static int
__gmp_cmp_function::eval(mpz_srcptr, mpf_srcptr)’:
/usr/include/gmpxx.h:914:13: error: ‘mpf_cmp_z’ was not declared in this
scope
   { return -mpf_cmp_z(f, z); }
 ^
/usr/include/gmpxx.h:914:13: note: suggested alternative: ‘mpf_cmp_d’
   { return -mpf_cmp_z(f, z); }
 ^
 mpf_cmp_d
/usr/include/gmpxx.h: In static member function ‘static bool
__gmp_binary_equal::eval(mpf_srcptr, mpz_srcptr)’:
/usr/include/gmpxx.h:980:12: error: ‘mpf_cmp_z’ was not declared in this
scope
   { return mpf_cmp_z(f, z) == 0; }
^
/usr/include/gmpxx.h:980:12: note: suggested alternative: ‘mpf_cmp_d’
   { return mpf_cmp_z(f, z) == 0; }
^
mpf_cmp_d
/usr/include/gmpxx.h: In static member function ‘static bool
__gmp_binary_less::eval(mpf_srcptr, mpz_srcptr)’:
/usr/include/gmpxx.h:1040:12: error: ‘mpf_cmp_z’ was not declared in this
scope
   { return mpf_cmp_z(f, z) < 0; }
^
/usr/include/gmpxx.h:1040:12: note: suggested alternative: ‘mpf_cmp_d’
   { return mpf_cmp_z(f, z) < 0; }
^
mpf_cmp_d
/usr/include/gmpxx.h: In static member function ‘static bool
__gmp_binary_less::eval(mpz_srcptr, mpf_srcptr)’:
/usr/include/gmpxx.h:1042:12: error: ‘mpf_cmp_z’ was not declared in this
scope
   { return mpf_cmp_z(f, z) > 0; }
^
/usr/include/gmpxx.h:1042:12: note: suggested alternative: ‘mpf_cmp_d’
   { return mpf_cmp_z(f, z) > 0; }
^
mpf_cmp_d
gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/build.make:110: recipe
for target
'gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o' failed
make[2]: ***
[gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/block.cc.o] Error 1
CMakeFiles/Makefile2:963: recipe for target
'gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/all' failed
make[1]: *** 

Re: [Discuss-gnuradio] Issue Receiving Messages Using Gr-IEEE-802-15-4

[Bastian Bloessl]

Hi,

there are quite a lot of "XBee" boards. Some of them support multiple
PHYs etc. So please make sure that the device is actually sending
standard compliant IEEE 802.15.4 frames on the channel that you are
tuned to. Use gr-fosphor to make sure that the device is actually
sending on the frequency that you are expecting.

The transceiver, by default, shows a loopback configuration. Make sure
it worked, i.e., it showed something in the PCAP file (you have to
enable the Wireshark block).
When switching to HW, disable the blocks that loop the samples back to
the PHY.

If you still have problems, try different gains, make sure the antenna
is connected to the correct port, make sure there are no overflows. If
you use an SDR with an uncompensated DC offset, you can also try offset
tuning.

If that also doesn't work, please provide more information.

Best,
Bastian


On 8/15/19 9:48 AM, Tellrell White wrote:
> Hello
> I'm using the GR-IEEE 802.15.4 OQPSK Transceiver and I'm trying to
> receive a packet from a XBee ZigBee module and then import that packet
> to wireshark. However, the file sink is always empty after running the
> flowgraph. I have the rime stack, socket pdu, message strobe, and packet
> pad all disabled since I'm simply trying to receive a packet. Is there
> something I need to configure within the MAC block to do this?
> 
> Tellrell
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 

-- 
Dr. Bastian Bloessl
Secure Mobile Networking Lab (SEEMOO)
TU Darmstadt, Germany

www.bastibl.net
GitHub/Twitter: @bastibl



smime.p7s
Description: S/MIME Cryptographic Signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Computation of RFNoC Blocks in GRC

[Felix Greiwe]

Hi Derek,

thank you for your helpful answer!

In the link you sent, they mention that Q16 Format is used as otw Format.
Is that the same as the signed Q1.15 Format? I think it has to be, because
otherwise only positive numbers could be mapped.

I now managed to add numbers from my registers to my signal in GRC in this
Q1.15 Format by multiplying the values in the registers by 2^15 and round
it to the nearest integer in the xml file at:

yourootmodule/rfnoc/blocks/

Thus, if you write 0.1 to the register, for example with a qt-gui range
block, it gets converted to the 2s complement Q1.15 Format. Maybe that
helps other people too.

Best regards

Felix

> Hi Felix,
>
> The USRPs use signed complex 16 bit integers internally in the FPGA.
> These are converted (optionally!) to signed compled 32 bit floating
> point numbers on the host pc by UHD. The format actually sent over
> USB/Ethernet is called the Over The Wire format and the format that the
> user code facing is the CPU format.
> https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
>
> These conversions are scaling operations, multiplication. Which is why
> your multiplication on the FPGA works as you expect it to. Addition on
> the FPGA must be scaled as you found, using the know ledge that a 16 bit
> signed integer will be converted to/from a floating point number and
> normalized to +-1.
>
> You can set the number formats in the USRP Source and Sink blocks, I
> forget if the RFNoC blocks also support that in GNU Radio Companion, but
> you can certainly do it in the underlying Python and C++.
>
> Cheers,
> Derek
>
> On 13/08/2019 14:12, Felix Greiwe wrote:
>> Hello together,
>>
>> I recently created some RFNoC-Blocks using the RFNoC Modtool and an USRP
>> x310 from ETTUS for future GRC application. My Simulation in Vivado went
>> well and thus I built an FPGA-Image and flashed it to my USRP x310
>> device.
>> In GRC however, I witnessed very strange behaviour considering addition
>> operations of my blocks, so I went back to the most simple functioning
>> block, the RFnOC gain block from the RFNoC getting started page:
>>
>> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>> (All Source Files are linked at the bottom of that page, no need to read
>> anything to understand my problem)
>>
>> What that block does, is to receive a signal from GNURadio, split it
>> into
>> I and Q Phase and multiply it by a constant value inside the FPGA of the
>> USRP. The outgoing signal is then the product of input and constant, for
>> example 0.1*5 = 0.5. Important in this case is, that the range of
>> result_values are limited to [-1,1] by the fpga.
>>
>> To test addition instead of multiplication (which works), i edited one
>> single line of the noc_block_gain.v file from
>>
>>  >> wire [31:0] i_mult_gain = i*gain;
>>  >> wire [31:0] q_mult_gain = q*gain;
>>
>> to
>>
>>  >> wire [31:0] i_mult_gain = i+gain; // in_phase component (real)
>>  >> wire [31:0] q_mult_gain = q*gain; // quadrature phase (imag)
>>
>> where gain is a 16 Bit register which can be adressed through GNURadio
>> Companion.
>>
>> In GRC I created a simple flowgraph which generates a complex cosine
>> with
>> I and Q data samples, which then are prossessed by my modified gain
>> block.
>> I expected the Q-Phase to behave exactly like before, and get multiplied
>> by the value in the gain register, and the I-Data to move upwoards in my
>> GRC Time Sink by the value I add to it.
>>
>> Link to picture of Flowgraph:
>> https://ibb.co/s2jSZtK
>>
>> While the expectations considering the multiplication got fulfilled, in
>> the addition part I see no changes in my results. Only when i pump my
>> gain
>> up to great numbers (for example 1), i see a shift upwoards in my
>> diagram. My final observation was, that the shift upwoards is close or
>> equal to: "gain_value"/(2^15 -1).
>>
>> Results with "gain" of 5:
>> https://ibb.co/7zJq2zx
>>
>> Results with "gain" of 26214 (~ (2^15 -1)*0.8):
>> https://ibb.co/dtD6cJ7 (Put Q-Data to invisible here, to see I-Data
>> better)
>>
>> At this point I have a few questions, I hope someone can answer:
>>
>>  - Why do the operations "multiplication" and "addition" differ in
>> behaviour and how can I get my desired "normal" behaviour?
>>
>>  - At which point does GNURadio/RFNoC/theFPGA convert my signals to the
>> range of [-1,1]? Is it always doing this with a fixed formula or only
>> when the number exceeds the range? Any other information considering
>> this?
>>
>> - Does it interpret my 16 Bit gain vector as a simple integer in the
>> multiplication path and as something different,(maybe Q-Format) in the
>> addition path? Why does it not simply add the value of my register to my
>> signal?
>>
>> Any help is greatly appreciated, even when only parts get answered or
>> when
>> it addresses errors in my thougthprocess. I did my best to point out my
>> problem, feel free to ask if you did not understand everything or my
>> mediocre english is 

[Discuss-gnuradio] Issue Receiving Messages Using Gr-IEEE-802-15-4

[Tellrell White]

Hello
I'm using the GR-IEEE 802.15.4 OQPSK Transceiver and I'm trying to receive
a packet from a XBee ZigBee module and then import that packet to
wireshark. However, the file sink is always empty after running the
flowgraph. I have the rime stack, socket pdu, message strobe, and packet
pad all disabled since I'm simply trying to receive a packet. Is there
something I need to configure within the MAC block to do this?

Tellrell
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio