Re: ControlPort error in gr-ieee802-11, wifi-loopback example.

[Bastian Bloessl]

Dear Anton,

On 7/3/21 6:54 PM, Anton Ottosson wrote:
> I see now my silly mistake. I thought the "xx" messages printed
> in the console were due to an error with ControlPort/Thrift, but it
> turns out these were the literal messages being sent by the `Message
> Strobe`. So the combination of the readme saying I should expect "Hello
> World" and me seeing the message about ControlPort and Thrift made me
> assume there was something wrong with the messaging, without actually
> taking the time to inspect the flowgraph a little bit more carefully.

Arg, sorry for the confusion. I updated the readme and removed the
"hello world" reference. At some point, I added a slider to adjust the
frame size and changed the payload from "hello world" to "x" * frame_size.

> 
> So it seems to be working as intended, I think, and I can disable the
> `CtrlPort Performance Monitor` block to get rid of the message about
> ControlPort/Thrift. This still leaves me wondering a couple of things
> though:

Yes, just disabling is fine.

> 
> 
>  1. What is the `CtrlPort Performance Monitor` block for? Is it
> necessary for anything in `gr-ieee802-11`?

GNU Radio comes with CtrlPort, which provides an interface to a
flowgraph that allows to get and set parameters/data, for example, from
an external program.
https://www.gnuradio.org/doc/doxygen/page_ctrlport.html

Performance Counters can be enabled in a GNU Radio flowgraph to record
statistics about queue sizes, CPU time of blocks, and other performance
metrics.

The CtrlPort Performance Monitor starts a GUI that visualizes
performance figures of a flowgraph, polling its performance counters
through the CtrlPort interface.

It is completely irrelevant for the functionality of the flowgraph. Just
disabling the block is fine.

>  2. Why does it not work, since I have Thrift installed?

I don't use PyBombs but AFAIS gnuradio-default installs gnuradio 3.8
without a dependency on thrift. Installing thrift afterwards doesn't
help since gnuradio probably doesn't get recompiled. If you want
CtrlPort, I'd recommend to reinstall gnuradio. It should detect thrift
during the build. If it still doesn't work, check the cmake output to
figure out why the component was not enabled.

Best,
Bastian

> 
> 
> But I will look inte these things myself, so don't waste your time
> writing an answer for me, unless you really want to 
> 
> Regards,
> Anton
> 
> *From:* Anton Ottosson
> *Sent:* Saturday, July 3, 2021 5:47:08 PM
> *To:* discuss-gnuradio@gnu.org
> *Subject:* ControlPort error in gr-ieee802-11, wifi-loopback example.
>  
> 
> Hi,
> 
> 
> I am trying to set up `gr-ieee802-11`
> (https://github.com/bastibl/gr-ieee802-11
> <https://github.com/bastibl/gr-ieee802-11>), `maint-3.8` branch, with
> GNU Radio 3.8. As recommended in the readme I run the
> `wifi_loopback.grc` example flowgraph, expecting to see some decoded
> "Hello World" packets in the console. The flowgraph runs, but the output
> does not show what I expected. The most important part of the output is
> probably the message
> 
> 
> `Failed to to connect to ControlPort. Please make sure that you have
> Thrift installed and check your firewall rules.`
> 
> 
> printed during startup. More details, including console output, can be
> seen
> here: 
> https://github.com/bastibl/gr-ieee802-11/issues/292#issuecomment-873317584
> <https://github.com/bastibl/gr-ieee802-11/issues/292#issuecomment-873317584>
> 
> 
> I must confess that I don't really know what the role of  "ControlPort"
> and Thrift is here, so I'm not sure how to proceed. But this is not what
> the output is supposed to be, right? Has anyone here had the same
> problem, and found a way to get past it?
> 
> 
> My current setup was installed using PyBOMBS, under Ubuntu 20.04.2 LTS.
> To be precise i initialized a PyBOMBS prefix with
> `gr-recipes/gnuradio-default` and then installed
> `gr-recipes/gr-ieee-80211`. After seeing the message above I also
> installed `gr-recipes/apache-thrift`, hoping that this would solve the
> issue, but it did not seem to make any difference.
> 
> 
> Best regards,
> 
> Anton
> 

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: Handshake and Message Passing with gr-ieee802-11

[Bastian Bloessl]

Hi Cameron,

On 6/10/20 8:00 PM, Cameron Matson wrote:
> The buffer seems to be building up in size as I'd expect, and the first
> message goes through, but I get no output from the WiFi Phy block, and
> so the buffer just continues to grow in size without sending out any
> more messages.  Since my block passes the messages through unaltered,
> why wouldn't the PHY block handle the output of my block the same as if
> it weren't there?

I don't see a reason why this shouldn't work. It might just be a bug in
your code. You can add Message Debug blocks to the flowgraph to check
the message flow, e.g., if the block receives the ACK to the first
frame. Or you could forward the output to the ack port without the PHY, etc.

If you have problems to figure out the underlying issue, you could also
upload the code somewhere.

Best,
Bastian

Re: GNU Radio on Android

[Bastian Bloessl]

Hi,

I was just about to ask if someone would be willing to test the Android
toolchain I was working on. I pushed it to GitHub some hours ago and am
looking for someone to test it :-)

https://github.com/bastibl/gnuradio-android

Its a git repo with many submodules and a Dockerfile that installs
Android Studio, the SDKs, and cross-compiles the GNU Radio toolchain
including several OOTs. There are also sample applications, e.g., an FM
receiver:

https://www.youtube.com/watch?v=8ReyVzUyppA

If you're on Slack, I can guide you through the build and write the
readme in parallel. If not, I hope to have a first version of the
documentation ready on the weekend.

Best,
Bastian



On 4/23/20 8:59 PM, jean-michel.fri...@femto-st.fr wrote:
> Since I have little else to do at the moment than playing with my phone,
> I debugged the USB OTG port of my Sony Z5, which led me to install the
> rtl-sdr driver, which led me to install some non-GNU Radio application
> to test the SDR capability of the phone, and it works. I haven't learnt
> anything in the process.
> 
> I do have Tom's detailed description on compiling GNU Radio but I am afraid
> the 2017 flowchart for 3.7 is no longer valid, and I have Bastian's video 
> showing off GNU Radio 3.8 on android which also does not teach me much other
> than making me envious.
> 
> Is there some documentation on getting started, considering I have absolutely
> no clue on how to cross compile to Android ?
> 
> Thanks, JM
> 
> --
> JM Friedt, FEMTO-ST Time & Frequency/SENSeOR, 26 rue de l'Epitaphe,
> 25000 Besancon, France
> 

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: gr-rds modules documentation

[Bastian Bloessl]

There are examples in the examples directory that demonstrate how
everything can be put together.

https://github.com/bastibl/gr-rds/tree/maint-3.8/examples

I'm not sure if or where they are installed on the packaged version.
They show a complete FM receiver w/ RDS and a custom GUI.

https://www.youtube.com/watch?v=05i9C5lhorY

Best,
Bastian



On 4/6/20 3:50 AM, David Hagood wrote:
> I'm trying to find any documentation on the gr-rds modules -
> specifically, what do they expect to be fed with? It doesn't look like
> they accept IF, nor demodulated FM - it looks like they expect some
> other block between them and the FM discriminator. I've not found any
> docs on the WIKI, nor anything online that describes them.
> 
> This is what is shipped in the Ubuntu 20.04 release, in case that matters.
> 
> 
> 

Re: Proposal for GSoC

[Bastian Bloessl]

Dear Prashant,

welcome to the list! I'm glad, you're interested in the project.

The proposal already looks quite nicely and your experience suggests,
you'd be a good fit for the project.

Regarding the scope, it's actually broader than I would have expected
:-) In GNU Radio, you have for example gr-qtgui, which provides a set of
GUI visuals and controls for flowgraphs. The initial idea was to have
something similar for Android (ideally also with support for gestures, etc).

As far as I see, your proposal covers these widgets and, in addition, a
port of GRC to Android. While this would be nice to have, it also seems
very ambitious. (And a second GRC might be hard to maintain.)

I think it might make sense to focus on the GUI widgets (and do them
properly with multiple inputs, triggers, gestures, configurable line
styles, etc.). Implementing "only" these widgets and an example app that
demonstrates their use is already quite some work.

Would you have an Android phone, OTG adapter, and USB-based SDR that you
could use for the project?

I hope we can get some more thoughts on the scope of the project.

Best,
Bastian


On 3/17/20 3:11 AM, PRASHANT KUMAR wrote:
> Hello Community,
> 
> This is Prashant Kumar from IIT Bhilai (Electrical Engineering and
> Computer Science, undergraduate 3rd year). I would like to work for GNU
> Radio this summer (GSoC 2020). I am interested in the project named
> "Android": https://wiki.gnuradio.org/index.php/GSoCIdeas#Android
> <https://slack-redir.net/link?url=https%3A%2F%2Fwiki.gnuradio.org%2Findex.php%2FGSoCIdeas%23Android>.
> 
> 
> I have created some sample UIs for this project. Please have a look at
> my proposal (
> https://docs.google.com/document/d/1S_e2US6aT80H3twCDQ210hDYHW0jWJG91DwhTA22nFY/edit?usp=sharing
> ). Looking for constructive feedback and suggestions regarding this project.
> 
> Yours Sincerely,
> Prashant Kumar

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: Zigbee transceiver

[Bastian Bloessl]

Dear Sampath,

I already replied yesterday. Maybe you didn't get the email:

Dear Ranganathan,

the two connections to the Wireshark block are for (1) the packets that
are generated locally and (2) the packets that are received. It is the
same kind of data, i.e., the bytes that are about to be send out/the
bytes that were demodulated.

If you disconnect "rxout" from the PHY, you won't see the packets that
were received.
If you disconnect "pdu out" from the MAC, you won't see the packets that
are generated locally.

So what you describe sounds like you don't receive packets. Do you do
this over the air?

Best,
Bastian

On 3/5/20 5:04 PM, sampath ranga wrote:
> Hello GNU Radio World,
> 
>    If someone has worked in Mr. Basti's code, can anyone help me in
> explaining , what is the role of connection from PHY Layer to wireshark.
> Because I can get the working of MAC to wireshark but i cant get the
> work that happens from PHY to wireshark cause i am not seeing any
> changes even if i disconnect it.
> 
> Regards,
> Sampath

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: Wire shark output question

[Bastian Bloessl]

Dear Ranganathan,

the two connections to the Wireshark block are for (1) the packets that
are generated locally and (2) the packets that are received. It is the
same kind of data, i.e., the bytes that are about to be send out/the
bytes that were demodulated.

If you disconnect "rxout" from the PHY, you won't see the packets that
were received.
If you disconnect "pdu out" from the MAC, you won't see the packets that
are generated locally.

So what you describe sounds like you don't receive packets. Do you do
this over the air?

Best,
Bastian

On 3/3/20 11:05 PM, sampath ranga wrote:
> Dear all,
> 
>    I am currently working on IEEE802.15.4 protocol with GNU Radio and
> different SDR. I am using Dr. Basti's code for testing. Its successful.
> But i am having few questions to ask. I see two connections to Wireshark
> from PHY layer "rxout" pin and also from pdu out of MAC layer. When i
> disable PHY Layer wire that goes to wireshark, i am still receiving the
> packets in wireshark like usual. But if i disable pdu out to wireshark
> wire , i am not receiving the packets. pdu output pin is from app in
> from Rime. So the output going from the pdu out to wireshark is before
> modulation ?isn't it? or is the packet from pdu out to wireshark is
> after modulation and demodulation from pdu in? why is the packets still
> receiving on wireshark if i disable the wire that runs from rxout of PHY
> Layer to wireshark. Please let me know if i need to ask the question in
> more clear way. Looking forward for someone's help to clear this doubt
> 
> Thanks and regards,
> Ranganathan Sampathkumar

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

www.bastibl.net
GitHub/Twitter: @bastibl

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

[Bastian Bloessl]

Hi,

you're right, the RIME stack is a network stack. But it is completely
optional. You can just disable the block if you don't need it. It was
just convenient to setup connections with Contiki running on a TelosB node.

If you use something different than Contiki (i.e., a node w/o RIME)
frames will not pop out of the RIME ports. But you will see all frames
that are received by the SDR in the Wireshark trace. It logs everything
that is received, independent from PAN ID, etc.

If you use other nodes, as Marcus said:
- check that they use the same PHY (O-QPSK in 2.4GHz)
- check that they use the same channel
- To RX with a custom node: implement a firmware that shows all frames
(independent from MAC, PAN ID, etc.)
- To RX frames w/ GNU Radio, you don't have to do anything special as
every received frame will show up in GR.

Some nodes with PCB antennas are not that great. If you have problems
receiving them with GR, try to (1) increase TX gain, (2) get it closer
to the SDR, (3) increase RX gain of the SDR.

Hope it helps,
Basti

On 2/15/20 9:51 PM, sampath ranga wrote:
> Hello Marcus Muller , 
> 
>    Thank you so much for the reply . The thing about Rime Stack is rime
> stack is a network level stack . So my question is if its network level
> stack is that the block thats restricting me from getting other hardware
> signals on the Wireshark ?? and I want to let you know that i am trying
> different type of flow graph changes to make it work and i am posting
> this after playing with MAC and Rime . I even tried to seperate the tx
> and rx section to see if it is working but still it is not . 
>  
> 
> Thanks and regards ,
> Ranganathan Sampathkumar 
> 
> On Sat, Feb 15, 2020 at 2:39 PM Marcus Müller  <mailto:muel...@kit.edu>> wrote:
> 
> Hi,
> 
> slightly will have to repeat myself:
> 
> On 15.02.20 21:15, sampath ranga wrote:
> > Hello Everyone,
> >
> >     1. I was trying for the past few weeks to make the Zigbee Trx
> > communicate with the other Zigbee hardware for implementation
> > verification . I am not using TelOS b mote with COntiki Firmware
> > instead i am using a Zigbee dongle as a hardware to make the
> > communication work . My question is why is the flowgraph restricting
> > only to hear the "hello world" message but not the message from other
> > hardware? If my SDR could operate at 2.4GHz in air , the transceiver
> > block should not only hear the "GNU Radio Transmitted message but also
> > from the other hardware isnt it? The other hardware is also not
> > receiving the GNU Radio's message.
> 
> This is wireless communications. Not only do you have to configure all
> devices in a compatible manner, channel and receiver conditions can make
> interoperation problematic.
> 
> You will have to apply your own signal processing / wireless education
> to debug this.
> 
> >   2. Is the Rime stack / MAC layer that fixes frames stopping the
> > other hardware to send or receive?
> 
> 
> I don't understand this question, sorry.
> 
> >   3. I am also trying the same Zigbee Trx in 2 laptops, the message
> > that i set in laptop 1 at GNU Radio Zigbee TRX has been received in
> > wireshark at laptop 1 and laptop 2 message at laptop 2 , Why are not
> > they syncing with each other if i give same destination or pan id with
> > channel number?
> 
> Same answer as to 1. You're not doing any signal-level debugging on
> this, so we can't help you.
> 
> > Technically i am trying to do 2 work , Either have two laptop that has
> > each flowgraph with 2 different message and wanna see if they both are
> > transferring their message at wireshark, which is right now not
> happening
> Same answer as to 1.
> > secondly , trying to transmit Zigbee Trx basti's message to a seperate
> > zigbee hardware (Xbee or any zigbee sniffer) or send message from Xbee
> > and trying to receiving in on Wireshark at the GNU Radio end
> 
>     Same answer as to 1.
> 
> > I also face the issue of when i transceive the message its showing
> > "Bad FCS"  and also the packet flow is getting stopped when i open the
> > wireshark . Please throw some ideas on this . 
> >
> Same answer as to 1.
> 

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: [Discuss-gnuradio] buffer allocation failing with RuntimeError: bad_alloc

[Bastian Bloessl]

AFAIS, there are two parameters for shared memory: shmmax and shmall.
The first sets the maximum size for a single segment, the latter the
total available shared memory (in number of pages).

You could try to increase shmall as well.

Best,
Bastian

On 11/21/19 11:58 AM, Eamon Heaney wrote:
> Yeah, I tried changing the maximum shared memory, but that didn't work.
> I mean, it didn't resolve the problem; I gave it 2147483648 but the
> error persists. I tried adding a zero to that, but that's an "Invalid
> Argument."
> 
> On Thu, Nov 21, 2019 at 5:17 AM Ron Economos  <mailto:w...@comcast.net>> wrote:
> 
> You must be running an older kernel that doesn't set kernel.shmmax
> to some large value.
> 
> To check the current setting:
> 
> sysctl kernel.shmmax
> 
> To set it higher:
> 
> sudo -w kernel.shmmax=2147483648
> 
> Ron
> 
> On 11/21/19 01:59, Eamon Heaney wrote:
>> I'm running the sample wifi_tx.grc flowchart from gr-ieee802.11,
>> substituting a null sink for the USRP sink to test it.
>>
>> When I try to run it, it fails with the following error message:
>> "
>> >set_min_output_buffer on block 7 to 207744
>> >set_min_output_buffer on block 9 to 2077440
>> >set_min_output_buffer on block 11 to 2077440
>> >set_min_output_buffer on block 12 to 207744
>> >set_min_output_buffer on block 13 to 415488
>> >set_min_output_buffer on block 14 to 207744
>> >set_min_output_buffer on block 26 to 262144
>> >set_min_output_buffer on block 27 to 96000
>> >set_min_output_buffer on block 31 to 10
>> >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> >gr::buffer::allocate_buffer: failed to allocate buffer of size
>> 1038720 KB
>> >gr::vmcircbuf_mmap_shm_open: mmap (1): Cannot allocate memory
>> >gr::buffer::allocate_buffer: failed to allocate buffer of size
>> 1038720 KB
>> >Traceback (most recent call last):
>> >  File "/home/vtti/working/wifi_tx.py", line 297, in 
>> >    main()
>> >  File "/home/vtti/working/wifi_tx.py", line 276, in main
>> >    tb.start()
>> >  File
>> "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/top_block.py",
>> line 111, >in start
>> >    top_block_start_unlocked(self._impl, max_noutput_items)
>> >  File
>> "/usr/local/lib/python3.6/dist-packages/gnuradio/gr/runtime_swig.py",
>> line >5828, in top_block_start_unlocked
>> >    return _runtime_swig.top_block_start_unlocked(r,
>> max_noutput_items)
>> >RuntimeError: std::bad_alloc
>> "
>> Here's a picture of my flowchart:
>> gnuradio-runtimeError-bad_alloc.png
>>
>> Tested this on a different machine, and it works fine, so the
>> problem isn't with the flowchart itself. I'm working off the
>> maint-3.8 branch, installed from source.
>>
>> Any idea why I'm getting this error, or how I could resolve it?
>> Thanks!
>> -- 
>> Eamon Heaney
>> /
>> /Fleet Commander/
>> //
>> /President, Model UN at Virginia Tech/
>> /
> 
> 
> 
> -- 
> Eamon Heaney
> /
> /Fleet Commander/
> //
> /President, Model UN at Virginia Tech/
> /

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: [Discuss-gnuradio] Transmitting 802.11 packets with the HackRF w/out burst transmissions

[Bastian Bloessl]

Hi,

you're right that there is no burst mode like with the UHD blocks. But
that doesn't mean that it won't work.

With UHD (in tagged stream mode) you first load all samples of a burst
in the input buffer and then stream to the device. That makes
interruptions due to scheduling (and therefore frame corruption) less
likely.

With the HackRF, you just stream samples to the device and it will send
them out without any explicit indicators where the burst starts and
ends. If you stream samples fast enough without interruptions during a
frame, it should work.

Did you try the 3.8 version of the module? If there are problems, you
can share the flowgraph and I'll give it a try.

Best,
Bastian



On 11/6/19 7:55 AM, Eamon Heaney wrote:
> Thanks for the tip, looks like I've got some work ahead of me.
> Appreciate it.
> 
> On Wed, Nov 6, 2019 at 1:28 AM Alexander W  <mailto:alexander.e.wag...@gmail.com>> wrote:
> 
> Hey, 
> I was running into the same problem by running the 802.15.4
> flowcharts with a Pluto SDR. To enable burst transmission I wrote a
> block that pads zeros to the end of a tagged stream to fill the
> buffer of the SDR. 
> 
> The block is added to bastibl's gr-foo OOT module. The Block is
> called "pad tagged stream". To use it you need to set the buffer
> size to the buffer size of the HackRF. 
> 
> Regards, 
> Alex
> 
> 
> 
> Eamon Heaney mailto:hean...@vt.edu>> schrieb am
> Mi., 6. Nov. 2019, 07:10:
> 
> Hi,
> 
> Been working on this Gnuradio/HackRF wifi transmitter for a
> while now, and recently learned that the HackRF driver doesn't
> support burst transmission. I've been working off the wifi_tx
> example
> 
> <https://github.com/bastibl/gr-ieee802-11/blob/maint-3.8/examples/wifi_tx.grc>
> from bastibl's gr-ieee802-11 repo so far, but it looks like I'll
> need another approach.
> 
> Is there another method that could transmit 802.11 packets that
> would work with the HackRF?
> 
> Thanks!
> 
> 
> 
> -- 
> Eamon Heaney
> /
> /Fleet Commander/
> //
> /President, Model UN at Virginia Tech
> /
> /
> 
> 
> 
> -- 
> Eamon Heaney
> /
> /Fleet Commander/
> //
> /President, Model UN at Virginia Tech/
> /

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

