On 06/03/2012 05:14 PM, Phil wrote:
> /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:
> In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short
> unsigned int, int, bool)’:
> /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51:
> error:
On 04/06/12 15:41, Alexandru Csete wrote:
First you make a clone "git clone git:/git.osmocom.org/gr-osmosdr" (I
assumed you already had that), then you change into the gr-osmosdr
directory and do "git checkout b2128bc"
OK Alex, that worked. Now I need to discover why gnuradio compiles with
e
On Mon, Jun 4, 2012 at 1:24 AM, Phil wrote:
> On 03/06/12 21:41, Alexandru Csete wrote:
>>
>> I tried to build as well yesterday and failed for me too - as I recall
>> with the same error. I checked out the code again today and it fails
>> too but with a different error, so the code is changing at
On 04/06/12 12:49, Marcus D. Leech wrote:
Phil, I'm pretty sure that Josh was asking about which particular
flavour of the dozen or so popular
Linux distributions you're using. It matters. Different distributions
use different file-system layouts,
store header files in different location
On 03/06/12 08:54 PM, Phil wrote:
> On 04/06/12 10:43, Josh Blum wrote:
>>
>>>
>>> /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:
>>> In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short
>>> unsigned int, int, bool)’:
>>> /usr/local/src/gnuradio-3.6.0/gnuradio
On Sun, Jun 3, 2012 at 4:31 PM, Ben Reynwar wrote:
> Hi Vahid,
>
> First I'd try using a much longer string of bits and see if that help.
>
> Second I'd find an example in gnuradio
> (gr-digital/python/qa_constellation.py should have a working dqpsk
> test) and then work from there.
>
> Thirdly if
On 04/06/12 10:43, Josh Blum wrote:
/usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:
In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short
unsigned int, int, bool)’:
/usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51:
error: ‘optval
>
> /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:
> In constructor ‘gr_udp_sink::gr_udp_sink(size_t, const char*, short
> unsigned int, int, bool)’:
> /usr/local/src/gnuradio-3.6.0/gnuradio-core/src/lib/io/gr_udp_sink.cc:123:51:
> error: ‘optval_t’ was not declared in thi
Almost there I think. It looks like I'm missing something to do with gr-udp.
-- ##
-- # Gnuradio enabled components
-- ##
-- * python-support
-- * testing-support
-- * volk
-- * doxyge
Hi Vahid,
First I'd try using a much longer string of bits and see if that help.
Second I'd find an example in gnuradio
(gr-digital/python/qa_constellation.py should have a working dqpsk
test) and then work from there.
Thirdly if you want pi/4-dqpsk you won't be able to use the standard
dqpsk_mo
On 03/06/12 21:41, Alexandru Csete wrote:
I tried to build as well yesterday and failed for me too - as I recall
with the same error. I checked out the code again today and it fails
too but with a different error, so the code is changing at the moment.
You can go back to commit b2128bc8644214
On 03/06/12 21:20, Alexandru Csete wrote:
Phil,
I think you misunderstand. You must have GNU Radio installed prior to
compiling gr-osmosdr as gr-osmosdr uses the GNU Radio API.
Thank you Alex, I'm finding Gnuradio, and the way that it operates, a
difficult subject to grasp.
--
Regards,
P
On 05/29/2012 11:59 PM, Pol Henarejos wrote:
> Dear Josh,
>
> The hardware is USRP2 at 10Msps with latest UHD version
> UHD_003.004.001-165-unstable.
>
Well, this surprises me. I have never know USRP2/N210 to internally
overflow. The gigE pipe essentially has no back-pressure, so the
overflowi
The python generic_demod.py block uses the constellation_receiver_cb
block to do both some fine-tuning of the phase and the mapping to
bits. It can be found at:
gnuradio/gr-digital/lib/digital_constellation_receiver_cb.cc
This in turn will use the decision_maker method of the constellation
object
Hi Tom,
Tom Rondeau wrote on 2012-06-03 17:12:
> On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser
> Patrick,
>
> It looks like you're problem is in the rational_resampler code. I
> wonder if there's something about the resampling rate being used
> that's causing something to go out of bounds here
Dear everyone:
Recently I have been doing my graduation design, wchich is the implemention
of 802.11a ofdm PHY. My tutor required me to use FPGA so I implemented baseband
OFDM modulation-demodulation using Virtex5 FPGA. My tutor decided not to use
USRP because the RF bandwidth is too limited.
On Sat, 2 Jun 2012 17:47:50 -0400, Nick Iliev wrote:
> Hello,
>
> we have implemented a 2 TX x 1 RX MISO testbed with GNU Radio 3.4 and
> USRP1 . Both transmitters are using at 2.4GHz ( actually tx1 uses
> 2.401GHz and tx2 uses 2.403GHz ) , and are sending data ( BPSK
> modulated ) at the same ti
On Sat, Jun 2, 2012 at 5:50 AM, Patrick Strasser
wrote:
> Hello list,
>
> I'm playing around with gqrx, an excellent example which great
> standalone software can be built with gnuradio.
>
> I'm running phirsch's rtlsdr fork, do not have a Funcube Dongle or USRP
> at hand, but rather a Terratex NO
On Mon, May 28, 2012 at 1:39 PM, Nazmul Islam
wrote:
> Hello,
>
> I am trying to transmit a GLFSR sequence using bpsk (non-differential
> modulation). I am using gnuradio-companion to construct the blocks. My
> transmit path is is simply the following: GLFSR source -> BPSK Mod
> (Non-differential)
On Fri, Jun 1, 2012 at 7:14 PM, Dhrubojyoti Roy
wrote:
> Dear All,
>
> I was experimenting with GNURadio to see if multiple transmitter threads can
> exist in the same program. The following are my transmitter class
> definitions (both are set to the same transmission parameters):
>
> class my_tra
On Fri, Jun 1, 2012 at 3:12 PM, Igor Volodin wrote:
> Hello, all
>
> My configuration:
> Linux Xubuntu 12.04
> AMD Athlon XP 2400
> Linux ghost32 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:51:22 UTC 2012
> i686 athlon i386 GNU/Linux
>
>
>
> I am compiled latest version of gnuradio, and tried to
On Fri, Jun 1, 2012 at 9:31 AM, Ryan Connelly
wrote:
> For example at
> http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsWritePythonApplications/annotate/19
>
> Line 637 there is a typo
>
> class my_gui_flow graph(stdgui2.std_top_block):
>
> Should be
>
> class my_gui_flow_graph(stdgui
On Wed, May 30, 2012 at 3:04 PM, Josh Stevens wrote:
> Hello All,
>
> A couple of days ago i had installed a GNURadio digital image
> processing block that makes an image source and sink block available as
> displayed in the image below.
> Resource : https://github.com/a-w-s/GNURadio-DIP
>
On Sat, May 26, 2012 at 12:08 PM, Marius wrote:
> Hi!
>
> I found a comment in the source code of the MPSK block, that it could
> be used for oQPSK demodulation. I think this block is very interesting
> implementation, however I'm not sure which parameters I should use for
> oQPSK. In the gr-ieee8
On Fri, May 11, 2012 at 7:03 AM, Martin Braun wrote:
> In the current state of gr-howto (which is also used in gr_modtool), the
> SWIG stuff is done pretty intelligently by using the header files as
> .i-files, which means there is no need to write a SWIG header for every
> block.
>
> One advantag
On Fri, May 11, 2012 at 10:37 PM, Andrew Davis wrote:
>> free weekend
> I had one once!
>
> So any plans for the application specific top-level blocks ( noaa,
> pager, atsc )? I feel these could be moved to the CGRAN, or better yet
> there could be a separate top-level folder for projects like thi
Hello,
I want to set up the OpenBTS, and I want to know which board is
better, USRP1 or USRP2? Or any other suggestion? Thank you.
--
Best regards,
Pan, Luyuan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailma
On Sun, Jun 3, 2012 at 6:42 AM, Phil wrote:
> Thank you for reading this.
>
> I've progressed a little since I last wrote and have received my ezcap USB
> dongle. Unfortunately, I'm still having problems.
>
> Cmake produces the following, which seems to indicate that all is well:
>
>
> --
On Sun, Jun 3, 2012 at 12:51 PM, Phil wrote:
> Thank you for reading this.
>
> I'm still unable to compile gr-osmosdr and a Gpoogle search shows that
> others have had to same problem but I haven't found any solutions.
>
> Following instructions I think I have captured signals from a local FM radi
Thank you for reading this.
I'm still unable to compile gr-osmosdr and a Gpoogle search shows that
others have had to same problem but I haven't found any solutions.
Following instructions I think I have captured signals from a local FM
radio station. How do I play this captured file? I haven
30 matches
Mail list logo
