Package gnuradio-core was not found error [2 Attachments]
I really hate bothering others, but I'm having trouble installing OP25 and don't know how to proceed. I'm getting a 'Package gnuradio-core was not found in the pkg-config search path.' error message when executing ./configure I'm running Ubuntu 12.04, and I have successfully installed GNURadio v3.7.2.1 from the build-gnuradio script on their install from source page. I've tested the install with an RTL dongle and a quick FM demodulator and it does function properly, as well as a spectrum plot. All the required dependencies for OP25 have been met, with the exception of the gr-4fsk package. It throws the same error as stated above. I've attached the logs for both installs, as they're too long to paste in here. I've Googled and searched here at op25-dev to no avail. I'd really appreciate any hints as to get past this last hurdle. I'm anxious to play with Max's LSM/CQPSK tools. Thanks for reading! -Scott
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
Ok, one thing I neglected to mention(not on purpose) is I installed an op25 package from Matt Robert's web link. I found it from an old post(997) of yours here in the group. It was a succesful install, but it did not contain any of the tools I was looking for. Having said that, how do I clean up that install? Will the git source take care of that? I'm not finding anything related to 'gr-op25' or 'max-pybombs' anywhere. Please forgive me for being a little too green with all this stuff. I'm normally pretty self-proficient in that I can figure things out on my own. I'm not in my comfort zone here, but I'm determined. Thanks for the help Max. -Scott
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
I'm pretty sure I understand how this install process works now. Thank you for the guidance. I'm kind of digging the pybombs concept. I chose to install the max-pybombs branch, which ended with an 'installation ok via: src' message. I wasn't able to save the install log, as terminal buffer was limited. I'm still trying to figure out where things are getting installed. But I'll figure all that out eventually... One note about the OP25 recipes, there was already one named 'libitpp.lwr' in the default pybombs/recipe directory. Both files were different sizes, and I over-wrote the stock one. I should have compared the two, but I didn't. I got curious about the max-trunking-update1 branch and pulled that down to check things out. I noticed that the recipe in that branch points to the max-pybombs branch. I'm guessing this is in error? Thanks again Max! -Scott
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
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@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 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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] On Behalf Of verymetl@hotmail.com Sent: Thursday, January 16, 2014 1:53 PM To: op25-dev@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@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 Bob, This shouldn't be taken as an definitive installation guide. There are some assumtions in that you need to know how to navigate around a file system from a command line. If anyone has any corrections, feel free to chime in! Having said that... I do not recommend any pre-installed GNURadio installations. This will ensure you obtain the current stable releases of everything needed. You first have to choose an operating system. I chose the latest stable release of Ubuntu 12.04 LTS. That is available here: http://www.ubuntu.com/download/desktop There is nothing remarkable about installing the OS, it's pretty straight forward... The OP25 wiki specifies a GNURadio version of 3.6 and higher. I chose to install the latest, v3.7 from the 'Installing From Source' method. Knowing what I know now, you can skip that step and go straight to installing from the PyBombs repository. This will install v3.7 of GNURadio and all it's dependencies. This will save you about two hours, as the GNURadio install takes this long to complete. PyBombs takes just as long. From the 'PyBOMBS GNU Radio Build Quick Start' page located here: http://gnuradio.org/redmine/projects/pybombs/wiki/QuickStart git clone git://github.com/pybombs/pybombs cd pybombs ./pybombs install gnuradio Assuming everything installs without errors, you should have a working copy of GNURadio installed. Now we need to pull in the OP25 source and the max-pybombs branch: git clone git://op25.osmocom.org/op25.git cd op25 git checkout max-pybombs There are two recipe files(pybombs install scripts), gr-op25.lwr and libitpp.lwr that you need to copy from op25/pybombs/recipes directory into the pybombs/recipes installation directory from above. There will already be a 'libitpp.lwr' dependency file in the pybombs/recipes dir, you can either rename it to something else(change the extension), or overwrite it like I did. Once you've copied the files to the pybombs/recipes directory, you need to go to the pybombs installation dir and execute the following command: ./pybombs install gr-op25 If everything installs without issue, you now need to set up the runtime environment variables in order to run the OP25 scripts. You should still be in the /pybombs install location, now execute the following command: ./pybombs env This will print out some paths to various things and a location to a shell script that will set these same variables. Execute this script as follows: source /foo/bar/setup_env.sh (use the path that actually prints out on your screen!) That's it, good luck! -Scott
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 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
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
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
---In op25-dev@yahoogroups.com, <verymetl@...> wrote:
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
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
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..
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
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
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
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
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
:-) 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
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
'"Sysname"\t"Control Channel List"\t"Offset"\t"NAC"\t"Modulation"\t"TGID Tags File"\t"Whitelist"\t"Blacklist"\n'
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
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
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
---In op25-dev@yahoogroups.com, <verymetl@...> wrote:
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
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
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, <verymetl@hotmail.com> wrote:
[Attachment(s) <#14391f36165701d6_TopText> from verymetl@hotmail.comincluded below]
I really hate bothering others, but I'm having trouble installing OP25 and don't know how to proceed. I'm getting a 'Package gnuradio-core was not found in the pkg-config search path.' error message when executing ./configure
I'm running Ubuntu 12.04, and I have successfully installed GNURadio v3.7.2.1 from the build-gnuradio script on their install from source page. I've tested the install with an RTL dongle and a quick FM demodulator and it does function properly, as well as a spectrum plot.
All the required dependencies for OP25 have been met, with the exception of the gr-4fsk package. It throws the same error as stated above. I've attached the logs for both installs, as they're too long to paste in here.
I've Googled and searched here at op25-dev to no avail. I'd really appreciate any hints as to get past this last hurdle. I'm anxious to play with Max's LSM/CQPSK tools.
Thanks for reading!
-Scott
participants (4)
-
ikj1234i＠yahoo.com -
Matt Mills -
Robert A Klamp Jr. -
verymetl＠hotmail.com