www.bastibl.net
GitHub/Twitter: @bastibl

Re: Subject Line Prefix Missing

[Bastian Bloessl]

Hi,

FWIW, I filter mailing lists based on the List-Id field, which still
works fine.

Just found out that this seems to be a thing :-)
https://www.ietf.org/rfc/rfc2919.txt

Best,
Bastian

On 10/30/19 3:21 PM, Johannes Demel wrote:
> Hi all,
> 
> I was wondering about that mailing list behavior as well.
> 
> My solution
> 1. If "Mail From 'discuss-gnuradio@gnu.org'"
> 2. If "Mail To 'discuss-gnuradio@gnu.org'"
> In my case: move to folder.
> 1. covers original mails
> 2. covers replies.
> 
> I had to split this into 2 separate rules but that's due to my email 
> service provider.
> This solution is more verbose about who receives such an email. e.g. 
> off-list replies should not end up to be caught by these rules.
> 
> Anyways, I just wanted to share my 2 cents on that. Maybe someone finds 
> this info useful.
> 
> Cheers
> Johannes
> 
> 
> 
> On 30.10.19 15:11, Müller, Marcus (CEL) wrote:
>> Hi Ed,
>>
>> "deliberate" would be wrong. Surprising, not really, if we'd have read
>> the info mails from the gnu.org mailing list admin more carefully:
>>
>> In the process of respecting DMARC in the ML infrastructure, they
>> disabled rewriting of the subject line for outgoing mail servers that
>> signal strict DMARC compliance. The mailing list seems to think your
>> server does (I don't know why, to be honest, can't seem to find those
>> DNS entries).
>>
>> So, for now, my understanding is that there's nothing *we* can do about
>> it. (We should be able to change the settings of the ML; but in which
>> range, and what we'd break on the way, isn't quite clear to us at this
>> point.)
>>
>> For some reason, my university mail server seems to sort these mails
>> correctly, and so do GMail instances. Probably a list header?
>>
>> Best regards,
>> Marcus
>>
>> On Wed, 2019-10-30 at 09:17 -0400, Ed Criscuolo wrote:
>>> I've noticed that recent postings to the list are missing
>>> the "[Discuss-gnuradio] prefix that was automatically
>>> added to the subject line.
>>>
>>> Was this  a deliberate change? I hope not, as I find that
>>> feature very useful in picking out the list messages
>>> from amid all the spam.
>>>
>>>
>>> @(^.^)@  Ed
>>>

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

www.bastibl.net
GitHub/Twitter: @bastibl

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

[Bastian Bloessl]

Hi,

great you got it working. AFAIK, there is not *the* XBee module, but
very different modules are sold as XBee. Some of them support standard
compliant IEEE 802.15.4/ZigBee (O-QPSK in 2.4GHz). They will work with
the OOT.

Best,
Bastian

On 8/31/19 8:29 PM, Tellrell White wrote:
> Thanks Bastian
> I was able to get it to work by adjusting the tuning frequency and the
> gain. I do have an additional question for you. Can the platform be used
> to communicate with XBee modules? For example, if I create a message
> using the message strobe in the flow graph would I be able to see this
> message using an XBee module?
> 
> Tellrell 
> 
> On Thu, Aug 15, 2019 at 5:16 AM Bastian Bloessl  <mailto:m...@bastibl.net>> wrote:
> 
> 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 <mailto: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 <http://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] How to define maximum number of samples in in Sync_Short used in IEEE802.11

[Bastian Bloessl]

Hi,

the sync short blocks doesn't know how long the frame is. It just
recognized that there is one. Since it doesn't know the length, it
forwards samples corresponding to a "large" frame into the flow graph.
If the frame is shorter, needless samples are dropped at a later stage.

IIRC, the actual maximum frame size allowed by the standard is above
2000 byte. I set max samples so that a 1500 byte BPSK1/2 frame can still
be decoded, i.e., such a frame should have around 540 OFDM symbols with
80 samples each.

Best,
Bastian

On 8/22/19 9:08 AM, SG wrote:
> Hi,
> 
> I have been trying to run WiFi receiver on my SDR using GNURadio based
> approach developed by Bastian in gr-ieee802-11.  However, I am not able
> to figure out the reason behind definition of Max_Samples=540*80 in
> sync_short.cc file.
> 
> Could anyone help clarifying this to me.
> 
> Thanks and Regards
> 
> SG
> 
> 
> ___
> 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] 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] Problem GNU RADIO WIFI tranceiver

[Bastian Bloessl]

Hi,

Regarding sudo: You use a flowgraph with a TUN/TAP interface. If it
doesn't already exists, GNU Radio tries to create it, which requires
root privileges. I'd recommend to just create the interface before
starting GNU Radio. See the rx_demo.sh script in the apps folder to see
how this can be done.

Regarding the setup: It looks like you are trying to start with the most
complex setup (TUN/TAP, networking, etc.) There are also wifi_{rx,tx}
examples. Try to run them on different PCs with antennas and make sure
they work.

Regarding 'D's on the console: This doesn't mean "data", but that UHD
had to drop samples because your PC didn't process them fast enough.
It's documented in the manual:
https://files.ettus.com/manual/page_general.html
Please, try running sender and transmitter on different PCs and start
with the simpler flowgraphs. Once you connect GNU Radio to the network
stack, it might send all kinds of messages that you didn't want to send.
(E.g. Dropbox discovery, etc).

Regarding the constellation points, please try to adjust the RX and TX
gains. There are sliders in the GUI. I'm not sure if 75% work well with
a loopback cable and 30dB of attenuation.

Regarding the time sink: I'm not sure what you expected to see. In
simulations, there are only the samples that you send. It's the frame
plus 10k zero padding at beginning and end. If you use hardware, the
receiver will sample at a constant rate. In your case, the devices
produces 10e6 samples per second (independent from any frame
transmissions). The sink displays 1024. If you wanted to "see
everything", this would be nearly 10k frames per second. Neither your
GPU, nor you screen, nor your eye can do this. GNU Radio, therefore,
just grabs some samples and displays them. Chances that you see the
frame like in the simulations are very small. Try to use a trigger and
play with the level. Then you should see something similar.
(Middle-click on the widget.)

Regarding thread priority: It is unrelated, but if you want to get rid
of the warning, please do as suggested in the manual:
https://files.ettus.com/manual/page_general.html

Best,
Bastian




On 7/26/19 2:37 PM, timothe dissaux wrote:
> Hi everyone,
> i'm facing a problem on gnu radio concerning a wifi tranceiver made by
> Bastian Bloessl.
> 
> I have summarized the issue in the attached pdf.
> if you are missing any information, do not hesitate to ask me for it.
> 
> I would like to point out that I am a beginner on gnu radio
> 
> In the hope that someone will be able to unlock me
> Sincerely
> Timothy, an engineering trainee in the field of electronics based at
> Heriot-Watt University (Scotland)
> 
> ___
> 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] Received data rate for wifi_rx in gnuradio

[Bastian Bloessl]

Hi,

the data rate of the PHY (derived from the encoding) is not similar to
link-level data rate. You would not reach the PHY data rate even if
frames would be sent back-to-back (overhead from preamble and signal
field). That being said, I'm not sure about your configuration. I don't
think there is a 5Mbps MCS.

I'm also not sure what you are trying to benchmark. Maximum TX rate,
receiver performance, or both at once. Regarding the transmitter, it is
not optimized for speed. It uses the upstream OFDM blocks, which, AFAIK,
introduce overhead from memory management.

There are several issues on the topic, e.g.:
https://github.com/bastibl/gr-ieee802-11/issues/162
https://github.com/bastibl/gr-ieee802-11/issues/146#issuecomment-447776917
https://github.com/bastibl/gr-ieee802-11/pull/32

And there is a paper:

G. Arcos, R. Ferreri, M. Richart, P. Ezzatti, and E. Grampín,
“Accelerating an IEEE 802.11 a/g/p Transceiver in GNU Radio,” in 9th
Latin America Networking Conference (LANC’16), Valparaíso, Chile: ACM,
Oct. 2016, pp. 13–19. DOI: 10.1145/2998373.2998443.

If you need high TX rates, there are easy improvements, as mentioned in
the paper and pull request.

Best,
Bastian

On 5/30/19 6:26 PM, Torell, Kent L wrote:
> Well, you could look at the raw data you've captured/processed from the Lime, 
> and process a few milliseconds of that.  Plot the amplitude, and you will see 
> the bursts of the wifi transmitter.  You can isolate a burst and determine 
> the spectral bandwidth to bound the modulation rate, then do some simple 
> demodulation to get a better measure of the modulation type (bpsk has only 2 
> phases) and rate.  Wireshark will tell you the user data rate, after the 
> transport packets are re-assembled after stripping off the header and control 
> bits of the physical layer signal.
> Kent
> 
> -Original Message-
> From: SG  
> Sent: Wednesday, May 29, 2019 10:10 PM
> To: Torell, Kent L ; discuss-gnuradio@gnu.org
> Subject: Re: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio
> 
> Thanks for your reply.
> 
> So in the considered system, transmitter is continuously broadcasting data at 
> the rate 5Mbps using ieee802.11 protocol (BPSK modulation is used). The WiFi 
> receiver is receiving continuously using LimeSDR Mini and I am trying to 
> capture data rate after the decode and demodulation of received signal. It is 
> receiving the broadcasted data at a significantly lower rate (based on 
> wireshark capture statistics) for which I am unable to identify the reason. 
> So I was wondering if looking at wireshark file is an accurate way to 
> approach this data-rate calculation problem or something more appropriate 
> exists.
> 
> Thanks
> 
> SG
> 
> On 29/05/19 9:35 PM, Torell, Kent L wrote:
>> Wi-fi is short burst messages.   So the modulation data rate is high, but 
>> the effective user data rate is low.  'Data rate' is very context dependent.
>>
>> -Original Message-
>> From: Discuss-gnuradio 
>>  On Behalf Of 
>> SG
>> Sent: Wednesday, May 29, 2019 1:26 AM
>> To: discuss-gnuradio@gnu.org
>> Subject: [Discuss-gnuradio] Received data rate for wifi_rx in gnuradio
>>
>> Hi,
>>
>> I have been wondering and trying to figure out a way to calculate data rate 
>> of the wifi_rx.  One way that I thought was to check the captured statistics 
>> of the wireshark (.pcap) file generated by wifi_rx. However, these are far 
>> lower than the transmitter rate which is set to 5Mbps and the receiver is 
>> based on the gr-ieee802.11.
>>
>> Could anyone point me in the right direction for calculating data-rate in 
>> gnuradio.
>>
>> Thanks
>>
>> SG



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

[Discuss-gnuradio] Workshop on Open Radio Platforms at Crowncom

[Bastian Bloessl]

Hi all,

the deadline for the open radio platforms workshop at Crowncom was
extended to 12 February.

Please consider submitting, if you are working on (or using) cool
hardware or software prototypes.

http://crowncom.org/workshop-open-radio-platforms/

Best,
Bastian



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] gr-ieee802-15-4 OOT Module not Working on E312

[Bastian Bloessl]

Hi,

On 1/18/19 12:42 AM, David Alexander wrote:
> I am currently trying to get an OOT module working on an Ettus E312, but
> I am having issues with the code as I have described in the following
> Github Issue
> https://github.com/bastibl/gr-ieee802-15-4/issues/40

...and what about the proposed solution of changing `int` to a clearly
defined data type like `uint8_t` or whatever fits for the different
vectors? This should be done in the GNU Radio blocks (C++ domain) and
the numpy arrays used in the PHY (np.array([...], dtype=np.uint8)).

Best,
Bastian



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

[Discuss-gnuradio] Workshop on Open Radio Platforms for 5G

[Bastian Bloessl]

Hi all,

I'll organize a small workshop on *Open Radio Platforms for 5G Research
and Beyond* at CROWNCOM 2019 in Poznan, Poland. Please consider
submitting if you are working on (or with) interesting hardware or
software prototypes.

Best,
Bastian



 Workshop on

  *Open Radio Platforms for 5G Research and Beyond*

 to be held in conjunction with CROWNCOM 2019
in Poznan, Poland on June 11-13, 2019.

  http://crowncom.org/workshop-open-radio-platforms/


Call for Papers
===

The digital transformation of our society won’t be possible without
the support of an appropriate mobile network infrastructure. The
evolution of this network infrastructure needs to meet the
requirements of 5G (and beyond) poses challenging research problems:
higher bandwidths and lower latencies are being demanded together with
the ability to serve a multiplicity and heterogeneity of devices. On
top of this, the network infrastructure evolution must take place in
an energy-efficient and economically sustainable manner.

Within this context, the existence of platforms and testbeds that can
speed up mobile networks innovation and enable the validation and
optimization of new radio technologies already in an early phase of
the development cycle is of paramount importance. Such platforms and
testbeds are already playing a key role in testing and evaluating the
performance achieved by new research ideas and developments. Moreover,
these platforms are covering a broad set of research questions, some
of them focusing on specific low-level aspects of wireless
communications, and some others on the study of the entire end-to-end
mobile network, including in some cases extensions tailored to the
need of specific vertical industries (automotive, industry 4.0,
eHealth, ect.). In addition, these platforms and testbeds have to be
able to validate the most significant network KPIs under realistic
conditions and in a controllable and reproducible manner.

The main focus of this workshop will be to present the latest
developments on existing platforms for 5G research and beyond (in both
hardware and software domains). A special focus will be put on open
source developments, as they speed up innovation in the mobile
networks ecosystem.


Submission
==

EAI provides the Confy submission system. Papers should be up to eight
pages long with reference, and have to comply with the Springer format
(see the website for further information [1]).

[1] http://crowncom.org/initial-submission/


Publication
===

- Proceedings will be submitted for publication by Springer
- Proceedings will be submitted for inclusion in leading indexing
  services, including EI Elsevier Engineering Index, Thomson
  Scientific ISI Proceedings, Scopus, CrossRef, Google Scholar, DBLP,
  as well as EAI’s own EU Digital Library (EUDL).
- Authors of selected papers will be invited to submit extended
  versions of their accepted appers to the special issue on „New
  application domains for the cognitive-based solutions in the context
  of 5G and beyond” in EURASIP Journal on Wireless Communications and
  Networking
- Moreover, selected papers will be invited for publication in the
  following EAI Endorsed Transactions:
  - EAI Endorsed Transactions on Cognitive Communications
  - EAI Endorsed Transactions on Wireless Spectrum


Important dates
===

Submission:   29 January 2019
Notification: 11 March 2019
Camera-ready: 12 April 2019
Conference:   11-13 June 2019


-- 
Dr. Bastian Bloessl
Research Fellow @ CONNECT Center
Trinity College Dublin

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



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] adapt the MAC of the gr-ieee802.11

[Bastian Bloessl]

Hi,

On 10/26/18 9:18 AM, Steve Joumessi Demeffo wrote:
> 
> I want to build a LiFi test bench by implementing the old PHY 802.11 IR
> layer specification (PPM-4 modulation, FEC, header) and a CSMA MAC layer
> without Ack and then split the MAC between SDR and FPGA to improve
> performance.
> I would like to start from the project gr-ieee802.11 for the
> construction of the MAC, but it is built for the PHY OFDM 802.11 a / b
> standard.
> I want to know which blocks I have to modify to adapt the MAC to my
> project. I am also looking for source code documentation. Thanks for
> your help.

I'm afraid gr-ieee802-11 is of not much help here. It is mainly the PHY.
The MAC block just adds the required headers but doesn't implement CSMA.
I also worked on a simplified channel access (broadcast only), but that
was for the FPGA of the N210.

Best,
Bastian


> Best regards
> 
> Steve JOUMESSI DEMEFFO
> 
>  
> 
> Le 2018-10-25 18:00, discuss-gnuradio-requ...@gnu.org a écrit :
> 
>> Send Discuss-gnuradio mailing list submissions to
>>  discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>  https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> or, via email, send a message with subject or body 'help' to
>>  discuss-gnuradio-requ...@gnu.org 
>> <mailto:discuss-gnuradio-requ...@gnu.org>
>>
>> You can reach the person managing the list at
>>  discuss-gnuradio-ow...@gnu.org <mailto:discuss-gnuradio-ow...@gnu.org>
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Discuss-gnuradio digest..."
>>
>>
>> Today's Topics:
>>
>>1. Re: Simulation to compute BER of a Modulator/Demodulator
>>   Encoding/Decoding system (Cinaed Simson)
>>2. adapt the MAC of the gr-ieee802.11 (Steve Joumessi Demeffo)
>>3. Re: adapt the MAC of the gr-ieee802.11 (Bastian Bloessl)
>>
>>
>> --
>>
>> Message: 1
>> Date: Wed, 24 Oct 2018 15:20:36 -0700
>> From: Cinaed Simson > <mailto:cinaed.sim...@gmail.com>>
>> To: discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org>
>> Subject: Re: [Discuss-gnuradio] Simulation to compute BER of a
>>  Modulator/Demodulator Encoding/Decoding system
>> Message-ID: <3afe8356-c05e-78df-3bfe-1c894268e...@gmail.com 
>> <mailto:3afe8356-c05e-78df-3bfe-1c894268e...@gmail.com>>
>> Content-Type: text/plain; charset=utf-8
>>
>> On 10/23/2018 08:28 PM, Christian BusquielSanz wrote:
>> > I am having this output with my Reed Solomon test:
>> > 
>> > Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>> > 
>> > Generating: '/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py'
>> > 
>> > Executing: /usr/bin/python -u
>> > /home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py
>> > 
>> > Traceback (most recent call last):
>> >   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> > line 283, in 
>> > main()
>> >   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> > line 271, in main
>> > tb = top_block_cls()
>> >   File "/home/cbusquielsanz/GNURadio/work/ReedSolomon_Test_001.py",
>> > line 87, in __init__
>> > self.satellites_encode_rs_0 = satellites.encode_rs(0)
>> > AttributeError: 'module' object has no attribute 'encode_rs'
>> > 
>> >>>> Done (return code 1)
>> > 
>> > 
>> > 
>> > 
>> > It seems that there is a problem with GR Satellites "CCSDS Reed-Solomon 
>> > Encoder"
>> > 
>> > I am attaching the flowgraph, the GRC file
>> > 
>> > I have not found information about this issue
>> > 
>> > What am I doing wrong?
>> > Thank you
>>
>> It runs without error for me under version 3.7.13.4.
>>
>> That is, it generates 3 windows each with a single straight line of
>> amplitude 0.
>>
>> -- Cinaed
>>
>> > 
>> > 
>> > 
>> > Christian S?ngir Busquiel Sanz
>> > 
>> > 
>> > 
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> &g

Re: [Discuss-gnuradio] adapt the MAC of the gr-ieee802.11

[Bastian Bloessl]

Hi Steve,

On 10/25/18 9:30 AM, Steve Joumessi Demeffo wrote:
> I want to adapt the MAC of the gr-ieee802.11 project to a PPM physical
> layer. I want to know which blocks I need to adapt to my project.

Probably `lib/mac.cc`, but that's hard to tell with this little
information. It would be helpful if you could be a bit more specific.

Best,
Bastian


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

Re: [Discuss-gnuradio] RDS-TMC for FM

[Bastian Bloessl]

Hi

On 10/14/18 9:42 PM, Vladislav Fenchak wrote:

Dear all,
im creating a new project and its related to fm radio in general. My 
question is if I can get the song title and artist from specific fm 
using RDS TMC through the gnu radio API.


There is no direct API call, but it is decoded. (There is no special 
field for the artists and song title, but it is usually in the 
'radiotext' field, which is decoded.)


See the demo here:
https://www.youtube.com/watch?v=05i9C5lhorY

Best,
Bastian


--
Dr. Bastian Bloessl
Research Fellow @ 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] Awgn simulation error

[Bastian Bloessl]

On 09/28/2018 05:48 PM, dapodun nudopad wrote:

Hi,
I had run the sim.grc in the awgn simulation folder from gr-ieee802.11 
and I get this following from the terminal. Plus, I'm not sure how I 
should measures the ber however the error I got is below. Thanks
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.HEAD-0-g929e3b32


MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
set_min_output_buffer on block 28 to 96000
thread[thread-per-block[1]: ]: 
pmt_to_long: wrong_type : #t


BER errors are not logged.

Regarding the PMT type error: There are several versions and branches of 
GNU Radio. And they have different APIs. I don't know what you are 
running, but it looks like you use the wrong branch of gr-foo for your 
GNU Radio version. There are only two branches in gr-foo, so just try 
the other one.


The fact that there are different branches that are supposed to be used 
with different versions of GNU Radio is btw the second sentence of the 
readme.


You posted this question (two times!) in an issue on GitHub (which I 
answered), then you created a new issue with the question on GitHub, 
then you posted here in another thread (which already had the answer), 
and know you opened this thread.


