op25-dev

op25-dev@lists.osmocom.org

312 discussions

bch.cc
by Matt D 09 Dec '13

09 Dec '13

Hey guys, Can anyone please explain to me what is going on in bch.cc? I am trying to figure out what ECC is used in there and where it is used exactly. Thanks -- ------ Matt D ------------

2 1

How can I make some changes to the code??
by Matt D 05 Nov '13

05 Nov '13

Hey guys, I deleted my whole op25. checked out a new one. applied Balint's patch, made some simple changes to the hdu.cc ldu1.cc ldu2.cc and tdu.cc files, and built with no errors at all. the changes i made: string hdu::duid_str() const { cout << "HDU"; return string("HDU"); } string ldu1::duid_str() const { return string("LDU1"); cout << "LDU1"; } string ldu2::duid_str() const { cout << "LDU2"; return string("LDU2"); } string tdu::duid_str() const { cout << "TDU"; return string("TDU"); } all i get in terminal when i hear the noise is a few HDUs. No LDU1s or any of the others. There should be like 400 "TDU's. I have been unable to figure what i am doing wrong. Any guidance will be very much appreciated. Thanks. -- ------ Matt D ------------

1 0

trouble getting header data
by Matt D 05 Nov '13

05 Nov '13

Hey guys, Is anyone getting garbage in the traffic pane UI? I deleted my whole op25. checked out a fresh version. r328 if i remember right. did the whole bootstrap, configure, make check, sudo make install dance; and i am getting garbage in the UI. my logfile looks like this: 2013-11-04 11:02:15.797525 HDU Unknown (0) 0xb13f Unknown (0xc4) 0x5f73 2013-11-04 11:05:10.612410 HDU Unknown (0) 0xed38 Unknown (0x9) 0x73f5 2013-11-04 11:09:21.108211 HDU Unknown (0) 0x8100 Unknown (0x77) 0x1dec 2013-11-04 11:09:21.108955 HDU Unknown (0) 0x61 Unknown (0xa5) 0x7300 2013-11-04 11:09:21.281898 HDU Unknown (0) 0x2ba6 Unknown (0xff) 0x63f7 2013-11-04 11:09:21.460865 HDU Unknown (0) 0x63 Unknown (0x8) 0x7100 2013-11-04 11:09:21.650893 HDU Unknown (0) 0xae6f Unknown (0x7c) 0xed67 2013-11-04 11:09:21.834137 HDU Unknown (0) 0x85 Unknown (0x19) 0x6500 2013-11-04 11:09:22.022031 HDU Unknown (0) 0xf984 Unknown (0x6) 0x360c as you can see, none of these fields are good data except the date/time. the HDU should only show up once in while. So something is repeatedly putting "HDU" and the nonsense data onto the thread to the GRC. In addition to that i did a: string hdu::duid_str() const { cout << "HUD\n" ; return string("HDU"); } in the hdu.cc and as expected i hundreds of "HUD"s print in the terminal. so similarly i did a: string ldu1::duid_str() const { return string("LDU1"); cout << "LDU1\n" ; } in the ldu1.cc. and i get no "LDU1"s in the terminal. Ive done this whole routine 3 times and have got the same result. something weird is going here that was not with previous versions. like i said the HDU packets should only come up once in a blue. it would seem that snapshot() is firing off way to many pickles without getting the right data in to them. i have not been able to figure what i am doing wrong here. can someone please do a fresh install and see if the snapshot() and the traffic pane play nice for them? Thanks -- ------ Matt D ------------

1 1

Repeater vs Decoder Code
by lukekb＠gmail.com 01 Nov '13

01 Nov '13

I have put together a C++ based decoder P25 CAI audio (https://github.com/robotastic/smartnet-recorder/blob/master/logging_receive… https://github.com/robotastic/smartnet-recorder/blob/master/logging_receive…) based off the usrp_rx.py file and using the C blocks in /blocks http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks?order=name/src http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src?order=name/l… http://groups.yahoo.com/trac/wiki.png/browser/trunk/blocks/src/lib?order=na…. It using a lot of CPU though. Are the C code blocks for the Repeater any diferent? Should I try building off of those instead? My basic app is recording a SmartNet system. It follows the trunking control channel and the creates loggers to capture the audio from a talkgroup and saves it to WAV file. Right now it is using DSD which has been shoehorned into a GR Block, but I would much rather use OP25. Unfortunately the DSD implementation allows for about 7 concurrent recordings, and I am only able to get about 2-3 using OP25 on a quad core machine. I am sure the fault is on my end, I just want to make sure I am using the best code to base my stuff off of, before I begin trying to track down my problems. - Luke

2 2

pickle.cc and
by Matt D 25 Oct '13

25 Oct '13

-----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-----

2 6

memory error turns weird
by Matt D 24 Oct '13

24 Oct '13

-----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-----

2 2

Build instructions for new release
by ikj1234i＠yahoo.com 24 Oct '13

24 Oct '13

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

1 0

project announcements (again)
by ikj1234i＠yahoo.com 24 Oct '13

24 Oct '13

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

1 0

Fresh Proxies
by keyword_planner＠yahoo.com 18 Oct '13

18 Oct '13

Fresh Proxies http://freshproxies.com/

1 0

Correct decoder: op25_decoder_ff.cc or op25_decoder_bf.cc
by trinmole 11 Sep '13

11 Sep '13

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

3 5

← Newer
1
...
19
20
21
22
23
24
25
...
32
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

op25-dev