OP25 OP25 AMBE Tone Feature Missing

[studgeman]

File this under missing feature not bug, and I post it so others have a reference.

Now that I actually have OP25 decoding phase2 (thanks boatbod) I noticed something today. With the scanner running in parallel with OP25 fire station alerting tones (Quick Call II) were not generated in OP25, but were in the scanner.

Tones with the IMBE/AMBE vocoders:
Tones such as quick call, DTMF are not coded in the same way voice is. The DVSI vocoders detect the tone and specially code it outside of the voice process. These types of tones are coded into the chip. If you have ever noticed that certain tones sound crystal clear this is why.

If you happen to be running OP25 and notice this behavior, its not a bug, its a missing feature, it should be reasonably straightforward to reverse engineer if anyone has the time and patience and I am sure Mike and boatbod would appreciate the help. The code may be in SDRTrunk as well. I seem to remember the IMBE vocoder implementation generating tones.

 

[Spitfire8520]

It would be nice to eventually see this feature added to OP25. It interesting to note that OP25 does seem to already reproduce tones correctly when dealing with the IMBE vocoder on P25 Phase 1 systems.

 

[boatbod]

It would be nice to eventually see this feature added to OP25. It interesting to note that OP25 does seem to already reproduce tones correctly when dealing with the IMBE vocoder on P25 Phase 1 systems.

Are what you hear on the ph1 system actually coded and transmitted as tones or just encoded audio?

We have one county local to me that broadcasts minitor tones over their ph2 system, but they are not actually digitally encoded as tones.

 

[Spitfire8520]

Are what you hear on the ph1 system actually coded and transmitted as tones or just encoded audio?

We have one county local to me that broadcasts minitor tones over their ph2 system, but they are not actually digitally encoded as tones.

I am not 100% sure if either system actually transmits them as tones or audio. I can say with certainty that all tones across dozens of different dispatch setups on both Harris and Motorola Phase 1 systems are correctly generated. Harris and Motorola Phase 2 systems have never correctly generated a tone, which I find odd.

EDIT: Just checked the recordings I have access to and noticed I cannot find any evidence to support my below statement. As a result, the below observation is likely error of my memory.

(Old Statement Below)

What is more odd is that the Phase 2 system I am speaking of once used a gateway between their old EDACS to P25 for while migrating between systems. I believe that OP25 failed to correctly generate the tones that were connected through the gateway from the old analog system, which I would think is just straight encoded audio. That could indicate a problem with the Phase 2/AMBE code just being unable to generate a simple sine wave tone.

 

[studgeman]

They are coded tones. Its a Motorola 7.16 system with Phase 1 and Phase 2 sites. In this case the tones are generated in the MCC7500 consoles. IMBE tones come through, AMBE they do not.

If I read the software correctly with the -2 option OP25 invokes the AMBE, without the -2 it uses the IMBE.

 

[boatbod]

They are coded tones. Its a Motorola 7.16 system with Phase 1 and Phase 2 sites. In this case the tones are generated in the MCC7500 consoles. IMBE tones come through, AMBE they do not.

If I read the software correctly with the -2 option OP25 invokes the AMBE, without the -2 it uses the IMBE.

The "-2" option only enables the decoding of phase 2 (p25p2_tdma) and does not affect the phase 1 codec in any way.

The choice of decoder for phase 1 is controlled by the "IMBE" environment variable config parameter if it exists.

 

[nokoa3116]

The tones my fire department uses sound like this:
https://soundcloud.com/nokoa-official/sets/fire-tones

Some calls are 3 tones some are 1, and sometimes the tones sound different. I don't know if it's for paging or just for attention. I would really love to be able to hear them using boatbod's OP25.

 

[kb9mwr]

I think that is a little more involved than you think. There are likely only a few folks experienced with the voice coding stuff. That said, there is also room for improvement with the earlier AMBE version that D-Star uses. If you find someone to take up the task of the tones and the earlier version improvements, please let me know. I'd happily contribute to their beer fund in return for their efforts.

