op25-dev

op25-dev@lists.osmocom.org

307 discussions

by Stephen

Hi, Where would I find the library for op25? It looks like everything builds but I can't find a .a file for op25. The only library I can find is libimbe_vocoder.a. Am I missing something? stephen

12 years, 7 months

op25 New Install What version Of Ubuntu? What Version of GNURadio?

by Andrewiski

I am setting up an Ubuntu pc for the sole purpose of running op25. I am struggling getting op25 to work on Ubuntu 12.10 as GCC 4.11 does not seem to be available to install anymore because it has compatibility issues with the newer version. At least that is what I have found on the web. Anyways I have the need to view raw p25 packets to trouble shoot a bug with a specific radio's data packets. I have two ways to receive the audio stream either via discriminator tap or via usb rtl-sdr. In Ubuntu 12.10 I have done the following. Failed to build GNURadio 3.2.2 with compiler errors, not missing imports but things like invalid syntax etc so preaty sure it is because I can't use Gcc 4.11 in Ubuntu 12.10 Successfully installed GNURadio 3.6 via builtin" Ubuntu Software Center" installer Successfully make and install op25 at least didn't get any errors. Successfully make and install patched version of wireshark. Successfully make gr-fsk4 but had to add stderr definitions to a couple of the files to fix make errors also had to copy gruel_common.i from /usr/local/include/gruel/swig to /usr/local/include/gnuradio/swig to fix missing gruel_common.i error Succesfully make imbe_vocoder. I tried to run "./audio_p25_rx.py a" from the op25/python directory but kept getting an "importError: no module named op25" error. I tired setting PYTHONPATH environment variable to /usr/local/lib/python2.7/dist-packages where the op25.py file was located (http://www.youtube.com/watch?v=86KtgkaH5H0) but still same error so I copied all of the op25/python/ files to /usr/local/lib/python2.7/dist-packages/gnuradio folder I ran it there and still got op25 errors. I figured it was an issue with gnuradio version so I uninstalled gnuradio using Ubuntu Software center. I also did a "make uninstall" on the gr-fsk4 I installed earlier because it seems to have been replaced in op25 with gr-baz. gr-baz is included in this install script I did a build of gnuradio and a buch of other needed tools using a script located at (http://www.sbrac.org/files/build-gnuradio) I made a folder new folder src in my home directory I coped the build-gnuradio script to this folder. I then ran chmod 755 build-gnuradio to allow execution. I ran "./build-gnuradio v all" (took awhile and had some warnings but no errors) Now things started to work at least without the import errors so referenecs seem to be a lot better. I can run ./rtl_sdr and do a capture so thats a plus as I know my cheap sdr usb receiver is working. If I run ./audio_p25_rx.py I get the following errors Using Volk machine: sse4_1_64 Traceback (most recent call last): File "./audio_p25_rx.py", line 1044, in <module> app = stdgui2.stdapp(p25_rx_block, "APCO P25 Receiver", 3) File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 38, in __init__ wx.App.__init__ (self, redirect=False) File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7981, in __init__ self._BootstrapApp() File "/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 42, in OnInit self._max_noutput_items) File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 64, in __init__ self.panel = stdpanel (self, self, top_block_maker, max_nouts) File "/usr/local/lib/python2.7/dist-packages/gnuradio/wxgui/stdgui2.py", line 86, in __init__ self.top_block = top_block_maker (frame, self, vbox, sys.argv) File "./audio_p25_rx.py", line 97, in __init__ self.__init_gui(frame, panel, vbox) File "./audio_p25_rx.py", line 276, in __init_gui self.spectrum_plotter = self.spectrum.win.plot AttributeError: 'fft_window' object has no attribute 'plot' If I open and execute (http://svn.spench.net/main/gr-baz/samples/OP25.grc) from http://wiki.spench.net/wiki/Gr-baz#grc I get the follow errors Using Volk machine: sse4_1_64 Traceback (most recent call last): File "/home/andrewadevries/op25/op25_grc.py", line 563, in <module> tb = op25_grc() File "/home/andrewadevries/op25/op25_grc.py", line 306, in __init__ self.rtl2832_source_0 = baz.rtl_source_c(defer_creation=True, output_size=gr.sizeof_gr_complex) AttributeError: 'module' object has no attribute 'rtl_source_c' Any one offer some suggestions?

