Re: Use /dev/swradioN (v4l2 api) as source
Franco, as far as I understand this, the libraries like libmirisdr and librtlsdr do not use the v4l2 kernel driver at all, they use libusb to connect to the devices and the driver is implemented in user-space. I looked into the v4l2 documentation and the example fm radio, it's not exactly easy to implement a device control using ioctl. Also there seem to be better ways to read the data than just reading the device (asynchronous DMA techniques with special buffers). As I couldn't find any GNURadio source block being able to use the v4l2 API, I assume it's not easy to write. For now I'll stick with SoapyMiri (it seems that libmirisdr is just more picky what USB connector is used, using another one I could solve the dropped samples). Best regards Stefan Am 14.06.22 um 04:41 schrieb Franco VENTURI: Stefan, if I were you I would contact the author of that SoapyMiri driver on GitHub about your problems with it, since to me he seems interested in improving it and he probably would be able to run some tests on his setup to troubleshoot and fix those issues. As per my comment about using the kernel API directly, the word 'directly' was not a good choice; I meant it in the sense of connecting from your userland application 'directly' to the kernel (as opposed via a library or a module like SoapyMiri). This said, if you just want to stream directly from that device /dev/swradioN, I believe it is a character device that streams I/Q samples as 16bit shorts (this is what I remember from long ago; please double check it). In this case I think you should be able to read from it using a GNU Radio file source block with a type of 'complex short' (you shouldn't need a throttle block because the sample rate is decided by your /dev/swradioN device). The limitation of this approach is that it is good only for the streaming part; the control part (like selecting sample rate, frequency, possibly filters, etc) is probably through specialized ioctl() calls to that device (again you may want to double check that), so either you rely on an external application for that or you would have to write an OOT GNU Radio module (or perhaps someone already did, I am not sure). Franco On 06/13/2022 8:47 PM Stefan Oltmanns wrote: Thank you very much for that information, haven't seen that somebody continued the work on libmirisdr. I was able to get it working with an OsmoSDR Source using soapy=0,driver=soapyMiri I had to modify the SoapyMiri driver, as OsmoSDR sets the bandwidth to 3/4 of the sample rate, but there are only certain fixed bandwidth values allowed, otherwise SoapyMiri will throw a runtime error (maybe it should find the closest allowed value). For now I hardcoded a bandwidth value and it works, but... I get a lot of dropped samples, not suitable for practical use. This doesn't happen with the kernel driver. You said "instead of using the kernel API directly", is there anything that is using the kernel API indirectly? I couldn't find any GNURadio plug-in that is using the SDR kernel API provided by v4l2 at all. Best regards Stefan gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.3.0-rc1 built-in source types: file rtl rtl_tcp rfspace soapy redpitaya [INFO] Opening Mirics MSi2500 default (e.g. VTX3D card) :: 0001... failed to open miri usb device 0 with code -3 Traceback (most recent call last): File "/home/stefan/miri_test.py", line 188, in main() File "/home/stefan/miri_test.py", line 166, in main tb = top_block_cls() File "/home/stefan/miri_test.py", line 117, in __init__ self.osmosdr_source_0 = osmosdr.source( RuntimeError: Unable to open LibMiriSDR device. Am 14.06.22 um 00:28 schrieb Franco VENTURI: Stefan, instead of using the kernel API directly you may want to look into a SoapySDR source in GNU Radio, since the SoapySDR block is now a first class citizen in GNU Radio 3.9/3.10 According to this recent discussion in the SoapySDR GitHub repository (https://github.com/pothosware/SoapySDR/issues/359) there's a SoapyMiri driver (https://github.com/ericek111/SoapyMiri) that might work for you. A comment in the same thread (https://github.com/pothosware/SoapySDR/issues/359#issuecomment-1150982319) has also instructions about integrating his fixes in OsmoSDR, if I understand correctly. I personally haven't tried this approach so I don't really know if it works or not, but I thought you might find this information useful. Franco On 06/13/2022 3:26 PM Stefan Oltmanns wrote: Hello, is there any way to use devices exposed as /dev/swradioN by the v4l2 Linux kernel API with GNURadio directly? At the moment there are only two in-tree kernel drivers, one for the RTL2832U and the other for the Mirics MSi2500. For the RTL2832U librtlsdr seems to be the better option, as it offers more features to control the device, but libmirisdr see
Re: Use /dev/swradioN (v4l2 api) as source
Thank you very much for that information, haven't seen that somebody continued the work on libmirisdr. I was able to get it working with an OsmoSDR Source using soapy=0,driver=soapyMiri I had to modify the SoapyMiri driver, as OsmoSDR sets the bandwidth to 3/4 of the sample rate, but there are only certain fixed bandwidth values allowed, otherwise SoapyMiri will throw a runtime error (maybe it should find the closest allowed value). For now I hardcoded a bandwidth value and it works, but... I get a lot of dropped samples, not suitable for practical use. This doesn't happen with the kernel driver. You said "instead of using the kernel API directly", is there anything that is using the kernel API indirectly? I couldn't find any GNURadio plug-in that is using the SDR kernel API provided by v4l2 at all. Best regards Stefan gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.3.0-rc1 built-in source types: file rtl rtl_tcp rfspace soapy redpitaya [INFO] Opening Mirics MSi2500 default (e.g. VTX3D card) :: 0001... failed to open miri usb device 0 with code -3 Traceback (most recent call last): File "/home/stefan/miri_test.py", line 188, in main() File "/home/stefan/miri_test.py", line 166, in main tb = top_block_cls() File "/home/stefan/miri_test.py", line 117, in __init__ self.osmosdr_source_0 = osmosdr.source( RuntimeError: Unable to open LibMiriSDR device. Am 14.06.22 um 00:28 schrieb Franco VENTURI: Stefan, instead of using the kernel API directly you may want to look into a SoapySDR source in GNU Radio, since the SoapySDR block is now a first class citizen in GNU Radio 3.9/3.10 According to this recent discussion in the SoapySDR GitHub repository (https://github.com/pothosware/SoapySDR/issues/359) there's a SoapyMiri driver (https://github.com/ericek111/SoapyMiri) that might work for you. A comment in the same thread (https://github.com/pothosware/SoapySDR/issues/359#issuecomment-1150982319) has also instructions about integrating his fixes in OsmoSDR, if I understand correctly. I personally haven't tried this approach so I don't really know if it works or not, but I thought you might find this information useful. Franco On 06/13/2022 3:26 PM Stefan Oltmanns wrote: Hello, is there any way to use devices exposed as /dev/swradioN by the v4l2 Linux kernel API with GNURadio directly? At the moment there are only two in-tree kernel drivers, one for the RTL2832U and the other for the Mirics MSi2500. For the RTL2832U librtlsdr seems to be the better option, as it offers more features to control the device, but libmirisdr seems to unmaintained and not stable (at least for me), support has been removed from OsmoSDR years ago. I do have such a Dongle and with the kernel driver it seems to work just fine. I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2 source block could be very useful. Is there any specific reason, why such a source block doesn't exist yet? Or is it just that nobody needed it and therefore no one bothered writing one? Best regards Stefan
Use /dev/swradioN (v4l2 api) as source
Hello, is there any way to use devices exposed as /dev/swradioN by the v4l2 Linux kernel API with GNURadio directly? At the moment there are only two in-tree kernel drivers, one for the RTL2832U and the other for the Mirics MSi2500. For the RTL2832U librtlsdr seems to be the better option, as it offers more features to control the device, but libmirisdr seems to unmaintained and not stable (at least for me), support has been removed from OsmoSDR years ago. I do have such a Dongle and with the kernel driver it seems to work just fine. I also found an out-of-tree driver for CX2388x-based TV cards, so a V4L2 source block could be very useful. Is there any specific reason, why such a source block doesn't exist yet? Or is it just that nobody needed it and therefore no one bothered writing one? Best regards Stefan
Re: [Discuss-gnuradio] Disable some paths of the flowgraph without stopping (C++)
Hello, I'm not using GRC, it's an C++ application with no Python at all. That is the flowgraph: I've got one OsmoSource, to that are connected several paths like this: freq xlating fir filter -> quadrature demod -> fir filter -> custom sink And one path like: freq xlating fir filter -> stream to vector -> fft -> complex to mag squared -> nlog10 -> custom calibration sink I'm demodulating and decoding several signals at once, one problem is that the RTL SDR tuner is not very frequency stable, so I've created the calibration path. I just need to provide a reference frequency, and the application will make a FFT of that area and my custom sink will provide an floating average of the maximum position, the maximum level and the average level. With that data the application can decide if it has picked up the reference and calculate the correction factor. That all works fine, but I would like to disconnect the calibration path when it's not needed to safe resources. But when the freq xlating fir filter of the calibration path is not connected to the source I'll get a segfaut. Best regards Stefan Am 06.11.2017 um 01:24 schrieb Brashendeavours: > Hello, > > It all depends on your use case and potential for reuse, as well as if you > are using Gnuradio Companion. If you use GRC to layout and generate your > flow graphs, they will overwrite any custom code you add to the top_block.py. > > Your understanding of the use of the null sink or zero source is right, if > you want to disconnect and manipulate the structure of your flowgraph while > it is running. > Your hier black could also simply disconnect, and instantiate new blocks as > required. > > Could you supply a diagram (through GRC/or otherwise) to help explain what > you want to achieve? > > Blake > >> On Nov 5, 2017, at 1:35 PM, Stefan Oltmanns wrote: >> >> Hello Blake, >> >> can you explain what the advantage of using a hier block is? At the >> moment I cannot see any advantage if I use this kind of block >> combination only once. >> >> I'm sorry, but I don't understand how a null sink alone helps me. If I >> disconnect the path I've got an unconnected input, no unconnected output. >> >> What I think could work is a real null source (IMHO the null source in >> GNU Radio is a zero source) that is connected to a null sink, which by >> itself is pretty useless, but then I could switch the block from the >> real source to the null source whether it should be en- or disabled. >> >> Am I thinking wrong? Any better idea? >> >> Best regards >> Stefan >> >> >>> Am 05.11.2017 um 18:40 schrieb Brashendeavours: >>> Stefan, >>> >>> Consider wrapping the blocks you want to switch in/out in a hier block. >>> Use the setter functions of the hier block parameters to: >>> 1. lock the flow graph >>> 2. swap in/out the null sink(s) [1] >>> 3. unlock the flowgraph >>> >>> [1] https://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1null__sink.html >>> >>> Respectfully, >>> Blake >>> >>> >>> >>> Sent from my iPhone >>>> On Nov 4, 2017, at 7:13 PM, Stefan Oltmanns >>>> wrote: >>>> >>>> Hello, >>>> >>>> I've got a flowgraph with one source that will end in several sinks. Not >>>> all paths of the flowgraph are needed all the time and I would like to >>>> enable/disable a path without stopping the flowgraph to reduce processor >>>> load. >>>> When I leave a path unconnected by default the application will crash. >>>> I've seen there is a (deprecated) Valve block implemented in Python, but >>>> I'm all C++. >>>> >>>> Is there a solution in C++? >>>> If there is not, I could probably write a custom block that could either >>>> just return 0 from work function or copy all data from input to output, >>>> but I don't like the idea of copying the data, is there a way to just >>>> handover the pointer? >>>> >>>> Best regards >>>> Stefan >>>> >>>> >>> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Disable some paths of the flowgraph without stopping (C++)
Hello Blake, can you explain what the advantage of using a hier block is? At the moment I cannot see any advantage if I use this kind of block combination only once. I'm sorry, but I don't understand how a null sink alone helps me. If I disconnect the path I've got an unconnected input, no unconnected output. What I think could work is a real null source (IMHO the null source in GNU Radio is a zero source) that is connected to a null sink, which by itself is pretty useless, but then I could switch the block from the real source to the null source whether it should be en- or disabled. Am I thinking wrong? Any better idea? Best regards Stefan Am 05.11.2017 um 18:40 schrieb Brashendeavours: > Stefan, > > Consider wrapping the blocks you want to switch in/out in a hier block. > Use the setter functions of the hier block parameters to: > 1. lock the flow graph > 2. swap in/out the null sink(s) [1] > 3. unlock the flowgraph > > [1] https://gnuradio.org/doc/doxygen/classgr_1_1blocks_1_1null__sink.html > > Respectfully, > Blake > > > > Sent from my iPhone >> On Nov 4, 2017, at 7:13 PM, Stefan Oltmanns wrote: >> >> Hello, >> >> I've got a flowgraph with one source that will end in several sinks. Not >> all paths of the flowgraph are needed all the time and I would like to >> enable/disable a path without stopping the flowgraph to reduce processor >> load. >> When I leave a path unconnected by default the application will crash. >> I've seen there is a (deprecated) Valve block implemented in Python, but >> I'm all C++. >> >> Is there a solution in C++? >> If there is not, I could probably write a custom block that could either >> just return 0 from work function or copy all data from input to output, >> but I don't like the idea of copying the data, is there a way to just >> handover the pointer? >> >> Best regards >> Stefan >> >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Disable some paths of the flowgraph without stopping (C++)
Hello, I've got a flowgraph with one source that will end in several sinks. Not all paths of the flowgraph are needed all the time and I would like to enable/disable a path without stopping the flowgraph to reduce processor load. When I leave a path unconnected by default the application will crash. I've seen there is a (deprecated) Valve block implemented in Python, but I'm all C++. Is there a solution in C++? If there is not, I could probably write a custom block that could either just return 0 from work function or copy all data from input to output, but I don't like the idea of copying the data, is there a way to just handover the pointer? Best regards Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest Gnuradio git won't compile on OS X
See: http://llvm.org/bugs/show_bug.cgi?id=9665 When I understand that correctly it´s a bug in the intel avx header files. The solution is either use other header files or do not use const int, but literal values or enum. Best regards Stefan Am 24.10.2014 21:15, schrieb West, Nathan: > The intel docs specify that function as taking a const int, so I'm not > sure why that wouldn't work but the literal value would. Although I'm > basically fine with using the literal value, I feel like the "correct" > thing to do is use a const int here. At a minimum I'd like to at least > understand what's happening. > > * Is this caused by a specific version of clang that is introduced by > the OS upgrade? (aka can I install a version of clang to test this on > linux) > * Are there some "be super strict about const parameters" flags being > passed in that haven't been previously? > * Is there some compiler cache issue that caused your const change to > be silently ignored? > > If you're willing to test #3 that would be great. If you can provide a > command line used to compile (make VERBOSE=1 > file; parse file for > this build command) and a clang version I might be able to tinker with > this. I'm assuming here that clang on Macs is not modified from the > publicly available clang (I don't actually know if that's true or > not). > > Nathan > > On Thu, Oct 23, 2014 at 7:57 PM, Michael Dickens > wrote: >> Oh goody! I have a MacPorts ticket with this issue, and my AVX Mac is >> currently unavailable for fixing this. Maybe somebody (Nathan? Tom?) can >> figure out the correct fix? - MLD >> >> On Oct 23, 2014, at 1:52 PM, Stefan Oltmanns wrote: >> >>> Adding const did not fix the problem, so I gave the 0xdd / 0x88 directly >>> as shuffle mask parameter in _mm256_shuffle_ps, then it compiles without >>> any problems (same fix for volk_32fc_deinterleave_imag_32f.h) >> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stop() and wait() on topblock does not work on OS X
I just compiled against latest gnuradio from git, still the same problem.
Best regards
Stefan
Am 25.09.2014 19:51, schrieb Michael Dickens:
> Mine outputs (in gdb):
> {{{
> gr-osmosdr v0.1.3-1-g4bb2fa4e (0.1.4git) gnuradio v3.7.x-xxx-xunknown
> built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace
> [Reading symbols for shared libraries . done]
> Using device #0 Realtek RTL2838UHIDIR SN: 0001
> Found Rafael Micro R820T tuner
>
> Program exited normally.
> (gdb)
> }}}
>
> Can you try updating GNU Radio to the latest GIT master? You'll have to
> reinstall gr-osmosdr too. I'm installing the 10.10 preview right now for GR
> / UHD testing; I'll try this code on 10.10 and 10.9 soon. - MLD
>
> On Sep 25, 2014, at 1:15 PM, Stefan Oltmanns wrote:
>
>> The NooElec R820T
>> (http://www.nooelec.com/store/sdr/sdr-receivers/nesdr-mini-rtl2832-r820t.html)
>> looks exactly like my R820T device, just a different branding. The
>> output I get:
>>
>> gr-osmosdr v0.1.3-1-g4bb2fa4e (0.1.4git) gnuradio 3.7.5
>> built-in source types: file fcd rtl rtl_tcp rfspace
>> Using device #0 Realtek RTL2838UHIDIR SN: 0001
>> Found Rafael Micro R820T tuner
>>
>> I compiled with the same command-line, unfortunately I do not have
>> access to a 10.8 mac.
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Latest Gnuradio git won't compile on OS X
Adding const did not fix the problem, so I gave the 0xdd / 0x88 directly
as shuffle mask parameter in _mm256_shuffle_ps, then it compiles without
any problems (same fix for volk_32fc_deinterleave_imag_32f.h)
Thank you very much
Stefan
Am 23.10.2014 19:50, schrieb West, Nathan:
> On Thu, Oct 23, 2014 at 12:37 PM, Stefan Oltmanns
> wrote:
>> I just got the latest git version of gnuradio and tried to compile, but
>> I get compilation errors resulting from avxintrin.h:
>>
>> http://pastebin.com/uq4uGeNs
>>
>> These errors seems to be common and result from using non-standard
>> GCC-extensions that clang does not support.
>>
>> Any ideas?
>
> This is a recently introduced bug; thanks for the report!
>
> This is apparently because clang is stricter than gcc on constant
> arguments. The shuffle parameter is defined as an int rather than
> const int. The same instruction/function has been used for a long time
> without any problems, but in other cases we always give the literal
> value rather than a variable.
>
> Since you're building from source I'll assume you might be able to try
> this patch out:
>
> --- a/volk/kernels/volk/volk_32fc_deinterleave_32f_x2.h
> +++ b/volk/kernels/volk/volk_32fc_deinterleave_32f_x2.h
> @@ -42,8 +42,8 @@ static inline void
> volk_32fc_deinterleave_32f_x2_a_avx(float* iBuffer, float* qB
>
>unsigned int number = 0;
>// Mask for real and imaginary parts
> - int realMask = 0x88;
> - int imagMask = 0xdd;
> + const int realMask = 0x88;
> + const int imagMask = 0xdd;
>const unsigned int eighthPoints = num_points / 8;
>__m256 cplxValue1, cplxValue2, complex1, complex2, iValue, qValue;
>for(;number < eighthPoints; number++){
>
> Otherwise, just roll back to a commit before we merged in the volk
> gsoc work (1-2 weeks, I think).
>
> Nathan
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Latest Gnuradio git won't compile on OS X
I just got the latest git version of gnuradio and tried to compile, but I get compilation errors resulting from avxintrin.h: http://pastebin.com/uq4uGeNs These errors seems to be common and result from using non-standard GCC-extensions that clang does not support. Any ideas? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stop() and wait() on topblock does not work on OS X
The NooElec R820T
(http://www.nooelec.com/store/sdr/sdr-receivers/nesdr-mini-rtl2832-r820t.html)
looks exactly like my R820T device, just a different branding. The
output I get:
gr-osmosdr v0.1.3-1-g4bb2fa4e (0.1.4git) gnuradio 3.7.5
built-in source types: file fcd rtl rtl_tcp rfspace
Using device #0 Realtek RTL2838UHIDIR SN: 0001
Found Rafael Micro R820T tuner
I compiled with the same command-line, unfortunately I do not have
access to a 10.8 mac.
Am 25.09.2014 18:25, schrieb Michael Dickens:
> On Sep 25, 2014, at 10:22 AM, Stefan Oltmanns wrote:
>> Unfortunately I do not have any other hardware than two different RTL
>> devices (one with E4000 tuner and one with R820T).
>> I attached the most simple program to reproduce that error, it just
>> connects the OsmoSDR source with a null sink, starts the flowgraph,
>> waits a second and then stops it and exit.
>> Working fine on Linux and Windows, but not on OS X (10.9), program never
>> returns. Same problem with all stuff (boost/libusb...) self build or
>> installed using ports.
>> Is someone able to find the bug?
>
> I compiled your code using
> {{{
> c++ -O2 -I/opt/local/include -L/opt/local/lib -lgnuradio-osmosdr
> -lgnuradio-runtime -lgnuradio-blocks -lboost_system-mt -Wall -o osmo_test
> osmo_test.cc
> }}}
> then tried it using the following devices without issues (returns cleanly),
> using MacPorts for all of the software installs, running on OSX 10.8.5
> (latest updates), Xcode 5.1.1 (Build version 5B1008):
>
> + HackRF Jawbreaker
> + NooElec R820T
> + ER B210
>
> I'll try on 10.9 shortly, since maybe this is an OS specific issue. - MLD
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stop() and wait() on topblock does not work on OS X
Unfortunately I do not have any other hardware than two different RTL
devices (one with E4000 tuner and one with R820T).
I attached the most simple program to reproduce that error, it just
connects the OsmoSDR source with a null sink, starts the flowgraph,
waits a second and then stops it and exit.
Working fine on Linux and Windows, but not on OS X (10.9), program never
returns. Same problem with all stuff (boost/libusb...) self build or
installed using ports.
Is someone able to find the bug?
Thanks
Stefan
Am 23.09.2014 09:06, schrieb Sylvain Munaut:
>> Ah; OK. Running osmocom_fft using a HackRF Jawbreaker and everything works
>> OK; I can do "stop", "run", and close without issues. Maybe this issue is
>> specific to some RTL device(s) rather than OSX? - MLD
>
> Well, it definitely works with rtl on linux, but it wouldn't suprise
> me if the issue was specific to the combination OSX+rtl since the
> 'stop' path is highly dependent of the hw driver and its interactions
> with libusb.
>
> Cheers,
>
> Sylvain
>
#include
#include
#include
#include
int main(int argc, char **argv)
{
double rate = 240.0;
gr::top_block_sptr tb = gr::make_top_block("test");
osmosdr::source::sptr osmo_source = osmosdr::source::make( "numchan=1" );
osmo_source->set_sample_rate(rate);
gr::blocks::null_sink::sptr sink =
gr::blocks::null_sink::make(sizeof(gr_complex));
tb->connect(osmo_source, 0, sink, 0);
tb->start();
usleep(100);
tb->stop();
tb->wait();
return 0;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] stop() and wait() on topblock does not work on OS X
Hi Michael, sorry, my mistake. I introduced a stupid bug in my short test program with a sine source so I got a similar result like in my complete program, although GnuRadio is working fine. The problem is probably located somewhere in OsmoSDR/rtl-sdr/libusb. Without any hardware connected (OsmoSDR generates null source) it´s working fine, with a RTL-Stick connected it doesn´t work. I tried two different ones (E4000 and R820T tuner), same result. Unfortunately I do not have any other hardware to test. Oh, I won´t be on GRCon, flying to another continent just to get some bugs fixed is probably a bit too much. Thanks Stefan Am 18.09.2014 17:11, schrieb Michael Dickens: > Hi Stefan - Do you have an example program that I could do testing on? That > would help expedite any fix. Thanks! - MLD > > On Sep 18, 2014, at 10:39 AM, Stefan Oltmanns wrote: >> my C++ program is already working great, except one major bug on OS X: >> >> I cannot stop the flowgraph: When I call on the top block: >> >> gr_tb->stop(); >> gr_tb->wait(); >> >> It will hang on the wait. That means the program cannot quit nicely, but >> will always crash at exit. It´s working fine on Linux and Windows. >> Is there some known problem? >> >> First I installed GnuRadio using macports (removed and then installed >> from source using depencies from macports). >> Then I removed all the macports stuff and installed all dependencies >> myself (with boost 1.56), same problem. > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reset() for probe_avg_mag_sqrd
Hi, I´m sorry, I just looked at that issue just before writing that mail, he must have updated that while I was writing the mail. And no, I was not discouraged, I´ve been on holiday the last weeks, that´s why I did not response the last weeks. Anyway, I created a git branch like requested, I never really worked with gut before, so I just followed a guide, but in the last step I´ll get an error: Cannot access URL http://gnuradio.org/git/gnuradio.git/, return code 22 fatal: git-http-push failed What am I doing wrong? Do I need somekind of login data? I set my name and email using git config, but I was never asked for username/password? Best regards Stefan Am 22.08.2014 12:09, schrieb Martin Braun: > Stefan, > > Johnathan asked you a couple of questions regarding your patch. I'm not > sure if you've already answered him, but the usual approach here is that > we continue patch-related discussions on the issue tracker. So what it > looks like from here is that's actually stalling on you :) > > Once things are in the issue tracker, they don't get forgotten. However, > sometimes it takes longer to merge/address things. Hope this doesn't > discourage you or any other contributor. > > Cheers, > M > > On 08/21/2014 07:43 PM, Stefan Oltmanns wrote: >> Hi, >> I posted the issue with a patch about 2 weeks ago, I´m not sure anybody >> has seen it yet: >> http://gnuradio.org/redmine/issues/709 >> Would be great if it could be included. >> >> Thanks >> Stefan >> >> >> Am 04.08.2014 11:05, schrieb Martin Braun: >>> Stefan, >>> >>> this might be useful, can you post an issue on gnuradio.org, and >>> describe as clearly as possible what you need? A patch, even if small, >>> also helps to make things clearer for us. >>> >>> M >>> >>> On 08/02/2014 07:50 PM, Stefan Oltmanns wrote: >>>> Hello, >>>> >>>> my application is monitoring the RF level and often changeing the >>>> frequency. Unfortunately it takes some time for probe_avg_mag_sqrd to >>>> adjust to the new RF level (about 2 seconds if old level -10dB and new >>>> level -40dB). >>>> I found out the the iir-filter probe_avg_mag_sqrd uses has a reset >>>> function, so all I did was adding a reset-function in probe_avg_mag_sqrd >>>> to call it and it seems so work fine. >>>> Is there any reason probe_avg_mag_sqrd doesn´t have a reset function >>>> yet? Is there some problem I don´t see? >>>> In case not, could that be added in official GNURadio? Otherwise my >>>> application would only work with modified GNURadio (or I would need to >>>> include my modified probe_avg_mag_sqrd with a new name in my >>>> appliaction). I would prefer to have this feature in official GNURadio, >>>> as it´s probably useful for somebody else as well. >>>> >>>> Best regards >>>> Stefan >>>> >>>> >>>> Note: I´m not sending a patch because it´s just 3 lines of code and I >>>> don´t know Python, so somebody else would have to complete it anyway. >>>> >>>> ___ >>>> 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 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] stop() and wait() on topblock does not work on OS X
Hi, my C++ program is already working great, except one major bug on OS X: I cannot stop the flowgraph: When I call on the top block: gr_tb->stop(); gr_tb->wait(); It will hang on the wait. That means the program cannot quit nicely, but will always crash at exit. It´s working fine on Linux and Windows. Is there some known problem? First I installed GnuRadio using macports (removed and then installed from source using depencies from macports). Then I removed all the macports stuff and installed all dependencies myself (with boost 1.56), same problem. Best regards Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] reset() for probe_avg_mag_sqrd
Hi, I posted the issue with a patch about 2 weeks ago, I´m not sure anybody has seen it yet: http://gnuradio.org/redmine/issues/709 Would be great if it could be included. Thanks Stefan Am 04.08.2014 11:05, schrieb Martin Braun: > Stefan, > > this might be useful, can you post an issue on gnuradio.org, and > describe as clearly as possible what you need? A patch, even if small, > also helps to make things clearer for us. > > M > > On 08/02/2014 07:50 PM, Stefan Oltmanns wrote: >> Hello, >> >> my application is monitoring the RF level and often changeing the >> frequency. Unfortunately it takes some time for probe_avg_mag_sqrd to >> adjust to the new RF level (about 2 seconds if old level -10dB and new >> level -40dB). >> I found out the the iir-filter probe_avg_mag_sqrd uses has a reset >> function, so all I did was adding a reset-function in probe_avg_mag_sqrd >> to call it and it seems so work fine. >> Is there any reason probe_avg_mag_sqrd doesn´t have a reset function >> yet? Is there some problem I don´t see? >> In case not, could that be added in official GNURadio? Otherwise my >> application would only work with modified GNURadio (or I would need to >> include my modified probe_avg_mag_sqrd with a new name in my >> appliaction). I would prefer to have this feature in official GNURadio, >> as it´s probably useful for somebody else as well. >> >> Best regards >> Stefan >> >> >> Note: I´m not sending a patch because it´s just 3 lines of code and I >> don´t know Python, so somebody else would have to complete it anyway. >> >> ___ >> 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 mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Hi Michael, yes, I have not modified my program at all: I added a #error "Broken allocation engine" to volk_malloc.c at the beginning of the other allocation engine. I tried to recompile, but compiler stopped with my error message. As I did not re-run cmake I´m sure this engine was also used before. Next step I removed my mutex-hack from freq_xlating_fir_filter and changed the #if for posix_memalign test in volk_malloc.c to #if 1, in other words posix_memalign is always used. Compiled without an error and runs stable. So I´m pretty sure bug #710 is the reason. The only thing I´m not sure is: You said you verified that posix_memalign is used by GnuRadio on OS X. I checked my build process, I did not add any OS X 10.7 compatibility command, I used exactly the cmake line from the guide: http://gnuradio.org/redmine/projects/gnuradio/wiki/MacInstall and posix_memalign was not used I think either the #if-clause in volk_malloc.c needs an addition for OS X >= 10.8. or cmake-file needs to be modified. Best regards Stefan Am 06.08.2014 20:26, schrieb Michael Dickens: > Hi Stefan - I'm guessing that the issue Tom made yesterday < > http://gnuradio.org/redmine/issues/710 > applies, yes? Was the change to > your (local; not GR) code, to use posix_memalign instead of some other method > of memory allocation? I'm guess I'm not all clear on where the issue actual > was ... but, I'm glad you got the bug figured out and/or can work around it > without a hack. - MLD > > On Aug 5, 2014, at 11:19 PM, Stefan Oltmanns wrote: >> Confirmed it´s the allocator: >> Recompiling with other allocation engine removed did not work. >> Removed my hack and compiled with posix_memalign: Stable. >> Thank you very much > -- > Michael Dickens, OSX Programmer > Ettus Research Technical Support > Email: supp...@ettus.com > Web: http://www.ettus.com > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Confirmed it´s the allocator: Recompiling with other allocation engine removed did not work. Removed my hack and compiled with posix_memalign: Stable. Thank you very much Stefan Am 05.08.2014 21:54, schrieb Stefan Oltmanns: > Yes, it´s OS X 10.9, but I think I compiled with 10.7 compatibility, > will check what happens when I recompile with the other allocation > engine removed. > > Am 05.08.2014 21:27, schrieb Michael Dickens: >> On Aug 5, 2014, at 3:17 PM, Tom Rondeau wrote: >>> Great, that explains it. On Linux, you're using posix_memalign, but on the >>> other OS's, you must be falling through on that into the other allocation >>> engine, which does not have any thread safety but really should be. >>> >>> I've created ticket #710 and will get to it soon. >> >> If Stefan is using OSX 10.8 or 10.9 then he actually is using posix_memalign >> -- Apple added that function into 10.8+, and I've confirmed that GR uses it, >> too. - MLD >> -- >> Michael Dickens, OSX Programmer >> Ettus Research Technical Support >> Email: supp...@ettus.com >> Web: http://www.ettus.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] Stable on Linux, many crashes on Windows and OS X
Yes, it´s OS X 10.9, but I think I compiled with 10.7 compatibility, will check what happens when I recompile with the other allocation engine removed. Am 05.08.2014 21:27, schrieb Michael Dickens: > On Aug 5, 2014, at 3:17 PM, Tom Rondeau wrote: >> Great, that explains it. On Linux, you're using posix_memalign, but on the >> other OS's, you must be falling through on that into the other allocation >> engine, which does not have any thread safety but really should be. >> >> I've created ticket #710 and will get to it soon. > > If Stefan is using OSX 10.8 or 10.9 then he actually is using posix_memalign > -- Apple added that function into 10.8+, and I've confirmed that GR uses it, > too. - MLD > -- > Michael Dickens, OSX Programmer > Ettus Research Technical Support > Email: supp...@ettus.com > Web: http://www.ettus.com > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Hi Michael,
I was able to fix the problem with an extraordinary ugly hack:
I added a global mutex to GnuRadio and protect
gr::filter::freq_xlating_fir_filter_ccf_impl::build_composite_fir with
it, so only one instance can call
gr::filter::kernel::fir_filter_ccc::set_taps at the time.
Stable now on both OS X and Windows. I think it´s definitely a bug in
Volk, or is Volk not supposed to be thread-safe?
Can you confirm that bug?
Why it worked on Linux before, I´m not sure, either other code in
GnuRadio is used or the scheduler of the OS is somehow different, so
that the problem never occurred.
Thank you very much
Stefan
Am 05.08.2014 15:58, schrieb Michael Dickens:
> Hi Stefan - OK; cool. Loading up that example, it runs for quite a long time
> as you describe, before crashing. Here's the backtrace from gdb when it
> crashes. So, yes, it looks like either freq_xlating_fir_filter has a bug or
> you're not using it correctly; I haven't had time to look into it further
> yet. I'd recommend you poke around some more in the freq_xlating_fir_filter
> and make sure your usage is correct. If you get nowhere, ping the list with
> the specifics of what you've tried including a code-snippet. - MLD
> {{{
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x00030109
> [Switching to process 75636 thread 0x13603]
> 0x000101dc4c5b in volk_free ()
> (gdb) bt
> #0 0x000101dc4c5b in volk_free ()
> #1 0x000101208591 in gr::filter::kernel::fir_filter_ccc::set_taps ()
> #2 0x0001012185bf in
> gr::filter::freq_xlating_fir_filter_ccf_impl::build_composite_fir ()
> #3 0x000101218764 in gr::filter::freq_xlating_fir_filter_ccf_impl::work
> ()
> #4 0x000100e5af79 in gr::sync_decimator::general_work ()
> #5 0x000100e2db00 in gr::block_executor::run_one_iteration ()
> #6 0x000100e6901d in gr::tpb_thread_body::tpb_thread_body ()
> #7 0x000100e584be in gr::tpb_container::operator() ()
> #8 0x000100e582d4 in
> gr::thread::thread_body_wrapper::operator() ()
> #9 0x000100df9ae6 in boost::function0::operator() ()
> #10 0x000101f8f625 in boost::(anonymous namespace)::thread_proxy ()
> #11 0x7fff9940c772 in _pthread_start ()
> #12 0x7fff993f91a1 in thread_start ()
> }}}
> --
> Michael Dickens, OSX Programmer
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: http://www.ettus.com
>
> On Aug 4, 2014, at 7:20 PM, Stefan Oltmanns wrote:
>> thank you very much for testing! The code is in pre-alpha state, and
>> that the About box stops GnuRadio was just a quick-and-dirty hack for
>> testing. Normally About should not do anything else than showing the
>> About Box.
>>
>> Please try again and open the included example.csv with the program.
>> That creates and starts the GnuRadio flowgraph and continuously changes
>> frequency of the hardware and the frequency Xlating filter. You should
>> see four symbolized batteries, with RF level (and counter since last
>> update when there is a signal) written above, frequency and
>> name/description below. In case there is no signal they will be dark
>> grey, otherwise light grey (and in case the program detects a battery
>> signal it can decode they will be green/yellow/red depending on the
>> battery state).
>>
>> _I think I was just able to isolate the problem_:
>>
>> When I only do set_center_freq(frequency_offset) with one Frequency
>> Xlating filter no crashes. You can test that by removing the first or
>> second line of the example.csv (so that two frequency never fit within
>> the 2,4 MHz bandwidth). The other Xlating filters still exists and are
>> active in the flowgraph, but set_center_freq is never called on them.
>> Program is stable then.
>>
>> Just by adding this line:
>>
>> if((freq_len+1)> bat_decoders[freq_len+1]->SetFreqOffset((int)(bat_blocks[freq_pos]->GetFreq())-center_freq);
>>
>> in the for-loop in the very last function (BatMonFrame::OnTimer) will
>> make the program instable again.
>> This does nothing else than setting the frequency of the next Frequency
>> Xlating filter to the same value (if there is one).
>>
>> I don´t see how this can be a bug in my program, I think it has to be a
>> bug in GNURadio (as it is not predictable and caused by doing the same
>> thing on two different instances of the same object in very short time
>> range -> my guess would be a threading problem). Can you confirm that?
>>
>> I tested this on two different systems (Quad-Core Haswell and Dual-Core
>> Ivy Bridge mobile), same result for both.
>>
>> Thank you very much,
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Hi Michael, thank you very much for testing! The code is in pre-alpha state, and that the About box stops GnuRadio was just a quick-and-dirty hack for testing. Normally About should not do anything else than showing the About Box. Please try again and open the included example.csv with the program. That creates and starts the GnuRadio flowgraph and continuously changes frequency of the hardware and the frequency Xlating filter. You should see four symbolized batteries, with RF level (and counter since last update when there is a signal) written above, frequency and name/description below. In case there is no signal they will be dark grey, otherwise light grey (and in case the program detects a battery signal it can decode they will be green/yellow/red depending on the battery state). _I think I was just able to isolate the problem_: When I only do set_center_freq(frequency_offset) with one Frequency Xlating filter no crashes. You can test that by removing the first or second line of the example.csv (so that two frequency never fit within the 2,4 MHz bandwidth). The other Xlating filters still exists and are active in the flowgraph, but set_center_freq is never called on them. Program is stable then. Just by adding this line: if((freq_len+1)SetFreqOffset((int)(bat_blocks[freq_pos]->GetFreq())-center_freq); in the for-loop in the very last function (BatMonFrame::OnTimer) will make the program instable again. This does nothing else than setting the frequency of the next Frequency Xlating filter to the same value (if there is one). I don´t see how this can be a bug in my program, I think it has to be a bug in GNURadio (as it is not predictable and caused by doing the same thing on two different instances of the same object in very short time range -> my guess would be a threading problem). Can you confirm that? I tested this on two different systems (Quad-Core Haswell and Dual-Core Ivy Bridge mobile), same result for both. Thank you very much, Stefan Am 04.08.2014 15:16, schrieb Michael Dickens: > Hi Stefan - OK; well if "make test" worked on OSX for you then the GR install > is probably good to go. No guarantees. If you uninstall your OO-MacPorts GR > install and use gnuradio-devel, then you will should get the same results (if > not better). I'm not sure why you would want an OO-MacPorts GR install > unless you wanted to change GR itself. > > After tweaking "build_osx" for my setup, everything builds nicely. Running > "./batmon" I see an empty window and basic menus; nothing else. I can leave > it running (in gdb) for a long time without it crashing. I don't know what > to do with it otherwise. I have an Ettus B210 hooked up. > > If I select "batmon" -> "About" I see the about box, which when I close > crashes the executable. Looking through the code in main.cpp, > BatMonFrame::OnAbout calls BatMonFrame::StopReceiver, which in turn calls > "gr_tb->stop" even though gr_tb has not been initialized (I set a breakpoint > where it is set, and the code does not get there before this call). Probably > best to check gr_tb before using it, just in case, in all the methods that > call it. Also, I'm not sure why you would stop processing -after- the about > box has been closed; maybe beforehand makes more sense? > > If you let me know what else to test, I'll try that too. Otherwise, without > actual functionality the basic GUI seems to "work". - MLD > -- > Michael Dickens, OSX Programmer > Ettus Research Technical Support > Email: supp...@ettus.com > Web: http://www.ettus.com > > On Aug 3, 2014, at 12:00 AM, Stefan Oltmanns wrote: >> thank you very much for your help. I´ve attached the program in it´s >> current state (messy pre-alpha code) to this mail. It´s a GUI >> application (wxWidgets). On my system it compiles with build_osx (it´s >> just one line and probably won´t work without editing on other systems). >> After program is started: File->Open Transmitter Configuration and >> select example.csv, GNURadio is started and in a timer loop frequency >> will be changed for source and Frequency Xlating filter. On Linux I >> tested it for about two hours and no crash. >> Of course there could also be something wrong with my program and on >> Linux it just doesn´t cause any problem. >> >> It uses OsmoSDR source, so other devices should work as well. Note that >> sample rate is currently hardcoded in the source (2,4 MHz). >> >> I did run make test on OS X and it completed with 100% pass. > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Stable on Linux, many crashes on Windows and OS X
Hello, I want my program to be platform independent (it should work on Linux, OS X and Windows). Although it runs stable on Linux (Xubuntu 14.04 amd64), on both Windows (Win 7 x64) and OS X (10.9) it´s crashing after about a minute. For OS X I followed the build guide provided (installed using ports, then uninstalled and compiled from source). This is the console output: - Mac OS; Clang version 5.1 (clang-503.0.38); Boost_105500; UHD_003.007.001-0-unknown gr-osmosdr v0.1.1-10-g9cb023b0 (0.1.2git) gnuradio 3.7.5git-127-g41d08443 built-in source types: file fcd rtl rtl_tcp uhd rfspace Using device #0 Realtek RTL2838UHIDIR SN: 0093 Found Elonics E4000 tuner Using Volk machine: avx_64_mmx_orc /Users/stefan/.gnuradio/prefs/vmcircbuf_default_factory: No such file or directory vmcircbuf_createfilemapping: createfilemapping is not available gr::vmcircbuf_sysv_shm: shmat(1): Too many open files gr::vmcircbuf_sysv_shm: shmat(1): Too many open files gr::vmcircbuf_sysv_shm: shmat(1): Too many open files gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_sysv_shm: shmget(1): Invalid argument gr::vmcircbuf_mmap_shm_open: mmap or shm_open is not available Segmentation fault: 11 - Other example - Mac OS; Clang version 5.1 (clang-503.0.38); Boost_105500; UHD_003.007.001-0-unknown gr-osmosdr v0.1.1-10-g9cb023b0 (0.1.2git) gnuradio 3.7.5git-127-g41d08443 built-in source types: file fcd rtl rtl_tcp uhd rfspace Using device #0 Realtek RTL2838UHIDIR SN: 0093 Found Elonics E4000 tuner Using Volk machine: avx_64_mmx_orc VOLK: tried to free a non-VOLK pointer Segmentation fault: 11 - Sometimes "VOLK: tried to free a non-VOLK pointer" does not result in a crash and the program keeps running normally. For Windows I compiled GNU Radio using Visual Studio 2012 (x64 build). It´s the same here: It works fine for about a minute, then it crashes. When I start to debug using Visual Studio, it shows me that the crash occurred in the free-function (I cannot see the call stack). Interestingly on Linux it uses the Volk-machine "avx_64_mmx", on Mac OS X "avx_64_mmx_orc" (on Windows I don´t know), although it´s the same computer. Is there a difference between these two and could "avx_64_mmx_orc" be the reason for the crashes? Can I force GNU Radio to use another Volk-machine? Any other ideas? Best regards Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] reset() for probe_avg_mag_sqrd
Hello, my application is monitoring the RF level and often changeing the frequency. Unfortunately it takes some time for probe_avg_mag_sqrd to adjust to the new RF level (about 2 seconds if old level -10dB and new level -40dB). I found out the the iir-filter probe_avg_mag_sqrd uses has a reset function, so all I did was adding a reset-function in probe_avg_mag_sqrd to call it and it seems so work fine. Is there any reason probe_avg_mag_sqrd doesn´t have a reset function yet? Is there some problem I don´t see? In case not, could that be added in official GNURadio? Otherwise my application would only work with modified GNURadio (or I would need to include my modified probe_avg_mag_sqrd with a new name in my appliaction). I would prefer to have this feature in official GNURadio, as it´s probably useful for somebody else as well. Best regards Stefan Note: I´m not sending a patch because it´s just 3 lines of code and I don´t know Python, so somebody else would have to complete it anyway. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Port flowgraph from Python to C++
Hello, I was able to create a flowgraph in GRC to demodulate a signal (low-frequency battery telegram of wireless microphones). Now I started to port the generated code from Python to C++. I had to realize that some blocks are Python-only, like the FM Demodulator. I was able to rebuild the FM Demodulator in C++, for one exception: The FM demodulator uses optfir, which is implemented in Python, so it cannot be used in C++. So I replaced it with firdes (I noticed the parameter difference in transition band end and transition band width). Another thing is that the Frequency-Xlating-Filter uses a complex lowpass, but in C++ I could only find a complex band-pass, so I used a band-pass with lower frequency 0, is that the same? Also it works, the signal is a lot noisier and the result cannot be decoded in many cases. I think the reason are the different filters. Could that be the reason? As I understood, both optfir and firdes create just a bunch of numbers and that´s it. As my program is not going change the filter parameters they could be hardcoded in my program, right? Best regards Stefan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
