SoftRadio Handbook 2015/16 - Testadvance · Motorola MotoTrbo DM4600/01 and DM3600/01 ... Nexedge...

Rev. A.01 6/08/2015

SoftRadio Handbook 2015/16 Intelligent, distributed Two-way Radio Management System

Testadvance pty/ltd

SoftRadio Handbook 2015/16

Copyright © testadvance pty/ltd 2010-15 Page 1 of 65

[email protected]

Tel: 1 300 559 376 (Australia)

Int’l: +61 3 8819 3591

www.testadvance.com

Disclaimer

The information herein is provided solely for the purpose of concept or product description and is not to be deemed as a statement of guaranteed properties. This document is subject to change without notice. While this document and

all the information contained herein and/or referred to have been carefully checked by testadvance, deviations cannot be completely ruled out. In the case errors are detected, the reader is kindly requested to notify testadvance.

In no event shall testadvance be responsible or liable for any loss or damage resulting from the use of the information provided herein or the application of the equipment.

© 2010 – 2015 by testadvance pty/ltd.

All rights reserved. Where materials and other related content are provided by, sourced from or referenced to our OEM partner LS Elektronik AB, the associated copyrights of LS Elektronik AB are recognised.

We kindly thank LS Elektronik AB for their support in creating this handbook.

No part of this document may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of testadvance pty/ltd.

mailto:[email protected]

http://www.testadvance.com/



Contents

1. Introduction ...................................................................................................................................... 4

2. The SoftRadio RMS ........................................................................................................................... 6

3. Modular design, distributed intelligence .......................................................................................... 9

Why a modular RoIP ‘platform’? .................................................................................................... 10

Key benefits of the SoftRadio modular RMS ................................................................................... 11

4. The SoftRadio Console .................................................................................................................... 13

Core functions ................................................................................................................................ 15

Basic operation of a radio-call ................................................................................................ 15

SoftRadio ‘Help’ function ................................................................................................................ 17

Key settings .................................................................................................................................... 18

5. SoftRadio Virtual Control Heads ..................................................................................................... 21

Motorola TETRA.............................................................................................................................. 21

MTM800E & MTM5200/5400/5500 ....................................................................................... 21

MTM700/800 (non-E-type) ..................................................................................................... 22

Motorola MotoTrbo DM4600/01 and DM3600/01 ........................................................................ 23

Motorola GM/CDM-Series .............................................................................................................. 23

GM360 (GM160/338/338LS/339/660, MCX760, CDM1550/1550LS+; PRO7100/7200) ......... 24

CDM1250 (PRO5100) .............................................................................................................. 24

GM1280 .................................................................................................................................. 24

GM380 (GM398/399) ............................................................................................................. 25

Kenwood......................................................................................................................................... 25

Nexedge NX720/820 & TK-7360/8360 .................................................................................... 25

TK-7180/8180/7189/8189 ...................................................................................................... 26

Hytera MD785/788 DMR ................................................................................................................ 26

ICOM IC-M423/M424 Marine Radio ............................................................................................... 27

Sepura SRM2000, SRM3500, SRG3500, SRG3900 ........................................................................... 27

Basic Settings for VCH Display ........................................................................................................ 27

6. The RoIP Interface Unit ................................................................................................................... 30

General Purpose RIU ...................................................................................................................... 31

Custom applications ............................................................................................................... 33

RIU with Virtual Control Head ........................................................................................................ 33

Special-purpose options and functions........................................................................................... 34

RIUs for non-radio devices .............................................................................................................. 34

SoftLine IP-interconnect for Radio and Control Head extensions ................................................... 35

SoftLine core functions ........................................................................................................... 36

Set-Up for RoIP Interface Units ....................................................................................................... 37



7. SoftRadio Options & Add-ons ......................................................................................................... 38

SoftRadio CrossPatch ...................................................................................................................... 38

CrossPatch Features and functions ................................................................................................. 39

GroupSend ...................................................................................................................................... 40

Receive Diversity – ‘Diversity Voting’ ............................................................................................. 40

Radio Call Options and CallLog ....................................................................................................... 41

Selective Calls & Speed Dial .................................................................................................... 42

Local CallLog and Tone Decoder ............................................................................................. 42

PhoneConnect (PSTN, GSM/3G, SIP) .............................................................................................. 43

I/O Control for remote I/O ports .................................................................................................... 44

Productivity Enhancements ............................................................................................................ 45

MapView ........................................................................................................................................ 45

8. VoiceLog ......................................................................................................................................... 47

9. SoftRadio StatusLog & ObjectLog ................................................................................................... 49

10. IP-RoIP Networks ............................................................................................................................ 51

Understanding the impact of network topologies .......................................................................... 52

Networks within one Local LAN subnet (UDP) ........................................................................ 52

Networks beyond a local LAN subnet (UDP and TCP) ............................................................. 53

Quality of Service comparison UDP vs. TCP/IP ........................................................................ 54

Mixed RoIP network topologies ...................................................................................................... 54

Type A: Consoles on one local LAN subnet, radios local and non-local................................... 55

Type B: Radios on one local LAN subnet, consoles local and non-local .................................. 55

Type C: Both radios and consoles local and non-local (type A & B combined) ....................... 56

Integrating TCP connected radios and consoles ............................................................................. 56

SoftRadio Network Repeater .................................................................................................. 57

SoftRadio Radio Server ........................................................................................................... 58

Example configurations .................................................................................................................. 58

11. SoftRadio System Administration ................................................................................................... 62

SoftRadio Network Monitor ........................................................................................................... 62

SoftRadio Network Logger .............................................................................................................. 64



1. Introduction

Many organisations rely on two-way radio to communicate with users that are beyond the reach of telephone and IT-Networks. Radio networks often need to distribute base-radios geographically to provide the required coverage. This places limitations on how they can be accessed, and by whom. In other cases, multiple base-radios may be co-located to provide the required access and capacity. Yet this can limit RF-performance and coverage. Repeaters are often used to extend coverage, but have limitations of their own.

With Radio-over-IP (RoIP), radios can be connected via IP-Networks (LAN, WAN or the Internet). Users can access radio-communications from devices such as a PC or laptop. Operators or dispatchers no longer need to physically access a radio to use it. With RoIP, radios become in effect nodes that can be distributed geographically without the typical limitations of access and control.

While coverage and capacity are traditionally predominant concerns, operations increasingly need to consider how efficiently and effectively information can be processed. After all, extracting relevant information, and making and communicating decisions is the fundamental purpose of communicating in the first place. Operators need to be able to aggregate information from a variety of sources, and process information effectively and efficiently – a crucial aspect of informed and timely decision making.

Radio-communications cannot be simply ‘plugged in’ to other systems. Information needs to be extracted before it can be utilised. Only once it is understood can a decision be made, and the outcomes of that decision communicated to the recipient. Yet extracting and consolidating information from communications is not an efficient use of resources. Operators should be able to focus on those areas and tasks that deliver the greatest returns to the organisation – deciding and informing.

It stands to reason that the value a radio network delivers is determined by how well it enables operations to utilise information. As no two operations or work-forces are the same, a radio network is most cost-effective where it can be managed and used in a way that fits that specific organisation’s needs, objectives and constraints. Now and in the future.

Figure 1 Example integrated SoftRadio Radio Management System



The SoftRadio Radio Management System (RMS) allows organisations to implement a radio network that best fits their needs and circumstances. Operators and users in turn can focus on the core tasks of exchanging and using information. Information is clear and functional, and only as complex as needed. Radio communications can be accessed from a PC anywhere within the organisation. Radios can be located to optimise both coverage and capacity. Existing radio-assets and infrastructure con be integrated, and their useable life-span extended. RMS functions can be used, allocated and added as and when needed. For example operators can be given access to embedded applications such as voice-logs and non-radio channels such as VoIP phone. Common applications such as e-mail and office tools are available on console.

By providing such a high degree of fit and ‘evolve-ability’, SoftRadio furthers functional integration. Fitting, in other words sensible levels of integration furthers operational awareness. For example operators can view information across the radio-network, and monitor and share work-loads with their peers. Supervisors and managers can as needed monitor the radio-network from their own PC. Organisations in turn can incorporate radio and non-radio systems under one, common operational structure.

SoftRadio RMS operates on standard Windows PCs, for example a desk-top, touchscreen, laptop or tablet (Windows XP, 2000, Vista or Win7/8). Using commonly available devices and technology is very cost-effective, simplifies maintenance and delivers versatility. Operation requires little more than common ‘PC skills’. Radios and devices are ‘nodes’ on an IP-network, and administration, troubleshooting and maintenance can be done in collaboration with an organisation’s IT department.

SoftRadio is inherently robust. As it does not rely on a central or platform SW, there is no single-point-of-failure. If one node ‘goes down’, all other nodes can continue to operate.

Figure 2 Focussing on information and situational awareness

Clear, concise information Efficient & effective

Situational Awareness



2. The SoftRadio RMS

SoftRadio is a modular Radio Management System (RMS) applying the principle of distributed intelligence and processing. SoftRadio does not require a central ‘platform’. Each console and each device-node can operate independently of others.

At the core of a SoftRadio system or network is the RoIP channel. A RoIP channel is created by ‘attaching’ a two-way radio to an IP-Network via a RoIP Interface Unit (RIU) at one end, and a Windows PC with a SoftRadio console application at the other end. Both are in effect nodes on an IP-Network. The SoftRadio console incorporates the ‘system intelligence’ needed to manage communications with a node, be it a radio or other applicable device. The console device panel provides the operator with status information and control functions such as. PTT. The soundcard in the PC provides the analogue/ digital conversion of the analogue audio signal and the console application manages the transport over IP. At the radio end, the RIU converts the analogue signals from and to the radio into IP-data, and vice versa.

Figure 3 System concept

Figure 4 Radio channel over IP

SoftRadio Console Radio & Interconnect

IP (LAN/WAN)

AUDIO & PTT

Windows PC

RoIP Interface Unit (RIU)

AUDIO & PTT

Local Network

Operator Consoles

Radio resources

Extended Network

System Admin/Applications

Radio users

Internet/ WAN



SoftRadio RIUs are available in general-purpose, radio-specific and special-purpose configurations. General-purpose RIUs connect Audio/PTT from any two-way radio via RoIP. Radio-specific RIUs allow to control a radio via an interactive replica of a radio’s control head on the console, the Virtual Control Head (VCH).

Radio channels can be simply added by adding a radio and RIU to create a new radio-node. The new radio-node is made available to the consoles via a simple update to their configuration files. Similarly, additional consoles, or operator-nodes are readily added. In the SoftRadio system, each node (RIU, console or other relevant SoftRadio device) is identified by a unique ID, up to a total of 240 in a standard system.

A SoftRadio network can also be extended geographically, for example to make use of another site’s LAN, to locate radios across a corporate WAN, or even to access remote radios via the Internet. SoftRadio network devices are used as ‘building blocks’.

Figure 5 Radio/RIU with VCH

Figure 6 Building and expanding a RoIP Radio Network

Device Panel & VCH

Primary Local LAN Subnet (UDP)

Intra-network (TCP)

Internet/ WAN

SoftRadio Network Monitor

Network Repeater

SoftRadio Operator Consoles

Inter-network (TCP)

Radio Server

Second TETRA Network Location Primary Analogue and TETRA

Network E.g. Remote

Airband Radio



Operations can for example start with a simple core application and expand this network over time, integrating other networks and locations as and when feasible. SoftRadio network devices also allow organisations to retain and extend the use of existing assets. (Described in detail in Section 10)

SoftRadio RMS further allows to add functionalities beyond basic radio-communications, such as applications for remote-control, logging, task-management, and system administration. SoftRadio’s modular design allows to add these functionalities as and when it makes operational and indeed financial sense. Examples include:

• Migrating to new radio-formats or technologies while keeping existing radios in operation • Adding functions such as CrossPatch, GroupSend, Selective Calls and Diversity Voting • Adding system-wide applications such as voice-logging, activity management or mapping • Adding system-administration tools to the growing network

SoftRadio allows to add functionalities and capabilities in a manner that fits with the operational needs and constraints, such as time and budget. As the intelligence is distributed within the system, adding capability requires no system-wide upgrades or major re-configuration:

• Console Add-ons are added to one or more consoles as options, the additional functionality is seamlessly integrated in the console’s standard device panel