12 years, 7 months

Trouble running OP25

by rbrtklamp

Hi I am new to the group and GNUradio. I have installed gnuradio on ubuntu 12.04 from the directions at this link. http://blogs.bu.edu/mhirsch/2012/07/installing-gnu-radio-in-ubuntu-12-04-x6… I then went to the build instructions page and followed them to the T, all seemed to be going well but when I enter the command line to start it ~/src/op25/python$ ./audio_p25_rx.py -a I get this error message robert@robert-laptop:~/src/op25/python$ ./audio_p25_rx.py -a Traceback (most recent call last): File "./audio_p25_rx.py", line 34, in <module> from gnuradio import audio, eng_notation, fsk4, gr, gru, op25 ImportError: cannot import name fsk4 robert@robert-laptop:~/src/op25/python$ Can anybody please help me get the program running I am not great with software code and really need to get this up and running for a current project I am a part of. I am hoping this issue can be resolved with a couple of command lines. Thank You For Your Time and Help, Robert Klamp Jr.

12 years, 7 months

Patches & instructions to get OP25 working with UHD/GRC/DES-OFB

by Balint

Hi folks, It has taken a little longer than I anticipated, but it's all here: http://wiki.spench.net/wiki/OP25 The page describes: . Getting the latest OP25 working with the latest GNU Radio (one easy patch) . Using the Legacy USRP shim so OP25 can access any USRP via UHD (one symlink) . How to do a side-by-side install of multiple OP25 versions <http://wiki.spench.net/wiki/Side-by-side_GNU_Radio_Modules> (one copy & script) . Adding DES-OFB decryption (a little more complex, but all the instructions are there) The side-by-side guide <http://wiki.spench.net/wiki/Side-by-side_GNU_Radio_Modules> not only applies to OP25, but any other GR module. Don't forget to install gr-baz <http://wiki.spench.net/wiki/gr-baz> to get the OP25 Decoder block <http://wiki.spench.net/wiki/gr-baz#op25> for GNU Radio Companion, a sample flowgraph that does the decoding from a variety of sources, the patches themselves and additional sample files. Please let me know if this is useful to people, what success you have, and if anyone is keen to move the DES-OFB code to the latest source (the patch is for version 219!). Kind regards, Balint

12 years, 8 months

OP25 working with UHD and GRC [2 Attachments]

by Balint

Hi folks, I had the pleasure of sitting with some major OP25 contributors (Max and Mike) at the GNU Radio conference today, and also managed to get OP25 working with a USRP N210 using UHD. You can see in the attached image that I'm using the OP25 block from gr-baz in GRC (the flowgraph sends the decoded audio to the speakers via the Audio Sink). The voice frames' data is being printed in the console, and four-level dibits are shown on the scope. The other tabs contain FFTs for the entire baseband and the selected channel, and make use of the new click-handler feature that triggers a callback containing the frequency you clicked on. You can therefore tune (really change the offset in the Freq Xlating Filter) to a signal you see appear on the FFT just by clicking on it (the same way you can with the Python apps, e.g. usrp_p25_rx/audio_p25_rx, however this is all from GRC). The IT++ 4.2 BCH problem still exists, so I've used the alternate implementation that Max also uses in the 'repeater' code to handle identification of the frame header. The GRC flowgraph obviously uses the UHD Source block to capture the baseband data, but the Python scripts (e.g. those mentioned above) also now work with UHD. The legacy USRP code is actually untouched as I've written a thin wrapper for UHD that makes any UHD-compatible device accessible through the legacy interface (i.e. brought 'from gnuradio import usrp' & usrp.source_c back). Not the best approach to force projects to move to UHD properly, but a temporary measure in the meantime ;) I'll post some code soon! Kind regard, Balint

