Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

Please, stay on the list.

On 04 Oct 2014, at 18:20, Ernest Szczepaniak  wrote:

> Hi,
> 
> we are talking about 'frame.bin' signal right?

yes

> Becouse my decoder says:
> 
> Service: 'ok'
> Protocol_version: 'Supported'
> Type: 'Menagement'
> Subtype: 'Probe Request'
> To_DS: 'True'
> From_DS: 'False'
> More_fragments: 'No'
> Power_menagement: 'Power-Saving Mode'
> More_data: 'No'
> Protected: 'No'
> Order: 'Random'
> 
> and the initial state was 0b0101011. Furthermore, i cant see those "1", which 
> will indicate the broadcast adress thou:( So i think it is not working 
> correctly yet.

If you are still not convinced, you can very easily send the frame with a USRP 
and receive it with a WiFi card to inspect the MAC header with Wireshark. You 
can either use a simple GNU Radio flow graph (file source -> USRP sink) or use 
the tx_samples_from_file example that ships with UHD. At least my card agreed 
with my interpretation of the payload :-)

Best,
Bastian

> 
> W dniu 2014-10-04 19:56, Bastian Bloessl pisze:
>> Hi,
>> 
>> On 04 Oct 2014, at 15:50, Ernest Szczepaniak  
>> wrote:
>> 
>>> Hello,
>>> 
>>> First of all, much love for your reply (it made my day).
>>> 
>>> So i started with sent frame [2]. And my receiver gives some nice results:
>>> 
>>> - found OFDM symbol
>>> - aquired time synchronization
>>> - Shmidl/Cox says that there is no frequency offset (so it is good for no 
>>> noise frame)
>>> - SIGNAL field is modulated with BPSK 6 Mbps (correct) and it says that:
>>>- rest of the data is modulated with BPSK 6Mbps
>>>- coderate is 1/2
>>>- 1 bit per carrier
>>>- 364 octets of data (is that correct?)
>>>- reserved field, parity bit and tail bits seems to be fine.
>>> 
>>> Further MAC decoding says that:
>>> - descrambler initial state is [0 1 0 1 0 1 1] (correct?)
>>> - 16 zeros in SERVICE field (7 for desrcambler synchro and 9 reserved - 
>>> seems to be correct)
>>> - according to standard this is a PNC Selection (PNCS) frame type with 
>>> retry ([0 0 0 1] in frame type field) is that correct?
>> 
>> my decoder says:
>> 
>> new mac frame  (length 360)
>> =
>> duration: 00 00
>> frame control: 00 08 (DATA)
>> Subtype: Data
>> seq nr: 0
>> mac 1: ff:ff:ff:ff:ff:ff
>> mac 2: 23:23:23:23:23:23
>> mac 3: ff:ff:ff:ff:ff:ff
>> Hello World!Hello World!Hello World!Hello World!Hello World!Hello 
>> World!Hello World!Hello World!Hello World!Hello World!Hello World!Hello 
>> World!Hello World!Hello World!Hello World!Hello World!Hello World!Hello 
>> World!Hello World!Hello World!Hello World!Hello World!Hello World!Hello 
>> World!Hello World!Hello World!Hello World!Hello World!
>> 
>> It does not contain a LLC, just a MAC header. It is BPSK 1/2 encoded. I 
>> guess the initial scrambler state was 0b0101010 (=42) and it is a data frame.
>> 
>> Best,
>> Bastian
>> 
>> 
>>> Best,
>>> 
>>> Ernest
>>> 
>>> 
>>> 
>>> W dniu 2014-10-04 11:16, Bastian Bloessl pisze:
 Hi,
 
 you can use gr-ieee802-11 [1] to generate WiFi frames. Just start the TX 
 flow graph and pipe the output to a file.
 I uploaded a frame (IQ data, no noise) [2] for you that you can use to get 
 started.
 
 I don’t use Matlab, so i don’t know how to import the data, but you can 
 display the IQ samples with
 
 od -fw8 frame.bin
 
 There is also a GNU Radio script [3] that might be helpful.
 
 Hope it helps,
 Bastian
 
 
 [1] https://github.com/bastibl/gr-ieee802-11
 [2] https://www.ccs-labs.org/~bloessl/frame.bin
 [3] 
 https://github.com/gnuradio/gnuradio/blob/master/gr-utils/octave/read_complex_binary.m
 
 
 
 On 02 Oct 2014, at 17:25, Ernest Szczepaniak  
 wrote:
 
