ProVoice IMBE decoding

Status
Not open for further replies.

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
ProVoice uses a variant of IMBE. In June of 2006, I examined the raw package structure to see how close it came to the P25 variation of IMBE. Here are my notes. Hope someone finds them useful.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
The purpose of this investigation is to determine whether the IMBE
vocoder used in APCO P25 solutions might apply to EDACS ProVoice.

An IMBE voice cell uses 144 bits per cell to represent 20ms of speech.

EDACS ProVoice frames are sent at a bit rate of 9600 bps. The frame sync
can be seen repeating at 96 byte intervals. The format is described below.

EDACS 80 ms ProVoice frame (96 bytes)

AE 24 66 66 D2 D2 D2 D2 D2 D2 D2 D2 ?? ?? FF 07
BE 2E 64 12 9D A2 ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? 42 EA ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??

(repeats for duration of call)

The above pattern suggests 72-74 bytes payload or 572-592 bits per frame
for voice and/or ANI information.

P25 uses 144 bit ECC cells; at 9 cells per P25 voice frame.

Assuming ProVoice is similar - 576 / 144 = 4.0 cells per frame.

IMBE voice cells are 20ms. Assuming 4 IMBE cells per frame
matches the 80ms interval occupied by the voice frame.

The "executive summary" is ... there may be four IMBE cells buried
somewhere inside each Provoice frame. Each cell is 18 bytes long.
The cells may be stacked consecutively or interleaved.

The following is pure speculation where K,L,M, and N represent the four IMBE cells.

AE 24 66 66 D2 D2 D2 D2 D2 D2 D2 D2 ?? ?? FF 07
BE 2E 64 12 9D A2 KK KK KK KK KK KK KK KK KK KK
KK KK KK KK KK KK KK KK LL LL LL LL LL LL LL LL
LL LL LL LL LL LL LL LL LL LL 42 EA MM MM MM MM
MM MM MM MM MM MM MM MM MM MM MM MM MM MM NN NN
NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN

Observation: the first two bytes match the two bytes located in between the
speculated L and M cells - if you reverse the order of the nibbles; eg.
Digits AE 24 when reversed give 42 EA. (Edit: coincidental to the sample data)

1010 1110 0010 0100
0100 0010 1110 1010

Observation: I can see repetitive byte pairs at bytes 12:13 (just before the "FF 07"
sequence) of every frame. The values seem to repeat every other frame.

Last frame ...

AE 24 66 66 D2 D2 D2 D2 D2 D2 D2 D2 55 55 FF 07
BE 2E 64 12 9D A2 ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
?? ?? ?? ?? ?? ?? ?? ?? 51 DB 55 55 51 DB 55 55
51 DB 55 55 51 DB 55 55 51 DB 55 55 51 DB 55 55
51 DB 55 55 51 DB 55 55 51 DB 55 55 51 DB 55 55
51 DB 55 55 51 DB 55 55 51 DB 55 55 51 DB 55 55
51 DB 55 55 51 DB 55 55 AE 25 54 AB 55 55 4B 06
AA AA B4 F9 55 55 4B 06 AE 25 54 AB 55 55 4B 06
AA AA B4 F9 55 55 4B 06 AE 25 54 AB 55 55 4B 06
AA AA B4 F9 55 55 4B 06 AE 25 54 AB 55 55 4B 06
AA AA B4 F9 55 55 4B 06 AE 25 54 AB 55 55 4B 06
AA AA B4 F9 55 55 4B 06 AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
AA AA AA AA AA AA AA AA AA AA AA AA AA AA 00 00

