Field Operator Manual

Brand: Secure Radio Communications Ltd, trading as Secure Radio Tagline: "Clear comms. Live control. One operation."

1. Purpose

This manual is for people who use Secure Radio in the field. It explains the core user experience in plain language:

1. how to get connected
2. how to transmit and receive
3. how to work with channels, private traffic, and talkgroups
4. how dispatch-requested video works when enabled
5. what to do when service quality is poor

2. Before You Start

Before using the app, make sure:

1. your device has network access
2. you have been provisioned on the correct tenant
3. your device and, if required, operator credentials are ready
4. you know which channel or talkgroup you are expected to use

For free-trial Day 0 setup, use Day 0 Free Trial Quickstart. In short: download the Android app from the trial-ready page or onboarding email, open the Android app login screen, tap the setup QR scan action, scan the Android/radio setup QR, choose your operator PIN, and then log in with that PIN. Do not scan the dispatch setup QR on the Android radio. The PIN is not sent in email and is not saved for you.

Free-trial radio checks are for low-friction self-evaluation. Treat real operational validation as part of Guided Evaluation or a managed rollout with customer SOPs, support routes, and success criteria.

If any of these are unclear, contact your tenant admin or dispatcher before going operational.

3. Logging In And Connecting

3.1 First Connection

On first use, the app or browser client should:

1. authenticate the device
2. connect to the service
3. prompt for operator identity if your organization requires it
4. join the default or selected operating channel

3.2 What “Connected” Should Feel Like

When connected successfully, you should be able to:

1. see the active channel or operating context
2. transmit when authorized
3. hear incoming traffic clearly
4. move between approved communication scopes without confusion

If the app looks connected but audio is not behaving correctly, treat that as an issue to report rather than assuming the system is healthy.

4. Core Operating Modes

4.1 Channel Mode

Channel mode is the default shared net. Use it for:

1. routine operational coordination
2. team-wide updates
3. general traffic meant for the shared audience

4.2 Private Or Selective Traffic

Use private or selective traffic when:

1. a message is intended for one user or a smaller group
2. you do not want to interrupt the main shared channel
3. the traffic is operationally specific

Selective traffic now has a defined reply-hold behavior:

1. if you receive a page / call alert, your reply is temporarily latched back to the sender
2. that private hold window is currently about 10 seconds
3. if either side continues the selective exchange, the hold window refreshes
4. if no one continues talking and the hold expires, the client returns to the open channel automatically
5. if you manually clear an active private hold, the session is dropped authoritatively so both sides return cleanly to the open net

4.3 Talkgroup Mode

Talkgroups are subgroups inside the broader tenant environment. Use them when:

1. only one function or subgroup should hear the traffic
2. you need tighter coordination inside a larger operation
3. your tenant admin has assigned the group to your operator identity for a specific purpose

If your organization requires operator identity, talkgroups should be treated as an operator-scoped feature. If you have not authenticated successfully, expect talkgroup access to remain unavailable.

Some talkgroups may be attached to an RF/DMR gateway. Those talkgroups behave more like a real radio bridge:

1. after pressing PTT, the client may show an RF keying or wait state
2. do not start speaking until the talk-permit cue or clear TALK NOW state
3. keep the first word deliberate because RF systems need time to key and settle
4. release PTT cleanly so the gateway can return to receive

4.4 Dispatch-Requested Video

Some tenants may enable dispatch-requested live video. If enabled, the workflow is:

1. dispatch sends a video request to your unit
2. you accept or decline the request
3. accepting does not start the camera yet
4. video starts only when you manually switch it on or press the in-app start control
5. when live, other participants in the same room may be told that video is available and can choose to watch it
6. your normal audio/PTT workflow continues during the video session

For supported hardware such as the Hytera P60, the side video switch is the preferred way to start or stop the live uplink after you have accepted the request.

5. Transmitting

5.1 Basic PTT Behavior

When transmitting:

1. confirm you are on the right channel or talkgroup
2. use PTT deliberately
3. wait for the transmit-ready cue if your workflow requires it
4. if the selected talkgroup is connected to DMR RF, wait through the RF keying state before speaking
5. speak clearly and avoid starting too early if your local SOP expects a talk permit rhythm

5.2 Main Audio Cues

The current cue package is intentionally small and consistent across clients.

The system now avoids many older non-essential sounds such as routine reconnect chirps or UI click tones so the operational cues are easier to trust.

5.3 Good Field Practice

Best practice:

1. keep messages short and structured
2. identify yourself or your unit according to your local SOP
3. avoid transmitting over active critical traffic
4. use the right mode for the message rather than forcing everything onto the main net

5.4 If Transmit Is Not Available

If you cannot transmit:

1. confirm you are connected
2. confirm you are on an allowed channel or talkgroup
3. confirm your operator permissions are valid
4. escalate to dispatch or your tenant admin if the issue persists