> Greetings engi's!
> 
> I'm currently working on my masters (802.11 wlan receiver with
> MATLAB/USRPN210). After creating all the important stuff ie:
> 
> -symbol finder
> -time synchronization
> -coarse and fine frequency compensation
> -symbol demodulator
> -deinterleaver
> -Viterbi decoder
> -descrambler etc.
> -MAC layer decoding
> 
> i'm looking for any tested 802.11 a/g IQ signal for further research
> becouse live samples captured by USRP seem to have incorrect result's
> (wrong frame type MAC field, random MAC adress, CRC, parity bits etc).
> 
> And here comes my 1st question.
> 
> Is there any place where i can get some real, tested IQ wlan signal i
> a/g standard and full description (rate, coded data, adresses, included
> MAC fields)? Tried with Agilent Signal Studio but files are saved in
> .wfm encrypted format :(
> 
> I also found GRC beacon frames transmitter, written in GRC
> 
> http://rrsg.ee.uct.ac.za/members/jwamicha/gr-wlan.tar.gz
> 
> but due to having GRC 3.7 (where 'gnuradio-core' was repleaced with
> 'gnurdaio-runtime') i can't simply compile this file becouse of 

Re: [Discuss-gnuradio] Bypass work function

[bob wole]

Well, in my case the tx/rx would not be stationary, so the channel is not
quite.

--
Bob



> If you can tolerate the stream stopping, use Power Squelch. Otherwise,
> time to dive in and follow Tom's advice from May - disable the CMA taps
> update loop when there's no signal. This whole idea assumes you have a
> mostly quiet channel, stationary tx/rx, etc. Interested to hear what you
> come up with.
>
> - Jeff
>
> On 10/01/2014 11:24 PM, bob wole wrote:
> > I applied this and this is useful in condition when you do not want to
> > process noise, because it is being multiplied by zero when there is no
> > signal. But I want that CMA taps remain unchanged when there is no
> > signal or just noise. In the above scenario CMA taps change due to
> > presence of noise, because it tries to equalize noise as well.  Thanks
> > for your comment.
> >
> > --
> > Bob
> >
> > On Mon, Sep 29, 2014 at 7:19 PM, Jeff Long  > > wrote:
> >
> > Try using a "threshold" off the "mag squared" and feed that into a
> > multiplier after block2 (with appropriate type adapters). As long as
> > block2 doesn't have a huge delay or do rate changes, this should
> work.
> >
> > - Jeff
> >
> > On 09/29/2014 10:23 AM, bob wole wrote:
> > > Hi thanks for your comment. block2 is the gnuradio "CMA equalizer
> > > block". I want the CMA block to remain quiet when there is no
> signal of
> > > interest.
> > >
> > > Bob
> > >
> > >
> > > Bob,
> > >
> > > Saw this the other day, but there isn't a lot to go on here.
> If block2
> > > is your own, you can make it do the bypass. You can also use
> some of the
> > > logic blocks and a multiplier depending on what you're doing.
> There
> > > isn't really a concept of on-the-fly switching in GNU Radio.
> > >
> > > - Jeff
> > >
> > > On 09/26/2014 01:02 PM, bob wole wrote:
> > >  >
> > >  > People, any ideas on it?
> > >  >
> > >  > --
> > >  > Bob
> > >  >
> > >  > On Wed, Sep 24, 2014 at 12:04 PM, bob wole <
> bnw...@gmail.com 
> > > >
> >  >  > 
> >  >  >  >
> >  >  >   I have following flowgraph:
> >  >  >
> >  >  >
> >  >  >
> >   usrp_source--->>probe_mag_squared_block>block2--->block3
> >  >  >
> >  >  > What I want to do is that I want to bypass the "work"
> > function of
> >  >  > block2 when the threshold level of probe_mag_squared
> > reaches.
> >  > I do
> >  >  > not want to stop(), lock(), disconnect the flow graph.
> > Is this
> >  >  > possible using stream tags, or message passing etc ?
> > Any example
> >  >  > code would be nice.
> >  >  >
> >  >  > --
> >  >  > Bob
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc

[Gisle Vanem]

Since my previous message seems to be ignored, here is something 
simpler for you to comment on.


In gr-blocks/lib/stream_pdu_base.cc, the read() and write() functions are 
used on sockets. This doesn't work well on Windows as you're probably 
aware. A simple fix is to has something like this at the top of this file:


#ifdef WIN32
 #undef read
 #undef write
 #define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0)
 #define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0)
#endif

I'm sure Boost have some better fix for this, but I don't know
Boost.

--gv


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

Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal

[Ernest Szczepaniak]

Greetings,

Ok, got this. After some test's i think that the problem is with my
descrambler (de-interleaver and Viterbi seems to be ok). Currently, im using
Matlab's one provided by comm. toolbox. 

Is it correct to use 127-bit length pre-defined scrambling/descrambling seq?
(i found it in 802.11 standard). Or it sould be only implemented as a shift
register with poly 1+x4+x7?

And last one question:

In any of frames generated by your grc script, there sould be 16x"0" in
SERVICE field (as it a part of PLCP Header) - becouse a typical wlan card is
able to decode it, it is following the 802.11 standard - am I right?

Best,
Ernest



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/GRC-3-6-802-11-a-g-test-signal-tp50585p50614.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] TVRX2 and GRC

