Re: [Discuss-gnuradio] uhd_packet_rx example freezes - Header/Payload Demux not releasing payload

[Justin Hamilton]

Hi Marcus,

Thanks for your response!

So I spent the last week testing out the changes you recommended. First I
had a look at the FLL block with the waterfall plots but couldn't
immediately spot anything strange, except that during pure simulation with
a perfect channel it did however shift things off centre and ruin
synchronisation. Pretty unexpected. The same doesn't happen when using
multipath channel taps or my real channel however. I also
increased/decreased the sps, eb and loop bandwidths on the various sync
blocks, leading to more packets being decoded and now the channel doesn't
lock up as before. To tune them I was watching the receiver constellations
and looking at how likely the system was to adapt vs. stick with the
current synchronisation.

It appears that the faster I send packets, the easier synchronisation is,
but if I send packets too often (< 1ms period) I get async buffer overflows
and am more prone to crashes. I'm not experiencing any under or overruns.
Ideally I'd be sending packets every 1-10ms, though since the end
implementation is completely async (connected to a TUN/TAP), I could
realistically get packets only every 1s, which would be horrendous for sync
in its current state.

In general I'm still only getting very few packets getting through however.
With the *header_format_default* I am able to receive quite a lot of
packets, while *header_format_counter* successfully decodes far less and
additionally crashes with a segfault while performing a CRC check. Are
there any additional sync steps I could take advantage of to improve my
performance?

Thanks for your help.

On Fri, Mar 31, 2017 at 12:15 AM, Marcus Müller 
wrote:

> Hi Justin,
>
> sorry for the delayed response. So:
>
> indeed, the uhd_packet_rx.grc flow graph has two different sync elements:
> 1. the FLL band-edge
> 2. PFB Clock Sync within the packet_rx hier block,
>
> as you've noticed.
>
> In your case, it's possible the FLL doesn't attack fast enough; you would
> verify that by comparing waterfalls / spectra of the signal before and
> after.
> Maybe you'd alternatively/additionally want to increase the bandwidth of
> the PFB Clock Sync. In a first attempt: increase the sps (from default 2 ->
> 3, for example); for that, increase the USRP source's sampling rate
> accordingly, adapt the FLL to that to still lock tightly onto you signal,
> and make sure the sps in the packet_rx reflects the new sps value.
>
> Best regards,
> Marcus
>
> On 03/28/2017 04:58 AM, Justin Hamilton wrote:
>
> Hi everyone,
>
> I'm trying to develop a packet-based, single-carrier system (BPSK, QPSK,
> QAM) with FEC (CC) similar to that implemented in packet_rx.grc and
> packet_tx.grc. I am using two Ettus B205mini-i as my USRP devices,
> connected for now, via a 50Ω, 30dB attenuator and SMA cable (antennas
> also at hand). I am using 64-bit Ubuntu 14.04LTS, Xeon E3-1575M, 32gb ram.
>
> When testing uhd_packet_rx.grc with the default BPSK signal I find that
> the receiver immediately locks up after I enable it using the "on"
> checkbox. After taking a look into the packet_rx hierarchical block, I
> found that the correlation estimator was indeed finding a peak indicating
> the transmitted packet. The generated tags were then used to trigger the
> Header/Payload Demux block to release the header as expected. This block
> doesn't seem to be getting back a valid decoded header however. This
> results in the payload never being released and causes buffer back pressure
> which leads back to the USRP source and ultimately locks up the system.
>
> I have noticed a frequency offset between my two radios due to the
> receiver constellation spinning, but hand-tuning it proved quite difficult.
> The difference might be outside the acceptable limits for the
> synchronisation blocks used?
>
> Possibly related: I am able to run packet_loopback_hier.grc without issue,
> except that if I add considerable noise to the system it often never
> recovers, either returning the message "gr::log :INFO:
> header_payload_demux0 - Parser returned #f" or flat out crashing. Could it
> possibly be the case that the noise added by my 'over-the-air' radio system
> is too much for the Polyphase Clock Sync and Costas Loop blocks to
> compensate for?
>
> Has anyone experienced this issue before or figured out how to solve it?
> If I can get these example flowgraphs working it'll be a great help for my
> custom flowgraph. Surely sending OTA packets with modulation and coding
> can't be this difficult :)
>
> Also if anyone has any tips on modifying the synchronisation (Costas Loop)
> to support QAM constellations that be great!
>
> Thanks for your help!
> Justin
>
>
> ___
> Discuss-gnuradio mailing 
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> 

