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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

Matt, If the FSK4 demod wasn't working properly, would we still be getting "good looking" values out of the dibits output of the OP25 block? We're getting the "four straight lines" at -3,-1,+1,+3 but still not audio out. Thanks, Andy On Thu, Apr 26, 2012 at 10:06 AM, Matt Robert <matt.robert80@yahoo.com>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@gmail.com> *To:* op25-dev@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

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@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@yahoogroups.com, "rrgsti" <bobrich@...> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF. I think a capture file would be ideal - this is a curly one for sure! Bob - which system is this coming off? Cheers, Matt ________________________________ From: Steve Glass <stevie.glass@gmail.com> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working   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@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@yahoogroups.com, "rrgsti" <bobrich@...> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

Hi folks, Thanks for the input. For some reason I didn't see p25craft.py and I think that will help me create reference packets to sort out what should and should not be. I'm not able to do any captures until this evening, but I had previously uploaded this, which I *believe* was the source used for the few lines in the last email. This was from gnuradio file sink recording from the RTL at 1Msps (the .wav file is the decoded audio from the same session using my hacked up data_unit.cc): http://s3.amazonaws.com/public-xrp/p25.iq.bz2 http://s3.amazonaws.com/public-xrp/p25.wav The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner. I'd be happy to capture more if it's of any use or upload the files to another location. Thanks --- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@...> wrote:

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@...> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@...> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On Behalf Of *Andy Knitt *Sent:* Tuesday, 24 April 2012 12:45 PM *To:* op25-dev@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****

****

Also, for what it's worth, I was able to get the P25 CAI dissector working in wireshark and it also identifies every frame as a HDU with a NAC (including DUID) of all zeroes. The check bit at the end of the NAC alternates between 0 and 1, I can't tell if that's the 113th bit that I'm looking at. I just overhead someone say 'you need to encrypt your radio' in the channel I'm listening to. Is it possible that it's encrypted with an empty key? Would that cause this to happen? --- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@...> wrote:

Success! Sort of.

For some reason, this patch makes it work:

Index: data_unit.cc =================================================================== --- data_unit.cc (revision 296) +++ data_unit.cc (working copy) @@ -36,7 +36,7 @@ data_unit::make_data_unit(const_bit_queue& frame_body) { data_unit_sptr d; - uint8_t duid = extract(frame_body, 60, 64); + uint8_t duid = extract(frame_body, 113, 114); switch(duid) { case 0x0: d = data_unit_sptr(new hdu(frame_body)); @@ -44,6 +44,7 @@ case 0x3: d = data_unit_sptr(new tdu(frame_body, false)); break; + case 0x1: case 0x5: d = data_unit_sptr(new ldu1(frame_body)); break;

Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc.

I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it.

Here's a tar file with the IQ data, audio output and python file compiled from the flowgraph.

http://s3.amazonaws.com/public-xrp/p25.tar.bz2

Here's the .wav file by itself

http://s3.amazonaws.com/public-xrp/p25-fixed.wav

Here is another set of samples of IQ file and output .wav

Thanks!

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Hi folks,

Thanks for the input. For some reason I didn't see p25craft.py and I think that will help me create reference packets to sort out what should and should not be.

I'm not able to do any captures until this evening, but I had previously uploaded this, which I *believe* was the source used for the few lines in the last email. This was from gnuradio file sink recording from the RTL at 1Msps (the .wav file is the decoded audio from the same session using my hacked up data_unit.cc):

http://s3.amazonaws.com/public-xrp/p25.iq.bz2 http://s3.amazonaws.com/public-xrp/p25.wav

The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner.

I'd be happy to capture more if it's of any use or upload the files to another location.

Thanks

--- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@> wrote:

...

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On > > Behalf Of *Andy Knitt > > *Sent:* Tuesday, 24 April 2012 12:45 PM > > *To:* op25-dev@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**** > > > > **** > > > > > > >

Hi Steve, This turned out to be an issue with the latest itpp library. Try uninstalling itpp 4.2 and installing 4.07 by package or source, then rebuild op25 (without changes). Good luck! --- In op25-dev@yahoogroups.com, "homernighthawk" <ctx50026@...> wrote:

Hi,

I have the same problem with op25.grc. 4 lines on the dibits tab and no audio. I tried the changes you mentioned and they make it work for me also.

Steve

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Success! Sort of.

For some reason, this patch makes it work:

Index: data_unit.cc =================================================================== --- data_unit.cc (revision 296) +++ data_unit.cc (working copy) @@ -36,7 +36,7 @@ data_unit::make_data_unit(const_bit_queue& frame_body) { data_unit_sptr d; - uint8_t duid = extract(frame_body, 60, 64); + uint8_t duid = extract(frame_body, 113, 114); switch(duid) { case 0x0: d = data_unit_sptr(new hdu(frame_body)); @@ -44,6 +44,7 @@ case 0x3: d = data_unit_sptr(new tdu(frame_body, false)); break; + case 0x1: case 0x5: d = data_unit_sptr(new ldu1(frame_body)); break;

Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc.

I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it.

Here's a tar file with the IQ data, audio output and python file compiled from the flowgraph.

http://s3.amazonaws.com/public-xrp/p25.tar.bz2

Here's the .wav file by itself

http://s3.amazonaws.com/public-xrp/p25-fixed.wav

Here is another set of samples of IQ file and output .wav

Thanks!

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Hi folks,

Thanks for the input. For some reason I didn't see p25craft.py and I think that will help me create reference packets to sort out what should and should not be.

I'm not able to do any captures until this evening, but I had previously uploaded this, which I *believe* was the source used for the few lines in the last email. This was from gnuradio file sink recording from the RTL at 1Msps (the .wav file is the decoded audio from the same session using my hacked up data_unit.cc):

http://s3.amazonaws.com/public-xrp/p25.iq.bz2 http://s3.amazonaws.com/public-xrp/p25.wav

The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner.

I'd be happy to capture more if it's of any use or upload the files to another location.

Thanks

--- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@> wrote:

...

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On > > > Behalf Of *Andy Knitt > > > *Sent:* Tuesday, 24 April 2012 12:45 PM > > > *To:* op25-dev@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**** > > > > > > **** > > > > > > > > > > > >

I found the correct fix for the phase issue in the fine transition code. There was pi^2 in a couple places where it should have been 2*pi. Here's a patch that includes all my fixes so far: Index: blocks/src/lib/software_imbe_decoder.cc =================================================================== --- blocks/src/lib/software_imbe_decoder.cc (revision 301) +++ blocks/src/lib/software_imbe_decoder.cc (working copy) @@ -757,6 +757,7 @@ { int i,j; //initialize + OldL = 0; Old = 1; New = 0; psi1 = 0.0; for(i=0; i < 58; i++) { @@ -931,7 +932,7 @@ // if(abs((int)sample) > 32767) { // sample = 32767 * (sample < 0) ? -1 : 1; // * sgn(sample) // } - sample /= 16384.0; /* 32768.0 - but audio amplitude is not full range of int16 */ + sample /= 65536.0; samples->push_back(sample); } } @@ -1394,10 +1395,8 @@ if(vee[ell][ New]) { if ( vee[ell][ Old]) { if(ell < 8 && fabsf(w0 - Oldw0) < .1 * w0) { // (fine transition) - const double PI_SQUARED = M_PI * M_PI; - const double INV_PI_SQUARED = 1.0 / PI_SQUARED; Dpl = phi[ell][ New] - phi[ell][ Old] -(Oldw0 + w0) * ell * 80; - Dwl = .00625 * (Dpl - PI_SQUARED * floorf((Dpl + M_PI) * INV_PI_SQUARED)); + Dwl = .00625 * (Dpl - 2 * M_PI * floorf((Dpl + M_PI) / (2 * M_PI))); THa = (Oldw0 * (float)ell + Dwl); THb = (w0 - Oldw0) * ell * .003125; Mb = .00625 *(MNew - MOld); --- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@...> wrote:

I admire your tenacity Clayton!

The change to software_imbe_decoder does improve audio quality at this end as well. I added a small amount of logging and noted that the code is going back and forth between the fine and coarse transition operations, so it doesn't seem like something is just 'pegged' at a wrong value. This is all magic to me, however, so I have no intuition about what is or is not correct.

This is running on 11.10 with itpp 4.07 built from source, latest copies of op25 and fairly recent gnuradio and gr-baz.

Thanks!

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I've made a bit of progress. It appears that the phase calculation in software_imbe_decoder::synth_voiced is not correct in the "fine transition" case, resulting in abrupt phase shifts between the 20ms frames. I'm not sure yet how to correct it, but by commenting out the "fine transition" case completely so that the "coarse transition" case always runs instead, I've eliminated most of the warble.

Another problem I noticed is that the audio output is sometimes greater than 1.0, resulting in clipping if connected directly to an audio sink. I corrected this by changing the "sample /= 16384.0;" line at the end of software_imbe_decoder::decode_audio back to "sample /= 32768.0;".

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I'm getting the same issue with the sound: speech is intelligible but with a strong warble that makes it sound like talking through a fan. I had a quick look at the waveform and spectrum of the output but didn't spot any obvious problems there. Not knowing IMBE, I couldn't get far with the code. Any ideas?

- Clayton

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc.

I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it.

It's fixed! I've posted a patch with all my fixes here: http://pastebin.com/8Tw0DNyy Audio output is sounding very good now. - Clayton --- In op25-dev@yahoogroups.com, "argilo314" <argilo@...> wrote:

I believe I found the source of the remaining warble. The unvoiced synthesizer seems to be filtering the same noise in each 20ms frame, rather than starting with fresh white noise each time, resulting in a 50 Hz hum. I'll try fixing it to match the spec over the few days.

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I found the correct fix for the phase issue in the fine transition code. There was pi^2 in a couple places where it should have been 2*pi. Here's a patch that includes all my fixes so far:

Index: blocks/src/lib/software_imbe_decoder.cc =================================================================== --- blocks/src/lib/software_imbe_decoder.cc (revision 301) +++ blocks/src/lib/software_imbe_decoder.cc (working copy) @@ -757,6 +757,7 @@ { int i,j; //initialize + OldL = 0; Old = 1; New = 0; psi1 = 0.0; for(i=0; i < 58; i++) { @@ -931,7 +932,7 @@ // if(abs((int)sample) > 32767) { // sample = 32767 * (sample < 0) ? -1 : 1; // * sgn(sample) // } - sample /= 16384.0; /* 32768.0 - but audio amplitude is not full range of int16 */ + sample /= 65536.0; samples->push_back(sample); } } @@ -1394,10 +1395,8 @@ if(vee[ell][ New]) { if ( vee[ell][ Old]) { if(ell < 8 && fabsf(w0 - Oldw0) < .1 * w0) { // (fine transition) - const double PI_SQUARED = M_PI * M_PI; - const double INV_PI_SQUARED = 1.0 / PI_SQUARED; Dpl = phi[ell][ New] - phi[ell][ Old] -(Oldw0 + w0) * ell * 80; - Dwl = .00625 * (Dpl - PI_SQUARED * floorf((Dpl + M_PI) * INV_PI_SQUARED)); + Dwl = .00625 * (Dpl - 2 * M_PI * floorf((Dpl + M_PI) / (2 * M_PI))); THa = (Oldw0 * (float)ell + Dwl); THb = (w0 - Oldw0) * ell * .003125; Mb = .00625 *(MNew - MOld);

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

I admire your tenacity Clayton!

The change to software_imbe_decoder does improve audio quality at this end as well. I added a small amount of logging and noted that the code is going back and forth between the fine and coarse transition operations, so it doesn't seem like something is just 'pegged' at a wrong value. This is all magic to me, however, so I have no intuition about what is or is not correct.

This is running on 11.10 with itpp 4.07 built from source, latest copies of op25 and fairly recent gnuradio and gr-baz.

Thanks!

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I've made a bit of progress. It appears that the phase calculation in software_imbe_decoder::synth_voiced is not correct in the "fine transition" case, resulting in abrupt phase shifts between the 20ms frames. I'm not sure yet how to correct it, but by commenting out the "fine transition" case completely so that the "coarse transition" case always runs instead, I've eliminated most of the warble.

Another problem I noticed is that the audio output is sometimes greater than 1.0, resulting in clipping if connected directly to an audio sink. I corrected this by changing the "sample /= 16384.0;" line at the end of software_imbe_decoder::decode_audio back to "sample /= 32768.0;".

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I'm getting the same issue with the sound: speech is intelligible but with a strong warble that makes it sound like talking through a fan. I had a quick look at the waveform and spectrum of the output but didn't spot any obvious problems there. Not knowing IMBE, I couldn't get far with the code. Any ideas?

- Clayton

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc.

I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it.

Strange, something got messed up when I posted the patch to Pastebin. Try grabbing the patch from here instead: http://argilo.dyndns.org/files/imbe-fixes-new2.patch - Clayton --- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@...> wrote:

Hi Clayton,

For some reason the patch against the .cc file won't apply at all...every hunk fails, even though they appear to line up more or less. The .h patch applies 'with fuzzing'. Any idea why? I pulled a fresh copy of revision 301 from svn to try it with. I'm just running 'patch -p0 < op25.diff'

I tried doing it by hand but the result sounded like glass shattering behind the voices...kind of interesting really.

Thanks again! I feel like I'm 10 years away from understanding what half of that code does...I'm glad you have it figured out. :)

Bob

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

It's fixed! I've posted a patch with all my fixes here:

http://pastebin.com/8Tw0DNyy

Audio output is sounding very good now.

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I believe I found the source of the remaining warble. The unvoiced synthesizer seems to be filtering the same noise in each 20ms frame, rather than starting with fresh white noise each time, resulting in a 50 Hz hum. I'll try fixing it to match the spec over the few days.

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I found the correct fix for the phase issue in the fine transition code. There was pi^2 in a couple places where it should have been 2*pi. Here's a patch that includes all my fixes so far:

Index: blocks/src/lib/software_imbe_decoder.cc =================================================================== --- blocks/src/lib/software_imbe_decoder.cc (revision 301) +++ blocks/src/lib/software_imbe_decoder.cc (working copy) @@ -757,6 +757,7 @@ { int i,j; //initialize + OldL = 0; Old = 1; New = 0; psi1 = 0.0; for(i=0; i < 58; i++) { @@ -931,7 +932,7 @@ // if(abs((int)sample) > 32767) { // sample = 32767 * (sample < 0) ? -1 : 1; // * sgn(sample) // } - sample /= 16384.0; /* 32768.0 - but audio amplitude is not full range of int16 */ + sample /= 65536.0; samples->push_back(sample); } } @@ -1394,10 +1395,8 @@ if(vee[ell][ New]) { if ( vee[ell][ Old]) { if(ell < 8 && fabsf(w0 - Oldw0) < .1 * w0) { // (fine transition) - const double PI_SQUARED = M_PI * M_PI; - const double INV_PI_SQUARED = 1.0 / PI_SQUARED; Dpl = phi[ell][ New] - phi[ell][ Old] -(Oldw0 + w0) * ell * 80; - Dwl = .00625 * (Dpl - PI_SQUARED * floorf((Dpl + M_PI) * INV_PI_SQUARED)); + Dwl = .00625 * (Dpl - 2 * M_PI * floorf((Dpl + M_PI) / (2 * M_PI))); THa = (Oldw0 * (float)ell + Dwl); THb = (w0 - Oldw0) * ell * .003125; Mb = .00625 *(MNew - MOld);

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

I admire your tenacity Clayton!

The change to software_imbe_decoder does improve audio quality at this end as well. I added a small amount of logging and noted that the code is going back and forth between the fine and coarse transition operations, so it doesn't seem like something is just 'pegged' at a wrong value. This is all magic to me, however, so I have no intuition about what is or is not correct.

This is running on 11.10 with itpp 4.07 built from source, latest copies of op25 and fairly recent gnuradio and gr-baz.

Thanks!

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I've made a bit of progress. It appears that the phase calculation in software_imbe_decoder::synth_voiced is not correct in the "fine transition" case, resulting in abrupt phase shifts between the 20ms frames. I'm not sure yet how to correct it, but by commenting out the "fine transition" case completely so that the "coarse transition" case always runs instead, I've eliminated most of the warble.

Another problem I noticed is that the audio output is sometimes greater than 1.0, resulting in clipping if connected directly to an audio sink. I corrected this by changing the "sample /= 16384.0;" line at the end of software_imbe_decoder::decode_audio back to "sample /= 32768.0;".

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote: > > I'm getting the same issue with the sound: speech is intelligible but with a strong warble that makes it sound like talking through a fan. I had a quick look at the waveform and spectrum of the output but didn't spot any obvious problems there. Not knowing IMBE, I couldn't get far with the code. Any ideas? > > - Clayton > > --- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote: > > > > Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc. > > > > I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it. >

Ahhhhh...who would have thought a deputy calling in tags could be like music to my ears. lol Sounds fantastic. Great job Clayton and thanks to everyone that has poured so much time and effort into this project and helping neophytes like myself along the way! Bob --- In op25-dev@yahoogroups.com, "argilo314" <argilo@...> wrote:

Strange, something got messed up when I posted the patch to Pastebin. Try grabbing the patch from here instead: http://argilo.dyndns.org/files/imbe-fixes-new2.patch

- Clayton

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Hi Clayton,

For some reason the patch against the .cc file won't apply at all...every hunk fails, even though they appear to line up more or less. The .h patch applies 'with fuzzing'. Any idea why? I pulled a fresh copy of revision 301 from svn to try it with. I'm just running 'patch -p0 < op25.diff'

I tried doing it by hand but the result sounded like glass shattering behind the voices...kind of interesting really.

Thanks again! I feel like I'm 10 years away from understanding what half of that code does...I'm glad you have it figured out. :)

Bob

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

It's fixed! I've posted a patch with all my fixes here:

http://pastebin.com/8Tw0DNyy

Audio output is sounding very good now.

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I believe I found the source of the remaining warble. The unvoiced synthesizer seems to be filtering the same noise in each 20ms frame, rather than starting with fresh white noise each time, resulting in a 50 Hz hum. I'll try fixing it to match the spec over the few days.

- Clayton

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote:

...

I found the correct fix for the phase issue in the fine transition code. There was pi^2 in a couple places where it should have been 2*pi. Here's a patch that includes all my fixes so far:

Index: blocks/src/lib/software_imbe_decoder.cc =================================================================== --- blocks/src/lib/software_imbe_decoder.cc (revision 301) +++ blocks/src/lib/software_imbe_decoder.cc (working copy) @@ -757,6 +757,7 @@ { int i,j; //initialize + OldL = 0; Old = 1; New = 0; psi1 = 0.0; for(i=0; i < 58; i++) { @@ -931,7 +932,7 @@ // if(abs((int)sample) > 32767) { // sample = 32767 * (sample < 0) ? -1 : 1; // * sgn(sample) // } - sample /= 16384.0; /* 32768.0 - but audio amplitude is not full range of int16 */ + sample /= 65536.0; samples->push_back(sample); } } @@ -1394,10 +1395,8 @@ if(vee[ell][ New]) { if ( vee[ell][ Old]) { if(ell < 8 && fabsf(w0 - Oldw0) < .1 * w0) { // (fine transition) - const double PI_SQUARED = M_PI * M_PI; - const double INV_PI_SQUARED = 1.0 / PI_SQUARED; Dpl = phi[ell][ New] - phi[ell][ Old] -(Oldw0 + w0) * ell * 80; - Dwl = .00625 * (Dpl - PI_SQUARED * floorf((Dpl + M_PI) * INV_PI_SQUARED)); + Dwl = .00625 * (Dpl - 2 * M_PI * floorf((Dpl + M_PI) / (2 * M_PI))); THa = (Oldw0 * (float)ell + Dwl); THb = (w0 - Oldw0) * ell * .003125; Mb = .00625 *(MNew - MOld);

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

I admire your tenacity Clayton!

The change to software_imbe_decoder does improve audio quality at this end as well. I added a small amount of logging and noted that the code is going back and forth between the fine and coarse transition operations, so it doesn't seem like something is just 'pegged' at a wrong value. This is all magic to me, however, so I have no intuition about what is or is not correct.

This is running on 11.10 with itpp 4.07 built from source, latest copies of op25 and fairly recent gnuradio and gr-baz.

Thanks!

--- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote: > > I've made a bit of progress. It appears that the phase calculation in software_imbe_decoder::synth_voiced is not correct in the "fine transition" case, resulting in abrupt phase shifts between the 20ms frames. I'm not sure yet how to correct it, but by commenting out the "fine transition" case completely so that the "coarse transition" case always runs instead, I've eliminated most of the warble. > > Another problem I noticed is that the audio output is sometimes greater than 1.0, resulting in clipping if connected directly to an audio sink. I corrected this by changing the "sample /= 16384.0;" line at the end of software_imbe_decoder::decode_audio back to "sample /= 32768.0;". > > - Clayton > > --- In op25-dev@yahoogroups.com, "argilo314" <argilo@> wrote: > > > > I'm getting the same issue with the sound: speech is intelligible but with a strong warble that makes it sound like talking through a fan. I had a quick look at the waveform and spectrum of the output but didn't spot any obvious problems there. Not knowing IMBE, I couldn't get far with the code. Any ideas? > > > > - Clayton > > > > --- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote: > > > > > > Basically looking at bit 113 (only) seems to indicate whether or not it's a voice frame of some sort. The audio still sounds like everyone is talking through a fan, but there are no dropouts, no clicks, no stutters, etc. > > > > > > I could not find anything resembling a DUID or NAC in the headers. If anyone has a suggestion to de-warble the audio, I would greatly appreciate it. > > >

Interesting! I did see on the MARCS page at Ohio.gov say that they were planning to upgrade to P25, which was a bit confusing. These are the control channels I'm able to see in UniTrunker with my little home-brew antenna. These are all around central/western ohio. The first one is the only analog system, and the signal is pretty poor. http://i.imgur.com/CoNGl.png I am able to decode the voice channels a bit in DSD on Windows as well. It's somewhat odd, as the voice, when it's smoothly decoded, is very high quality, but it drops out quite a bit. I'm doing it through the audio output of HDSDR, though, which is probably where the issue is. Anyway, DSD does kick out some diagnostic info as well if that's of any use. I can also get snapshots from Wireshark of the P25 CAI. I do appreciate any effort put into this but please enjoy your weekend first and foremost. :) Take care. --- In op25-dev@yahoogroups.com, "Matt" <matt.robert80@...> wrote:

Aha - the plot thickens. Ohio MARCS isn't a true P25 system - its an old Type 2, 3600 baud 2FSK Motorola trunk system that has Motorola ASTRO CAI compatible voice channels.

These systems were implemented between 1996 and 2002 which is after Motorola ditched VSELP as their codec and went to the CAI IMBE format that was ratified in 2002 as the real P25 standard. These systems supported analog voice also, however MARCS has dropped that and is only using digital voice.

These ASTRO voice channels use the same IMBE vocoder as a true P25 system, and a very similar CAI compatible format, but the usual P25 fields are used for other purposes. The NSWGRN used to use this before it went pure P25.

OP25 has been implemented to the P25 specs, which differ slightly form these systems.

The NAC values are calculated on these systems by a combination of the Type 2 System ID, and the Analog connect tone code. Anyone who played with the old classic trunker on 3600 baud systems will recall this.

If you could list which site you are listening to and the system ID, I can look into it further from some old notes that I have lying around.

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner.

I'd be happy to capture more if it's of any use or upload the files to another location.

Thanks

--- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@> wrote:

...

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On > > Behalf Of *Andy Knitt > > *Sent:* Tuesday, 24 April 2012 12:45 PM > > *To:* op25-dev@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**** > > > > **** > > > > > > >

So I have been trying figure out why I have been having problems with NID decoding in later versions of ubuntu, and have tracked it down to a difference in the versions of libitpp and libitpp-dev. After installing the versions from the 11.04 package repository (4.0.7-1, as opposed to 4.2-4 in 11.10 and onwards), it started working. The offending function call appears to be on line 177 in op25_decoder_bf.cc, which is a call to itpp::BCH.encode. It would be good if someone else could give this a try just to verify that it is an issue with later versions of libitpp (even though the bch source code doesn't appear to have changed in over 2 years...). Hope this info is of use to someone. Thanks, Mark --- In op25-dev@yahoogroups.com, "Matt" <matt.robert80@...> wrote:

One thing I need to clarify - when I say type 2 is a 3600 baud 2FSK system, I am referring to the control channel only. The voice channels are, of course, C4FM.

The really strange thing is that I have been over the DSD source code, and it decodes voice by specifically looking for LDU1 and LDU2 frames. If OP25 is detecting HDU frames, then DSD should be also..

Cheers, Matt

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Interesting! I did see on the MARCS page at Ohio.gov say that they were planning to upgrade to P25, which was a bit confusing.

These are the control channels I'm able to see in UniTrunker with my little home-brew antenna. These are all around central/western ohio. The first one is the only analog system, and the signal is pretty poor.

http://i.imgur.com/CoNGl.png

I am able to decode the voice channels a bit in DSD on Windows as well. It's somewhat odd, as the voice, when it's smoothly decoded, is very high quality, but it drops out quite a bit. I'm doing it through the audio output of HDSDR, though, which is probably where the issue is.

Anyway, DSD does kick out some diagnostic info as well if that's of any use. I can also get snapshots from Wireshark of the P25 CAI.

I do appreciate any effort put into this but please enjoy your weekend first and foremost. :)

Take care.

--- In op25-dev@yahoogroups.com, "Matt" <matt.robert80@> wrote:

...

Aha - the plot thickens. Ohio MARCS isn't a true P25 system - its an old Type 2, 3600 baud 2FSK Motorola trunk system that has Motorola ASTRO CAI compatible voice channels.

These systems were implemented between 1996 and 2002 which is after Motorola ditched VSELP as their codec and went to the CAI IMBE format that was ratified in 2002 as the real P25 standard. These systems supported analog voice also, however MARCS has dropped that and is only using digital voice.

These ASTRO voice channels use the same IMBE vocoder as a true P25 system, and a very similar CAI compatible format, but the usual P25 fields are used for other purposes. The NSWGRN used to use this before it went pure P25.

OP25 has been implemented to the P25 specs, which differ slightly form these systems.

The NAC values are calculated on these systems by a combination of the Type 2 System ID, and the Analog connect tone code. Anyone who played with the old classic trunker on 3600 baud systems will recall this.

If you could list which site you are listening to and the system ID, I can look into it further from some old notes that I have lying around.

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner.

I'd be happy to capture more if it's of any use or upload the files to another location.

Thanks

--- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@> wrote:

...

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On > > > > Behalf Of *Andy Knitt > > > > *Sent:* Tuesday, 24 April 2012 12:45 PM > > > > *To:* op25-dev@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**** > > > > > > > > **** > > > > > > > > > > > > > > > > > >

Definitely of use, thanks Mark. Its been ages since Ive built this from scratch so I'll whip up a new VM and replicate the issue. Cheers, Matt --- In op25-dev@yahoogroups.com, "markop25" <cottrell.m.a@...> wrote:

So I have been trying figure out why I have been having problems with NID decoding in later versions of ubuntu, and have tracked it down to a difference in the versions of libitpp and libitpp-dev. After installing the versions from the 11.04 package repository (4.0.7-1, as opposed to 4.2-4 in 11.10 and onwards), it started working. The offending function call appears to be on line 177 in op25_decoder_bf.cc, which is a call to itpp::BCH.encode. It would be good if someone else could give this a try just to verify that it is an issue with later versions of libitpp (even though the bch source code doesn't appear to have changed in over 2 years...). Hope this info is of use to someone.

Thanks, Mark

--- In op25-dev@yahoogroups.com, "Matt" <matt.robert80@> wrote:

...

One thing I need to clarify - when I say type 2 is a 3600 baud 2FSK system, I am referring to the control channel only. The voice channels are, of course, C4FM.

The really strange thing is that I have been over the DSD source code, and it decodes voice by specifically looking for LDU1 and LDU2 frames. If OP25 is detecting HDU frames, then DSD should be also..

Cheers, Matt

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

Interesting! I did see on the MARCS page at Ohio.gov say that they were planning to upgrade to P25, which was a bit confusing.

These are the control channels I'm able to see in UniTrunker with my little home-brew antenna. These are all around central/western ohio. The first one is the only analog system, and the signal is pretty poor.

http://i.imgur.com/CoNGl.png

I am able to decode the voice channels a bit in DSD on Windows as well. It's somewhat odd, as the voice, when it's smoothly decoded, is very high quality, but it drops out quite a bit. I'm doing it through the audio output of HDSDR, though, which is probably where the issue is.

Anyway, DSD does kick out some diagnostic info as well if that's of any use. I can also get snapshots from Wireshark of the P25 CAI.

I do appreciate any effort put into this but please enjoy your weekend first and foremost. :)

Take care.

--- In op25-dev@yahoogroups.com, "Matt" <matt.robert80@> wrote:

...

Aha - the plot thickens. Ohio MARCS isn't a true P25 system - its an old Type 2, 3600 baud 2FSK Motorola trunk system that has Motorola ASTRO CAI compatible voice channels.

These systems were implemented between 1996 and 2002 which is after Motorola ditched VSELP as their codec and went to the CAI IMBE format that was ratified in 2002 as the real P25 standard. These systems supported analog voice also, however MARCS has dropped that and is only using digital voice.

These ASTRO voice channels use the same IMBE vocoder as a true P25 system, and a very similar CAI compatible format, but the usual P25 fields are used for other purposes. The NSWGRN used to use this before it went pure P25.

OP25 has been implemented to the P25 specs, which differ slightly form these systems.

The NAC values are calculated on these systems by a combination of the Type 2 System ID, and the Analog connect tone code. Anyone who played with the old classic trunker on 3600 baud systems will recall this.

If you could list which site you are listening to and the system ID, I can look into it further from some old notes that I have lying around.

--- In op25-dev@yahoogroups.com, "rrgsti" <bobrich@> wrote:

...

The capture is from a local repeater in the Ohio MARCS system. I get pretty strong signals from a few of them, I believe this one in particular was from London, Ohio in Madison county (the control channel may actually be in there as well). I do know that RadioReference streams this repeater through a Uniden BC796D digital scanner.

I'd be happy to capture more if it's of any use or upload the files to another location.

Thanks

--- In op25-dev@yahoogroups.com, Matt Robert <matt.robert80@> wrote:

...

I thought the same thing but then recalled that 000 is not available as a NAC - the standard defines the value as having the range 0x001-0xFFF.

I think a capture file would be ideal - this is a curly one for sure!

Bob - which system is this coming off?

Cheers, Matt

________________________________ From: Steve Glass <stevie.glass@> To: op25-dev@yahoogroups.com Sent: Thursday, 3 May 2012 11:31 AM Subject: Re: [op25-dev] Re: OP25 GRC - Almost but not quite working

  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@> 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@yahoogroups.com, "rrgsti" <bobrich@> 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@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@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@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@yahoogroups.com [mailto:op25-dev@yahoogroups.com] *On >> > > > Behalf Of *Andy Knitt >> > > > *Sent:* Tuesday, 24 April 2012 12:45 PM >> > > > *To:* op25-dev@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**** >> > > > >> > > > **** >> > > > >> > > > >> > > > >> > > >> > >> > >