DV Dongle AMBE Codec: Potential

[PeterGV]

Eric... You totally rock. Thanks for your pioneering work, and keep us informed.

de Peter K1PGV

 

[kb1ipd]

Hello,

I am still working on a P25 decoder. I managed to spend over a week finding out my AR5000 does not pass the P25 waveform cleanly. 9600 baud EDACS is no problem with the AR5000. It appears there is too much level shifting of the waveform for a clean P25 decode. There is some circuity in the AR5000 between the Discriminator Output and the Demod Output. There is a mod to tap directly off the Discriminator Output. With the bad output I could not get a good decode of the sync bits and data clock recovery did not work well.

I tried my WinRadio G305e today as a test and the waveforms look a lot better. I still need to feed it through the decoder and see if I can get good decodes. Back to Square One.

73 Eric

I can't thank you enough for going to this effort. I suppose the discriminator problem is to be expected if there's not a direct output. You said back to square one? You can't reuse any of the software code or is this a hardware problem?

Good luck. If you can get a firm yes or no on this I'll be eternally indebted (well especially if the answer is yes)

73
Steve

 

[PeterGV]

Sigh!

I actually spent some time exchanging email with the people at DVSI today.

According to them, the AMBE-2xxx chips are designed to only decode audio streams from other AMBE-2xxx chips. They will NOT decode an extracted P25 audio stream.

While I had always understood the AMBE was backwards compatible with IMBE, the DVSI folks said, very specifically when asked, that the stream formats were different, and that the AMBE-2xxx part would not do P25 audio (assuming you extracted the P25 digital audio and clocked it correctly to the chip).

This was a major surprise to me.

More at this thread: http://www.radioreference.com/forums/showthread.php?p=765607

It would be very nice to put this to rest once and for all. So I eagerly await your tests, Eric.

de Peter K1PGV

 

[EricCottrell]

I can't thank you enough for going to this effort. I suppose the discriminator problem is to be expected if there's not a direct output. You said back to square one? You can't reuse any of the software code or is this a hardware problem?

Good luck. If you can get a firm yes or no on this I'll be eternally indebted (well especially if the answer is yes)

73
Steve

Hello,

I am a software developer so if it was from the beginning then it would be back to square zero.

I actually made some progress last night. I recorded some P25 from the WinRadio. I take the recording and play it back on one computer to the computer that has the p25dump program. After not liking the results of my playback system with the WinRadio files, I wrote code that extracts the samples directly from the wav file and dumps the bits as ASCII 1 and 0 characters.

I searched the output text file and found numerous P25 frame sync patterns! Finally! Now I can start extracting the voice frames. So now I am on Square Two.

73 Eric

 

[mancow]

You'se d' man

Good luck and let us know if we can do anything to help at all.

 

[kb1ipd]

Any updates on progress?

 

[MattSR]

Im sure he will post when he has something to report....

 

[EricCottrell]

Hello,

I have not completed the investigation yet but I finally made some progress.

I am not on this full time but was able to do some experiments over the weekend. The main problem was due to C4FM modulation used in P25 being a very difficult waveform to do simple clock recovery on. The clock is used to decide which sample of the ten samples per bit time is the center and represents the data value. The classic method uses zero crossings. If I graph the sample values I could see good values at the center of the data bit but there was a variation of where the zero crossing occurred due to what the previous data values were. This caused the decoding to actually drop or pickup bits during the decoding of the long voice packets. I got to the point where the short packets were decoding okay but the size of the voice frames were varying.

Last night I hit upon a better method to select what zero crossings to use and now it appears I am decoding voice frames better. I am seeing more consistent data that looks like real voice data. So over the weekend I should have time to actually feed the voice bits into the DV Dongle and see if it decodes.

Separately I have been playing with the DV Dongle. There seems to be a number of parameters that can be adjusted that gives the same basic rate but changes bit interleaving and other error correction methods. If the default one specified for 7200 bps does not work then some other combinations need to be tested.

73 Eric

 

[kb1ipd]