• Radio applications are added when and where needed, and only the affected consoles or devices may require an incremental upgrade, e.g. adding the RSSI capability to the selected RIUs

• System applications are typically added at a central location, and any ‘front-end’ console functions or device-panels are again seamlessly integrated



3. Modular design, distributed intelligence

Radio-communications are used to provide the timely exchange of information. While this may seem obvious, the value gained from radio-communications depends on that organisation’s unique needs, objectives and constraints. It stands to reason that the overriding goal must be to provide the best balance between capabilities (needs, objectives) and constraints (budgets, schedules, resources, infrastructure etc.). Future needs, for example from growth and new technologies also need to be considered. As organisations evolve, so too must radio infrastructure and operations be able to evolve.

Achieving optimal fit and hence cost-benefit, requires more than meeting current technical and organisational requirements. It also requires the ability to work towards the organisation’s context and objectives and how they influence cost-benefit. And as no technology or organisation can stand still, a truly fitting solution is designed with the foresight and flexibility to support future needs.

SoftRadio’s modular Radio Management System (RMS) brings together proven, cost-effective devices and technology with purpose-built RMS modules. Customers can configure their own fitting RMS from a portfolio of modules. Minimal upfront engineering is required, providing a high level of confidence that requirements are met within a defined budget and schedule. Operations can configure and reconfigure the system themselves, without needing to change the system-architecture. Organisations can maximise use of existing assets, better mitigate risks, and further security of investment and long-term ROA.

Figure 7 Overview SoftRadio Modular RMS

Client Operations

VoiceLog Object & Status Log Server Applications

System App’s & Admin

CrossPatch GroupSend

Console ‘Add-Ons’

CallOptions

System Applications Console ‘Front-Ends’

Internet/ WAN

Radio Nodes

Diversity Voting (RSSI) MapView (GPS Data)

Console Nodes

SoftRadio RMS

Console Core Functions

Network Repeater & Radio Server

Network ‘Building Blocks’



Why a modular RoIP ‘platform’?

Modularity has been successfully applied in a wide range of fields, from furniture to space-exploration. The challenge lies in balancing capability and adaptability against direct and indirect costs. Good ‘fit’ often involves costly custom design. As costs are a key concern, most radio networks today are instead built using Common-Off-The-Shelf (COTS) devices. These solutions initially seem less costly, yet when productivity is factored in, cost-benefit often deteriorates over time. COTS devices are designed for a wide range of needs and interests, and how they fit a specific organisation’s needs and objectives is always a compromise.

To overcome this, organisations often look to a ‘platform solution’. A platform RMS resembles in many ways a custom solution and may have similarly high up-front costs. These often arise from a perceived need to foresee future requirements that by nature are uncertain at the time of design. A typical approach is to build-in a high level of ‘configurability’. Configurability is the ability to change or amend the predefined capabilities or features. Yet this does not solve the problem, it merely distributes it.

Modularity on the other hand is the ability to include, exclude and rearrange capabilities independently, and without altering the system itself.

A Radio Management System is modular where:

• Architecture and design rules govern how a functional system is assembled from modules • Functionality is deconstructed into discrete capabilities assigned to individual modules • Each module is ‘independently intelligent’ • A functional system can be recreated and adapted by re-arranging or adding modules • The inherent design and engineering ‘know how’ is accessible, rather than prescriptive

Figure 8 Positioning of a genuinely modular RMS



Key benefits of the SoftRadio modular RMS

SoftRadio enables operations to use broadly available, cost-effective equipment to build and manage their radio network within a common system-architecture. RoIP is an ideal ‘backbone’. It uses proven, broadly available and highly cost-efficient IP-technology, devices and infrastructure. This removes constraints that unnecessarily limit a customer’s ability to build a system of their choice. Operations can add, combine, relocate, and/or re-use assets and resources as needed or desired. They can tailor the RMS to suit their specific work-structures, infrastructure and applications. Organisation can meet changing needs and circumstances without ‘upgrading’ or redesigning the system itself. Customers can choose to do so themselves, in cooperation with the supplier or outsource the work entirely.

Simply put, SoftRadio gives organisations given greater control and choice. It combines the fit of a custom designed system with the ease and cost-efficiency of off-the-shelf components.

Removing constraints – realising opportunities

SoftRadio allows organisation to build up complex radio networks over time, starting from even the most basic configuration – a single radio node and a single operator node. There is no need to define all future, and hence uncertain requirements. Engineers can add capabilities as and when needed. SoftRadio also supports customisation, using the same modular approach. A custom function or device is simply added to the system as a custom ‘design rule’ within the same architecture rules.

SoftRadio’s individual modules can interoperate under a wide range of circumstances. As the architecture is based on design rules rather than specific functional requirements, implementation does not require comprehensive requirements engineering. Instead, engineers can focus on those areas that further their and the organisation’s objectives. And as design engineering is much less involved, budgeting and development cycles are shorter, and uncertainty and risks are minimised.

Figure 9 Implementing a ‘best fit’ Radio Management System

System Modules

System App’s

NetworkModules

Console Modules

Radio Control

Radio Channels

SoftRadio: Repository of Capabilities

System Admin

Front-ends

Logging Resource

Mgt.

Integrated Network

Dispatch Consoles

Radio Control

Radio Channels

Customer System

•Operations•Business•Technology

Context

•Infrastructure•Resources•Users

Integration•Capabilities•Capacities•Usability

Functionality

Requirements Specification



A simple example of a modular system is a wardrobe system. It may comprise a standard frame, doors in different sizes and finish, and various internals. Its architecture governs how these are assembled. In SoftRadio, proven design-rules define how individual modules realise capabilities, such as creating a RoIP audio channel. SoftRadio’s system-architecture in turn governs how modules can be configured, changed, added and augmented. Radio channels and consoles can be added and re-configured. Existing assets can be re-used, extending their life-span and improving ROA. Different radio formats, devices and models are all integrated using the same design rules. Non-radio communication channels such as IP-phones can be integrated. Complex networks can be structured into sub-networks, for example to support different work-structures and geographies. Log-, radio-, and other system-data can be shared outside SoftRadio. And all the above can be implemented when and where ‘it makes sense’. The result is a highly ‘fitting’, and (as best possible) ‘future-proof’ two-way radio network.

Modular systems incorporate ‘know how’ as capabilities, not as pre-defined procedures

Distributed intelligence is a key in a modular RMS. No central platform SW or application is required – each node, RoIP Interface Unit (RIU) and console can operate independently. SoftRadio allocates capability and ‘machine intelligence’ purposefully across the modules of the system. As well, substantial know-how is built in to the system. This know-how includes technology expertise (e.g. radio-protocols, device-interfaces, etc.), as well as extensive experience across a variety of ‘real life’ applications.

Sustaining the long-term value of radio-systems and assets

Arguably one of the greatest benefits of a modular RoIP system is that it is highly efficient in incorporating learnings, essential to sustaining cost-benefit. This can be as simple as re-organising nodes and resources to optimise work-flows, or as complex as implementing interoperability across formats and geographies – all while maintaining current operations. External needs, or ‘drivers’ such as new technology or productivity initiatives are readily accommodated. As intelligence is distributed, delivering new capabilities does not require comprehensive changes or upgrades. Often all that is needed is a firmware update on the relevant modules. Ongoing development of SoftRadio ensures radio-communications continue to meet the needs of operations and deliver measurable returns to the business.

Figure 10 SoftRadio ‘evolution’ cycle

Functional Design

Design Rules

Relevance

Enhancing Capabilities

Functions System

ModulesSystem App’s

NetworkModules

Console Modules

Radio Control

Radio Channels

•Technology•Infrastructure

Context

•Capabilities•Usability•Configurability

Needs

Repository of Capabilities Customer Needs Devices & Technology Applications

Evolution

SoftRadio: Evolution Cycle

Learnings



4. The SoftRadio Console

SoftRadio is a Radio Management System (RMS) with distributed intelligence. Each SoftRadio console includes all the system intelligence needed to manage communications. No ‘platform SW’ is required and hence no single point-of-failure exists. Each console has the same fundamental capability. Consoles operate independently of each other, ensuring reliability and realising cost-efficient redundancy. Node management is simple, flexible and robust via simple, distributed configuration files. This makes it very easy to allocate and re-allocate resources, add devices or upgrade to new radio types.

SoftRadio is inherently robust. If one node ‘goes down’, all other nodes continue to operate fully. SoftRadio allows to quickly mitigate a node failure, e.g. by patching calls to other radios, or by taking over calls from a ‘down’ console. SoftRadio is simple and intuitive to use. Operators can configure the console to best fit their specific context and preferences, furthering productivity. The Radio-over-IP (RoIP) ‘backbone’ makes best use of existing IT- infrastructure and allows greater integration with operations. SoftRadio supports a range of add-ons, options and integration with non-radio communications and applications.

SoftRadio runs on a Windows PC, touchscreen, laptop or tablet (Windows XP, 2000, Vista or Win7/8) – no specialised terminals are required. Standard ‘off-the-shelf’ devices are very cost-effective, easy to maintain and highly versatile. Operation requires little more than common ‘PC skills’. Organisations can easily configure which other applications operators can access on their console. For example an internal VoIP telephone system, or a resource management system. Different tiers of access can be assigned, for example limiting operator consoles while allowing supervisors and administrators wider access. The SoftRadio console is available in two versions. A SoftRadio XL console can manage a maximum of 30 devices which can be organised in tabs. The SoftRadio standard version handles up to 8 devices.

With RoIP, a communications channel is created by ‘attaching’ a two-way radio to an IP-Network via a RoIP Interface Unit (RIU) at one end, and a Windows PC with a SoftRadio console application at the other end.

The SoftRadio application creates a device panel on each console. Each radio or node has its own panel within the device panel. All operators on all consoles can view and monitor the status of each radio or node they have been granted access to. Which nodes can be accessed can be configured individually for each console, in groups of consoles, or system-wide. Nodes that are not configured are simply not displayed. Console commands are executed via a mouse-click, hot-key, touchscreen, or combinations thereof.

Figure 11 End-to-end communications using SoftRadio console (Audio/PTT)

IN (Mic) OUT (Spkr)

External PTT

PTT AUDIO ON

Radio 1

Radio 2

Communication



The device panel provides status information for all radio and other device nodes on the network. Each console receives real-time updates such as incoming and waiting calls, as applicable alarms, and other information. Each operator can take an incoming call and send on any radio they have access to. Activities of other operators such as a PTT are displayed across the consoles on the system. For example when one operator is using a radio to send, this radio is locked for other users until the transmission is complete. Operators can configure the layout and display of information to suit their needs and preferences, furthering situational awareness. Figure 12 shows different device panel configurations, and a Virtual Control Head for a Motorola MTM radio.

Incoming audio is available to all operators simultaneously and any operator can take an incoming call. Operators can select whether to listen a radio via the green speaker button. Operators can monitor certain radios, such as Air Traffic Control, or supervisors can monitor radio traffic to redeploy resources as needed. Audio can be turned on or off at any time, for example to mute monitored radios when taking a call.

Audio is captured and reproduced using internal or external ‘soundcards’ recognised by Windows. This provides a high level of flexibility. For example a dispatcher with a stereo headset can monitor incoming radio calls on the left channel, while maintaining a phone conversation on the right channel. Commercial high-end soundcards with equalisers and filters can be employed to improve audio quality. Outgoing audio is by default not reproduced across the operator consoles – operators cannot hear what other operators are transmitting. There is the option in the set-up to allow operators to hear the outgoing audio from other consoles. This can be useful where operators are distributed across different locations.

A SoftRadio XL console allows one operator to handle up to 30 radio-communications simultaneously. In a network with more than 30 radios, different operators will typically handle different groups of radios on different consoles. SoftRadio XL allows to organise each group of radios on each console. This allows for example operators to share workloads across groups as no ‘hard’ boundaries need to be implemented. Or if needed, consoles can be limited to access only nodes within the designated group. For smaller networks, or networks with heavy traffic on fewer radios, the SoftRadio standard version handles up to 8 devices.

Figure 12 Example of SoftRadio XL device panel with tabs and a VCH

SoftRadio XL (vertical layout) Example Virtual Control Head (Motorola MTM5400, Kenwood NX720/820)



