Re: [Discuss-gnuradio] Problems with IEEE802-11 Blocks?

[Bastian Bloessl]

Hi,

> On 11. Jul 2017, at 02:04, Taylor Eisman  wrote:
> 
> Well, I've been trying to place Packet Pad 2 around the WiFi Phy Hier example 
> setup to get good results and still have not achieved any decent results. 
> Three things are possible, given specific placements of the Packet Pad 2 
> block: 1) WiFi MAC Decode detects 26 out of 29 packets

And what did you change with regard to the loopback flowgraph in the examples 
folder? I assume the loopback flowgraph works for you and your modifications 
leat to these problems.

> 2) WiFi MAC Decode receives the file but fails the checksum

Not sure what you mean and why there is a file involved. If the checksum fails 
the frame data (header and/or payload) was corrupted (either due to flowgraph 
modifications or bad SNR)

> 3) The Packet Pad 2 block fails to see the tagged stream.

I assume you placed it wrong. AFAIS, the screenshot doesn’t help much, as it 
shows the unmodified hier block.


> Does anybody have suggestions as to where to place Packet Pad 2 in the WiFi 
> Phy Hier example?

The hier block is not meant to be modified, but used in other blocks. The 
transceiver flow graph (meant for use with HW) and the loopback flow graph 
(runs without HW) will  show you how to use it. The loopback flow graph uses 
the Packet Pad block. Just start from that and gradually adjust the flowgraph 
for your experiments.

Best,
Bastian




> 
> Thanks,
> 
> Taylor
> 
> On Mon, Jul 10, 2017 at 2:14 AM, Bastian Bloessl  wrote:
> Hi,
> 
> please keep the conversation on the list.
> 
> On 7/9/2017 5:36 PM, Taylor Eisman wrote:
> Hey,
> 
> I went ahead and substituted Wifi Hier Phy into my program, and it made no 
> difference; however, I did end up using Packet Pad, and it was able to 
> receive a full frame. Using Packet Pad did not completely solve the problem 
> though because it does not pass the checksum check.
> 
> I tested the flowgraph without padding, i.e., frames back to back, and also 
> saw the problem mentioned in your previous email. So this was really related 
> to padding.
> 
> If your frames have a wrong checksum, they were not received correctly. 
> That's a different problem. What you want is not disable the checksum, but 
> understand why the frames got corrupted.
> 
> I don't know what your flowgraph is doing, but check the signal quality of 
> the stream that you feed into the WiFi receiver. Also avoid sending frames 
> padded with zeros (add a bit of noise).
> 
> Best,
> Bastian
> 
> Is there any way to quickly pass the checksum?
> 
> Thanks,
> Taylor
> 
> On Sun, Jul 9, 2017 at 1:57 AM, Bastian Bloessl  > wrote:
> 
> Hi,
> 
> I recommend to start with the example flow graph and make sure that
> it works works for you. If that works, just replace the constant
> message source with the data that you want to transmit.
> Did you maybe delete the packet pad block and just sent data back to
> back without any space in between?
> 
> Best,
> Bastian
> 
> 
> On 07/08/2017 09:20 PM, Taylor Eisman wrote:
> 
> I've been trying to use the IEEE802-11 blocks to simulate Wi-Fi
> environments. I've generated data from the local radio station,
> tagged it, modulated, etc. It is never able to generate a file
> at the end and I've tracked it down to an issue in the WiFi
> Decode block.
> 
> This is the error that the WiFi Decode block generates:
> 
> Decode MAC: frame start -- len 250  symbols 29  encoding 3
> copy one symbol, copied 0 out of 29
> copy one symbol, copied 1 out of 29
> copy one symbol, copied 2 out of 29
> copy one symbol, copied 3 out of 29
> copy one symbol, copied 4 out of 29
> copy one symbol, copied 5 out of 29
> copy one symbol, copied 6 out of 29
> copy one symbol, copied 7 out of 29
> copy one symbol, copied 8 out of 29
> copy one symbol, copied 9 out of 29
> copy one symbol, copied 10 out of 29
> copy one symbol, copied 11 out of 29
> copy one symbol, copied 12 out of 29
> copy one symbol, copied 13 out of 29
> copy one symbol, copied 14 out of 29
> copy one symbol, copied 15 out of 29
> copy one symbol, copied 16 out of 29
> copy one symbol, copied 17 out of 29
> copy one symbol, copied 18 out of 29
> copy one symbol, copied 19 out of 29
> copy one symbol, copied 20 out of 29
> copy one symbol, copied 21 out of 29
> copy one symbol, copied 22 out of 29
> copy one symbol, copied 23 out of 29
> Decode MAC: input 1
> copy one symbol, copied 24 out of 29
> Decode MAC: input 25
> copy one symbol, copied 25 out of 29
> Warning: starting to receive new frame before old frame was complete
> Already copied 26 out of 29 symbols of last frame
> 
> I've tried changing the source file to somet

Re: [Discuss-gnuradio] How to process file sink from UHD Source USRP

[Marcus Müller]

You're just saving samples from the USRP – there's no info like
"frequency" or "time" attached to those. It's just a very long row of
complex numbers.

Best regards,

Marcus