[Daniel Marlow]

On Oct 4, 2014, at 6:39 PM, Marcus D. Leech wrote:

>> 
>> On Oct 3, 2014, at 7:30 PM, Marcus D. Leech wrote:
>> 
>>> If you put your flow-graph itself (.grc file) somewhere, or attach it, we 
>>> can take a better look.
>>> 
>>> What kind of comptuer?  (OS, CPU/MEM specifics, etc).
>>> 
>>> 
>>> 
>>> -- 
>>> Marcus Leech
>>> Principal Investigator
>>> Shirleys Bay Radio Astronomy Consortium
>>> http://www.sbrac.org
>> 
>> Hi Marcus,
>> 
>> Thanks.   The .grc file is attached.  Other details:   
>> 
>> o Intel(R) Core(TM)2 Duo CPU E8400  @ 3.00GHz
>> o Memory 3GB
>> o OS 14.1 Ubuntu
>> 
>> Cheers,
>> Dan
>> 
>> 
>> 
> I've attached updates to your graph that should make it behave more 
> rationally:
> 
> 2Msps sample rate -- consistent with your programmed 1.7MHz analog bandwidth
> Deleted antenna spec in source block--it contained invalid specification
> Made the device address spec valid
> Moved things into user-changable variables:  freq and gain
> Made both source and FFT use the "samp_rate" variable, so changing that 
> variable will change both source and FFT sink
> Made FFT sink turn on averaging, and use "freq" variable to set center 
> frequency
> 
> I'd suggest looking it over carefully, and comparing against what you 
> originally had.
> 
> 
> 
> -- 
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
> 

Hi Marcus,

 Many thanks.   We will give that a try.

Cheers,
Dan


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

Re: [Discuss-gnuradio] Win32 and gr-blocks/lib/stream_pdu_base.cc

[Josh Blum]

