Re: example pfb_sync_test

[sarandis. Doulgeris]

bioic beaver and gnuradio 3.8. installed it :

sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy \
python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \
python3-zmq python3-scipy


sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio

i dont know what thrift is


Στις Πέμ, 13 Φεβ 2020 στις 4:21 μ.μ., ο/η Michael Dickens <
michael.dick...@ettus.com> έγραψε:

> Can you provide us with a little more info here, and that we can try to
> replicate your issue:
>
> * Is the OS "Ubuntu 18.04.3 LTS (Bionic Beaver)" ... or something else?
>
> * Are you trying to use the GNU Radio 3.8.0.0 release?
>
> * How did you install GR?
>
> * what version of Thrift is installed, and how did you install it?
>
>
> On Thu, Feb 13, 2020 at 9:04 AM sarandis. Doulgeris <
> sarandis.doulge...@gmail.com> wrote:
>
>> Hi when i try to run the example i get this error
>>
>> ControlPort Monitor running.
>> python3:
>> /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38:
>> static rpcserver_booter_base* rpcmanager::get(): Assertion
>> `booter_registered || aggregator_registered' failed.
>>
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
>

Re: example pfb_sync_test

[CEL]

Hi Sarandis,

all but the last three lines shouldn't be necessary at all (why did you
install all this?), but they don't hurt, either.

Thrift is a RPC backend, i.e. it allows a program to call functions in
other processes that don't even necessarily have to run on the same
computer.

GNU Radio *can* use thrift internally, but it doesn't have to. Could
you try

sudo apt install thrift-compiler python3-thrift 

and see whether that helps the symptom?

Best regards,
Marcus


On Fri, 2020-02-14 at 14:48 +0200, sarandis. Doulgeris wrote:
> bioic beaver and gnuradio 3.8. installed it :
> sudo apt install git cmake g++ libboost-all-dev libgmp-dev swig python3-numpy 
> \
> python3-mako python3-sphinx python3-lxml doxygen libfftw3-dev \
> libsdl1.2-dev libgsl-dev libqwt-qt5-dev libqt5opengl5-dev python3-pyqt5 \
> liblog4cpp5-dev libzmq3-dev python3-yaml python3-click python3-click-plugins \
> python3-zmq python3-scipy
> 
> sudo add-apt-repository ppa:gnuradio/gnuradio-releases
> sudo apt-get update
> sudo apt-get install gnuradio
> 
> i dont know what thrift is
> 
> Στις Πέμ, 13 Φεβ 2020 στις 4:21 μ.μ., ο/η Michael Dickens 
>  έγραψε:
> > Can you provide us with a little more info here, and that we can try to 
> > replicate your issue:
> > 
> > * Is the OS "Ubuntu 18.04.3 LTS (Bionic Beaver)" ... or something else?
> > 
> > * Are you trying to use the GNU Radio 3.8.0.0 release?
> > 
> > * How did you install GR?
> > 
> > * what version of Thrift is installed, and how did you install it?
> > 
> > 
> > On Thu, Feb 13, 2020 at 9:04 AM sarandis. Doulgeris 
> >  wrote:
> > > Hi when i try to run the example i get this error 
> > > 
> > > ControlPort Monitor running.
> > > python3: 
> > > /build/gnuradio-6i8Hb6/gnuradio-3.8.0.0~gnuradio~bionic/gnuradio-runtime/lib/controlport/rpcmanager.cc:38:
> > >  static rpcserver_booter_base* rpcmanager::get(): Assertion 
> > > `booter_registered || aggregator_registered' failed.
> > 
> > 


smime.p7s
Description: S/MIME cryptographic signature

make error with gr3.8

[Martin Spears]

good afternoon

