I'm not much of a coder but I can assist in taking captures of a p25 phase II system. There is a site near me. I have a gnuradio setup using rtlsdr dongles. Let me know how and what you would like me to capture. There are audio channels and a Motorola trunking control channel on this site. I've done some basic decoding of the control channel with some windows apps already but haven't tried anything with gnuradio yet. Keith ikj1234i <ikj1234i@yahoo.com> wrote:
Hello Stevie
Good to hear from you - this sounds like a good idea, for sure.
It's always tempting to take such an opportunity as this to rewrite the entire system from scratch :)
I think another piece to add to the puzzle that perhaps might be broken out as a separate item of concern would be UHD support.
Mostly I think that would affect our py code but not so much our C++ blocks.
Also when you added the fsk4 demod block to the op25 core it took me longer than it should but as of a few days ago I checked in several remaining stragglers to svn, all of our py code is now upgraded to use the in-tree version. I think there may have been one or two _very_ old ones that still use Franks' p25 and RD-LAP protocol handlers, but those apps date back to the days before our project had its own protocol processing...
Also for GR 3.6 in addition to cmake there is a new directory structure that apps are to conform to.
Looking further out there is some very exciting new stuff coming in GR for handling packet-oriented streams with timed transmission features. This looks like it should be a good fit for our repeater work, but will require effort to make use of the new capability.
Finally, we're interested in P25 phase II, and are looking for RF captures of various phase II scenarios.
Best
Max
--- In op25-dev@yahoogroups.com, Steve Glass <stevie.glass@...> wrote:
Hi Everyone
I think its time to organize a drive to move the code to the latest version of GNURadio. The OP25 codebase is suffering badly from bit rot and that needs fixing. GNURadio has evolved and developed many new features we've not properly kept up with. Fixing the codebase will mean that we can get people working with much less hassle than at present.
I've created a wiki page<http://op25.osmocom.org/wiki/wiki/ReengineeringPage>to act as the starting point. I shall start opening tickets this week and start mapping out the direction of the exercise. For now I want to focus the effort on the core OP25 components and we can use GRC as our top-level test harness. Take a look and take part in the discussion.
Atb
Steve
------------------------------------
Yahoo! Groups Links
Hi Keith This would be very helpful! We don't currently have a lot of hard data on how "phase 2" systems work. AFAIK the top thing on the wish list would be a voice channel capture (when the channel is transmitting in phase 2 / TDMA mode). Supposedly only the GRE PSR-800 scanner can receive this mode. The capture should be in complex format - the sample rate should probably be at least 96,000, higher rates no problem. As long your hardware is supported by GR you should be able to use the usrp_rx_cfile or uhd_rx_cfile app (or equiv). to do the signal capture... Mostly, the only other thing when capturing is to make sure the RF front end gain is set optimally - there are GR apps such as uhd_fft and usrp_fft for scoping signals, helpful to get a bearing on things... Best Max --- In op25-dev@yahoogroups.com, Keith S <ktsangel69@...> wrote:
I'm not much of a coder but I can assist in taking captures of a p25 phase II system. There is a site near me.
I have a gnuradio setup using rtlsdr dongles. Let me know how and what you would like me to capture. There are audio channels and a Motorola trunking control channel on this site. I've done some basic decoding of the control channel with some windows apps already but haven't tried anything with gnuradio yet.
Keith
ikj1234i <ikj1234i@...> wrote:
Hello Stevie
Good to hear from you - this sounds like a good idea, for sure.
It's always tempting to take such an opportunity as this to rewrite the entire system from scratch :)
I think another piece to add to the puzzle that perhaps might be broken out as a separate item of concern would be UHD support.
Mostly I think that would affect our py code but not so much our C++ blocks.
Also when you added the fsk4 demod block to the op25 core it took me longer than it should but as of a few days ago I checked in several remaining stragglers to svn, all of our py code is now upgraded to use the in-tree version. I think there may have been one or two _very_ old ones that still use Franks' p25 and RD-LAP protocol handlers, but those apps date back to the days before our project had its own protocol processing...
Also for GR 3.6 in addition to cmake there is a new directory structure that apps are to conform to.
Looking further out there is some very exciting new stuff coming in GR for handling packet-oriented streams with timed transmission features. This looks like it should be a good fit for our repeater work, but will require effort to make use of the new capability.
Finally, we're interested in P25 phase II, and are looking for RF captures of various phase II scenarios.
Best
Max
--- In op25-dev@yahoogroups.com, Steve Glass <stevie.glass@> wrote:
Hi Everyone
I think its time to organize a drive to move the code to the latest version of GNURadio. The OP25 codebase is suffering badly from bit rot and that needs fixing. GNURadio has evolved and developed many new features we've not properly kept up with. Fixing the codebase will mean that we can get people working with much less hassle than at present.
I've created a wiki page<http://op25.osmocom.org/wiki/wiki/ReengineeringPage>to act as the starting point. I shall start opening tickets this week and start mapping out the direction of the exercise. For now I want to focus the effort on the core OP25 components and we can use GRC as our top-level test harness. Take a look and take part in the discussion.
Atb
Steve
------------------------------------
Yahoo! Groups Links
participants (2)
-
ikj1234i -
Keith S