[op25-dev] Re: OP25 GRC - Almost but not quite working

Steve Glass stevie.glass at gmail.com
Thu May 3 01:31:36 UTC 2012


The 64 bit NID consists of the NAC+DUID (the low order 16 bits) and the
error correction bits (the high order 48 bits). Its possible the NAC is
zero for a data frame since it has its own addressing information within
the frame itself. That would leave you with just the DUID and the
appropriate BCH code for that value. Its possible (but not very likely)
that this would mean the high order bits would be mostly zeroes.

On 3 May 2012 01:02, rrgsti <bobrich at gmail.com> wrote:

> **
>
>
> Hi folks,
>
> I'm still tinkering with this but am running into a bit of a wall with
> regards to P25 data.
>
> These two lines are dumped to stderr using a call to the dump_cw function
> that I added to the code. I'm only dumping the first 30 bytes for brevity:
>
>
> 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff ff
> ff fe fc 25 ed
>
> 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 5b 10 ba 16 de 2e 82 69 36 3d 98
> 1f 9b f8 8e c6
>
> Based on what I've been able to determine so far, the first 48 bits are
> frame sync, and they should be fixed at 0x5575f5ff77ff, which is what we
> see above.
>
> The next 64 bits are supposed to be NID, which includes the DUID.
>
> I could be wrong, but I believe the 02 (which alternates between 02 and 03
> in the lines below) at the 9th byte, is the status bit-pair that is
> interleaved every 70 bits (9 bytes * 8 bits - 72 bits into the frame). Once
> removed, that shifts the remaining bits to the left 2, which still leaves
> the NID essentially filled with zeroes except for the last two bits.
> Immediately after the NID, however, the bits start flying again.
>
> Does this seem normal? I can't really find any annotated hex dumps of a
> P25 frame to try to line things up, but it seems that the NID should be
> populated with something other than zeroes. If you bit shift the 15th bit 2
> to the left, we'll get a parity bit set every now and then (again, unless
> I'm messing something up), but nothing else.
>
> I'm completely open to the fact that this could just be a bad signal, but
> I can get very clear decodes of the voice if I force the type to LDU1 or
> LDU2, and I have never seen anything but all zeroes here (across many
> minutes of decoded voice data)
>
> Any thoughts?
>
>
> --- In op25-dev at yahoogroups.com, "rrgsti" <bobrich at ...> wrote:
> >
> >
> > Hi Matt!
> >
> > Thanks for the info, it sounds like that is a very possible option. Is
> there a way to see the state of the fsk4 demodulator? I did try running
> with the updated OP25.py that Balint put out on Saturday (uses _op25.fsk4
> instead of the Radio Raush module, and it doesn't seem to behave any
> differently.
> >
> > I did find dump_cw in op25_imbe_frame.h and used it to dump frames right
> before their duid is read. I don't know if these will be meaningful, but
> I'll paste them in here. Moments of silence have the clusters of 0xff's on
> the right, while portions where there is audio has more random numbers.
> >
> > I did note that about 9 bytes into this dump there is a byte that keeps
> flipping between 2 and 3. Is it possible this is where the DUID is (shifted
> a bit or two). Each row starting with 0x55 0x75 is a new frame dumped, I
> only dump the first 32 bytes or so of each one.
> >
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 03 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 5b 10 ba 16 de 2e 82 69 36 3d
> 98 1f 9b f8 8e c6
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 74 35 56 de 42 7b ac 05 90 af
> 5a 0e 12 84 81 6b
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 52 0b 37 d6 c5 a6 11 79 56 f5
> 9b 1a 1e 22 8a 35
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 7e 2d f0 82 d0 4f f8 4d a2 61
> 34 94 52 a4 f8 ec
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 4e 46 60 ce 5d a8 8b 27 7f 62
> 78 ab c2 52 ee 0f
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 00 00 00 02 55 75 f5 ff 77 ff
> 2d 6f ae e2 78 2e
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 03 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff ff fc 25 ed
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 45 5e a4 8b 59 7f 74 31 29 f3
> ed d2 36 6c fa 30
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 46 33 55 22 52 69 8e 51 5c 01
> 0b ae 5a eb 36 8f
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 5b 10 ba 16 de 2e 82 69 36 3d
> 98 1f 9a f8 8e c6
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 00 00 00 02 55 75 f5 ff 77 ff
> 2d 6f ae e2 78 2e
> > 55 75 f5 ff 77 ff 00 00 02 00 00 00 00 00 01 26 2d 02 0f 68 4f ff ff ff
> ff ff fe fc 25 ed
> >
> >
> >
> > --- In op25-dev at yahoogroups.com, Matt Robert <matt.robert80@> wrote:
> > >
> > > Hi Bob,
> > >
> > > Its more than likely a result of a bad signal. The FSK4 demod tends to
> output zeros when it loses sync which is why the DUID is erroneously coming
> up as 0x00.
> > >
> > > LDU1/2 are the two types of voice frames. LDU1 has signalling data
> embedded and LDU2 has encryption sync data embedded.
> > >
> > > The kludge diff posted below will work - but only for valid frames
> with a corrupt DUID value.
> > >
> > >
> > > I'm sure the root cause is the FSK4 demod isn't locking properly and
> causing a bad DUID value to be outputted. I have seen similar behaviour in
> other areas of OP25 - for example I was looking at the IV/MI value (72
> bits) on a local P25 system here. Whenever the demodulator ran out of
> talent, it would output steams of constant zeros.
> > >
> > > Ohio MARCS is a Type 2 Smartzone Omnilink System with CAI compatible
> ASTRO voice channels - so its essentially P25 compatible. The P25 CAI spec
> was based on the ASTRO CAI from the same era, so its essentially the same
> thing.
> > >
> > > Is the system running any form of simulcasting?Â
> > >
> > > Cheers,
> > > Matt
> > >
> > > ________________________________
> > > From: rrgsti <bobrich@>
> > > To: op25-dev at yahoogroups.com
> > > Sent: Thursday, 26 April 2012 10:59 PM
> > > Subject: [op25-dev] Re: OP25 GRC - Almost but not quite working
> > >
> > >
> > > Â
> > > Quick update from my end.
> > >
> > > It looks like every frame coming out of the fsk4 demodulator (I'm
> assuming, still a n00b here) is marked with a 'duid' of 0x0. Consequently,
> when data_unit.cc initializes a new data_unit from the frame, it is always
> creating it as an HDU (P25 header) type. This then prevents the IMBE
> decoder from being executed b/c it's not a voice data unit type (LDU1/LDU2
> (no idea what these mean)).
> > >
> > > I figured maybe it has something to do with our system (Ohio MARCS)
> not being full P25 compliant and not including metadata of any sort, so I
> just made the following change to data_unit.cc and re-ran it:
> > >
> > > --- op25-orig/blocks/src/lib/data_unit.cc 2012-04-24
> 10:31:29.139694592 -0400
> > > +++ op25/blocks/src/lib/data_unit.cc 2012-04-26 08:12:35.183962129
> -0400
> > > @@ -39,7 +39,8 @@
> > > uint8_t duid = extract(frame_body, 60, 64);
> > > switch(duid) {
> > > case 0x0:
> > > - d = data_unit_sptr(new hdu(frame_body));
> > > + //d = data_unit_sptr(new hdu(frame_body));
> > > + d = data_unit_sptr(new ldu1(frame_body));
> > > break;
> > > case 0x3:
> > > d = data_unit_sptr(new tdu(frame_body, false));
> > >
> > > This seemed to sort of work as I now get rather garbled, but
> intelligible, audio from the decoder.
> > >
> > > I've uploaded the baseband capture (1Msps) and resulting audio .wav
> file that I get at the following URLS:
> > >
> > > http://s3.amazonaws.com/public-xrp/p25.iq.bz2
> > > http://s3.amazonaws.com/public-xrp/p25.wav
> > >
> > > Not sure if this is of any use, but it is encouraging to hear voices
> at least. :)
> > >
> > > Thanks!
> > >
> > > Bob
> > >
> > > --- In op25-dev at yahoogroups.com, Andy Knitt <andyknitt@> wrote:
> > > >
> > > > It looks like imbe_decoder_factory.cc in OP25 defaults to
> > > > 'software_imbe_decoder'. I manually changed the IMBE environment
> variable
> > > > to "soft" and confirmed it with printenv, but I'm still getting a
> flat line
> > > > at the output of the OP25 block. Any other ideas?
> > > >
> > > > Thanks,
> > > >
> > > > Andy
> > > >
> > > > On Mon, Apr 23, 2012 at 11:47 PM, Balint <balint256@> wrote:
> > > >
> > > > > **
> > > > >
> > > > >
> > > > > I *still* haven't checked out the latest code, but in my old code
> the
> > > > > default voice frame output was (null?).****
> > > > >
> > > > > There are options for file output, null, external (hardware)
> decoder and
> > > > > internal decoder. You used to be able to spec this on the command
> line as
> > > > > an environment variable:****
> > > > >
> > > > > export IMBE=soft****
> > > > >
> > > > > I changed my default to be the internal decoder (see
> > > > > `imbe_decoder_factory.cc').****
> > > > >
> > > > > ** **
> > > > >
> > > > > *From:* op25-dev at yahoogroups.com [mailto:op25-dev at yahoogroups.com]
> *On
> > > > > Behalf Of *Andy Knitt
> > > > > *Sent:* Tuesday, 24 April 2012 12:45 PM
> > > > > *To:* op25-dev at yahoogroups.com
> > > > > *Subject:* [op25-dev] OP25 GRC - Almost but not quite working****
> > > > >
> > > > > ** **
> > > > >
> > > > > ****
> > > > >
> > > > > I have the OP25 GRC demo that Balint provided up and running.
> > > > > Everything seems to working except I'm not getting any audio out of
> > > > > the OP25 block. I'm getting the "four line" output from the dibit
> > > > > output port when there is traffic on the channel, and the autotune
> > > > > output is outputting data. However, no audio. I put a scope on the
> > > > > audio output and it's a flat line at zero, even when the dibit
> output
> > > > > is "four lines". Any tips on how to further troubleshoot?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Andy****
> > > > >
> > > > > ****
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/op25-dev/attachments/20120503/9f7548a6/attachment.html>


More information about the op25-dev mailing list