(string of 00's followed by noise)

The sequence of AA's above are alternating 1's and 0's - the 4800 hz
"dotting" tone that marks the end of the call.


51 DB 55 55
51 DB 55 55
AE 25 54 AB
55 55 4B 06
AA AA B4 F9
55 55 4B 06

F9 is complement of 06

AE is complement of 51

4B is transpose of B4

AB is complement of 54

0010 0101

Observation: this does NOT work for encrypted ProVoice - it uses a different sync pattern.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
After writing the above, I later learned that the 8 octets of "D2" that start each voice frame are actually the crypto IV. Eight bytes of "D2" are a clear, unencrypted ProVoice transmission.

Like the P25 IMBE voice format, ProVoice is also published. For a mere $210, you too can own a copy of the specification:

IHS/Global - Search Results

Enjoy.
 

dsdauthor

Member
Joined
Mar 17, 2010
Messages
49
Thank you, that is very useful info. So to be clear is the frame sync AE 24 66 66? If so then it is not a 2 level sync? Most sync patterns are 2 level even if the rest of the frame is 4 level. I have been looking and unfortunately there are not any Provoice systems within listening range so I will need a .wav file with a few minutes of voice traffic to work on this. (the usual 48k/16bit/mono format).
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
ProVoice shares the same common air interface as the EDACS 9600 control channel. It is a simple two level FSK signal.
 
N

N_Jay

Guest
ProVoice shares the same common air interface as the EDACS 9600 control channel. It is a simple two level FSK signal.

You mean they share the same modulation.

That is far from a Common Air Interface.

Yes, EDACS digital modulation, which ProVoice is built on top of is a simple 2 level FSK type.
I think it is GSMK but I am not sure.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
N_Jay said:
That is far from a Common Air Interface.
I mean the same CAI. The spec describes both control channel and working (voice) channel formats. To be precise, the symbol format is a two level gaussian filtered FSK signal. The spec calls it "GFSK".

So there. ;-P
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
I have been looking and unfortunately there are not any Provoice systems within listening range so I will need a .wav file with a few minutes of voice traffic to work on this. (the usual 48k/16bit/mono format).
Samples sent.
 

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
Signals Analysis: APCO-25, is qualitative decoding possible from discriminator's output?

Thanks for interesting topic.

I also say thanks for all the interesting goodies ! As to the specific question, the discriminator tap is a good source of signals but unfortunately there are some types of stations that it can't hack. In the general case, of course, we wouldn't expect to be able to do much with a received SSB or AM signal if the only recorded version available came from a discriminator output.

One trouble is with P25 signals from systems that use LSM style simulcasting. I wonder if the "bad" one shown on your page (at signalsanalysis) was taken from an LSM system? Also I would be interested to see the eye diagrams related to this signal. The eye diagram is taken at a point after FM demodulation but prior to (attempting) C4FM demodulation, so it would show some information that is lost in your "symbol" plots. Also, how did you execute the actual C4FM demodulation? Is it possible to obtain complex I/Q captures plus discriminator tap captures simultaneously of the signal?

There is a very unfortunate discrepancy in your two diagrams. The "bad" one contains a blue-ish plot just above it (missing in the "good" one). Looking at this blue-ish plot, does it seem to show good periods interrupted by bad periods ?

Scanners have many other possible maladies impacting use with PSK
- the 455 KHz IF channel isn't very phase-flat (same for the 1st and 2nd IF's)
- the oscillators aren't all low phase-noise
- AGC action is incorrect for LSM

Currently in the OP25 project we have two primary methods of symbol extraction :
1. Frank's Radio Rausch FSK4 (C4FM) decoder
2. CQPSK decoder based on the GR MPSK receiver (works well with LSM, BTW)

IMHO, both methods have a valid place at the table. Unfortunately only the first (FM) method is compatible with the disc-tap.

Unitrunker, Slicerwizard, DsdAuthor, others on this forum, assuming we all don't want to be out of business due to the obsolescence of the disc-tap, what do folks see as the way forward from here?

Best Regards

Max
 

MSM_Maria

Member
Joined
Aug 25, 2009
Messages
22
Many thanks for attention to our article. That is only review article, which concerns main problems.

There is no big lack of correspondence in graphics. On the first one is an absence of clock synchronisation, on the second complete clock synchronisation is represented.

We stick to opinion that the best results are gotten from the phase demodulator aswel, but in a case with an output from the discriminator it is not acceptable. Nevertheless it is possible to receive quite good results from discriminator's output, but ofcourse it is not simple.

The very interesting subject and the very interesting DSD program.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Maria - thank you for the article link.

In the case of ProVoice - the signal is a simpler two level mode. I've revised my notes on the voice frame format - the previous example(s) were shifted two bits. Here's the corrected template:

Code:
57 12 33 33 69 69 69 69 69 69 69 69 a5 83 FF 83
DF 17 32 09 4E D1 KK KK KK KK KK KK KK KK KK KK
KK KK KK KK KK KK KK KK LL LL LL LL LL LL LL LL
LL LL LL LL LL LL LL LL LL LL 21 75 MM MM MM MM
MM MM MM MM MM MM MM MM MM MM MM MM MM MM NN NN
NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN

The observed frame sync value of 57123333 does NOT appear in the published spec.