As for the the missing tone support, I'd assume the MD380 emulator does support the tones
https://github.com/travisgoodspeed/md380tools/wiki/MD380-Emulator

 

[boatbod]

As for the the missing tone support, I'd assume the MD380 emulator does support the tones
https://github.com/travisgoodspeed/md380tools/wiki/MD380-Emulator

The MD380 Emulator appears to wrapper MD380 firmware, so although it can encode/decode AMBE on a Linux host, it's actually the underlying firmware running in the emulator that does the heavy lifting. I don't think the source for the device firmware (or therefore the AMBE decoder) is available.

 

[kb9mwr]

Well starting at page 18 in the TIA-102.BABA-1 P25 Half Rate Vocoder Addendum it talks about tones, tone frames, tone regeneration, bit vector and valies, and all kinds of other somewhat cryptic stuff that is above my head.

 

[KA1RBI]

Could someone please post a capture of an ambe (phase 2) session that is known to contain tone frames?

I.e., frames in which the tones are not sent as ordinary audio, but are instead sent as dedicated tone frames...

The preferred way to do this would be via the op25 "-r X" option, where X is the name of a file where the received raw symbol data is to be written...

73

Max

 

[PiccoIntegra]

Try this one Max. This talk group isn't always in TDMA mode, so it was HARD to catch. There may be about five minutes worth of control channel data before the transmission occurred.

I've tried to debug this myself, and frames that are supposed to be "tone frames" are not per what the spec says they are. i.e. ((b0 == 126) || (b0 == 127))

I had to modify p25p2_tdma::handle_voice_frame to accommodate higher packet types:
if (b[0] < 120)
to
if (b[0] < 128)

I never saw anything higher than "silence frames". (124 and 125)

I know there are tones because I've heard them on a live stream from the same talk group.

 

[slicerwizard]

The tone frames in that data have b0 values of 120 and 121. Tone indexes are 15 and 28 (468.75 Hz and 875 Hz); tone amplitude levels are about -52 dBm0.

 

[boatbod]

Try this one Max. This talk group isn't always in TDMA mode, so it was HARD to catch. There may be about five minutes worth of control channel data before the transmission occurred.

I've tried to debug this myself, and frames that are supposed to be "tone frames" are not per what the spec says they are. i.e. ((b0 == 126) || (b0 == 127))

I had to modify p25p2_tdma::handle_voice_frame to accommodate higher packet types:
if (b[0] < 120)
to
if (b[0] < 128)

I never saw anything higher than "silence frames". (124 and 125)

I know there are tones because I've heard them on a live stream from the same talk group.

For some reason Erasure, Silence and Tone were all disabled in p25p2_tdma::handle_voice_frame() even those there is code present to handle Silence frames in ambe.c

For the boatbod fork I've made some changes to log when AMBE TONE or AMBE ERASURE is decoded as well as performing a frame repeat for the erasure. So far there is nothing extra there to actually recreate the tone, but if you enable -v 10 at least you'll be able to see when a tone was broadcast.

 

[nokoa3116]

For some reason Erasure, Silence and Tone were all disabled in p25p2_tdma::handle_voice_frame() even those there is code present to handle Silence frames in ambe.c

For the boatbod fork I've made some changes to log when AMBE TONE or AMBE ERASURE is decoded as well as performing a frame repeat for the erasure. So far there is nothing extra there to actually recreate the tone, but if you enable -v 10 at least you'll be able to see when a tone was broadcast.

Thank you for taking actions for adding that feature. I pulled and built the project again, I looked at the stderr.2 file and seem to have some AMBE TONE on there for the police instance. There were no tones heard during the period I was testing through my Uniden scanner. For the Fire instance I had only one AMBE TONE outputted into that log file while during the testing period there were two tones played.

 

[boatbod]

((b0 == 126) || (b0 == 127))[/FONT]

