Re: [Discuss-gnuradio] tx_ofdm.grc & rx_ofdm.grc output data

[Martin Braun (CEL)]

On Wed, Oct 23, 2013 at 06:19:00PM -0700, eontool wrote:
> Has anyone  tested successfully these two files combined?
> 
> The input data or vector source is an array of 96 elements [0-95] but I'm
> getting a strange output at the end.
> 
> The 96 + 4 elements from the crc, then another 100 values (200 total), then
> the sequence repeats.

Hi eontool,

did you change any of the other settings, or use the defaults?

The data you're seeing is *after* the CRC?

> I tried using the OFDM transmitter and receiver blocks and they work
> perfectly, same input as ouput.
> 
> I began tracing the problem comparing the same log debug output files and it
> seems the "Header/Payload Demux" is causing some issues.

Which issues are these?
Can you check the payload output of the HPD. It contains two tags: The
length of the packet in bytes (==100 in your case) (key: len_tag_key)
and the number of OFDM symbols (depends on your config, key is
frame_len_tag_key). Are these correct?

If yes, can you confirm that the stream tags were correct at the
transmitter? Can you post the argument for the vector_source?

MB

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpN5l_vPlm79.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Zigbee

[Dan Aldrich]

I'm looking for a packet sniffer for zigbee. Is there a sample of how to do 
this with a RTL? The one I found on google used a FPGA.

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

Re: [Discuss-gnuradio] Zigbee

[Bastian Bloessl]

Hi,

there is an O-QPSK [1] phy that might be a starting point. Since you 
have a RTL dongle, I guess you plan to use the 800 or 900 MHz band. IIRC 
the chip sequences are slightly different there.


Best,
Bastian

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

On 2013-10-24 12:47, Dan Aldrich wrote:

I'm looking for a packet sniffer for zigbee. Is there a sample of how to do 
this with a RTL? The one I found on google used a FPGA.

Thanks,
-d
___
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] GnuRadio in particle accelerators

[Aylons Hazzud]

2013/10/23 M Dammer :
> I have no answer here. But talking about Gnuradio and nuclear physics I
> want to add my idea to your question:
> Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer
> ? These spectrometers usually work with a multichannel analyzer that
> measures the pulse height coming from the detector and then sorting the
> heights into bins. This is similar to the histogram GUI element found in
> GRC, but the counting is accumulative until a timer or manual
> interaction stops it. The big difference between SDR use and nuclear
> instrumentation is that while SDR mainly works with a constant stream of
> data the latter mainly deals with transient pulses.

Interesting.

But, is GnuRadio needed for it? The pulse height coming from the
detector is a pulsed high-frequency signal, or just a width-modulated
square wave?

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

Re: [Discuss-gnuradio] GnuRadio in particle accelerators

[Vanush Vaswani]

OT but has anyone used GNURadio for music production?

On Thu, Oct 24, 2013 at 10:54 PM, Aylons Hazzud  wrote:
> 2013/10/23 M Dammer :
>> I have no answer here. But talking about Gnuradio and nuclear physics I
>> want to add my idea to your question:
>> Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer
>> ? These spectrometers usually work with a multichannel analyzer that
>> measures the pulse height coming from the detector and then sorting the
>> heights into bins. This is similar to the histogram GUI element found in
>> GRC, but the counting is accumulative until a timer or manual
>> interaction stops it. The big difference between SDR use and nuclear
>> instrumentation is that while SDR mainly works with a constant stream of
>> data the latter mainly deals with transient pulses.
>
> Interesting.
>
> But, is GnuRadio needed for it? The pulse height coming from the
> detector is a pulsed high-frequency signal, or just a width-modulated
> square wave?
>
> ___
> 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] GnuRadio in particle accelerators

[M Dammer]

I thought about other options for signal analysis (KST for example). My
initial idea was in absence of a scintillation counter system to use a
(simple) PIN diode like the widely used BPW34 photodiode as detector.
There is some material about this on the web. Then put some amplifier
behind it and do the data acquisition with a DC to HF (direct sample)
modded RTL-SDR dongle. The interesting parameter in this case would be
the pulse height.