Node management is simple, flexible and robust. Console access is configured using an ‘.ini’-file that includes the ID, IP-Address and network access (UDP/TCP) of the nodes. ‘.ini’ files are created via a utility supplied with SoftRadio. Suitably trained system administrators can edit .ini files remotely using a simple text-editor. Nodes are readily changed, reconfigured, added or removed, simply by editing the file. Examples may be adding radios, maintenance, or for situational re-deployment of resources.

SoftRadio also provides Virtual Control Heads (VCH) for many radio types. A VCH allows to control a remote radio using an interactional replica of the radio’s control head displayed on the console. SoftRadio also supports a range of add-ons and options that enhance functionality and productivity of the RMS. These can be added as, where and when needed. VCH, add-ons and options are described in subsequent sections.

Core functions

Figure 13 shows a SoftRadio XL device panel for 3 connected radios, three tabs (groups of nodes/devices) and a basic device panel. The device panel is configured with a single speaker button, a wait button and the PTT button. The caption bar displays the name allocated to the radio or node. The channel number field displays information from the radio’s front panel. Typically the selected radio channel is shown, but the content displayed can be customised for a range of radio models.

Basic operation of a radio-call

• Receiving - Incoming audio

A yellow caption bar indicates that audio is being received on the radio (Squelch in the RIU has opened). Activating the speaker button activates the audio output on the selected device, for example a headset.

• Sending (PTT)

To send, the operator selects a radio and presses PTT. The currently selected radio is shown by the red arrow. PTT can also be executed via the spacebar on the keyboard, an assigned hotkey, or an external PTT device such as a foot-switch.

Figure 13 Basic device panel functions

Speaker Button

Yellow Wait Button

Channel/Info Field

Caption Bar

Send Button (PTT)

ACTIVE Radio

Group Tabs

Motorola MTM700

Motorola GM380

GM1280

Test

561



• Another console Sending (PTT) – radio is ‘locked’

When one operator sends, other consoles are blocked from sending on that radio. The caption bar for that radio is highlighted in orange indicating that an operator one another console is sending on that radio. The operators on the other consoles can still listen to the received audio by selecting the green speaker button.

• Selective call

A blinking green colour on the caption bar of the radio indicates that a selective call is being received.

• Call waiting / resend

Either a ‘wait’ or a ‘resend’ function can be displayed in the device panel. Which is active is selected in the settings menu. The ‘wait’ function allows an operator to put a call on ‘wait. An audio signal is sent to the caller indicating the operator/dispatcher is busy. The ‘wait’ on that specific radio appears on all consoles. A second operator can take the call and the call passes from the first console to the one taking it over.

The ‘resend’ button will re-transmit the last message transmitted on that radio.

Figure 14 Receving and sending via the device panel

Figure 15 Locked radio and selective call on the device panel

PTT is active Mic is open

Squelch is open on RIU Audio Output is active on PC

Sending Receiving

Selective call incoming

PTT active on other console

Radio ‘locked’ for sending Selective Call



SoftRadio ‘Help’ function

SoftRadio includes an extensive Help function within the application. The Help tool includes a wide range of information, from basic operations to advanced settings. It allows beginner operators and users to be productive faster. Operators can continue to improve their skills ‘on-the-job’, in turn given them the ability to coach and mentor other personnel.

Figure 16 Call waiting and resend on the device panel

Figure 17 Example of Help Screen

Resend

Call waiting

Call waiting

Resend last message



Key settings

SoftRadio provides a wide range of settings that allow operators and administrators to configure consoles to best suit their work-processes and structures. Each console can be configured individually, in groups or system-wide. Settings can be ‘locked’ to the user as needed.

Depending on the configuration of SoftRadio installed on the console, options may be listed here (as shown in the above example ‘Edit Cross-Patch options’ in the left image, and ‘Radio call list’ in the right image).

Under main settings, operators can select the following:

• Glue windows together – makes adjacent SoftRadio windows ‘stick’ to each other so that they can be moved as one, useful when rearranging multiple Virtual Control Head or options panels

• Settings for any installed options, for example as shown here editing CrossPatch settings • Select Devices – select which devices to be shown in each tab (SoftRadio XL)

Figure 18 Settings Menus

Settings Tabs



The reproduction of audio is a vital function for any operator console. SoftRadio makes use of the flexibility in Windows and PC sound devices to provide various options as shown in Figure 20.

Figure 19 Example menus for detailed settings(under tabs)

Figure 20 Examples for audio controls in device panel

Audio / ‘Speaker’ settings

Single speaker button (one audio channel) & volume control

L/R speaker button (two audio channels) & volume control



Table 1 provides an overview of the main settings available. More settings and entries are available. Settings can change depending on the options installed.

Detailed Settings Appearance

Vertical layout Device panels shown with controls (buttons) arranged vertically

Movable Device Panels Device panels are movable in the SoftRadio window, can be grouped and regrouped, panels are set to a fixed size

Group Device Panels into Tabs Organise devices under tabs. Each tab can hold one to all devices, and each device can be present on one or all tabs, SoftRadio XL only

Show radio channel A white panel displays information from the radio, typically the selected channel

Show speaker button Displays a single green speaker button which activates the reproduction of audio from the radio in a speaker or headset

Show left/right loudspeaker Displays two green speaker buttons, for left and right audio channel, allows to play audio from two devices simultaneously e.g. using a stereo headset

Show volume control SoftRadio displays a volume control for each speaker button

Enable GroupSend Panel For GroupSend option, allows sending on multiple radios at the same time

Open radio panel at call Radio Virtual Control Head opens when a selective call is detected

Popup at call SoftRadio device panel opens when a selective call is detected

Sound alarm at call Sound an alarm signal when a selective call is detected

Controls

Space key PTT by pressing the space key

Use external send-key Use an external PTT switch, e.g. a foot-switch

External send-key connected to Selects COM-port to use, a USB to COM-port adapter can be used

I/O Panels For I/O Panels option, used to read inputs and set outputs in the RIU at the radio-site, e.g. a door alarm

Hotkey Function A keyboard key or combination of keys that are associated with a specific function or program

Rx indicator hold time Determines lag of yellow squelch indication, default is 2s to take call

Radio Call List – requires Selective Calls / Speed Dial option

Radio Call List using Excel Call list stored in an Excel file

Radio Call List using MySQL Call list stored in a MySQL database

Multiple Hotkeys – requires option to be installed

Enable multiple hotkeys Radios/RIUs can have specific Hotkeys assigned, assigning a Hotkey via a double-click on the cell to the right of the radio name and selecting a key

Installed Options

Shows the options installed on the specific console

Table 1 Overview of most detailed settings



5. SoftRadio Virtual Control Heads

‘Virtual Control Heads’ (VCH) provide the ability to control a radio remotely using the same functionality and ‘look & feel’ of the radio itself. The RoIP Interface Unit (RIU) incorporates the additional functionality needed to interact with a compatible radio via its control-head/control-bus, such as a PEI or data-extension adaptor. The SoftRadio console in turn provides the user with a functional, interactive replica of the radio’s control head. The operator can control the radio using either the mouse, a touchscreen or keyboard shortcuts to activate functions on the VCH – just as if the operator is using the radio itself.

Radios can be programmed according to the relevant manufacturer’s specifications and the model’s capabilities. The standard console device panel and the VCH operate in parallel. Control and behaviour is fully transparent and integrated. Tasks executed on either are represented on both. For example an operator can keep the VCHs of key radios in the foreground, and maintain secondary radios for monitoring on the standard device panel.

Motorola TETRA

MTM800E & MTM5200/5400/5500

Settings on the VCH mimic the physical front panel. The VCH omits the front-panel control-knob as the volume of the audio on the console is adjusted using the Windows volume control, or using the volume controls in the SoftRadio device panel. Due to limitations of the PEI bus, the VCH cannot operate fully in parallel to the radio’s physical control head. For example a menu accessed on the physical control head is not replicated on the VCH, but a change made to the talk group will be shown. The VCH provides two additional keys to directly access SDS messages. The VCH omits features that are not required on the SoftRadio console, e.g. display brightness, screen saver, etc.

Figure 21 SoftRadio Virtual Control Heads



The VCH provides the following functions:

• TalkGroup list and selection; Scanning, list edit and scan on/off • Short dial list and calls; SDS send/receive • Change of TMO/DMO; Radio Info menu • Further functions are being added in upcoming revisions

The default interconnect uses the PEI connector on the rear of the transceiver. In the case of the MTM5500 the PEI port is interfaced via the DB9 connector on the front of the radio. Similarly when using a PMLN4908 Data Expansion Head with the MTM5400, the PEI is also on the front of the radio.

MTM700/800 (non-E-type)

The VCH replicates the Motorcycle Control Head of the MTM700/800. The VCH omits the front-panel control-knob as the volume of the audio on the console is adjusted using the Windows volume control, or using the volume controls in the SoftRadio device panel.

• Supported radio types for MTM700: M47xCC6TZ5, M47xCW6TZ2 • Supported radio types for MTM800: M80xCC6TZ5, M80xCW6TZ2 with (x=P/R/U frequency bands)

To connect a Motorola MTM700/800 radio, the standard control head is replaced with the suitable Expansion/Data Head. Audio and data is interfaced via the front 25-pin connector on the extension head, only the external alarm is connected on the rear connector of the transceiver. Default programming for ‘Pin 4’ is external alarm low output, allowing the RIU to recognise that a selective call has been received.

Figure 22 Motorola TETRA MTM5400/MTM800E and MTM5200/5400/5500/800E

Figure 23 Motorola TETRA MTM700/800



Motorola MotoTrbo DM4600/01 and DM3600/01

The VCH replicates a standard MotoTrbo DM4600/01 and DM3600/01. Settings on the VCH are made as on the physical front panel. A keypad is included to make selective calls easier. The VCH for the DM46xx series allows to set the keyboard to Channel Select as default. This simplifies operation in systems with many channels, such as Marine VHF radio.

All connections are made from the rear connector on the radio. The standard control head should be left in place and operates in parallel with the VCH. The radio shall be programmed for:

• Cable Type on the Accessories Page, set to: "Rear Data Accy" • GPIO Pin #17 shall be set to Ext Mic PTT, active low • GPIO Pin #26 shall be set to "Ext Alarm; High" • Alarm to "Permanent Ext Alarm"

Supported radio-models:

• DM4600/01 (XPR5550, DGM8000, XiR M8660, XiR M8668), recommend firmware 2.30.01 or higher • DM3600/01 VCH (XPR4500, XPR4550, XPR4580, XiR M8260, M8268, DGM6100)

Motorola GM/CDM-Series

Settings on the VCH are made as on the physical front panel. The VCH omits the front-panel control-knob as the volume of the audio on the console is adjusted using the Windows volume control, or using the volume controls in the SoftRadio device panel.

To connect a Motorola GM/CDM-series radio, the standard control head is replaced with the corresponding remote or extension head. (The VCH connection does not function via the microphone connector on the control head). Audio and data is interfaced via the front connector on the extension head, only the external alarm is connected on the rear connector of the transceiver. Default programming for ‘Pin 4’ is external alarm low output, allowing the RIU to recognise that a selective call has been received. The radio shall not be wired for ‘ignition sense’.

Figure 24 Motorola MotoTrbo DM4600/01 and DM3600/01



GM360 (GM160/338/338LS/339/660, MCX760, CDM1550/1550LS+; PRO7100/7200)

The keys displayed on the VCH can be configured with different symbols to suit different markets. Requires Expansion/Data head RLN4802.

CDM1250 (PRO5100)

Requires Expansion/Data head RLN4802.

GM1280

While the GM1280 is no longer in production, the RIU is available. Requires Expansion/Data head RLN4780.

Figure 25 GM360 (GM160/ 338/339/338LS/660, MCX760, CDM1550/1550LS+, PRO7100/7200)

Figure 26 CDM1250 (PRO5100)

Figure 27 Motorola GM1280 full keypad MPT1327 version, also known as MCX780



GM380 (GM398/399)

While the GM380 is no longer in production, the RIU is available. Requires Expansion/Data head RLN4780.

Kenwood

Nexedge NX720/820 & TK-7360/8360

The VCH replicates a Nexedge NX720/820 or Analogue TK-7360/8360 model. Settings on the VCH are made as on the physical front panel and an option is provided to activate a numeric keyboard.

Supported radio-models:

• Nexedge NX-720: E/GE/HK/HGK/HGK2; NX-820: E/GE/HK/HGK/HGK2 • Analogue TK-7360: E/M/HM/M2/HM2/HV; TK-8360: E/M/HM/M2/HM2/HU

The radio’s original control-head, microphone and speaker can be used in parallel with the SoftRadio VCH. All connections are made from the rear 15 pin connector on the radio. The radio shall be programmed with GPIO Pin 10 set to external PTT active low (Extended function, AUX-Tab). External PTT (voice) shall be connected to the MI2 line (Extended function, Modulation Line-Tab). To provide audio In/Out on the back connector, two jumpers need to be set in the radio (see the installation manual for details).

Figure 28 Motorola GM380 full keypad 5-tone version, also known as GM398, GM399

Figure 29 Kenwood Nexedge NX720/820 or TK-7360/8360



TK-7180/8180/7189/8189

The VCH replicates a TK-7180/8180/7189/8189 model. Settings on the VCH are made as on the physical front panel with the option to include a numeric keyboard in the VCH. Valid radio-models:

• TK-7180: E/E MPT/H; TK-8180: E/E MPT/H • TK-7189: E/E MPT; TK-8189: E/E MPT

The radio’s original control-head, microphone and speaker can be used in parallel. All connections are made from the rear 25 pin connector. The radio shall be programmed with External PTT on GPIO Pin 13. External PTT (voice) shall be connected to the MI2 line (Extended function, Modulation Line-Tab).

Hytera MD785/788 DMR

The VCH replicates a Hytera MD785/788 DMR radio. Settings on the VCH are made as on the physical front panel. The radio’s original control-head, microphone and speaker can be used in parallel with the VCH. All connections are made from the rear 26 pin connector on the radio.

VCH capability currently includes the following functions:

• Remote audio and PTT; Keys P1-P4 with short and long press • Channel/TalkGroup change; Presentation of channel/TalkGroup alias name • Presentation of the radio ID of the transmitting radio in a DMR group (Radio ID number not alias) • Icons for; receiving, transmitting, scanning, H/L-power • More functions are in development/testing

Figure 30 Kenwood TK-7180/8180/7189/8189

Figure 31 Hytera MD785/788 DMR



ICOM IC-M423/M424 Marine Radio

The VCH replicates an ICOM IC-M423/M424 Marine radio. Settings on the VCH are made as on the physical front panel. The radio’s original control-head, microphone and speaker can be used in parallel with the SoftRadio VCH. The VCH provides a fast key to CH16.

Sepura SRM2000, SRM3500, SRG3500, SRG3900

The VCH replicates a standard Sepura Tetra radio SRM2000, SRM3500, SRG3500 or, SRG39001. Settings on the VCH are made as on the physical front panel. All connections are made from one of the control head connectors on the radio. The physical control head can be left connected to the other port and can be used in parallel with the SoftRadio VCH.

Basic Settings for VCH Display

A radio’s VCH can be opened manually by ‘clicking’ on the channel number field or caption bar of the radio’s device panel. SoftRadio can also be set to automatically open the VCH when a selective call is detected. (SoftRadio device panel <Settings>).

The VCH is closed by again clicking the Channel No field or the Caption bar used to open it. It can also closed using the File-menu on the VCH or by closing the Window using the close control on the frame.

1 * SRG3900 using display of the SRG3500

Figure 32 ICOM IC-M423/M424 Marine

Figure 33 Sepura SRM2000, SRM3500, SRG3500, SRG3900



Various settings can be made on the individual VCH to suit the operator’s preferences and work-process. The settings are access from the Settings menu on the VCH itself.

• Glue windows together allows an operator to move the VCH, or multiple VCH panels together with the SoftRadio device panel as one. The panels in effect ‘stick’ together when placed close to each other. The setting can be overridden without needing to make a change in <Settings> by holding the [Ctrl]-key prior to moving the panels.

• Background colour on the VCH can be selected as either light or dark (dark is shown above). • The speaker can be turned on automatically at an incoming selective call • The information displayed in the Channel field can be configured (subject to the type of radio)

Figure 34 Opening a VCH

Figure 35 Display settings for the VCH

Figure 36 Channel No field settings



Table 2 provides an overview of VCH supported radios

Motorola Model

Motorola TETRA MTM800E & MTM5200/5400/5500

MTM700: M47xCC6TZ5, M47xCW6TZ2

M80xCC6TZ5, M80xCW6TZ2 with (x=P/R/U frequency bands)

MotoTrbo DM4600/01 (XPR5550, DGM8000, XiR M8660, XiR M8668), recommend firmware 2.30.01 or higher

DM3600/01 VCH (XPR4500, XPR4550, XPR4580, XiR M8260, M8268, DGM6100)

Motorola GM-Series GM1280, full keypad MPT1327 version; requires remote kit RLN4780 Note: No longer in production, RIU and VCH continue to be available.

GM380, GM398, GM399, full keypad MPT1327 version, requires remote kit RLN4780 Note: No longer in production, RIU and VCH continue to be available.

GM360, (GM160, GM660, MCX760, CDM1550, GM338, GM339, PRO7100, PRO7200, GM338LS, CDM1550LS+), requires remote kit RLN4802

CDM1250 CDM1250, (PRO5100), requires remote kit RLN4802

Kenwood Model

Nexedge NX720/820 NX-720 E/GE/HK/HGK/HGK2

NX-820 E/GE/HK/HGK/HGK2

Analogue TK-7360/8360 TK-7360 E/M/HM/M2/HM2/HV

TK-8360 E/M/HM/M2/HM2/HU

TK-7180/8180/7189/8189 TK-7180 E/E MPT/H TK-8180 E/E MPT/H TK-7189 E/E MPT TK-8189 E/E MPT

Hytera Model

MD785/788 DMR MD785 MD 788

ICOM Model

ICOM Marine IC-M423 IC-M424

Sepura Model

SRM/SRG SRM2000 SRM3500 SRG3500 SRG3900 (using display of the SRG3500)

Table 2 Overview of radio models available with Virtual Control Head



6. The RoIP Interface Unit

The RoIP Interface Unit (RIU) allows a two-way radio to be connected to an IP-Network, effectively making it ‘IP-capable’. RIUs are available in general purpose (Audio/PTT only), VCH and special purpose formats. VCH capable RIUs allow remote-control of a compatible radio over IP using a replica of its control head or front-panel on the operator screen (see section 5). Special purpose RIUs can connect a PSTN line, provide GSM/3G access, or extend a remote control-head over an IP-Network.

The primary function of the RIU is to convert the radio-communications signals (audio, squelch and PTT, call-data, status and control information) into data-packets for transport over an IP-network. The RIU converts the analogue signals into digital, and handles a range other functions such as Squelch via threshold recognition, or control data for use with the VCH. The RIU of course handles the reverse process as well, unpacking the data and converting it back into the relevant signals.

The RIU utilises a G.711 narrowband (300–3400 Hz, 8 ksamples/s) audio codec. Non-uniform (logarithmic, A-law) 8-bit quantization delivers a 64 kBit/s bit rate. As overheads are kept low, the resultant traffic loading for an active audio channel is approximately 80 kbyte/s. An inactive RoIP channel only carries a ‘keep alive’ status burst sent out every second to maintain identification of the RIUs in the network.

As the RoIP Interface Unit is an IP-capable device, it has its own IP-address and Network Interface Controller (NIC). The RIU’s NIC manages the exchange of data according to the relevant protocol. UDP is used in a local LAN Subnet, and TCP is used for connections beyond. The NIC allows one TCP connection via a single network socket alongside concurrent UDP (see also section 10).

Figure 37 SoftRadio RIU types

Audio/PTT

Virtual Control Head

RIU with VCH Radio with Control-bus, e.g. PEI

LAN/ WAN

Radio with Control Head / Data extension, e.g. GM1280

Radio Control Head

LAN/ WAN

e.g. PSTN

General Purpose RIU

Special Purpose RIUs

‘SoftLine’ RIUs

Audio/PTT via Radio ext. in/out (Mic/Spkr)

RIU <> Radio interconnect

https://en.wikipedia.org/wiki/G.711

https://en.wikipedia.org/wiki/Network_interface_controller

https://en.wikipedia.org/wiki/Network_interface_controller



General specifications:

Size Weight Power supply Operating Temperature

120 x 78 x 44 mm <300g (Typical 260g) 8 - 28Volt / 250mA 10 - +50 °C

Connectors RJ45 for Ethernet; D-sub for audio, power, I/O, data and auxiliary I/O

Table 3 General specifications for SoftRadio RoIP Interface Units

General Purpose RIU

General purpose, or generic RIUs allow to transport audio to and from any two-way radio via an IP-Network. When an operator transmits on a console, the RIU receives a PTT signal from the console and activates the transmitter. The audio is sent from the console and the RIU re-assembles and converts the data-packets into analogue, and supplied to the radio, for example via an External Microphone port.

When the radio receives an incoming call, the RIU receives an analogue audio signal from the radio, for example from a Speaker Out port. When the RIU’s AF (Squelch) detector recognises an audio signal is present, the RIU digitises the audio and assembles it into the appropriate IP-packets. These are sent to the consoles where the device panel then indicates an incoming call. RIUs also communicate their status and as relevant that of the radio, for example an incoming selective call, or information to update the VCH.

Figure 38 SoftRadio RoIP Interface Unit

Figure 39 Principle RoIP channel for Audio & PTT

Example MTM800E with VCH via PEI bus

Example Kenwood TK-718x/818x with VCH

Console PC RoIP Interface Unit

Sound Card

Package & address

Reassemble

Codec Package & address

Reassemble >> Audio/PTT

IP-Transport & Data >

<< Audio/Status

< IP-Transport & Data

Radio Interconnect Audio IN (Mic) Audio OUT (Spkr) PTT IN

UI

IP-Network

NIC

NIC

PTT & Audio (Tx)

Audio (Rx) & Status Information (RIU)



The versatility of the generic RIU allows for a wide range of uses. Different radio-types and applications can be enhanced via an IP-based interconnect. Limitations of location and access can be mitigated, or eliminated. For example two-wire base-stations can be migrated from a PSTN ‘leased line’ control to an IP-based configuration, reducing costs and improving access considerably. Equally, once the radio-communications is in the IP-realm, the data can be sent to and utilised by a range of other applications, for example autonomous surveillance and monitoring, testing of radio modules or assemblies, or to connect to remote VHF or HF radios. General purpose RIUs can be provided with different Audio/PTT configurations as shown in Table 4. Pre-configured cable-kits (RIU/radio interconnect) are available for a range of radio models and manufacturers.

Standard Audio In/OUT PTT

Unbalanced, Mic & Spkr levels OUT (to Radio Mic); 0 - 1.1Vpp , 330Ω output impedance IN (From Radio Speaker), 0.7 - 13Vpp (0.25 - 4.5Vrms), 660Ω load impedance

PTT by open collector closure to GND

Configuration types

Unbalanced, tuned for Motorola CM & GM radios, no VCH, Mic/Spkr levels

OUT (to Radio Mic); 0 - 1.1Vpp , 330Ω output impedance IN (From Radio Speaker), 0.7 - 13Vpp (0.25 - 4.5Vrms), 660Ω load impedance

PTT by open collector closure to GND

2-wire, -10dB Line level in/out -10dB @ 600Ω PTT by DC closure of the line (AC tone as an option)

4-wire, PTT via Tx-line, - 10dB Line level in/out -10dB @ 600Ω PTT by DC closure of the Tx-line (AC tone as an option)

6-wire, -10dB Line level in/out -10dB @ 600Ω PTT by open collector closure to GND

Table 4 Available I/O configurations for generic (Audio/PTT) RoIP Interface Unit

Figure 40 Example Audio/PTT only interconnect for ICOM A-110 Airband Radio

RIU LAN

Cable Interconnect Kit

/

ICOM A110

Aux Speaker

RF

8 - 28Volt /

Microphone Connector



Custom applications

SoftRadio RIUs can be also deployed in custom or development applications using one of the options shown in Table 4. For example a 4-wire generic RIU can be used to connect with a separate transmitter and receiver assembly in a test-bed application. The audio received by the RIU can be used in a variety of ways as it is available in digital form. For example analyses can be executed using PC based applications, audio logs can be easily created and samples recorded and distributed. SoftRadio RIUs have been successfully deployed across a range of custom applications. In some cases custom I/O configurations were tailored to fit the customer’s specific needs. Please contact us with any requirements that may not be covered here.