Yeah, something is going on and I can't quite put my finger on it. On my local p25p2 system there is apparently one jurisdiction that is (occasionally) broadcasting tones but the b0 value has been coming in varied in the Erasure range (121-123) yet it is consistent and plays for about the right duration.

I've read the spec 'til my eyes hurt and am having indigestion on the different validation rules... in one place it says anything with b0 = 126,127 is a tone, but elsewhere it says to validate using u0-u3 (in the table describing the bit placement of ID, AD etc).

Still exploring with lots of logging. Waiting for real tones is tedious. Unfortunately capturing then for replay is harder still!

 

[slicerwizard]

It's simple - the spec is wrong.


First 6 bits of u0 are set; this limits b0 to range 1111000 - 1111111 (120 to 127)

Low 3 bits of b0 come from u3.

The 8 bit tone index is repeated 4 times across u1, u2, u3.

Therefore the low 3 bits of b0 are controlled by the tone index value and can assume any value from 000 to 111; therefore a tone frame b0 value will range from 120 to 127.


Verify tone frame by:

- first 6 bits of u0 are 111111

- last 4 bits of u3 are 0000

- frame contains four identical tone index values

- tone index value is valid

 

[boatbod]

It's simple - the spec is wrong.


First 6 bits of u0 are set; this limits b0 to range 1111000 - 1111111 (120 to 127)

Low 3 bits of b0 come from u3.

The 8 bit tone index is repeated 4 times across u1, u2, u3.

Therefore the low 3 bits of b0 are controlled by the tone index value and can assume any value from 000 to 111; therefore a tone frame b0 value will range from 120 to 127.


Verify tone frame by:

- first 6 bits of u0 are 111111

- last 4 bits of u3 are 0000

- frame contains four identical tone index values

- tone index value is valid

We reached the same conclusion, albeit at differing rates of comprehension.

Seems the first thing to do is check for a valid tone, and if that check fails then you go in to voice/erasure/silence processing.

I'm putting some stuff together now to see if I can get the decoding working reliably, then once that is in place someone (maybe not me) can come up with a good tone regeneration algorithm. [The issue I have is how to make the tone sound continuous, not a staccato series of 20ms discontinuous frames cobbled together.]

ETA: I pushed some c/c++ library changes to improve the handling of Tone Frames. It now appears to be decoding and validating these properly and will log a message (at -v 10) when a tone frame is detected along with the ID (freq) and AD (amplitude). Next step will be tone synthesis....

1543281405.617593 AMBE TONE ID=38, AD=85
1543281409.998759 AMBE TONE ID=32, AD=92

NOTE: if you want to try these changes you'll need to be on the boatbod fork and run the following commands:

cd ~/op25/build
git pull
make
sudo make install

 

[slicerwizard]

someone (maybe not me) can come up with a good tone regeneration algorithm. [The issue I have is how to make the tone sound continuous, not a staccato series of 20ms discontinuous frames cobbled together.]

Again, simple.

Sine waves are generated by audio sample = cos(angle) * gain; angle is stepped (increased) for each sample; step size is based on tone frequency and output sampling rate (8 kHz? 48 kHz?); just retain the current angle at the end of one tone frame and use it to start the next tone frame. Sin and cos functions don't seem to care when angles are greater than 360 degrees, but I'd keep it in the 0 to 360 range:

if ((angle += step) >= 360.f)
angle -= 360.f;

You may need separate data for each timeslot.

 

[boatbod]

Again, simple.

Sine waves are generated by audio sample = cos(angle) * gain; angle is stepped (increased) for each sample; step size is based on tone frequency and output sampling rate (8 kHz? 48 kHz?); just retain the current angle at the end of one tone frame and use it to start the next tone frame. Sin and cos functions don't seem to care when angles are greater than 360 degrees, but I'd keep it in the 0 to 360 range:

if ((angle += step) >= 360.f)
angle -= 360.f;

You may need separate data for each timeslot.

I'm well on the way to having a solution - the building blocks are in place, but it's getting late tonight. Will probably have to wait until later in the week to get back at it.