I think at that stage, it would be time to take a step back from your 
actual problem and reconsider your way to approach this. There's a 
really good text on how to ask questions:


http://www.catb.org/esr/faqs/smart-questions.html

Best,
Bastian

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

Re: [Discuss-gnuradio] Error compiling gr-ieee802.11

[Bastian Bloessl]

Hi,

On 09/28/2018 04:26 PM, Dmitriy Tochansky wrote:
Here is a link to patch 
https://github.com/gnuradio/gnuradio/commit/5197311dd22744b784ff9ae2cd965a26ef04f4a4 


Thanks—will this let gr-ieee802.11 compile against the master branch?

No, it's a commit that remove 'delete_head_blocking' from api.
To build gr-ieee802.11 you need to use 'maint-3.7' branch of gnuradio 
and 'master' for gr-foo and gr-ieee802.11.
If you need exactly gnuradio 'master' branch for your project, I think 
you have to do some patches to gr-foo at least.




Both gr-foo and gr-ieee802-11 have master and next branches that were 
supposed to work with the corresponding GNU Radio branches. I'd suggest 
you try the next branch of the modules.


Best,
Bastian

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

Re: [Discuss-gnuradio] Error Linking UHD

[Bastian Bloessl]

Any chances you are confusing libgnuradio-uhd.so with libuhd.so. To me 
it sounds like you want to link against the latter.


Maybe some linkers resolve symbols from libuhd through libgnuradio-uhd 
and some don't (which might make sense if you do not use any symbols 
defined in libgnuradio-uhd).


Best,
Bastian

On 6/19/2018 13:27, Gilad Beeri (ApolloShield) wrote:
The MESSAGE directive shows it should be ok - added to 
lib/CMakeLists.txt, after the first target_link_libraries(), the line 
"MESSAGE(STATUS "DEBUG GR LIBS: ${GNURADIO_ALL_LIBRARIES}")".


The output:
/
/
/-- DEBUG GR LIBS: 
/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so;/home/user/gr/lib/libgnuradio-filter.so;/home/user/gr/lib/libgnuradio-fft.so;/home/user/gr/lib/libgnuradio-uhd.so/

/
/
I moved away all cmake/ files and then put them back one-by-one until 
the build succeeded, which meant I ended up removing:

  D cmake/Modules/CMakeParseArgumentsCopy.cmake
  D cmake/Modules/FindGnuradioRuntime.cmake
  D cmake/Modules/GrMiscUtils.cmake
  D cmake/Modules/GrPython.cmake
  D cmake/Modules/GrSwig.cmake
  D cmake/Modules/GrTest.cmake
  D cmake/Modules/UseSWIG.cmake

but still no luck (the undefined symbol error still exists).

It might be worth to mention, the version I use is 3.7.11.1.


On Tue, Jun 19, 2018 at 2:47 PM Müller, Marcus (CEL) > wrote:


add a "message ()" directive that prints the GNURADIO_ALL_LIBRARIES
that is actually used in your lib/CMakeLists.txt. If that is wrong:

Move your OOT's cmake/Modules/* out of the way – I do not endorse the
fact that we're distributing copies of all the GNU Radio CMake scripts
with our OOT template, as these might outdate locally.

I must admit I don't have an OOT where I test gr-uhd linkage myself.

Best regards,
Marcus

On Tue, 2018-06-19 at 14:42 +0300, Gilad Beeri (ApolloShield) wrote:
 > I've done "rm -rf build/*" and "pushd build; cmake  ../; and make
-j7; and make install; popd" ~ 50 times since yesterday :)
 >
 > Any suggestions for debugging it?
 >
 > On Tue, Jun 19, 2018 at 2:33 PM Müller, Marcus (CEL)
mailto:muel...@kit.edu>> wrote:
 > > I must admit this is surprising to me, as the line of code where
 > > LIBS=... is printed is pretty integrally coupled to the line that
 > > specifies what GNURADIO_ALL_LIBRARIES is. Maybe CMake got confused?
 > > I know this is kind of a "haveyoutriedturningitoffandonagain"
answer,
 > > but have you tried completely rm'ing your build/ directory and
letting
 > > CMake run anew?
 > >
 > > Best regards,
 > > Marcus
 > >
 > > :e ../cmake/Modules/FindG               On Tue, 2018-06-19 at
14:19 +0300,
 > > Gilad Beeri (ApolloShield) wrote:
 > > > I have a similar problem as described in
https://lists.gnu.org/archive/html/discuss-gnuradio/2015-05/msg00195.html.
 > > >
 > > > When I try to run tests (with Python), I get:
 > > >
 > > > Traceback (most recent call last):
 > > >   File "python/myblock.py", line 12, in 
 > > >     from myproj.myproj_swig import mitigation_source
 > > >   File
"/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
line 28, in 
 > > >     _myproj_swig = swig_import_helper()
 > > >   File
"/home/user/gr/lib/python2.7/site-packages/myproj/myproj_swig.py",
line 24, in swig_import_helper
 > > >     _mod = imp.load_module('_myproj_swig', fp, pathname,
description)
 > > > ImportError:
/home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0: undefined
symbol: _ZN3uhd11time_spec_tC1Eld
 > > >
 > > >
 > > > I did add "UHD" to the line starting with
"set(GR_REQUIRED_COMPONENTS" (in my root CMakeLists.txt) so I get
the output of
 > > >
 > > > Checking for GNU Radio Module: UHD
 > > > -- Checking for module 'gnuradio-uhd'
 > > > --   Found gnuradio-uhd, version 3.7.11.1-as
 > > >  * INCLUDES=/home/user/gr/include
 > > >  *

LIBS=/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so
 > > > -- Found GNURADIO_UHD:

/home/user/gr/lib/libgnuradio-uhd.so;/home/user/gr/lib/libgnuradio-runtime.so;/home/user/gr/lib/libgnuradio-pmt.so;/usr/lib/liblog4cpp.so

 > > > GNURADIO_UHD_FOUND = TRUE
 > > >
 > > > I also have in my lib/CMakeLists.txt file
${GNURADIO_ALL_LIBRARIES} in both target_link_libraries() lists.
 > > >
 > > > I have "#include " in my header file.
 > > >
 > > > But for some reason, it doesn't seem to link gnuradio-uhd:
 > > >
 > > > readelf -d /home/user/gr/lib/libgnuradio-myproj-1.0.0git.so.0.0.0
 > > >
 > > >  0x0001 (NEEDED)             Shared library:
[libboost_system.so.1.58.0]
 > > >  0x0001 (NEEDED)             Shared library:

Re: [Discuss-gnuradio] A few questions regarding gr-ieeee802-11

[Bastian Bloessl]

Hi,

On 06/08/2018 10:18 AM, Tal Peer wrote:
1. In the Sync Long block, the input is put through a matched filter 
defined by the long training sequence in time domain. I'm probably 
overseeing something here, but  I would expect this sequence to be the 
same as the sequence given in table I-6 of the standard (well, a part of 
it at least, since it repeats 2.5 times). Now, I understand the LONG 
vector is generated using the create_long.R script and not knowing any R 
I tried to reproduce this in MATLAB. However, after some experiments I 
figured that in order to reproduce the same sequence I have to run in 
MATLAB (a is the freq. domain sequence):


fliplr(fft(ifftshift(a)/sqrt(52)))

where from the R script I would actually expect (as we're transforming 
the sequence from frequency to time domain and also conjugating it to 
create a matched filter):


