> I think the way to properly handle GIL from long running calls
> is to add py::call_guard()
Josh
Full success! I snarfed the gr code for msg_queue, msg_handler, and message,
and added this call guard. There is no more GIL deadlock in the python OP25
apps.
Max
The script pasted below runs OK in 3.8 but hangs (with no iteration output) in
3.10 (Ubuntu 22.04). Naturally no message is anticipated - but the script
should not hang!
This problem is blocking the release of OP25 for GR3.10.
I suspect deadlock due to failure to release the Python GIL.
Kindly
did this post somehow get missed?
From: ikjtel
Subject: [Discuss-gnuradio] patches and instructions for adding python and
numpy to GNU Radio for android
Date: Tue, 9 Jun 2015 23:10:36 + (UTC)
http://lists.gnu.org/archive/html/discuss-gnuradio/2015-06/msg00150.html
As previously mentioned, I've been working on adding python and numpy to
the existing GNU Radio android version (GrAnd). I've named the
resulting Frankensteinian creation GrAndPy.
The goals of the project (that have been successfully achieved so far) were:
a) build using a solid proper
Greetings
These messages appeared when running make V=1 VERBOSE=1 on a checkout of
v3.7.7 in ubuntu 14.04 x86_64.
The build ran OK - not sure how serious it is; I'm posting in case anyone
finds it interesting.
Best Regards
Max~~~Dependee
On Sat, 11 Apr 2015, Marcus Muller wrote:
to get a backtrace. For a bit more of background [1].
[1] http://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB
Hi Marcus
This writeup on using gdb is great!
I noticed one very small nitpick, the find command will fail on any system
that
Hi Bob
On Thursday, February 26, 2015 12:40 PM, bob wole bnw...@gmail.com wrote:
Hi, Before I start working on Op25 I want to know what kind of demodulator
detector is op25 using? Correlation filters or frequency discriminator
(quadrature demod) ? Which algos for symbol timing
Firstly, the current gr-op25 recipe in pybombs will build a version of OP25
that's compatible only with GNU Radio version 3.7. (If one really wanted to
build OP25 for GR3.6 he could pull the old SVN repo which is still online, but
that version is no longer maintained). However (last I knew)
Hi Doug
It appears that more extensive changes (than just the tiny patch I sent
yesterday) would be needed to gz-baz to make it compatible with the latest
(3.7) versions of GR and of op25. Also (AFAIK) there is no support for P25
Phase II in gr-baz.
The version of op25 (the GR-3.7.x
from gnuradio import gr, gru, op25 as _op25
ImportError: cannot import name op25
It's slightly challenging to attempt remote diagnosis of this type of issue; at
first glance I thought this might just be an easy one (need to run ldconfig,
perhaps; or a need to set the proper
Doug
One thing you could try is to make the following change in gr-baz
python/op25.py - YMMV.
Max
diff --git a/python/op25.py b/python/op25.py
index 19669da..d45d794 100644
--- a/python/op25.py
+++ b/python/op25.py
@@ -22,7 +22,8 @@
_verbose = True
import math
-from gnuradio import gr,
import op25
I got the prompt right back, no error message.
Right - pretty much as expected. This strongly suggests that the python code
you're attempting to use (in this case, from gr-baz) has not yet been
forward-ported so as to be compatible with the new GR version 3.7.x API's (and
Is there any existing 4FSK transceiver system in gnuradio ?
Yes. The OP25 project has an implementation of FSK4 for use in P25, where FSK4
is sometimes known as C4FM.
Both modulation and demodulation is supported. Here are links to the actual
code (see below) Note that the demod block
missing dependency for audio support for Ubuntu
Hi Tom
op25 is more or less out of business without GR audio support - is there a way
to add something in the gr-op25 pybombs recipe to specify that audio should be
included as a 'depends' prerequisite? Thx to Scott for finding this and
We're starting to get a few more folks who have used pybombs (successfully) to
install gnuradio and/or gr-op25.
Below is one comment - I have to admit, I had the same question/uncertainty
myself, re: the gituser (Username for git access) prompt. For me,
concurrent make threads was obvious and
One of the toughest problems to crack has been making OP25 easier for users to
install.
Historically there were long lists of system commands, pre-requisite packages,
and other
red tape. This was bad enough to scare away most users, and those who stuck
with it,
most of them, would then run
OK, this error seems to be all fixed now, but as a result I now have a doubt
about pybombs .
[The background of the problem is in the previous posting (yesterday) about
this, but essentially the problem started when I changed the pybombs recipe for
libusb in order to force pybombs to build
On Jan. 8, 2013, George wrote:
Same problem with libfaad2, fix recipe, and fix the cmake file that
set up where to look for both header files and library.
That was your solution also?
Hate to admit, was in a hurry so I just nuked the system library copy, and
replaced it with the ones that
I found this bug to be very humorous ;-)
In the case of a source download where the source file to be unpacked
is one of tar.gz or tgz or tar.bz2 or tbz2, you had better not make the
name of the recipe the same as the name of the top-level directory in the
archive. If you make them the same
pybombs is great!
Ran into a small error compiling uhd which access 'libusb_error_name' - that
symbol was not added until libusb-1.0.9, but the pybombs recipe has
satisfy_deb: libusb-1.0-0-dev - which doesn't define that symbol, so there's
a compile error...
Should the recipe be changed to
This error occurred when attempting to do ./pybombs install gnuradio - after
I manually overrode the recipe to build libusb-1.0.9 from source. That made
uhd happy [after I found it was still looking for the one in /usr/include/, and
corrected that], and the process got 90% of the way done
Now I'm wondering why I didn't get any segmentation faults.
You should be able to reproduce this by loading the alist file from the
reference site
http://www.inference.phy.cam.ac.uk/mackay/codes/alist.html (that example may
not be a good LDPC example, but should at minimum cause a fault in
OK here is my next question :-)
One of the other parity codes in P25 TDMA known as ISCH is a similar
binary code which the specs decribe as follows:
The Information field in the ISCH is 40 bits encoded with a
(40, 9,16) binary code.The (40, 9,16) code derived from a
(40,10,16) binary code
Greetings
I was very interested in this project for possible application to the op25
project, since P25 uses several FEC codes
including RS and other block codes. I've brought up the gr-ldpc library and
have a few questions. Due to the hateful YAhoo mail composer, I'm hesitant to
post
This is a case of everything used to just work in 3.6 and below, our
Gardner/Costas block relies on this functionality; i.e., it did a #include of
gri_mmse_fir_interpolator_cc.h and contructed a new one via new
gri_mmse_fir_interpolator_cc().
Of course I changed the above (respectively) for
FWIW
Getting this on an older ubuntu (10.10) box, trying to compile from a cloned
uhd git repo (which should be current as of today)
/home/mhp/uhd/host/utils/b2xx_fx3_utils.cpp: In function ‘int32_t main(int32_t,
char**)’:
/home/mhp/uhd/host/utils/b2xx_fx3_utils.cpp:546: error: ‘struct
FWIW - I'm not a FCD user ;-)
Getting this on a ubuntu 10.10 box trying to compile gr 3.7.1
Linking CXX executable fcd_nfm_rx
../../lib/libgnuradio-fcd-3.7.1.so.0.0.0: undefined reference to
`libusb_handle_events_completed'
collect2: ld returned 1 exit status
make[2]: ***
In the FWIW Dept.
Was randomly tuning around (on an analog communications receiver ;-) and came
across this on 17,860 KHz, VOA Radiogram is a Voice of America program
experimenting with digital text and images
via shortwave broadcasting. It is produced and presented by Dr. Kim
Andrew
There was recently an article in QEX (ARRL's print mag for experimenters) about
building one's own VNA using an SDR. Don't have the exact issue in hand, but
should be locatable by doing a search for QEX vector network analyzer
Best Regards
Max
Whenever VOIP and GPL'ed software are mentioned I always think of asterisk.
It's safe to say that asterisk has a history that is as interesting and as long
as that of GNU Radio :-). (Another buzzword to keep an eye on in this area BTW
is ROIP).
Anyway asterisk (in addition to being the GPL
Okay, so was in zombie mode when I typed the command, but certainly was not
expecting to get a segmentation fault.
The failing command was
/usr/bin/python /usr/local/bin/uhd_fft --spec 'A:0 B:0' -f 924e6
Things worked fine with --spec 'A:0'. Below is the seg fault, reported in case
Try setting the subdevice spec string for for the two channel usage.
-josh
Excellent! that worked, thanks.
Best
Max
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
This is on a USRP1 with two channels , when calling get_usrp_info(0) all is
fine, but get_usrp_info(1) is greeted with a crash:
Traceback (most recent call last):
File eh.py, line 158, in module
main ()
File eh.py, line 151, in main
tb = build_block (options.args, options.tx_enable,
So, my question is how to remove carrier offset in the I/Q signals.
If your frequencyoffset is Fo, you'll need to develop a local oscillator
signalat frequency-Fo andfeed that to one input of a mixer/modulator
[multiplier] stage (the other input being your original signal). The output of
the
From: adream adream...@gmail.com
but the SDR is always deal with I/Q signals.
So, I want to know how gnuradio deal with these problem?
Can you give me more advice, or a paper which talk about these problem.
Thank you.
Hmm, couldnot possibly think of a
I believe I have fixed your problem. Check out the latest master
branch (it's commit 77035b5d188be9e5dcd6731b1a58a4ce47451bde).
I was using your demo code that you posted here as a test, and it's
now working fine for me now.
Tom
cool, I did a build from the git sources and so far it's
FWIW
http://www.drdobbs.com/embedded-systems/soft-radio/240007489
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
I'll be interested to see how cmake reports the architecture checks for VOLK
here.
pasted below. Hopefully the mailers won't mangle, if so i'll post it to a web
page and send a link.
What happens if you just have a sig_source_f-multiply_ff-null_sink?
:-( It works perfectly, without any
Yes, looks like it. But it's an Atom, which might change things. I
know we had some issues on Atom's before, but I thought that we worked
them out. I'll be interested to see how cmake reports the architecture
checks for VOLK here.
Hi Tom
I've made some further progress, and this may be
The reason this doesn't cause a problem for you in 3.3 is because
that's pre-Volk. This looks like you're running SSE operations on a
system that doesn't support it.
Hi Tom
I shall put together the full list of stuff you mentioned, but 3 quick things
1) the system apparently does support
At the moment it's easily reproducible. Same app runs under GR v3.3 with no
trouble. Let me know if I can provide any more info - in particular, perhaps
there's a special GDB command to dump the xmm register set?
Best Regards
Max
On Wed. Jul 4, 2012 Tom Rondeau wrote
I only know of the Per Vices product but have not gotten my hands on
it. But I'm really happy that they have produced their own GNU Radio
interface for it already.
My biggest question is if it's well-shielded enough for the noisy RF
environment inside a
It has a photo of *both*
Well, two separate photos, if one wanted to be technical ;-)
Max___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On Thu, Apr 5, 2012 at 5:11 AM, Tom Rondeau wrote:
You can use the following link as a guide to debugging segfaults when
they occur:
http://gnuradio.org/redmine/projects/gnuradio/wiki/FAQ#How-do-I-debug-GNU-Radio-in-Python
Hi Tom
I've noticed this issue pop up a few times on the list and
While all of this has been mentioned previously on our op25-dev list, I'd like
to take this opportunity (from the GR 2011 Conference in Philadelphia, Penna.)
to announce a couple of sub-projects which could be put off forever (nothing is
ever truly finished ;-) but nonetheless would benefit
You might also try playing with kalibrate
http://thre.at/kalibrate
it will scan for GSM base stations and use the results to determine
the current local frequency error in your USRP. If you have an
independent means of determining this error frequency, and compare
this with the results of
Nick Foster wrote:
In the real world this problem is usually solved by
dynamically resampling the audio stream at a rate controlled
by a feedback loop responding to the observed clock mismatch.
I have a USRP1 with a BasicTX daughterboard. When transmitting,
what is the proper method in a GNU
In the real world, glitches happen on analog channels.
Which is why you develop techniques to cope with them.
I see the occasional underrun/overrun as equivalent to
these glitches.
Yep - it just so happens that these are digital (P25) channels,
not analog ones, but robust detection/correction
Did anyone use it to receive pi/4 DQPSK signal before?
In the op25-dev project http://sedition.org.au/op25/ we see a
very common variant of PI/4 DQPSK, so-called CQPSK/LSM.
Experimentation has shown that the gr_mpsk_receiver_cc() is not
optimal for CQPSK. There seem to be multiple causes,
Has anyone written a motorola trunk decoder for gnuradio? I'd like to be
able to dump all active audio in a trunk to separate streams by
talkgroup. I'd love to know about any trunk decoders in general.
In addition to Nick's Moto Smartnet II decoder on CGRAN, the op25-dev project
also has a
On Mon, Feb 14, 2011 at 3:09 AM, Venkat Vinod address@hidden wrote:
2. Is time.sleep() function is an appropriate way to use for OFF
cycles in my model ?? If not can anyone suggest me better way to
break the transmission using GNU blocks ??
On Fri, 18 Feb 2011 14:05:33 -0500 Yan Nie
FWIW
Analog to Digital Converter with 16 bits and 448000 Samples
per second based in the Bt878A
http://hackaday.com/2005/11/08/using-a-tv-tuner-as-a-high-speed-adc/
---which takes you to
http://www.domenech.org/bt878a-adc/index-e.htm
---Also see
btaudio.c module modification to get 896000
What you seem to not realize or understand is that the
GNU Radio software that you can compile and putz around
with is worth significantly more to you than any piece of
hardware that will capture or create EM radiation.
Brian is 100% correct.
Could I make just a small attempt to amplify it?
Anybody else had any success in tapping the IQ in a receiver
and feeding that into GNURadio?
Yes - haven't gotten into the 9-10 MHz range IF's, but I have built converters
for 455 KHz IF's - overall they work quite well although there are some slight
compromises in the overall system; for
Have been playing with the channelizer and it's amazing! To re-raise an old
point: IMHO, By all means, the hARRIS (lowercase h notation) should be kept,
IMHO.
1. Sorry if this has been previously asked but I wasn't able to find it - say
we want to channelize a swath but we're only interested
Hello Marcus
Have you tried using the native 'arecord' command ?
This may help isolate whether it's in GR's audio source or what...
Also look within 'alsamixer' for any odd little switches etc
Also, there's a possibility that 192K might only be supported with restrictions
(mono only or
looking for an implementation that's entirely USRP based.
I am only looking to be able to get the demodulated symbols
on the USRP rather than doing it on the PC. Would I need to
implement all of the blocks you mentioned -
Correct. ISTR Stevie's receiver has a squelch block as well...
Also,
Hey all,
Has anyone attempted to implement a C4FM demodulator on the Altera
Cyclone in the USRP1? Right now I'm hoping to do this to read
P25 encrypted packets on the FPGA instead of on the CPU, and I
wanted to know if it was possible. If so, could anyone could
point me to any sort of
On Mon, 6 Sep 2010 17:03:00 -0400 Tom Rondeau wrote:
A trivial change would be to have it loop until it it read
min(N_USER_SPECIFIED_ITEMS, noutput_items) items.
Eric
Indeed, this could be something we want to talk more about.
Kind of on the periphery of my vision, I can see a handful
of
The TX side of the project is still fairly primitive--they have a
hand-coded flow-graph that implements an APCO-25 4-level
FSK modulator, using an *audio* sink, and then carefully plugging the
audio into the guts of a physical radio, right at the [snipped]
Soundcard output direct into a TX
In the case of a real flow-graph, taking real data in at
4800symbols/second, going to a real USRP transmitter, will it still
run in fits and starts or will it do the right thing??
It will do the right thing, assuming that all blocks do the right
thing and compute as much output as they
--- On Fri, 8/20/10, Tom Rondeau trondeau1...@gmail.com wrote:
the polyphase
filterbank approach will perform better than both. This
suggests
either an error in the parameters you chose or a bug in the
code.
Many thanks for the update. A third possibility (albeit perhaps more remote?) -
I've run a comparison test of
- the old GR dqpsk block
- the new one (dqpsk2)
- the op25 cqpsk (Gardner/Costas) block
The resulting constellation diagrams are viewable at
http://www.lightlink.com/mhp/qpsk2/
The results are: Gardner is the winner, the old GR blocks take second, the new
ones
In a word, NEVER. No self respecting communication systems designer would
allow
that much excess bandwidth on the air or any realistic transmission medium.
To me this doesn't make sense. The spectral bandwidth required is never a
function of the
samples per symbol (SPS); it's a function of
--- On Wed, 8/11/10, Tom Rondeau trondeau1...@gmail.com wrote:
If you are using more than 2 samples
per symbol,
you are oversampling. That is, you are wasting your radio's
time and
power processing more samples than is required. The
That wasn't the point - the specific question concerned
Still getting this error message when trying to play with the new block
gr_fir_ccf: using SSE
thread[thread-per-block[1]: gr_block dd_mpsk_sync_cc (3)]: gr_complex must be
8-byte aligned
I've pasted the py program code below - it's trivial. An initial offhand
diagnosis might suggest this is
Trying to experiment with the new MPSK block now in git. Getting the following
error message -
thread[thread-per-block[10]: gr_block dd_mpsk_sync_cc (34)]: gr_complex
must be 8-byte aligned
The ultimate source block in this case is a
gr.file_source(gr.sizeof_gr_complex,...)
The python
67 matches
Mail list logo