RIU with Virtual Control Head

RIUs with ‘Virtual Control Head’ (VCH) provide a functional replica of the Control Head on the console.

Figure 41 Interconnect for a generic 4-wire interconnect

Figure 42 Principle RoIP channel with Audio & PTT and Control Head functionality

PTT to transmitter

Modulation to transmitter

AF (audio) from receiver

PTT activated from Console Audio into RIU

Audio from RIU Tx Twisted Pair

Rx Twisted Pair

>> Audio/PTT & VCH Control << Audio/Status & VCH Display

Audio / PTT IN Control Bus E.g. PEI

Console PC RoIP Interface Unit

Sound Card

Package & address

Reassemble

Codec Package & address

Reassemble

UI

IP-Network

NIC

NIC

Control Head/Bus Data Management

VCH Display/Data Management

IP-Transport & Data >

< IP-Transport & Data

PTT & Audio (Tx)

Audio (Rx) & Status Information (RIU)

Control Data FROM Radio

Control Data TO Radio

http://testadvance.com/contact-us/



The VCH display operates just as the ‘real’ radio does. The relevant functions can be accessed by pressing the replicated buttons. This can be done using the mouse and keyboard, or via a touchscreen. Multiple operators at different locations can access a radio’s Virtual Control Head. The data I/O for radio control uses the relevant RS-232, TTL, USB or other manufacturer-specific protocols or bus configurations such as a PEI bus. See also: Virtual Control Heads (VCH)

Special-purpose options and functions

SoftRadio RIUs can be configured with a number of options, depending on the type of interconnect needed for a specific radio type or model (some radios require more of the ports available on an RIU, some fewer).

Remote data I/O (RS-232 compatible) ports on the RIU can be for example used to access on-site devices such as a security system, or a RF Power Measuring or SWR device. This allows operators or administrators to access site-specific functions remotely. RIUs can also be provided with specific output configurations to interconnect with custom applications or devices. Available analogue I/O ports include:

• Up to 3 inputs with High (‘On’) = 2.5-30V; Low (‘Off’) = 0-0.8V, 47kohm impedance to ground • Up to 3 open collector outputs, max. 30V & max. 10mA with optional reverse-current protected

5.6k pull-up to +5V • 1 high current output, max. 16V & max. 500mA

Please contact us with any requirements that may not be covered here.

Tone-decoder options are used together with the Local CallLog option to decode Land Mobile or Marine Radio calls. See also: Using SoftRadio Call Options & CallLog. RSSI decoders are used together with the Receive Diversity option to determine the received signal strength at a base radio (requires a compatible radio). See also: Using SoftRadio Receive Diversity.

RIUs for non-radio devices

SoftRadio RIUs are also available that can connect non-radio devices. RIUs are available to connect to a standard analogue phone-line (PSTN) or a GSM cellular networks using a GSM/3G modem. See also: Using SoftRadio PhoneConnect.

Figure 43 Example full VCH interconnect for Motorola MTM800E Radio with PEI bus

Power

RF

RIU 8 - 28Volt / 300mA

MTM800E

Radi

o Fr

ont P

anel

LAN < To console

Cable Interconnect Kit

/ /

PEI/Acc. Conn.

Typ. 12V/ 300mA

http://testadvance.com/wp-content/uploads/resources/SoftRadio-Virtual-Control-Heads.pdf


http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-Call-Options.pdf

http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-Receive-Diversity.pdf

http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-PhoneConnect.pdf




Intercom RIUs are also available for operations that need to connect different operators via a wireline. For example Intercom units can be used in Command Control Vehicles to extend communication into tunnels and other areas were RF communications are not possible or severely degraded. The Intercoms are connected in one talk group for all operators with an active intercom on the console. Several intercom RIUs can be connected to the same wire line. If the CrossPatch is installed on a console, an intercom call can be patched to a radio channel or phone line. It is also possible to connect two Command Control Vehicles together through the intercom wire line ports.

SoftLine IP-interconnect for Radio and Control Head extensions

SoftLine RIUs allow to create virtual ‘wire connections’ over IP, for example to extend a control head via an IP-Network without using a PC-based console. In some operations, there may be restrictions on using a PC. Or it may simply be the user’s preference to retain the physical control head, often the case when replacing an expensive leased-line (PSTN) connection with an IP-connection.

To extend a remote control head via an IP-Network, two specialised SoftLine RIUs are used ‘back-to-back’. One RIU connects the radio transceiver to the IP-Network as in the standard implementation of SoftRadio, while a second RIU connects a standard control head to the IP-Network, in effect replacing the function of the SoftRadio PC-console. SoftLine is available in a generic configuration and in configurations optimised for Motorola GM380 / GM1280 and Sepura SRG3500 radios.

Figure 44 SoftLine interconnect types

Option to retain local Control Head

LAN/ WAN

Motorola GM380/1280 with Control Head/Data extension Radio Control Head ‘SoftLine’ Motorola

LAN/ WAN

Sepura SRG3500 Radio Control Head ‘SoftLine’ Sepura

LAN/ WAN

‘SoftLine’ generic

1 x virtual 2- or 4-wire audio connection

1 x virtual (transparent) RS-232 2 x virtual logic I/O connections

Device Device



SoftLine RIUs can also be used to create a ‘hard wired’ cross-patch between different radios. While a CrossPatch can be implemented on SoftRadio consoles using the CrossPatch (SW) option, there may be cases where this is not feasible. Using two SoftLine RIUs, two radios can be connected ‘back-to-back’ via an IP-Network. This may be as described earlier to connect two radios via IP that were previously connected using PSTN lines. With SoftLine, two radios can be connected independent of their format, frequency band, make or model. What is required is that both radio-sites have the necessary IP-access, for example in the form of DSL lines. When two radios are patched using SoftLine, the incoming audio on one radio will be rebroadcast on the other, for example to ‘patch’ radio-communications from an Airband to a TETRA radio.

SoftLine core functions

SoftLine RIUs can be applied in a range of applications using the functions described below. For custom applications and for example how to apply Digital I/O to control audio transport via IP, please contact us.

The transfer of audio data starts when the AF detector in the RIU detects an AF signal at the input. The detector threshold can be set using the Network Interface Setup utility provided with the unit. Audio gain is preset to 1:1 with a maximum of +2dBm@600ohm. Two generic, 4-wire audio SoftLine RIUs are available:

• Type 3009/10, preset to -10dB@600 ohm, e.g. to replace a typical PSTN ‘land line’ • Type 3009/21, preset to microphone and speaker levels (see Table 4), e.g. to connect two radios

The Baud rate can be set to from 1200baud to 19200baud again using the setup utility. Data is buffered internally in the RIU and in case transport is interrupted, the RIU re-sends the buffered data within 50ms.

Two general purpose digital inputs and outputs on each RIU allow end-to-end transport of digital data over the IP-Network.

Where SoftLine is used to connect two radios ‘back to back’, the digital I/O is used to send a PTT trigger (e.g. from a Squelch output, or a specific logic trigger) from the initiating device to ‘slave’ RIU and the connected radio or transmitter. The set-up can be both uni-directional and bidirectional, such that one radio can only ‘follow’, or both radios can trigger and follow. In many cases the RIUs internal AF detect signal can be used to activate the transmitter on the following radio.

Figure 45 Using SoftLine to create a ‘hard’ patch

LAN/ WAN

Airband Radio TETRA Radio

‘SoftLine’ CrossPatch

‘Master’ ‘Slave’




Set-Up for RoIP Interface Units

Each RIU is configured prior to installation using a dedicated set-up utility, the Network Interface Setup program. The utility is provided with each RIU and/or SoftRadio delivery. In line with the modular design of the SoftRadio Radio Management System, set-ups of RIUs are conducted independently of the RMS itself.

Please contact us if you require further information on setting up a RoIP Interface Unit.

Figure 46 Network Interface Setup utility




7. SoftRadio Options & Add-ons

SoftRadio Radio Management System (RMS) and RoIP Interface Units (RIU) open up a wide range of opportunities to add productive features to the system. Add-ons and options include:

• CrossPatch, GroupSend & Receive Diversity • Radio Call Options, CallLog & PhoneConnect • MapView • Console productivity options and enhancements • VoiceLog • User Status and Task Logs

SoftRadio CrossPatch

The CrossPatch option allows to create ‘patches’ between different nodes on the network. A patch in effect routes the traffic from one node (radio, phone connect or similar) and automatically routes it via the console to the patched node. For example a VHF radio call coming in from one radio connected to the SoftRadio network can be routed to a TETRA radio-user via a TETRA radio on the network. In effect, the CrossPatch app acts as a telephone operator used to, connecting one line to another. The entire process is transparent to the radio users. See also: Using CrossPatch

CrossPatches allow operators and operations to make best use of the radio assets and resources available at any given time. Up to eight radios can be in the same patch and each operator can make up to four patches at the same time. Operators can be allowed to configure their own patches, or the configuration of patches can be predetermined by a system administrator. Or there can be a mix of the two, with one or two designated consoles being able to configure patches dynamically.

Figure 47 CrossPatch options to interconnect radios via console

Console with CrossPatch Option

LAN/WAN

VHF Analogue Site A

UHF TETRA Site B

‘Virtual’ connection

Audio routed between radios in patch

http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-CrossPatch.pdf



Patches can be used in a wide range of circumstances, such as emergencies, public events or for more efficient staffing in different periods of traffic loads. CrossPatch is of course ideally suited to dealing with radio faults and maintenance.

CrossPatch is an excellent tool in implementing interoperability. It allows organisation more flexibility in how they migrate to new equipment and technology. The useful life of existing assets can be extended, for example by linking analogue radios to trunked and/or digital systems. CrossPatch can also be used to connect phone communications to radio users using the PhoneConnect add-on.

CrossPatch Features and functions

A CrossPatch group can contain two or more devices and each console can create several CrossPatch groups. A device can only be part of one CrossPatch group. Each console that is to create, display and edit patches requires the CrossPatch to be installed. SoftRadio displays the patches between nodes as lines connecting the device panels.

In SoftRadio XL which supports up to 30 nodes, patches are identified with an ‘X1’, ‘X2’, ‘X3’ etc. The routing of the audio is executed on the console on which the patch was originally created. When this computer is shut down, the CrossPatch group is no longer available. A patch to a phone line exists only as long as the phone is off-hook and is automatically removed when the call is ended.

The CrossPatch editor (see Figure 48) can be accessed from the SoftRadio Settings menu, or from the device panel using a ‘right-click’. The editor window shows the existing patches and allows to add new CrossPatch groups, remove existing groups, and add or remove radios within a group.

Figure 48 CrossPatch in the SoftRadio device panel

Edit CrossPatches

CrossPatches

Examples of CrossPatches: • Across coverage areas • Cross-band (e.g. UHF/VHF) • Cross-format (e.g. Analogue to TETRA) • Tunnels, ‘RF canyons’ – chain radios for continued

coverage • Radio – phone – cellular • Ad-hoc or emergency, link e.g. analogue, digital and

phone, or re-allocate resources to increase capacity



GroupSend

GroupSend enables operators to very easily set-up a simultaneous transmission to multiple radios. SoftRadio provides a dedicated GroupSend panel for the option. Radios that are to be included in the GroupSend are selected via a ‘tick box’ on the device panel. To execute a group transmission, the GroupSend PTT is used. All radios in the group can be continued to be used as individual radios from their own panel. GroupSend allows to broadcast alerts, message and ‘pages’ across channels, bands and even different radio-formats and -systems.

Receive Diversity – ‘Diversity Voting’

Some types of two-way radios include the capability to provide a Received Signal Strength Indication (RSSI). SoftRadio’s Receive Diversity makes use of RSSI to automatically select the radio with best RF-path across the radios in a defined group. The application evaluates which radio currently has the strongest received signal on the group frequency or channel and pre-selects that radio to take the incoming call (yellow caption bar). See also: Using Receive Diversity