On 24/10/13 12:54, Aylons Hazzud wrote:
> 2013/10/23 M Dammer :
>> I have no answer here. But talking about Gnuradio and nuclear physics I
>> want to add my idea to your question:
>> Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer
>> ? These spectrometers usually work with a multichannel analyzer that
>> measures the pulse height coming from the detector and then sorting the
>> heights into bins. This is similar to the histogram GUI element found in
>> GRC, but the counting is accumulative until a timer or manual
>> interaction stops it. The big difference between SDR use and nuclear
>> instrumentation is that while SDR mainly works with a constant stream of
>> data the latter mainly deals with transient pulses.
> Interesting.
>
> But, is GnuRadio needed for it? The pulse height coming from the
> detector is a pulsed high-frequency signal, or just a width-modulated
> square wave?




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

Re: [Discuss-gnuradio] Missing File?

[Tom Rondeau]

On Wed, Oct 23, 2013 at 8:19 PM, Paul B. Huter  wrote:
> Running my script, I get an error (repeated twice):
>
> ~\AppData\Roaming\.gnuradio\prefs\vmcircbuf_default_factory: Invalid
> argument
>
> I looked, and there is no 'vmcircbuf_default_factory' in the \prefs folder
> (there isn't anything in there). The Internet (GNURadio website and GNURado
> mailing list archives in addition to general Internet searches) provides
> plenty of examples of 'vmcircbuf_sysv_shm, where the user is told to update
> the 'vmcircbuf_default_factory' file, but nothing relating directly to my
> problem.
>
> Is this a file that should have been created when I installed GNURadio and
> its dependencies? Can I just create the file, and, if so, what does the
> structure/format look like? Or, can someone point me to either a sample
> file, or the file location somewhere else?
>
> Thank you.

This file is created the first time you try to run GNU Radio, so not
during build or even install. It /will/ get created when you run 'make
test' or any other GNU Radio application.

Is this on Windows? I'm honestly not sure what the right factory
function is for Windows, but my guess is this file should contain:

gr::vmcircbuf_createfilemapping_factory

Note that that's just one line, no carriage return or anything else.

Tom

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

Re: [Discuss-gnuradio] forecast and set history function for haar decomposition

[Tom Rondeau]

On Wed, Oct 23, 2013 at 1:33 PM, Bharat Mukkala
 wrote:
> its true that setting the history to length of coefficients work, but when we
> go for more than 1 level of decomposition, the output from previous level
> will be used , so how can is use the output again ?

Seems to me like you'll need to keep that state inside the object.

> i have another doubt , if we set the size of each element in the input
> signature to be 4*sizeof(float) and size of each output element to be
> 4*sizeof(float)  in a gr::sync_block, then in the work function , how each
> element will be handled, (is it like 4 input items of size float), also
> please tell me how to use them.
> thank you

Look at some of the other blocks where a vector length is specified.
gr-blocks/lib/float_to_short_impl.cc might be a good one to look at.
The vlen used here means that each item is of size vlen times the size
of a float (on the input stream). If vlen=4, each item is composed of
4 floats. So if 'float *in = (float*)input_items[0]', then it has a
length of ninput_items[0]*4. You can index the array from 0 to
(ninput_items[0]*4 - 1).

Tom

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

[Discuss-gnuradio] GOES LRIT???

[Raydel Abreu (CM2ESP)]

Hello,

Is there any GOES LRIT decoder available under Linux and GNU Radio with
support for USRP or RTL-SDR. In case there is only USRP compatibility,
perhaps with the GRC file freely available it can be attempted to be
converted for RTL-SDR?

I have found some tools but only for POES HRPT...

Thanks,

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

Re: [Discuss-gnuradio] GnuRadio in particle accelerators

[Michael Okun]

Hi Mark and Aylons,

I've also wondered whether a cheap RTL-SDR could be used with GnuRadio
as a multichannel analyzer for a homemade Gamma Spectrometer, either
using a Geiger tube or a scintillator.  I think the tuner would need
to be bypassed so that the sampler can get direct samples.  There's
info on a direct sampling mod here:
http://www.rtl-sdr.com/rtl-sdr-direct-sampling-mode/

I've also been curious about using GnuRadio for analysis of other high
bandwidth signals, for example from magnetic field detectors such as a
GMR sensor.

Definitely let us all know if you try this out or come up with other
interesting non-radio instrumentation applications.   There are so
many interesting possibilities!

Cheers,
Michael