fliplr(conj(ifft(fftshift(a)/sqrt(52


I'm not sure if I understand you correctly. It sounds like you think the 
steps in the R-script are reasonable, but you fail to reproduce it in 
MATLAB. I don't have MATLAB, so I cannot test it, but maybe you forgot 
an 'i' and were using the fft instead of the ifft.


I've done it again in Python and it results in exactly the steps that 
you seem to expect.


To reproduce the sequence in the standard:


import numpy as np

# frequency domain
fd = np.array([0]*6 + [1, 1, -1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 1, 1, 
-1, -1, 1, 1, -1, 1, -1, 1, 1, 1, 1, 0, 1, -1, -1, 1, 1, -1, 1, -1, 1, 
-1, -1, -1, -1, -1, 1, 1, -1, -1, 1, -1, 1, -1, 1, 1, 1, 1] + [0]*5)


# time domain
td = np.fft.ifft(np.fft.ifftshift(fd/64**.5), norm="ortho")

sync_long = np.append(td[32:], [td, td])
# sequence in standard considers windowing
sync_long[0] = sync_long[0] / 2

# Standard, Appendix I
sync_long




To reproduce the sequence in the code:



# taps for matched filter (I used a different/weird scaling)
m = np.fft.ifft(np.fft.ifftshift(fd), norm="ortho") * (64.0/52)**.5
m = np.conj(m)
m = m[::-1] # reverse for d_fir kernel (which reverses again)
# sequence in sync_long block
m








I think I might be missing something here and would be glad if someone 
could shed some light on this.


2. As seen in the provided examples, the (Random) Periodic Message 
Source from gr-foo is useful for simulations. However, due to a bug in 
GR 3.7, flowgraphs using it won't stop automatically. I'm aware that 
this has already been fixed by this PR: 
https://github.com/gnuradio/gnuradio/pull/797 . However, I would like to 
be able to use a vanilla GR 3.7 and the fix was applied to the next 
branch due to API change. Are there any known workarounds not requiring 
patching?


No, you'll have to use `next` or wait some more time until next is 
merged in master. Marcus is working on thatn (see PR 
https://github.com/gnuradio/gnuradio/pull/1809)


Best,
Bastian


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

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

Hi,

On 05/02/2018 12:04 PM, Sumit Kumar wrote:

Hi Bastian,

Yes thats correct. I believe this problem will be there if I do soft bit 
MRC i.e. independent decoding of the two branches. Just combining the 
long sync is not the solution :(


On an other note I have following question :

Inside the general_work in sync_long.cc, *ninput* is computed as follows.

*    int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
8192);*


This is the case when there are two inputs to sync_long i.e. *in* and 
*in_delayed*.


How shall I compute *ninput* when I have another branch coming say *in1* 
and *in1_delayed*.


In sync_short I faced the same issue when I input another branch. There 
I modified as follows :


*int ninput = std::min(std::min(ninput_items[2] 
,std::min(ninput_items[0], ninput_items[1])), std::min(ninput_items[4], 
ninput_items[3]));*


where previously it was

*int ninput = std::min(std::min(ninput_items[0], ninput_items[1]), 
ninput_items[2]);* 


That's a bit a confusing way to write it, but I guess it's OK.

You'd do it similarly also in Sync Long but also keep the 8192. You 
could check if there's a better min-function that accepts a variable 
number of arguments.


Best,
Bastian




Regards
Sumit
**
On 02/05/2018 08:26, Bastian Bloessl wrote:
The problem with this configuration is that the "Soft frame equalizer" 
blocks  are not synced. It's the same problem as with the Sync Short 
block, just at a later stage. Consider what happens, if one branch 
manages to decode the signal field and one doesn't. Or one thinks it's 
a 100 Byte BPSK 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
 mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
 const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
 add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed 
to the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making 
it difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar<sumit.ku...@eurecom.fr>  wrote:
So basically I will be combining the correlation values from all 
antennas to find the start of WiFi frame. With this approach, I 
believe, there wont be any need of synchronization between 
branches. Let me know your view on this.
That depends at what stage you want to combine the signal. I’d do it 
at a later stage, i.e., do frame detection and synchronization in 
each branch independently and combine the subcarriers after 
equalization. With that approach, you wouldn’t combine correlations 
values. In essence, you have to make sure that all branches start 
the synchronization process if one branch detects a frame.


Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:
I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first 
author, but since it was not real-time and for a single-carrier 
scheme, it might not be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any 
existing open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining 
for Ultra-Low Power Wildlife Monitoring". Howeve

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

The problem with this configuration is that the "Soft frame equalizer" 
blocks  are not synced. It's the same problem as with the Sync Short 
block, just at a later stage. Consider what happens, if one branch 
manages to decode the signal field and one doesn't. Or one thinks it's a 
100 Byte BPSK 1/2 and the other thinks it's a 200 Byte 64-QAM 3/4


Best,
Bastian



On 04/29/2018 03:30 PM, Sumit Kumar wrote:
"In essence, you have to make sure that all branches start the 
synchronization process if one branch detects a frame."


I am doing only slightly different from above. Frame detection is 
happening with the combined value of correlation. And once frame is 
detected, both of the branches start the synchronization process.


I have created a dual channel short_sync which uses 
*(a[n1]+a[n2])/(p[n1]+p[n2])* to compute *in_cor.

*

If this in_cor > d_threshold, i declare that WiFi has started on both 
the branches by calling a modified *insert_tag *function as follows:*

*

void insert_tag(uint64_t item, double freq_offset, *double 
freq_offset_1*, uint64_t input_item) {
     mylog(boost::format("frame start at in: %2% out: %1%") % item % 
input_item);

*
*    const pmt::pmt_t key = pmt::string_to_symbol("wifi_start");*
*    const pmt::pmt_t value = pmt::from_double(freq_offset);*
     const pmt::pmt_t value_1 = pmt::from_double(freq_offset_1);
*    const pmt::pmt_t srcid = pmt::string_to_symbol(name());*
*    add_item_tag(0, item, key, value, srcid); // tag branch -1 *
     add_item_tag(1, item, key, value_1, srcid); ***//** tag branch -2**
**

*}*

*freq_offset* for both the branches are computed independently too. *
*

The dual channel short sync block outputs two streams which are fed to 
the usual WiFi Long Sync-> FFT -> Equalizer-> etc etc steps.




With this  approach simulator works flawlessly now. Also with USRP it 
works good. But after some time, say 2-3 minutes or so, USRP stops 
receiving signal. There is no warning or error or overruns etc making it 
difficult for me to debug further.


Regards
Sumit

On 29/04/2018 14:49, Bastian Bloessl wrote:

Hi,


On 28. Apr 2018, at 17:02, Sumit Kumar<sumit.ku...@eurecom.fr>  wrote:
So basically I will be combining the correlation values from all antennas to 
find the start of WiFi frame. With this approach, I believe, there wont be any 
need of synchronization between branches. Let me know your view on this.

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian


Regards
Sumit



On 27/04/2018 11:25, Bastian Bloessl wrote:

I don't know about such an implementation. IIRC, in the paper, we recorded the 
IQ samples and processed the data offline.

If you are interested in the code you could write the first author, but since 
it was not real-time and for a single-carrier scheme, it might not be too 
helpful for your project.

If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:

Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any existing open 
source example if you know.

For this implementation, I was following one of your recently co-authored paper 
"Low-Complexity Soft-Bit Diversity Combining for Ultra-Low Power Wildlife 
Monitoring". However it seems that the source code is not open yet.

Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. What is 
making USRP to stop receiving.

https://www.youtube.com/watch?v=SPXLJ3iEWg8=youtu.be  


Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization logic between 
the branches. Consider what happens if one branch receives frames while the 
other one doesn't, then data queues up in the add block, which will sooner or 
later lead to overruns, independent from the buffer size.

Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's basically a MRC 
but instead of combining the actual signals according to their SNR, we combine 
the LLRs from separate branches and send them to Soft Decision Viterbi Decoder 
(SDVD). For this, I have modified gr-ieee 80211 which generates soft bits and 
integrated a SDVD with it. It works good when I use either single branch or 
both branch separately.

In order to implement SBMRC, for every OFDM symbol decoded, a vector of LLR 
(size 48 X 1) is generated from both the rec

Re: [Discuss-gnuradio] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

Hi,

> On 28. Apr 2018, at 17:02, Sumit Kumar <sumit.ku...@eurecom.fr> wrote:

> So basically I will be combining the correlation values from all antennas to 
> find the start of WiFi frame. With this approach, I believe, there wont be 
> any need of synchronization between branches. Let me know your view on this. 

That depends at what stage you want to combine the signal. I’d do it at a later 
stage, i.e., do frame detection and synchronization in each branch 
independently and combine the subcarriers after equalization. With that 
approach, you wouldn’t combine correlations values. In essence, you have to 
make sure that all branches start the synchronization process if one branch 
detects a frame.

Best,
Bastian

> Regards
> Sumit 
> 
> 
> 
> On 27/04/2018 11:25, Bastian Bloessl wrote:
>> I don't know about such an implementation. IIRC, in the paper, we recorded 
>> the IQ samples and processed the data offline. 
>> 
>> If you are interested in the code you could write the first author, but 
>> since it was not real-time and for a single-carrier scheme, it might not be 
>> too helpful for your project. 
>> 
>> If you come up with a solution, let me know. 
>> 
>> Best, 
>> Bastian 
>> 
>> 
>> On 04/27/2018 11:15 AM, Sumit Kumar wrote: 
>>> Ok I understand now. Could you point me how to approach for such 
>>> synchronization between the two branches. Or if there are any existing open 
>>> source example if you know. 
>>> 
>>> For this implementation, I was following one of your recently co-authored 
>>> paper "Low-Complexity Soft-Bit Diversity Combining for Ultra-Low Power 
>>> Wildlife Monitoring". However it seems that the source code is not open 
>>> yet. 
>>> 
>>> Sumit 
>>> 
>>> 
>>> On 27/04/2018 11:00, Sumit Kumar wrote: 
>>>> Yes indeed, this could also happen! I note this in my to-do list. 
>>>> 
>>>> But as of now there are no warnings of overruns etc. I recorded it. What 
>>>> is making USRP to stop receiving. 
>>>> 
>>>> https://www.youtube.com/watch?v=SPXLJ3iEWg8=youtu.be 
>>>> 
>>>> Sumit 
>>>> 
>>>> 
>>>> On 27/04/2018 10:41, Bastian Bloessl wrote: 
>>>>> Hi, 
>>>>> 
>>>>> I'm not sure if I get it, but don't you need some synchronization logic 
>>>>> between the branches. Consider what happens if one branch receives frames 
>>>>> while the other one doesn't, then data queues up in the add block, which 
>>>>> will sooner or later lead to overruns, independent from the buffer size. 
>>>>> 
>>>>> Best, 
>>>>> Bastian 
>>>>> 
>>>>> On 04/27/2018 09:54 AM, Sumit Kumar wrote: 
>>>>>> Hi, 
>>>>>> 
>>>>>> I am working on soft bit maximal ratio combiner (SBMRC). It's basically 
>>>>>> a MRC but instead of combining the actual signals according to their 
>>>>>> SNR, we combine the LLRs from separate branches and send them to Soft 
>>>>>> Decision Viterbi Decoder (SDVD). For this, I have modified gr-ieee 80211 
>>>>>> which generates soft bits and integrated a SDVD with it. It works good 
>>>>>> when I use either single branch or both branch separately. 
>>>>>> 
>>>>>> In order to implement SBMRC, for every OFDM symbol decoded, a vector of 
>>>>>> LLR (size 48 X 1) is generated from both the receiver branches. These 
>>>>>> two vectors of LLR are further added and sent to SDVD. I configured the 
>>>>>> ADD block to take 48 floats as input. 
>>>>>> 
>>>>>> First I made a simulator for SBMRC, but even after increasing the output 
>>>>>> buffer size to 50, warnings of buffer over flow kept coming. 
>>>>>> 
>>>>>> Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx A 
>>>>>> and Tx/Rx B ports as my receive branches. The LEDs go green for a second 
>>>>>> then stop. No error no warning. 
>>>>>> 
>>>>>> Looks like the *ADD *block is the cause. I have never seen this, so I am 
>>>>>> clueless where to debug. Am I missing something fundamental here ? 
>>>>>> 
>>>>>> The attached picture *usrp_sbmrc* says details of my schematic and the 
>>>>>> results when I use USRP. 
>>>>>> 
>>>>>> The attached picture *sbmrc_sim* says details of my schematic and the 
>>>>>> results when I use simulations. 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ___ 
>>>>>> 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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

I don't know about such an implementation. IIRC, in the paper, we 
recorded the IQ samples and processed the data offline.


If you are interested in the code you could write the first author, but 
since it was not real-time and for a single-carrier scheme, it might not 
be too helpful for your project.


If you come up with a solution, let me know.

Best,
Bastian


On 04/27/2018 11:15 AM, Sumit Kumar wrote:
Ok I understand now. Could you point me how to approach for such 
synchronization between the two branches. Or if there are any existing 
open source example if you know.


For this implementation, I was following one of your recently 
co-authored paper "Low-Complexity Soft-Bit Diversity Combining for 
Ultra-Low Power Wildlife Monitoring". However it seems that the source 
code is not open yet.


Sumit


On 27/04/2018 11:00, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. 
What is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals 
according to their SNR, we combine the LLRs from separate branches 
and send them to Soft Decision Viterbi Decoder (SDVD). For this, I 
have modified gr-ieee 80211 which generates soft bits and integrated 
a SDVD with it. It works good when I use either single branch or 
both branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 
Tx/Rx A and Tx/Rx B ports as my receive branches. The LEDs go green 
for a second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so 
I am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and 
the results when I use simulations.






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









--
Dipl.-Inform. Bastian Bloessl
Researcher @ 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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

Not sure what this video shows, but I guess that's the same thing. If 
one queue of the add block is full (and the other is empty) then, I 
guess, the flow graph is stuck and the USRP will stop receiving.


On 04/27/2018 11:00 AM, Sumit Kumar wrote:

Yes indeed, this could also happen! I note this in my to-do list.

But as of now there are no warnings of overruns etc. I recorded it. What 
is making USRP to stop receiving.


https://www.youtube.com/watch?v=SPXLJ3iEWg8=youtu.be

Sumit


On 27/04/2018 10:41, Bastian Bloessl wrote:

Hi,

I'm not sure if I get it, but don't you need some synchronization 
logic between the branches. Consider what happens if one branch 
receives frames while the other one doesn't, then data queues up in 
the add block, which will sooner or later lead to overruns, 
independent from the buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's 
basically a MRC but instead of combining the actual signals according 
to their SNR, we combine the LLRs from separate branches and send 
them to Soft Decision Viterbi Decoder (SDVD). For this, I have 
modified gr-ieee 80211 which generates soft bits and integrated a 
SDVD with it. It works good when I use either single branch or both 
branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector 
of LLR (size 48 X 1) is generated from both the receiver branches. 
These two vectors of LLR are further added and sent to SDVD. I 
configured the ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the 
output buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx 
A and Tx/Rx B ports as my receive branches. The LEDs go green for a 
second then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so I 
am clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and 
the results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and the 
results when I use simulations.






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







--
Dipl.-Inform. Bastian Bloessl
Researcher @ 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] Issue while adding streaming data : Integrating MRC in gr-ieee 80211

[Bastian Bloessl]

Hi,

I'm not sure if I get it, but don't you need some synchronization logic 
between the branches. Consider what happens if one branch receives 
frames while the other one doesn't, then data queues up in the add 
block, which will sooner or later lead to overruns, independent from the 
buffer size.


Best,
Bastian

On 04/27/2018 09:54 AM, Sumit Kumar wrote:

Hi,

I am working on soft bit maximal ratio combiner (SBMRC). It's basically 
a MRC but instead of combining the actual signals according to their 
SNR, we combine the LLRs from separate branches and send them to Soft 
Decision Viterbi Decoder (SDVD). For this, I have modified gr-ieee 80211 
which generates soft bits and integrated a SDVD with it. It works good 
when I use either single branch or both branch separately.


In order to implement SBMRC, for every OFDM symbol decoded, a vector of 
LLR (size 48 X 1) is generated from both the receiver branches. These 
two vectors of LLR are further added and sent to SDVD. I configured the 
ADD block to take 48 floats as input.


First I made a simulator for SBMRC, but even after increasing the output 
buffer size to 50, warnings of buffer over flow kept coming.


Then I used USRP, it simply refuses to work. I am using NI 2901 Tx/Rx A 
and Tx/Rx B ports as my receive branches. The LEDs go green for a second 
then stop. No error no warning.


Looks like the *ADD *block is the cause. I have never seen this, so I am 
clueless where to debug. Am I missing something fundamental here ?


The attached picture *usrp_sbmrc* says details of my schematic and the 
results when I use USRP.


The attached picture *sbmrc_sim* says details of my schematic and the 
results when I use simulations.






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



--
Dipl.-Inform. Bastian Bloessl
Researcher @ 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] gr-ieee802-11 and the blocks with multiple inputs

[Bastian Bloessl]

Hi,

On 02/07/2018 06:57 AM, Halit Bugra Tulay wrote:

1) The one working with 3 separate null sinks ( https://imgur.com/a/siXZN )
2) The one that does not work ( https://imgur.com/a/BFTol )

As similar to what I observed before, the first one keeps communicating 
without a problem while the second one stops communicating after a few 
successive received frame. I don't understand what causes this problem. 
Do you have any idea about this?


AFAIK, the sink with three inputs expects the same number of samples at 
each input. If one branch has no samples, i.e., if one receiver does not 
detect frames (or detects less frames), the other queues fill up. When 
the first queue is full, the SDR will stop producing samples and since 
the null source cannot continue, the flow graph stalls.
For the null sources that's not an issue, but if you want to decode the 
frame based on multiple RX branches, you probably need some logic to 
check which of the receiver synced on the frame.


Best,
Bastian

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

Re: [Discuss-gnuradio] 802.15 Zigbee transceiver

[Bastian Bloessl]

Hi,

On 01/30/2018 07:04 PM, Zhiwu Guo wrote:

Dear all,

I am working on the gnuradio project of 802.15 Zigbee transceiver which 
I downloaded from link below:


https://github.com/bastibl/gr-ieee802-15-4

I am looking the mac.cc file which is located in the lib files. As we 
all know know, there are two types of MAC mechanism in 802.15, one is 
the CSMA based, another one is TDMA based. I am wondering which 
mechanism is this mac.cc written for? I could not find any hints on this 
file. Thank you.


The MAC block just adds the MAC header. It doesn't implement any channel 
access procedure, it's just a PHY implementation.


Best,
Bastian

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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

[Bastian Bloessl]

Hi,

On 01/19/2018 10:30 PM, sumit kumar wrote:

Hi Michael, Yes I just made one and pushed everything.

https://github.com/sumitstop/MTSDR-gnuradio/commits/master

https://github.com/sumitstop/MTSDR-gr-ieee-80211/commits/master


I didn't test it, but I think you should declare the function virtual.

Best,
Bastian




My changes are in latest commit.

Thanks

On 19 January 2018 at 19:50, Michael Dickens > wrote:


__
Hi sumit - Do you have a public repo, e.g. on GitHub, that we can
review. It's virtually impossible to debug C++ issues like this
without having the code. What you want to do is very possible; just
a matter of getting all the methods in place precisely. - MLD

On Fri, Jan 19, 2018, at 10:20 AM, sumit kumar wrote:

hi..so it is not working somehow. Both builds were successful i.e.
gnuradio build with the modifications and gr-ieee-80211 build with
modifications.

gnuradio recognizes my new function as a method of
constellation_bpsk_sptr as you can see in the ipython screenshot



However gr-ieee 80211 doesnt see it as you can see in the
screenshot below. It sees only the decision_maker



Please give me some more pointers to solve this



On 19 January 2018 at 15:38, sumit kumar > wrote:

Ok a correction

I declared it like this inside the constellations.h , now I am
waiting for the compilation to finish

    class DIGITAL_API constellation_bpsk : public constellation
    {
    public:
      typedef boost::shared_ptr sptr;

      // public constructor
      static sptr make();

      ~constellation_bpsk();


      unsigned int decision_maker(const gr_complex *sample);
*float decision_maker_soft(const gr_complex *sample);*


    protected:
      constellation_bpsk();
    };

On 19 January 2018 at 15:08, sumit kumar > wrote:

Ok, so shall I do like this :

In the file
/gnuradio/gr-digital/include/gnuradio/digital/constellations.h
under public section I declare my function as follows

*class DIGITAL_API constellation*
*      : public boost::enable_shared_from_this*
*    {*
*    public:*
**
*float decision_maker_soft(const gr_complex *sample) = 0;*
**
*}*

and In the file /gnuradio/gr-digital/lib/constellations.cc
I add this

*    float*
*    constellation_bpsk::decision_maker_soft(const
gr_complex *sample)*
*    {*
*      return (-4*real(*sample)); // LLR for BPSK*
*    }*


After this I recompile gnuradio and then recompile
gr-ieee-80211.. right ?

On 19 January 2018 at 14:51, Michael Dickens
> wrote:

__
The GR constellation programming uses a base class
that defines the API that will be SWIG-ified back into
Python. So the base class must contain your
"*decision_maker_soft" *method. Then you overload it
for any inheriting class such as "constellation_bpsk".
Hope this helps! - MLD


On Fri, Jan 19, 2018, at 8:43 AM, sumit kumar wrote:

Actually I have to test it in a interference limited
environment, I guess the soft demodulate will be
needed. I saw your blog post about how you cleverly
used your won constellations
https://www.bastibl.net/constellation-objects/


However when I try doing something like that, I get
errors.

For example, I defined my own function
decision_maker_soft inside constellations_impl.h as
follows

class constellation_bpsk_impl : public constellation_bpsk
{
public:
constellation_bpsk_impl();
~constellation_bpsk_impl();

unsigned int decision_maker(const gr_complex *sample);
*float decision_maker_soft(const gr_complex *sample);*
};

and then defined it in constellation_impl.cc as

float
constellation_bpsk_impl::decision_maker_soft(const
gr_complex *sample) {
return (-4*real(*sample));
}

But when I call my function like this

mod->decision_maker_soft from ls.cc (least 

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

[Bastian Bloessl]

I'm not sure if I understand you correctly, but you have to 
differentiate what performance you mean. IT++ might have better decoding 
performance (since it's using soft-bits), but the SIMD implementation 
has better computational performance (i.e., needs less CPU).


To be honest, I didn't do a lot of testing between IT++ and the current 
version. (I think I've seen a paper that compared soft-bits vs. 
hard-bits and there was a 2-3dB improvement, but you have to check). 
Since the decoder was a CPU bottleneck, I was more than happy to merge 
the SIMD implementation, which was developed by Gonzalo Arcos based on 
the gr-dtv decoder. See here


http://www.ccs-labs.org/bib/arcos2016accelerating/

Best,
Bastian

On 1/18/2018 13:41, sumit kumar wrote:
Thanks for confirming. I believe that IT++ version will work with 
corresponding GNU Radio version.


Also what do you think (since you have developed the code for long time 
:) ) : IT++ version will be as efficient as the current one? I mean the 
current version uses SIMD for Viterbi.
I have tested the current version for success rate. I can share the 
results(attached). Success rate mentioned is nothing but ratio of 
received to transmitted frame per second using a R VSG. The test was 
done over the air.




On 18 January 2018 at 13:06, Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>> wrote:


Hi,

you are right. The current implementation does not use soft-bits but
feeds hard bits into the decoder.

In 2013, I used the soft-input Viterbi decoder from the IT++ library.

http://itpp.sourceforge.net/4.3.1/convcode.html
<http://itpp.sourceforge.net/4.3.1/convcode.html>

Best,
Bastian

On 01/17/2018 11:36 AM, sumit kumar wrote:

Hi,

I am doing some proof of concept using gr-ieee 802.11.
The paper by author [1] says that it uses softbits, however in
the method

*constellation::decision_maker(const gr_complex *sample)*, I see
outputs as hardbits.
Am I missing something here i.e. any particular commit or branch
where the softbits implementation is there.

   Its very important for my algorithm to use softbits :-/

[1]
https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf
<https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf>

Sumit




--
Sumit Kumar




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

Re: [Discuss-gnuradio] Softbits in gr-ieee 802.11 ?

[Bastian Bloessl]

Hi,

you are right. The current implementation does not use soft-bits but 
feeds hard bits into the decoder.


In 2013, I used the soft-input Viterbi decoder from the IT++ library.

http://itpp.sourceforge.net/4.3.1/convcode.html

Best,
Bastian

On 01/17/2018 11:36 AM, sumit kumar wrote:

Hi,

I am doing some proof of concept using gr-ieee 802.11.
The paper by author [1] says that it uses softbits, however in the method

*constellation::decision_maker(const gr_complex *sample)*, I see outputs 
as hardbits.
Am I missing something here i.e. any particular commit or branch where 
the softbits implementation is there.


  Its very important for my algorithm to use softbits :-/

[1] https://conferences.sigcomm.org/sigcomm/2013/papers/srif/p9.pdf

Sumit


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

Re: [Discuss-gnuradio] Sampling rate of gr-ieee 802.15.4

[Bastian Bloessl]

Hi,

> On 9. Nov 2017, at 17:25, Sumit Kumar  wrote:
> 
> Hi, 
> 
> The 802.15.4 spec says that the channels should be 2 MHz wide with 5 MHz 
> inter channel spacing. 
> 
> Why does gr-ieee 802.15.4 uses a sampling rate of 4MHz instead of 2 MHz ? 
> 
> Off course it works with commercial devices, but I am curious why 4 MHz and 
> not 2 MHz. 

With 4Mhz, the receiver samples the signal at a rate of 2 samples per chip. You 
could also use less or more, it’s a trade-off between computational complexity 
and performance.

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

Re: [Discuss-gnuradio] Warning while running gr-ieee-80211

[Bastian Bloessl]

Hi,

On 10/25/2017 06:13 AM, sumit kumar wrote:

*Ubuntu 16.04*
*GNURadio and gr-ieee-80211 installed yesterday using pybombs *

I get this warning when I run the wifi_rx.grc

"The total sum of rates (20.00 MSps on 1 channels) exceeds the 
maximum capacity of the connection"


Looks like warning from your SDR driver. What are you using? If the same 
hardware already worked, the only thing I could imagine is that you 
plugged a USB 3.0-capable device in a USB 2.0 port.


Best,
Bastian

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

Re: [Discuss-gnuradio] gr-foo

[Bastian Bloessl]

Hi,

On 10/21/2017 01:18, Ron Economos wrote:
It's an issue with gr-foo. For some reason, Bastian jumped the gun and 
made a change to gr-foo to work with the yet to be released GNU Radio 
3.8 where the fractional resampler had been renamed to the mmse resampler.


I get lots of emails about that, but I don't understand the problem. As 
the readme suggests:


"Like GNU Radio, this module uses *master* and *next* branches for 
development, which are supposed to be used with the corresponding GNU 
Radio branches."


So the next branch of gr-foo is supposed to be used with the next branch 
of GNU Radio and the master branch of gr-foo is supposed to be used with 
the master branch of GNU Radio.


Did I push to the wrong branches or is there a general problem with this 
approach to OOT module development?


Best,
Bastian




If you go back one commit, it will compile

git checkout 2ba97c8d6d1e6bb322446773e42cbdac347c0085

Ron

On 10/20/2017 03:26 PM, Cinaed Simson wrote:

I'm installing gnuradio and number of oot modules on a new i7 laptop.

I have the latest git pulls for gnuradio and gr-foo.

Gnuradio builds without any issues.

For gr-foo, cmake finds everything and generates the make files.

But when I run

   make

in the gr-foo build directory, it craps out - indicating it can't find

   #include 

I did a find on the gnuradio tree it case per chance it was moved but no
cigar.

I was able to build it a while back - maybe 3.7.10?

Maybe I could just check out an older version of gnuradio and copy the
file into gr-foo - but that has the potential of blowing up in my face.

I can build gr-ieee802-11 and gr-ieee802-15-4 without gr-foo so it's not
a show stopper.

Or am I just missing something?

-- Cinaed


root@alfven:/opt/gnuradio/src/gr-oot/gr-foo/build# make
Scanning dependencies of target gnuradio-foo
[  5%] Building CXX object
lib/CMakeFiles/gnuradio-foo.dir/burst_tagger_impl.cc.o
[ 10%] Building CXX object
lib/CMakeFiles/gnuradio-foo.dir/channel_model_impl.cc.o
In file included from
/opt/gnuradio/src/gr-oot/gr-foo/lib/channel_model_impl.cc:18:0:
/opt/gnuradio/src/gr-oot/gr-foo/lib/channel_model_impl.h:27:47: fatal
error: gnuradio/filter/mmse_resampler_cc.h: No such file or directory
  #include 
    ^
compilation terminated.
lib/CMakeFiles/gnuradio-foo.dir/build.make:77: recipe for target
'lib/CMakeFiles/gnuradio-foo.dir/channel_model_impl.cc.o' failed
make[2]: *** [lib/CMakeFiles/gnuradio-foo.dir/channel_model_impl.cc.o]
Error 1
CMakeFiles/Makefile2:121: recipe for target
'lib/CMakeFiles/gnuradio-foo.dir/all' failed
make[1]: *** [lib/CMakeFiles/gnuradio-foo.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2




___
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 mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] 802.15.4 Frame sync confusion

[Bastian Bloessl]

Hi,

On 10/19/2017 09:00 AM, Sumit Kumar wrote:
Yes but even to get the chip sequences, which are nothing but bits, the 
incoming complex samples have to be decoded i.e. OQPSK demodulation.


I saw MATLAB implementation by Rice University as well in the latest 
release of MATLAB 2017b (they have included a 802.15.4 toolbox)


All of them employ the same technique i.e. first do a OQPSK demodulation 
and then find preambles.


I was wondering why not do auto correlation or cross correlation of 
incoming complex samples as there is a repetition of samples in the 
beginning.


Currently, the receiver looks like this:

IQ -> FM demodulation -> clock recovery (extract chips) -> search for 
the chip sequence of the preamble.


It's only one simple way to do it. I'm sure you could get higher 
performance with more complicated algorithms that consider the signal at 
an earlier stage, i.e., you could work with the baseband signal or the 
signal after FM demodulation. However, both approaches would increase 
(at least) computational complexity. It's a trade-off.


Best,
Bastian





Sumit

On Wed, Oct 18, 2017 at 3:50 PM, Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>> wrote:


Hi,

On 10/18/2017 01:24 PM, sumit kumar wrote:

Hi,


If my understanding is correct, most of the 802.15.4 receiver
implementations perform frame synchronization i.e. find the
start of the frame using the preambles which are nothing but 8
zeros(each of which is further converted to 32 bit chip).

This is done after the OQPSK symbols (complex samples) are
already decoded to bits. Same does the gr-ieee 802.15.4


It's actually working with the chip sequences not the data bits.
When the receiver is not synchronized is searches for the chip
sequence that corresponds to the zero data bits, i.e., the preamble.
Once the sequence is found (when the chip sequence matches
reasonably well), it continues to decode chip sequences with the
known alignment (and looks for the SFD data bits).

That means the algorithm works already on a rather deep layer. I'm
sure it could be much improved. It is just a simple approach that
presents a tradeoff between performance and complexity (in terms of
CPU time and implementation complexity).

Best,


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

Re: [Discuss-gnuradio] TunTap Interace for GNU Radio IEEE 802.11 a/g/p module

[Bastian Bloessl]

Hi,

On 10/19/2017 02:49 AM, Wen Cui wrote:

I followed the nic.sh file and your replies to others in the mail list. I 
really want to know whether it is only related to the TUN/TAP setup thing or it 
is related to the gnuradio code. I don’t know how to figure out the setup 
problem of the transceiver and where is the good place to ask this question. If 
you'd like to give me a hint, I will really appreciate about that.
  
PC1:

//wireless card in PC1
Tap0, IP: 192.168.123.1 MAC: 12:34:56:78:90:ab
wls5, IP: 192.168.123.20 MAC: a8:96:8a:f6:d5:2e

//USRP connected the PC1 through Ethernet cable
enp10s0, IP: 192.168.10.100 MAC: 40:6a:7f:bc:f2:2f
USRP, IP: 192.168.10.5 MAC: 00:80:2f:0a:cf:68

PC2:
//wireless card in PC2
wlp8s0, IP:192.168.123.50 MAC: 74:e7:0f:34:42:ba

I did the same config code as nic.sh does in PC1 but with changed IP and MAC 
address. I also set the arp and route things in PC2.

After I turn the tap0 up in PC1, I cannot PING PC1 anymore through PC2, and 
vice versa. The PC1 can hear the ICMP request from PC2, but cannot reply for 
that.


If both PCs can send a ping, but both don't trigger a reply, it might 
just be that ICMP requests are ignored.


This can be changed with:

echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all

If that's not the problem, start Wireshark on both sender and receiver 
and monitor the TUN/TAP interface only to better understand what's 
really going on. Maybe a frame is sent, but not received by the SDR or 
something like that.


Best,
Bastian

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

Re: [Discuss-gnuradio] 802.15.4 Frame sync confusion

[Bastian Bloessl]

Hi,

On 10/18/2017 01:24 PM, sumit kumar wrote:

Hi,


If my understanding is correct, most of the 802.15.4 receiver 
implementations perform frame synchronization i.e. find the start of the 
frame using the preambles which are nothing but 8 zeros(each of which is 
further converted to 32 bit chip).


This is done after the OQPSK symbols (complex samples) are already 
decoded to bits. Same does the gr-ieee 802.15.4


It's actually working with the chip sequences not the data bits. When 
the receiver is not synchronized is searches for the chip sequence that 
corresponds to the zero data bits, i.e., the preamble. Once the sequence 
is found (when the chip sequence matches reasonably well), it continues 
to decode chip sequences with the known alignment (and looks for the SFD 
data bits).


That means the algorithm works already on a rather deep layer. I'm sure 
it could be much improved. It is just a simple approach that presents a 
tradeoff between performance and complexity (in terms of CPU time and 
implementation complexity).


Best,
Bastian

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

Re: [Discuss-gnuradio] stop/start is not called in gr.basic_block

[Bastian Bloessl]

Hi,

On 10/05/2017 03:13 AM, Miklos Maroti wrote:

I am trying to implement a simple block in python but it seems that
stop and start is never called when I implement them. The bare bones
python code would be this:

class test(gr.basic_class):
 def __init__(self):
 gr.basic_block.__init__(self, name="test", in_sig=None, out_sig=None)

 def start(self):
 print "never called"
 return gr.basic_block.start(self)

The same works in C++. I could not find any example that implements
start/stp in python, but looking at the docs for gr.basic_block it
should work. Any ideas?


AFAIK, if the block is not connected to any other block, it is not 
handled by the flow graph/scheduler.
If you don't actually have a use-case for a completely separate block, 
you could try adding a stream or message port an connect it.


Best,
Bastian

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

Re: [Discuss-gnuradio] Asynchronous Switch between two stream inputs to one output GNU Radio C++

[Bastian Bloessl]

Hi,

On 07/27/2017 01:19 AM, Cristian Rodríguez wrote:

Imágenes integradas 1
This block just receive signal for one of the two ports at the same 
time. In this way, for example if it receives in the IN0, in the IN1 
there's nothing. Depending on the parameter Initial Standard I select 
which input must pass to the output, that as supposed, is the input in 
which I have signal.


Then, i wrote the next forecast() method.

 void forecast(int noutput_items, gr_vector_int _items_required){
 if(d_st_aux == 0){
 ninput_items_required[0] = 0;
 ninput_items_required[1] = noutput_items;//Tx Xbee
 }else{
 ninput_items_required[0] = noutput_items;//Tx Wifi
 ninput_items_required[1] = 0;
 }
   }

In that way I just take the input that has signal, and that works perfectly.

The problem is when, through the third input, I send a command in order 
to change the input that I want to read. That's done by way of 
re-writing the value of *d_st_aux*, it occurs in real time. For this 
case, I would need that forecast method changes in real time, the  
ninput_items_required, but it doesn't work. I think the block is just 
calling the forecast method when it starts, but I need to call forecast 
in real time.


I think the general design of the block is OK. After the message is 
received forecast() and (depending on forecast() and the availability of 
samples) work() will also be called. That means forecast() is *not* only 
run during initialization of the block.


Maybe the actual problem is at a different part of the code. Or maybe 
things happen in a different order then you expect. I would recommend to 
add some debug output to forecast(), work(), and the message handler. 
That might help to debug the problem.



Best,
Bastian

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

Re: [Discuss-gnuradio] Message Passing Not Working

[Bastian Bloessl]

Hi,

AFAIS, you call the output message port "gain", but try to publish to 
the message port "gain_port". When I changed it to use "gain", it seems 
to work.


Best,
Bastian


On 07/22/2017 12:49 AM, Tellrell White wrote:
In the attached flow graph, I've created a block, "gain setter" that 
takes in a number of input items and after the input items reach a 
certain amount, the block will issue a command to the ursp sink to 
change the gain to a certain value. I basically did this using a loop. 
However, it doesn't seem like the gain of the signal changes according 
to the freq sink plot of the received signal. Any ideas??




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

Re: [Discuss-gnuradio] Calculate BER in WIFI 802.11p standards !

[Bastian Bloessl]

Hi,


On 07/17/2017 11:06 AM, Mériem Saïdi wrote:

Hi,

I use 802.11 IEEE standards to code and decode a PMT message and i would 
like to calculate the BER between the source of information I want to 
encode and the same source after decoding. (see attached screen-shots below)
Except that I have all time a null BER ! however the "channel model" 
block introduce noise so the BER can't be null!
I've tried with a Random Source instead of Message Strobe but always the 
same result !
I don't know if the problem comes from one of the encoding/decoding 
flowgraph, or from the position of outputs i took to calculate BER ??!!

any ideas please ?!


If you want to see errors, you have to change the SNR (lower it) or 
switch to higher modulation and coding schemes.


Apart from that, it is currently not out of the box possible to measure 
the BER, just the FER. An example simulation can be found in the 
simulations/awgn folder of the project. It produces this plot


https://github.com/bastibl/gr-ieee802-11/blob/next/simulations/awgn/pdr.pdf

Best,
Bastian

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

Re: [Discuss-gnuradio] csma_and_agc branch

[Bastian Bloessl]

Hi Richard,

strange errors. Any chances that you have another (old) installation somewhere 
on your system?

Best,
Bastian

> On 14. Jul 2017, at 22:36, Collins, Richard 
> <richard.coll...@axenterprize.com> wrote:
> 
> Hello,
> 
> I'm having trouble building Bastien Bloessl's csma_and_agc branch of GNURadio 
> on Ubuntu 16.04 LTS. I've already run through his version of UHD (except for 
> building the fpga bitstream and soft cpu firmware binaries -- it appears I'll 
> need Windows XP or Suse 11, and a copy of Xilinx ISE 12.2 for that, eek). 
> 
> Here are the steps that I've taken, and the errors I received:
> 
> $ git clone -b csma_and_agc --recursive 
> https://github.com/bastibl/gnuradio.git
> $ cd gnuradio && mkdir build && cd build
> $ cmake -Wno-dev -DENABLE_GR_COMEDI=OFF ../
> 
> The git clone command checks out the version of volk with the git tag:
> f28a8be8af974d1a55a176009cb0b7927bc2
> 
> Halfway through the build, I'll get a couple errors where it seems CMake (or 
> python or something) is looking in gnuradio/ for files that exist in 
> gnuradio/volk/... for example:
> 
> /usr/bin/python2: can't open file 
> '/home/ninja/workspace/src_bastibl/gnuradio/gen/volk_compile_utils.py': 
> [Errno 2] No such file or directory
> 
> Making a symlink to the gnuradio/volk/gen folder in gnuradio (i.e. cd ../ && 
> ln -s volk/gen) seems to allow CMake to continue until it hits the next volk 
> requirement and is looking again in the wrong directory.
> 
> I also get the following error soon after (though it looks like outputs from 
> two different sources are competing for stdout or stderr, given the out of 
> order nature of some things being logged to the screen):
> 
> -- CPU width is 64 bits, Overruled arch 32
> CMake Error at volk/lib/CMakeLists.txt:129 (list):
>   list sub-command REMOVE_ITEM requires list to be present.
> Call Stack (most recent call first):
>   volk/lib/CMakeLists.txt:253 (OVERRULE_ARCH)
> 
> It finishes with:
> 
> -- Configuring incomplete, errors occurred!
> See also 
> "/home/ninja/workspace/src_bastibl/gnuradio/build/CMakeFiles/CMakeOutput.log".
> See also 
> "/home/ninja/workspace/src_bastibl/gnuradio/build/CMakeFiles/CMakeError.log".
> 
> Attached is the output from CMake that I'm referencing 
> (cmake_user_displayed_output.txt), as well as the two CMake log files 
> referenced at the end of the cmake run.
> 
> 
> Questions:
> 
> Should I be using a different version of volk, or maybe change something in a 
> CMakeLists.txt file?
> Does anyone happen to have a copy of the csma_and_agc binaries for the N210r4 
> (for use with the XCVR2450 daughtercard, as it appears the changes are only 
> made for use with this radio card)?
> 
> 
> Thanks to anyone who can help,
> 
> Richard
> 

--
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)

[Bastian Bloessl]

Hi,

On 07/12/2017 07:36 AM, sumit kumar wrote:

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.


Try forcing the dongle to a specific rate after you switched it to ad 
hoc mode. If that doesn't work, I would use the 5GHz band (there it 
doesn't downgrade to 11b). Make sure to use a channel that doesn't 
require DFS.



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 
transceive >
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.


That's a question for the people from openairinterface.



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 :)