12 years, 10 months

Court Rules that the Wiretap Act Does Not Prohibit Intercepting Unencrypted Wire

by ahenney

The Volokh Conspiracy September 7, 2012 Friday 4:02 AM EST District Court Rules that the Wiretap Act Does Not Prohibit Intercepting Unencrypted Wireless Communications LENGTH: 1078 words The decision is In re INNOVATIO IP VENTURES, LLC PATENT LITIGATION. MDL Docket No. 2303, Case No. 11 C 9308. (N.D.Ill. August 22, 2012), via Cybercrime Review. The opinion holds that anyone can monitor the unencrypted wi-fi communications of anyone else without implicating the Wiretap Act. I think the decision is wrong, and I wanted to explain why. The court holds that unsecured wireless communications are not covered by the Wiretap Act because of the exception found in 18 U.S.C. § 2511(g)(i). That exception states: (g) It shall not be unlawful under this chapter or chapter 121 of this title for any person- (i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public; The Court concludes that this exception covers unsecured wi-fi communications, so that it is entirely lawful to snoop in on someone else's private communications over an unsecured wireless network: Innovatio is intercepting Wi-Fi communications with a Riverbed AirPcap Nx packet capture adapter, which is available to the public for purchase for $698.00. See Riverbed Technology Product Catalog, http://www.cacetech.com/products/catalog/ (last visited Aug. 21, 2012). A more basic packet capture adapter is available for only $198.00. Id. The software necessary to analyze the data that the packet capture adapters collect is available for down load for free. See Wireshark Frequently Asked Questions, http://www.wireshark.org/faq.html#sec1 (last visited Aug. 21, 2012) ("Wireshark® is a network protocol analyzer. . . . It is freely available as open source. . . ."). With a packet capture adapter and the software, along with a basic laptop computer, any member of the general public within range of an unencrypted Wi-Fi network can begin intercepting communications sent on that network. Many Wi-Fi networks provided by commercial establishments (such as coffee shops and restaurants) are unencrypted, and open to such interference from anyone with the right equipment. In light of the ease of "sniffing" Wi-Fi networks, the court concludes that the communications sent on an unencrypted Wi-Fi network are readily available to the general public. I don't think that's right. Look closely at the text: "configured so that such electronic communication is readily accessible to the general public." In my view, that text focuses on the intent of the designer - the person who does the configuring of the network so that it works a particular way - to design the network so that the general public was supposed to be able to access them. Of course, you might not know the actual intent of the designer with 100% certainty. But with many technologies, it's obvious what counts as an expected use and what counts as an unexpected use. Cf. United States v. Morris, 928 F.2d 504 (2d. Cir. 1991) (creating an "intended function" test to distinguish authorized access to a network from unauthorized access to a network). No one suggests that unsecured wireless networks are set up with the goal that everyone on the network would be free to read the private communications of others. In my view, that ends the matter: the exception doesn't apply, and the interception of the contents of wireless communications is covered by the Wiretap Act. An analogous issue arose in Tapley v. Collins, 41 F.Supp.2d 1366 (S.D.Ga. 1999), which involved listening in on cordless telephone calls that were broadcast by cordless phones and (back then) not encrypted. The Tapley court held that this exception did not permit the interception of unencrypted cordless telephone calls: This subdivision . . . obviously contemplates the use of scanners to intercept (a) police, fire and emergency radio traffic; along with (b) any other electronic communications the designers and users of which-from decades of experience-have no reasonable grounds to expect anything but casual, even wide-scale interception by others (e.g., "CB radios"). In contrast, cordless telephones were never designed with that intent. True, early versions were prone to substantial electronic "leakage," leading courts and Congress alike to conclude that no one could reasonably claim a right to privacy when using them. See Spetalieri, 36 F.Supp.2d at 113; Peavy, 37 F.Supp.2d at 505-06. But no one has argued that cordless phone manufacturers intended, or were even lax about, any "incidental broadcast" feature. That's right, I think. The issue under 2511(2)(g)(i) is what the designers intended users to be able to do, not what someone can do contrary to the designer's intentions. Consider the implications of a contrary rule by focusing on the example of communications over a wire. You can buy a KeyKatcher keylogger for $55 from Amazon (with free super saver shipping!) and install it on a wire of Internet traffic. It's a lot cheaper than the wireless packet capture devices the Court is focused on in its decision. Under the Court's decision, the Wiretap Act categorically should not apply to that quintessential act of wiretapping whenever the wire was itself available to the public simply because anyone can buy the $55 device and install it. In my view, that can't be the test: The issue is not whether a member of the public could engage in the wiretapping as a matter of cost and practicality, but rather whether the technology is set up consistently with a design that reflects an intent that members of the public would be able to monitor those communications. Two final points. First, my sense is that the court did not need to reach this legal question in the first place. The case is a patent dispute rather than a wiretapping case, and there is no suppression remedy because the communications are electronic communications (and the statutory suppression remedy only applies to wire and oral communications). Second, a much more difficult question is the one presented in In re Google Inc. Street View Electronic Communications Litigation, 794 F. Supp. 2d 1067, 1070 (N.D. Cal. 2011): Does the "radio communication" exception in 18 U.S.C. 2511(2)(g)(ii) exempt wireless communications from the Wiretap Act? That issue is now on appeal before the Ninth Circuit in the Google Street View case, and I think Judge Ware was correct to conclude that the exception does not apply. But whatever you think is the right answer to that question, I think it's the more difficult issue.

12 years, 10 months

OP25 + UHD Bounty

by Matt Mills

Also, If anyone has the inclination to improve OP25, I'll offer a 250$ bounty for a version of OP25 checked into subversion that is compatible with the latest version of gnuradio and UHD (claimable for the next 30 days). Thanks, Matt.

12 years, 10 months

repeater.vocoder doesnt run to completion [1 Attachment]

by Matt Mills

Hi All, I'm trying to have repeater.vocoder() run as a small app to read from a file sink and write to a wav sink... If I replace the vocoder with a char_to_short() block it works as expected, however with the vocoder in place it never completes... Also, it looks as though even though it has run out of samples the vocoder thread continuously runs at 100% cpu. Anyone have any ideas? (associated python is attached. thanks, Matt.

12 years, 10 months

Wireshark expected output

by Matt Mills

All, What should the expected output of P25 data in wireshark be while running uhd_c4fm_rx_nogui.py? I have it running, hooked up a UDP sink and can see distinct dibits flowing into the slicer/decoder, and I receive UDP to my patched wireshark however all I ever get are 141 length Header Data Units. I also cant seem to get any audio out of the signal using OP25 (however if I pipe the same signal through DSD it produces audio). FYI, I'm also using the latest gnuradio with UHD. Thanks, Matt.

12 years, 10 months

"NameError: global name 'msgq' is not defined" in audio_p25_rx.py

by rajani_38

I'm new to GNURadio and OP25, and am facing the above error when trying to run audio_p25_rx.py. How I installed: On Ubuntu 10.04, I installed GNURadio 3.6, ensured that the prerequisites on the BeginnersBuild page were installed, then installed and built OP25, the imbe_vocoder, and then the repeater as instructed on the BuildInstructions page. Also installed gr-fsk4. I had put in the following symlink to get over some gruel problems while trying to build gr-fsk4: $ln -s /usr/local/include/gruel/swig/gruel_common.i /usr/local/include/gnuradio/swig/gruel_common.i Now I am stuck with the msgq error. I'd like to know if the build is expected to work with gnuradio 3.6. and whether audio_p25_rx.py can be executed without any input, just to make sure the OP25 build works. (I understand that in gnuradio 3.6 the usrpm folder has been deprecated and that seems to be giving rise to other Not Found errors for other scripts...) Any help will be greatly appreciated. Don't mind going to Gnuradio 3.2.2 if that will make life simpler. Thanks - Ram

12 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

op25-dev