Re: [Discuss-gnuradio] GRC 3.6 / 802.11 a/g test signal
Please, stay on the list. On 04 Oct 2014, at 18:20, Ernest Szczepaniak ernest_szczepan...@wp.pl 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 ernest_szczepan...@wp.pl 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 ernest_szczepan...@wp.pl 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 an error: --- checking for GNURADIO_CORE... configure: error: Package requirements (gnuradio-core = 3) were not met: No package 'gnuradio-core' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively,
Re: [Discuss-gnuradio] Bypass work function
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 willco...@gmail.com mailto:willco...@gmail.com 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 mailto:bnw...@gmail.com mailto:bnw...@gmail.com mailto:bnw...@gmail.com mailto:bnw...@gmail.com mailto:bnw...@gmail.com mailto:bnw...@gmail.com mailto:bnw...@gmail.com wrote: I have following flowgraph: usrp_source---probe_mag_squared_blockblock2---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
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
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 16x0 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
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 TVRX2.grc 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
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
