Audible tones passing through DIU3000

[tone_P25]

Hi,

We have a system where we have been transmitting 1kHz tones through Motorola infrastructure for a fair while which has worked well. The tones are high pitched warning tones used in emergency situations. Recently we have upgraded to Tait P25 TB9100 bases and the tone doesn't get through. My understanding is that the IMBE vocoder in the Tait Gateway Console is blocking the 1 kHz tone. Fair enough, we are looking at ways around this.

My question is on the original Motorola setup. It also uses an IMBE vocoder (in the DIU3000) and the tones pass through that no problem. Why? Shouldn't the IMBE vocoder be removing them? The tones also pass when the frequency is changed to other audible ranges. DSP version in the DIU3000 is 3.18.

The setup is descibed below, the brackets represent the interface between units:

Analog 1 kHz tone generated -> AMU > (4 wire E&M) -> Motorola Centracom Gold Elite -> (4 wire E&M) -> DIU3000 -> (V.24) -> ASTRO TAC -> (V.24) -> Motorola Quantar base -> (CAI) -> XTS2500

Initially I thought the DIU3000 was interpreting the 1 KHz as a Tone remote Control signal (the 1 Khz tone was encapsulated in High level and low level guard tone) and then converting it to a digital Function REQuest (FREQ) to be interpreted at the terminal as a 1 kHz tone (does that make sense?) but I have since found out that the system works when the input tone frequency is varied (note, waiting for secondary confirmation on this)

Sorry if I've missed some fundamentals, not really my area, I've just been reading through manuals and this forum to make sense of what's going on.

Thanks for any assitance,

Tone_P25

[tone_P25]

Some additional information, I've measured the frequency of the alert tone and it is 1011 kHz. This is the same frequency as the P25 test tone. Could there be some relation here? How does the centracom process the 1 kHz test tone. Is it a control signal passed through the ACIM? Does it accept a 1011 kHz frequnecy from the AMU audio input which is converted to a control signal in the console?

Regards,

Tone_P25

[Wowbagger]

I've not worked at the system level like this, but I do know some things that will cause issues with a vocoder:
1) level. If the level is too hot, the vocoder will see clipping, and that distortion will confuse it.
2) Older vocoders: IMBE had a bug that DVSI fixed in AMBE, that caused issues encoding certain tones. Are all your devices using the newer AMBE vocoder?
3) multiple encode. If your system is encoding/decoding/re-encoding, that can cause issues.

Remember that vocoders are designed to handle VOICE, not tones. Much of the time systems that are supposed to handle both voice and tones have a separate tone encoder block that will detect tones, convert them into a different type of signaling, and bypass the vocoder.

[tone_P25]

Thanks for the response Wowbagger,

1) OK, will check this
2) No, all vocoders, are IMBE as descibed above. Interesting information from DVSI: the IMBE vocoder will generate a 1011 Hz tone when a certain bit pattern (as detailed in APCO P25 standard) is fed into the D/A side. My question was how this would work in the other direction, i.e. the A/D. Why does the terminal emit the 1011 Hz tone when the cosole operator presses a button to generate a analog 1011 Hz tone?
Motorola don't seem to know, from my research I think that they have either:
1/ Modified the IMBE vocoder to pass 1 kHz tones in the DIU3000; or
2/ Are interpreting the 1011 Hz analog wave form in the same way that the DIU3000 processes TRC commands (converts them to digital Frequency REQuests for transport via the V.24 protocol). However instead of generating a Frequency REQuest the DIU3000 generates the 1011 Hz bit pattern which will be interpreted at the terminals IMBE vocoder as a 1011 Hz tone. Or maybe a command similar to the Frequency REQuest is sent out of the DIU3000 which sets a switch in the Quantar base to genertae the 1011 bit pattern from there.

Anyone else have an idea on this, surely with the amount of knowledge on this forum someone else has a view.

3) Yes, we've noticed that when the signal goes through alot of D/A's, A/D's the quality drops. Good observation.

Another interesting point, the IMBE vocoder will pass tones below 400 Hz (according to Tait). On this, 400 Hz triangular wave sounds higher pitched than sine wave. Why?

[tone_P25]

Some follow up on my issue that may be of help to someone some day when they are trolling through this forum. I've come to the conclusion that what is happening is that the DIU3000 is detecting the 1000 Hz tone (from the analog input side) and then generating the "1011" bit pattern (at the digital output). The bit pattern is detected by the terminal which makes it generate the 1011 Hz tone locally.

Reasons for this conclusion are:
- The measured input frequency at the console was 1000 Hz, while the measured frequency at the receiving terminal is 1011 Hz (happens to be the P25 1011 test tone frequency). If the analog tone was being passed through the network then the frequency would not change by 11 Hz.
- 1011 test bit pattern has been part of standard functionality of the IMBE vocoder since it was implemented
works on any IMBE terminal. In our network a range of different manurfactuer IMBE terminals are used and the tone works on all of them.


