Re: SDRA-2024
hel...@relix.de wrote: Dear Lists, The programme for the 10th Software Defined Radio Academy (June 29) in Friedrichshafen is ready. : Dr. Ulrich Rohde N1UL and others: 10 Years of Software Defined Radio Academy ... 16:00 - 16:30 Phil Karn KA9Q These guys are attending and on my birthday! I'd wish I could come. But I'll follow the stream on YouTube instead (on June 29). -- --gv
Re: Pail of Milky Way Horn Radio Telescope
Glen Langston wrote: Comments and improvements welcomed. Data are all obtained using Gnuradio designs available from the DSPIRA web site. https://github.com/WVURAIL/gr-radio_astro Tried building it on Win-10 using MSVC/clang-cl. But it fails on the use of 'clock_gettime()', 'CLOCK_REALTIME' etc. -- --gv
Re: Radioconda 2022.09.22 released
Ryan Volz wrote: Radioconda 2022.09.22, including GNU Radio 3.10.4.0, is now available: https://github.com/ryanvolz/radioconda/releases Tried it with a random .qrc-file. But it crashed inside Cairo. Call-stack: ucrtbase!abort+0x4e ucrtbase!common_assert_to_stderr_direct+0xb2 ucrtbase!common_assert_to_stderr+0x1d ucrtbase!wassert+0x71 cairo!cairo_surface_destroy+0x40 cairo!cairo_font_options_status+0xc09 cairo!cairo_debug_reset_static_data+0xb8 cairo!cairo_destroy+0x48 _cairo_cp310_win_amd64!PyInit__cairo+0xb48 python310!_Py_Dealloc+0x7 python310!_Py_DECREF+0xd python310!_Py_XDECREF+0xf ... And from Cairo: Assertion failed: CAIRO_REFERENCE_COUNT_HAS_REFERENCE (>ref_count), file cairo-surface.c, line 955 Any chance to have the .PDB-files on Windows? -- --gv
Re: Missing Block
Kyeong Su Shin wrote: Hello Mohammad: I guess a out-of-tree module is not installed (probably gr-dab, as the missing blocks are related to dab). You can install it by yourself, but I think gr-dab does not support 3.10 yet (and is not actively being updated). There's some 3.9 ports, though. https://github.com/andrmuel/gr-dab/issues/28 This repo seems to support 3.9+: https://github.com/elafargue/gr-dab/commit/2d0d2db72d006afd185b09de77da04025b3c683a -- --gv
Re: An example of pure C++ code of GNU Radio?
Clark Chiu wrote: I went through most of the tutorials of GNU Radio and part of the source code. I understand GNU Radio is composed by Python for the interface and C++ for the DSP block implementations. My question is, is there any example that only uses C++ code? A simple example is 'gr-audio/examples/c++/dial_tone.cc'. If you want a more advanced C++ application, then look at the GQrx program: https://github.com/csete/gqrx -- --gv
Re: GNU Radio on Raspberry Pi 4?
Franco VENTURI wrote: if you are interested in using SDRplay API version 3.X (I think the latest version of their API is 3.07), and you are on GNU Radio 3.7, you may want to take a look at the gr-sdrplay GNU Radio OOT module I modified to work with SDRplay API version 3.X: https://github.com/fventuri/gr-sdrplay/tree/API3+RSPduo (notice the non-default branch name: 'API3+RSPduo'). I tried your 'master' branch. No problem building that. But I have problems with the 'API3+RSPduo' branch: git checkout API3+RSPduo error: pathspec 'API3+RSPduo' did not match any file(s) known to git. What?? Besides there are *many* warning '4250' in MSVC building this module: rsp1a_impl.h(33): warning C4250: 'gr::sdrplay3::rsp1a_impl': inherits 'gr::sdrplay3::rsp_impl::gr::sdrplay3::rsp_impl::start' via dominance etc.
Re: clang formating
Den 11.11.2020 13.28, skrev Johannes Demel: Hi Gisle, `file` is not a placeholder but the literal argument. `--style=file` tells `clang-format` to search for a `.clang-format` file in the current and parent folders. Oh. But deleting the '%GR_ROOT/.clang-format' and doing a: clang-format.exe -style=file -i file_descriptor_sink_impl.cc in '%GR_ROOT/gr-blocks/lib', works too. So it traverses multiple directories under my %GR_ROOT? Adding a '--verbose' gives no extra clue what this tool does and where it finds '.clang-format'. -- --gv
Re: clang formating
Johannes Demel wrote: unless the clang-format behavior changed, the function call should be: clang-format --style=file -i path/to/file.cc The `--style=file` option tells clang-format to search for a `.clang-format` file. Does not work on Windows (using clang-format v10.0.0). In a .bat-file I have: clang-format.exe -style=%GR_ROOT%/.clang-format -i %* No matter how style is; '--style' or '-style', it says 'Invalid value for -style'. Only these values works: LLVM, Google, Chromium, Mozilla, WebKit. which all are equally ugly. -- --gv
Help with Python import
Hi list. I've having troubles understanding how GnuRadio and Python 3.x in particular should be told to import stuff under '/lib/site-pages'. I have a 'PYTHONPATH' containing both: /lib/site-pages /lib/site-pages/volk_modtool etc. But yet a statement like (in '/bin/volk_modtool.py'): from volk_modtool import volk_modtool, volk_modtool_config causes Python 3.x to error out with: ImportError: cannot import name 'volk_modtool' But patching it into, it works [1]: --- a/volk_modtool/volk_modtool.py 2020-02-03 09:55:18 +++ b /bin/volk_modtool.py 2020-03-25 09:44:29 @@ -21,7 +21,7 @@ # -from volk_modtool import volk_modtool, volk_modtool_config +from volk_modtool import * from optparse import OptionParser, OptionGroup import os -- What does the syntax "from volk_modtool import x, y" require or do in comparison to the "from volk_modtool import *" syntax? Anybody care to enlighten a Python newbie? [1]: volk_modtool.py -m: (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ -- --gv
Re: [Discuss-gnuradio] Error compiling gr-qtgui/lib
Michael Dickens wrote: Hi Gisle - Which version of GR are you trying to build? GR37 uses qwt52+qt4, while GR38 uses qwt6+qt5 ... I'm guessing Qwt 6.1.4 should work, though I don't think I've tried it out yet. - MLD I use the 'master' at https://github.com/gnuradio/gnuradio.git Should be v3.8, no? But just switching to 'https://github.com/osakared/qwt.git' compiles fine. Although it fails at the link stage and the latest commit is 2,5 year old! I just don't get this package mess! -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error compiling gr-qtgui/lib
Hello list. I have some errors while compiling 'gr-qtgui' using MSVC and/or clang-cl. From clang-cl: TimeRasterDisplayPlot.cc(199,30): error: allocating an object of abstract class type 'TimeRasterData' d_data.push_back(new TimeRasterData(d_rows, d_cols)); ^ f:/Qt/Qwt/src\qwt_raster_data.h(100,25): note: unimplemented pure virtual method 'interval' in 'TimeRasterData' virtual QwtInterval interval( Qt::Axis ) const = 0; ^ TimeRasterDisplayPlot.cc(374,20): error: no member named 'setInterval' in 'TimeRasterData' d_data[i]->setInterval(Qt::ZAxis, QwtInterval(minIntensity, maxIntensity)); ~ ^ The error on 'setInterval' is in other files too. I suspect I'm using the wrong Qwt library. This is the one I'm using: svn://svn.code.sf.net/p/qwt/code/trunk/qwt ver. 6.1.4 Or are we supposed to use another (older) one? -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RTTY receiver
Cinaed Simson wrote: It builds find on my ARM 64 Odroid running jessie. Maybe it just doesn't build on the raspberry pi 3. I'm running a slightly dated version of gnuradio - 3.7.12git-295-ga0adcd33. Just out of curiosity, I built using MSVC-2017. The only issue I found was the need to add a '#include ' in some place due to things like: if (bits_eaten >= bits_per_word and sample) Otherwise it links fine; not tested. -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] [OT] Old world magic
I had to share this wonderful video, Student Short Film: "Shortwave": https://www.youtube.com/watch?v=jK2iKtjrYOU A great attempt at an experiment in the "Philosophy of Everyday Life". -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] qa_* programs question
Hello list. To make sure my GnuRadio build work okay, I've also linked some of the 'qa_*exe' programs. But they are far from easy to understand. E.g. in 'qa_block_tags.exe', how can I specify verbose mode to see more details of what it is really testing? More like in e.g. GoogleTest. Now, from 'qa_set_msg_handler.exe', I get only this: Running 1 test case... gr::pagesize: no info; setting pagesize = 4096 *** No errors detected But from the 'qa_set_msg_handler.exe --help' page, it hints on a '--report_level'. Which seems not to accept any value. Besides, the help-page has this: .. catch_system_errors - Allows to switch between catching and ignoring system errors (signals) color_output - Allows to switch between catching and ignoring system errors (signals) Same text for both options!? Where are these texts from? I fail to find any such things in GnuRadio or Log4cpp. I'm on Win-10, MSVC-2017 using Log4CPP v.1.1.13. -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-fec Viterbi example
Jean-Michel FRIEDT wrote:
I am currently investigating LRPT (as used by METEOR-M2) and am
stuck with the Viterbi decoder. While trying to use
https://github.com/gnuradio/gnuradio/blob/master/gr-fec/lib/viterbi/decode.cc
which implements
I tried building this program on Windows and failed. Since it's
missing in viterbi/CmakeLists.txt, I fail to see it's built by
default. How did you compile it? Are you sure it wasn't written
on a big-endian machine?
On Windows at least, the viterbi.h + decode.cc + encode.cc are
not up-to-date. Missing proper dllexport, setmode(fd,O_BINARY)
etc. etc.
Anyway, with some patching I was able to link and run them.
But I have no data to test the Viterbi encoder/decoder with.
Could you please ship some files to me?
I am unable to encode the sync word 0x1ACFFC1D to the expected result
0xfc 0xa2 0xb6 0x3d 0xb0 0x0d 0x97 0x94 as explained at
https://www.teske.net.br/lucas/2016/11/goes-satellite-hunt-part-3-frame-decoder/
I know this encoded sync word is correct because cross-correlating the
METEOR stream (after proper constellation rotation) with this word gives
a correlation peak every 16384 samples (=1024 byte sentence * 8 bits/byte * 2
bits/Viterbi encoder).
I am doing (word.bin was generated with Octave's fwrite function)
$ xxd word.bin
: 1acf fc1d ..
and then
$ cat word.bin | ./viterbi/encode > t.bin
but
$ xxd t.bin
: 0101 0001 0001 0101 0001
0010: 0001 0100 0001 0101 0100
0020: 0001 0101 0101 0101 0101 0100
0030: 0001 0100 0100 0001 0100 0100 0101
0040: 0001 0001 0101 0001 0101
does not match the expected bit sequence which should be
word=[1 1 1 1 1 1 0 0 ... % fc
1 0 1 0 0 0 1 0 ... % a2
1 0 1 1 0 1 1 0 ... % b6
0 0 1 1 1 1 0 1 ... % 3d
1 0 1 1 0 0 0 0 ... % b0
0 0 0 0 1 1 0 1 ... % 0d
1 0 0 1 0 1 1 1 ... % 97
1 0 0 1 0 1 0 0 ... % 94
I had no lock with 'xxd -revert' to check your results here
I used the attached hex2bin.c instead.
And BTW, my patches also attached.
--
--gv
/*
* hex2bin - simple hex to bin filter
* anti...@invece.org - under GPL version 2
*/
#include
#include
#include
#include
#include
static int hex2bin (void)
{
char hex[3];
int d = 0;
unsigned char c;
int stdin_fd = fileno(stdin);
int n_read;
while ((n_read = read(stdin_fd, hex, sizeof(hex)-1)) > 0)
{
if (n_read == 1)
{
if (hex[0] != '\n')
{
fprintf (stderr, "input parse error, odd digits in hex file\n");
return (1);
}
return (1);
}
hex[2] = '\0';
sscanf (hex, "%x", );
c = (unsigned char) d;
printf ("%c", c);
}
return (0);
}
static int bin2hex (void)
{
int stdin_fd = fileno(stdin);
int n_read;
unsigned char c;
#ifdef _WIN32
setmode (fileno(stdin), O_BINARY);
setmode (fileno(stdout), O_BINARY);
#endif
while ((n_read = read(stdin_fd, , 1)) > 0)
printf ("%.2x", c);
return (0);
}
int main (int argc, char **argv)
{
if (argc >= 2 && strstr(argv[1], "-r"))
return bin2hex();
return hex2bin();
}
--- a/gr-fec/include/gnuradio/fec/viterbi.h 2015-12-16 20:39:46
+++ b/gr-fec/include/gnuradio/fec/viterbi.h 2018-08-10 12:33:59
@@ -24,6 +24,13 @@
* But it fits so nicely into a 32-bit machine word...
*/
+#ifndef INCLUDED_VITERBI_H
+#define INCLUDED_VITERBI_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
#include
struct viterbi_state {
@@ -51,3 +58,10 @@
FEC_API unsigned char
viterbi_get_output(struct viterbi_state *state, unsigned char *outbuf);
+
+#ifdef __cplusplus
+};
+#endif
+
+#endif /* INCLUDED_VITERBI_H */
+
--- a/gr-fec/lib/viterbi/decode.cc 2015-12-16 20:39:46
+++ b/gr-fec/lib/viterbi/decode.cc 2018-08-10 14:05:31
@@ -49,14 +49,21 @@
float RATE=0.5;
float ebn0 = 12.0;
float esn0 = RATE*pow(10.0, ebn0/10);
+
gen_met(mettab, amp, esn0, 0.0, 4);
// Initialize decoder state
struct viterbi_state state0[64];
struct viterbi_state state1[64];
unsigned char viterbi_in[16];
+
viterbi_chunks_init(state0);
+#ifdef _WIN32
+ setmode (fileno(stdin), O_BINARY);
+ setmode (fileno(stdout), O_BINARY);
+#endif
+
while (!feof(stdin)) {
unsigned int n = fread(syms, 1, MAXENCSIZE, stdin);
unsigned char *out = data;
--- a/gr-fec/lib/viterbi/encode.cc 2015-12-16 20:39:46
+++ b/gr-fec/lib/viterbi/encode.cc 2018-08-10 14:05:55
@@ -44,6 +44,11 @@
unsigned char data[MAXCHUNKSIZE];
unsigned char syms[MAXENCSIZE];
+#ifdef _WIN32
+ setmode (fileno(stdin), O_BINARY);
+ setmode (fileno(stdout), O_BINARY);
+#endif
+
while (!feof(stdin)) {
unsigned int n = fread(data, 1, MAXCHUNKSIZE, stdin);
encoder_state = encode(syms, data, n, encoder_state);
--- a/gr-fec/lib/viterbi/metrics.c 2015-12-16 20:39:46
+++
[Discuss-gnuradio] [volk] MSVC optimizer bug
I'm experiencing an INTERNAL COMPILER ERROR in MSVC-2017
(latest version 19.13.26129 for x86) when compiling
volk/lib/volk_machine_sse2_mmx.c.
Function volk_32f_index_max_16u_a_sse(), ref:
https://www.gnuradio.org/doc/doxygen-3.7.2.1/volk__32f__index__max__16u_8h_source.html
at lines 70 - 122.
Is anybody else having troubles with this?
A fix for me was to remove all '-O..' flags when compiling
this file. No problems with any other files. Or use the attached patch.
This "optimizer bug" has been reported here:
https://developercommunity.visualstudio.com/content/problem/237802/optimizer-bug-still-persists.html
--
--gv
--- a/kernels/volk/volk_32f_index_max_16u.h 2016-07-28 15:53:26
+++ b/kernels/volk/volk_32f_index_max_16u.h 2018-06-25 11:28:31
@@ -143,6 +143,23 @@
#include
+/*
+ * To bypass an Optimizer bug in MSVC-2017.
+ * Ref:
+ *
https://developercommunity.visualstudio.com/content/problem/215602/new-optimizer-code-generation-bug.html
+ *
+ * Turn off all optimizations for this function.
+ */
+#if defined(_MSC_VER) && !defined(__clang__)
+ #define OPTIMIZE_OFF() __pragma (optimize ("g", off));
+ #define OPTIMIZE_DEF() __pragma (optimize ("", on));
+#else
+ #define OPTIMIZE_OFF()
+ #define OPTIMIZE_DEF()
+#endif
+
+OPTIMIZE_OFF()
+
static inline void
volk_32f_index_max_16u_a_sse(uint16_t* target, const float* src0,
uint32_t num_points)
@@ -200,6 +217,8 @@
target[0] = (uint16_t)index;
}
+OPTIMIZE_DEF()
+
#endif /*LV_HAVE_SSE*/
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Need help with docs/sphinx
I'm on Windows-10 trying to build the Python docs using
'sphinx-build -b html'. As the README says, it's really
best suited for Unix with it's run_sphinx_build.sh.
Anyway, I tried with this GNU-make snippet
in docs/my-doc.mak:
PY_PATH = $(SITE_DIR)
PYD_PATH = ... all the paths under $(SITE_DIR)/gnuradio here
define generate_sphinx
echo "Creating Sphinx documentation in: $(realpath $(2))."
export PYTHONPATH='$(PY_PATH);$(PYD_PATH);$(PYTHONPATH)' ; \
sphinx-build -q -T --no-color -b html $(1) $(2) 2> sphinx.log
endef
# And BTW, I need to export with PYTHONPATH in quotes, otherwise
# 'bash' complains.
sphinx/source/conf.py: sphinx/source/conf.py.in
sed -e 's|@VERSION@|$(VERSION)|g' \
-e 's|@CMAKE_CURRENT_SOURCE_DIR@|$(realpath sphinx)|g' \
-e 's|@CMAKE_INSTALL_PREFIX@|$(BUILD_DIR)|g' \
-e 's|@GR_PYTHON_DIR@|lib/site-packages|g' < $< >> $@
sphinx: sphinx/source/conf.py
$(call generate_sphinx, sphinx/source, sphinx/out)
--
It doesn't work; I get 15600 lines of traceback and errors in the
sphinx.log file; none (few?) of the .pyd files are found. I think
I'm invoking sphinx-build with the correct PYTHONPATH.
Here is one of those errors:
WARNING: F:\gv\dx-radio\gnuradio\docs\sphinx\source\analog.rst:4:
(WARNING/2) autodoc: failed to import class u'cpm' from module
u'gnuradio.analog';
the following exception was raised:
Traceback (most recent call last):
File "f:\programfiler\python27\lib\site-packages\sphinx\ext\autodoc.py", line
658, in import_object
__import__(self.modname)
File
"F:\gv\dx-radio\gnuradio\MSVC-build\lib\site-packages\gnuradio\analog\__init__.py",
line 33, in
from analog_swig import *
File
"F:\gv\dx-radio\gnuradio\MSVC-build\lib\site-packages\gnuradio\analog\analog_swig.py",
line 26, in
_analog_swig = swig_import_helper()
File "F:\gv\dx-radio\gnuradio\MSVC-build\lib\site-packages\gnuradio\analog\analog_swig.py", line 22, in
swig_import_helper
_mod = imp.load_module('_analog_swig', fp, pathname, description)
ImportError: DLL load failed: The given module was not found << translated from
Norwegian.
---
even though I have a
F:\gv\dx-radio\gnuradio\MSVC-build\lib\site-packages\gnuradio\analog\_analog_swig.pyd
and obviously a 'analog_swig.py' in the correct place, no?
Where is the Swig-generated code expecting the .pyd to exist?
And do I really need all these paths for Sphinx to find it's stuff?
It seems it wants more PATHS than that.
I'm not sure what '@GR_PYTHON_DIR@' should be substituted with.
But with the above, it writes this in the generated shpinx/source/conf.py:
sys.path.insert(0, os.path.abspath('F:/gv/dx-radio/gnuradio/docs/sphinx'))
sys.path.insert(0, 'F:/gv/dx-radio/gnuradio/MSVC-build/lib/site-packages')
Is that correct?
--
--gv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Link error in _blocks_swig10.pyd
I had trouble linking the _blocks_swig10.pyd block.
(some missing '_imp_' symbols).
So I investigated the ./gr-blocks/lib/ code and noticed
there was a missing 'BLOCKS_API' for the classes in
moving_average_XX_impl.h.t. This patch patch fixed it:
--- a/gr-blocks/lib/moving_average_XX_impl.h.t 2017-11-14 20:19:06
+++ a/gr-blocks/lib/moving_average_XX_impl.h.t 2017-11-14 21:48:23
@@ -32,7 +32,7 @@
namespace gr {
namespace blocks {
-class @NAME_IMPL@ : public @NAME@
+class BLOCKS_API @NAME_IMPL@ : public @NAME@
{
private:
int d_length;
--
--gv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [Bulk] Re: How to "kill flowgraph" with a custom block
davidk wrote: > Here is my UDP Server Block Python Code: > > /import numpy > import socket > from gnuradio import gr > from gnuradio import blocks > > UDP_IP = "192.168.10.2" > UDP_PORT = 58 > > sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) > > class serverSource(gr.sync_block): > def __init__(self): > > > gr.sync_block.__init__(self,name="serverSource",in_sig=None,out_sig=[numpy.float32]) > print "Setting up server" > sock.bind((UDP_IP, UDP_PORT)) Shouldn't there be a: sock.listen(1) self.clientsock, _ = sock.accept() here? > def work(self, input_items, output_items): > out = output_items[0] > data, addr = sock.recvfrom(1024) And I guess this should receive from the client sock. Not the server socket. Hence: data, addr = self.clientsock.recvfrom(1024) -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnuradio Windows 3.7.10.1 gqrx fails again?
André Godau wrote: > gqrx fails when trying to start, with the message ...could not find or > load the Qt platform "windows" in "". > I see that`s been an issue (and resolved) before. Can you tell me how to > fix this? There's an empty platforms folder in the Gnuradio tree, I > tried to copy an qwindows.dll from Qt 5.5 into it, but to no avail. Do I > need to set another Env Var (the " could not find...in "" " makes me > wonder). Maybe changing (or deleting) the env-var 'QT_QPA_PLATFORM_PLUGIN_PATH' can change anything. Ref: https://github.com/pyqt/python-qt5/wiki/Qt-Environment-Variable-Reference -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building GNU-Radio for Windows
Rowan Sylvester-Bradley wrote: > jam.c: In function `main': > > jam.c:403: error: `environ' undeclared (first use in this function) > > jam.c:403: error: (Each undeclared identifier is reported only once > > jam.c:403: error: for each function it appears in.) > > pathunix.c:276:19: tchar.h: No such file or directory > > pathunix.c: In function `ShortPathToLongPath': All of these .h-files and symbols are in any normal MingW distro (from mingw.org, TDM-gcc or MinGW-w64). Which one do you use? So I think you're env-vars are not correct: %C_INCLUDE_PATH, %CPLUS_INCLUDE_PATH, etc. PS. GNU-Radio builds a bit better using MSVC-2015 (if you have that). -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Volk: __cpuid_count() for MSVC
I noticed since last time (a year ago) I tried building
Volk using MSVC v16, the volk_cpu.tmp.c now uses the
gcc-centric function '__cpuid_count()' which MSVC doesn't
have.
I'm not really sure if the below patch is correct. But I
assume (from looking at gcc 5.1's source) that the ECX should
be loaded with the 'count' value. So could it be patched into
something like this?
--- a/volk/tmpl/volk_cpu.tmpl.c 2015-09-01 13:52:53
+++ b/volk_cpu.tmpl.c 2015-09-07 13:44:25
@@ -71,8 +71,16 @@
static inline unsigned int cpuid_count_x86_bit(unsigned int level, unsigned int count, unsigned int reg, unsigned int
bit) {
#if defined(VOLK_CPU_x86)
+#if defined(_MSC_VER) && defined(HAVE_INTRIN_H)
+ int regs[4];
+ __cpuidex(regs, level, count);
+#elif defined(__GNUC__)
unsigned int regs[4];
__cpuid_count(level, count, regs[0], regs[1], regs[2], regs[3]);
+#else
+ #error No __cpuid()!
+#endif
return regs[reg] >> bit & 0x01;
#else
return 0;
---
Just to let you know.
The docs on MSVC's __cpuidex() is here:
https://msdn.microsoft.com/en-us/library/vstudio/hskdteyh(v=vs.100).aspx
--
--gv
___
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
Martin Braun wrote: I'm not sure what you're saying/asking here. Maybe the original makes it clear: https://lists.gnu.org/archive/html/discuss-gnuradio/2014-10/msg00044.html It's true we don't have a lot of Windows developers, and if you're willing to take on this issue, it would be appreciated. Trying to build Volk using MSC seems impossible now, so the issue will have to wait. E.g. on volk: volk_cpu.c(85): error C3861: '__cpuid_count': identifier not found Seems to GNU-C is required now (MingW/gcc has this function. MSVC does not). Is this intentional or just another miss? If the former, why the unfriendliness towards MSVC? -- --gv ___ 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 wrote: 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 ... 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. Just a note on this (my almost 1 year old email). Seems there are no Windows users of GnuRadio that needs to play with sockets. I did a "git pull" just now and saw to my dismay that this issue (with using read() + write() on sockets) is still present. According to github, the last change of this (relevant to Winsock) file was on 5 March 2013! --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Illegal CustomBuild for MSVC 18
I have had some more success building Gr using MSVC v18 than MSVC v16 previously (nearly impossible). Besides the high noise-level (due to cmake/msvc/config.h), the C++ building seems fine. But the build stops in 'build\gnuradio-runtime\swig' at some CustomBuild/CustomCommand. Here is from the MSbuild output: if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal call :cmErrorLevel %errorlevel% goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd setlocal !! because of this if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal call :cmErrorLevel %errorlevel% goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd setlocal if %errorlevel% neq 0 goto :cmEnd :cmEnd endlocal call :cmErrorLevel %errorlevel% goto :cmDone :cmErrorLevel exit /b %1 :cmDone if %errorlevel% neq 0 goto :VCEnd Building Custom Rule F:/gv/dx-radio/gnuradio-3.x/gnuradio-runtime/swig/CMakeLists.txt '' is not recognized as an internal or external command, What command in 'gnuradio-runtime\swig\CMakeLists.txt' could trigger this illegal CMD batch snippet? BTW. I generated the .sln/.vcxproj files by a script: setlocal cd build set OPT=-DCMAKE_CXX_COMPILER=cl -DCMAKE_C_COMPILER=cl ^ -DCMAKE_CXX_COMPILER_ENV_VAR=-nologo -O2 -MD ^ -DCMAKE_C_COMPILER_ENV_VAR=-nologo -O2 -MD ^ -Wno-dev -DCMAKE_BUILD_TYPE=Release -DENABLE_TESTING=1 ^ -DPORTAUDIO_LIBRARIES=%MINGW32%/src/Sound/Portaudio/lib/portaudio_static_x86.lib cmake %OPT% -G Visual Studio 12 2013 .. ... -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CMake/ninja error?
I'm having trouble with Cmake and the produced ninja make-files All seems to go well with Cmake -GNinja, but the commands to produce a .res file is wrong. It includes a /MP E.g. if I do a 'ninja.exe gnuradio-runtime', which gives: [1/2] Building RC object gnuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gnuradio-runtime.rc.res FAILED: G:/MingW32/bin/CMake/bin/cmcldeps.exe RC ... /MP /bigobj ... /fognuradio-runtime/lib/CMakeFiles/gnuradio-runtime.dir/gnuradio-runtime.rc.res .. fatal error RC1106: invalid option: /MP ninja: build stopped: subcommand failed. Not sure if this is the fault of Cmake, Ninja or GnuRadio. -- --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] log2() missing in MSVC v16
Tom Rondeau t...@trondeau.com wrote: Also, considering that Windows XP is an unsupported operating system from Microsoft, we don't have much of an incentive to track it or keep things updated there. There isn't much in Gr that absolutely needs Win-Vista+. Except for GetThreadId() which I really have little idea why is needed. But this function could be emulated on pre-Vista. If your patches are trivial and don't bother anything else, then sure. But it looks like your patch here just shoves in the log2 without regard for whether or not log2 actually exists on the system. According to: http://msdn.microsoft.com/en-us/library/hh308239(v=vs.110).aspx log2() is available in VC 2012 onwards. So an #ifdef could test for '_MSC_VER = 1600' I believe. --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] log2() missing in MSVC v16
Hi again.
I finally was able to build most of GR using CMake and
the generated Visual Studio 2010 gnuradio.sln file. Since I'm
not sure if this platform is supported or not, it may be a futile attempt.
I patched cmake/msvc/config.h since I figured that was the active one.
IMHO it's confusing that 'volk\cmake\msvc\config.h' seems to include
almost the same stuff.
Well, volk now uses the log2() function which my MSVC v16
doesn't have. And multiply_matrix_ff_impl.cc etc. uses these
ISO-646 keywords like 'not', 'and' etc. I solved these errors by
patching cmake/msvc/config.h like so:
@@ -29,6 +29,16 @@
static inline double rint(double x){return (x 0.0)? floor(x + 0.5) : ceil(x -
0.5);}
static inline float rintf(float x){return (x 0.0f)? floorf(x + 0.5f) :
ceilf(x - 0.5f);}
+static inline double log2 (double x)
+{
+ return log ((double)x) / log (2.0F);
+}
+
+// Use of ISO-646 keyword ('not', 'and' etc. needs this header.
+#ifdef __cplusplus
+#include ciso646
+#endif
+
(the cast in log2() was need to resolve any C++ ambiguty).
Not sure if this hurts if VC 2012+ already have log2() in it's math.h.
BTW.
Here is how I used VC 2010 Express to build:
cmake -G Visual Studio 10 2010
msbuild -nologo -p:Configuration=Release -fileLogger
-fileLoggerParameter:Summary;Verbosity=minimal;LogFile=gnuradio-build.log gnuradio.sln
Anybody else having success with VC 2010? Or are you Windows users
(Ettus?) using VS 2012 only? Seems like Win-XP is unsupported since I get
a call to the non-existant GetThreadId(). It's in kernel32.dll, but on Vista+
only.
--gv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Exports in _runtime_swig.pyd
I'm still trying to understand the build-process and internals of GnuRadio. While trying to build the Swig .pyd modules, I notice that gnuradio-runtime/swig/runtime_swig.i has a: #define GR_RUNTIME_API Thus functions/vars in _runtime_swig.pyd gets a dllexport linkage. But comparing to gnuradio-runtime/swig/pmt_swig.i there is no PMT_API at the top. Why the difference? --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Exports in _runtime_swig.pyd
I wrote: Thus functions/vars in _runtime_swig.pyd gets a dllexport linkage. But comparing to gnuradio-runtime/swig/pmt_swig.i there is no PMT_API at the top. Why the difference? Further to the problem I had with linking in the Swig code for this: extern const pmt_t PMT_T; (in pmt_swig.i) This may work fine with the GNU linker, but MSVC needs explicit dllimport. So I patched pmt_swig.i like this: --- pmt_swig.i.orig 2014-09-24 13:48:36 + +++ pmt_swig.i2014-10-19 14:51:19 + @@ -80,11 +80,6 @@ swig_int_ptr.__repr__ = lambda self: write_string(self) %} - - extern const pmt_t PMT_T; - extern const pmt_t PMT_F; - extern const pmt_t PMT_EOF; - pmt_t get_PMT_NIL(); #define PMT_NIL get_PMT_NIL() - pmt/pmt.h already has the proper import decoration. No point declaring those with 'extern'. So now .py examples using _pmt_swig.pyd works just fine. I noted in the Ettus Gr installation, there where no _pmt_swig.pyd. Maybe that's due to the problem they had with link that on Windows. Seems imposible w/o correct DLL-linkage. --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MSVC v16 'static const' error
I just got this error from MSVC v16 while trying to compile
atsc_sync_impl.cc:
g:\gv\dx-radio\gnuradio-3.x\gr-dtv\lib\atsc\atsc_sync_impl.h(37) :
error C2864: 'gr::dtv::atsc_sync_impl::LOOP_FILTER_TAP' : only static const
integral data members can be initialized within a class
g:\gv\dx-radio\gnuradio-3.x\gr-dtv\lib\atsc\atsc_sync_impl.h(38) :
error C2864: 'gr::dtv::atsc_sync_impl::ADJUSTMENT_GAIN' : only static const
integral data members can be initialized within a class
The code works fine with g++ 4.7.2. I figured these 'private const data'
had to be initialised in the .cc-file. Here is how I patched it:
--- atsc_sync_impl.cc.orig 2014-08-18 22:46:57 +
+++ atsc_sync_impl.cc 2014-10-15 19:14:01 +
@@ -31,6 +31,9 @@
namespace gr {
namespace dtv {
+const double atsc_sync_impl::LOOP_FILTER_TAP = 0.0005; // 0.0005 works
+const double atsc_sync_impl::ADJUSTMENT_GAIN = 1.0e-5 / (10 *
ATSC_DATA_SEGMENT_LENGTH);
+
atsc_sync::sptr
atsc_sync::make(float rate)
{
--- atsc_sync_impl.h.orig2014-08-18 22:46:57 +
+++ ./atsc_sync_impl.h 2014-10-15 19:24:45 +
@@ -34,8 +34,8 @@
class atsc_sync_impl : public atsc_sync
{
private:
- static const double LOOP_FILTER_TAP = 0.0005;// 0.0005 works
- static const double ADJUSTMENT_GAIN = 1.0e-5 / (10 *
ATSC_DATA_SEGMENT_LENGTH);
+ static const double LOOP_FILTER_TAP; // = 0.0005
+ static const double ADJUSTMENT_GAIN; // = 1.0e-5 / (10 *
ATSC_DATA_SEGMENT_LENGTH);
static const int SYMBOL_INDEX_OFFSET = 3;
static const int MIN_SEG_LOCK_CORRELATION_VALUE = 5;
static const int SSI_MIN = -16;
--gv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building with MSVC v16
Tom Rondeau t...@trondeau.com wrote: Just to begin with, we do not currently have good support and testing for Windows systems and are actively discussing how to handle this OS. I believe that any support for Windows at all, such as through the current binaries provided by Ettus Research, require VS 2012 or something (really not sure, but I believe later than what you're using). I use VS 2010 and Ettus, yes seems to be using VS 2012. I fail to see why VS 2010 isn't good enough. It was little tweaking to get it to work. No they add nothing and I'm not a fan of them. My guess is that some of it was that code was prototyped in Python and converted over to C++ and these were carried along with it. It's a hard thing to grep for, but I'll be patching a few of the cases that I found. Adding a #include iso646.h to my specially crafted config.h fixed that. GCC includes that unconditionally (thanks to Josh Blum for tipping me on that). --gv ___ 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
[Discuss-gnuradio] Building with MSVC v16
Hi list. I've managed to build Gr using MingW. Now trying the same using Visual C Express 2010 (cl 16), gives me some troubles. I'm just adding all my points here instead of multiple emails. *) reed-solomon/*.[ch] needs 'FIXED' to be defined since my cl doesn't support variable arrays. What bad could happen with 'FIXED' defined? Besides '-DFIXED' clashes enormously with the wingdi.h header. So what about 'GR_FIXED_ARRAYS' instead? *) The special C++10 (?) features like 'not', 'and' and 'or' doesn't work here. Do they really bring anything new to Gr? Ref. gr-blocks/lib/multiply_matrix_ff_impl.cc etc. *) gr-fcd/lib/hid/hid-libusb.c doesn't have a config.h test. I get tons of errors if it's not these. I added pthreads-w32 to make it work, but I'm not sure it's a good idea. Are you supporting HID devices on Windows at all? *) gr-fec/lib/ber_tools.cc should IMHO have a config.h too. *) In gr-blocks/tests/benchmark_nco.cc and gr-blocks/tests/benchmark_vco.cc: #include gnuradio/blocks/nco.h #include gnuradio/blocks/fxpt_nco.h Shouldn't that be: #include gnuradio/nco.h #include gnuradio/fxpt_nco.h Seems like an oversigth (*nco.h was once under gr-blocks?) Or could it be trouble at my end? --gv ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Some fairy C++ error in gr-filter
Hi list. My 1st post here.
I have a big problem with CMake and some of the generated
files under gr-filter/lib. E.g. here is a snippet from it:
#include fir_filter_ccc.h
#include gnuradio/io_signature.h
#include volk/volk.h
namespace gr {
namespace filter {
fir_filter_ccc::sptr
fir_filter_ccc::make(int decimation, const std::vectorgr_complex taps)
{
return gnuradio::get_initial_sptr(new fir_filter_ccc
(decimation, taps)); /// line 40
}
At line 40 my g++ 4.7.2 starts yelling w/o me understanding what it says.
Here is the 1st error (edited):
fir_filter_ccc_impl.cc: In static member function 'static
gr::filter::fir_filter_ccc::
sptr gr::filter::fir_filter_ccc::make(int, const std::vectorstd::complexfloat
)':
fir_filter_ccc_impl.cc:40:23: error: cannot allocate an object of abstract type
'gr::filter::fir_filter_ccc'
What's this? Is this because 'FILTER_API' is an dllexport? Or is my
fir_filter_ccc_impl.cc generated incorrectly? What is that file and
fir_filter_ccc.h supposed to look like?
Some info for you: 'g++ -fconserve-space -c -DDEBUG -g -O1 -Wall' ..etc.
Thanks in advance.
--gv
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
