Re: [Discuss-gnuradio] viterbi.c, integer overflow at cumulative metric

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey Vesa, the cc_decoder_impl.cc and it's corresponding volk kernel "volk_8u_x4_conv_k7_r2_8u.h" in gr-fec avoid this problem already by normalizing the path metric after each step in the trellis. I'm not sure if they are on the master branch yet, but

Re: [Discuss-gnuradio] ofdm channel estimation

On 07/13/2014 01:06 PM, xianda wrote: > Hi all: > Have you ever using the > gnuradio/gr-digital/examples/ofdm/rx_ofdm.grc?And I change the > rx_ofdm.py as follows: > self.connect((self.digital_ofdm_chanest_vcvc_0, 1), > blocks.file_sink(gr.sizeof_gr_complex * fft_len, 'channel-est

Re: [Discuss-gnuradio] Squelch and the KSHT sounds ...

The 'Power Squelch' block in GRC is my favourite and I would recommend using this one. Have a look at the following GRC flow graph for a working example that uses the power squelch block: https://raw.githubusercontent.com/m0mik/scanoo/master/apps/scanoo.com_rx.grc Note that the 'Ramp' setting is

[Discuss-gnuradio] Removing gnuradio 3.6 and reinstalling 3.7 with build-gnu radio

I have a system that is remotely deployed. I have ssh access to the machine and some limited Vnc. I do not have physical access to do a fresh OS install. In looking at my install, it looks like I got 3.6 for most stuff, but a fair amount of 3.7 is 'tainting' the install. I'd like to remove every

[Discuss-gnuradio] channel models in GNURADIO

Hi all, I am using GNURADIO 3.7 and Ubuntu 13. I want to know if the channel models (Doppler shift) is the same/similar with matlab channel models (Doppler shift). Did someone compare them? I am inetersted in Doppler shift part. -- NE___ Discuss-g

Re: [Discuss-gnuradio] viterbi.c, integer overflow at cumulative metric

On Mon, Jul 14, 2014 at 3:19 AM, Jan Krämer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey Vesa, > > the cc_decoder_impl.cc and it's corresponding volk kernel > "volk_8u_x4_conv_k7_r2_8u.h" in gr-fec avoid this problem already by > normalizing the path metric after each step in

Re: [Discuss-gnuradio] Doubt in digital modulation chain

On Mon, Jul 7, 2014 at 4:08 PM, Manu T S wrote: > Dear All, > > I am constructing the flow graph(screen capture, grc) attached. > > I am expecting the data at the output of packed-to-unpacked block to be > the same as the data at the output of differential decoder, except for some > stray bits in

Re: [Discuss-gnuradio] Squelch and the KSHT sounds ...

Thank you Mike. Yes, pwr_squelch is the one I'm trying. Good choice! :-) However, what I think I need is an asymmetrical squelch, one that quickly breaks squelch on the attack but uses a retarded rate for the decay. I'm looking into the blocks now. It looks like the pwr_squelch builds on the squelc

[Discuss-gnuradio] gnuradio on ubuntu touch

Is gnuradio able to run on Ubuntu Touch? I want to use my tablet with gnuradio and rtl-sdr. Do you guys think its possible with Ubuntu Touch? Or there is another way to do it? Thanks Regis -- View this message in context: http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315.html

[Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

Attached, you'll find a pair of very-simple .grcs One is a UDP sender (using a pair of UDP sinks) The other is a UDP receiver (using a pair of UDP sources) The sender clearly works, as verified by 'tcpdump' at the receiving system. The ports are correct, etc. But *nothing* is coming out of

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

I saw something similar last week. On Mon, Jul 14, 2014 at 8:21 AM, Marcus D. Leech wrote: > Attached, you'll find a pair of very-simple .grcs > > One is a UDP sender (using a pair of UDP sinks) > > The other is a UDP receiver (using a pair of UDP sources) > > The sender clearly works, as verif

Re: [Discuss-gnuradio] gnuradio on ubuntu touch

Hi Regis, I don't know anything about Ubuntu touch. But if it's a proper linux, then yes, GNU Radio will run on it, probably. The question is however if your tablet is powerful enough to do something useful with the data, since we tend to use strong computers to do realtime signal processing. Gree

Re: [Discuss-gnuradio] Scanoo --> Was Squelch and the KSHT sounds ...

You need to double click something in the flowgraph and click ok/cancel before it will allow you to run the flowgraph. It's a weird GRC bug. Mike -- Mike Jameson M0MIK BSc MIET Ettus Research Technical Support Email: supp...@ettus.com Web: http://ettus.com On Mon, Jul 14, 2014 at 3:40 PM, wrot

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

Also saw the same thing. =) On Mon, Jul 14, 2014 at 8:59 AM, Marcus D. Leech wrote: > On 07/14/2014 11:47 AM, John Malsbury wrote: > > I saw something similar last week. > > Opened up firewall rules. That didn't help. But netcat could see the > traffic, so it's being delivered up to userlan

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

On 07/14/2014 11:47 AM, John Malsbury wrote: I saw something similar last week. Opened up firewall rules. That didn't help. But netcat could see the traffic, so it's being delivered up to userland. On Mon, Jul 14, 2014 at 8:21 AM, Marcus D. Leech > wrote:

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

On 07/14/2014 12:00 PM, John Malsbury wrote: Also saw the same thing. =) You can't leave the bind-addr blank--set it to the interface addy over which you expect packets to arrive, that works. I suspect that there's some missing code to deal properly with a "promiscuous bind" in the UDP sourc

[Discuss-gnuradio] Question regarding frequency offset correction

Hi all, In many applications very good synchronization of carrier and sampling frequencies is required. Available sources of signal not always have good clock reference. One of the examples is cheap RTL SDR receiver based on a DVB-T dongle. Without any additional effort to correct frequency offset

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

Set the bind address to '0.0.0.0' to listen on all interfaces. This would be a good default setting. -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com Web: http://scanoo.com On Mon, Jul 14, 2014 at 5:13 PM, Marcus D. Leech wrote: > On 07/14/2014 12:00 PM, John Malsbury wrote: > >> Also sa

Re: [Discuss-gnuradio] gnuradio on ubuntu touch

Hi Marcos, thank you for your reply. What would be the minimum required configuration for a computer to run gnuradio without problems? Regis -- View this message in context: http://gnuradio.4.n7.nabble.com/gnuradio-on-ubuntu-touch-tp49315p49325.html Sent from the GnuRadio mailing list archive

Re: [Discuss-gnuradio] gnuradio on ubuntu touch

Running Linux :) The thing is that GNU Radio is but a framework, and has little computational overhead; the load you are seeing is primarily defined by the signal processing you do, so I can't answer that question. I like to bring up a analogy: It's like asking what the minimum requirement for pla