Sending ACKs is not the same as CSMA. The transceiver doesn't send ACKs, 
if some packet is lost, TCP resends the segment. (ARQ happens on 
transport layer not on link layer).


Best,
Bastian




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 <mailto:Discuss-gnuradio@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
<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




--
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)

[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] 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] Problems with IEEE802-11 Blocks?

[Bastian Bloessl]

Hi,

> On 11. Jul 2017, at 02:04, Taylor Eisman <taylor.eis...@my.utsa.edu> 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 <m...@bastibl.net> 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 <m...@bastibl.net 
> <mailto:m...@bastibl.net>> 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
>   

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

[Bastian Bloessl]

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 <m...@bastibl.net 
<mailto:m...@bastibl.net>> 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 something else. I've
messed with the parameters and noticed that it is always 3
symbols short of a full frame, even if there are theoretically
3000 symbols, it would only pass 2997 symbols.

Any ideas on what could be causing this?

I'm attaching the WiFi Phy Hier graph to give you some idea of
the layout
.



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


    -- 
    Dipl.-Inform. Bastian Bloessl

CONNECT Center
Trinity College Dublin

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




--
Thanks,

Taylor Eisman
Graduate Researcher
University of Texas at San Antonio


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

Re: [Discuss-gnuradio] GR- IEEE 802.15.4 PHY Issues

[Bastian Bloessl]

The staggering of the imaginary part in combination with the half sine 
pulse shape, makes the constellation point move on the unit circle. 
During a bit period it makes a 90 degree transition to one of the 
neighboring constellations (encoding the 0 and 1). It doesn't actually 
stay at the ideal constellation points, but immediately starts the next 
transition.


Now if the sample rate would be very high, you would see many closely 
spaced points on the unit circle. But the example flow graph uses a 
sample rate of only 4M, i.e., 2 symbols per bit/chip. Therefore, you see 
only one more sample/constellation point when the transition is half way 
through, leading to 8 different points shown in the constellation sink.


Best,
Bastian


On 07/08/2017 09:22 PM, Tellrell White wrote:

Thanks for the response Bastian

I have taken a look at the IEEE 802.15.4 as suggested. I do see that 
half sine pulse shaping is used according to the standard. However,  I 
believe the issue may be with my understanding of O-QPSK. I've attached 
a picture that I use as a reference. I thought the key difference 
between qpsk and o-qpsk is that due to the staggering of the imag 
component by a half a symbol, o-qpsk can only result in 90 degree 
transitions instead of the 180 degree variations seen in qpsk. I'm still 
trying to understand why i'm seeing 8 constellation points from my 
constellation sink and not the usual 4 that you would see in any o-qpsk 
constellation plot. If any one has a good reference on this please share.


Tellrell


On Saturday, July 8, 2017 5:53 AM, Bastian Bloessl <m...@bastibl.net> wrote:


Hi,

On 07/08/2017 05:03 AM, Tellrell White wrote:
 > Hello Guys
 > I'm currently using the IEEE 802.15.4 PHY. I've added a random source to
 > the flow graph and also a qt gui time and constellation sink. I have two
 > questions, why does the constellation plot attached show more than the
 > usual 4 constellation points seen in O-QPSK constellation?? Is it due to
 > the sampling rate I'm using which is 8M in this case.

The default sampling rate is 4M, I don't know what you changed when you
tried to make it 8M. If you add a constellation sink to the unmodified
flowgraph you will see constellation points on the unit circle (your
second screenshot), which is what you would expect, since IEEE 802.15.4
uses O-QPSK with a half-sine pulse shape (see the standard).


 >
 > Also, I was curious as to if the vector source added which implements
 > the half sine pulse shaping was creating a problem so I disabled it and
 > I was able to see the expected 4 constellation points. So, is the source
 > of extra constellation points I'm seeing?? I've attached both the .grc
 > file and 2 screen shots, one representing both constellation plots
 > discussed.


With this you removed the pulse shaping, so you see only the QPSK
constellations, but it's also not 15.4 anymore. Most standards use some
kind of pulse shaping, so you don't see only the constellation points
when you look at the final IQ signal. I don't understand why this is a
problem for you.


Best,
Bastian





___
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] Problems with IEEE802-11 Blocks?

[Bastian Bloessl]

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 something else. I've messed with 
the parameters and noticed that it is always 3 symbols short of a full 
frame, even if there are theoretically 3000 symbols, it would only pass 
2997 symbols.


Any ideas on what could be causing this?

I'm attaching the WiFi Phy Hier graph to give you some idea of the layout
.



___
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] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,
On 07/08/2017 07:11 PM, sumitstop wrote:

Wao superb! you cleaned it out also. Yes it works. Thanks much.

But did you figure out what was the issue at the first place :)


I'm not sure. Maybe it was related to one of the Packet Pad blocks. 
Since you resampled, you also changed the length of the frame, which 
might have confused the block (the length tag at the start of the frame 
didn't correspond to the length of the frame anymore).




I have another related question about the wireshark connector in
transceiver_OQPSK.grc. I see that wireshark connector gets input from two
different outputs.

One from pdu_out of IEEE802.15.4 MAC and another from rxout of IEEE802.15.4
OQPSK PHY

When I see the output pcap file i..e sensor.pcap, same packet is logged
twice. I realized this by observing their sequence number field, which
repeats two times for every broadcast frame.


Yes, in the loopback configuration it logs all frames twice. Once they 
are sent and once they are received. The setup makes more sense when you 
actually transmit frames over the air. Then you might want to log what 
was sent and what was received.


In your simulations you probably know what you sent and are only 
interested in which frames made it through. In that case, just remove 
the connection from the sender to the Wireshark block.


Best,
Bastian

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

Re: [Discuss-gnuradio] TUNTAP PDU with rds example

[Bastian Bloessl]

Hi,

On 07/07/2017 06:06 PM, Markley da Silva Mendes wrote:

Hi all,

I would like to know if there is any example where I have captured the 
data rds (radio data sistem), using an RTL-2832u, and transformed into 
ethernet frames using the TUNTAP PDU block? And if there is any 
documentation explaining how I can use the TUNTAP PDU block with other 
technologies (zigbee, bluetooth, zWave ...)?


I don't know what you would expect from connecting RDS to a TUNTAP 
interface. With TUNTAP you create a virtual Ethernet interface, which 
allows you to connect your transceiver to the Linux network stack.

For RDS, I don't see any benefit from doing this.

What you might want is connect the transceiver to Wireshark to inspect 
and dissect the data. This can be done with RFtap:


https://rftap.github.io/blog/2016/08/27/decoding-rds-with-rftap.html

Best,
Bastian

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

Re: [Discuss-gnuradio] GR- IEEE 802.15.4 PHY Issues

[Bastian Bloessl]

Hi,

On 07/08/2017 05:03 AM, Tellrell White wrote:

Hello Guys
I'm currently using the IEEE 802.15.4 PHY. I've added a random source to 
the flow graph and also a qt gui time and constellation sink. I have two 
questions, why does the constellation plot attached show more than the 
usual 4 constellation points seen in O-QPSK constellation?? Is it due to 
the sampling rate I'm using which is 8M in this case.


The default sampling rate is 4M, I don't know what you changed when you 
tried to make it 8M. If you add a constellation sink to the unmodified 
flowgraph you will see constellation points on the unit circle (your 
second screenshot), which is what you would expect, since IEEE 802.15.4 
uses O-QPSK with a half-sine pulse shape (see the standard).




Also, I was curious as to if the vector source added which implements 
the half sine pulse shaping was creating a problem so I disabled it and 
I was able to see the expected 4 constellation points. So, is the source 
of extra constellation points I'm seeing?? I've attached both the .grc 
file and 2 screen shots, one representing both constellation plots 
discussed.


With this you removed the pulse shaping, so you see only the QPSK 
constellations, but it's also not 15.4 anymore. Most standards use some 
kind of pulse shaping, so you don't see only the constellation points 
when you look at the final IQ signal. I don't understand why this is a 
problem for you.



Best,
Bastian

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,

On 07/06/2017 07:55 AM, sumitstop wrote:

Hello Bastian,
Sorry for late response.
I am attaching the files for your reference. There are 2 grc files

1. wifi_zigbee.grc : wifi and zigbee loopbacks are running in parallel >>
works good

2. wifi_zigbee_interference.grc : Here I interpolate the zigbee output by 5,
feed to channel, add to 20 MHz wifi signal. Added signal is fed directly to
wifi receiver however I decimate it by 5 before feeding it to zigbee
receiver.

I see the following on the terminal for the 2nd grc file.

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_4.0.0.rfnoc-devel-283-g7ff43262
MAPPER: encoding: 0
set_min_output_buffer on block 9 to 397056
set_min_output_buffer on block 11 to 397056
set_min_output_buffer on block 13 to 397056
set_min_output_buffer on block 14 to 397056
set_min_output_buffer on block 16 to 397056
sender started
set_min_output_buffer on block 58 to 96000


After that nothing happens, just the cursor keeps blinking.

wifi_zigbee.grc


wifi_zigbee_interference.grc




I was playing a bit around with the flow graph. Forgot what the actual 
problem was, but this adapted version works for me:


http://www.ccs-labs.org/~bloessl/wifi_zigbee_interference.grc

Best,
Bastian

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

Re: [Discuss-gnuradio] Running gr-ieee 802.11 and gr-ieee 802.15.4 under same flowgraph (interference and co-existence)

[Bastian Bloessl]

Hi,

thanks for the detailed description. I’m not sure what the actual error is. 
What do you mean with grc turns dark.
Does it crash or stop receiving or actually show a black window? Did grc turn 
dark or the flow graph?

Best,
Bastian



> On 4. Jul 2017, at 22:10, sumitstop  wrote:
> 
> Hello, 
> (Its a long post :) as I want to give as much details as possible)
> 
> Today I did a strange experiment. Under GNU Radio companion, I created a
> blank project. Then I copy pasted the wifi_loopback.grc from gr-ieee 802.11
> to my blank project and made it run. Off course I took care of the initial
> settings of the variables and all. It ran successfully. Then I copy pasted
> the transceiver_OQPSK.grc from gr-ieee 802.15.4 to the same grc project
> where wifi_loopback.grc was there. Then I separated the variables carefully
> and make both wifi_loopback and transceiver_OQPSK to run under the same flow
> graph at the same time. They ran successfully without any issue! 
> 
> In the next step, I tried to create an environment of interference between
> WiFi and ZigBee by adding the baseband output of WiFi transmitter and ZigBee
> transmitter. But before that I upsampled the ZigBee 5 times to make it 20
> MHz wide. 
> 
> In the next step, I took the output of mixed signal i.e. ZigBee + WiFi and
> fed it to individual receivers. Here also I downsampled the mixed signal to
> 4 MHz before feeding it to the ZigBee receiver. 
> 
> But this setup din't work at all. The grc just turned dark. There were no
> error messages. I am not sure where I am theoretically and/or practically
> wrong. 
> 
> * I am trying to analyse WiFi and ZigBee interference. 
> 
> Regards


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

Re: [Discuss-gnuradio] Python and C++ codes of the blocks IEEE 802.11

[Bastian Bloessl]

Hi Christian,

> On 24. Jun 2017, at 22:50, Cristian Rodríguez 
>  wrote:
> 
> This parameter is no global, I mean, when I use the wifi_phy_hier.grc in the 
> transceiver.grc or tx.grc, etc, If I modify the parameter before launch the 
> simulation it is ok, the change has effect in the flowgraph, but if i add a 
> QT GUI Range, and I modify it after the beginning of the simulation it 
> doesn't have effect. Then I think the "set" of the parameter is no global 
> (thinking in OOP).

Currently, the sensitivity is only through the constructor of the Sync Short 
block. That means it’s set when the block is instantiated and cannot be changed 
afterwards.

If you want to change the parameter while the flow graph is running (through a 
slider in the GUI, for example), you will have to extend the Sync Short block 
with a callback.
You could have a look at the Frame Equalizer block, for example. It allows 
changing the algorithm during run-time.

To extend Sync Short you have to:
- add the callback function to the XML description of the block:  (see here 
https://github.com/bastibl/gr-ieee802-11/blob/next/grc/ieee802_11_frame_equalizer.xml#L9)
- implement the callback for the block (note that the callback is a public 
function that has also to be added to the definition in /include/, and the use 
of a mutex since ‘work’ and the callback are called in different thread 
contexts).

If you implement this, please make a pull-request :-)

> 
> Besides, this parameter is used in the WiFi Sync Short, and i want to modify 
> this block to set that parameter as an input, and create another block in 
> which i'm going to include a fuzzy system to set the parameter depending on 
> other parameters.

For that use-case, I would extend the Sync Short block with an async message 
input (the gray ports in GRC) and let your fuzzy system send PMTs with the 
updated sensitivity values.

Best,
Bastian




> But at the very first, I need to be able to modify the parameter Threshold 
> (sensitivity) globally.
> 
> 
> 
> Thanks a lot for your time Marcus.
> 
> Best regards,
> 
> Cristian.
> 
>  
> 
> Best regards,
> 
> Marcus
> 
> 
> On 06/24/2017 11:17 PM, Cristian Rodríguez wrote:
>> Hi all,
>> 
>> I hope all is going well.
>> 
>> I was trying to modify the code of some blocks, where is usually the code of 
>> an specific block or flowgraph?
>> 
>> Specifically, I want to modify the number of inputs in the 
>> wifi_phy_hier.grc, and put the variable Sensitivity as global, I mean, that 
>> i can modify it while the code is running, as rx_gain or tx_gain. 
>> 
>> But in general, where can i find the codes? Are there some predefined 
>> folders?
>> 
>> Thanks in advance.
>> 
>> Best regards,
>> 
>> Cristian


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

Re: [Discuss-gnuradio] ieee80211 Packet Header Question

[Bastian Bloessl]

Hi,

On 06/19/2017 04:35 AM, Richard Bell wrote:

Hello,

I'm looking at the ieee 802-11 OOT from cgran to try and duplicate the 
custom packet header creation done there. I'm wondering how the 
signal_field "block" (it's not a block, it's just a class I think) was 
made.


It was not auto-generated, if you mean this. I created it with an editor.

Is it a 'noblock', or is it something else
The signal is a C++ class, derived from digital::packet_header_default, 
which is not a GNU Radio block:


https://github.com/bastibl/gr-ieee802-11/blob/next/include/ieee802-11/signal_field.h#L27

I'm not sure because there are impl.cc and impl.h files, which do not get created by default 
when a 'noblock' is made.


I'm not sure what you mean here, but the files for the signal field were 
not created with gr_modtool... The split between main class and *_impl 
is more about swig bindings and makes also sense for non-blocks.


Best,
Bastian

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

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/09/2017 05:14 PM, zhan siyu wrote:
Then how to explain the relationship between the 5M and the 115K bits/s 
throughput?


I cannot since I see absolutely no relationship. Maybe you want to 
explain (in detail) why you think these numbers should match.



Best,
Bastian





Best regards.

Siyu


2017-06-08 21:41 GMT+08:00 Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>>:


Hi,

On 06/07/2017 02:32 PM, zhan siyu wrote:

Thanks for your reply. Let me explain what I 'm doing.

I have two B210s connected with two computers. I want to measure
the throughput between the two computers over the usrp
connection over gr-ieee802-11. But no matter how hard I try,
like tuning the parameters and turning off my own wifi card and
AP, I can only get 150K B/s, which should be around 300K B/s if
my theoretical calculation is right.  There are no underrun or
overrun errors. The throughput measurement tool I'm using is
iperf, which is an application to measure the end to end throughput.

Could you give me some hints?


I'm afraid I can't help a lot, since I have no idea what iperf is
doing. I guess it floods the network stack with UDP packets. The GNU
Radio transceiver, however, has no back pressure mechanism, so it
will just drop the frames when they are injected into the GNU Radio
flow graph.

Also, I don't understand what exact analytical number you are trying
to reproduce here. In fact, I have no idea what this experiment is
supposed to show/prove or what part of the transceiver you are
trying to profile. If, at all, this experiment will tell you how
fast the TX-side can produce frames.

This was investigated in

Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and
Eduardo Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in
GNU Radio," Proceedings of 9th Latin America Networking Conference
(LANC'16), Valparaíso, Chile, October 2016, pp. 13-19.

Turns out, you can improve the TX-side by improving the OFDM Carrier
Allocator.

Best,
Bastian



Best regards.

Siyu

2017-06-07 14:02 GMT+08:00 Bastian Bloessl <m...@bastibl.net
<mailto:m...@bastibl.net> <mailto:m...@bastibl.net
<mailto:m...@bastibl.net>>>:


 Hi,

 On 06/07/2017 03:04 AM, zhan siyu wrote:

 Thanks. I just wonder why. Because I meet some performance
 problem. I thought it maybe caused by my
misconfiguration of the
 gr-ieee802-11 code. Now, it seems not.


 I'm a bit confused why the fact that the transceiver is not
 configured through iwconfig ruled out any configuration
issues, but
 great that all seems to be set up now.


 However, theoretically,  as my current sample rate is
10M and
 BPSK. So the coding rate should be 10M/2 = 5M b/s. The
 throughtput should be around 5M/8 = 625K B/s. Assuming
the 12%
 head cost, so the data throughput should be 625 * 88 %
= 550K
 B/s.  But as my experiment shows, the throughput is
only 150K B/s.

 I'm new to the communication. Is my calculation right ?


 BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet
has to
 be subtracted, i.e. the actual maximum rate depends on the
frame size.


 If it were right, then what might cause the gap?


 Since you don't explain what you are doing, this is very
hard to
 tell. You would reach this theoretical throughput only if
you send
 frames back-to-back (which probably only works if you
pregenerate
 the sample stream). But also a WiFi card will insert
inter-frame
 space, so that the actual throughput will not match the
theoretical
 maximum physical layer throughput.

 Best,
 Bastian



 One more question, I didn't run the volk_profile. Does
it matter?

 Best regards.

 Siyu


     2017-06-07 4:23 GMT+08:00 Bastian Bloessl
<m...@bastibl.net <mailto:m...@bastibl.net>
 <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>
<mailto:m...@bastibl.net <mailto:m...@bastibl.net>

 <mailto:m...@bastibl.net <mailto:m...@bastibl.net>>>>:

  Hi,

  On 06/06/2017 03:55 PM, zhan siyu wrote:

  Hi all,

  I just found I can't use the iwconfig tap0
rate 20M to
 setup the
  bandwidth 

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/07/2017 02:32 PM, zhan siyu wrote:

Thanks for your reply. Let me explain what I 'm doing.

I have two B210s connected with two computers. I want to measure the 
throughput between the two computers over the usrp connection over 
gr-ieee802-11. But no matter how hard I try, like tuning the parameters 
and turning off my own wifi card and AP, I can only get 150K B/s, which 
should be around 300K B/s if my theoretical calculation is right.  There 
are no underrun or overrun errors. The throughput measurement tool I'm 
using is iperf, which is an application to measure the end to end 
throughput.


Could you give me some hints?


I'm afraid I can't help a lot, since I have no idea what iperf is doing. 
I guess it floods the network stack with UDP packets. The GNU Radio 
transceiver, however, has no back pressure mechanism, so it will just 
drop the frames when they are injected into the GNU Radio flow graph.


Also, I don't understand what exact analytical number you are trying to 
reproduce here. In fact, I have no idea what this experiment is supposed 
to show/prove or what part of the transceiver you are trying to profile. 
If, at all, this experiment will tell you how fast the TX-side can 
produce frames.


This was investigated in

Gonzalo Arcos, Rodrigo Ferreri, Matías Richart, Pablo Ezzatti and 
Eduardo Grampín, "Accelerating an IEEE 802.11 a/g/p Transceiver in GNU 
Radio," Proceedings of 9th Latin America Networking Conference 
(LANC'16), Valparaíso, Chile, October 2016, pp. 13-19.


Turns out, you can improve the TX-side by improving the OFDM Carrier 
Allocator.


Best,
Bastian




Best regards.

Siyu

2017-06-07 14:02 GMT+08:00 Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>>:


Hi,

On 06/07/2017 03:04 AM, zhan siyu wrote:

Thanks. I just wonder why. Because I meet some performance
problem. I thought it maybe caused by my misconfiguration of the
gr-ieee802-11 code. Now, it seems not.


I'm a bit confused why the fact that the transceiver is not
configured through iwconfig ruled out any configuration issues, but
great that all seems to be set up now.


However, theoretically,  as my current sample rate is 10M and
BPSK. So the coding rate should be 10M/2 = 5M b/s. The
throughtput should be around 5M/8 = 625K B/s. Assuming the 12%
head cost, so the data throughput should be 625 * 88 % = 550K
B/s.  But as my experiment shows, the throughput is only 150K B/s.

I'm new to the communication. Is my calculation right ?


BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet has to
be subtracted, i.e. the actual maximum rate depends on the frame size.


If it were right, then what might cause the gap?


Since you don't explain what you are doing, this is very hard to
tell. You would reach this theoretical throughput only if you send
frames back-to-back (which probably only works if you pregenerate
the sample stream). But also a WiFi card will insert inter-frame
space, so that the actual throughput will not match the theoretical
maximum physical layer throughput.

Best,
Bastian



One more question, I didn't run the volk_profile. Does it matter?

Best regards.

Siyu


2017-06-07 4:23 GMT+08:00 Bastian Bloessl <m...@bastibl.net
<mailto:m...@bastibl.net> <mailto:m...@bastibl.net
<mailto:m...@bastibl.net>>>:

 Hi,

 On 06/06/2017 03:55 PM, zhan siyu wrote:

 Hi all,

 I just found I can't use the iwconfig tap0 rate 20M to
setup the
 bandwidth of the tap0. The error message is :

 Error for wireless request "Set Bit Rate" (8B20) :
SET failed on device tap0 ; Operation not
supported.

 But in their video , it can be set in this way. May I
know how
 to solve it ?


 The WiFi transceiver is attached to the tun/tap interface,
which is
 a virtual Ethernet device. This device doesn't support
WiFi-specific
 configuration through iwconfig.

 If you wanted this level of integration, you would have to
write a
 kernel module that attaches the transceiver to a virtual
WiFi card.

 Some group already did that, but they didn't release the
source code.

 Best,
 Bastian



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

Re: [Discuss-gnuradio] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/07/2017 03:04 AM, zhan siyu wrote:
Thanks. I just wonder why. Because I meet some performance problem. I 
thought it maybe caused by my misconfiguration of the gr-ieee802-11 
code. Now, it seems not.


I'm a bit confused why the fact that the transceiver is not configured 
through iwconfig ruled out any configuration issues, but great that all 
seems to be set up now.




However, theoretically,  as my current sample rate is 10M and BPSK. So 
the coding rate should be 10M/2 = 5M b/s. The throughtput should be 
around 5M/8 = 625K B/s. Assuming the 12% head cost, so the data 
throughput should be 625 * 88 % = 550K B/s.  But as my experiment shows, 
the throughput is only 150K B/s.


I'm new to the communication. Is my calculation right ?


BPSK 1/3 is 3Mbit/s gross at 10MHz. The overhead per packet has to be 
subtracted, i.e. the actual maximum rate depends on the frame size.



If it were 
right, then what might cause the gap?


Since you don't explain what you are doing, this is very hard to tell. 
You would reach this theoretical throughput only if you send frames 
back-to-back (which probably only works if you pregenerate the sample 
stream). But also a WiFi card will insert inter-frame space, so that the 
actual throughput will not match the theoretical maximum physical layer 
throughput.


Best,
Bastian




One more question, I didn't run the volk_profile. Does it matter?

Best regards.

Siyu


2017-06-07 4:23 GMT+08:00 Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>>:


Hi,

On 06/06/2017 03:55 PM, zhan siyu wrote:

Hi all,

I just found I can't use the iwconfig tap0 rate 20M to setup the
bandwidth of the tap0. The error message is :

Error for wireless request "Set Bit Rate" (8B20) :
   SET failed on device tap0 ; Operation not supported.

But in their video , it can be set in this way. May I know how
to solve it ?


The WiFi transceiver is attached to the tun/tap interface, which is
a virtual Ethernet device. This device doesn't support WiFi-specific
configuration through iwconfig.

If you wanted this level of integration, you would have to write a
kernel module that attaches the transceiver to a virtual WiFi card.

Some group already did that, but they didn't release the source code.

Best,
Bastian




--
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] why can't use iwconfig when I run the gr-ieee802-11

[Bastian Bloessl]

Hi,

On 06/06/2017 03:55 PM, zhan siyu wrote:

Hi all,

I just found I can't use the iwconfig tap0 rate 20M to setup the 
bandwidth of the tap0. The error message is :


Error for wireless request "Set Bit Rate" (8B20) :
  SET failed on device tap0 ; Operation not supported.

But in their video , it can be set in this way. May I know how to solve it ?


The WiFi transceiver is attached to the tun/tap interface, which is a 
virtual Ethernet device. This device doesn't support WiFi-specific 
configuration through iwconfig.


If you wanted this level of integration, you would have to write a 
kernel module that attaches the transceiver to a virtual WiFi card.


Some group already did that, but they didn't release the source code.

Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Bastian Bloessl]

On 06/04/2017 06:07 PM, Qurat-Ul-Ann Akbar wrote:
It does detect the correlation and start of frames in sync_Short 
block but data is not decoded probably because of high noise. 
If there are no overruns and your SNR is so incredibly bad that you 
cannot even detect the autocorrelation at the start of the frame, I 
would try a different SDR.


Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Bastian Bloessl]

On 06/04/2017 05:35 PM, Qurat-Ul-Ann Akbar wrote:
Then what could be the problem for a low SNR. The average power I see at 
the receiver is -100 to -120 db and the signal is too distorted within 
noise.


This can have many reasons (including gain, interference, DC offsets, LO 
leakage, etc etc.) I think it will take some more effort from your side 
to find out what's going wrong.


You might find lots of helpful information on
- wime-project.net/installation/
- the GNU Radio Wiki
- the mailing list archive
- Stack overflow




And I watched your video on YouTube in which you were showing a demo of 
the WiFi receiver. In that video you had big antennas and I don't think 
those were Vert 2450.


If the video shows larger dipoles with cables, they were ECOM9-5500. 
Again, I don't believe that the antennas are your problem. I used the 
transceiver successfully with many different antennas, including the 
Vert 2450 that you are using.


Best regards,
Bastian





On Jun 4, 2017 11:21 AM, "Bastian Bloessl" <m...@bastibl.net 
<mailto:m...@bastibl.net>> wrote:




On 06/04/2017 05:16 PM, Qurat-Ul-Ann Akbar wrote:

I understand. But you didnt connect them directly to the USRP.
You used some cable to connect the two and had a stand for your
antenna. Can you tell me which cable was that ?


I have no idea what you are talking about. When I used the Vert
antennas, I connected them directly to the USRP.

If you experience low SNR you'll probably not improve things if you
add cables between the SDR and the antenna. I doubt that the antenna
or cables are your problem.

Best,
Bastian




On Jun 4, 2017 11:13 AM, "Bastian Bloessl" <m...@bastibl.net
<mailto:m...@bastibl.net> <mailto:m...@bastibl.net
<mailto:m...@bastibl.net>>> wrote:

 Hi,


 On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:

 Thank you for the explanation. Can you tell me which
antennas
 did you use for your experiments when you wrote your paper?
 Because I think a major problem with my receiver is a
very low
 SNR because everything works fine with simulations.
Currently I
 am using Vert 2450 antenna with my USRP N210.


 I used the same setup with the Vert 2450 antennas.

 Best,
 Bastian






     On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl
 <m...@bastibl.net <mailto:m...@bastibl.net>
<mailto:m...@bastibl.net <mailto:m...@bastibl.net>>
 <mailto:m...@bastibl.net <mailto:m...@bastibl.net>
<mailto:m...@bastibl.net <mailto:m...@bastibl.net>>>> wrote:

  Hi,

  On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:

  Hello,

  How is the timing offset being handled in the
802.11
 module. I
  see that the sync_long block does frequency offset
 correction
  and the frame_equalizer block does the phase
correction
 but I
  dont understand where is the timing offset being
 handled. Can
  anyone tell me which algorithm is being used
to do that?


  The Sync Long block correlates the signal with the
known
 pattern of
  the long preamble to derive how the FFTs have to
be aligned
     in time.

  Best,
  Bastian


-- 
Dipl.-Inform. Bastian Bloessl

CONNECT Center
    Trinity College Dublin

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



--
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] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Bastian Bloessl]

On 06/04/2017 05:16 PM, Qurat-Ul-Ann Akbar wrote:
I understand. But you didnt connect them directly to the USRP. You used 
some cable to connect the two and had a stand for your antenna. Can you 
tell me which cable was that ?


I have no idea what you are talking about. When I used the Vert 
antennas, I connected them directly to the USRP.


If you experience low SNR you'll probably not improve things if you add 
cables between the SDR and the antenna. I doubt that the antenna or 
cables are your problem.


Best,
Bastian





On Jun 4, 2017 11:13 AM, "Bastian Bloessl" <m...@bastibl.net 
<mailto:m...@bastibl.net>> wrote:


Hi,


On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:

Thank you for the explanation. Can you tell me which antennas
did you use for your experiments when you wrote your paper?
Because I think a major problem with my receiver is a very low
SNR because everything works fine with simulations. Currently I
am using Vert 2450 antenna with my USRP N210.


I used the same setup with the Vert 2450 antennas.

Best,
Bastian






On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl
<m...@bastibl.net <mailto:m...@bastibl.net>
<mailto:m...@bastibl.net <mailto:m...@bastibl.net>>> wrote:

 Hi,

 On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:

 Hello,

 How is the timing offset being handled in the 802.11
module. I
 see that the sync_long block does frequency offset
correction
 and the frame_equalizer block does the phase correction
but I
 dont understand where is the timing offset being
handled. Can
 anyone tell me which algorithm is being used to do that?


 The Sync Long block correlates the signal with the known
pattern of
 the long preamble to derive how the FFTs have to be aligned
in time.

 Best,
         Bastian



--
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] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Bastian Bloessl]

Hi,


On 06/04/2017 04:25 PM, Qurat-Ul-Ann Akbar wrote:
Thank you for the explanation. Can you tell me which antennas did you 
use for your experiments when you wrote your paper? Because I think a 
major problem with my receiver is a very low SNR because everything 
works fine with simulations. Currently I am using Vert 2450 antenna with 
my USRP N210.




I used the same setup with the Vert 2450 antennas.

Best,
Bastian







On Sun, Jun 4, 2017 at 12:33 PM, Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>> wrote:


Hi,

On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:

Hello,

How is the timing offset being handled in the 802.11 module. I
see that the sync_long block does frequency offset correction
and the frame_equalizer block does the phase correction but I
dont understand where is the timing offset being handled. Can
anyone tell me which algorithm is being used to do that?


The Sync Long block correlates the signal with the known pattern of
the long preamble to derive how the FFTs have to be aligned in time.

Best,
Bastian



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

Re: [Discuss-gnuradio] IEEE 802.11 Transceiver Module - Timing offset at receiver side

[Bastian Bloessl]

Hi,

On 6/3/2017 9:11 PM, Qurat-Ul-Ann Akbar wrote:

Hello,

How is the timing offset being handled in the 802.11 module. I see that 
the sync_long block does frequency offset correction and the 
frame_equalizer block does the phase correction but I dont understand 
where is the timing offset being handled. Can anyone tell me which 
algorithm is being used to do that?


The Sync Long block correlates the signal with the known pattern of the 
long preamble to derive how the FFTs have to be aligned in time.


Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE802.11 transceiver - problems sending data

[Bastian Bloessl]

Hi,

On 5/26/2017 4:04 PM, Cristian Rodríguez wrote:


**arp -a**
? (192.168.123.1) at 12:34:56:78:90:ab [ether] PERM on wlp2s0

**route**
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse 
Iface

192.168.123.0   *   255.255.255.0   U 0  00 wlp2s0

**ifconfig**
wlp2s0Link encap:Ethernet  HWaddr e0:ca:94:68:06:a7
   inet addr:192.168.123.2 Bcast:192.168.123.255  Mask:255.255.255.0
   UP BROADCAST MULTICAST  MTU:1500  Metric:1

**iwconfig**
wlp2s0IEEE 802.11
   Mode:ad-hoc  Frequency:2.462 GHz

Then i don't catch the problem.



As I said, I would recommend to use Wireshark (at sender and receiver) 
and the debug/logging output of the WiFi transceiver to see where things 
go wrong.


We have no chance to debug your network config.

Best,
Bastian


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

Re: [Discuss-gnuradio] IEEE802.11 transceiver - problems sending data

[Bastian Bloessl]

Hi,

On 5/26/2017 10:57 AM, Marcus Müller wrote:

Hi Cristian,

assuming this is a network config issue



Me too. I think that trying to ping a local address and having it routed 
over interfaces might, in theory, be possible, but hard to setup.


Try communicating with a WiFi card of another PC. Set the interface to 
ad hoc mode and setup static routing and ARP entries. That's what I did 
in the video. You already have the script for the SDR host. The other 
hosts uses similar IP and ARP configurations (but, of course, doesn't 
create the TUN/TAP device or start GNU Radio).


Best,
Bastian



: On modern Linuxes, it's usually
not a great idea to manipulate network config using ifconfig directly – 
NetworkManager tends to change things automagically if it doesn't think 
the link is functional (sometimes, even if it is). Please make sure your 
card is either unmanaged by NetworkManager, or set up the device like 
you want it to behave, and then activate the connection with `nmcli`. 
I'm not quite sure this is best solved on the discuss-gnuradio mailing 
list – we're not really linux networking setup experts :)


Best regards,

Marcus


On 05/26/2017 07:18 AM, Cristian Rodríguez wrote:



2017-05-19 7:04 GMT-05:00 Bastian Bloessl <m...@bastibl.net 
<mailto:m...@bastibl.net>>:


Hi,

> On 19. May 2017, at 12:09, Cristian Rodríguez
<cristian.rodriguez...@gmail.com
<mailto:cristian.rodriguez...@gmail.com>> wrote:
>
>  You will have to also add the corresponding entry in reverse
direction. It’s not in the script since I always used the WiFi
card of another PC.

> I did that as follows:
>
> sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp4s0

So you just set up one ARP entry.


>
> Then use Wireshark to monitor GNU Radio (that’s what you might
do at the moment) and also the WiFi card. This might help to
understand what frames are actually sent, if they are OK (MAC, IP,
BSS) and if they are successfully received by the WiFi card and
the SDR.
> If i do a ping from the interface tap0 to 192.168.123.2 (IP of
my wifi card) it doesn't work. The signal is going out of the USRP
but the Wifi Card of the computer is not taking it.
>
> ping -I tap0 192.168.123.2
>
> If i do a ping from the interface wlp4s0 to 192.168.123.1 (IP of
USRP B210) it doesn't work. The signal is NOT going out of the
Wifi card (i verifed that through wireshark).
>
> ping -I wlp4s0 192.168.123.1

As I said, you will have to actually look at the frame (BSS, MAC,
IP, …) and see if the fields are OK. Also put the receiver in
monitor mode to check if the packet is actually received. It’s a
configuration issue and you will have to find out where in the
network stack it gets dropped.