6. Working With Video Requests

6.1 When To Accept

Accept a video request when:

1. dispatch has asked for visual confirmation or scene awareness
2. the request is operationally legitimate
3. it is safe and appropriate to use the camera in your environment

6.2 When To Decline

Decline or question the request when:

1. the request appears unexpected or unsafe
2. the device cannot be used safely for video in the current situation
3. local SOP or privacy rules do not allow video in that context

6.3 Going Live

After you accept:

1. use the hardware video switch or the in-app start control
2. keep the device stable and frame what dispatch actually needs to see
3. continue normal voice discipline because audio remains live and important

6.4 Stopping Video

Stop video when:

1. dispatch tells you the request is complete
2. the operational need is over
3. continuing video would no longer be safe or appropriate

7. Receiving

6.1 What Good Receive Behavior Looks Like

Good receive behavior means:

1. incoming traffic starts promptly
2. words are clear and not clipped
3. the app remains stable during the full talkspurt

6.2 What To Watch For

Report issues if you notice:

1. the first few words are missing
2. audio arrives late or in bursts
3. speech sounds heavily clipped or robotic
4. the app appears connected but receive is unreliable

These symptoms are especially important to report if they happen repeatedly in the same location or under the same network conditions.

8. Moving Between Communication Scopes

Depending on your permissions, you may be able to:

1. switch channels
2. participate in talkgroups
3. receive private or selective traffic

Best practice:

1. always confirm which net you are on before transmitting
2. return to the expected operating net when directed
3. treat subgroup or private traffic as intentional workflows, not casual switching

In selective/private traffic, returning to the open net normally happens automatically when the hold window expires. If the client still appears stuck in private mode after traffic has clearly finished, report that behavior rather than working around it silently.

9. Working Under Poor Network Conditions

8.1 What You May Observe

Under poor connectivity, you may see:

1. delayed receive audio
2. clipped speech
3. short reconnects
4. inconsistent transmit or receive quality

8.2 What To Do

If communications quality drops:

1. confirm whether the issue affects only your device or multiple users
2. move to stronger connectivity if operationally possible
3. inform dispatch if traffic is being missed
4. avoid assuming the issue will resolve by itself during critical traffic

8.3 What To Report

When reporting quality problems, include:

1. whether you were on Wi-Fi or cellular
2. whether you were transmitting or receiving
3. whether the issue affected the start of speech or the full message
4. whether the issue happened once or repeatedly

10. Daily Operating Checklist

Before a shift or operational session:

1. open the app and confirm it connects
2. confirm your operator identity is valid if required
3. confirm the expected channel or talkgroup
4. confirm whether tenant video is in scope for the operation if your device supports it
5. perform a quick voice check if your SOP requires it

11. Safety And Discipline

This platform is designed for operational environments. Users should:

1. avoid unnecessary channel clutter
2. follow local radio discipline
3. use the correct communication scope
4. escalate service-quality issues early rather than normalizing them

12. Troubleshooting

12.1 I Cannot Connect

Check:

1. network availability
2. whether your device was provisioned correctly
3. whether you entered any required operator credentials correctly

12.2 I Can Connect But Cannot Transmit

Check:

1. whether you are on the right channel
2. whether your role allows transmit on that scope
3. whether another user is actively transmitting

12.3 I Hear Clipped Or Delayed Audio

Check:

1. whether the issue is isolated to your device
2. whether your current network is weak or unstable
3. whether dispatch or another user can reproduce it

12.4 I Am Unsure Which Net To Use

Do not guess. Ask dispatch or your supervisor which channel or talkgroup is correct for the task.

12.5 A Video Request Will Not Start

Check:

1. whether your tenant has video enabled
2. whether you accepted the request first
3. whether you switched video on after accepting
4. whether the device granted camera permission
5. whether you are still in the same room or operating context

12.6 The Setup QR Does Not Work

Check:

1. whether you are scanning the Android/radio QR, not the dispatch QR
2. whether the setup QR has expired or has already been redeemed
3. whether camera permission is enabled for the app
4. whether you are using the current trial-ready page or onboarding email

If the QR is expired, already used, or redeemed on the wrong client, ask support or the trial owner for a fresh activation path. If regeneration is not available, a new trial or manual provisioning may be required.

12.7 I Forgot My Trial PIN

The PIN is chosen during setup and is not sent by email. If you forget it, ask support or the trial owner to reset or reprovision the Android radio identity. The old PIN cannot be recovered from the app or onboarding email.

13. Escalation Path

Field users should normally escalate issues in this order:

1. dispatch or local supervisor
2. tenant admin
3. platform support or customer success through the customer’s designated support route

14. Bottom Line

For field users, the system should feel simple: connect, confirm the right net, transmit clearly, receive clearly, respond to legitimate video requests when enabled, and escalate any quality issue early. The platform is most effective when users combine its features with disciplined operational communications practice.