Squelch on Systems Saber opening delayed - why?

[radio-link]

Hi out there!

I am on programming a bunch of VHF Systems Sabers III for conventional use, and I am coming to some minor problems I could not solve yet.

The most annoying is, the squelch opens with half a second delay. No signalling, no MDC, no DOS - may Securenet be the reason? But it makes no difference strapping a mode to clear, the delay remains...

Another minor annoyance, the 04.00.02 RSS corrupts the data even while editing, when reaching a number of above 200 channels there shows up garbage in the codeplug, and I have to start from scratch or from the last good backup of the codeplug.

The good thing, Securenet (DES/DES-XL) is of much better audio quality than in the XTS5k radios! What did M do with those new radios? Did they implement it just on the fly, and the users should change to P25 ASAP, due to bad audio in Securenet?

Thank you for your ideas!

Ralph.

[oh2glg]

The most annoying is, the squelch opens with half a second delay.

After getting a Systems Saber III I found same problem too, but haven't found any solution for it.

I think it could not be due to receiver powersave, since it really doesn't have any save function as other convertional analog radios do, but it still is slow to open squelch.

If anyone knows what it is, I too would be happy to hear it.

[akardam]

Your unmute delay problem probably is in fact due to encryption being enabled. A quick 'n dirty experiment would be, disable "secure equipped" in the RSS, program the radio, and see if the delay goes away. This has been a known problem for some time now. It is of course mitigated by making sure you wait a second or so after keying up, to speak - not a bad idea on a repeated channel, especially if networked, and it does no harm on simplex, either.

[radio-link]

Your unmute delay problem probably is in fact due to encryption being enabled. A quick 'n dirty experiment would be, disable "secure equipped" in the RSS, program the radio, and see if the delay goes away. This has been a known problem for some time now. It is of course mitigated by making sure you wait a second or so after keying up, to speak - not a bad idea on a repeated channel, especially if networked, and it does no harm on simplex, either.

I will give it a try, but seems to confirm my guess. The problem is, the system here is in tactical use, trimmed to fast response times, and in fact you can press your PTT and start talking without having to be worried that only a single letter is lost, so those radios seem to be unusable for this purpose. I was hoping for the workaround blocking the important channels for Securenet capability and program some additional Securenet channels into the radios, but it does not help.

Here in Germany we usually do not use stuff like MDC, PL, DPL and other things making the radios slow and unresponsive. We want to push and talk "PTT", not push, wait, then talk "PTWTT" :-) This is it what makes TETRA very difficult to get accustomed to for experienced users of the analogue systems.

[AEC]

The first thing is not to strap the channels, then you can select clear or secure simply by 'throwing the switch' in whatever mode you are on.

Systems Sabers by nature have a somewhat slower RX response time when switching from TX to RX, although this might be a CON-X level problem as I have had CON-6 and 7 versions that were pretty fast, even when secure was active.

I never strap any channels to secure or clear, that's done to allow the 'dummies' to forget the settings and does the switching for them.

I've also noticed that when more channels are added, the ramp up time from cold boot slows, this may also contribute to slow TX/RX response times also, but not positive.

Trunked radios like the Systems Sabers don't have 'sleep' times that cycle the receiver as the trunked network polls the radios far too often to allow power save functions to be used, so the receivers should be active at all times.

But in reality, using any form of encryption will also slow down receiver repsonse time due to the module's decoding of encrypted audio, it does take a 'little' longer for the receiver to respond, and users on these systems should get in the 'habit' of holding the PTT down for 1/2 second, then talk, so the receiving station doesn't miss any traffic, or hears a clipped portion of a transmission...which could spell trouble if let's say 'NO' was taken as 'GO'....A missed syllable could mean disaster.

Even in clear mode, there's a slight 'lag time', it's less, but still present.

A quick check of the display will indicate if the conversation is encrypted or clear, then you can decide on which 'mode' to use based on that.

This is why I prefer to NOT slave my channels, as I may select to operate in the 'clear' on a secure slaved channel, but you can't do that when this option is selected.

If for some reason, a squad member loses a key while on site, having slaved channel operations means one man is out of the loop now, with no way to respond securely....bad choice as far as I am concerned.

[radio-link]

It was just a thought that strapping the channels that anyway need no encryption to clear may improve reponse time, but there is no difference at all.

For those who are interested, I finally got it. With F4-F6-F6 (beginning from the very first screen) there are some timers, and the secure unmute inhibit timer did the job. I have tried this already, but for some reason the menu does not keep its settings all the time. May have to do with tuning parameters, it is written to the radio reliably when first the tuning parameters are loaded and those are written back together with the codeplug.
My first test was setting all three timers to 0 (MDC, secure and MDC/secure) - then squelch was opening with no delay at all, but also in secure mode each receives transmission was beginning with a harsh noise, until decoding was in sync. So I started increasing the value, and with 48 I get reliable suppression of the securenet noise, but also a usable response in normal analog carrier squelch. The original (bad) setting was 95.
MDC is not used here in germany, so those settings could stay at 0.