On 10/05/2014 04:25 AM, Gisle Vanem wrote:
> Since my previous message seems to be ignored, here is something simpler
> for you to comment on.
> 
> In gr-blocks/lib/stream_pdu_base.cc, the read() and write() functions
> are used on sockets. This doesn't work well on Windows as you're
> probably aware. A simple fix is to has something like this at the top of
> this file:
> 
> #ifdef WIN32
>  #undef read
>  #undef write
>  #define read(sk,buf,len) ::recv (sk, (char*)(buf), len, 0)
>  #define write(sk,buf,len) ::send (sk, (const char*)(buf), len, 0)
> #endif
> 
> I'm sure Boost have some better fix for this, but I don't know
> Boost.

The issue is that the stream_pdu_base file descriptor is both a network
socket for socket_pdu and tuntap handle for tuntap_pdu. Calling ::recv()
and ::send() would be a good cross platform solution for the socket
case, but im not sure if that will work for the tuntap (which is linux
specific anyway).

Ideally we could switch the code to call send/recv, and the tuntap would
continue working -- this needs testing.

Your patch is pretty good too, because it doesnt interfere with existing
functionality, and the tuntap is ifdefed out on windows.

The best way to upstream patches seems to be through github. I recommend
creating a github pull request for this change, and some of the other
changes you mentioned in the previous email.

-josh

> 
> --gv
> 
> 
> ___
> 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] GRC 3.6 / 802.11 a/g test signal

[Bastian Bloessl]

On 10/05/2014 01:37 PM, Ernest Szczepaniak wrote:

Greetings,

Ok, got this. After some test's i think that the problem is with my
descrambler (de-interleaver and Viterbi seems to be ok). Currently, im using
Matlab's one provided by comm. toolbox.

Is it correct to use 127-bit length pre-defined scrambling/descrambling seq?


No, this is an example output if you initialize the scrambler with 
0b111.



(i found it in 802.11 standard). Or it sould be only implemented as a shift
register with poly 1+x4+x7?


yes.



And last one question:

In any of frames generated by your grc script, there sould be 16x"0" in
SERVICE field (as it a part of PLCP Header)


yes.



- becouse a typical wlan card is
able to decode it, it is following the 802.11 standard - am I right?


No. It's following the standard and, thus, a normal card can decode it :-)

Best,
Bastian

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

Re: [Discuss-gnuradio] TVRX2 and GRC

[Martin Braun]

On 10/03/2014 11:23 PM, Daniel Marlow wrote:
>  As the second attached screen shot shows, however, the system does
> not run properly, producing a string of "D's", with the FFT window
> going dark.   The warning that reads "Sensor 'lo_locked' failed to lock
> within timeout on channel 0" seems like it might be related.

On top of what Jeff + Marcus have said, that warning was a result of an
over-zealous checking, which is removed in the latest version.

Cheers,
M


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

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[Martin Braun]

On 10/03/2014 12:44 AM, George Nychis wrote:
> Marcus,  I like the idea of an uber-repo with external submodules.  That
> would mean these submodules could link to a repo we could provide the
> user, a repo they already have on github, or a repo they have on some
> other external server.  But in the end, our uber repo would point to all
> of them and then they could update the commit that external submodule
> points to over time.  Thanks for that suggestion.

Sorry for being a buzzkill here,

but I don't really like this except as a temporary/transition solution.
Assume CGRAN really takes off and grows. Do you really want all OOTs out
there in a single repo? What exactly is their logical connection, which
would warrant them all being tied together in a super-repo?
This would require someone to keep updating the submodules, too, which
seems unnecessary.

In the long run, I would assume people want to host their OOTs on github
(or similar services), and CGRAN would simply be a link to those.
As I said, during a transition time, we might want something else.
But submodules are messy, and I suggest not using them for this
particular application.

M


