I am currently preparing a release of my DRM transmitter blockset. This
package shall contain my GNU Radio blocks and a set of classes (no
blocks) used for initializing the transmitter parameters before the flow
graph is started.
At the moment, I have a source tree generated by gr_modtool based on
CMake that contains my GNU Radio blocks and creates the python module
“drm” and a second folder containing the classes for initializing where
I wrote the .i file myself and compile everything by hand. This folder
ends up in “drm_init”. Everything works fine if I do it like that but
it’s quite inconvenient.
Now I’d like to combine these two build processes in the CMake build and
the two modules in one.
My first try was to add the source files in the CMakeLists file in lib/,
the header files in include/. Then I added everything from my custom
swig file in the existing one in swig/.
It compiles without any errors or warnings, but when I try to import my
module, I get “undefined symbol” errors. I looked at the swig shared
library file using “nm” and noticed that I have lots of undefined
symbols in the part that contains my former drm_init module. The C++
shared library seems fine, so I guess it’s a SWIG problem.
I would really appreciate it if somebody could give me a hint how I can
configure CMake / SWIG correctly. The current (working) configuration
can be found on fewu · GitHub. The custom make file can be found under
misc/, the other in the swig/ folder.
It compiles without any errors or warnings, but when I try to import my
module, I get “undefined symbol” errors. I looked at the swig shared
library file using “nm” and noticed that I have lots of undefined
symbols in the part that contains my former drm_init module. The C++
shared library seems fine, so I guess it’s a SWIG problem.
You probably have some class or function thats defined in a header and
either missing from the library or not exported. SWIG basically uses all
of the functions/classes you feed it. So anything missing, so long as it
was defined in a header you fed to swig, is going to be heard about when
you import the module.
Are you compiling with -fvisibility=hidden? you need to declare any
public symbols to be default visibility http://gcc.gnu.org/wiki/Visibility
That hint with the visibility option solved all my problems. I commented
it out in the CMakeLists.txt and the undefined symbols were gone. Thank
you so much!
Hi Felix,
Do you have something in a ready-to-test state concerning the DRM
transmitter?
I got a new DRM receiver (DR111) which shows the MER and SNR of the
reception.
I am preparing a release for the beginning of next week. The release
will contain my DRM30 transmitter with various, fully configured
flowgraphs that hopefully can be used more or less as-is and especially
without deep knowledge of DRM. It’s already working, but before
releasing my code I want to put together a Readme file explaining how to
install/use my software and what the constraints are. When everything is
ready to be made public, I will notify the list about it.
Currently I am implementing DRM+ support but I cannot say if it will
make it into the first release. But as I mentioned before, this project
doesn’t end for me when GSoC ends. I already wrote to Michael Feilen and
asked for a version of his DRM+ receiver software so that I can test my
code.
We got the same consumer receiver (DR111) here at my institute, but it’s
a preproduction sample as far as I know and it’s quite buggy. Especially
bandwidths above 10 kHz (spectrum occupancy 4 and 5) do not work with
that receiver and unicode support for text messages is very limited.
However, DREAM decodes the signal and so I guess I’m not doing
everything wrong =).
Felix,
Anything I can help, I’m here.
Did you installed the latest firmware version to your DR111?
CDNSE is really fixing the bugs we report.
Sodira can decode DRM+ also, it’s quite buggy, but works somehow.
DRM developments is really a need here in Brazil (especially DRM+). 15
august the Brazilian government created the digital radio consilliere
group and December is set for the announcement of the standard. We hope
it
will be the DRM, for all bands.
Open implementations of DRM is helping us to push DRM ahead here.
; )
Danke!
Rafael D.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.