I've tried to solve the trouble the whole week. I don't think my 
computer is able to support the communication between its Wifi card 
and the USRP B210. When i do a Ping from the USRP to the wifi card (in 
monitor mode), and it receives the ping, it stops working and in the 
terminal which is executing the app nic.sh appear *ether type: IP. *In 
the wireshark file for the side of Tx, it clearly have stoped working. 
I've tried to solve it, but i don't think is a configuration problem.


On the other side, i got a computer and i'm try to communicate to it. 
When i configure Monitor mode i can get packages.


What interface Mode do you think i should use? Ad-hoc or managed?

I've tried both but for me it doesn't work.

I've checked the frame and it looks as supposed. It shows the MAC of 
the PC which is receiving, the MAC associated to the USRP and the 
common flags.


I think it is a problem in the configuration file in the PC which is 
receiving.

In that PC i'm doing the next:

Turn off the interface:
sudo ifconfig wlp2s0 down
Set the mode
sudo iwconfig wlp2s0 mode monitor/managed
Turn on the interface:
sudo ifconfig wlp2s0 up
Set in the channel that USRP is going to send
sudo iw dev wlp2s0 set freq 2472
Assign an IP in the network, the USRP is .1
sudo ifconfig wlp2s0 192.168.123.2
Modify the kernel's IPv4 network
sudo route add -net 192.168.123.0/24 <http://192.168.123.0/24> wlp2s0
Set a static route
sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp2s0

All the commands work, i checked with iwconfig, ifconfig, route, arp -a

*arp -a*
? (192.168.123.1) at 12:34:56:78:90:ab [ether] PERM on wlp2s0

*route*
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref
Use Iface

192.168.123.0   *   255.255.255.0   U 0  00 wlp2s0

*ifconfig*
wlp2s0Link encap:Ethernet  HWaddr e0:ca:94:68:06:a7
  inet addr:192.168.123.2 Bcast:192.168.123.255  
Mask:255.255.255.0

  UP BROADCAST MULTICAST  MTU:1500  Metric:1

*iwconfig*
wlp2s0IEEE 802.11 ESSID:off/any
  Mode:Managed  Frequency:

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Bastian Bloessl]

Hi,

On 05/23/2017 01:12 PM, Ayan Chatterjee wrote:

Hi,

Is there any buffer on the receiver side which stores received packets 
before decoding ?


Yes, there are many. GNU Radio uses shared buffers to exchange data 
(samples) between blocks. See here:


https://www.gnuradio.org/blog/buffers/

Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver

[Bastian Bloessl]

Hi,

On 05/23/2017 12:54 PM, Ayan Chatterjee wrote:

Hi,

In IEEE 802.11 a/g/p Receiver 
(https://github.com/bastibl/gr-ieee802-11), when a packet gets dropped, 
does the transmitter resend another packet with the same sequence number ?




No.

Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.15.4_OQPSK PHY Constellation issues

[Bastian Bloessl]

Hi,

On 05/23/2017 02:45 AM, Tellrell White wrote:

Hi All,
I'm currently using the the IEEE 802.15.4 testbed developed by Bastian 
Bloessl, and company, specifically the offset-qpsk PHY. The only changes 
I've made to the flow-graph developed by Bastian is adding  a vector 
source consisting of 0's and 1's as my input source and adding a 
constellation sink. I've attached the flow-graph for reference. When 
running the flow-graph, the output of the constellation doesn't look 
quite correct. For instance I'm not quite sure why there are 
constellation points at 0 + j and 0 - j as well as at 1 + 0j  and 1- 0j. 
A picture of the constellation plot is also attached.


I'm not sure what you are irritated about. With OQPSK you don't change 
abruptly, but transition from one constellation point to the other on a 
circle. Depending on the sample rate, there are multiple points 
in-between the final constellation at +-0.707 +- 0.707i. (in that case 
it is just one).



Best,
Bastian

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

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p transreceiver module - Number of symbols per frame?

[Bastian Bloessl]

Hi,

On 05/21/2017 11:45 PM, Qurat-Ul-Ann Akbar wrote:

Hi,

I want to look at the number of symbols copied for *each frame received 
*in wifi_rx flow graph. I have been trying to understand how the start 
of each frame is calculated and by looking at the code it seems like its 
being done in the wifi sync_short block where the auto correlation 
coefficient is being checked against a threshold and then the d_plateau 
is being updated until it reaches MIN_PLATEAU.


However, for the number of symbols per frame, there is a MAX_SAMPLES 
which is set to 540*80 where 80 is the number of samples per symbol but 
I don't understand why is the total number of symbols per frame set to 540?


IIRC, that corresponds to a 1500 byte BPSK 1/2 frame. It just pipes in 
the maximum number of samples, since this block doesn't know the actual 
size of the frame.





Whats the role of MIN_GAP? Why is it being used to detect a shorter frame?



The autcorrelation has a plateau at the beginning of the frame. To avoid 
triggering multiple times, the receiver waits at least MIN_GAP samples.


But even if the receiver still copies samples, it can already 
resynchronize after MIN_GAP samples, i.e., if it's not one large frame, 
but short ones with low interarrival time.





Moreover, does it mean that the number of symbols per frame can be 
either MAX_SAMPLES or MIN_GAP because in both cases it starts searching 
for new frames. What if one frame has less number of symbols than 
MIN_GAP and MAX_SAMPLES?


It will receive frames with __up to__ MAX_SAMPLES and short frames 
back-to-back, if they are spaced __at least__ MIN_GAP samples.


Best,
Bastian


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

Re: [Discuss-gnuradio] IEEE802.11 transceiver - problems sending data

[Bastian Bloessl]

Hi,

> On 19. May 2017, at 12:09, Cristian Rodríguez 
>  wrote:
> 
>  You will have to also add the corresponding entry in reverse direction. It’s 
> not in the script since I always used the WiFi card of another PC.

> I did that as follows:
> 
> sudo arp -s 192.168.123.1 12:34:56:78:90:ab -i wlp4s0

So you just set up one ARP entry.


> 
> Then use Wireshark to monitor GNU Radio (that’s what you might do at the 
> moment) and also the WiFi card. This might help to understand what frames are 
> actually sent, if they are OK (MAC, IP, BSS) and if they are successfully 
> received by the WiFi card and the SDR.
> If i do a ping from the interface tap0 to 192.168.123.2 (IP of my wifi card) 
> it doesn't work. The signal is going out of the USRP but the Wifi Card of the 
> computer is not taking it. 
> 
> ping -I tap0 192.168.123.2
> 
> If i do a ping from the interface wlp4s0 to 192.168.123.1 (IP of USRP B210) 
> it doesn't work. The signal is NOT going out of the Wifi card (i verifed that 
> through wireshark).
> 
> ping -I wlp4s0 192.168.123.1

As I said, you will have to actually look at the frame (BSS, MAC, IP, …) and 
see if the fields are OK. Also put the receiver in monitor mode to check if the 
packet is actually received. It’s a configuration issue and you will have to 
find out where in the network stack it gets dropped.

Best,
Bastian


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

Re: [Discuss-gnuradio] IEEE 802.11 a/g/p Transceiver - Packets not properly getting received

[Bastian Bloessl]

Hi,

> On 19. May 2017, at 08:17, Ayan Chatterjee  wrote:

> While using https://github.com/bastibl/gr-ieee802-11 receiver, I am getting 
> some wrong packets, which when opened with Wireshark give infos like:
> 
> - 1506 Fragmented IEEE 802.11 frame
> - 1345 Data, SN =3977, FN =1, Flags= p, PRMF
> - 51 Association Request, SN = 1776, FN=14, flags = p...M..
> 
> How do I get all packets in unfragmented form?

the receiver just logs the frames as seen by the phy. I don’t know if there is 
a tool or Wireshark extension that does further processing.

Maybe you could ask people on the Wireshark mailing list. They might be more 
into that.

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

Re: [Discuss-gnuradio] IEEE802.11 transceiver - problems sending data

[Bastian Bloessl]

Hi,

this is a rather complex setup. I would not immediately run SSH, but start with 
a simple ping (test GNU Radio and the WiFi card as senders). Try to see what 
works and what goes wrong, for example, ARP (in both directions) or routing.

IIRC, the script just sets up ARP in one direction (from the SDR to the WiFi 
card). You will have to also add the corresponding entry in reverse direction. 
It’s not in the script since I always used the WiFi card of another PC.

Then use Wireshark to monitor GNU Radio (that’s what you might do at the 
moment) and also the WiFi card. This might help to understand what frames are 
actually sent, if they are OK (MAC, IP, BSS) and if they are successfully 
received by the WiFi card and the SDR.

(Also make sure that an SSH server is actually running.)

There are a lot of things that can go wrong in this setup. You should try to 
narrow it down a bit. Once you have a more specific problem, it might be easier 
to help. 

Best,
Bastian





> On 16. May 2017, at 16:57, Cristian Rodríguez 
>  wrote:
> 
> Hi all.
> 
> I'm trying to run the file nic.sh (app for the transceiver flowgraph in 
> gnuradio) as in this youtube video of Bastian, but i can run it at all.
> 
> I have:
>   • USRP B210
>   • i7 4710HQ, 12 Gb RAM, USB 3.0.
>   • Ubuntu 16.04.2
> I'm doing 
> 
> I understand the proof as:
> 
> 
> 
> Then i just would have to reconfigure my PC MAC in the nic.sh file and 
> flowgraph, put a channel in the 2GHz band, set 20 Msamples/s and run it.
> 
> It is the main part of nic.sh file. I just changed my MAC and assigned the 
> 192.168.123.2 IP. The other is the same of i got in Github.
> 
> 
> 
> I did the same in the flowgraph (just in this WIFI MAC block).
> 
> 
> 
> Thus. I run the app by the terminal... ./nic.sh.
> 
> Later, i open another terminal and type ssh 192.168.123.2, and it doesn't 
> work as in the video. Then i check wireshark and it is that happens. I'm 
> receiving the petition of a TCP port but it for any reason is not working. In 
> this way i can't connect from the USRP B210 to my pc. I think my PC is not 
> answering the petition or something like that.
> 
> 
> 
> The MACs are as supposed (i Checked it in wireshark)
> 
> 
> Thanks in advance for the time to read it.
> 
> Best regards,
> 
> Cristian


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

Re: [Discuss-gnuradio] ImportError: No module named _osmosdr_swig

[Bastian Bloessl]

Maybe it’s a problem with loading the shared library, similar to this issue:

https://github.com/bastibl/gr-ieee802-11/issues/74

Best,
Bastian


> On 10. May 2017, at 23:19, Fernando  wrote:
> 
> On 10/05/17 22:43, Cinaed Simson wrote:
>> The odd thing is gnuradio-companion should have complained if the
>> PYTHONPATH wasn't being set.
>> 
>> So it's being set somewhere else.
>> 
>> How do you know you only have one installation of gnuradio installed?
> Opensuse has a packet manager similar to debian, I have installed
> gnuradio from the packet manager
> 
>> 
>> And where did you get the gnuradio you installed?
>> 
>> In any case type
>> 
>> which gnuradio-config-info
>> 
>> and
>> 
>>   gnuradio-config-info --prefix --sysconfdir --enabled-components
>> --builddate --prefsdir --version
> 
> fernando@andromeda:~> which gnuradio-config-info
> /usr/bin/gnuradio-config-info
> fernando@andromeda:~> gnuradio-config-info --prefix --sysconfdir
> --enabled-components --builddate --prefsdir --version
> /usr
> /etc
> /etc/gnuradio/conf.d
> 
> python-support;testing-support;volk;doxygen;sphinx;gnuradio-runtime;gr-ctrlport;gr-blocks;gnuradio-companion;gr-fec;gr-fft;gr-filter;gr-analog;gr-digital;gr-dtv;gr-atsc;gr-audio;*
> alsa;* oss;* jack;*
> portaudio;gr-channels;gr-noaa;gr-pager;gr-qtgui;gr-trellis;gr-uhd;gr-utils;gr-video-sdl;gr-vocoder;gr-fcd;gr-wavelet;gr-wxgui
> 3.7.11
> fernando@andromeda:~>
> 
> 
>> 
>> Then you need to find your grc.conf file and delete it
>> 
>>  find $HOME -name grc.conf
>> 
>> Then try to start gnuradio-companion - don't add anything to the flow
>> graph. Just see if it starts up properly.
>> 
> 
> It starts properly, but when I try to add both osmocom blocks it crashes
> again
> 
> I have made a clean install of the same version of Opensuse (42.2) in a
> different partition, sharing the same /home partition, installed
> gnuradio and gr-osmosdr and it does not crash
> 
> thanks
> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>>> 
>>> and running gnuradio-companion it crashes again with osmocom
>>> 
>>> 
>>> no luck  :-(
>>> 
>>> thanks
>>> 
>>> 
>>> 
>>> On 10/05/17 03:46, Cinaed Simson wrote:
 On 05/09/2017 12:23 AM, Fernando wrote:
> 
> On 09/05/17 07:02, Cinaed Simson wrote:
>> On 05/08/2017 03:44 PM, Fernando wrote:
>>> My GRC crashes when I place a osmocom source and osmocon sink.
>>> 
>>> Doing some research I have found that is a python problem with 
>>> _osmosdr_swig
>>> 
>>> fernando@andromeda:~> python -c 'import osmosdr' Traceback (most recent
>>> call last):   File "", line 1, inFile
>>> "/usr/lib64/python2.7/site-packages/osmosdr/__init__.py", line 26, in
>>>  from osmosdr_swig import *   File
>>> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 21,
>>> in  _osmosdr_swig = swig_import_helper()   File
>>> "/usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py", line 20,
>>> in swig_import_helper return
>>> importlib.import_module('_osmosdr_swig')   File
>>> "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
>>>__import__(name) ImportError: No module named _osmosdr_swig
>>> fernando@andromeda:~>
>>> 
>>> I am using Opensuse 42.2, and it have been reported taht it works fine
>>> for other people with the same OS.
>>> 
>>> there is a package called python-gr-osmosdr wich contains
>>> /usr/lib64/python2.7/site-packages/osmosdr/osmosdr_swig.py
>> Remove the directory
>> 
>>  /home/fernando/.grc_gnuradio
>> 
>> Check to ensure there's a shared library
>> 
>>   _osmosdr_swig.so
>> 
>> in the same directory.
>> 
>> Check to ensure the installation of gnuradio was added to your python 
>> path
>> 
>>  python -c "import os; print(os.environ.get('PYTHONPATH', ''))"
>> 
>> Check to ensure there's only one installation of gnuradio.
>> 
>> -- Cinaed
>> 
> _osmosdr_swig.so  is here
> 
> andromeda:/home/fernando # find / |grep _osmosdr_swig.so
> /usr/lib64/python2.7/site-packages/osmosdr/_osmosdr_swig.so
> 
> 
> 
> fernando@andromeda:~> python -c "import os;
> print(os.environ.get('PYTHONPATH', ''))"
> it reports no error
 Actually, not reporting a PYTHONPATH is an error.
 
 In order for the gnuradio-companion to find osmosdr/_osmosdr_swig.so it
 needs a PYTHONPATH defined - there's more than version of python
 installed on most Linux systems.
 
 Try it again but type
 
  python2.7 -c "import os; print(os.environ.get('PYTHONPATH', ''))"
 
 It's possible that python is linked to a different version of python2.7
 on your system.
 
 If it's empty again, make sure python2.7 is the version of python you're
 using in your shell by typing
 
   python --version
 
 If the version is not python2.7 (or a minor version of 2.7) then add
 

Re: [Discuss-gnuradio] gr_ieee-80211 receiver

[Bastian Bloessl]

> On 9. May 2017, at 08:26, LiLi  wrote:
> 
> If we want to capture frames from a route, we should change the codes.
> The codes on github can capture frames  which generate by the wifi_tx codes
> bacause the value of FCS is constant. After we change the value OF FCS to be
> an adaptive one, the frames from a route can be captured.
> 

FCS stands for frame check sequence. If the FCS doesn’t match the constant in 
the code, the frame is corrupt. It’s true that if you disable the FCS check 
that you “receive” more frames.  You will also see the corrupt ones.

(If you wonder why the FCS compares against a constant, you should have a look 
at the standard.)

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

Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate

[Bastian Bloessl]

Hi,


> On 8. May 2017, at 09:00, Thom L  wrote:
> 
> IIRC, it shows the autocorrelation of the signal. If you add a trigger to the 
> default plot (level ~0.56) you should see the characteristic plateau of the 
> short training sequence at the beginning of frames (this is used for frame 
> detection).
> 
> Ok that's right? But I don't understand very well the signification of the 
> “plateau”

The  characteristic plateau of the autocorrelation is used for frame detection 
by the Sync Short block. The plot can sometimes help to debug issues with it. 
For example, it can be used to
- roughly adjust the gain even if synchronization / decoding does not work 
(i.e. if there are no subcarrier constellations)
- often people experience a DC offset or LO leakage. In that case the 
autocorrelation is always high, which is directly visible in the plot.
- determine a threshold for frame detection
Also, I hoped, it might be helpful to better understand what the Sync Short 
block is locking for.

Best,
Bastian






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

Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate

[Bastian Bloessl]

> On 7. May 2017, at 21:27, Thom L <thomas.lavare...@gmail.com> wrote:
> 
> Hi Bastian,
> 
> Le 7 mai 2017 22:10, "Bastian Bloessl" <m...@bastibl.net> a écrit :
> 
> The red line is the complex component (which is around 0), while the blue 
> line shows the real part (which jumps between 1 and -1).
> 
> Yes but it jumps at sample rate 20M and not 6M? 

IEEE 802.11a/g always uses 20MHz channels independent from the modulation and 
coding scheme. So it will always be a signal with a 20MHz bandwidth.
If you encode data with BPSK and a coding rate of 1/2, the 20MHz signal will 
carry 6Mbit/s (bits per second, not bandwidth in frequency domain).

> What I would is to see the bit rate 

If you want to visualize the data throughput, I would recommend to parse the 
Wireshark output and calculate a moving average. But you won’t see the 6 
MBit/s. It’s only the PHY throughput, which you could only reach if you sent a 
single frame with infinite size.


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

Re: [Discuss-gnuradio] gr-ieee802-11 wifi signal bitrate

[Bastian Bloessl]

Hi Thomas,

> On 7. May 2017, at 09:21, Thom L  wrote:
> I added a time block sink and watched the signal in 6M mode (sampling rate is 
> 20M) but I can not interpret the result (cf attachment). Well I do not have 
> to look at the right place or the right way ..

I’m not sure what you are trying to visualise, but the equalizer outputs the 
data subcarriers. In the picture it shows BPSK, where the constellation points 
are around (-1, 0) and (1,0).
The time domain plot interprets the subcarriers as time series and visualises 
real and imaginary parts in a line plot. The red line is the complex component 
(which is around 0), while the blue line shows the real part (which jumps 
between 1 and -1).

> In fact I can not quite understand the graph in the time domain which is by 
> default in the module gr-ieee811 (magnitude)

IIRC, it shows the autocorrelation of the signal. If you add a trigger to the 
default plot (level ~0.56) you should see the characteristic plateau of the 
short training sequence at the beginning of frames (this is used for frame 
detection).

Best,
Bastian


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

Re: [Discuss-gnuradio] How to tell Flowgraph to Stop in Work()?

[Bastian Bloessl]

Hi,

maybe it's enough to return WORK_DONE (= -1) from work().

Best,
Bastian

On 04/29/2017 01:32 AM, Ghost Op wrote:
> I'm working on a module in C++ and when a condition happens I want my
> work function to signal to the flowgraph to stop.
> 
> I saw some references for python to self._top_block but does anyone
> have a suggestion on how to do it in C++?
> 
> Thanks!
> 
> ___
> 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] CMake error related to log4cpp in non-standard location

[Bastian Bloessl]

Hi,

are you talking about building in-tree modules or OOTs?

On 04/28/2017 11:13 PM, Michael Dickens wrote:
> Hi Eugene - What you write looks to be true about the current GR
> codebase. Bastian Bloessl has a commit that adds in LOG4CPP_INCLUDE_DIR
> & related to those in-tree areas that need it (branch "ugly_cmake"): <
> https://github.com/bastibl/gnuradio/commit/16d8e8cb9bd658991dabbc253c74850248b80f83
>> .  I don't know the best solution, but it seems like there's got to be
> a better way than manually including variables for logging as done right
> now. Cheers! - MLD

This branch was supposed to demonstrate what ugly cmake stuff we would
have to add if we don't add the includes of dependencies to a module's
exported includes.

To avoid this mess, we added LOG4CPP_INCLUDE_DIRS to
GNURADIO_RUNTIME_INCLUDE_DIRS, which should be added by all modules:

https://github.com/gnuradio/gnuradio/pull/1195/commits/51e565532f1f867baacc004222971fcf3703773b

That means the problem should be fixed for in-tree modules and the
ugly_cmake branch should be obsolete. If you have problems in-tree
please let me know which module doesn't compile.

A similar mechanism should, in my opinion, also be adopted for OOT
modules. Currently, GNURADIO_ALL_INCLUDE_DIRS (which is set by
find_package(gnuradio)) do not include the folders of its dependencies
(i.e., the headers references from the public includes, like log4cpp).