On 07/11/2017 01:23 AM, Sinta Novtafiani wrote:
> Hello Marcus,
>
> Thankyou for your advice. I just want to know data actual of my
> program like frequency, time and power then save as file txt so i can
> read the data anytime. But i have problem, when i read the raw binary
> file use those source code above, its appears float data in one
> coloumn and i don't know which one frequency, time, or power because i
> didn't got header of the data. I have to convert .dat file into format
> that can read anywhere or convert to numerical data in matrix because
> the data will process furthermore 
>
> On Jul 10, 2017 2:09 PM, "Marcus Müller"  > wrote:
>
> Dear Sinta,
>
> I've had this discussion several times before, so let me please
> shortly mention that you've signed up to the mailing list via
> Nabble, which is a very suboptimal thing for you (you might miss
> answers posted by us). Please sign out of nabble, and sign up
> directly to
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> ; enough
> of that :)
>
> This is more of a collection of thoughts for future readers than
> direct criticism on your approach:
>
> Well, I really don't know why you would want a text file
> containing float samples. It doesn't make sense from a precision
> point of view, it doesn't make sense from a storage size point of
> view, and it doesn't even make sense from a usability point of
> view – I don't really believe you'll get a "feeling" for data if
> you scroll around in a 1mio lines text file :)
>
> That being said, there's probably very legitimate reason you'd
> want a CSV file (for example, get a couple data points only to
> import them into a spreadsheet software). You probably want to
> look into the "Head" block that limits the number of items going
> through.
>
> Also, you could just as well in your Python code not save all of
> `data`, but only let's say `data[:100]`.
>
> Best regards,
>
> Marcus
>
> On 07/10/2017 08:54 AM, Sinta Novtafiani wrote:
>> Hello Nicholas,
>>
>> Thankyou for your reply. I've try that way and its work. I have a
>> problem, my file that generate from file sink is big. And it
>> cause text edtior become not reponding when i open file that have
>> converted to txt. Did you know how to control file size from file
>> sink?
>>
>> I use this code below to convert binary file into txt
>>
>> data=scipy.fromfile(open('filename'), dtype=scipy.float32)
>> scipy.savetxt('filename.txt', data)
>>
>> On Mon, Jul 10, 2017 at 1:52 AM, Nicolas Cuervo
>> mailto:nicolas.cue...@ettus.com>> wrote:
>>
>> Hello Sinta,
>>
>> This specific question is handled in the GNURadio FAQ [1].
>> Please try to use the scipy.fromfile() method and check if
>> the output agrees with your expectations.
>>
>> Regards,
>> - Nicolas
>>
>> [1] 
>> https://wiki.gnuradio.org/index.php/FAQ#What_is_the_file_format_of_a_file_sink.3F_How_can_I_read_files_produced_by_a_file_sink.3F
>> 
>> 
>>
>> On Mon, Jul 10, 2017 at 5:25 AM, Sinta Novtafiani
>> mailto:snvt...@gmail.com>> wrote:
>>
>> I got UHD Source receiver with frequency sweeper, its
>> working fine but i need
>> to read and actually process the data to make graph out
>> of it without using
>> QT GUI, i try to open with hex editor but dont seem to
>> understand the
>> pattern of the file that i need to process, im making
>> python program to
>> convert it to numbers but the number that comes up doesnt
>> seem relevant with
>> the one i see at QT GUI.
>> > >
>> > >
>>
>>
>>
>> --
>> View this message in context:
>> 
>> http://gnuradio.4.n7.nabble.com/How-to-process-file-sink-from-UHD-Source-USRP-tp64518.html
>> 
>> 
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnurad

[Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[sumit kumar]

Hi,

I have to do timing analysis of individual blocks of gr-ieee80211
I have built my gnuradio with the following

~/rfnoc/src/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
-DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On -Werror
../

build was successful.

And again I built gr-ieee80211 with following

~/rfnoc/src/gr-ieee-80211/build$ cmake
-DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DENABLE_PERFORMANCE_COUNTERS=On -Werror ../

However I get a warning that
*CMake Warning:*
*  Manually-specified variables were not used by the project:*

*ENABLE_PERFORMANCE_COUNTERS*

In order to do timing analysis of individual blocks of gr-ieee80211, I am
following the documentation at
https://gnuradio.org/doc/doxygen/page_perf_counters.html

Does only GNU Radio need to be built with the  flag
-DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?

~~
john@john-Precision-5510:~/rfnoc/src/gr-ieee-80211/build$ cmake
-DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
-DENABLE_PERFORMANCE_COUNTERS=On -Werror ../
-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
Checking for GNU Radio Module: RUNTIME
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/
john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_RUNTIME_FOUND = TRUE
Checking for GNU Radio Module: DIGITAL
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-digital.so;/home/
john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/
lib/libgnuradio-pmt.so
GNURADIO_DIGITAL_FOUND = TRUE
Checking for GNU Radio Module: FFT
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-fft.so;/home/john/
rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_FFT_FOUND = TRUE
Checking for GNU Radio Module: FILTER
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-filter.so;/home/
john/rfnoc/lib/libgnuradio-fft.so;/home/john/rfnoc/lib/
libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_FILTER_FOUND = TRUE
Checking for GNU Radio Module: PMT
 * INCLUDES=/home/john/rfnoc/include
 * LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/
john/rfnoc/lib/libgnuradio-pmt.so
GNURADIO_PMT_FOUND = TRUE
-- Found LOG4CPP: /usr/lib/liblog4cpp.so
-- 
-- Checking for module SWIG
-- Found SWIG version 3.0.8.
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

ENABLE_PERFORMANCE_COUNTERS


-- Build files have been written to: /home/john/rfnoc/src/gr-ieee-
80211/build
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[Marcus Müller]

Hi Sumit,

> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
exactly, only GNU Radio needs to be built with that flag – functionally,
it's something that is done in the scheduler, not in the blocks the
scheduler runs.

Best regards,

Marcus


On 07/11/2017 12:59 PM, sumit kumar wrote:
> Hi, 
>
> I have to do timing analysis of individual blocks of gr-ieee80211
> I have built my gnuradio with the following 
>
> ~/rfnoc/src/gnuradio/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> build was successful. 
>
> And again I built gr-ieee80211 with following 
>
> ~/rfnoc/src/gr-ieee-80211/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> However I get a warning that 
> *CMake Warning:*
> *  Manually-specified variables were not used by the project:*
> *
> *
> *ENABLE_PERFORMANCE_COUNTERS*
> *
> *
> In order to do timing analysis of individual blocks of gr-ieee80211, I
> am following the documentation at
> https://gnuradio.org/doc/doxygen/page_perf_counters.html
> 
>
> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ? 
>
> ~~
> john@john-Precision-5510:~/rfnoc/src/gr-ieee-80211/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> Checking for GNU Radio Module: RUNTIME
>  * INCLUDES=/home/john/rfnoc/include
>  *
> LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> Checking for GNU Radio Module: DIGITAL
>  * INCLUDES=/home/john/rfnoc/include
>  *
> LIBS=/home/john/rfnoc/lib/libgnuradio-digital.so;/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_DIGITAL_FOUND = TRUE
> Checking for GNU Radio Module: FFT
>  * INCLUDES=/home/john/rfnoc/include
>  *
> LIBS=/home/john/rfnoc/lib/libgnuradio-fft.so;/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_FFT_FOUND = TRUE
> Checking for GNU Radio Module: FILTER
>  * INCLUDES=/home/john/rfnoc/include
>  *
> LIBS=/home/john/rfnoc/lib/libgnuradio-filter.so;/home/john/rfnoc/lib/libgnuradio-fft.so;/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_FILTER_FOUND = TRUE
> Checking for GNU Radio Module: PMT
>  * INCLUDES=/home/john/rfnoc/include
>  *
> LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_PMT_FOUND = TRUE
> -- Found LOG4CPP: /usr/lib/liblog4cpp.so
> -- 
> -- Checking for module SWIG
> -- Found SWIG version 3.0.8.
> -- Configuring done
> -- Generating done
> CMake Warning:
>   Manually-specified variables were not used by the project:
>
> ENABLE_PERFORMANCE_COUNTERS
>
>
> -- Build files have been written to:
> /home/john/rfnoc/src/gr-ieee-80211/build
>
>
>
>
>
> ___
> 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

[Discuss-gnuradio] Chunks to symbols with 16 QAM modulation

[Rafik ZITOUNI]

Dear gnuradio users,

I am trying to use digital_chunks_to_symbols to reconstruct block by block
my QAM modulator.

Please could you give me an idea how to set the constellation points in
Symbol Table field?  I can do it with BPSK, QPSK and 8PSK using
constellation[0].points, constellation[1].points and
constellation[2].points, but how can I do it with 16 QAM ?

For my 16 QAM receiver, could you please tell me if it's possible to have a
constellation points view?

Best,

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

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[sumit kumar]

Ok I understood. Now I have a following question.

I did a grep in the build directory

grep -r 'work_time_total' .

And I found that indeed its there as said on https://gnuradio.org/doc/doxyg
en/page_perf_counters.html
It  seems a lot of task is already been done ! :)