> Rick, thanks for this suggestion also!  I will make sure that we are
> able to include some sort of snapshot.  When you say snapshot here, does
> that act as some sort of release or history?  It must be different than
> a tag, since you say tags are part of a snapshot.  Can you give me an
> example snapshot provided by some other service?
> 
> On Thu, Oct 2, 2014 at 7:51 AM, Marcus Müller  > wrote:
> 
> Hi everyone,
> 
> that seems to be a nice solution you're proposing, George. What
> about having a uber-repo that uses external submodules? This way,
> you could have your single CGRAN repo, with all the packages as
> submodules, some documentation in a single wiki, all per gitlab, and
> just keep the projects as independent repos, hosted on a cgran
> machine or on github/osmocom/wherever. We get the functionality to
> backup "all the GNU Radio ecosystem" at once by running some git
> submodule update command, and pybombs could just clone that repo,
> and init submodules as the user installs them.
> 
> Greetings,
> Marcus
> 
> 
> On 30.09.2014 01:00, George Nychis wrote:
>> I agree with Martin that once we go to git, every project has its own
>> independent repo.  That shouldn't take much time at all to do, I can just
>> run some svn2git magic to spit out separate repositories.  The question
>> will be where those repositories live.  I can host the repositories 
>> again.
>> I could replace the tired Trac interface with Gitlab and then host the
>> repositories locally and through there.  If that's the case, Github
>> repositories could be forked in Gitlab and/or point to the Github repos?
>> (e.g., for people who only want their code on Github).  I think the
>> downside of Gitlab is that it doesn't seem to be very customizable to, 
>> for
>> example, have a coherent single Wiki of some sort like Trac dd.  It will 
>> be
>> a bunch of separate Wikis buried in to each separate repository's page.
>>
>> So I think we are agreeing so far on git with multiple repositories for
>> each project.  What we need to figure out is what the frontend is.
>>
>> On Mon, Sep 29, 2014 at 3:47 PM, Martin Braun  
>> 
>> wrote:
>>
>>> On 29.09.2014 14:55, Marcus D. Leech wrote:
>>>
 I have no religious convictions about git vs svn.

 I'd have to change a couple of scripts [...]

>>> When CGRAN was inaugurated, github wasn't as popular as it was (and GNU
>>> Radio was still on SVN itself). We would not have gone for a central SVN
>>> repo if github had been on our radar back then.
>>>
>>> I guess most people either share Marcus' sentiment, or are biased 
>>> towards
>>> git. So, ditching SVN is pretty much a no-brainer.
>>>
>>> However, one major difference between SVN and git is that the latter
>>> doesn't have the concept of every dir being a repo in and of itself.
>>> This means if we simply pushed everything to a giant github repo, that
>>> would not be terribly useful (definitely not a replacement for CGRAN),
>>> although I can see that being a temp solution so that at the very least,
>>> nothing is lost (a big advantage of using github is that they're less
>>> likely to lose data).
>>>
>>> Really, every CGRAN project should be pulled into it's own little repo,
>>> e.g. on github. Migrating from SVN to git is really easy (even with
>>> preserving history and all). I guess we could put up instructions on 
>>> how to
>>> do that if there's popular demand.
>>>
>>> However, there's also the wiki pages on CGRAN. We do need a strategy for
>>> those (and a way to access them).
>>>
>>> Keep the ideas and comments c

Re: [Discuss-gnuradio] CGRAN down indefinitely, but hopefully not for long (want feedback)

[Bastian Bloessl]

On 10/06/2014 08:21 AM, Martin Braun wrote:

but I don't really like this except as a temporary/transition solution.
Assume CGRAN really takes off and grows. Do you really want all OOTs out
there in a single repo? What exactly is their logical connection, which
would warrant them all being tied together in a super-repo?
This would require someone to keep updating the submodules, too, which
seems unnecessary.





In the long run, I would assume people want to host their OOTs on github
(or similar services), and CGRAN would simply be a link to those.
As I said, during a transition time, we might want something else.
But submodules are messy, and I suggest not using them for this
particular application.


Since, git 1.8.2 a git submodule can track a branch [1] (as opposed to 
pointing to a commit). That means that it is not necessary to update the 
submodules in the super-repo. A submodule is very similar to a pybombs 
recipe, a link to a repo and a branch.
Most likely most of the repos (i.e. GNU Radio apps/modules) will be 
hosted at github or similar services. So nothing would change for the 
authors of the modules. (That's at least my understanding of the 
proposed solution)



Best,
Bastian


[1] 
https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186



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