Diversity Voting uses defined groups of radios, ‘diversity groups’. The radios are located at different sites, for example along a coast-line or transport channel. Each radio in a group is set to the same channel, i.e. frequency. Only when the different receivers are on the same frequency can a valid comparison of the signal strength be made as propagation is a function of frequency/wavelength. The application evaluates which radio of the group currently has the strongest received signal and pre-selects the radio with the strongest signal as having an incoming call (yellow caption bar). The add-on is installed on one or more SoftRadio consoles, depending on the number of operators that require the functionality. Each console that is to use diversity voting requires the option to be installed and configured. 2 to 30 receivers can be connected in the same diversity group and each operator can have up to 16 groups active. As the algorithm to compare signal strengths is executed on each specific console, different consoles can be configured with different settings, for example to reflect different radio-topologies or to manage different coverage areas. An example may be the different approach lanes and docking areas at a large harbour.

To ensure correct comparison between RSSI values, it is recommended to use radios of the same type in one voting group. An option board that handles the RSSI signal is required in the RoIP Interface Unit. The radios used in a diversity group need to be equipped with a suitable RSSI output. Radios from the Motorola GM-series are a suitable type and are currently in active use as diversity receivers with a number of clients.

Figure 49 GroupSend in the SoftRadio device panel

Execute GroupSend

Include in GroupSend

http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-Receive-Diversity.pdf



A useful side-benefit is that operators can track the position of the mobile radio relative to the radio sites. Multiple voting groups are supported. The number of radios in each group is limited by the version of the SoftRadio console installed (8 for the standard SoftRadio, 30 for the XL version).

Radio Call Options and CallLog

Radio Call Options and CallLog are a suite of add-ons and options that build on each other. Call Options provide the basic features, such as making selective calls from a pre-programmed list, speed-dialling and text-messaging for compatible radios.

Figure 50 Receive Diversity example configuration

Figure 51 Receive Diversity on SoftRadio device panel

Console with Diversity Voting Option

LAN/WAN

Ch 16 Site A

Ch 16 Site B Ch 16 Site C

RSSI data

Compare RSSI data



The CallLog, as the name implies, provides the logging of incoming calls. When implemented together, operators can make, log and respond to calls efficiently. See also: Using SoftRadio Call Options & CallLog.

Selective Calls & Speed Dial

The Selective Calls & Speed Dial option simplifies making selective calls from a SoftRadio console. A simple to use and editable speed dial list includes username, radio ID, Net Id and call type. Each console can have its own call list file. Files can be readily copied across consoles and templates can be created for use across the system. Currently supported are Private Calls over MotoTrbo in DMR mode, 5-tone and MPT-Systems and MDC signalling over MotoTrbo radios in analogue mode. For Motorola MotoTrbo radios, Speed Dial allows operators to make calls more easily and faster by directly accessing a list of radios on the consoles, rather than via the radio’s panel-menu/Virtual Control Head.

Text Messaging is provided via a text function in the speed dial list window (for suitably capable radios). The operator can select a predefined message or enter text directly using the PC’s keyboard. Messages are sent to a radio, or a group of radios in the speed dial list. Signalling tones (CCIR, EEA etc.) are generated on the console PC. This allows the use of radios without tone functionality to Call Options. Tones can be configured differently for different radios on the system.

Local CallLog and Tone Decoder

A Local CallLog is available for Land Mobile and Marine radio systems. The Local CallLog in conjunction with a tone-decoder in the RIU allows to log selective calls and trigger actions on the SoftRadio console. The tone decoder in the RIU (option) decodes all incoming tones and sends these as data messages via the IP-connection to the SoftRadio console. An alarm call will be highlighted in red for higher visibility. The alarm can also be set to sound an alarm tone.

Local CallLog is local to a SoftRadio console. Different consoles can have different configurations, call groups etc. The calls will be presented in a list together with a timestamp and which radio the call came in on. The calls are both displayed in a user window that shows the latest calls and saved in a log file on the console PC. A new log file is created each day.

Figure 52 Call List with text message

http://testadvance.com/wp-content/uploads/resources/Using-SoftRadio-Call-Options.pdf



For Land Mobile Systems the RIU is used with the tone decoder for CCIR, ZVEI and EEA tone systems. For Marine Radio Systems a FSK tone decoder for ATIS, DSC is used in the RIU. ATIS calls can also be exported, e.g. to a GIS systems.

PhoneConnect (PSTN, GSM/3G, SIP2)

PhoneConnect adds the ability to make calls to the PSTN and/or cellular telephone-systems directly from the SoftRadio console. PhoneConnect adds a dial-pad menu to the standard SoftRadio screen. Connection to the PSTN line or cellular network is made through a special-purpose RIU. Connections to IP-Phone switches with SIP-protocol will be made through the LAN with the NetworkRepeater as a gateway. This is currently under development. Audio reproduction is the same as for radios via the selected sound device and headset or speakers. For analogue (PSTN), a special RIU connects to a two-wire DTMF line. For GSM (2G)/3G a special RIU is paired with a suitable 2G/3G modem. Satellite phones with PSTN connectivity can also be accessed.

Each operator can have a dedicated phone line, or share one or more lines with other operators. Calls can be made, received and put on hold for other operators to take over. If the CrossPatch option is installed on the console, an operator can patch calls between phone and radio users. See also: Using SoftRadio PhoneConnect

2 Currently under development

Figure 53 Local CallLog list display with Call Back

Figure 54 ATIS/DSC CallLog





I/O Control for remote I/O ports

SoftRadio Remote IO Control allows an operator to remotely control the auxiliary I/O ports on the RIU from within the SoftRadio console (SoftRadio XL only). Applications can be e.g. to deactivate a security system, access sensors or monitor RF-parameters such as SWR using suitable devices at the radio site.

Figure 55 Options to connect with telephone systems

Figure 56 Example Remote IO Control on Console Device Panel

Test 561

GM380

MTM

MTM700

Network Repeater *SIP Option in development

PSTN GSM/3G

SIP* Gateway



Productivity Enhancements

As described earlier, SoftRadio consoles can be configured to better suit the work-processes and practices in a specific operation or environment. In some instances, further functionalities may be useful and are often developed in cooperation with customers. To ensure a good balance of functionality and costs, these more specialised features are offered as options rather than being incorporated as standard features.

• Display Text Export (Motorola MTM & GM series): Allows to export the text displayed in Motorola MTM & GM radios to integrate with non-SoftRadio systems, for example to detect and export a special SDS message.

• External Alarm: The add-on provides a logic output on the COM Port when a radio receives a selective call.

• No shutdown: SoftRadio can be set up to start automatically and cannot be shut down by an operator.

• Hook Switch emulator: For systems where console operators use handsets. The add-on allows to use the hook switch to control the console loudspeakers (on/off). Control is done via a data message over the network and can extend to control the speakers on other consoles.

• Multiple Hotkeys (SoftRadio XL Only): Allows the operator to assign specific keys on the keyboard to execute PTT for specific radios, e.g. ’1′ for Radio 1, ’2′ for Radio 2, etc.

• Programmable Hotkeys (SoftRadio XL Only): Allows an operator or administrator to create special shortcut keys on the SoftRadio console. These can e.g. be used to execute common tasks on one or more radios otherwise only available via the radio’s Virtual Control Head.

MapView

SoftRadio MapView provides the capability to display the location of radios and alarms on a SoftRadio console PC. The MapView add-on to the SoftRadio console provides the display and graphical tracking of the relevant radios. The MapView Server manages the database of the radios configured in the systems and their last reported position and state. See also: Using SoftRadio MapView

Each radio unit will be presented with an operator selected icon on the map. The operator can easily centre and zoom the map on one unit. He can also fetch more information about the unit, with a simple click. Fixed points can be marked on the map, for example the location of a depot or a worksite.

MapView requires the SoftRadio console application to be installed and ‘running’. The SoftRadio network requires radios suitably capable of receiving and providing position data from the mobile and portable radios for which the position is to be displayed and tracked in MapView and MapView server. The current version of MapView supports Motorola MTM800E, MTM5400 and MTM550 TETRA radios. Support of further TETRA and Motorola MotoTrbo radio models is in development. The server application is designed to run on the console PC and is compatible with any Windows 7 or Windows 8 PC. MapView requires SoftRadio version 3.3.18.10 or higher.

Operators can locate a radio by selecting a radio from the list in the left menu-bar which centres the map to the position of that radio. The information displayed for a radio can be edited, and custom markers can be added, for fixed locations such as a depot or facility. In the event an alarm is received from a radio together with its position, the map will centre on that radio and the corresponding icon is changed to reflect an alarm state. The radio will be placed at the top of the active list in the left menu-bar.

http://testadvance.com/wp-content/uploads/resources/SoftRadio-MapView.pdf



Figure 57 SoftRadio MapView

Custom Markers & Map Settings

Radio Marker Radio List

Search Field

Custom Marker Satellite View



8. VoiceLog

SoftRadio VoiceLog is a Windows server based application that allows operations to record, recall and archive audio communications from across the network. The standard version (P/N 2862) supports up to 30 nodes and more than 200 consoles. The ‘lite’ version (P/N 2862/02) supports up to 4 nodes and 4 consoles.

VoiceLog can be used on individual consoles and system-wide. An individual operator can review past radio traffic for a specific time-frame, e.g. a previous call. This can be useful when a vehicle operator is ‘off air’, after a shift-change of operators, or when critical instructions were not acknowledged. A supervisor or system-administrator can review communications from all consoles and radios. Audio traffic can of course be archived for longer periods, for example for incident management and investigative purposes.

VoiceLog records all audio traffic across SoftRadio consoles, radios and other nodes such as a PSTN line, to a common, designated storage device. Recordings are made in the standard .wav-format and named with date, time and audio path. Logs are managed using a MySQL database. 20 hours of constant recording corresponds to approximately 1GB of data. A 1TB hard drive provides enough storage capacity to record audio for approximately 12 months. With suitable network backup, operations can record and archive voice-traffic for years. See also: Using SoftRadio VoiceLog

VoiceLog connects to the SoftRadio network as a node within SoftRadio’s modular design and system-architecture. Accordingly it has its own device panel on the SoftRadio console. The panel is managed by SoftRadio as any other panel, allowing to resize, re-arrange and configure the panel via relevant settings.

Once installed and connected to the network, VoiceLog broadcasts its presence to the SoftRadio consoles (clients). These in turn identify the VoiceLog server and create a VoiceLog device panel. When a client console queries the VoiceLog Server, the server retrieves the information identifying available recordings from its database and sends it back to the client console for display.

Figure 58 SoftRadio VoiceLog basic application diagram

‘Background’ recording of audio traffic

Internet/ WAN

Windows PC with VoiceLog Server Application

SoftRadio Device Panel

Client requests audio

Server provides audio to client console

Local Radios

Remote Radio

VoiceLog Playback Panel

Administrator Database, Audio Files Playback/Review

Audio

VoiceLog Device Panel

http://testadvance.com/wp-content/uploads/resources/SoftRadio-VoiceLog.pdf



Selecting the ‘Show VoiceLog’ field in the device panel in SoftRadio opens the VoiceLog Playback panel. The Playback panel displays the available audio segments as small horizontal bars. Using the Playback panel, the operator can select the audio channel to listen to which is identified by the name of the relevant radio or device. This is the same name that appears in the standard SoftRadio device panels.

Two time-lines of recordings are displayed for each device connected, one for outgoing and one for incoming audio. The operator can select to view either or both, using the tick-boxes as shown in Figure 3. Each length of active audio (‘burst’) is displayed on the time line. A user simply sets the marker (cursor) on the desired burst to play back the recording. When an operator presses the playback button, the server sends the audio to the console. The console plays back the audio using the sound devices configured for that console, typically the internal sound-card and the headset or speakers.

Figure 59 SoftRadio console VoiceLog device panel

Figure 60 VoiceLog Playback panel

Green – Audio from Radio

Blue – Audio from Console (operator)

Radio Name (on/off)

Time-frame size (short/long)

Cursor

Time-frame shift (earlier/later)

Opens VoiceLog Playback panel

Opens last received audio message

Playback

Volume / Speaker Configurable in SoftRadio settings

SoftRadio Device Panel



9. SoftRadio StatusLog & ObjectLog

Dispatch or command & control centres often have multiple operators managing a large number of radio-users in the field. Radio-users typically call an operator to update their status, for example when a task is complete. Operators in turn may need to query a radio-user on the status. This requires that both radio-user and operator keep track of whom to call and when, who is handling this task or user, and the required action. Operators also may need to merge or transfer the information to other applications, for example a fleet-management system. Managing calls and information increases overhead. This can also give rise to errors, especially during peak traffic or where issues need to be escalated.