Re: [Discuss-gnuradio] OFDM implementation for high data rates

[Ron Economos]

There's the DVB-T transmitter and receiver in the Digital Television 
component of GNU Radio. It's capable of 31.6 Mbps in a standard 8 MHz 
bandwidth. (and can be used at higher bandwidths).


I have some OOT modules that allow sending IP packets over DVB. Note 
that these modules only implement the transmit portion and are meant to 
be used with commercial receivers.


https://github.com/drmpeg/gr-mpe

https://github.com/drmpeg/gr-ule

One of the drawbacks is that DVB-T is a streaming protocol, so a two-way 
link would require a full-duplex RF system. Also, latency is pretty high 
due to the long frame size used in DVB-T. You can get a much lower 
latency with the DVB-T2 transmitter (which has adjustable frame size), 
but there's no companion DVB-T2 receiver in GNU Radio (you have to use a 
commercial DVB-T2 receiver like the PCTV 292e).


Ron

On 04/06/2017 09:52 AM, Yaşar Sinan NASIR wrote:

Hi,

For OFDM transmitter and receiver, I was using benchmark_tx/rx 
implementations. However, I am wondering what is the best publicly 
available OFDM implementation for relatively high bandwidths (10s of 
MHz) and data rates (10s of Mbps)?


Best,
Sinan




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

Re: [Discuss-gnuradio] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

On Thu, 2017-04-06 at 20:55 +, Nick Foster wrote:
> Unrelated to the question at hand, but since you're on the subject:
> how are you resetting the Viterbi decoder state between packets? I
> tried the same thing some years ago and it worked well except for
> that problem.
> 
> --n

I haven't gotten that far yet. :P

I have a symbol synchronizer block (using the MSK TED that the MSK
timing recovery block uses) that will give me Q samples/symbol out,
synchronized to the symbol centers.  It also propagates tags properly,
so I'll have the center of one of the first symbols in a packet marked
with a tag (using the corr_est block).

I was planning on writing a block to inject samples, if needed, near
that marked symbol to keep the decimating matched filters and viterbi
inputs properly aligned (so they will always process fully aligned
symbols).

I had not looked into what state the metrics and viterbi decoder might
be keeping.  If they need explicit reseting, I was going to modify them
to watch for a tag.

So a lot of my design concept for feeding the gr-trellis CPM processing
methodology depends on this symbol synchronizer block:

https://github.com/awalls-cx18/gr-nwr/blob/master/grc/nwr_symbol_sync_x
x.xml