Then I opened gnuradio-runtime.conf.in and did the following (as mentioned
in the documentation)

[PerfCounters]
on = True
export = True
#clock = thread
clock = monotonic

Now I run my application , for example wifi_rx.py

Where do I see the timings ?

I opened the ieee802_11_swig.py, and I see def pc_work_time_total(self)
is there for all the blocks, but how to use them :-/

Can you give a use case, for example :

In line 1953 of ieee802_11_swig.py, we have

class frame_equalizer_sptr(object):

and inside this calss we have the function :

def pc_work_time_total(self):
"""pc_work_time_total(frame_equalizer_sptr self) -> float"""
return
_ieee802_11_swig.frame_equalizer_sptr_pc_work_time_total(self)

Now what should I do to see total time consumed by frame_equalizer and
where do I expect the output.
~~~

./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"mac_sptr_pc_work_time_total", _wrap_mac_sptr_pc_work_time_total,
METH_VARARGS, (char *)"mac_sptr_pc_work_time_total(mac_sptr self) ->
float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"mapper_sptr_pc_work_time_total", _wrap_mapper_sptr_pc_work_time_total,
METH_VARARGS, (char *)"mapper_sptr_pc_work_time_total(mapper_sptr self) ->
float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"moving_average_cc_sptr_pc_work_time_total",
_wrap_moving_average_cc_sptr_pc_work_time_total, METH_VARARGS, (char
*)"moving_average_cc_sptr_pc_work_time_total(moving_average_cc_sptr self)
-> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"moving_average_ff_sptr_pc_work_time_total",
_wrap_moving_average_ff_sptr_pc_work_time_total, METH_VARARGS, (char
*)"moving_average_ff_sptr_pc_work_time_total(moving_average_ff_sptr self)
-> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"parse_mac_sptr_pc_work_time_total",
_wrap_parse_mac_sptr_pc_work_time_total, METH_VARARGS, (char
*)"parse_mac_sptr_pc_work_time_total(parse_mac_sptr self) -> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"sync_long_sptr_pc_work_time_total",
_wrap_sync_long_sptr_pc_work_time_total, METH_VARARGS, (char
*)"sync_long_sptr_pc_work_time_total(sync_long_sptr self) -> float"},
./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
*)"sync_short_sptr_pc_work_time_total",
_wrap_sync_short_sptr_pc_work_time_total, METH_VARARGS, (char
*)"sync_short_sptr_pc_work_time_total(sync_short_sptr self) -> float"},




On 11 July 2017 at 13:17, Marcus Müller  wrote:

> Hi Sumit,
>
> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
>
> exactly, only GNU Radio needs to be built with that flag – functionally,
> it's something that is done in the scheduler, not in the blocks the
> scheduler runs.
>
> Best regards,
>
> Marcus
>
> On 07/11/2017 12:59 PM, sumit kumar wrote:
>
> Hi,
>
> I have to do timing analysis of individual blocks of gr-ieee80211
> I have built my gnuradio with the following
>
> ~/rfnoc/src/gnuradio/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> build was successful.
>
> And again I built gr-ieee80211 with following
>
> ~/rfnoc/src/gr-ieee-80211/build$ cmake -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc
> -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_PERFORMANCE_COUNTERS=On
> -Werror ../
>
> However I get a warning that
> *CMake Warning:*
> *  Manually-specified variables were not used by the project:*
>
> *ENABLE_PERFORMANCE_COUNTERS*
>
> In order to do timing analysis of individual blocks of gr-ieee80211, I am
> following the documentation at
> https://gnuradio.org/doc/doxygen/page_perf_counters.html
>
> Does only GNU Radio need to be built with the  flag
> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
>
> 
> 
> ~~
> john@john-Precision-5510:~/rfnoc/src/gr-ieee-80211/build$ cmake
> -DCMAKE_INSTALL_PREFIX=/home/john/rfnoc -DCMAKE_BUILD_TYPE=RelWithDebInfo
> -DENABLE_PERFORMANCE_COUNTERS=On -Werror ../
> -- Boost version: 1.58.0
> -- Found the following Boost libraries:
> --   filesystem
> --   system
> Checking for GNU Radio Module: RUNTIME
>  * INCLUDES=/home/john/rfnoc/include
>  * LIBS=/home/john/rfnoc/lib/libgnuradio-runtime.so;/home/john/
> rfnoc/lib/libgnuradio-pmt.so
> GNURADIO_RUNTIME_FOUND = TRUE
> Checking for GNU Radio Module: DIGITAL
>  * INCLUDES=/home/john/rfnoc/include
>  * LIBS=/home/john/rfnoc/lib/libgnuradio-d

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[Marcus Müller]

So, the performance counters need to be enabled in your GNU Radio
preferences; I don't think editing the configuration input template
helps, unless you build & reinstall (don't do that). Instead, run
`gnuradio-config-info --prefs` first and check whether PerfCounters are
enabled.

To query these counters, you can

  * use the gr::block::pc_bla_foo() methods of every block, or
  * use ControlPort at run time, for example using the
gr-ctrlport-monitor, which you can add to a flowgraph elegantly from
GRC. This, however, requires both an enabled controlport in CMake as
well as a working and found Thrift installation at CMake time –
check whether the CMake output contain

-- Configuring gr-ctrlport support...
--   Dependency Boost_FOUND = 1
--   Dependency SWIG_FOUND = TRUE
--   Dependency SWIG_VERSION_CHECK = TRUE
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
*--   Enabling gr-ctrlport support.*
--   Override with -DENABLE_GR_CTRLPORT=ON/OFF

AND, directly below

-- Checking for module 'thrift'
--  Found thrift, version XX.XX.XX

AND, below

-- Python checking for Thrift - found

AND, below

-- Found THRIFT: /usr/lib64/libthrift.so
-- Found and enabling Thrift backend to ControlPort


On 07/11/2017 03:11 PM, sumit kumar wrote:
> Ok I understood. Now I have a following question. 
>
> I did a grep in the build directory 
>
> grep -r 'work_time_total' .
>
> And I found that indeed its there as said
> on https://gnuradio.org/doc/doxygen/page_perf_counters.html
> 
> It  seems a lot of task is already been done ! :) 
>
> Then I opened gnuradio-runtime.conf.in
>  and did the following (as mentioned
> in the documentation)
>  
> [PerfCounters]
> on = True
> export = True
> #clock = thread
> clock = monotonic
>
> Now I run my application , for example wifi_rx.py
>
> Where do I see the timings ? 
>
> I opened the ieee802_11_swig.py, and I see def
> pc_work_time_total(self) is there for all the blocks, but how to use
> them :-/ 
>
> Can you give a use case, for example : 
>
> In line 1953 of ieee802_11_swig.py, we have 
>
> class frame_equalizer_sptr(object):
>
> and inside this calss we have the function :
>
> def pc_work_time_total(self):
> """pc_work_time_total(frame_equalizer_sptr self) -> float"""
> return
> _ieee802_11_swig.frame_equalizer_sptr_pc_work_time_total(self)
>
> Now what should I do to see total time consumed by frame_equalizer and
> where do I expect the output. 
> ~~~
>  
>
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"mac_sptr_pc_work_time_total", _wrap_mac_sptr_pc_work_time_total,
> METH_VARARGS, (char *)"mac_sptr_pc_work_time_total(mac_sptr self) ->
> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"mapper_sptr_pc_work_time_total",
> _wrap_mapper_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"mapper_sptr_pc_work_time_total(mapper_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"moving_average_cc_sptr_pc_work_time_total",
> _wrap_moving_average_cc_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_cc_sptr_pc_work_time_total(moving_average_cc_sptr
> self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"moving_average_ff_sptr_pc_work_time_total",
> _wrap_moving_average_ff_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_ff_sptr_pc_work_time_total(moving_average_ff_sptr
> self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"parse_mac_sptr_pc_work_time_total",
> _wrap_parse_mac_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"parse_mac_sptr_pc_work_time_total(parse_mac_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"sync_long_sptr_pc_work_time_total",
> _wrap_sync_long_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"sync_long_sptr_pc_work_time_total(sync_long_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx:{ (char
> *)"sync_short_sptr_pc_work_time_total",
> _wrap_sync_short_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"sync_short_sptr_pc_work_time_total(sync_short_sptr self) -> float"},
>
>
>
>
> On 11 July 2017 at 13:17, Marcus Müller  > wrote:
>
> Hi Sumit,
>
>> Does only GNU Radio need to be built with the  flag
>> -DENABLE_PERFORMANCE_COUNTERS or the OOT projects too ?
> exactly, only GNU Radio needs to be built with that flag –
> functionally, it's something that is done in the scheduler, not in
> the blocks the scheduler runs.
>
> Best regards,
>
> Marcus
>
>
> On 07/11/2017 12:59 PM, sumit kumar wrote:
>> Hi, 
>>
>> I have to do timing analysis of individual blocks of gr-ieee80211
>> I have built my gnuradio with the following 
>>
>> ~/rfnoc/src/gnuradio/build$ cmake
>> -DCMAKE_INSTA

[Discuss-gnuradio] gr-scan giving false alarms

[GNUBeginner]

Hello Everyone,