Re: [Discuss-gnuradio] Question regarding frequency offset correction

On Mon, Jul 14, 2014 at 12:14 PM, Perper wrote: > Hi all, > > In many applications very good synchronization of carrier and sampling > frequencies is required. > Available sources of signal not always have good clock reference. One of > the examples is cheap RTL SDR receiver based on a DVB-T dong

Re: [Discuss-gnuradio] UDP sender/receiver what the heck am I doing wrong

On 07/14/2014 12:36 PM, Mike Jameson wrote: Set the bind address to '0.0.0.0' to listen on all interfaces. This would be a good default setting. Yup, this works. That was one of my test-cases *before* I changed the firewall rules... -- Mike Jameson M0MIK BSc MIET Email: m...@scanoo.com

Re: [Discuss-gnuradio] Question regarding frequency offset correction

On 07/14/2014 01:01 PM, Aditya Dhananjay wrote: On Mon, Jul 14, 2014 at 12:14 PM, Perper > wrote: Hi all, In many applications very good synchronization of carrier and sampling frequencies is required. Available sources of signal not always have good cloc

Re: [Discuss-gnuradio] Question regarding frequency offset correction

Hi Piotr, there's various control loop based offset correction, look for the PLL and FLL examples. There's a feedback loop base class in GNU Radio for monolithic correction. For the frequency correction estimate feedback, you could easily use a message bus, that will occasionally inform the upstrea

Re: [Discuss-gnuradio] cmake don't found portaudio

On Thu, Jul 10, 2014 at 3:39 PM, Rodrigo Farias wrote: > Hi, > I'm installing version 3.7.3 on Ubuntu 14.04. > > Cmake output: > . > . > . > -- Configuring gr-audio support... > -- Dependency Boost_FOUND = 1 > -- Dependency ENABLE_GNURADIO_RUNTIME = ON > -- Enabling gr-audio support. > --

Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?

The UDP sink doesn't support complex int 16, so what would I be able to change the type to in order to come to a close solution for this problem? Also, I have lowered the sample rate to very small amounts such as 1e6, but I still lose packages on the receiving end. There is a 1-gigabit switch b

Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?

I forgot to add that the 1e6 data rate was going to a null sink. The data rate is only 1Mhz * 4bytes * 2 channels = 8M bytes per second to a null sink, which should be fine. Does anyone have any suggestions as to what settings I should have in my UDP source block in terms of payload size, buffe

Re: [Discuss-gnuradio] Why am I dropping data over the UDP network?

Hi Marcus, On 14.07.2014 22:01, Ward, Marcus D. wrote: > The UDP sink doesn't support complex int 16, so what would I be able to > change the type to in order to come to a close solution for this problem? It should, using the datatype "short". > > Also, I have lowered the sample rate to very smal

Re: [Discuss-gnuradio] [USRP-users] GNU Radio flow graph code

Hi Alejandro, please always ask on the list! GNU Radio companion only generates a single python file containing the definition of your flow graph. This flowgraph consists of connected blocks, of which the USRP UHD sink/source is capable of communicating using UHD. Its source code can be found in

[Discuss-gnuradio] GNU Radio Release 3.7.4 Available for Download

GNU Radio release 3.7.4 is available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.7.4.tar.gz MD5 sum: 94e7115ad7b46b5bc9e0b336cf74d8ba gnuradio-3.7.4.tar.gz This release incorporates a large number of new features and bug fixes, and represents a longer than usual development

Re: [Discuss-gnuradio] Ofdm tramsmitter

ok 2014-07-15 4:22 GMT+02:00 Sara Chérif : > > > -- Forwarded message -- > From: Marcus Müller > Date: 2014-07-13 22:37 GMT+02:00 > Subject: Re: [Discuss-gnuradio] Ofdm tramsmitter > To: discuss-gnuradio@gnu.org > > > Hi GP 2014 > > On 13.07.2014 21:49, GP 2014 wrote: > > Hi, >