> Hi Aylons,
> I have no answer here. But talking about Gnuradio and nuclear physics I
> want to add my idea to your question:
> Would it be possible to use Gnuradio in a (home made) Gamma Spectrometer
> ? These spectrometers usually work with a multichannel analyzer that
> measures the pulse height coming from the detector and then sorting the
> heights into bins. This is similar to the histogram GUI element found in
> GRC, but the counting is accumulative until a timer or manual
> interaction stops it. The big difference between SDR use and nuclear
> instrumentation is that while SDR mainly works with a constant stream of
> data the latter mainly deals with transient pulses.
>
> Mark
 On 23/10/13 17:14, Aylons Hazzud wrote:
> > Hi, people. Anyone here has experience using Gnuradio or USRP as an
> > instrumentation tool (I mean, not for actual radio transmissions)?
> >
> > After years studying, hobbying and working with SDR, I've just learned
> > that they are very similar to particle acceleator instrumentation, in
> > a very pleasant way: I was just hired to work on one, precisely
> > because of the skills acquired with my SDR projects.
> >
> > Moreover, this particular project (Sirius, in Brasil), has adopted an
> > open hardware and free software attitude, which makes the use of
> > Gnuradio particularly interesting.
> >
> > Has anyone worked with this kind of instruments using Gnuradio? Is
> > USRP a good tool for this kind of job, or you can think about any
> > limitation?
> >
> > 

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

Re: [Discuss-gnuradio] tx_ofdm.grc & rx_ofdm.grc output data

[eontool]

Hi Martin.

I used the default settings for the parameters.

The data I'm seeing is after de CRC.

Here's my payload output at the HPD:
--
Tag Debug: HPD / Payload
Input Stream: 00
  Offset: 1547  Source: n/a Key: frame_len   Value: 17
  Offset: 1547  Source: n/a Key: packet_num   Value: 182
  Offset: 1547  Source: n/a Key: packet_len   Value: 800
  Offset: 1547  Source: n/a Key: ofdm_sync_carr_offset   Value: 0
  Offset: 1547  Source: n/a Key: ofdm_sync_chan_taps   Value:
#
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
  Offset: 1555  Source: n/a Key: packet_len   Value: 960
--

My vector source argument is:
tagged_streams.make_lengthtags((packet_len,), (0,), length_tag_name)


Other stuff:

I changed the OFDM Frame Equalizer of the payload part:
From:
digital.ofdm_equalizer_simpledfe(fft_len, *header*_mod.base(),
occupied_carriers, pilot_carriers, pilot_symbols, 2).base()

To:
digital.ofdm_equalizer_simpledfe(fft_len, *payload*_mod.base(),
occupied_carriers, pilot_carriers, pilot_symbols, 2).base()

I added a Repack Bits block at the rx, just before the CRC, from 2 to 8
bits.

I uploaded a screenshot and the grc file  here

 
:

Any help is really appreciated, thanks!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/tx-ofdm-grc-rx-ofdm-grc-output-data-tp44356p44367.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] tx_ofdm.grc & rx_ofdm.grc output data

[ashish mishra]

Hi

 Change the payload modulation to BPSK(Same as BPSK) and keep the bytes repack 
as 1 to 8 .

It will do the trick





On Thursday, 24 October 2013 11:44 PM, eontool  wrote:
 
Hi Martin.

I used the default settings for the parameters.

The data I'm seeing is after de CRC.

Here's my payload output at the HPD:
--
Tag Debug: HPD / Payload
Input Stream: 00
  Offset: 1547  Source: n/a     Key: frame_len   Value: 17
  Offset: 1547  Source: n/a     Key: packet_num   Value: 182
  Offset: 1547  Source: n/a     Key: packet_len   Value: 800
  Offset: 1547  Source: n/a     Key: ofdm_sync_carr_offset   Value: 0
  Offset: 1547  Source: n/a     Key: ofdm_sync_chan_taps   Value:
#
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
  Offset: 1555  Source: n/a     Key: packet_len   Value: 960
--

My vector source argument is:
tagged_streams.make_lengthtags((packet_len,), (0,), length_tag_name)


Other stuff:

I changed the OFDM Frame Equalizer of the payload part:
From:
digital.ofdm_equalizer_simpledfe(fft_len, *header*_mod.base(),
occupied_carriers, pilot_carriers, pilot_symbols, 2).base()