Could anyone please tell me why gr-scan gives three different frequency
finding results (2410 MHz, 2412 MHz, 2414 MHz) when I inject only 2412 MHz
signal with -30 dBm power level?

Thanks



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/gr-scan-giving-false-alarms-tp64519.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Daemonizing a flowgraph

[devin kelly]

Hello,

I have a flowgraph that I made with  GRC and modified.  All I want to do
with the flowgraph is make it run as a daemon.  I understand that if there
are overflows or underflows I'll miss them, that's OK.

I added some basic python code to daemonize my flowgraph:


# Fork once
try:
pid = os.fork()
except OSError:
print 'error forking'

if pid > 0:  # if parent, return
return

os.umask(0)

# Reset the session ID
try:
os.setsid()
except OSError:
sys.exit(1)

# Fork twice, giving up ownership of first parent's SID
try:
pid = os.fork()
except OSError:
print 'error forking'

if pid != 0:  # if parent, return
sys.exit(0)

# Change PWD
try:
os.chdir('/')
except OSError:
return

# Close open files
sys.stdin.close()
sys.stdout.close()
sys.stderr.close()

with open('/dev/null', 'r+') as devnull:
sys.stdin = devnull
sys.stdout = devnull
sys.stderr = devnull

tb = top_block_cls(options)
tb.start()
time.sleep(60.0)
tb.stop()
tb.wait()

When I run this, it works at first (I get my prompt back, you can see me
trying to open the file).  But then the UHD hijacks my stdout/stderr and
resumes as if nothing happened.

$ ./flowgraph.py -t
30

linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.005-0-g32951af2

$ vim flowgraph.py -- X300 initialization
sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass

How do I stop the UHD from doing this?

Thanks for any help,
Devin
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Cinaed Simson]

Okay, I definitely see the signals at +- 1kHz.

And I forgot to mention one other problem.

If I look at the raw data in a frequency sink it's almost a straight
line lying on the frequency axis.

I had to adjust the scaling to +-0.05 to see the symbols. Is this to be
expected?

It seems odd that a device with a maximum power 116 dBm would have such
a weak signal.

Maybe the antenna was to close? The distance of the receiving antenna
was roughly 0.1 of the carrier wavelength from transmitting antenna.

Also, the documents indicate the channel width is from 7 kHz to 16 kHz -
the sampling rate of 8 kHz may have been to small.

But in any case, there's a lot of good information in this thread and
it's going to take me a while to digest all of it.

Thanks!



On 07/10/2017 05:55 PM, Andy Walls wrote:
> From: HLL
> Date: Mon, 10 Jul 2017 20:44:01 +0300
>> Hi,
>> Thank you very much!!
>> I Need to thoroughly go over your response and understand it all, but
>> thanks :)
>>
>> I also noticed the 2 different in bit timings, I thought it's
>> something electrically, since I noticed the "long" lows and highs are
>> on some specific timings and the shorts have another timing.
>>
>> Before experimenting with the graph (and the said OOT modules). I'm
>> going over it and trying to understand it,
>> what the rotator does, and what it it's role?
> 
> It performs a (cyclic) frequency shift of the signal spectrum.  It is
> called a rotator because the DFT of a sampled signal "lives" on the
> unit circle of the z-plane.  The rotator block rotates the entire z-
> plane about its origin by a certain number of radians, thus effectively
>  shifting the spectrum of the signal.
> 
> I use the rotator block to shift the audio frequency bins of +350 Hz
> and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I filter
> off what were the negative audio frequency bins, the DC spike from the
> FM CFO, and a lot of the spectrum which is just noise.
> 
>> The part with 2 pll carrier tracking is used for locking the carrier
>> of the low and high freq as I understand (I.E. The cheap digital PWM
>> or clock devider)
> 
> Yes, but they both track *and* downconvert the tracked tone to DC.
> 
> This is a coherent FSK receiver design, which is probably overkill for
> this application, but I used it to handle uncertainty in the actual
> audio tone bins used for the mark and space frequencies.
> 
>> what is the role of the complex conjugates (mirror over the real
>> axis?),
> 
> The complex conjugate is to handle a quirk of the GNURadio PLL block
> before the subtraction.  When the PLL carrier tracking block does it's
> downconversion of the tracked tone to DC, it doesn't have a phase angle
> of 0 degrees (a purely real number), instead it has a phase angle of
> something a bit less than pi/4 radians.
> 
> The complex conjugate is so when I do the following subtract, I will
> get constellation points on opposite sides of the circle in the I-Q
> plane.
> 
> 
>>  subtract,
> 
> This is standard for a coherent FSK demodulator and for certain non-
> coherent FSK demodulators.  Google images should show a number of block
> diagrams doing this.
> 
> 
>>  c-to-f and add part?
> 
> Well, after the subtraction you have I-Q plane constellation points of
> about A*exp(j*pi/4) and A*exp(j*5*pi/4), and a fuzzy trajectory line
> going approximately straight between those points.  I needed to convert
> those to real values.
> 
> I could have taken the complex magnitude and the complex argument and
> somehow tried to assign the proper sign to the complex magnitude, but
> that was work. :)  Since the two constellation points and the
> trajectory is restricted to quadrants I and III of the I-Q plane, it
> was easier to just add combine the real and imaginary parts to get a
> real number. 
> 
> 
>>   Are you "subtracting" the (locked) `0` square wave from the `1`
>> square wave, why?
> 
> No.
> 
> Let's pretend GNURadio's quirky almost pi/4 angle output from the
> downconverted tone is actually 0 radians instead of almost pi/4.
> 
> When the mark PLL is locked on to the mark tone, it will output a value
> of A.  When the space PLL is locked on to a space tone, it will output
> a value of A as well.
> 
> To have a mark symbol represented by A and a space symbol represented
> by -A, we have to invert the output value of the space PLL, hence the
> subtraction.
> 
> Also note, that one should not receive mark and space tones at the same
> time, so when the mark PLL is outputting A, the space PLL is ideally
> outputting 0, and vice-versa.
> 
> 
>> I think I understand most of the rest (the `missing block` from their
>> names :) )
>>
>> Thanks,
>> HLL
>>
>> P.S. FYI, The capture I'v attached contains 4 bursts of 2 devices, 2
>> from device A and 2 from device B.
> 
> Yes, I noticed 4 bursts, two at one energy level and two at another
> energy level.
> 
> Regards,
> Andy
> 
>> P.S.2 It is probably some cheapo electronic components or re-using
>> the m

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[sumit kumar]

