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

Hi Scott Thanks a lot for posting these instructions. Reading through your posting, it strikes me that we've still got more work to do :-) First of all, not sure what Stevie wants to do about libitpp, but in the last few days (as you've also discovered) the pybombs repository has added a new official recipe for libitpp. It's probably much higher quality than the one that I slapped together, and in fact now that there's an "official" version out for this recipe, I've been toying with the idea of deleting the one that we have in our repo, since it's more or less obsolete now. However if we did that it your procedures would need to be updated because they mention copying that recipe. Secondly, the entire business of needing to copy the recipes will hopefully be temporary - once we can get the gr-op25.lwr recipe merged into the upstream pybombs. Stevie might have an ETA on when this might happen... But once we have that in place then the procedures become a lot simpler because all you'd need to do to install gr-op25 from scratch on a fresh, empty machine would be to clone the pybombs repo, cd to the toplevel, and then run ./pybombs install gr-op25. The gr-op25 recipe itself has gnuradio as a prerequisite, so it's not necessary for the user to 'pybombs install gnuradio' as a separate step. About the only other thing to mention is that all of the new pybombs/gr-op25 stuff requires gnuradio 3.7. That is, the op25 git repo can't be built against gnuradio 3.6 or earlier releases of gnuradio, due to the extensive API changes going from gr3.6 to gr3.7. Scott, once again, many thanks for all of your feedback and more. It will be very helpful as we try to keep making op25 better, and I'm looking forward to hearing more comments and questions from you. Best Max

Hi Scott We in turn owe much credit to the GNU Radio developers, and a host of others including the osmosdr team. There is an app osmocom_fft -- see http://sdr.osmocom.org/trac/wiki/GrOsmoSDR . That app should already be installed and all set to run since gr-osmosdr is installed by pybombs as a prereq for op25. It has GUI controls for setting the variable RF gain(s). You should see a separate slider for each programmable gain that the RTL stick supports (assuming it has this at all I suppose). I don't have an RTL USB stick - still waiting for my order to be delivered. Would be interested to hear what happens in osmocom_fft - are you able to see any of the LSM CC's using that? There are a few other things to try also using osmocom_fft - first instead of tuning to the exact frequency of the signal, tune (say) 50 KHz offset from the frequency - so if the station you want is at 157.125 try tuning 157.175 - then look for your desired signal 50 KHz leftward from center. Reason for this is to try to avoid the dreaded "DC offset" problem. Another thing to do is add an FM trap (if needed). Anyway, both of the above tuning issues are taken care of with extra parameters to scope.py. But first it's necessary to confirm your RTL can see the signal at all, so it would be good to give osmocom_fft a spin. Also please paste the command line you're using when running scope.py Max

---In op25-dev(a)yahoogroups.com, <verymetl@...> wrote: OK very interesting . First , try adding a new option when you run scope.py -S 250000 which should set the sample rate to 250K. Seems it's unhappy with the default 320K. When you're running scope.py manually you can add the -c NNN option where NNN is the offset in Hz. If you know the PPM (error offset) you can multiply that by the frequency in MHz to get the offset NNN. For example say your PPM error is 2.5 then 2.5 * 851 = 2127 so you would have -c 2127..... You may need to fiddle with the sign (so, also try -c -2127) As far as adjustable gain - looks like you can't adjust the RF gain. Is it adjustable when running osmocom_fft ? Also you can try adding an option -o 50000 if there's a DC offset problem (usually shows up as a spectral line at the tuned frequency even when the antenna is disconnected) so to sum up try ./scope.py --args "rtl=0" -f 851.012e6 -S 250000 -o 50000 -c 2127 Best Max

Yeah 61 PPM seems very high -what do you see the signal when you look at the spectrum plot (you may need to use the +/- keys to bring the spectrum into view) Try starting scope.py with no -c option at all (or -c 0), then look at the "C4FM" display and the "data scope", and use the "fine tune" slider to center the signal horizontally. You may need to try -c 5000 (or -c -5000) to get the signal initially close enough so the slider is able to center it. Eventually you should be able to come up with a value for -c such that the signal is centered without needing to use the fine-tune slider... 45000 seems too high - I'd expect that about +/- 10000 would be as much as you'd ever need at 800 MHz, but I haven't experimented with the RTL yet... Max