The octet pair at 12/13 consistently alternates between the values "AA AA" and "A5 83". Combining these two yields a BCH protected codeword. AAAAA583 is the "null" code word for the working (voice) channel.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
Unitrunker, Slicerwizard, DsdAuthor, others on this forum, assuming we all don't want to be out of business due to the obsolescence of the disc-tap, what do folks see as the way forward from here?
I think something like a "Soft Rock" hardwired to the receiver's IF with the I+Q signals piped into a stereo sound input is the direction we need to go. Complexity is the same as a slicer - but far more versatile.
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
I am soooo glad we are finally getting into good solid technical discussions concerning complex digital mode demodulation! In my personal opinion, focus REALLY needs to be on designing a good solid reproduceable I/Q demodulation method encompassing everything from IF filtering to I and Q outputs. I've thought this for a very long time, actually. And I am speaking to both the hobbyists/experimenters as well as the actual product manufacturers.

Max (KA1RBI), I think your info and summary of the difficulties facing the current scanner designs was excellent! I hadn't thought at all about the AGC issues - good you brought that up!

I can't believe that I/Q demodulation by itself would significantly add to the cost of a consumer scanner but I DO see the final IF filter quality being an issue as well as making a nice tight local oscillator with low phase noise output within acceptable cost range. I think those two issues (final IF filter group delay quality and local oscillator stability and phase noise) will be the biggest hurdles of scanner manufacturers to design with low cost.

For us as experimenters it may be ok to neglect the final IF filter by simply bypassing it for experimental purposes BUT, eventually, for everyday usage a good final IF filter will be needed to deal with adjacent channel and passband noise issues. Also, we will probably need a good external oscillator to take the place of the scanner's (or other receiver's) internal LO. Maybe something like these will work: Nova Engineering: Products: NovaSource G6. The quality of the internal mixer might also be an issue so we may have to literally take over for the entire final IF chain.

If I were designing this from the ground up I would probably start with a modular approach to make a solid high performance testbed with as high quality parts as could be afforded and obtained. This would be used for concept testing of hardware and software. At the point where understanding of the concepts involved is high enough and where repeatable high performance results are obtained I would then look at where to reduce costs and consolidate/simplify hardware designs. The ultimate goal being a solid design ready for mass production within reasonable cost windows.

Unitrunker, I realize this discussion derailed from your Provoice focus and really belongs in a more general thread (the DSD thread, maybe, or a new one devoted to the hardware aspects of this effort) but I wanted to reply to the issues brought up by MSM_Maria and KA1RBI. Moderators, feel free to divest the non-relevant posts from this thread and move to either a more appropriate existing one or to an entirely new one if necessary. It is not my intention to hijack Unitrunker's real focus!

Unitrunker, I do have a question for you, though, if you don't mind. You mention the "Soft Rock" again as you did in the GRE forums thread about I/Q test points. I followed your link but could not find any descriptive information concerning the product. Could you direct me to where to find such info, details, schematics, block diagrams, operation and usage, etc.? Many thanks in advance!

-Mike
 
Last edited:

KA1RBI

Member
Joined
Aug 15, 2008
Messages
799
Location
Portage Escarpment
It is not my intention to hijack Unitrunker's real focus!

-Mike

Nor mine.

A couple of additional items. First, I have an experimental, strictly D.I.Y. project along these lines... It is at
A 455 KHz IF Downconverter for Digital Radio Reception
Lots of things about this design are sub-standard but it
a) works
b) outputs a data format that's fully compatible with the complex I/Q format used by GR and the USRP

Unfortunately it doesn't work with LSM/CQPSK using a R.S. scanner modified to add a 455 KHz IF output connector.