Cheers,

Tone_P25

[sim]

Can I know what is the number of bits to transmit a 1011Hz test tone pattern from the base to radio to perform a reeive BER test? Does the 1011 Hz tone pattern uses both the LDU's which comes to 3456 bits? Im comparing it to o.153 test pattern which each frames consisting of 511 bits.

[MattSR]

This is how all lossy codecs work - not just with pure tones but with voice information as well. The IMBE codec, being digital, introduces quantisation when making its pitch estimations - therefore you will find that all tones from (just as an example) 980Hz to 1020Hz will be reproduced by the codec as a 1011Hz tone. Theres only a limited number of bits in each 88 bit IMBE voice codeword to represent pitch information, so the whole voice spectrum between 100-3000Hz is broken up into pitch estimates which are represented as 208 separate bands.

The behaviour you describe is to be expected for any tone going through the codec.

If you would like more information, please read the IMBE patent (US Pat 5,870,405) page 24. Link here --> http://www.google.com/patents?id=9dEEAA ... ch&f=false

Cheers,
Matt

Some follow up on my issue that may be of help to someone some day when they are trolling through this forum. I've come to the conclusion that what is happening is that the DIU3000 is detecting the 1000 Hz tone (from the analog input side) and then generating the "1011" bit pattern (at the digital output). The bit pattern is detected by the terminal which makes it generate the 1011 Hz tone locally.

Reasons for this conclusion are:
- The measured input frequency at the console was 1000 Hz, while the measured frequency at the receiving terminal is 1011 Hz (happens to be the P25 1011 test tone frequency). If the analog tone was being passed through the network then the frequency would not change by 11 Hz.
- 1011 test bit pattern has been part of standard functionality of the IMBE vocoder since it was implemented
works on any IMBE terminal. In our network a range of different manurfactuer IMBE terminals are used and the tone works on all of them.


Cheers,

Tone_P25

[Wowbagger]

This is how all lossy codecs work - not just with pure tones but with voice information as well. The IMBE codec, being digital, introduces quantisation when making its pitch estimations - therefore you will find that all tones from (just as an example) 980Hz to 1020Hz will be reproduced by the codec as a 1011Hz tone.

The reason 1011 Hz is used, not 1000, is that 1011 Hz can be exactly represented by the IMBE vocoder.

With respect to the OP's questions:

There is an APCO standard bit pattern for the 1011Hz pattern that fully specifies every bit of both LDU1 and LDU2. However, this means you can only use the APCO standard pattern in conventional talk-around mode, as the pattern ALSO specifies the talk group data in LDU1.

The part of the data that specifies the voice frame itself is also specified in the APCO standard, and you can conduct a test using that bit pattern as the voice payload while generating the rest of the data (trunking data, encryption, etc.) normally - the Aeroflex 2975 and 3900 family both do this.

The 511 bit pattern you mention is ALSO specified in the APCO standard - it is a standard pseudorandom pattern generated by a linear shift feedback register. However, that pattern has absolutely NO APCO 25 framing data - no header, no sync bits, no framing data - it's just 511 bits of data with a perfect autocorrelation function (that is, the only match for the pattern is with zero bits offset - you cannot offset it by other than a multiple of 511 bits and get a match).

Normally, when computing BER, if you are using the 511 pattern, you use all the bits. If you are computing for the APCO standard patterns with framing, you ignore the sync bits.

[MattSR]

This is how all lossy codecs work - not just with pure tones but with voice information as well. The IMBE codec, being digital, introduces quantisation when making its pitch estimations - therefore you will find that all tones from (just as an example) 980Hz to 1020Hz will be reproduced by the codec as a 1011Hz tone.

The reason 1011 Hz is used, not 1000, is that 1011 Hz can be exactly represented by the IMBE vocoder.

Yes. Thats exactly what I was saying. Thanks for paraphrasing. As I already said, due to the pitch estimation, and the limited number of bits used to convey pitch information, theres only 208 separate tones that can be exactly represented by IMBE. The codec will pick the nearest one and in this case, it just so happens to be near the test pattern tone.

[boteman]

Very informative discussion. Where might I find a list of all tones, such as 1011Hz, so that I can set my alert tones to match so that they don't sound "underwater"?

For example, for the alternating high-low alert tone I can encode 1011Hz for the high tone, but need to know what a good choice for the low tone would be.

Thanks.

[Astro Spectra]

@tone_P25, so did you change your alarm tone to 1011 Hz and try to see if that works OK with the TB9100?