Awesome! You're my new hero. If you can extract the speech stream that would be amazing, even if you can't yet decode it. I'm currently looking into some other options for how IMBE/AMBE hardware might be able to be hosted through a PC.

 

[w8hey]

Eric, were you ever able to make any progress on this?

 

[kb1ipd]

It's been a while. I'd be interested to know if any progress has been made or if the project has been dropped. I personally don't have a DV Dongle and I'm not very experienced in programming for this kind of thing, but if it turns out that there is some progress and it has potential then I'll likely buy my own and start working on it. That being said, I'm a student and don't have much money to plunk down on that.

If it could be made to work with Apco-25 then the next step could be opensky and provoice!

 

[MattSR]

Hello,

Has any progress been made on this?

Thanks,
Matt

 

[Mike_G_D]

NXDN applications

I, too, am interested in how this is progressing, if at all. Now, I also have an interest in the NXDN digital voice format. It uses the AMBE vocoder which may make it more applicable to the DV Dongle. If Eric is still working on this or is checking this thread at all I would suggest examining that application especially if the P25 work is proving too frustrating.

The NXDN thread is here if interested: http://www.radioreference.com/forums/showthread.php?t=93655.

Rich, N2DLX, has wrote that he is willing to provide discriminator-tapped audio samples if Eric or whomever is interested.

-Mike

 

[tekayemane]

Hi

I was wondering if it is possible to have a software implementation of IMBE vocoder. I want to build an SDR receiver as my senior project that takes p25 signals and performs demodulation and decoding and result in a bit stream output of the original signal. I want to implement this project using the USRP h/w and gnuradio -3.1.3 toolkit on my fedora 9.0 OS.
As I can see from forums it is not difficult to implement the demodulator but there is problem with the IMBE vocoder as it is copyrighted by DVSI.
So, if any body has ideas please give your suggestions!
teka

 

[tekayemane]

Hello,

We have programs that can decode 9600 baud P25 control channels from a discriminator tap and voice is just another frame type. This will be a good use of a stereo line in with the control channel on one line in channel and voice channel on the other line in channel.

The fun part is decoding the protocol and getting it into the proper format for the AMBE chip. I remember that the FEC (Forward Error Correction) part of the P25 voice frame is done by the AMBE chip so the PC just needs to do the upper level error correction.

I briefly looked at the ProVoice format a year or so ago and it appears to be similar to the EDACS control channel format. It uses a different preamble. The important bits are transmitted three times with the second time inverted just like the control channel. There are additional "unimportant" bits at the end that are just transmitted once. In P25 there are also "unimportant" bits that are not protected by FEC. This is the reason P25 tends to sound robotic on weak signals. I do not know if the ProVoice stream has FEC or not but the end result seems to be a similar data stream fed to the IMBE chip as P25.

I ordered one and it is being shipped ground out of Atlanta so it will take a few days. I suspect it will be a few weeks before I can figure out if this can decode P25. We have a local DStar Repeater so I could always use it for DStar if it does not decode IMBE.

73 Eric

Hello there,
I am developing a p25 receiver using gnuradio and usrp and I wonder if you have some ideas regarding the demodulator and decoder components.
thanks
teka

 

[inigo88]

Just a quick *bump* on this thread. I got really excited reading through both pages and then realized the last post from Eric was all the way back in April. Eric, if you have the time we'd love to know if you're still working on this project and if any progress has been made. Thanks!

-Inigo

 

[N_Jay]

Hello there,
I am developing a p25 receiver using gnuradio and usrp and I wonder if you have some ideas regarding the demodulator and decoder components.
thanks
teka

Demod should not be too hard.

Your school engineering library should be able to get you the standards documents.

Decode is a bit harder. You may try contacting DVSI.

 

[SCPD]

Decode is a bit harder. You may try contacting DVSI.

The TIA docs include a full vocoder description.

 

[N_Jay]

The TIA docs include a full vocoder description.

Yes, a description, but I doubt enough for development of a working and compatible vocoder.

 

[MattSR]

You'd be surprised how much detail is given. As Rick has said its a full description - if you have some codec/DSP nous you could probably reverse engineer the codec.