To:
digital.ofdm_equalizer_simpledfe(fft_len, *payload*_mod.base(),
occupied_carriers, pilot_carriers, pilot_symbols, 2).base()

I added a Repack Bits block at the rx, just before the CRC, from 2 to 8
bits.

I uploaded a screenshot and the grc file  here

 
:

Any help is really appreciated, thanks!



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/tx-ofdm-grc-rx-ofdm-grc-output-data-tp44356p44367.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Missing File?

[Paul B. Huter]

Tom:

Thank you for the reply. This is my first GNU Radio application, and typing
'make test' at the Windows command line does nothing. I followed the Ettus
installation instructions for installing GNU Radio and UHD, and I cannot
find anything anywhere about "make" with Windows. I found some other
instances of people having issues like mine, but they seem to have been
related to wxPython prior to GNU Radio 3.7 (which is what I have).

Anyone have any other ideas as to how to remedy this situation, including
running some other application to get things set up?

Thank you.


On Thu, Oct 24, 2013 at 9:07 AM, Tom Rondeau  wrote:

> On Wed, Oct 23, 2013 at 8:19 PM, Paul B. Huter 
> wrote:
> > Running my script, I get an error (repeated twice):
> >
> > ~\AppData\Roaming\.gnuradio\prefs\vmcircbuf_default_factory: Invalid
> > argument
> >
> > I looked, and there is no 'vmcircbuf_default_factory' in the \prefs
> folder
> > (there isn't anything in there). The Internet (GNURadio website and
> GNURado
> > mailing list archives in addition to general Internet searches) provides
> > plenty of examples of 'vmcircbuf_sysv_shm, where the user is told to
> update
> > the 'vmcircbuf_default_factory' file, but nothing relating directly to my
> > problem.
> >
> > Is this a file that should have been created when I installed GNURadio
> and
> > its dependencies? Can I just create the file, and, if so, what does the
> > structure/format look like? Or, can someone point me to either a sample
> > file, or the file location somewhere else?
> >
> > Thank you.
>
> This file is created the first time you try to run GNU Radio, so not
> during build or even install. It /will/ get created when you run 'make
> test' or any other GNU Radio application.
>
> Is this on Windows? I'm honestly not sure what the right factory
> function is for Windows, but my guess is this file should contain:
>
> gr::vmcircbuf_createfilemapping_factory
>
> Note that that's just one line, no carriage return or anything else.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Missing File?

[Paul B. Huter]

Turns out this error doesn't mean anything, my script executes just fine.


On Thu, Oct 24, 2013 at 6:11 PM, Paul B. Huter wrote:

> Tom:
>
> Thank you for the reply. This is my first GNU Radio application, and
> typing 'make test' at the Windows command line does nothing. I followed the
> Ettus installation instructions for installing GNU Radio and UHD, and I
> cannot find anything anywhere about "make" with Windows. I found some other
> instances of people having issues like mine, but they seem to have been
> related to wxPython prior to GNU Radio 3.7 (which is what I have).
>
> Anyone have any other ideas as to how to remedy this situation, including
> running some other application to get things set up?
>
> Thank you.
>
>
> On Thu, Oct 24, 2013 at 9:07 AM, Tom Rondeau  wrote:
>
>> On Wed, Oct 23, 2013 at 8:19 PM, Paul B. Huter 
>> wrote:
>> > Running my script, I get an error (repeated twice):
>> >
>> > ~\AppData\Roaming\.gnuradio\prefs\vmcircbuf_default_factory: Invalid
>> > argument
>> >
>> > I looked, and there is no 'vmcircbuf_default_factory' in the \prefs
>> folder
>> > (there isn't anything in there). The Internet (GNURadio website and
>> GNURado
>> > mailing list archives in addition to general Internet searches) provides
>> > plenty of examples of 'vmcircbuf_sysv_shm, where the user is told to
>> update
>> > the 'vmcircbuf_default_factory' file, but nothing relating directly to
>> my
>> > problem.
>> >
>> > Is this a file that should have been created when I installed GNURadio
>> and
>> > its dependencies? Can I just create the file, and, if so, what does the
>> > structure/format look like? Or, can someone point me to either a sample
>> > file, or the file location somewhere else?
>> >
>> > Thank you.
>>
>> This file is created the first time you try to run GNU Radio, so not
>> during build or even install. It /will/ get created when you run 'make
>> test' or any other GNU Radio application.
>>
>> Is this on Windows? I'm honestly not sure what the right factory
>> function is for Windows, but my guess is this file should contain:
>>
>> gr::vmcircbuf_createfilemapping_factory
>>
>> Note that that's just one line, no carriage return or anything else.
>>
>> Tom
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD: Control Packet Attempt, Sequence