For that reason it is currently not possible to compile OOTs with
non-standard log4cpp location. You would have to patch the module (add
findlog4cpp.cmake and configure the patch appropriately).

See the discussion here:
https://github.com/gnuradio/gnuradio/issues/1045

Best,
Bastian

> 
> On Fri, Apr 28, 2017, at 02:46 PM, Eugene Grayver wrote:
>> The current GR CMakeFile(s) apparently do not add the include path 
>> LOG4CPP_INCLUDE_DIR to the compile.  Can't build w/ log4cpp in non-standard 
>> location.
> 
> ___
> 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] Sync short in gr-ieee802-11

[Bastian Bloessl]

Hi,

On 04/18/2017 04:34 PM, Nikita Airee wrote:
> Hi again, a few quick questions.
> 
> How do you decide on the values of MIN_GAP(480) and Max frame size(540*80)?

I chose MIN_GAP to correspond to the shortest possible frame.

MIN_GAP(480) = Preamble (320) + Signal field(80) + at least one data
symbol (80)


> 
> If during reception, one frame arrives within 480 samples of the other,
> say within preamble duration of the first, are the subsequent samples
> are copied anyway because the block is in copy state?

Then you have an interference situation. If one frame is much stronger
"Sync Long" will hopefully align reception with the stronger frame. (It
searchers for the maximum correlation with the known pattern of the long
preamble within a window of 320 symbols, IIRC.)

If the interfering frames arrives 320-480 samples delayed, it will just
interfere.

If it arrives more then 480 samples later and manages to raise the
autocorrelation coefficient high enough, Sync Short will mark the
beginning of a new frame and the receiver switches over to the new frame.

Best,
Bastian


> 
> Bests, 
> Nikita
> 
> On Apr 12, 2017 9:38 PM, "Bastian Bloessl" <m...@bastibl.net
> <mailto:m...@bastibl.net>> wrote:
> 
> Hi,
> 
> On 04/12/2017 03:49 PM, Nikita Airee wrote:
> > Oh yes it does! But how does MIN_GAP come into the picture? Is it the
> > minimum gap required between 2 frames for the second to be
> detected as well?
> 
> Yes. At the beginning of a a frame, the autocorrelation stays high for
> some time. This makes sure that frame detection is triggered only once
> per frame. It is the minimum number of samples between successive
> triggers.
> 
> 
> > Also if I'm not wrong the first frame is simply discarded when the one
> > coming after is detected because there seems to be no provision for
> > keeping the stronger frame and discarding the weaker one?
> 
> Currently, the receiver just switches to the new frame. You could add
> some more lines of code to make a better decision. Without adding much
> complexity you could use the power level to decide.
> Note that only because you hit these lines of code doesn't mean that
> frames actually interfered. At this stage the receiver doesn't know how
> long the frame is and just copies samples corresponding to a
> maximum-sized frame.
> 
> Best,
> Bastian
> 
> 
> >
> > On Apr 12, 2017 3:53 PM, "Marcus Müller" <marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>
> > <mailto:marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>>> wrote:
> >
> > Hi Nikita,
> >
> > I'll jump into the general_work method here, directly:
> >
> >
> >   switch(d_state) {
> >   case SEARCH: {
> >   int i;
> >   for(i = 0; i < ninput; i++) {
> >   if(in_cor[i] > d_threshold) {
> >   if(d_plateau < MIN_PLATEAU) {
> >   d_plateau++;
> >
> >   } else {
> >   d_state = COPY;
> > … break;
> >   }
> > … }
> >   consume_each(i);
> >   return 0;
> >   }
> >   case COPY: {
> >   int o = 0;
> >   while( o < ninput && o < noutput && d_copied <
> MAX_SAMPLES) {
> >   if(in_cor[o] > d_threshold) {
> >   if(d_plateau < MIN_PLATEAU) {
> >   d_plateau++;
> >
> >   // there's another frame
> >   } else if(d_copied > MIN_GAP) {
> >   d_copied = 0;
> >   d_plateau = 0;
> > … break;
> >   }
> > …
> >   out[o] = in[o] * exp(gr_complex(0,
> -d_freq_offset * d_copied));
> >   o++;
> >   d_copied++;
> >   }
> >
> >   if(d_copied == MAX_SAMPLES) {
> >   d_state = SEARCH;
&

Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Bastian Bloessl]

Hi,

On 04/15/2017 11:03 AM, Anshul Thakur wrote:
> Hi,
> 
> I have for now circumvented the problem. But I did try looking into the
> correlation values by logging the correlation after the divide block
> into a file and inspecting the values in Matlab.
> 
> Here are some statistics:
> 
> Contiguous samples considered:  4.096e8;
> # of samples with correlation > 0.7 : 2241
> # of samples with correlation in (0.6, 0.7]: 2405
> # of samples with correlation in (0.5, 0.6]: 14998
> 
> Threshold value considered in GNU RC block: 0.7
> 
> This was after removing all zero padding from delay block.


Not sure what you mean. The delay block does not do zero padding.


> 
> To get around the problem, I essentially used one of my SDRs as a dummy
> repeater that just picked all samples at one frequency and transmitted
> them at a different frequency. In this case, I was able to successfully
> receive a large number of PDUs and decode them in wireshark. This begs
> the question as to what I might be doing wrong with the original setup!
> Some more pointers I could look at?

Could you describe your current experiment again? I'm not sure what your
current problem is and what you are trying to work around.


> 
> Also, when I use the Loopback flowgraph with no packet padding, I am
> unable to receive any PDUs in wireshark. If I add some padding, they are
> detected. Is that expected behaviour?

You send frames back to back. When the frame detection algorithm sees
the second frame, it adds a tag to mark the beginning of a new frame.
With a high SNR, the autocorrelation rises fast and the tag might be
placed already in the preceding symbol. This could lead to the last OFDM
symbol of the preceding frame to be dropped.
However, since the frame detection algorithm doesn't know about the
length of the preceding frame and since that something that doesn't
happen in reality, I think it's not an issue. In simulations you could
just add some samples padding.

Best,
Bastian

> 
> I took some pointers from this
> thread 
> http://gnuradio.4.n7.nabble.com/gr-ieee802-11-receiver-td63486.html#a63508
> 
> On 30 March 2017 at 01:56, Bastian Bloessl <m...@bastibl.net
> <mailto:m...@bastibl.net>> wrote:
> 
> Hi,
> 
> On 03/29/2017 07:01 PM, Anshul Thakur wrote:
> >
> >
> > You could also test different RX/TX gains and parameters for the 
> padding
> > block (I don't have a BladeRF, so I have no experience). Also assert
> > that there are no overruns or underruns.
> >
> > I altered the values of gains and padding values (I increased the
> > padding values). That didn't seem to help.
> >
> 
> Actually, I was thinking of decreasing (or completely removing) it. Did
> you only try to increase it? Did you do anything else to debug? Like
> sending a stream of '0' and monitor the autocorrelation?
> 
> Best,
> Bastian
> 
> 

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

Re: [Discuss-gnuradio] gr_ieee-80211 receiver

[Bastian Bloessl]

Hi,

On 04/13/2017 12:20 PM, LiLi wrote:
> Hi,
> We couldn't capture anything when we put wireshark connector after 'decode
> MAC'. When debug was enable   of 'decode Mac', we found the packets were all
> dropped. We tried to read codes of decode MAC block. We got a question
>

My previous comment still applies. Really, these very last blocks in the
decoding chain aren't your problem. Please see the other email.

Best,
Bastian

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

Re: [Discuss-gnuradio] Sync short in gr-ieee802-11

[Bastian Bloessl]

Hi,

On 04/12/2017 03:49 PM, Nikita Airee wrote:
> Oh yes it does! But how does MIN_GAP come into the picture? Is it the
> minimum gap required between 2 frames for the second to be detected as well?

Yes. At the beginning of a a frame, the autocorrelation stays high for
some time. This makes sure that frame detection is triggered only once
per frame. It is the minimum number of samples between successive triggers.


> Also if I'm not wrong the first frame is simply discarded when the one
> coming after is detected because there seems to be no provision for
> keeping the stronger frame and discarding the weaker one?

Currently, the receiver just switches to the new frame. You could add
some more lines of code to make a better decision. Without adding much
complexity you could use the power level to decide.
Note that only because you hit these lines of code doesn't mean that
frames actually interfered. At this stage the receiver doesn't know how
long the frame is and just copies samples corresponding to a
maximum-sized frame.

Best,
Bastian


> 
> On Apr 12, 2017 3:53 PM, "Marcus Müller" <marcus.muel...@ettus.com
> <mailto:marcus.muel...@ettus.com>> wrote:
> 
> Hi Nikita,
> 
> I'll jump into the general_work method here, directly:
> 
> 
>   switch(d_state) {
>   case SEARCH: {
>   int i;
>   for(i = 0; i < ninput; i++) {
>   if(in_cor[i] > d_threshold) {
>   if(d_plateau < MIN_PLATEAU) {
>   d_plateau++;
> 
>   } else {
>   d_state = COPY;
> … break;
>   }
> … }
>   consume_each(i);
>   return 0;
>   }
>   case COPY: {
>   int o = 0;
>   while( o < ninput && o < noutput && d_copied < MAX_SAMPLES) {
>   if(in_cor[o] > d_threshold) {
>   if(d_plateau < MIN_PLATEAU) {
>   d_plateau++;
> 
>   // there's another frame
>   } else if(d_copied > MIN_GAP) {
>   d_copied = 0;
>   d_plateau = 0;
> … break;
>   }
> …
>   out[o] = in[o] * exp(gr_complex(0, -d_freq_offset * 
> d_copied));
>   o++;
>   d_copied++;
>   }
> 
>   if(d_copied == MAX_SAMPLES) {
>   d_state = SEARCH;
>   }
> …
>   consume_each(o);
>   return o;
>   }
>   }
> 
> So, this is a pretty classical state machine approach: at every call
> of general_work, the block is in either the COPY or the SEARCH
> state. We only care about whether COPY also does a search operation,
> and, lo:
> 
>   if(d_plateau < MIN_PLATEAU) {
>   d_plateau++;
> 
>   // there's another frame
>   } else if(d_copied > MIN_GAP) {
>   d_copied = 0;
>   d_plateau = 0;
> 
> is exactly that.
> 
> Best regards,
> Marcus
> 
> 
> On 12.04.2017 12:12, Nikita Airee wrote:
>> Hello everyone,
>>
>> I was trying to understand how the synchronization in
>> gr-ieee802-11 actually works and went through:
>>
>> Bastian Bloessl, Michele Segata, Christoph Sommer and Falko
>> Dressler, "An IEEE 802.11a/g/p OFDM Receiver for GNU Radio" 
>>
>> However, it seems that the Short Sync and many other blocks have
>> developed further since then.
>>
>> From what I understand, the current sync_short.cc does the following:
>>
>> 1) searches for the peak normalized correlator o/p and compares
>> with the set threshold
>> 2) as enough number of simultaneous peaks are detected in
>> correlator o/p, it moves onto the copy stage
>>
>> Here is where my doubt lies. Does the block keep looking for new
>> frames while the old one is being copied? Also, what is MIN_GAP's
>> function in the code and how is its value decided upon?
>>
>> Could you please clear up these doubts a little?
>>
>> Bests,
>> Nikita Airee
>>
>>
&g

Re: [Discuss-gnuradio] gr_ieee-80211 receiver

[Bastian Bloessl]

Hi,

LiLi  writes:

> Hi, everyone
>
> I am using gr-ieee-80211 to recieve wifi packets on 2.4G.
> The operating system is Ubuntu.The version of GNU RADIO is 3.7.5, and we use
> USRP N210 with SBX daughterboard.
> Our purpose:
> Capture packets of 802.11 protocol on 2.4G or the other band SBX
> daughterboard
> Our problems:
> When the Wireshark Connector was connected to 'WIFI Decode MAC', it can't
> receive any frame but an empty file. I want to figure out the cause, but it
> may consume a long time for a beginner. I think the main cause may exist in
> the 'WIFI Decode MAC' or the Wireshark Connector in the view that the latter
> can receive frames before the former.

I don't believe it's a problem with the Wireshark or 'Decode MAC'
block. It's more likely that something goes wrong earlier. This can have
a lot of reasons (gain setting, wrong sample rate, wrong channel,
overruns, ...). You might find something useful here:

https://www.wime-project.net/installation/

If you still have problems, it would be helpful if you could provide
some more details on what happens and what you did to debug. Something
like are frames detected? Are only frames detected or is frame detection
triggered all the time? Did you try the setup with other transceivers?
Does the constellation diagram look good, etc.

> Another tricky problem which I want to make clear is that whether the
> surroundings contains pure 802.11g frame. Could you show me the possible
> reasons? As I target to captured frames on 2.4GHz , how should the
> parameters of the Wireshark be recomposed?

There is nothing you can do in the receiver. You have to make sure that
the device that you want to monitor sends 11a/g/p frames. Others are at
the moment not supported.

How to configure the mode depends on your device. (If you open a network
with a MacBook it works for me. Maybe that could be a simple test.)

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee802_11 receiver

[Bastian Bloessl]

Hi,

On 04/09/2017 03:49 PM, serefay wrote:
> Hi, 
> 
> Thanks for your reply. I could not find out how can I solve it. But this
> problem comes only when I receive from a file source. Even tough  when send
> the IQ samples that I captured with Hackrf, which i saved in a file, it
> encounters the same problem.Is there any some blocks can be alternative to
> file source to send the samples to the receiver?


Sorry, but I still don't understand what you are trying to do. It would
be great it you could describe it a bit more detailed.

Anyhow, gr-ieee802-11 also has a transmitter. So why not just generate
frames, as opposed to replaying a noisy capture. If you are trying to
transmit a captured sample file from disk, the disk might be the bottle
neck. (A 20MHz signal is 160Mbyte/s).

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee802_11 receiver

[Bastian Bloessl]

Hi,

On 04/08/2017 02:32 PM, serefay wrote:
> Hello everyone,
> 
> I am using gr-ieee802_11 to regenerate wifi packets. I receive packets with
> HackRf and regenerate the same packet with transmitter and now I want to
> look whether they look the similar but  some packets are not received. I
> enabled MAC decode debug and it gives this error when it misses the packet.

I don't get that part...

> "
> Decode MAC: input 53
> Warning: starting to receive new frame before old frame was complete
> Already copied 27 out of 30 symbols of last frame
> "
> can anyone please help me  and give me some  idea what could result this
> error.? I would be grateful for any help.
> Thanks

This might happen if a frame is detected while another frame is already
received, i.e. the second frame interferes with the current frame. See
the hidden terminal problem for why this might happen.

(Another explanation might be that the receiver was initially sync on
noise and now switches to the real frame.)

Best,
Bastian



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

Re: [Discuss-gnuradio] Commercial Transmitters in IEEE 802.11 a/g/p Transceiver

[Bastian Bloessl]

Hi,

On 04/08/2017 07:31 AM, Ayan Chatterjee wrote:
> I have a small query regarding IEEE 802.11 a/g/p Transceiver:
> https://github.com/bastibl/gr-ieee802-11
> 
> Can any commercial device along with packet generator software be used
> as transmitters for this 802.11 receiver? If yes, what are some packet
> generators suggested for this purpose? If no, can you suggest
> modifications for allowing the set up to do so?

As the name suggests, any IEEE 802.11a/g/p device should be compatible
on the PHY. It doesn't care which packets you send. You also don't need
a special generator. It will, for example, receive beacons from an AP.

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee 802.11 and commercial AP (late ACK packets)

[Bastian Bloessl]

Hi,

On 04/03/2017 09:44 PM, sumitstop wrote:
> Hello Bastian, 
> 
> How much the delay between sensing the channel and sending the ACK should
> be. With X300 I was able to achieve a minm of 80 microsecs round trip time.
> Not less than that. 

Interesting. What exactly did you measure? I assume you used PCIe?

> 
> I am now sure that it cant be done on GPP, just wondering how fast it should
> be. If you can direct me to some link, that would be great :) 

The timing constraints are given in the standard (They depend on the
mode, but they are below 80us).

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Bastian Bloessl]

Hi,

On 03/29/2017 07:01 PM, Anshul Thakur wrote:
>
> 
> You could also test different RX/TX gains and parameters for the padding
> block (I don't have a BladeRF, so I have no experience). Also assert
> that there are no overruns or underruns.
> 
> I altered the values of gains and padding values (I increased the
> padding values). That didn't seem to help.
>  

Actually, I was thinking of decreasing (or completely removing) it. Did
you only try to increase it? Did you do anything else to debug? Like
sending a stream of '0' and monitor the autocorrelation?

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee 802.11 and commercial AP (late ACK packets)

[Bastian Bloessl]

Hi,

On 03/29/2017 01:11 PM, sumitstop wrote:
> Hi, 
> 
> With gr-ieee 802.11, I know that SIFS cannot be respected becz of USB delays
> (B210), but what we can also try is that : sending ACK packet before all the
> layer-2 retries are exhausted ! Instead of sending ACK withing 10 microsecs. 
> 
> In this way, the throughput will be down for sure but the device can
> communicate with a commercial 802.11 AP. 
> 
> I was wondering if anyone tried like this and I can get some heads up. 
> 

It's not only about sending fast enough, but mainly about sending at the
right point in time (i.e. immediately after a frame). Since the SDR
doesn't do channel sensing on the FPGA, this is at least not
straightforward.

Best,
Bastian

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

Re: [Discuss-gnuradio] gr-ieee 802.11 transceiver, Trouble with the received packets

[Bastian Bloessl]

Hi,

please keep the conversation on the list.

On 03/29/2017 05:43 AM, Cristian Rodríguez wrote:
> It is very bad. I was trying and trying these days and i can't receive
> all the samples. What do you think, is a enough processor frequency so i
> can get the samples?. In this moment i have a core I5-6200U and 12Gb RAM.
> 
> I'm very worried about it, because i did a lot of proofs, even an
> overclocking and it didn't work. Then i think i'll have to get other
> processor.

I doubt that CPU performance is your actual problem. I would recommend
to make sure that frame detection is working. You might just have a DC
offset and the receiver triggers frame detection all the time. This
would overload any PC.

If everything works as it is supposed to and the PC is really to slow,
see for some tips here:
https://www.wime-project.net/installation/

If you ran volk_profile and really nothing works, only then I would try
another PC.

Best,
Bastian



> 
> What can you advice me?.
> 
> Thanks in advance.
> 
> Best regards,
> 
> Cristian
> 
> 2017-03-27 0:00 GMT-05:00 Bastian Bloessl <m...@bastibl.net
> <mailto:m...@bastibl.net>>:
> 
> Hi,
> 
> On 03/26/2017 09:44 PM, Cristian Rodríguez wrote:
> > When it started i do:
> >
> > 1. In the flowgraph I'm in the freq 178 | 5.89 Mhz | 11p with sample
> > rate=10MHz
> > . It is shown in the terminal
> 
> You should use Wireshark (on both sides) to check whether the frames
> look as expected. From the ASCII debug output it is hard to tell what
> kind of frame that is.
> 
> Also the 'O's indicate that the PC cannot keep up with the sample stream
> and drops packets.
> 
> 
> >
> > 2. I open another terminal and i try to do a ssh port and i receive it
> > (in the second terminal):
> 
> I assume the other side of the connection is a PC with a normal WiFi
> card. Make sure to adapt the ARP entries to match the MAC of the card.
> The WiFi card also needs static ARP entries for the SDR.
> 
> 
> > NOTES:
> > It is courious that i get  when the transceiver is not receiving
> > anything.
> 
> This means your PC is not fast enough to process the incoming samples.
> Either it is too slow, or frame detection is triggered too often due to
> a DC offset, for example.
> 
> 
> 
> Best,
> Bastian
> 
> 

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

Re: [Discuss-gnuradio] gr-ieee802_11 not able to send or receive packets.

[Bastian Bloessl]

Hi,

On 03/28/2017 06:43 PM, Anshul Thakur wrote:
> With this, two parts work independently: 
> - I am able to Rx packets from Wifi using wifi_rx.py (however, it works
> best only when I use it from the shell script provided. That is strange!).
> - I am able to Tx packets from SDR which are detected by a Wifi card in
> monitor mode.

Great.

> 
> However, When one SDR transmits and the other is receiving, I am not
> able to receive the packets sent by the SDR. 
> - I tried it using wifi_rx shell script on one, and wifi_tx.py on the
> other. PDUs from other Wifi Devices are detected.
> - I also tried putting a direct line between the Tx of one SDR to Rx of
> the other. Still no reception.

I think you should try to find out where things go wrong. Are frames
detected? Is frame detection triggered all the time? Does the receiver
sync on the frames (i.e., looks the constellation diagram somehow OK)?
etc., etc.

Maybe the BladeRF also has some calibration routines for TX DC offset
(which, I think, could make things worse for the receiver with line of
sight).

You could also test different RX/TX gains and parameters for the padding
block (I don't have a BladeRF, so I have no experience). Also assert
that there are no overruns or underruns.

Best,
Bastian


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