Cheers Max,
I don't really want to re-write everything but I want to fix the bit rot
and get it all working again. The refactoring will be painful and
extracting IT++ less painful than it might have been since we have much of
the code now (the BCH decoder you reverse engineered from the VB is pretty
solid so that was about the biggest pain).
I shall remove the advice relating to Frank's page from the wiki since its
now all done and am keen to move forward. Shall keep you informed on
progress as well as make postings to the list.
ATB
Steve
On 8 March 2013 11:05, ikj1234i <ikj1234i(a)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(a)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