Ok, I fixed the apache issue and control port seems to be running on the
example provided in share/gnuradio/examples/ctrlport
polyphase example

However when I drag and dropped ctrlport in wifi_transceiver.grc , I see
the following

ControlPort Monitor running.
gr::log :INFO: controlport - Apache Thrift: -h john-Precision-5510 -p 39251
Omonitor::endpoints() = -h john-Precision-5510 -p 39251
running: ['gr-perf-monitorx', 'john-Precision-5510', '39251']
OConfiguration has not turned on all of the appropriate ControlPort
features:
[ControlPort] on = False
[ControlPort] edges_list = False
[PerfCounters] on = False
[PerfCounters] export = False

Then I manually set all of them to True, as I did last time, but no luck.

Do I have to rebuild everything again ? The documentation says I can change
the behavior at runtime :(


On 11 July 2017 at 16:08, Marcus Müller  wrote:

> So, the performance counters need to be enabled in your GNU Radio
> preferences; I don't think editing the configuration input template helps,
> unless you build & reinstall (don't do that). Instead, run
> `gnuradio-config-info --prefs` first and check whether PerfCounters are
> enabled.
>
> To query these counters, you can
>
>- use the gr::block::pc_bla_foo() methods of every block, or
>- use ControlPort at run time, for example using the
>gr-ctrlport-monitor, which you can add to a flowgraph elegantly from GRC.
>This, however, requires both an enabled controlport in CMake as well as a
>working and found Thrift installation at CMake time – check whether the
>CMake output contain
>
> -- Configuring gr-ctrlport support...
> --   Dependency Boost_FOUND = 1
> --   Dependency SWIG_FOUND = TRUE
> --   Dependency SWIG_VERSION_CHECK = TRUE
> --   Dependency ENABLE_GNURADIO_RUNTIME = ON
> *--   Enabling gr-ctrlport support.*
> --   Override with -DENABLE_GR_CTRLPORT=ON/OFF
>
> AND, directly below
>
> -- Checking for module 'thrift'
> --  Found thrift, version XX.XX.XX
>
> AND, below
>
> -- Python checking for Thrift - found
>
> AND, below
>
> -- Found THRIFT: /usr/lib64/libthrift.so
> -- Found and enabling Thrift backend to ControlPort
>
>
> On 07/11/2017 03:11 PM, sumit kumar wrote:
>
> Ok I understood. Now I have a following question.
>
> I did a grep in the build directory
>
> grep -r 'work_time_total' .
>
> And I found that indeed its there as said on https://gnuradio.org/doc/
> doxygen/page_perf_counters.html
> It  seems a lot of task is already been done ! :)
>
> Then I opened gnuradio-runtime.conf.in and did the following (as
> mentioned in the documentation)
>
> [PerfCounters]
> on = True
> export = True
> #clock = thread
> clock = monotonic
>
> Now I run my application , for example wifi_rx.py
>
> Where do I see the timings ?
>
> I opened the ieee802_11_swig.py, and I see def
> pc_work_time_total(self) is there for all the blocks, but how to use them
> :-/
>
> Can you give a use case, for example :
>
> In line 1953 of ieee802_11_swig.py, we have
>
> class frame_equalizer_sptr(object):
>
> and inside this calss we have the function :
>
> def pc_work_time_total(self):
> """pc_work_time_total(frame_equalizer_sptr self) -> float"""
> return _ieee802_11_swig.frame_equalizer_sptr_pc_work_time_
> total(self)
>
> Now what should I do to see total time consumed by frame_equalizer and
> where do I expect the output.
> 
> 
> ~~~
>
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char 
> *)"mac_sptr_pc_work_time_total",
> _wrap_mac_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"mac_sptr_pc_work_time_total(mac_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"mapper_sptr_pc_work_time_total", _wrap_mapper_sptr_pc_work_time_total,
> METH_VARARGS, (char *)"mapper_sptr_pc_work_time_total(mapper_sptr self)
> -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"moving_average_cc_sptr_pc_work_time_total",
> _wrap_moving_average_cc_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_cc_sptr_pc_work_time_total(moving_average_cc_sptr self)
> -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char
> *)"moving_average_ff_sptr_pc_work_time_total",
> _wrap_moving_average_ff_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"moving_average_ff_sptr_pc_work_time_total(moving_average_ff_sptr self)
> -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char 
> *)"parse_mac_sptr_pc_work_time_total",
> _wrap_parse_mac_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"parse_mac_sptr_pc_work_time_total(parse_mac_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char 
> *)"sync_long_sptr_pc_work_time_total",
> _wrap_sync_long_sptr_pc_work_time_total, METH_VARARGS, (char
> *)"sync_long_sptr_pc_work_time_total(sync_long_sptr self) -> float"},
> ./swig/ieee802_11_swigPYTHON_wrap.cxx: { (char 
> *)"sync_short

Re: [Discuss-gnuradio] Chunks to symbols with 16 QAM modulation

[Cinaed Simson]

On 07/11/2017 05:13 AM, Rafik ZITOUNI wrote:
> Dear gnuradio users, 
> 
> I am trying to use digital_chunks_to_symbols to reconstruct block by
> block my QAM modulator. 
> 
> Please could you give me an idea how to set the constellation points in
> Symbol Table field?  I can do it with BPSK, QPSK and 8PSK using
> constellation[0].points, constellation[1].points and
> constellation[2].points, but how can I do it with 16 QAM ?

Try

 Symbols:digital.qam_16()[1]
 Constellations: digital.qam_16()[0]

-- Cinaed


> 
> For my 16 QAM receiver, could you please tell me if it's possible to
> have a constellation points view? 
> 
> Best, 
> 
> -- 
> **Rafik
> 
> 
> 
> ___
> 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] Decoding 2FSK Compensating for carrier jitter/skewing (CFO)