and another (to be written) custom block for injecting < Q samples to
preserve alignment, and perhaps yet another (to be written) custom
block to handle the f0T frequency correction.  (The GNURadio stock
rotator block actually drifts slightly over a great many samples due to
numerical roundoff, plus it can't be synchronously reset).

I was hoping using gr-trellis practically would have been a little bit
easier. :(  

-Andy

> On Thu, Apr 6, 2017 at 12:38 PM Andy Walls
>  wrote:
> > On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > > sure, feel free to look into the gr-trellis documentation and
> > provide
> > > some feedback.
> > > If you have further questions please let us know.
> > >
> > > best,
> > > Achilleas
> > 
> > Hi Achilleas:
> > 
> > My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver,
> > using
> > the Viterbi algorithm for optimal demodulation of the CPM symbols.
> > 
> > In examining gr-trellis/examples/python/test_cpm.py, I see that
> > everything is perfectly synchronized, for the purposes of
> > demonstration. (The addition of a 0.0 to the end of the 99% energy
> > orthonormal basis vectors for the matched filter correlators, to
> > have
> > the taps completely fall into the initial all-0 history of the fir
> > filter blocks, was a nice trick BTW).
> > 
> > In my design concept for a receiver, I believe I have worked out
> > carrier frequency offset correction, phase offset correction,
> > symbol
> > timing recovery at either 4 or 5 samples per symbol, and injecting
> > samples to properly realign the symbols entering the decimating
> > matched
> > filter correlators when a new burst is received.
> > 
> > What I can't quite figure out is how to properly synchronize the
> > correction of f0T carrier frequency shift introduced by the CPM
> > decomposition, without unintentionally adding an arbitrary phase
> > shift
> > to the symbol's signal in the CPM decomposition.
> > 
> > Do I restart the complex exponential frequency shift sequence with
> > a
> > phase of 0 at the start of each symbol?  I think that works for
> > Q=4.
> > But what about for Q=5?
> > 
> > The reason I ask is that it appears the phase of the complex
> > correlation output by the matched filters will affect the metric
> > for
> > which CPM decomposition signal gets selected as the best match.
> > 
> > Looking at the 16, 99% energy CPM decomposition signals generated
> > by
> > the test_cpm.py script:
> > 
> > >>> print abs(Sf.transpose())
> > [[ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.96823385  0.34970555]
> >  [ 1.96823385  0.34970555]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.90550352  0.600571  ]
> >  [ 1.81592306  0.83465307]
> >  [ 1.81592306  0.83465307]]
> > 
> > Many of the signals can only be distinguished from each other
> > properly
> > when the correlator outputs have proper phase.
> > 
> > Thank you for any advice you can provide.
> > 
> > Regards,
> > Andy
> > 
> > ___
> > 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] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Nick Foster]

Unrelated to the question at hand, but since you're on the subject: how are
you resetting the Viterbi decoder state between packets? I tried the same
thing some years ago and it worked well except for that problem.

--n

On Thu, Apr 6, 2017 at 12:38 PM Andy Walls 
wrote:

> On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> > sure, feel free to look into the gr-trellis documentation and provide
> > some feedback.
> > If you have further questions please let us know.
> >
> > best,
> > Achilleas
>
> Hi Achilleas:
>
> My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver, using
> the Viterbi algorithm for optimal demodulation of the CPM symbols.
>
> In examining gr-trellis/examples/python/test_cpm.py, I see that
> everything is perfectly synchronized, for the purposes of
> demonstration. (The addition of a 0.0 to the end of the 99% energy
> orthonormal basis vectors for the matched filter correlators, to have
> the taps completely fall into the initial all-0 history of the fir
> filter blocks, was a nice trick BTW).
>
> In my design concept for a receiver, I believe I have worked out
> carrier frequency offset correction, phase offset correction, symbol
> timing recovery at either 4 or 5 samples per symbol, and injecting
> samples to properly realign the symbols entering the decimating matched
> filter correlators when a new burst is received.
>
> What I can't quite figure out is how to properly synchronize the
> correction of f0T carrier frequency shift introduced by the CPM
> decomposition, without unintentionally adding an arbitrary phase shift
> to the symbol's signal in the CPM decomposition.
>
> Do I restart the complex exponential frequency shift sequence with a
> phase of 0 at the start of each symbol?  I think that works for Q=4.
> But what about for Q=5?
>
> The reason I ask is that it appears the phase of the complex
> correlation output by the matched filters will affect the metric for
> which CPM decomposition signal gets selected as the best match.
>
> Looking at the 16, 99% energy CPM decomposition signals generated by
> the test_cpm.py script:
>
> >>> print abs(Sf.transpose())
> [[ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.96823385  0.34970555]
>  [ 1.96823385  0.34970555]
>  [ 1.90550352  0.600571  ]
>  [ 1.90550352  0.600571  ]
>  [ 1.81592306  0.83465307]
>  [ 1.81592306  0.83465307]]
>
> Many of the signals can only be distinguished from each other properly
> when the correlator outputs have proper phase.
>
> Thank you for any advice you can provide.
>
> Regards,
> Andy
>
> ___
> 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] Proper synchronization of f0T correction to use gr-trellis for a receiver (Re: gr-trellis test_cpm.py question)