StatusLog relieves operators from these overheads and allows them to handle calls and actions with the necessary attention and in the priority required. With StatusLog, each operator can easily maintain a clear overview of the real-time status of all radio-users and any associated calls.

SoftRadio StatusLog is a Windows server based application that assists in managing activities in a radio network. StatusLog receives and logs incoming calls from radio-users in the field. The application automatically updates the status of these users. All operators on SoftRadio consoles using StatusLog see the same information in real-time.

Each incoming Status Call is logged with the code and text for the status, for example ‘Signed-In’, ‘Check-Point 1’ or ‘Depot’, the radio-user and a time stamp. The time stamped includes when it is received, when it is first answered and when it is last handled. Status messages can also be exported to other systems.

Figure 61 StatusLog showing incoming calls and status

Voice-call queue

Status Display



StatusLog also logs voice-call requests from radio-users in the field. The system is configured such that voice-call requests from the field are made to one base radio and placed in a queue. Having a single queue for incoming voice-call requests ensures that all operators work from the one queue and requests are responded in the correct order. Any operator with access to the queue can take a call, or if required, a specific operator can be made aware that a call is pending in the queue. A further benefit is that users in the field are not dependent on a particular operator or station being available. Operations in turn can allocate resources with a greater degree of flexibility.

An emergency call is highlighted in red square on all dispatcher screens and placed at the top of the voice-call queue. An alarm tone will sound until the alarm is cleared by an operator/from the computers until one dispatcher clears the alarm.

The optional ObjectLog provides an additional level of functionality or activity management. Operations can pre-assign individual radio-users to specific ‘objects’ and define parameters or conditions to be met. In effect, ObjectLog adds task-information to the status-information provided in StatusLog, further reducing the overhead for operators and radio-users. This feature is especially useful where operations have a comparatively large proportion of recurring or standard tasks. To add this task information, the object defines the entity or item that tasks are performed on or for. Conditions or parameters define the criteria that are used to determine how, or if, the tasks has been performed as required. For example a security guard can be assigned to a facility and certain times and locations for call-ins can be pre-set. Or a radio-user can be assigned to a vehicle and conditions can be set for when to call in with an update, when the vehicle needs to arrive at the depot, and by when it needs to be loaded.

See also: SoftRadio Status & ObjectLog.

Figure 62 ObjectLog showing objects and conditions

http://testadvance.com/wp-content/uploads/resources/SoftRadioStatusObjectLog.pdf



10.IP-RoIP Networks

A RoIP-based radio network can be implemented in various topologies. In its simplest form all devices (nodes) are connected to the same local LAN subnet. Nodes are typically radios and their attached RIUs, but can also be other devices attached to the network, e.g. a PTSN interface.

An organisation’s operational needs and objectives should determine how a radio network is implemented, not the constraints of location or the IP-Networks available. Radios may all be located at one site, or they can be distributed across multiple locations with operations managed from one control centre. In other cases, both radios and operators may be distributed across various locations. With RoIP, operations can use an existing IP-backbone across multiple LAN subnets, a corporate WAN, or even the Internet.

Figure 63 Principle topologies of an IP/RoIP Network

While it is essential that access to RoIP devices is not limited by the characteristics of the underlying IP-Network, this needs to be achieved in a cost-effective and efficient manner. It may be technically possible to include in each individual device all the functionality needed to ensure compatibility with the variety of network topologies possible, yet this is not a cost-effective approach.

SoftRadio’s modular structure delivers the required functionality through dedicated RoIP/IP-Network devices. This allows operations to incorporate these ‘network building blocks’ as and when needed. Organisations can build-out an IP-based radio network cost-effectively by extending the network when and where it adds value.

SoftRadio Network Repeater and Radio Server are the ‘building blocks’ that enable operations to build a fully accessible radio-network and make effective use of existing networking capability.

• Network Repeater enables local consoles to access distributed radios concurrently • Radio Server enables distributed consoles to access local radio-nodes concurrently • For mixed topologies, RadioServer and Network Repeater can be employed together

The following sections provide a more detailed explanation of the impact network topologies have on an IP-based radio network, and how Network Repeater and Radio Server overcome these constraints.

Radio resources

System Admin/Applications

Radio users

Internet/ WAN

Local LAN / UDP TCP

http://testadvance.com/wp-content/uploads/resources/SoftRadio-Benefits-of-a-Modular-RMS.pdf



Understanding the impact of network topologies

IT-networks use different protocols to transport IP-packets. In a local LAN subnet, the default for a SoftRadio installation, packets can be transported via the User Datagram Protocol (UDP). UDP is a ‘connection-less’ protocol that allows streaming, broadcasting and concurrent access to network nodes. For connections beyond a local LAN subnet, transport is via TCP/IP. TCP is a ‘connection-based’ protocol. Here a connection must first be established before data can be transferred, and the connection must be closed before the resources are released. TCP does not allow for concurrent access and broadcasting. Which transport protocol is used determines how resources can be shared in a RoIP based system.

As described in Section 6, the RoIP Interface Unit (RIU) connects a two-way radio to an IP-Network, creating a radio-node. The RIU has its own Network Interface Controller (NIC) and IP-address, just as any other IP-capable device. The NIC provides a single network socket, enabling it to handle a single TCP connection alongside concurrent UDP exchanges.

On the operator side, the SoftRadio console is installed on a Windows PC. The PC provides the analogue-digital conversion needed to send and reproduce audio. The SoftRadio application manages access to, and the exchange of data with the radio-nodes. Relevant configuration files are defined for each console using the SoftRadio ConnectionsSetup utility. Each file can include entries for both UDP and TCP nodes.

Networks within one Local LAN subnet (UDP)

UDP allows nodes on a local LAN subnet to send messages (datagrams) to other hosts without first negotiating transmission channels or data paths. UDP uses a simple transmission model with a minimum of protocol ‘overhead’. The protocol is transaction-oriented, stateless and supports datagrams. The absence of retransmission delays makes UDP ideally suited for streaming applications such as audio. Unidirectional communication is very efficient in UDP. The ability to send broadcasts is ideal for status updates and the management of the resources across the system. Devices, radio-nodes and consoles co-located on the same local LAN subnet are referred to as being ‘local’.

Figure 64 Radios and consoles in one local LAN subnet – connection via UDP

Primary Local LAN Subnet (UDP) All nodes are local

Primary Network (e.g. Analogue and TETRA)

SoftRadio Operator Consoles

Local radio-nodes can be accessed by up to 99 local consoles at a time

UDP Traffic

Switch

http://en.wikipedia.org/wiki/User_Datagram_Protocol

http://en.wikipedia.org/wiki/TCP/IP

http://en.wikipedia.org/wiki/Datagram



In a local LAN subnet and using UDP, consoles do need not to log-in to a radio-node to transmit. Here the SoftRadio application manages access such that only one console can transmit at the same time. Similarly, RIUs can broadcast audio and status information continually and simultaneously to all SoftRadio consoles. In neither case is a dedicated network handshake and connection required as in TCP.

The disadvantage of UDP is that it can only operate within a local LAN subnet, or ‘broadcast domain’. For connections beyond a local LAN subnet, consoles and radio-nodes must connect via TCP over a router or gateway. Datagrams and broadcasts cannot pass through a router and are not supported in TCP.

Networks beyond a local LAN subnet (UDP and TCP)

TCP provides end-to-end connectivity across multiple subnets and network segments. It specifies how data is packetized, addressed, transmitted, routed and received. TCP involves four layers. The link layer contains communication technologies for a single network segment (link). The internet layer connects hosts across independent networks, thus establishing internetworking. The transport layer handles host-to-host communication. The application layer provides process-to-process application data exchange. Commensurate with the more complex and ‘unknown’ transport channels, TCP also provides enhanced error checking and redundancy including as needed retransmission of packets. TCP obviously involves significantly more overheads, which in turn can add substantially to the traffic-load on the network.

Figure 65 Radio-nodes and consoles in different subnets – connection via TCP

The disadvantage of TCP is that it does not allow datagrams, and information broadcasts. Each RIU can handle only one TCP connection at a given time. Status information and audio from non-local radios cannot be broadcast to multiple consoles via TCP. Only the console ‘logged in’ to the RIU receives the information. The retransmission of packets to overcome transmission errors degrades the ability to stream real-time data such as audio.

It is important to remember that ‘local’ always refers to relationship between nodes (RIUs, consoles or other devices) on the same local LAN subnet. There can be one, or more local subnets in a LAN network. Each subnet forms its own group of local nodes. Connections within a local group are in UDP.

Data-transport beyond a local group is via a TCP connection, for example between nodes on different subnets, or to and from nodes connected via WAN or Internet.

Router Radio 1 & 2

Radio 3 & 4

Radios 1 through 4

Non-local radio-nodes can be accessed by only one (1) console at a time



Figure 66 Two radio networks, each on their own local LAN subnet (two separate groups of local nodes)

Even though radios or consoles may be within the same geographical site or even the same building, in network terms they are only ‘local’ if they are on the same subnet. To avoid confusion, the term non-local is used to describe nodes beyond the relevant subnet. The term ‘remote’ is used to describe the geographical or physical location.

Quality of Service comparison UDP vs. TCP/IP

Quality of Service (QoS) overall is not measurably impacted by whether UDP or TCP is used as the RF channel is the ‘weakest link’. Performance tests have shown that regardless of the transport protocol used, QoS (audio-to-audio) is measurably improved compared to a direct radio-to-radio connection. The improvement is gained in the analogue to digital conversion performed in the RIU.

Radio Server and Network Repeater further improve QoS, and also reduce protocol overheads and measurably reduce traffic load.

Mixed RoIP network topologies

As with any IP-Network, a wide range of configurations and topologies are possible. Which configuration is used depends on the operational needs, organisational structure, build-out and other aspects often unique to the organisation. There are three types of mixed topologies for a RoIP network:

A. Local consoles on one local LAN subnet, with local and non-local radios (via LAN, WAN, or Internet) B. Local radios on one local LAN subnet, with local and non-local consoles C. Local and non-local radios and consoles across network subnets and segments (type A & B)

The following sections describe the characteristics and limitations of each topology (when implemented without a Network Repeater or Radio Server).

Access between consoles and radios not local to each other is via TCP

Secondary Subnet – Local nodes via UDP

Primary Subnet - Local nodes via UDP

TCP

E.g. Primary: 192.168.10.XX

E.g. Secondary: 192.168.20.XX

Primary Network Secondary Network



Type A: Consoles on one local LAN subnet, radios local and non-local

Figure 67 SoftRadio network in a type A configuration (local consoles, local and non-local radios)

The above configuration is typical for a central command centre with distributed radio resources. Here the local consoles on the primary local LAN subnet must access the remote radio-nodes via TCP. Hence only the console that is logged on to a non-local RIU can send on, and receive the status and audio from that radio. Only when the first console breaks the connection, can a second operator log-on to the RIU of that radio. The other consoles are in effect ‘blind’ to the non-local radios.

Type B: Radios on one local LAN subnet, consoles local and non-local

Figure 68 SoftRadio network in a type B configuration (local radios, local and non-local consoles)

Distributed consoles are often needed where operations have large local sites such as mines, logistics hubs, or airports, and facilities or headquarters which are geographically separate. For example airline staff at an airport may have their own local radio network at the airport, while the airline’s headquarters may be located elsewhere. The staff at headquarters can access the radio-network and communicate with staff ‘on the ground’ via radio communications accessed through their consoles at headquarters.

Secondary Console


Internet/ WAN

Each RIU can only support one TCP access at a time

TCP

TCP

Primary Consoles

Remote Console

Non-local radio-nodes

TCP


E.g. Primary: 192.168.10.XX

E.g. Secondary: 192.168.20.XX

Internet/ WAN


Primary network - Local radio-nodes



Another application may be to use mobile consoles on tablets or laptops, for example when setting-up remote mining or exploration sites, or for emergency responders.

As described earlier, only local consoles can only access local radio-nodes via UDP. The other consoles need to access radio-nodes via TCP. Each RIU can handle one TCP connection alongside the UDP exchanges, hence the system can operate without limitations if there is only one non-local console. Where there are more than one non-local consoles, each of these can only connect to a radio-node when it is not connected to another console via TCP. Only the connected non-local console can receive status and audio data.

Type C: Both radios and consoles local and non-local (type A & B combined)