following this doc ---> 
https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit#heading=h.ocyosag08tha
[https://lh6.googleusercontent.com/NpLjzlqjSnbxqXvWzufp6eebVI2b_nl3zh8nLiVVmDudyD_GsQaH2k4xM11qW3GJhoFav7JEew=w1200-h630-p]
GNU Radio 3.8, Ettus UHD and Ubuntu 
19.10
Install Ubuntu 19.10 Used the network installer on a USB stick, downloads on 
demand. Selected kubuntu-desktop and openssh-server Ignore encfs warning 
Install Ettus UHD Drivers For The B210 (and others) We roughly follow this 
guide, with some modifications for python 3 and the newer package names...
docs.google.com


everything goes perfectly until I do make -j4


~/source/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ../
-- The CXX compiler identification is GNU 7.4.0
-- The C compiler identification is GNU 7.4.0
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Build type not specified: defaulting to release.
-- Build type set to Release.
--
-- The build system will automatically enable all components.
-- Use -DENABLE_DEFAULT=OFF to disable components by default.
--
-- Configuring testing-support support...
--   Enabling testing-support support.
--   Override with -DENABLE_TESTING=ON/OFF
-- Found Git: /usr/bin/git
-- Extracting version information from git describe...
-- Performing Test HAVE_VISIBILITY_HIDDEN
-- Performing Test HAVE_VISIBILITY_HIDDEN - Success
-- Performing Test HAVE_WARN_SIGN_COMPARE
-- Performing Test HAVE_WARN_SIGN_COMPARE - Success
-- Performing Test HAVE_WARN_ALL
-- Performing Test HAVE_WARN_ALL - Success
-- Performing Test HAVE_WARN_NO_UNINITIALIZED
-- Performing Test HAVE_WARN_NO_UNINITIALIZED - Success
-- Compiler Version: cc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-- Compiler Flags: /usr/bin/cc:::-O3 -DNDEBUG  -fvisibility=hidden 
-Wsign-compare -Wall -Wno-uninitialized
/usr/bin/c++:::-O3 -DNDEBUG  -fvisibility=hidden -Wsign-compare -Wall 
-Wno-uninitialized
-- ADDING PERF COUNTERS
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - not found
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   date_time
--   program_options
--   filesystem
--   system
--   regex
--   thread
--   unit_test_framework
--   chrono
--   atomic
-- PYTHON_EXECUTABLE not set - using default python3
-- Use -DPYTHON_EXECUTABLE=/path/to/python2 to build for python2.
-- Found PythonInterp: /usr/bin/python3.6 (found suitable version "3.6.9", 
minimum required is "3.6.5")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython3.6m.so (found suitable 
exact version "3.6.9")
-- Python checking for six - python 2 and 3 compatibility library - found
--
-- Checking for module SWIG
-- Found SWIG version 3.0.12.
-- Found SWIG: /usr/bin/swig3.0
--
-- Configuring python-support support...
--   Dependency PYTHONLIBS_FOUND = TRUE
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency SIX_FOUND = TRUE
--   Enabling python-support support.
--   Override with -DENABLE_PYTHON=ON/OFF
--
-- Configuring VOLK support...
-- Build type set to Release.
-- Extracting version information from git describe...
--
-- Python checking for python >= 2.7
-- Python checking for python >= 2.7 - found
--
-- Python checking for mako >= 0.4.2
-- Python checking for mako >= 0.4.2 - found
--
-- Python checking for six - python 2 and 3 compatibility library
-- Python checking for six - python 2 and 3 compatibility library - found
-- Boost version: 1.65.1
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1")
-- Checking for module 'orc-0.4 > 0.4.11'
--   Found orc-0.4 > 0.4.11, version 0.4.28
-- Found ORC: /usr/lib/x86_64-linux-gnu/liborc-0.4.so
-- Found Doxygen: /usr/bin/doxygen (found version "1.8.13") found components:  
doxygen dot
-- QA Testing is enabled.
--   Modify us

Re: make error with gr3.8

[CEL]

Hi Martin,

1. you're using a guide meant for Ubuntu 19.10, but you are running a
Ubuntu 18.04. So, yeah, that probably works, but really, not what you'd
normally do.
2. UNLESS you really need the Ettus version of UHD, and can't work with
the one supplied with your Ubuntu installation, building anything from
source is a bad idea. 

**Do you REALLY need UHD 3.15 on Ubuntu 18.04**?
It'd be usually easier to just upgrade to Ubuntu 19.10. That has UHD
3.15 in its default installation sources, so no need to build UHD from
source, and you can install GNU Radio linking to that version of UHD
for that without having to compile anything from source. 

Please do not compile software from source unless you really need to;
that's just complications without benefits. We're supplying current GNU
Radio packages for Ubuntu [1] that are way easier to install. But, as
said, you can only work with  a *really* old UHD if you stay on Ubuntu
18.04. Updating your Ubuntu is my recommendation. (Please uninstall all
things you've built from source before updating your Ubuntu: cd
uhd/build; sudo make uninstall)

If you can live with the old version of UHD that Ubuntu 18.04 ships
(e.g. if you have no USRP, or a USRP N210, or so), it's better to not
install UHD from source (i.e. uninstall what you've built from source),
and just follow [1], even on Ubuntu 18.04. 

Regarding your problem: the fact that building breaks when linking gr-
blocks points to insufficient RAM. Back when I started with GNU Radio
about 10 years ago, that was a very common sight. Today, it's rare to
find a PC that has insufficient RAM and not enough Swap, but you seem
to be in the unlucky situation that you're running out of it.
This again stresses the unnecessary amount of complications building
from source brings.

Best regards,
Marcus

[1] 
sudo add-apt-repository ppa:gnuradio/gnuradio-releases
sudo apt-get update
sudo apt-get install gnuradio

This automatically installs the version of UHD your Ubuntu brings (old
UHD 3.10 on Ubuntu 18.04, new Ubuntu 3.15 on Ubuntu 19.10), and
installs GNU Radio. Should take less than 3 Minutes.

Below, a bit of commentary:

On Fri, 2020-02-14 at 18:50 +, Martin Spears wrote:
> following this doc ---> 
> https://docs.google.com/document/d/17gbDc_l32wbNIrXopUWIr1pOpu_Ty8tTeC4t12Ah_XE/edit#heading=h.ocyosag08tha
> 
!!! > Ubuntu 19.04 != Ubuntu 18.04
>  
> GNU Radio 3.8, Ettus UHD and Ubuntu 19.10

<---

> ~/source/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/usr ../

Dangerous, you're installing into directories usually managed by your
Linux distro (i.e. Ubuntu). I do not recommend that.

> […]
> after make -j4
> 
> […]
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_c_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_f_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_s_impl.cc.o
> [ 47%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_i_impl.cc.o
> [ 48%] Building CXX object 
> gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/ctrlport_probe2_b_impl.cc.o
> [ 48%] Linking CXX shared library libgnuradio-blocks.so

This is the most RAM-intense step in the whole GNU Radio build.

> [ 48%] Built target gnuradio-blocks

... Hence my suspicion that you run out of RAM. It might be something
else. The fact that there's no compiler error printed, however,
suggests my suspicion is right. You can usually check using `dmesg`,
whether there's a OOM (out-of-memory) kill log entry somewhere.

> Makefile:140: recipe for target 'all' failed
> make: *** [all] Error 2

:( 



smime.p7s
Description: S/MIME cryptographic signature

Re: GSoC 2020 Introduction

[Sebastian Koslowski]

Hi Akhil,

welcome, good to hear that GNU Radio peaked your interest!

You are absolutely right, C++, Python and Qt are among the most used
technologies inside GNU Radio. And there is always lots to do outside of
the actual DSP and theory thereof.
QtGUI related work is always much appreciated.
Regarding GSoC, Google hasn't announced which organisations have been
accepted yet. So, we're kind of waiting until that happens (see their
timeline [1])  before taking further action.
However, that doesn't mean for you to wait. You head over to GitHub, get
familiar with the code, maybe consider working on some smaller related
issues, get used to the workflow.

Sebastian

[1] https://developers.google.com/open-source/gsoc/timeline

On Fri, Feb 14, 2020 at 7:41 AM Akhil Nair  wrote:

> Hi everyone! I'm Akhil, a second year undergrad in computer engineering at
> AIT Pune, India.I wish to participate in GSoC this year under your
> organization.
>
> I'm afraid I'm completely new to GNU Radio however reading your wiki I
> feel that this community is pretty welcoming and it seems like an
> organization I would enjoy working with this year.
>
> As I mentioned I have no experience with GNU Radio however I'm going
> through the tutorials in the wiki now and am quite willing to learn
> whatever I need to help contribute.
>
> I'm familiar with programming in C++ as well as Python and have worked a
> little on Qt so the Qt5 GUI Integrations idea seems like a good fit for me.
> I'd appreciate it if the mentors could guide me in any way to any
> code/information related to the project. Working on anything related to the
> project or even a partial implementation of the idea would help me grasp
> what is required for the project and what I'm expected to implement.
>
> Last of all, this being a Qt related project I'm assuming there's not much
> theory I should be familiar with, however if there is I'd be glad if you
> could tell me what to learn.
>
> Thanks and Regards,
> Akhil Nair
>

Re: Baseband signals frequency,amplitude,data rate determination.

[CEL]

Hi Md. Atiqur, 

On Fri, 2020-02-14 at 20:43 +0100, Md. Atiqur Rahman wrote:
> For a QPSK modulation technique, I choose to set constellation point 1 to -1, 
> hence 1.4142 would be amplitude

Ah, you're confusing the magnitude of the complex number with the
amplitude of the I and Q component.

So, yes, the magnitude of (1 + 1j), (1 - 1j), (-1 + 1j) and (-1 -1j)
are 1.41, but the real and imaginary parts are still +-1.

>  but in the timing diagram, it looks less than that.

So, that's correct :)

> Another point is, as my sampling rate is 2Mhz, and samples per symbol are 32, 
> hence 62.5K is the symbol rate, what will be my baseband signal frequency? 

0 Hz. That's what "baseband" means.


Best regards,
Marcus

PS: As someone occasionallly advising students, I'd recommend
you clean up your flow graph; there's blocks in there you've commented
out that you can never use (WX can't coexist with QT GUI). Also, try to
make it as linear as possible, so to make it really easy to follow the
"sample flow" optically. This is the Nr. 1 debugging hint for GRC
beginners, and it really helps a lot when talking about a flow graph.

Also, by the way, you're using a legacy GNU Radio. We've released GR
3.8, and you're still on 3.7.; the new GNU Radio has fewer bugs, and
vector export for GRC figures, which is important to anyone writing a
thesis with GRC flow graph pictures ;)


smime.p7s
Description: S/MIME cryptographic signature

Re: Baseband signals frequency,amplitude,data rate determination.

[Md. Atiqur Rahman]

Thank you for the clarification.  I will update it to 3.8 soon.
However, baseband is the main signal which will be converted to RF signal
by means of upconverter. I have a SDR device(red-pitaya), in which two
digitally modulated baseband signals(I-Q) will come out separately and
later on with RF front end it will be mixed with high frequency. That is
the main idea. Hence, first, I need the basic baseband signal (low
frequency) but it would be a 0Hz frequency? That I have no idea of. The
timing diagram is showing the signal has some certain frequency, then it
would be 0?
Would you please give me some details. Thank you so much.

ps: WX block insertion was a mistake. I didn't realize it until you
mentioned it. As I am going to write a report on my work as well, it is
great to know that now the graph can be export. Is there any updates also
for extracting GRC flow graph from file>screen capture  as well?

On Fri, Feb 14, 2020 at 9:01 PM Müller, Marcus (CEL) 
wrote:

> Hi Md. Atiqur,
>
> On Fri, 2020-02-14 at 20:43 +0100, Md. Atiqur Rahman wrote:
> > For a QPSK modulation technique, I choose to set constellation point 1
> to -1, hence 1.4142 would be amplitude
>
> Ah, you're confusing the magnitude of the complex number with the
> amplitude of the I and Q component.
>
> So, yes, the magnitude of (1 + 1j), (1 - 1j), (-1 + 1j) and (-1 -1j)
> are 1.41, but the real and imaginary parts are still +-1.
>
> >  but in the timing diagram, it looks less than that.
>
> So, that's correct :)
>
> > Another point is, as my sampling rate is 2Mhz, and samples per symbol
> are 32, hence 62.5K is the symbol rate, what will be my baseband signal
> frequency?
>
> 0 Hz. That's what "baseband" means.
>
>
> Best regards,
> Marcus
>
> PS: As someone occasionallly advising students, I'd recommend
> you clean up your flow graph; there's blocks in there you've commented
> out that you can never use (WX can't coexist with QT GUI). Also, try to
> make it as linear as possible, so to make it really easy to follow the
> "sample flow" optically. This is the Nr. 1 debugging hint for GRC
> beginners, and it really helps a lot when talking about a flow graph.
>
> Also, by the way, you're using a legacy GNU Radio. We've released GR
> 3.8, and you're still on 3.7.; the new GNU Radio has fewer bugs, and
> vector export for GRC figures, which is important to anyone writing a
> thesis with GRC flow graph pictures ;)
>


-- 
Sincerely,
Md Atiqur Rahman
Hochschule Bremen

Re: Baseband signals frequency,amplitude,data rate determination.

[CEL]

Hello,

> I need the basic baseband signal (low frequency) but it would be a
0Hz frequency?

Yes, as said, it would be a band-limited signal around 0 Hz. That's the
definition of baseband signal.

I'm not sure what you mean with

> timing diagram is showing the signal has some certain frequency

A timing diagram (not _quite_ sure what that is) shows no frequency.

Are you perhaps mixing up bandwidth and frequency? Or maybe symbol
rate? (But you already have some calculations of symbol rate, so I'm
really not sure what you mean.)

Regarding bandwidth: Bandwidth of a linear modulation (without Bias) is
always fully defined by the pulse shaping filter. You have one of these
in your system!

Best regards,
Marcus

PS: 
https://www.analog.com/media/en/training-seminars/design-handbooks/Software-Defined-Radio-for-Engineers-2018/SDR4Engineers.pdf
might be a good place to start; you have gaps in understanding of
chapters 2.1–2.3, 2.7, and 4.1–4.2, it seems. It'll be very hard for
you to understand what your equalizer and synchronizers do.


On Fri, 2020-02-14 at 21:24 +0100, Md. Atiqur Rahman wrote:
> Thank you for the clarification.  I will update it to 3.8 soon. 
> However, baseband is the main signal which will be converted to RF signal by 
> means of upconverter. I have a SDR device(red-pitaya), in which two digitally 
> modulated baseband signals(I-Q) will come out separately and later on with RF 
> front end it will be mixed with high frequency. That is the main idea. Hence, 
> first, I need the basic baseband signal (low frequency) but it would be a 0Hz 
> frequency? That I have no idea of. The timing diagram is showing the signal 
> has some certain frequency, then it would be 0? 
> Would you please give me some details. Thank you so much.
> 
> ps: WX block insertion was a mistake. I didn't realize it until you mentioned 
> it. As I am going to write a report on my work as well, it is great to know 
> that now the graph can be export. Is there any updates also for extracting 
> GRC flow graph from file>screen capture  as well?
> 
> On Fri, Feb 14, 2020 at 9:01 PM Müller, Marcus (CEL)  wrote:
> > Hi Md. Atiqur, 
> > 
> > On Fri, 2020-02-14 at 20:43 +0100, Md. Atiqur Rahman wrote:
> > > For a QPSK modulation technique, I choose to set constellation point 1 to 
> > > -1, hence 1.4142 would be amplitude
> > 
> > Ah, you're confusing the magnitude of the complex number with the
> > amplitude of the I and Q component.
> > 
> > So, yes, the magnitude of (1 + 1j), (1 - 1j), (-1 + 1j) and (-1 -1j)
> > are 1.41, but the real and imaginary parts are still +-1.
> > 
> > >  but in the timing diagram, it looks less than that.
> > 
> > So, that's correct :)
> > 
> > > Another point is, as my sampling rate is 2Mhz, and samples per symbol are 
> > > 32, hence 62.5K is the symbol rate, what will be my baseband signal 
> > > frequency? 
> > 
> > 0 Hz. That's what "baseband" means.
> > 
> > 
> > Best regards,
> > Marcus
> > 
> > PS: As someone occasionallly advising students, I'd recommend
> > you clean up your flow graph; there's blocks in there you've commented
> > out that you can never use (WX can't coexist with QT GUI). Also, try to
> > make it as linear as possible, so to make it really easy to follow the
> > "sample flow" optically. This is the Nr. 1 debugging hint for GRC
> > beginners, and it really helps a lot when talking about a flow graph.
> > 
> > Also, by the way, you're using a legacy GNU Radio. We've released GR
> > 3.8, and you're still on 3.7.; the new GNU Radio has fewer bugs, and
> > vector export for GRC figures, which is important to anyone writing a
> > thesis with GRC flow graph pictures ;)
> 
> 


smime.p7s
Description: S/MIME cryptographic signature

About the transceiver and sending packets to / from a hardware

[sampath ranga]

Hello Mr. Bloessl Bastian,

How are you? I am Ranganathan Sampathkumar, one of the research
students who gave request to you through Linkedin a few days ago. I was
reading through your research paper IEEE802.15.4 test bed through USRP
(transceiver). Thank you for giving such a wonderful paper to read through.
I also have few questions regarding that. My questions are:

1. Is the implementation verification can only be done with TelosB mote
with contiki firmware? Can we use other Zigbee hardware to sniff the
message ? When i tried to do that i can transceive the message successfully
in Wireshark whereas for implementation when i use a different hardware ,
the particular hardware couldnot sniff the messages.
 2. Or if i do in reverse, say for example if i try to send a message from
other Zigbee device to the GNU Radio that has transceiver code with .pcap
file, I am seeing the "packets that has been sent from the transceiver in
.pcap file at Wireshark  but the .pcap file doesnot have the message from
the other hardware device".

Is that the rime stack that is controlling it from sending or receiving
message from other device cause its network layer or is it MAC layer? Cause
i have been same channel number, same PAN ID in both the hardware and in
GNU block but still it couldnt hear or send to other hardware

Can you/someone throw me a light on this ? Like do the transceiver block
can send message to other Zigbee hardware or can it receive from the other
hardware ?

Thanks and regards,
Ranganathan Sampathkumar

Re: About the transceiver and sending packets to / from a hardware

[CEL]

Hi!

On Fri, 2020-02-14 at 14:57 -0600, sampath ranga wrote:
> How are you? I am Ranganathan Sampathkumar, one of the research students who 
> gave request to you through Linkedin a few days ago.

I'd respectfully like to point out that as an author and maintainer of
open source software, it's often a very time-consuming task to read the
private messages asking for advice about one's projects. Knowing the
less-than-amusing messages that show up on the issues on Basti's
software projects, I think it what reaches him in private actually be a
really bad burden for him.

It's really much better that you wrote here to the mailing list; in
general, unless it's really something that *must* be done in privacy,
it's polite to use the public platforms of open source projects and
communities. Thanks for reaching out in this public way!

> 1. Is the implementation verification can only be done with TelosB mote with 
> contiki firmware? 

Haven't played with in a while, but gr-ieee802-15-4 is at least as far
as I know a standards-compliant implementation: If you configure it in
a standards-compliant way, it simply "speaks" zigbee. 

> Can we use other Zigbee hardware to sniff the message?

Yes?

>  When i tried to do that i can transceive the message successfully in 
> Wireshark 

with what did you try? Notice that the Wireshark dissector might not
like the packet format of all capture devices.

>  2. Or if i do in reverse, say for example if i try to send a message
> from other Zigbee device to the GNU Radio that has transceiver code
> with .pcap file, I am seeing the "packets that has been sent from the
> transceiver in .pcap file at Wireshark  but the .pcap file doesnot
> have the message from the other hardware device".

There's different 802.15.4 PHYs, make sure you're using the same, and
appropriately configured, for your other device. There's more that can
go wrong here than can go right – employ your signal processing
knowledge and the Qt GUI sinks to inspect what you're receiving while
you are receiving it.

Best regards,
Marcus


smime.p7s
Description: S/MIME cryptographic signature

Re: About the transceiver and sending packets to / from a hardware

[sampath ranga]

Hello Mr.Marcus Muller ,

   I totally understand and i apologize for not asking my question in
public . I am new to this forum . I have been working on gnu radio for some
time and just came to know about this platform that does discussion . So I
just got an idea of how to subscribe and how to post the questions. I am
totally sorry if something is wrong . Yes i will see through the reply you
sent and try to work on it and will get you back soon

Thanks and regards ,
Ranganathan Sampathkumar

On Fri, Feb 14, 2020 at 4:31 PM Müller, Marcus (CEL) 
wrote:

> Hi!
>
> On Fri, 2020-02-14 at 14:57 -0600, sampath ranga wrote:
> > How are you? I am Ranganathan Sampathkumar, one of the research students
> who gave request to you through Linkedin a few days ago.
>
> I'd respectfully like to point out that as an author and maintainer of
> open source software, it's often a very time-consuming task to read the
> private messages asking for advice about one's projects. Knowing the
> less-than-amusing messages that show up on the issues on Basti's
> software projects, I think it what reaches him in private actually be a
> really bad burden for him.
>
> It's really much better that you wrote here to the mailing list; in
> general, unless it's really something that *must* be done in privacy,
> it's polite to use the public platforms of open source projects and
> communities. Thanks for reaching out in this public way!
>
> > 1. Is the implementation verification can only be done with TelosB mote
> with contiki firmware?
>
> Haven't played with in a while, but gr-ieee802-15-4 is at least as far
> as I know a standards-compliant implementation: If you configure it in
> a standards-compliant way, it simply "speaks" zigbee.
>
> > Can we use other Zigbee hardware to sniff the message?
>
> Yes?
>
> >  When i tried to do that i can transceive the message successfully in
> Wireshark
>
> with what did you try? Notice that the Wireshark dissector might not
> like the packet format of all capture devices.
>
> >  2. Or if i do in reverse, say for example if i try to send a message
> > from other Zigbee device to the GNU Radio that has transceiver code
> > with .pcap file, I am seeing the "packets that has been sent from the
> > transceiver in .pcap file at Wireshark  but the .pcap file doesnot
> > have the message from the other hardware device".
>
> There's different 802.15.4 PHYs, make sure you're using the same, and
> appropriately configured, for your other device. There's more that can
> go wrong here than can go right – employ your signal processing
> knowledge and the Qt GUI sinks to inspect what you're receiving while
> you are receiving it.
>
> Best regards,
> Marcus
>

Re: About the transceiver and sending packets to / from a hardware

[CEL]

It's great that you posted here! I was thanking you for that! Welcome
to the community!

On Fri, 2020-02-14 at 16:37 -0600, sampath ranga wrote:
> Hello Mr.Marcus Muller , 
> 
>I totally understand and i apologize for not asking my question in public 
> . I am new to this forum . I have been working on gnu radio for some time and 
> just came to know about this platform that does discussion . So I just got an 
> idea of how to subscribe and how to post the questions. I am totally sorry if 
> something is wrong . Yes i will see through the reply you sent and try to 
> work on it and will get you back soon 
> 
> Thanks and regards , 
> Ranganathan Sampathkumar 
> 
> On Fri, Feb 14, 2020 at 4:31 PM Müller, Marcus (CEL)  wrote:
> > Hi!
> > 
> > On Fri, 2020-02-14 at 14:57 -0600, sampath ranga wrote:
> > > How are you? I am Ranganathan Sampathkumar, one of the research students 
> > > who gave request to you through Linkedin a few days ago.
> > 
> > I'd respectfully like to point out that as an author and maintainer of
> > open source software, it's often a very time-consuming task to read the
> > private messages asking for advice about one's projects. Knowing the
> > less-than-amusing messages that show up on the issues on Basti's
> > software projects, I think it what reaches him in private actually be a
> > really bad burden for him.
> > 
> > It's really much better that you wrote here to the mailing list; in
> > general, unless it's really something that *must* be done in privacy,
> > it's polite to use the public platforms of open source projects and
> > communities. Thanks for reaching out in this public way!
> > 
> > > 1. Is the implementation verification can only be done with TelosB mote 
> > > with contiki firmware? 
> > 
> > Haven't played with in a while, but gr-ieee802-15-4 is at least as far
> > as I know a standards-compliant implementation: If you configure it in
> > a standards-compliant way, it simply "speaks" zigbee. 
> > 
> > > Can we use other Zigbee hardware to sniff the message?
> > 
> > Yes?
> > 
> > >  When i tried to do that i can transceive the message successfully in 
> > > Wireshark 
> > 
> > with what did you try? Notice that the Wireshark dissector might not
> > like the packet format of all capture devices.
> > 
> > >  2. Or if i do in reverse, say for example if i try to send a message
> > > from other Zigbee device to the GNU Radio that has transceiver code
> > > with .pcap file, I am seeing the "packets that has been sent from the
> > > transceiver in .pcap file at Wireshark  but the .pcap file doesnot
> > > have the message from the other hardware device".
> > 
> > There's different 802.15.4 PHYs, make sure you're using the same, and
> > appropriately configured, for your other device. There's more that can
> > go wrong here than can go right – employ your signal processing
> > knowledge and the Qt GUI sinks to inspect what you're receiving while
> > you are receiving it.
> > 
> > Best regards,
> > Marcus


smime.p7s
Description: S/MIME cryptographic signature