-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hey guys,
in the op25 traffic pane, the thread that waits for new data to be
received, waits to receive the pickled values for the fields in the
traffic tab, can someone please tell me exactly where the thread gets
its pickle from?? it is a c++ map right? the pickle i mean. does
anyone know what file that comes from?
beucase i commented out the functions in the pickle.cc pickle.h, in
op25/blocks/src/lib rebuilt same as stated on osmocom and i am still
getting updated data in the python UI. how can this be??
is the pointer to that thread: gr_msg_queue_sptr d_msgq; i cant
comment out anything in the snapshoit_du_handler beucase it wont biuld
if i do.
THanks!
- --
- ------
Matt D
- ------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSaId/AAoJECrdp7MWSIVbvVgIAIp0MFwgbyzTDuxBuQLHcqkG
WuMT3o7u7ShiS0j1uXjUaaBGSl/55qn98jTLDMMLZIBKdTqDv0czPlWLEHRQTijM
wFuftN53zC1E2+USxLqyvNGV1UjkAxMlvY4liKDAfR4LCdWUrVRHJsUTzgOQ8/gw
CgsV9UAevVHyhzW/s5c7NT+iHNdfLgmlyhNLMOS3D2z1zQLnEy4dUotOey0V7KxX
Wfc89vdlmaSriAywNt/JaqMFkP9eU+Csh5rwOV87WU6jqOBiXV6WutIyW0F+gnRx
DVgaxfXDwaKrVOaUwQtpaXicXrCLVAKJLX/Z78Lewqbu8nW2Fl3lc4qhXCj8jJs=
=cwsj
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hello,
has anyone seen this error??? :
*** glibc detected *** /usr/bin/python: free(): invalid pointer:
0xaea02a58 ***
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(+0x75ee2)[0xb75a7ee2]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZdlPv+0x1f)[0xb69a6adf]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSs4_Rep10_M_destroyERKSaIcE+0x1b)[0xb6a0e7bb]
/usr/lib/i386-linux-gnu/libstdc++.so.6(+0xb0800)[0xb6a0e800]
/usr/lib/i386-linux-gnu/libstdc++.so.6(_ZNSsD1Ev+0x2e)[0xb6a0e86e]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN19snapshot_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x2a6)[0xb2d79e56]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN17data_unit_handler6handleEN5boost10shared_ptrI9data_unitEE+0x54)[0xb2d78c74]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN16voice_du_handler6handleEN5boost10shared_ptrI9data_unitEE+0x66)[0xb2d7b116]
/usr/local/lib/python2.7/dist-packages/gnuradio/_op25.so(_ZN15op25_decoder_bf14receive_symbolEh+0x18c)[0xb2d92bec]
my guess is the memory mix up is happening here:
void
snapshot_du_handler::handle(data_unit_sptr du)
{
if(d_msgq) {
string snapshot(du->snapshot());
if(snapshot.size() > 0) {
const size_t snapshot_sz = snapshot.size() + 1;
gr_message_sptr msg = gr_make_message(/*type*/0,
/*arg1*/++d_data_units, /*arg2*/0, snapshot_sz);
char *snapshot_data = reinterpret_cast<char*>(msg->msg());
memcpy(snapshot_data, snapshot.c_str(), snapshot_sz);
d_msgq->handle(msg);
}
}
data_unit_handler::handle(du);
}
but wait the issue gets more interesting than 'du' pointing to an
invalid location:
to try to see if i could stop op25 from giving this dying error, i
commented out all of the snaphot()s in the hdu, ldu1, ldu2, and tdu.
but i am still getting all of the pickled data in the python UI.
¿¿ WTH ??!! can someone please explain to me what i am missing here?
- --
- ------
Matt D
- ------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: MacGPG2 - http://www.gpgtools.org/macgpg2.html
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSZ9MgAAoJECrdp7MWSIVbPrsIAKJF/SZ5SY7F54sykWLHxFyB
eJmCW7q9PhsSshC6UU0+ogrYrVvmp2Du/PaNgfqQlMPJmsslJMe2RRRDul2jaosW
I9ZcAzRDXxaTfHP1g+SqIqfLGlvW7LRydq/Hpzczj6UD6GnkyMz6eaWNKuw+cis7
ZsqmaJZYzxDDfFvD5wm1xAnV1VUPSlwENV9BRUo+40TQBWs4nmJI/rge7BPByH6f
ttASLCERBDPX9gts9PeWtF1nnYgFR6rubDAKbc6sG7byi/TPGvbOIjrGKd/r9wEx
QobOYPxf0uKdkH4V2FRUhDMdJX/rR8fv109KFLr2K7eyAziyqEMqXwjNC9IH3iA=
=FWv5
-----END PGP SIGNATURE-----
Software prerequisites include GNU Radio 3.7; also cmake; as well as the current list of build packages listed on the build instructions page http://op25.osmocom.org/trac/wiki.png/wiki/BuildInstructionsPage
Once this is done and the tar.gz file has been downloaded and unpacked from
http://mattrobert.com/Wireless/op25-gr3.7-0.01.tar.gzThe two subdirectories, gr-op25 and gr-op25_repeater must be built as follows
cd ......./gr-op25
mkdir build
cd build
cmake ../
make
sudo make install
[repeat the above commands for gr-op25_repeater]
cd ......./gr-op25_repeater
mkdir build
cd build
cmake ../
make
sudo make install
Well - in the previous message I failed to give credit that is due to Jeff Long who contributed the changes to gr-op25 for the GNU Radio 3.7 conversion effort. Many thanks for this contribution which represents a lot of tedious effort! Was great seeing you again at the 2013 GRCon in Boston!
Also, sorry the previous announcement was formatted strangely, the opportunity to 'preview' postings has been removed :-( Here is another try - maybe the scrollbars will disappear this time
Max
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I'm pleased to announce a major new OP25 release, which may be
downloaded at http://mattrobert.com/Wireless/op25-gr3.7-0.01.tar.gz
The code has been completely reorganized with the following key changes:
1) This release of OP25 is compatible with GNU Radio version 3.7 (or newer)
2) The build system has been changed from autotools/autoconf to cmake
3) Support for gr-osmosdr has been added. This means that (in addition to
USRP support) hardware support is extended to all devices supported
by osmosdr (see http://sdr.osmocom.org/trac/wiki/GrOsmoSDR for a
complete list of supported hardware)
4) Experimental trunk tracking support for IMBE voice channels now
included (optimized for LSM/CQPSK) in the signal scope application
Not all pieces (in particular the python scripts) have been converted
to the new format yet. Other pieces (for example the Wireshark plugin)
should continue to be downloaded from the SVN repository while we work
on pulling them into to the new codebase.
Please excuse the mess - we're working to make improvements and this
release is the first step in that process. These code updates will
be released as tarballs for the interim period until we can our GIT
repository is established. Please notify the list of questions or
problems with this new release.
For more information about the trunking and voice support which has
been added to the scope.py app see the wiki page at
http://op25.osmocom.org/trac/wiki.png/wiki/SignalScopePage
I am trying to use the OP25 blocks for a C++ program. I have everything running fine as a .GRC. I also have a makefile to bundle everything up into a library.
I am confused which C++ blocks I should be using - should it be op25_fsk4_demod_ff.cc connected to op25_decoder_ff.cc ?
op25_decoder_ff.h get exported to /usr/include/ however only op25_decoder_bf.cc is included in the Makefile.am
There is no op25_fsk_demod_fb.cc so I am not sure how I would connect the decoder_bf block in.
What are the correct C++ blocks to use to replicate the "OP25 FSK4 Demod" & "OP25 Deocder" Python Blocks?
Are there any C++ programs I could use as an example?
Thanks for any pointers!
- Luke
Hey,
I am interested in writing the shortened hamming decoder and rs decoder
for the LC information. Is there any sort of reference manuals that
describe how the shortened hamming code is implemented? From looking at
the op25 lib; op25_hamming.h in particular, it looks like its being done
bitwise in
hamming_15_decode function. i just really don't know what that giant
encoding array & the small decoding array are and how those relate to
the generator matrices in the tia pdf?
i think i kind of have to know what those are about before i can proceed
to write a decoder of the LCWs. But thereafter i suspect it shouldn't be
to hard.
the matrix algebra approach is how i understand how to decode hamming
codes and that approach is not used in op25. furthermore I am not sure
if implementing an algebraic approach would be appropriate (ie. fast
enough) for our use here?
so it would be a big help if I knew how exactly the hamming_15_decode
function works, and in particular what those to arrays (encoding &
decoding) are, and where they come from, and how the generator and
parity matrices (or functions) are utilized?
Thanks!
--
------
Matt D
------------
on my most recent crash there was a little more information than before.
after the memory map in the shell where the crash occurred there is now
this message:
^CTraceback (most recent call last):
File "/usr/local/bin/gnuradio-companion", line 63, in <module>
ActionHandler(args, Platform())
File
"/usr/local/lib/python2.7/dist-packages/gnuradio/grc/gui/ActionHandler.py",
line 70, in __init__
gtk.main()
and the new from gdb:
warning: .dynamic section for
"/usr/local/lib/python2.7/dist-packages/gnuradio/gr/_gnuradio_core_runtime.so"
is not at the expected address (wrong library or version mismatch?)
--
------
Matt D
------------
Hi,
When compiling i did 'configure --enable-debugging'.
so the memory error finally crashed op25 and the core file dumped. i
ran 'sudo gdb /home/matt/OP25_GRC/op25_grc.py /home/matt/core.8995'.
I hardly got anything out of gdb (i attached a copy of what was in
terminal) but it did say the /home/matt/OP25_GRC/op25_grc.py was not in
executable format: file format not recognized.
What am I doing wrong here?
--
------
Matt D
------------
Sorry to drag up an ancient thread. I was wondering what specific modifications were needed for the general_work function of op25_decoder_ff.cc?
Does only returning synthesized frames work or does IMBE expect for some empty results to be inserted where there is no data to smooth things out? I am trying something similar using DSD and the WAV files I record with only synthesized data do not sound as good as audio played back with empty frames returned when no data is available.
Thanks for any tips you have!
Luke
--- In op25-dev(a)yahoogroups.com, "Balint" <balint256@...> wrote:
>
> Dear all,
>
> I've uploaded to the Files section of the board a new 'audio_p25_rx.py',
> which is the original file modified to output IMBE audio, and read/write
> WAV/float data files (since I don't have a USRP and use a discriminator
> tap).
>
> Some notes:
>
> # wx must be set to 'nongl' mode (widgets are the older non-OpenGL type)
>
> # Make sure your ~/.gnuradio/config.conf has a '[wxgui]' section, which
> contains the line 'style=nongl'
>
> #
>
> # Voice output requires the environment variable 'IMBE' set to 'soft', AND
> modification to op25_decoder_ff.cc to prevent
>
> # excessive zero values being output (which chops up the real output
> stream and produces too much silence) - this can
>
> # be done by only producing 'general_work' output values when actual voice
> data is synthesised (i.e. return the number
>
> # of synthesised samples produced and don't pad the output buffer with
> silence)
>
> #
>
> # If you want to capture using Wireshark, don't forget to run this as root!
>
> # Use the '-w' wait option, then start Wireshark and begin capturing, then
> return to your terminal and hit any key.
>
>
>
> In addition, I've found that software_imbe_decoder dies sporadically at
> 'decoder/src/lib/software_imbe_decoder.cc:1022'. I believe this is because
> the class member variable 'OldL' is left un-initialised, and used as such on
> line 1018. Adding 'OldL = 0;' to the class constructor (line 756) appears to
> fix the problem (and causes the 'OldL == 0' check on line 1005 to kick in).
>
>
>
> Please let me know if you try the new Python code and have any problems.
>
> Balint
>
