This is partially our fault, the documentation sorely needs to be updated. The root cause of problem you've encountered is that GNU Radio v3.7 is installed but you're attempting to build the old pre-gr-3.7 version of op25. The new 3.7 version (gr-op25) is now in git and there is a new branch (max-pybombs) that contains a pybombs recipe that's set up to build gr-op25 against gr version 3.7. You should be able to build the new version using roughly the following steps - clone the gr-op25 git repo and also clone pybombs - switch to gr-op25 branch max-pybombs - copy the two recipes in the gr-op25 pybombs/recipes (*.lwr) to the pybombs recipes/ directory - use pybombs to build and install gr-op25 (./pybombs install gr-op25) The above may run into issues - we can't fix them if we don't hear about them... Best Max

git clone git://op25.osmocom.org/op25.git then git checkout max-pybombs Also, there have been numerous trunking updates - see the signal scope page (scroll down approx. 2/3) http://op25.osmocom.org/trac/wiki.png/wiki/SignalScopePage For the trunking updates there is a separate branch max-trunking-update1 which should be a superset of max-pybombs . As for the existing installed version(s) of op25, if you go through the pybombs process it will install a copy of gr-op25 in a separate location that in theory should not conflict with other prior version(s). Max

Hi Scott Thanks for the update. First the diff between max-pybombs and max-trunking-update1 does not affect the pybombs installation process at all. You just need to switch to the max-pybombs branch in order to get access to the recipes. Once it's installed via either of the two max-* branches you can access the trunking stuff since that's strictly python code changes having nothing to do with pybombs. The confusion should all go away once the recipes get pushed to master, then there won't be any need to call out a specific branch in pybombs at all. In order to set up the proper run time environment pybombs has a subcommand called 'env'. So you would run ./pybombs env This will write out a file (it will print the file name) which you would then source using the shell (assuming bash shell and assuming pybombs writes out the file named /foo/bar/setup_env.sh), you would do source /foo/bar/setup_env.sh Once this is done you can then 'cd' to the op25_repeater/apps directory and you should be able to invoke ./scope.py as per the wiki page... Please let us know how you make out and if you have any further questions. Best Max

Please if you have a step by step or just some good information on the new install process please post it. Linux is not my native operating system and all these PyBombs and things are really confusing. I would be very grateful to get some direction on the matter as you said from one noob to another. Thanks, Bob From: op25-dev(a)yahoogroups.com [mailto:op25-dev@yahoogroups.com] On Behalf Of verymetl(a)hotmail.com Sent: Thursday, January 16, 2014 1:53 PM To: op25-dev(a)yahoogroups.com Subject: [op25-dev] RE: Package gnuradio-core was not found error Hi Max Just a quick note as not to leave you hanging.. Setting the proper run time environment solved all my issues with running the OP25 python scripts. So I think I'm good to go now as far as having a working install. It was really a lot less painful then I expected the whole process to be. I'm now happy I took the plunge. I'm contemplating wiping the partition and starting fresh, then document it all for others to follow. From one noob to another, so to speak. Due to my inexperience with Linux left me with a messy install anyway. The path to gr-op25_repeater/apps is eight layers deap from home. Too much typing.. heh I do have several questions, but I'll post those in new topics unrealated to the install process. Thank again for all the help Max, it's appreciated! -Scott ---In op25-dev(a)yahoogroups.com, <ikj1234i@...> wrote: Hi Scott Thanks for the update. First the diff between max-pybombs and max-trunking-update1 does not affect the pybombs installation process at all. You just need to switch to the max-pybombs branch in order to get access to the recipes. Once it's installed via either of the two max-* branches you can access the trunking stuff since that's strictly python code changes having nothing to do with pybombs. The confusion should all go away once the recipes get pushed to master, then there won't be any need to call out a specific branch in pybombs at all. In order to set up the proper run time environment pybombs has a subcommand called 'env'. So you would run ./pybombs env This will write out a file (it will print the file name) which you would then source using the shell (assuming bash shell and assuming pybombs writes out the file named /foo/bar/setup_env.sh), you wo uld do source /foo/bar/setup_env.sh Once this is done you can then 'cd' to the op25_repeater/apps directory and you should be able to invoke ./scope.py as per the wiki page... Please let us know how you make out and if you have any further questions.< /p> Best Max

You are using the old SVN version that is not compatible with gnuradio 3.7. You need to use the new GIT version that uses cmake instead of all the bootstrap stuff. It hsould be available on the op25 git repo now, or tarballs are available further in the mailing list archive. On Tue, Jan 14, 2014 at 11:11 AM, &lt;verymetl(a)hotmail.com&gt; wrote:

Hi Max, In all fairness, all credit goes to you, Steve and MattSR and everyone else involved for putting this together in the first place. I think I just happened to catch things at the right time that made installing much easier then it has been in the past. I've watched the OP25 project for a few years now, mostly because of your LSM research and discovery. I'm not really sure I'll be able to utilize the OP25 project to it's fullest potential, but my goals were simple to begin with. My main purpose was to use the scope app you wrote to see if I could get stable constellation/symbol plots. The LSM system I'm interested in has four control channels that all exhibit different characteristics. One channel I can get 100% squelch lock on my scanner, two others with intermittent locks, and one that rarely gets locked on. Guess which one rarely gets used, and which one is almost always used?? yeah... Assuming I can achieve decent demodulation of LSM, at the very least, I'd like to put something simple together that would send a cleaned up signal out the sound card(48k or 96k) into another PC running the Unitrunker app. Ideally, I'd like to send assembled P25 packets out a UDP port for processing elsewhere on the network. I've always wanted a data pump style app for processing trunking packets. At the moment, I'm not having any success getting my RTL device tuned right. I'm not seeing the obvious spike on the spectrum scope. Looking though the scope python code, I don't see any references to change the ppm correction settings, or AGC settings related to the RTL devices. I found the code in the osmosdr_src_c source related to those settings, so I can hard code them if I need to. I'm too tired to mess with it tonight though.. I'll tackle that tomorrow. Thanks to the OP25 team for the awesome goodies! -Scott