[Cinaed Simson]

On 07/11/2017 03:56 PM, Cinaed Simson wrote:
Opps.
> 
> If I look at the raw data in a frequency sink it's almost a straight
> line lying on the frequency axis.

I meant time sink

  If I look at the raw data in a TIME sink it's almost a straight
  line lying on the TIME axis.

> 
> I had to adjust the scaling to +-0.05 to see the symbols. Is this to be
> expected?
> 
> It seems odd that a device with a maximum power 116 dBm would have such
> a weak signal.
> 
> Maybe the antenna was to close? The distance of the receiving antenna
> was roughly 0.1 of the carrier wavelength from transmitting antenna.
> 
> Also, the documents indicate the channel width is from 7 kHz to 16 kHz -
> the sampling rate of 8 kHz may have been to small.
> 
> But in any case, there's a lot of good information in this thread and
> it's going to take me a while to digest all of it.
> 
> Thanks!
> 
> 
> 
> On 07/10/2017 05:55 PM, Andy Walls wrote:
>> From:HLL
>> Date:Mon, 10 Jul 2017 20:44:01 +0300
>>> Hi,
>>> Thank you very much!!
>>> I Need to thoroughly go over your response and understand it all, but
>>> thanks :)
>>>
>>> I also noticed the 2 different in bit timings, I thought it's
>>> something electrically, since I noticed the "long" lows and highs are
>>> on some specific timings and the shorts have another timing.
>>>
>>> Before experimenting with the graph (and the said OOT modules). I'm
>>> going over it and trying to understand it,
>>> what the rotator does, and what it it's role?
>>
>> It performs a (cyclic) frequency shift of the signal spectrum.  It is
>> called a rotator because the DFT of a sampled signal "lives" on the
>> unit circle of the z-plane.  The rotator block rotates the entire z-
>> plane about its origin by a certain number of radians, thus effectively
>>  shifting the spectrum of the signal.
>>
>> I use the rotator block to shift the audio frequency bins of +350 Hz
>> and +940 Hz down to -295 Hz and +295 Hz respectively.  Then I filter
>> off what were the negative audio frequency bins, the DC spike from the
>> FM CFO, and a lot of the spectrum which is just noise.
>>
>>> The part with 2 pll carrier tracking is used for locking the carrier
>>> of the low and high freq as I understand (I.E. The cheap digital PWM
>>> or clock devider)
>>
>> Yes, but they both track *and* downconvert the tracked tone to DC.
>>
>> This is a coherent FSK receiver design, which is probably overkill for
>> this application, but I used it to handle uncertainty in the actual
>> audio tone bins used for the mark and space frequencies.
>>
>>> what is the role of the complex conjugates (mirror over the real
>>> axis?),
>>
>> The complex conjugate is to handle a quirk of the GNURadio PLL block
>> before the subtraction.  When the PLL carrier tracking block does it's
>> downconversion of the tracked tone to DC, it doesn't have a phase angle
>> of 0 degrees (a purely real number), instead it has a phase angle of
>> something a bit less than pi/4 radians.
>>
>> The complex conjugate is so when I do the following subtract, I will
>> get constellation points on opposite sides of the circle in the I-Q
>> plane.
>>
>>
>>>  subtract,
>>
>> This is standard for a coherent FSK demodulator and for certain non-
>> coherent FSK demodulators.  Google images should show a number of block
>> diagrams doing this.
>>
>>
>>>  c-to-f and add part?
>>
>> Well, after the subtraction you have I-Q plane constellation points of
>> about A*exp(j*pi/4) and A*exp(j*5*pi/4), and a fuzzy trajectory line
>> going approximately straight between those points.  I needed to convert
>> those to real values.
>>
>> I could have taken the complex magnitude and the complex argument and
>> somehow tried to assign the proper sign to the complex magnitude, but
>> that was work. :)  Since the two constellation points and the
>> trajectory is restricted to quadrants I and III of the I-Q plane, it
>> was easier to just add combine the real and imaginary parts to get a
>> real number. 
>>
>>
>>>   Are you "subtracting" the (locked) `0` square wave from the `1`
>>> square wave, why?
>>
>> No.
>>
>> Let's pretend GNURadio's quirky almost pi/4 angle output from the
>> downconverted tone is actually 0 radians instead of almost pi/4.
>>
>> When the mark PLL is locked on to the mark tone, it will output a value
>> of A.  When the space PLL is locked on to a space tone, it will output
>> a value of A as well.
>>
>> To have a mark symbol represented by A and a space symbol represented
>> by -A, we have to invert the output value of the space PLL, hence the
>> subtraction.
>>
>> Also note, that one should not receive mark and space tones at the same
>> time, so when the mark PLL is outputting A, the space PLL is ideally
>> outputting 0, and vice-versa.
>>
>>
>>> I think I understand most of the rest (the `missing block` from their
>>> names :) )
>>>
>>> Thanks,
>>> HLL
>>>
>>> P.S. FYI, The capture I'v attached contains 4 bursts of 2 devices, 2
>>> from device A and 2 from 

[Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

[sumit kumar]

Hello,

I was trying to understand gr-ieee 802.11 wifi_transceiver.grc
I see the youtube video
https://www.youtube.com/watch?v=tAVgsJLM-sc

I believe a single gr-ieee 802.11 wifi_transceiver.grc is running on a
laptop with usrp and communicating with a WiFi card (ath5k driver) of
another laptop
<*I hope my understanding is correct*>

I visited the git page and it looks to me like "*Ad Hoc Network with WiFi
card*" as the author has mentioned.

How do I replicate this experiment. If someone has replicated the stuff
shown in video, pl let me know :)