[Paul B. Huter]

I am getting the following error when running my script -

UHD Error:
 Control packet attempt 0, sequence number 391:
 RuntimeError: no control response, possible packet loss

Mostly "attempt 0", but one "attempt 1", six different sequence numbers.

Does this mean anything? Is my data good? Is there a way to write my script
so I do not get this type of problem?

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

[Discuss-gnuradio] Problem with error_rate block?

[Rick Spanbauer]

I was trying to use the error_rate block tonight, and noticed it seems to
be throwing an error related to blocks.message_from_string.  The
following change to error_rate.py seems to have fixed the issue:

diff error_rate.py error_rate.py-orig
116c116
< msg = gr.message_from_string(arr.tostring(), 0, gr.sizeof_float,
num)
---
> msg = blocks.message_from_string(arr.tostring(), 0,
gr.sizeof_float, num)
139c139
< msg = gr.message_from_string(arr.tostring(), 0, gr.sizeof_float,
num)
---
> msg = blocks.message_from_string(arr.tostring(), 0,
gr.sizeof_float, num)

Just passing this along, if anyone runs into the same problem.

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

[Discuss-gnuradio] SBRAC update

[Marcus D. Leech]

I don't usually post updates about our work at SBRAC on this list, 
mostly because progress at the observatory has been so very slow, owing 
to having

  zero budget to work with.

However, today, we achieved a significant milestone in our progress.  
The feed platform is in-place, with all the RF cabling connected, and 
brought down
  to ground level.  We didn't have time to do any tests today, and I'm 
exhausted, having worked for 2.5 hours in the bucket of a "SkyLift" provided

  by the Ottawa Fire Department.

Here's a picture of the feed platform in-place, just before we got it 
wired up:


http://www.sbrac.org/files/feed_in_place.jpg

Next week, we'll be doing some preliminary testing, and maybe get some 
of our "science" computers in place.  The receivers are a mixture of
  both RTLSDR devices, and USRPs.  There'll be a USRP doing the pulsar 
work, and another one doing the precision hydrogen spectral work, and
  an assortment of RTLSDR devices doing radiometry, and the "rough" 
hydrogen spectral work.


We've been slowly "nibbling away" at this thing for several years, and 
it's gratifying to get to a point where you have obvious, visible, 
progress...




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

Re: [Discuss-gnuradio] tx_ofdm.grc & rx_ofdm.grc output data

[eontool]

Hello again.

OK, so now after changing a few things it finally works, I get the expected
data correctly at the output.

Apparently it works automatically for BPSK Modulation on both header and
payload because the arguments on these variables are equal to "1". But, in
order to work for QPSK o QAM you need to add the variables to the
"header_formatter" and to the project itself.

Issues I found:

Change the "header_formatter" to:
digital.packet_header_ofdm(occupied_carriers, 1, "packet_len", "frame_len",
"", bps_header, bps_payload)
 
Add the corresponding variables:
bps_header = header_mod.bits_per_symbol()
bps_payload = payload_mod.bits_per_symbol()

Change the argument on the OFDM Frame Equalizer to:
digital.ofdm_equalizer_simpledfe(fft_len, *payload_mod.base()*,
occupied_carriers, pilot_carriers, pilot_symbols, 2).base()

Add "1" skip symbol to the Payload Serializer block.

Add a Repack block just before de CRC on the tx part.
Bits per input byte: payload_mod.bits_per_symbol()
Bits per output byte: 8

Change the GRG Block on the rx side from "generate" to "check".
 
If you want QPSK for the header or QAM on the payload, try changing the "80"
delay to "72" or "84".

That should do it, it works for BPSK, QPSK and 16QAM. I'm uploading the grc
file anyway.

ofdm_txrx_full.grc
  

Thanks for the help.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/tx-ofdm-grc-rx-ofdm-grc-output-data-tp44356p44374.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