Audio holes on 3600 systems, while operating secure

[Mars]

Has anyone ever experienced unexplainable "audio holes" while operating on SZOL 4.1 (3600) systems, in ASTRO Secure mode?

I had a PS report this issue to me about a year ago and at the time, I brushed it off as being related to bad coverage or old firmware.

I did further testing and replicated the problem. Indeed, there are audio holes. It only happens on secure transmissions. Digital clear is NOT affected.

Here are specs:

Radio 1 - ASTRO Saber III 800 MHz
Firmware: R07.71.07 / N08.03.05
UCM: R03.58


Radio 2 - ASTRO Spectra Plus 8MB
Firmware: R17.01.01, DSP R17.01.00
Secure: R05.07.15

Both units are operating secure, with AES-256.

Radio 1 (AS3) can TX/RX secure, no problems.

Radio 2 (AS+) can TX secure, but some comms as received by Radio 1, are not heard. It can RX secure comms from Radio 1 all the time, no problems.

I've verified there are no alignment issues with Radio 2 and it is sending proper OSWs to the controller for a secure call. A channel is granted, but no audio is received by Radio 1.

Both radios are site-locked to the same Omnilink site.

Both radios can TX/RX 100% of the time on simplex, without any problems.

---

Now here's where it gets somewhat interesting: The PS user who contacted me about identical problems, is using a mixture of ASTRO25 portables/mobiles.

The radio I'm having problems with is also part of the ASTRO25 platform (AS+).

I'm seriously wondering if there's an undocumented/unconfirmed issue with the ASTRO25 firmware or UCM firmware.

Are there any other agencies out there who have had/having the same problem with TXing secure calls on a 4.1 Omnilink system?

FWIW, my tests were conducted in AES-256, but the PS agency is using DES-OFB. It doesn't seem to be algo-specific.

 

[Ice-T]

Curious issue. It would be good to confirm (via a third radio monitoring in the clear, perhaps) whether or not encrypted audio is indeed being transmitted by the Quantar after the channel grant. Have you confirmed it's happened on multiple voice channels, or perhaps it's the same one every time the issue occurs?

 

[Mars]

Will do further testing as time permits and report back.

 

[d119]

Can it be replicated on another system? Is it possible this system isn't keeping up with it's FSB's?

 

[Mars]

Can it be replicated on another system? Is it possible this system isn't keeping up with it's FSB's?

Can't replicate it on an alternate system. Asked for permission and was denied.

As for the sys admins not keeping up on the FSBs, I guarantee you they have not. They are criminally negligent in maintaining the system. It is falling apart and their staff have all quit. This same system has dozens of pirates on it -- and it's still used for public safety, if you can believe it.

 

[d119]

That's likely the problem. I seem to recall (though I cannot guarantee it) some FSB's related to secure audio issues for SZ4.1 in the last few years. It's important to keep up on that stuff! Last 4.1 I maintained was offlined a few years ago, though.

 

[Notarola]

I seem to remember a reference to something similar in an industry technical forum. The issue seems to be that the encrypted header is not being generated properly. This is why you would get encrypted p25 reception on a "clear" radio but nothing on the "encrypted radio". As far as the encrypted radio is concerned a non matching encrypted transmission is present. This also explains the intermittent occurrences as the header (HDU) most of the time contains the correct ALGID.

 

[bonusmalusturpis]

Check the coverage type in the codeplug

 

[MattSR]

The Encryption Sync info contained in the HDU is retransmitted every 360ms in the LDU2 frame. Any loss or corruption of the HDU means that you lose sync for 360ms maximum.

Losing a whole transmission indicates application layer issues in the radio itself..

I seem to remember a reference to something similar in an industry technical forum. The issue seems to be that the encrypted header is not being generated properly. This is why you would get encrypted p25 reception on a "clear" radio but nothing on the "encrypted radio". As far as the encrypted radio is concerned a non matching encrypted transmission is present. This also explains the intermittent occurrences as the header (HDU) most of the time contains the correct ALGID.

 

[Mars]

Check the coverage type in the codeplug

Thanks, but this isn't the issue.

 

[Notarola]

Matt I have looked through all my files to locate the original info with no luck. You are correct about the encryption sync being in both the hdu/ldu2. The issue if i remember is that when the transmision starts the repeater would generate the wrong type for the whole transmission. It may have something to do with the fact the repeater wasnt actually repeating the data recieved but rather it was "cleaning" it up (possibly decoding end reencoding) before retransmitting it. I really wish I had payed more attention to the post when I had read it.

Mars. if you can get DSD running maybe you can look at the header info and see if you can capture a bad transmission.

PS I am still working on OP25 its in a holding pattern