Hello Max The osmocom_fft app is the first thing I ran upon install. It does in fact display the desired spectrum as expected. However, in order for the app to display the ppm slider, you must specify a ppm value from the command line parameter. e.g. -c 61 Here is an example for any new comer that comes along; (This will show the relevant tweek settings at run time.) osmocom_fft -a rtl=0 -v -f 853.275e6 -s 2.4e6 -g 49 -c 61 --dc-offset-mode 0 --iq-balance-mode 0 -W The last parameter -W is for the waterfall. Use -S for the oscilloscope view. As far as your scope script, I invoke it like this: ./scope.py --args "rtl=0" -f 851.012e6 Here is the intial responce linux; GNU C++ version 4.6.3; Boost_105300; UHD_003.006.002-64-g92b0b7ab gr-osmosdr v0.1.0-59-g7ae3e985 (0.1.1git) gnuradio v3.7.2.1-137-gf7f28bbd built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace Using device #0 Realtek RTL2838UHIDIR SN: 00000061 Found Rafael Micro R820T tuner gain: name: LNA range: start 0 stop 0 step 0 supported sample rates 250000-2560000 step 24000 Using Volk machine: sse3_32_orc Invalid sample rate: 320000 Hz set_center_freq: 851012000 I've never gotten the script to except a valid sample rate either. I'm assuming it's passing an invalid format to the osmosdr subsystem? I also don't think it's setting the frequency correcly, though it's not complaining. All plots look the same no matter what frequency I enter. I'm not sure how to proceed, so I'll wait for your instructions.. Thanks Max -Scott

It took that sample rate.. here's what I used: ./scope.py --args "rtl=0" -f 853.270e6 -S 250000 -o 50000 -c -45000 output: built-in source types: file osmosdr fcd rtl rtl_tcp uhd hackrf bladerf rfspace Using device #0 Realtek RTL2838UHIDIR SN: 00000061 Found Rafael Micro R820T tuner gain: name: LNA range: start 0 stop 0 step 0 supported sample rates 250000-2560000 step 24000 Using Volk machine: sse3_32_orc Exact sample rate is: 250000.000414 Hz set_center_freq: 853275000 853.2750 is the frequecy I need, with a PPM value of 61 which is used by all rtl_sdr programs. I don't think I'm setting the offsets corrctly..

Reading more about the RTL - can't wait for mine to show up. However, might have spoken too soon, 61 PPM might be a little on the high side but maybe it's not unreasonable for the RTL. In any case, if you can get the scope.py spectrum FFT plot working it should be simple to center the signal... Which tuner chip do you have, the E4000 or the R820T ? Max

Hi Scott Could you post some screen captures, I'd like to see - eye (data scope) - constellation (select: mode=standard; color=mono; source=differential) - demodulated symbols (be sure to select "PSK" not "FSK4" for this) - those three are the main ones, would also be good to see the C4FM and Spectrum displays - on my laptop there is a "prt sc" / "sys req" key that brings up a print screen dialog On the stuttering - what values of -S (besides 250000) have you tried so far? Note that this version of scope.py only processes a single signal at a time, so it can use the lowest sampling rate that's supported by the hardware, the lowest tested rate is 96K. The valid rate ranges should be printed out when the program starts up. The only thing that a 2M rate would really accomplish is to burn additional CPU. Max

:-) I'll have to wait til my RTL order arrives in order to get to the bottom of the issues, but there is a gain setting parameter (-N) that might also work. Many thanks for your feedback. Would be interesting to have you set up scope.py using a trunking (-T) configuration - I'd also be curious to see how you make out on LSM voice channel decoding. The constellation plot shows that there is a nice zone in the vicinity of the origin (0,0) where there is no signal energy, but that the symbols are not all concentrated at the circumference. This plot is ultra-typical of LSM. If you have a directional antenna you can use that as a guide to aiming the antenna for best reception - just adjust such that all the symbols move away from the center... Max

ah - sounds like you're not running the latest version - you'll need to git checkout max-trunking-update1 Not necessary to recompile or re-install anything, the changes are confined to the python apps/ directory. When changing branches using git checkout it may obscure any local changes you've made, so you may want to move any such changes aside prior to switching branches. You can also do 'git status' to see what's what... Max

Yeah, the way that offset errors are handled is in need of a revisit, I'll be making those decisions after reviewing the RTL (they must be on a slow boat from the East). Basically the "-c" (calibration) was the old way that scope.py took care of offsets, and when the new trunking support was grafted on that was supposed to be replaced by a per-system offset in the TSV file. Ideally it would work the same way as other osmo apps - specify the offset in a single parameter. BTW it won't work if you specify the offset twice, once on the command line and then again in the 'offset' parameter of the TSV file; one or the other is enough. One reason I'm skeptical of the command line offset is it seems to be a non-linear function of frequency... It's possible with your "frequency correction" patch to scope.py that's taken care of all issues, and you can just set "-c" to zero and "offset" in the TSV files likewise to zero...... Not sure until I've had a chance to play with the hardware... Nonetheless your reports are very encouraging! It's possible also that you're on an encrypted channel. You can adjust the value of the "-v" parameter upwards (try -v 15) - that will print out a running log of frame activity to the console - should be able quickly to separate whether you're seeing voice or packet data or what... Max