ProVoice IMBE decoding

[Mike_G_D]

Mike
here is the Softrock Info Page

Lite + USB Xtall RX V9.0 - Home Page


Ronen - 4Z4ZQ
Ronen Pinchooks (4Z4ZQ) WebSite

Thanks! Much appreciated!

-Mike

 

[dsdauthor]

I had to literally reboot my machine twice. The PITA DRM protection on the TIA specs won't let me open two of them at once.


So there you have it. Annex H has the interleave schedule.

Symbol Bit 1  Bit 0 Symbol Bit 1   Bit 0
     0 c0(18) c1(23)    36 c0( 6)  c1(11)
     1 c2(22) c3(22)    37 c2(10)  c3(10)
     2 c4(14) c5(14)    38 c4( 2)  c5( 2)
     3 c0(17) c1(22)    39 c0( 5)  c1(10)
---------------->8 snip 8<------------------

The bits are paired into symbols (which has nothing to do with the 1 bit per symbol modulation format). As you can see, the most significant bit of c0 is placed in the most significant bit of byte 0.

Thank you so much for your hard work. I would argue that providing ProVoice capability is more important than P25. You can walk into a Radio Shack to buy a P25 capable scanner. You can't buy a ProVoice capable scanner over the counter. I hope to see some new live feeds appear in the months ahead.

Everyone anxiously awaits your next release announcement. 8^)

Unfortunately it is not that simple. That may be the interleave within an IMBE frame but it does not tell us how they interleave two IMBE frames together. At first it looks like there are 6 bits from frame 1 and then 6 bits from frame 2, the next 6 bits from frame 1 etc. The problem is that 284 is not evenly divisible by 6 so there have to be some exceptions to that general pattern. If you assume that they alternate every 6 bits, that seems to work until halfway through the second data field where things don't always match up.

Here is a sample of how pairs of 6 bits are duplicated in the "filler" frame that begins most voice transmissions. These filler frames appear to contain four identical IMBE frames. These are the bits from data fields "K" and "L" in the order left-right/top-bottom. They have been separated into two columns 6 bits wide to show how the bits repeat every 6 bits. This isn't perfect as you can see some pairs aren't duplicates.

field K (142 bits):

imbe1 imbe2

000100 000100
001000 001000
001100 001100
100110 100110
001100 001100
001000 001000
111010 111010
000110 000110
110100 110100
111110 111110
011100 011100
001110 0011

field L (142 bits):

imbe1 imbe2

           10
010010 010010
001100 001100
011100 011100
110111 101111
111011 111011
010011 010010
111010 111001
100001 100001
011001 011010
100010 100000
001000 001011
1001   1100

When I apply the intra-frame interleave schedule to each imbe frame derived from the above method I get some errors and no inteligible speech so it's not right.

 

[SCPD]

Okay ... I can't read. This is an "Intra" slot interleave table - not and "Inter" slot interleave table.

Here's a possible clue: "The seven modulated code vectors are then interleaved as specified in Appendix H, and finally the frame bits are
embedded in the Enhance Digital Access Communications System format in ascending order."

EDIT: After some digging - I no longer believe the IMBE cells are interleaved in pairs. I think the cells are independent of each other. The "two slot interleaver" is poorly named.

 

[SCPD]

For the benefit of others wanting to play along ... here is a raw bit file of Provoice data. It has been trimmed to contain 50 or so neatly byte aligned voice frames. That's roughly 200 IMBE cells or about 4 seconds of speech. It is ZIP compressed ONLY because this forum won't accept a raw data file type for upload. You'll need a hex dump or hex editor utility to view the data.

 

[dsdauthor]

I have the interleave completely sorted out and now have error free decode with speech. I expect to have a release out sometime this weekend.

In case anyone is curious, here is the solution:

ProVoice voice frames contain four IMBE frames in two groups of two. Each pair of IMBE frames is interleaved together.

Fortunately there are special "filler" ProVoice frame seen at the beginning of a transmission that appear to have four identical IMBE frames. Because the frames are identical we can easily see groups of 5 or 6 bits that repeat and indicate how the two IMBE frames were combined:

Field 1 (142 bits)

IMBE1  IMBE2

000100 000100
001000 001000
001100 001100
100110 100110
001100 001100
001000 001000
111010 111010
000110 000110
110100 110100
111110 111110
011100 011100
001110 0011

Field 2 (142 bits)

IMBE1  IMBE2
           10
010010 010010
001100 001100
011100 011100
11011  11011
111110 111110
110100 110100
101110 101110
011000 011000
010110 010110
101000 101000
000010 000010
11100 11100

The two 5 bit pairs being separated by 8 pairs was a clue that the IMBE data within each frame was interleaved with 8 row spacing. All of the bits in column 6 being 0 suggested that those bits were part of c6, since c6 does not have any pseudo-random bit modulations applied. It turns out that these filler frames contain an value for w0 that makes the frame invalid and the rest of the bits (after bit modulations) are all zero.

Using trial and error and verifying with the number of corrected errors I was able to determine the exact interleave pattern within each IMBE frame. Fortunately this like most interleave systems follows a fairly simple pattern.

 

[SCPD]

I have the interleave completely sorted out and now have error free decode with speech. I expect to have a release out sometime this weekend.

Fantastic! I'll be in EDACS land this weekend. Can't wait to try it out.

 

[Radioman96p71]

Same here, I'm watching the wiki page so i can test it on our ProVoice system! Should be interesting.

 

[robsterw]

Noob alert... Would it now be technically possible to implement EDACS AEGIS in a future release?

 

[SCPD]

Have no clue on Aegis - please start a new thread discussion.

Now that dsd 1.3 is released, this thread is closed!