[Andy Walls]

On Mon, 2017-04-03 at 09:06 -0400, Achilleas Anastasopoulos wrote:
> sure, feel free to look into the gr-trellis documentation and provide
> some feedback.
> If you have further questions please let us know.
> 
> best,
> Achilleas

Hi Achilleas:

My objective is to implement an AIS (GMSK, BT=0.4, L=3) receiver, using
the Viterbi algorithm for optimal demodulation of the CPM symbols.

In examining gr-trellis/examples/python/test_cpm.py, I see that
everything is perfectly synchronized, for the purposes of
demonstration. (The addition of a 0.0 to the end of the 99% energy
orthonormal basis vectors for the matched filter correlators, to have
the taps completely fall into the initial all-0 history of the fir
filter blocks, was a nice trick BTW).

In my design concept for a receiver, I believe I have worked out
carrier frequency offset correction, phase offset correction, symbol
timing recovery at either 4 or 5 samples per symbol, and injecting
samples to properly realign the symbols entering the decimating matched
filter correlators when a new burst is received.

What I can't quite figure out is how to properly synchronize the
correction of f0T carrier frequency shift introduced by the CPM
decomposition, without unintentionally adding an arbitrary phase shift
to the symbol's signal in the CPM decomposition.

Do I restart the complex exponential frequency shift sequence with a
phase of 0 at the start of each symbol?  I think that works for Q=4. 
But what about for Q=5?  

The reason I ask is that it appears the phase of the complex
correlation output by the matched filters will affect the metric for
which CPM decomposition signal gets selected as the best match.

Looking at the 16, 99% energy CPM decomposition signals generated by
the test_cpm.py script:

>>> print abs(Sf.transpose())
[[ 1.81592306  0.83465307]
 [ 1.81592306  0.83465307]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.96823385  0.34970555]
 [ 1.96823385  0.34970555]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.96823385  0.34970555]
 [ 1.96823385  0.34970555]
 [ 1.90550352  0.600571  ]
 [ 1.90550352  0.600571  ]
 [ 1.81592306  0.83465307]
 [ 1.81592306  0.83465307]]

Many of the signals can only be distinguished from each other properly
when the correlator outputs have proper phase.

Thank you for any advice you can provide.

Regards,
Andy

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

[Discuss-gnuradio] OFDM implementation for high data rates

[Yaşar Sinan NASIR]

Hi,

For OFDM transmitter and receiver, I was using benchmark_tx/rx
implementations. However, I am wondering what is the best publicly
available OFDM implementation for relatively high bandwidths (10s of MHz)
and data rates (10s of Mbps)?

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

[Discuss-gnuradio] List of SDRs that are able to work in burst mode like USRP

[Paul I.]

Hello,

Does anybody know which other SDRs are able to work in burst mode (i.e. to
receive/transmit burst of data at specific time) like USRP?

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

Re: [Discuss-gnuradio] Cross compile OOT cmake error

[Zach Hudson]

I am trying to get it running on a Red Pitaya (ARM Cortex A9 running Linux)

Zach

On 04/06/2017 06:21 AM, Philip Balister wrote:

On 04/05/2017 07:46 PM, Zach Hudson wrote:

Perhaps I should explain that I am woefully uneducated on all of this.
Could you point me to a good resource that could help me learn more
about what I am getting myself into? Or is that toolchain something easy
to install?

What is your target hardware? That would help narrow the focus of the
answer :)

Philip