Often a radio network needs to be expanded to accommodate changing or growing operations. Figure 69 shows such a configuration where both radio resources and operators/consoles are located in different subnets, and some nodes are connected via external networks. The example shown here is typical for a multi-site operation with one primary and one secondary network, as well as a remote radio and console.

Figure 69 SoftRadio network in a type C configuration (local and non-local consoles and radios)

It is important to remember that because of the characteristics of the IP-Network, visibility and usability of non-local radio-nodes is limited to one console at a time without the use of a suitable network device.

Integrating TCP connected radios and consoles

SoftRadio Radio Server and Network Repeater are the ‘building blocks’ that enable the SoftRadio system to seamlessly integrate different IP protocols. They in effect replicate TCP connected nodes (non-local nodes) as virtual local nodes. This ensures that the functionality of the system is not limited by the structural characteristics of the IP-Network(s). While both Server and Repeater provide the same principle functionality, each is designed to best fit one of the two fundamental topologies:

• Network Repeater is suited to configurations where multiple local consoles need to access non-local radio-nodes (Type A)

• Radio Server is suited to configurations where multiple local radio-nodes are accessed from multiple non-local consoles (Type B)

• For mixed topologies, RadioServer and Network Repeater can be employed together (Type C)


Secondary Console Remote Console

Primary Consoles

Secondary Subnet – Local nodes via UDP

Internet/ WAN

TCP




SoftRadio Network Repeater

To manage and utilise the radio resources most effectively and efficiently, operators need to receive status information and audio in real-time. The ability to access, and receive information from radio-nodes concurrently is essential. This is not possible via a TCP connection as shown in Figure 67. Here only one of the two local consoles can connect to a non-local radio-node.

The Network Repeater resolves this limitation by replicating TCP connections to radio-nodes (non-local nodes) as UDP exchanges within the local subnet. The Network Repeater in effect creates virtual local radio-nodes for those radios located beyond the local subnet. This allows multiple local consoles to access, and receive information from these radios concurrently. The TCP overheads are also reduced, minimising the traffic load on the network. The Network Repeater is ideal for larger dispatch centres with radios and devices distributed across subnets, locations and network topologies, including the Internet.

Figure 70 Network Repeater basic application diagram

In the standard configuration the Network Repeater replicates up to 60 TCP-connected radios as local radio-nodes. The LE version handles up to 8 TCP connections. The number of local consoles is not limited. Network Repeater is delivered as a Windows software package.

The Network Repeater application is installed on a suitable PC or Server connected to the local LAN subnet. Non-local radio-nodes are configured to connect via TCP to the repeater. Connections are defined by the IP-address and Radio ID set in the RIU. The local consoles access the Network Repeater rather than the nodes connected via TCP. The consoles are configured to connect to the Network Repeater via UDP and using its IP-address instead of the IP-address of the destination RIU (performed in the SoftRadio ConnectionsSetup utility).

The radio-nodes connected via the Network Repeater are differentiated by their Radio ID. The consoles in the local subnet now connect to both the radios connected via the repeater and those within the local subnet using UDP.

Non-local radios connect to the Network Repeater via TCP

SoftRadio Network Repeater

Local consoles access non-local radios via the Network Repeater using UDP

TCP

Primary Subnet - Local nodes via UDP Internet/

WAN

UDP



SoftRadio Radio Server

The Radio Server operates as the name states, as a server. In a local LAN subnet, each RIU or radio-node (or other connected SoftRadio device) sends out the status and audio data to all consoles via UDP – which it cannot do via a TCP connection. Figure 68 depicts a configuration with two non-local consoles and four local radio-nodes. As it is, this configuration would allow only one of the two non-local consoles to connect to each radio-node. The console not connected will not receive status and audio information, and is not able to send on the radio-nodes connected to the other non-local console.

Figure 71 Radio Server basic application diagram

Radio Server resolves this by allowing multiple simultaneous TCP connections to the radio-nodes attached to the server. The local radio-nodes connect to the Radio Server via UDP, allowing broadcast, concurrent access and the use of datagrams. On TCP side, the server in effect expands the number of network sockets available to non-local consoles, allowing multiple virtual TCP connections to a RIU or radio-node.

The RadioServer can handle up to 32 local radio-nodes and up to 32 non-local consoles. A maximum 64 connections are allowed, e.g. 2 consoles connecting to 32 radios (2x32=64) or 8 consoles connecting to 8 radios (8x8=64).

Radio Server is ideal for operations that require distributed operators and consoles to be able to access the centralised radios, for example logistics personnel at headquarters that support a remote mine site.

Example configurations

The following diagrams provide typical example of radio/RoIP network topologies to suit different operational needs.

Figure 11 and Figure 12 are examples of typical network topologies. They are also good examples of stages in the build-out of a larger radio network. Often operations experience the need to add radios, or consoles, but creating a whole new site is often not needed at that time. SoftRadio allows to evolve the network over times, either radios or consoles can be added first as shown in the two previous examples. These can be complemented at a later stage by adding consoles or radios, respectively. Adding a Radio Server to the new site as shown below creates a fully integrated two-site SoftRadio network.

SoftRadio Radio Server

TCP Primary Subnet - Local nodes via UDP Internet/

WAN

UDP Radio-nodes connect to the Radio Server using UDP

Non-local consoles connect to the Radio Server via TCP

http://en.wikipedia.org/wiki/Server_%28computing%29



Figure 72 Type A example – Main Site with distributed radios and radio-users using Network Repeater

Figure 73 Type B example – Main Site with distributed consoles and operators using Radio Server

Remote Radio (e.g. Airband)

Secondary Network Primary Network

Main Site

Network Repeater Communicate concurrently with all radio users, local and non-local

Internet/ WAN

Radio Server

Internet/ WAN

All consoles access radios concurrently, local and non-local

Radio Network

Off-site Operators

Main Site



Figure 74 Type B example – Two ‘independent’ sites with cross-site access using two Radio Servers

Often the next stage involves adding remote radios and further operator access. For example operations may need to monitor remote radio-traffic such as Airband or Maritime. Or they may need to add operator consoles at an off-site facility. Or an airline, mining or logistic company may want to allow staff at headquarters or technical support department to communicate with radio users directly. The applications are of course various.

Being able to build on the existing infrastructure, and extend the useable life of existing assets is a substantial contribution to achieving maximum cost-efficiency and ROI/ROA, and of course ROIC.

As well, enabling operations to seamlessly integrate different functions (departments), radio-networks, non-radio communication channels and operational systems greatly enhances productivity and performance. Arguably one of the main benefits of SoftRadio’s modular structure is that the build-out does not need to defined, nor budgeted for from the beginning. Instead, operations can add to their network as the needs and requirements evolve.

Figure 75 provides an example of how SoftRadio’s modular structure has been applied to meeting an organisation’s needs to evolve and build-out the radio network in line with the evolving needs and operations.

Network #1 Network #2

Radio Server Radio Server

Concurrent communication between all consoles and radios



Figure 75 Type C example – Distributed consoles and radios using Network Repeater and Radio Server

A further build-out for example may include:

• Adding a Radio Server to the Secondary Site allows all consoles to access those radios concurrently, including mobile consoles

• Adding a temporary site and radio-network for example via a microwave/satellite WAN link, which can be accessed from the main site

• Adding a Network Repeater to the Headquarters consoles, allowing staff to access all radios across the entire network, with the option to add an intercom function between the Main Site and HQ consoles

Primary Site Secondary Site

Radio Server

Network Repeater

Access all radios (primary, secondary & remote) Provide other consoles access to local radios

‘Off-Site’, e.g. HQ

Internet/ WAN

Remote Radios

Mobile console via WiFi/Cellular

Access local radios, and radios in primary network via the Radio Server, and remote radios via the Network Repeater

Access radios in primary network via Radio Server, secondary and remote radios via Radio Server/Network Repeater



11.SoftRadio System Administration

SoftRadio is based on a modular design and applies principles of distributed intelligence or distributed processing. RoIP Interface Units and operator SoftRadio consoles operate independently of a centralised control system. Each RIU and SoftRadio ‘node’ can continue to operate when others nodes ‘go down’. A RIU is programed with the relevant information when it is set-up for the specific network it is deployed into. Consoles are set-up using configuration (.ini) files that reside on the PC the SoftRadio console is installed on. The RIUs are typically configured when set-up as a radio-node (RIU, radio model and location). If required the RIU can be re-configured by using the Interface Setup utility. The SoftRadio console application resides on a PC in the network. Configurations can be administered locally using the ConnectionsSetup utility, or from a central location by administering the configurations files (.ini files) on the relevant console-PC. Other devices such as Network Repeater or Radio Server are administered in the same manner. A complete SoftRadio System Administrator manual provides detailed information and is of course provided with an implementation of a RoIP Network.

SoftRadio Network Monitor

SoftRadio Network Monitor provides an efficient means to monitor the status of the SoftRadio Network and its nodes. SoftRadio Network Monitor combines a proprietary SoftRadio InfoServer with the Nagios® Core open source IT monitoring and alerting platform. The Nagios Core application provides the front-end (user interface and function) while the InfoServer delivers provides the ‘raw’ information form the network to the Nagios application. For detailed information see SoftRadio Network Monitor.

Figure 76 Graphical status display for SoftRadio network

http://www.nagios.com/

http://testadvance.com/wp-content/uploads/resources/SoftRadio-Network-Monitor.pdf



A graphical user interface displays the status of the network nodes (consoles) in both map-style and in table and message form. Map-style displays provide a graphic of the SoftRadio network and the status of the nodes – green/’Up’ and red/’Down’. An additional warning status can be configured and displayed. Each map displays a limited set of node information and messages in a pop-up screen when a node is selected.

Tabular displays provide both an overview of the system and individual nodes. List-style displays provide details on status, status message and services and service messages. Service(s) provides key information on the network operation and on the SoftRadio operation. The detailed information can be accessed from the two map style displays by selecting a node. The below depicts a screen-shot from a recent installation.

Figure 77 List/tabular display for entire SoftRadio network

Key functions or features of SoftRadio Network Monitor:

• The monitoring system provides alert messages that can be sent via e-mail and/or SMS • The monitoring system is configurable. Configuration files are provided pre-defined and as

templates. Configurations can be maintained in structured groups that reflect the network configuration



• The monitoring system is readily expandable. Objects can be added and Object Definitions amended by editing the appropriate files, e.g. to add additional consoles, radio-interfaces (RIU’s) or network elements, and/or to modify or add status and services definitions

• The editing and maintenance of the monitoring system can be undertaken by system administrators and training can be provided

• The monitoring system can be provided pre-installed on a server with key network configurations and status and service definitions pre-defined

• All radio devices are checked for connectivity (ping) and that the firmware in the network interface is running

• All operator PC’s are checked for connectivity (ping) and that their SoftRadio client is running • Servers are checked for connectivity, for loading and storage space (disc) • Routers in the LAN/WAN can be checked if they have their own IP address • A wide variety of historical data can be accessed and displayed

SoftRadio Network Logger

The SoftRadio Network Logger is a trouble-shooting utility. The utility program logs information on key types of data that are received from the RoIP interface unit (RIU). The utility allows the system administrator to locate where data is possibly ‘lost’ in the network and equally, whether the data is provided correctly by the RIU in the first place.

Network Logger displays the IP-address and ID for the connection (RIU) and three LED indicators. The three ‘LED’ show whether:

• ‘Status’ is received • ‘Display’ data is received • ’Audio’ is received

The utility operates similar to the SoftRadio consoles. Network Logger creates panels for each RIU (radio) that is monitored and displays the following:

• RIU (radio) is receiving (Rx) by turning the panel background for that RIU yellow • RIU (radio) is transmitting (Tx) by turning the panel background red

When audio is received the background will indicate in yellow and the Audio Led will activate. Ticking the check-box on the panel starts the logging for that particular radio. Data is logged to the file displayed on the panel (see ID 101 in Figure 78). The log-file records relevant information on data received from the RIU.



Figure 78 SoftRadio Network Logger display panel

SoftRadio Handbook 2015/16 - Testadvance · Motorola MotoTrbo DM4600/01 and DM3600/01 ... Nexedge...

Documents

Transcript of SoftRadio Handbook 2015/16 - Testadvance · Motorola MotoTrbo DM4600/01 and DM3600/01 ... Nexedge...