I'm using the R820T based turners. The PPM values on these tuners are probably relative to them. I have one that requires 48, and another that need 61. I've gotten the scope tuned pretty close to the desired frequency, but it's just not acting right. The Fine Tune slider does work. When viewing the spectrum scope, I can see the dismal spike shift +-3k as you would expect. The scattered constellation cluster circles around in 360 degrees from center while fine tuning as well. The Signal Gain slider also functions properly as well. I noticed the scope app seems to stutter quite a bit too. The osmocom_fft doesn't do this running at high sample rates(2Mhz). Could this be the cause?? -Scott

Ok, holy crap! Success! LSM baby!! I had to hard code a couple of settings in the scope.py to get things rolling. Here is what I added after the self.channel_rate section: self.src.set_freq_corr(61.0, 0) print "freq_corr %d" % (self.src.get_freq_corr(0)) self.src.set_gain(49.6, 0) The set_gain is what was needed. I don't yet understand what the 'chan' parameter is for, more then one device? I just set it to '0'. This is so awesome Max! (See attached screenshots) -Scott

The -N option is in fact the parameter that I needed. I just didn't know how to use it... ./scope.py --args "rtl=0" -f 853.265e6 -S 250000 -c 10000 -N 'LNA:49' I've since removed my hack.. *facepalm* I did try and use the -T option, but it doesn't like the trunk.tsv format. Here is the error it's thowing: File "/usr/lib/python2.7/ConfigParser.py", line 512, in _read raise MissingSectionHeaderError(fpname, lineno, line) ConfigParser.MissingSectionHeaderError: File contains no section headers. file: trunk.tsv, line: 1 '"Sysname"\t"Control Channel List"\t"Offset"\t"NAC"\t"Modulation"\t"TGID Tags File"\t"Whitelist"\t"Blacklist"\n' -Scott

Ok, that solved that problem, thanks! The only changes I made were in the scope.py script, and it did not replace that file, so I'm good to go.. If I park on a voice channel, I'm getting near perfect voice decoding. Sometime transmissions appear to be data related and I get no voice. I don't have the TIA docs so I can't confirm what the data stream is telling me. Running the app with an offset cc frequency doesn't seem to apply to the voice channels. Same as if I specify an offset to the tsv file for this system. If I don't use offset tuning, it isn't tracking very well. So there is some tweaking I need to figure out for proper trunking functionality. -Scott

---In op25-dev(a)yahoogroups.com, <verymetl@...> wrote: My RTL sticks finally arrived from the East. Here are a few random comments... First the "Offset" that appears in the per-system trunking config file is in Hz, not in PPM. This is something that would be nice to get rid of entirely, and fold the functionality into the global PPM which only changes when the USB stick is changed to a different one. However there are still issues. The QPSK PLL in OP25 doesn't have a separate frequency-correction loop (yet), it only has a phase detection capability right now, which means that the tuning has to be closer than 1,200 Hz to the nominal carrier frequency. One PPM error at 850 Mhz would be 850 Hz of error, which means that for best results we'd need to use a fractional PPM. Accordingly the "Offset" Hz value provides a much finer method of tuning than the PPM. All this would be a non-issue if GPSDO clocks were used, then there would be neither PPM error nor offset error... A separate issue with the RTL sticks is there is a very long latency for the device to change frequencies, approx. 1.6 seconds after the frequency-change is commanded by the trunking receiver controller logic. This means that if we're switching from the trunk CC to a voice channel there's an excellent chance by the time we finally arrive on the voice channel that the transmission has already ended, followed by another 1.6 sec. delay before the control channel can be re-acquired. The cause of this extreme delay is not clear at this time. This delay does NOT occur when using the USRP; trunking following is very fast. Also the problem doesn't bite when Hamlib-tuned receiver is used. This is interesting re: the RTL USB stick because there is a hack to add support for the direct sampling mode (you have to do some soldering). So, the Hamlib controlled receiver is tapped at the final IF (455 K.C. or 10.7 M.C) and that would be fed directly to pin 1 or 2 of the RTL2832 using suitable matching circuitry (the hamitup converter is another option, but not as cool as this direct-input hack)... OTOH, the HackRF unit DOES seem to suffer from this or a similar timing problem... Max