Thanks
Zach

On 04/05/2017 04:07 PM, Philip Balister wrote:

On 04/05/2017 06:54 PM, Zach Hudson wrote:

I am using "../../gnuradio/cmake/Toolchains/oe-sdk_cross.cmake" as
called out on the wiki page:
https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target


That is the toolchain file. It expects you to install an OpenEmbedded
built toolchain and source an environment file.

Philip



Zach

On 04/05/2017 03:39 PM, Philip Balister wrote:

On 04/05/2017 06:17 PM, Zach Hudson wrote:

I am getting a cmake error when trying to follow the directions for
cross compiling an OOT.

CMake Error: Internal CMake error, TryCompile configure of cmake
failed
-- Check for working CXX compiler: /usr/bin/c++ -- broken
CMake Error at
/usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
 The C++ compiler "/usr/bin/c++" is not able to compile a simple
test
 program.

/usr/bin/c++ isn't normally a cross compiler. What toolchain are you
trying to use?

Philip


 It fails with the following output:





 CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
 CMakeLists.txt:24 (project)

I am able to compile it fine for local use. Any help would be
appreciated.


Zach Hudson
Shine Micro





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






--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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

Re: [Discuss-gnuradio] Cross compile OOT cmake error

[Philip Balister]

On 04/05/2017 07:46 PM, Zach Hudson wrote:
> Perhaps I should explain that I am woefully uneducated on all of this.
> Could you point me to a good resource that could help me learn more
> about what I am getting myself into? Or is that toolchain something easy
> to install?

What is your target hardware? That would help narrow the focus of the
answer :)

Philip

> 
> Thanks
> Zach
> 
> On 04/05/2017 04:07 PM, Philip Balister wrote:
>> On 04/05/2017 06:54 PM, Zach Hudson wrote:
>>> I am using "../../gnuradio/cmake/Toolchains/oe-sdk_cross.cmake" as
>>> called out on the wiki page:
>>> https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target
>>>
>> That is the toolchain file. It expects you to install an OpenEmbedded
>> built toolchain and source an environment file.
>>
>> Philip
>>
>>
>>>
>>> Zach
>>>
>>> On 04/05/2017 03:39 PM, Philip Balister wrote:
 On 04/05/2017 06:17 PM, Zach Hudson wrote:
> I am getting a cmake error when trying to follow the directions for
> cross compiling an OOT.
>
> CMake Error: Internal CMake error, TryCompile configure of cmake
> failed
> -- Check for working CXX compiler: /usr/bin/c++ -- broken
> CMake Error at
> /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
> The C++ compiler "/usr/bin/c++" is not able to compile a simple
> test
> program.
 /usr/bin/c++ isn't normally a cross compiler. What toolchain are you
 trying to use?

 Philip

> It fails with the following output:
>
>
>
>
>
> CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
> CMakeLists.txt:24 (project)
>
> I am able to compile it fine for local use. Any help would be
> appreciated.
>
>
> Zach Hudson
> Shine Micro
>
>
>
>
>
> ___
> 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] Derive OOT header format from header_format_default

[Justin Hamilton]

Hi everyone,

I was able to solve this issue by running *nm -C -u
libgnuradio-cognitiveSDR.so | grep header_format_cognitive* in my custom
module's folder "*gr-cognitiveSDR/build/lib*", which identified a function
accidentally declared in my class' header file, which wasn't implemented in
the source code and was trying to override the base class' corresponding
function. I simply removed this declaration and rebuilt/installed.

To make my new header format work with the *protocol_formatter_async* block
I also had to remove *"typedef boost::shared_ptr
sptr*" from my header file so that my class would instead inherit the
required sptr from *header_format_base* to satisfy the requirements of the
*protocol_formatter_async* block's make method.

The issue I am facing now is attempting to make my format's custom setter
and getter functions accessible by python GUI elements and variables inside
GRC. Currently it appears that after creating the formatter object (
*hdr_format*) and using it in the protocol formatter, I can't, for example,
call *hdr_format.setter_function()* to update some property in the header.
I get the following error:


*Value "hdr_format.set_bps(2)" cannot be evaluated:
'header_format_base_sptr' object has no attribute 'set_bps'*

Currently all my functions are declared as virtual both in "
*gr-cognitiveSDR/include/cognitiveSDR/header_format_cognitive.h*" and "
*gr-cognitiveSDR/lib/header_format_cognitive.h*" (not pure virtual ie. "*bool
setter_function() = 0*" as this prevents me from even instantiating the
object ), and defined in the source "
*gr-cognitiveSDR/lib/header_format_cognitive.cc*".

Any ideas? Do I need to add something to the SWIG config to make these
callback functions accessible?

Cheers.

On Fri, Mar 31, 2017 at 3:56 PM, Justin Hamilton 
wrote:

> Hi everyone,
>
> I'm creating a custom header format *'header_format_cognitive*' derived
> from *'header_format_default*'. I'm adding extra info to the default
> header, very similar to the way the child class *'header_format_counter*'
> adds bits/symbol to the default. I'm creating my class as an OOT module
> named *'cognitiveSDR'*.
>
> I'm running into what appears to be a common issue, with people previously
> creating spin-offs of *packet_header_default*, including gr-ieee-802.11.
> https://www.mail-archive.com/discuss-gnuradio@gnu.org/msg50789.html
> http://gnuradio.4.n7.nabble.com/Trouble-with-SWIG-for-
> packet-formatter-default-child-class-td52446.html
>
> I was able to compile, install and import my module in GRC, but once I try
> to create the class using a variable with 
> "cognitiveSDR.header_format_cognitive(..)",
> I get the message:
>
>
>
> *"Value "cognitiveSDR.header_format_cognitive(..)" cannot be
> evaluated: 'module' object has no attribute 'header_format_cognitive'"*
> To give some context, normally when creating a standard header format
> object using a GRC variable I call *"digital.header_format_counter(preamble_b,
> 3, Const_PLD.bits_per_symbol())"*
>
> *Steps taken so far:*
> 1. Created my new module *cognitiveSDR* with gr_modtool
> 2. Added *header_format_cognitive* (c++) using gr_modtool as type
> 'noblock'
> 3. Fleshed out the .cc and .h files using a combination of
> *header_format_counter*, *header_format_crc* and my own functions
> 4. Made sure to *#include * in
> the header file
> 5. Used *digital::header_format_default* as the parent class in the class
> declaration since it's now in separate namespace to 'digital'
> 6. Modified *set(GR_REQUIRED_COMPONENTS RUNTIME DIGITAL)* in
> CMakeLists.txt
> 6. Modified the SWIG file as shown below
>
> Are there any modifications that I should make to the default
> CMakeLists.txt file generated for the module or additional changes to the
> SWIG file in order to make my class accessible inside GRC? I assume the
> parent and child classes are linking up properly since cmake, make and
> install succeed.
>
> Thanks for you help! Cheers.
> Justin
>
> *cognitiveSDR_swig.i*
>
> *---*
> /* -*- c++ -*- */
>
> #define COGNITIVESDR_API
> #define DIGITAL_API
>
> %include "gnuradio.i"// the common stuff
>
> //load generated python docstrings
> %include "cognitiveSDR_swig_doc.i"
>
> %{
> #include "cognitiveSDR/header_format_cognitive.h"
> %}
>
> %include "gnuradio/digital/header_format_base.h"
> %include "gnuradio/digital/header_format_default.h"
>
> %include "cognitiveSDR/header_format_cognitive.h"
>
> %template(header_format_cognitive_sptr) boost::shared_ptr cognitiveSDR::header_format_cognitive>;
> %pythoncode %{
> header_format_cognitive_sptr.__repr__ = lambda self:
> ""
> header_format_cognitive = header_format_cognitive .make;
> %}
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio