Results 1 to 11 of 11

Thread: Audio holes on 3600 systems, while operating secure

  1. #1
    Join Date
    Dec 21, 2011
    Posts
    4,416
    Thanks
    3,661
    Thanked 6,329 Times in 1,807 Posts
    Country: Canada

    Default Audio holes on 3600 systems, while operating secure

    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.


  2. #2
    Join Date
    May 30, 2012
    Posts
    226
    Thanks
    29
    Thanked 59 Times in 29 Posts

    Default

    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?

  3. #3
    Join Date
    Dec 21, 2011
    Posts
    4,416
    Thanks
    3,661
    Thanked 6,329 Times in 1,807 Posts
    Country: Canada

    Default

    Will do further testing as time permits and report back.

  4. #4
    Join Date
    May 22, 2012
    Posts
    678
    Thanks
    286
    Thanked 426 Times in 196 Posts
    Country: United States

    Default

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

  5. #5
    Join Date
    Dec 21, 2011
    Posts
    4,416
    Thanks
    3,661
    Thanked 6,329 Times in 1,807 Posts
    Country: Canada

    Default

    Quote Originally Posted by d119 View Post
    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.

  6. #6
    Join Date
    May 22, 2012
    Posts
    678
    Thanks
    286
    Thanked 426 Times in 196 Posts
    Country: United States

    Default

    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.

  7. #7
    Join Date
    Feb 04, 2012
    Posts
    1,854
    Thanks
    166
    Thanked 644 Times in 290 Posts

    Default

    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.

  8. #8
    bonusmalusturpis No Longer Registered

    Default

    Check the coverage type in the codeplug

  9. #9
    Join Date
    Apr 09, 2012
    Location
    Australia
    Posts
    896
    Thanks
    227
    Thanked 602 Times in 226 Posts
    Country: Australia

    Default

    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..



    Quote Originally Posted by Notarola View Post
    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.

  10. #10
    Join Date
    Dec 21, 2011
    Posts
    4,416
    Thanks
    3,661
    Thanked 6,329 Times in 1,807 Posts
    Country: Canada

    Default

    Quote Originally Posted by bonusmalusturpis View Post
    Check the coverage type in the codeplug
    Thanks, but this isn't the issue.

  11. #11
    Join Date
    Feb 04, 2012
    Posts
    1,854
    Thanks
    166
    Thanked 644 Times in 290 Posts

    Default

    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