last week every thing was fine until today when i want to sense the
spectrum i faced this problem
>>./usrp_spectrum_sense.py 1901M 1983M > file.tr
Warning: this is known to have issues on some machines+Python version
combinations to seg fault due to the callback in bin_statitics. If you
It think you typo'd "pocsag" as "pogsag" somewhere, though.
/home/mleech/gr-pocsag/build/swig/pocsag_swigPYTHON_wrap.cxx:5099:22: error:
‘pogsag_decoder’ was not declared in this scope
One leetle typo and it goes all to shite. Stupid computers :-)
Johnathan
--
Marcus Leech
Principal Inv
On Sun, Apr 8, 2012 at 17:48, Marcus D. Leech wrote:
> Can swig only deal with the derived classes? None of the derived classes
> really work for me, since the number of output items is
> only loosely correlated to the number of input items, and I may not produce
> any output items until I see a
Trying to build a fairly simple decoder block, based on gr_block. The
compile goes OK, but swig goes very badly off the rails:
Can swig only deal with the derived classes? None of the derived classes
really work for me, since the number of output items is
only loosely correlated to the number o
> Does anyone have any pointers as to where I should be looking?
Hi Steven - First, the humor < http://xkcd.com/138/ >.
Do "ipcs -a" to see how many shared memory attachments are in place. You might
see a lot, given that 'shmat' returns 'too many files open'. Here's the BASH
script I run, ve
Sir,
Repeat is set to yes. I guess this is not the problem. Also, without the
USRP block (by sending the modulation output to the demoudalation input),
everything is working the way it should.
Best,
Huzaifa
Ben Reynwar wrote:
>
> For the vector source it looks like you're using [1,1,1,0,0,0]
Yeah we did try this sending the output of the mod to the input of the demod
thing and it works fine. The problem is only introduced when we are
introducing an USRP sink for transmitter and USRP source for the receiver.
We are trying the packed to unpacked thing and will get back to you very
soon.
Yeah we did try this sending the output of the mod to the input of the demod
thing and it works fine. The problem is only introduced when we are
introducing an USRP sink for transmitter and USRP source for the receiver.
We are trying the packed to unpacked thing and will get back to you very
soon.
My mistake. Apologies for overlooking the details, Huzaifa.
Try the unpacked-to-packed block.
-John
On 04/08/2012 03:14 PM, Marcus D. Leech wrote:
It doesn't matter where you put your antenna... Ask yourself a
fundamental question: When you assign both a receive chain and a
transmit chain
It doesn't matter where you put your antenna... Ask yourself a
fundamental question: When you assign both a receive chain and a
transmit chain to the same antenna port in a flow-graph, which one
gets access? How can you transmit and receive with the same frequency
with the same antenna witho
It doesn't matter where you put your antenna... Ask yourself a
fundamental question: When you assign both a receive chain and a
transmit chain to the same antenna port in a flow-graph, which one gets
access? How can you transmit and receive with the same frequency with
the same antenna witho
For the vector source it looks like you're using [1,1,1,0,0,0].
Perhaps the rest is getting cut-off, but if not then I would change
this to use a long random vector for the testing. If you are using
[1,1,1,0,0,0] repeated then the four symbols won't be used with
similar frequency, which might make
Dear John,
Waiting for your response...
And the reason for using TX/RX is that we connected the antennas on TX/RX
ports on the daughtercard (in both transmitter and receiver).
Thanks,
Huzaifa
John Malsbury wrote:
>
> A few more things:
>
> 1) You have both the receive and transmit portions
A few more things:
1) You have both the receive and transmit portions assigned to TX/RX.
This only works if you run in half-duplex mode and stop streaming to the
USRP. This is not the case.
2) Note the difference between sample rate, symbol rate, and bit rate.
symbol_rate = sample_rat
Dear Marcus,
I truly appreciate your prompt reply. However, I am not sure what should I
put in the 'modulus' field of the block. By hit and trial, wrong outputs are
emerging. Please guide.
Best Regards,
Huzaifa
Marcus D. Leech wrote:
>
>> We just removed the throttle blocks and the same prob
We just removed the throttle blocks and the same problem remains. Please let
us know how to achieve symbol synchronization.
Well, you're using DPSK, but not using a differential encoder on the TX
side, nor a differential decoder on the RX side.
huzaifazafar108 wrote:
Dear John,
Thank you f
We just removed the throttle blocks and the same problem remains. Please let
us know how to achieve symbol synchronization.
huzaifazafar108 wrote:
>
> Dear John,
>
> Thank you for such a prompt reply. Okay, we will remove the throttle
> blocks just now. But can you guide us how to achieve sym
Dear John,
Thank you for such a prompt reply. Okay, we will remove the throttle blocks
just now. But can you guide us how to achieve symbol synchronization then?
Best Regards,
Huzaifa
John Malsbury wrote:
>
> You do not need to use throttles when using a UHD sink/source, because
> the devi
You do not need to use throttles when using a UHD sink/source, because
the device provides timing for the flowgraph.
Remove the throttles and try again. If you still see the failure I'd
say you are not achieving symbol sync.
-John
On 04/08/2012 01:58 PM, Huzaifa Zafar wrote:
Dear all,
I
I have managed to compile the latest git version on MacOS 10.7.3 by setting
CC=gcc and CXX=g++.
The issue now is that most of the tests fail, the first being gr-core-test-all.
"gr-core-test-all" start time: Apr 08 17:00 BST
Output:
--
Testin
OK, I have a skeleton module with a single block in it that currently
does nothing. Went to build it:
[ 18%] Built target _pocsag_swig_doc_tag
[ 25%] Generating doxygen xml for pocsag_swig_doc docs
[ 31%] Generating pocsag_swig_doc.i
[ 37%] Generating pocsag_swig.tag
[ 43%] Swig source
/home/ml
After I do a newmod, how to I add a new block?
when I use gr_modtool.py add
It simply says no Gnu Radio module found in named directory.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
___
Discu
On 04/07/2012 06:44 PM, Adam Gunderson wrote:
> Drat, misread the version numbers that explains gr-fcd, still no luck on
> gr-audio though unless it ended up in a different place somehow.
>
> Pretty new to gnuradio, currently have a the dial_tone.grc working with an
> output to a wave file and t
23 matches
Mail list logo
