Re: clear buffers of stuck chain
You can't send more message than what your bandwidth/radio allows you to send. So, either throw away as many messages as necessary to bring the short- term average message rate to something your hardware can send, or implement a buffering block that puts incoming messages in a queue and slowly emits them. It might be beneficial if you modified gr-ieee802-15-4's PHY blocks in a way that they themselves emit "I've done sending a packet" messages, which you can use to know to when you can send more data. Best regards, Marcus On Tue, 2020-02-11 at 09:44 +0200, Eitan Hetzroni wrote: > Exactly, how can i solve this if i do want to spam? > > > On Mon, Feb 10, 2020 at 6:56 PM Sylvain Munaut <246...@gmail.com> wrote: > > My best guess at this point is you're spamming it with as much message > > as possible (way too many for the actual radio part to send) and then > > at some point the buffers are filled up and it's only accepting new > > messages at the rate it's actually sending them. > > > > Cheers, > > > >Sylvain > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete all copies of the message. smime.p7s Description: S/MIME cryptographic signature
Re: Help : UHD
On Tue, Feb 11, 2020 at 11:15 AM "Till Hülder" wrote: > > Hello, > > i want to implement a FMCW-Radar in a frequency-chirp. First i tested the > frequency-chirp . I send the chirp from TX to RX of my USRP. > I get this warning : > > UHD Warning: > For this connection, UHD recommends a receive frame size of at least > 8000 for best > performance, but your system's MTU will only allow 1472. > This will negatively impact your maximum achievable sample rate. > Check how to change the MTU size on your interface to be 8000. Google can help with that. > > UU > >>> Done > > My constellation- and time gui looks unlikely (see attachment) on the top > ist TX and the bottom ist RX. > > Does anybody has a solution for this? > Add more attenuation between TX and RX and/or change the gain of your RX to be lower. Brian >
Re: Error cross-compiling GNU Radio 3.8 for E310
As I stated I correctly compiled GNU Radio 3.8. Now I'm trying to compile one of mine C++ OOT module, and I'm obtaining a curious error. https://pastebin.com/ZyfJcHCa >From warnings it seems that several header files are got from /usr/include, not from sdk sysroot. Where is the problem? Thank you. Ivan Il 10.02.2020 17:36 Cinaed Simson ha scritto: > On 2/10/20 3:11 AM, kron...@tiscali.it [4]wrote: > >> Hi Ron! your flags solved the specific error. The error on stdlib.h still occurs. Ivan > > Hi Ivan - I've seen that error before. Try changing the include file name to > > #includesince it's bombing in C++ code. > > -- Cinaed > > the #include_next doesn't care if it's if it's an absolute path. > >> Il 10.02.2020 11:25 Ron Economos ha scritto: >> >>> For the "selected processor does not support `pld [aVector,#128]' in ARM mode" error, you can try adding these flags to the cmake command line. -DCMAKE_CXX_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" -DCMAKE_C_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" -DCMAKE_ASM_FLAGS:STRING="-march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -g" Ron On 2/10/20 00:56, kron...@tiscali.it [2]kron...@tiscali.it>wrote: >>> Dear all, I'm compiling GNU Radio 3.8 for E310 using the newer file system and SDK. Cmake runs smoothly, but when I compile I can see mainly two errors: - stdlib.h not found: this is impossible, because I can find it in the sysroot of the SDK. - "selected processor does not support `pld [aVector,#128]' in ARM mode" and something similar. The output of cmake and make can be found here: https://pastebin.com/feyfpgUV [1] Do you know how I can fix these errors? Thanks so much. Ivan >> Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 Giga in 4G a soli 8,99EUR al mese. http://tisca.li/smart30 [3] Con Tiscali Mobile Smart 30 4G hai minuti illimitati, 100 SMS e 30 Giga in 4G a soli 8,99€ al mese. http://tisca.li/smart30
gnuradio error
I installed gnuradio on Fedora 5.4.17-200.fc31.x86_64 using sudo dnf install gnuradio Afterwards when I attempt to run gnuradio-companion (typing gnuradio-companion in a terminal) I see several errors at start up Warning: restarting the docstring loader (crashed while loading 'qtgui_bercurve_sink') Warning: restarting the docstring loader (crashed while loading 'qtgui_const_sink_x') Warning: restarting the docstring loader (crashed while loading 'qtgui_edit_box_msg') Warning: restarting the docstring loader (crashed while loading 'qtgui_freq_sink_x') Warning: restarting the docstring loader (crashed while loading 'qtgui_histogram_sink_x') Warning: docstring loader crashed too often The gnuradio GUI opens up but using QT widgets causes a seg fault. Any help appreciated. Mike
Re: gnuradio error
Hi Mike, On 11/02/2020 21.38, Mike Gilmer wrote: > I installed gnuradio on Fedora 5.4.17-200.fc31.x86_64 using sudo dnf > install gnuradio The gnuradio's version in Fedora 31 is 3.7.13.5-6.fc31.x86_64 and 5.4.17-200 is the version of the Linux kernel. You can find the newer version 3.8 in the COPR repository https://wiki.gnuradio.org/index.php/InstallingGR#Fedora_COPR_Installation > Afterwards when I attempt to run gnuradio-companion (typing > gnuradio-companion in a terminal) I see several errors at start up > Warning: restarting the docstring loader (crashed while loading > 'qtgui_bercurve_sink') > Warning: restarting the docstring loader (crashed while loading > 'qtgui_const_sink_x') > Warning: restarting the docstring loader (crashed while loading > 'qtgui_edit_box_msg') > Warning: restarting the docstring loader (crashed while loading > 'qtgui_freq_sink_x') > Warning: restarting the docstring loader (crashed while loading > 'qtgui_histogram_sink_x') The Fedora official package does not provide these QT GUI blocks, actually it does not provide any QT blocks. The most probable reason is that Qt4 was removed from Fedora 31 and gnruadio 3.7 still uses Qt4. How did you installed these blocks? > Warning: docstring loader crashed too often > > The gnuradio GUI opens up but using QT widgets causes a seg fault. Can you take a backtrace? First install the needed tools and debuginfo packages sudo dnf install dnf-utils gdb sudo debuginfo-install python3 gnuradio then run gdb -ex run -ex bt --args /usr/bin/python2 /usr/bin/gnuradio-companion do whatever is needed to reproduce the segmentation fault and then provide the gdb output from your terminal. Regards, Vasil
GNURadio Leaking memory during repeated simulations
Hi, I am using GNURadio to decode a large amount of 1024-sample complex vectors of different modulation schemes. Thus, I have a for loop which runs gr.top_block.run() at each iteration and uses a vector sink to collect the results. The issue is that as the simulation keeps going, each itertion takes longer (e.g. starts of at 120it/sec, and then after 5000 iterations slows down to 10it/sec). I can see in task manager (I am on windows) that memory is increasing so clearly there is a memory leak where somehow the results of the iterations arent being deleted. Is there an explicit way to delete runs or is this a bug? CODE: calling code: ``` for _ in range(1): decode(sig) ``` decode func: ``` def decode(channel_sigs): tb = gr.top_block() ## # Variables ## nfilts = 32 sps = 4 timing_loop_bw = 3 * 6.28 / 100.0 # NOTE: this controls convergence speed! constellation_scheme, bps = get_constellation_scheme(scheme) rrc_taps = firdes.root_raised_cosine(nfilts, nfilts, 1.0 / float(sps), 0.35, 11 * sps * nfilts) phase_bw = 6.28 / 100.0 eq_gain = 0.01 arity = 4 Actual blocks channel_src = blocks.vector_source_c(channel_sigs, False) digital_pfb_clock_sync = digital.pfb_clock_sync_ccf(sps, timing_loop_bw, rrc_taps, nfilts, nfilts / 2, 1.5, 1) constellation_soft_decoder = digital.constellation_soft_decoder_cf(constellation_scheme) binary_slicer = digital.binary_slicer_fb() blocks_char_to_float = blocks.char_to_float(1, 1) recovered_bits_dst = blocks.vector_sink_f() ## # Connections ## tb.connect((channel_src, 0), (digital_pfb_clock_sync, 0)) tb.connect((digital_pfb_clock_sync, 0), (constellation_soft_decoder, 0)) tb.connect((constellation_soft_decoder, 0), (binary_slicer, 0)) tb.connect((binary_slicer, 0), (blocks_char_to_float, 0)) tb.connect((blocks_char_to_float, 0), (recovered_bits_dst, 0)) tb.run() recovered_bits = np.array(recovered_bits_dst.data()) return recovered_bits ```
LimeSDR Mini with gr-gsm
Hi, I am trying to use grgsm_scanner (https://gitlab.com/myriadrf/gr-gsm) with LimeSDR Mini for scanning and identifying the GSM frequency present and then live monitoring using grgsm_livemon for my project. I am running this in a loop where grgsm_scanner is called for identifying the present frequencies and then these frequencies are live monitored individually in a loop for 30 sec each by calling grgsm_livemon. This code is suppose to be exited from the terminal providing continuous scanning and monitoring unless interrupted. However, this loop is terminated after couple of iterations giving one of the following errors: * RuntimeError: boost::thread_resource_error: Resource temporarily unavailable * gr::vmcircbuf_sysv_shm:shmget(2): No space left on device gr::buffer::allocate buffer: failed to allocate buffer of size 64KB I have also tried setting kernel.shmmni=32000 which is suggested in the code but in vain. Are these errors related to each other? I am unable to resolve these errors for my code requiring continuous scanning and monitoring. Could anyone point me in right direction. Thanks and Regards SG