So, a separate round of experimentation.
1) The USRP was first connected directly to an antenna and correct reception of LSM confirmed.
2) The same antenna was now connected to the R.S. scanner; the USRP was then connected to its 455 KHz output. C4FM stations receive OK, but LSM/CQPSK stations don't. The eye diagram is even worse than normal for these. Signal strength is very strong.
3) An ICOM R7100 was borrowed. Its (factory) 10.7 IF output was fed to the USRP and the same experiment in (2) was repeated. The signal strength was too low to be usable. So an old home brew HF band MOSFET pre-amp was connected inline. This fixed the signal strength issue. C4FM stations now demodulate very nicely using FSK4. However LSM/CQPSK reception is still not working :-( . In one test, the radio was tuned 15 KHz off frequency so as to get rid of the AGC action (?) but this didn't change anything...

There are unfortunately too many independent variables here to try to eliminate possible suspects. For one thing different USRP daughterboard was used in case (1) from the one used in cases (2) and (3). The LSM demodulation software is also very tricky.

One final data point, the USRP has separate board, the "TVRX" based on a TV tuner module. This doesn't work with CQPSK !

Max
 

Mike_G_D

Member
Joined
Dec 19, 2002
Messages
1,241
Location
Vista, CA
New Hardware Thread Started

KA1RBI, MSM_Maria, Unitrunker, any others interested, I started a new thread concerning the hardware development efforts concerning these issues here: http://forums.radioreference.com/tr...digital-demodulation-hardware-discussion.html.

I would like to ask the moderators to move all of the posts related to the hardware discussions to that thread when possible so as not to inadvertently hijack this thread's focus.

KA1RBI - your info is interesting and I will check that link out! Hopefully we can continue the discussion in the hardware thread I mentioned.

Thanks all and my apologies to Unitrunker for the hijacking of his thread!

-Mike
 
Last edited:

dsdauthor

Member
Joined
Mar 17, 2010
Messages
49
Maria - thank you for the article link.

In the case of ProVoice - the signal is a simpler two level mode. I've revised my notes on the voice frame format - the previous example(s) were shifted two bits. Here's the corrected template:

Code:
57 12 33 33 69 69 69 69 69 69 69 69 a5 83 FF 83
DF 17 32 09 4E D1 KK KK KK KK KK KK KK KK KK KK
KK KK KK KK KK KK KK KK LL LL LL LL LL LL LL LL
LL LL LL LL LL LL LL LL LL LL 21 75 MM MM MM MM
MM MM MM MM MM MM MM MM MM MM MM MM MM MM NN NN
NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN NN

The observed frame sync value of 57123333 does NOT appear in the published spec.

The octet pair at 12/13 consistently alternates between the values "AA AA" and "A5 83". Combining these two yields a BCH protected codeword. AAAAA583 is the "null" code word for the working (voice) channel.

You are correct about most of that. ProVoice uses a slightly different version of IMBE than P25. It has 142 bits per frame instead of 144. There are two spacer bits (zeroes) after the end of each IMBE data field to round it up to 144 bits.

I have added support for 9600sym/sec 2 level FSK which tracks ProVoice samples nicely. The frame sync and location of the IMBE data was not hard to find. I have added support for this 7100x4400 version of IMBE to mbelib.

The only remaining challenge is to determine the interleave of the IMBE frames. It looks like there are two IMBE frames interleaved together in the fields labeled "KK" and "LL" in your chart, and two other IMBE frames interleaved together in "MM" and "NN".

In this particular version of IMBE the first bit is always set to zero. You can see that the first bit in "KK" and "MM" is always zero so that bit location is easy to identify (and in most interleave patterns the first bit is not moved so this makes sense). The sixth bit of "KK" and "MM" is also always zero so this is probably the first bit of IMBE frames 2 and 4. It looks like the two IMBE frames are interleaved together in 6 bit chunks. This is especially apparent in the first ProVoice frame in a transmission which contains four identical "filler" IMBE frames. In that we see pairs of 6 bit data (bits 0-5 are the same as 6-11, 12-17 are the same as 18-23 etc).

The rest of the interleave pattern remains to be determined. Once we have the correct (or even moderately correct) interleave pattern we should have voice decode.
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
You are correct about most of that. ProVoice uses a slightly different version of IMBE than P25. It has 142 bits per frame instead of 144.
The spec confirms this.

I have added support for 9600sym/sec 2 level FSK which tracks ProVoice samples nicely. The frame sync and location of the IMBE data was not hard to find. I have added support for this 7100x4400 version of IMBE to mbelib.
Fantastic! Where's the download link?

The only remaining challenge is to determine the interleave of the IMBE frames.
Oh.

It looks like there are two IMBE frames interleaved together in the fields labeled "KK" and "LL" in your chart, and two other IMBE frames interleaved together in "MM" and "NN".
The spec confirms this. On the flow diagram in Figure 20 is a box labeled "Two Slot Interleaver".

The rest of the interleave pattern remains to be determined. Once we have the correct (or even moderately correct) interleave pattern we should have voice decode.
Let me check ...
 

SCPD

QRT
Joined
Feb 24, 2001
Messages
0
Location
Virginia
The rest of the interleave pattern remains to be determined. Once we have the correct (or even moderately correct) interleave pattern we should have voice decode.
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.

Paragraph 7.5 said:
7.5 Bit Interleaving
Intra-frame bit interleaving is used to spread short bursts of errors among several code words. The
interleaving table for the 142 bits in each frame is tabulated in Annex H. This annex uses the notation
scheme where bit N-1 (where N is the vector length) is the MSB and bit 0 is the LSB. The minimum
separation between any two bits of the same error correction code is, in most cases, 6 bits.
So there you have it. Annex H has the interleave schedule.

Code:
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^)
 
Last edited:
Status
Not open for further replies.
Top