Regards

Sumit


* It reminds me of tunnel application which I ran on GNU Radio long back
(2012 I guess). There was an application tunnel.py
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] cmake warning with -DENABLE_PERFORMANCE_COUNTERS-On (gr-ieee80211)

[Bastian Bloessl]

Hi,

On 07/12/2017 01:19 AM, sumit kumar wrote:
However when I drag and dropped ctrlport in wifi_transceiver.grc , I see 
the following


ControlPort Monitor running.
gr::log :INFO: controlport - Apache Thrift: -h john-Precision-5510 -p 39251
Omonitor::endpoints() = -h john-Precision-5510 -p 39251
running: ['gr-perf-monitorx', 'john-Precision-5510', '39251']
OConfiguration has not turned on all of the appropriate ControlPort 
features:

 [ControlPort] on = False
 [ControlPort] edges_list = False
 [PerfCounters] on = False
 [PerfCounters] export = False

Then I manually set all of them to True, as I did last time, but no luck.


What do you mean with no luck? If it was the same output, you might have 
edited the wrong file. (The output above says you should turn on 
performance counters in your config. Your build is probably fine, i.e., 
it doesn't ask you to recompile. Just switch them on in your config.)


See here for how to enable ControlPort. Performance counters are enabled 
similarly.


https://gnuradio.org/doc/doxygen/page_ctrlport.html



Do I have to rebuild everything again ? The documentation says I can 
change the behavior at runtime :(


You can change these values without recompiling. If it didn't work, you 
might have adapted the wrong configuration file.


Best,
Bastian



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

Re: [Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

[Bastian Bloessl]

Hi,

On 07/12/2017 01:37 AM, sumit kumar wrote:

Hello,

I was trying to understand gr-ieee 802.11 wifi_transceiver.grc
I see the youtube video
https://www.youtube.com/watch?v=tAVgsJLM-sc

I believe a single gr-ieee 802.11 wifi_transceiver.grc is running on a 
laptop with usrp and communicating with a WiFi card (ath5k driver) of 
another laptop

<*I hope my understanding is correct*>


Yes, that's right.



I visited the git page and it looks to me like "*Ad Hoc Network with 
WiFi card*" as the author has mentioned >
How do I replicate this experiment. If someone has replicated the stuff 
shown in video, pl let me know :)


The configuration that I used for the GNU Radio transceiver can be found 
in the apps/nic.sh script.


It's not totally trivial to setup, you should have a rough idea about 
networking, MAC addresses, and ARP. Because on the other laptop you have 
to open an ad hoc network, add corresponding static ARP entries for the 
MAC configured for the GNU Radio transceiver, and set an IP in the same 
subnet as the GNU Radio transceivers TUN/TAP interface.


Best,
Bastian




Regards

Sumit


* It reminds me of tunnel application which I ran on GNU Radio long back 
(2012 I guess). There was an application tunnel.py



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



--
Dipl.-Inform. Bastian Bloessl
CONNECT Center
Trinity College Dublin

GitHub/Twitter: @bastibl
https://www.bastibl.net/

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

Re: [Discuss-gnuradio] SSH using gr-ieee 802.11 transceiver : (the youtube demo)

[sumit kumar]

On 12 July 2017 at 07:51, Bastian Bloessl  wrote:

> Hi,
>
> On 07/12/2017 01:37 AM, sumit kumar wrote:
>
>> Hello,
>>
>> I was trying to understand gr-ieee 802.11 wifi_transceiver.grc
>> I see the youtube video
>> https://www.youtube.com/watch?v=tAVgsJLM-sc
>>
>> I believe a single gr-ieee 802.11 wifi_transceiver.grc is running on a
>> laptop with usrp and communicating with a WiFi card (ath5k driver) of
>> another laptop
>> <*I hope my understanding is correct*>
>>
>
> Yes, that's right.
>
>
>> I visited the git page and it looks to me like "*Ad Hoc Network with WiFi
>> card*" as the author has mentioned >
>> How do I replicate this experiment. If someone has replicated the stuff
>> shown in video, pl let me know :)
>>
>
> The configuration that I used for the GNU Radio transceiver can be found
> in the apps/nic.sh script.
>
> It's not totally trivial to setup, you should have a rough idea about
> networking, MAC addresses, and ARP. Because on the other laptop you have to
> open an ad hoc network, add corresponding static ARP entries for the MAC
> configured for the GNU Radio transceiver, and set an IP in the same subnet
> as the GNU Radio transceivers TUN/TAP interface.
>
Hi,

Actually I am trying the same set-up :) However I face some issues. Such as
, when I configure my TP Link dongle (ath9k) in ad-hoc mode, it switches to
802.11b, instead of 802.11g. Could you suggest any such dongle where I can
force change the modulation method.
Regarding, ARP entries, I had the idea (couldn't  go ahead becz dongle
switch to 802.11b) : First establish adhoc connection between two
dongles(so that ARP tables are updated). Then copy mac address of one
dongle(say dongle A) to the transmitter of my openairinterface wifi
transceiver, then power off the dongle A and turn on my own cloned
transceiver.

However I was trying to send ACK for the pings generated from dongle B (the
other dongle) before the layer 2 trails are exhausted. I am trying all this
inside a RF cage.

How do you manage to work without sending ACK. Also I believe , you did
that video demo over the air. How did you manage without CSMA :)

>
> Best,
> Bastian
>
>
>
>> Regards
>>
>> Sumit
>>
>>
>> * It reminds me of tunnel application which I ran on GNU Radio long back
>> (2012 I guess). There was an application tunnel.py
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
> --
> Dipl.-Inform. Bastian Bloessl
> CONNECT Center
> Trinity College Dublin
>
> GitHub/Twitter: @bastibl
> https://www.bastibl.net/
>



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