The original version of the C-Soft console from Telex-Vega provided a user interface much like the user interfaces
standard and Vega s standalone desktop console. With the release of Version 3.0, the radio technician is now able
to completely define the look and operational characteri
of Vega VoIP products, C-Soft represents another method for controlling a radio network utilizing standard
computing equipment.
The C-Soft software console is protected from copying by the use of a security dongle attached to either the parallel
printer port, or to a USB port. Software updates are freely available within the same version family by simply
downloading them from our website at
www.vega-
stics of the radio operator s interface. With an infrastructure
signaling.com.
2 Computer System Requirements
6
Operating System:
Sound System:
Network Connection:
Processor Speed:
Memory:
Full Duplex windows compatible sound system. Sound Blaster or HW
Celeron 500 or greater especially if controlling P25 radios or large numbers of
Windows 2000 or XP required.
compatible recommended.
10 Mbps or 100Mbps TCP/IP connecti
radios.
Minimum of 256Mbytes recommended
on. Constant IP address preferred.
7
3 Software Installation
There are several steps to installing the C-Soft p
onto the computer and setup shortcuts to them.
3.1 Program Installation
Step 1:
Open Windows Explorer and create a new subdirectory under the root directory called C-Soft. This can be
accompli
right pane, right click on an open spot and select New->Folder. The folder will appear and allow the user to enter a
name for the new folder. Use C-
shed by selecting a local hard disk drive (typically drive C:) in the left pane of Windows explorer. In the
Soft. See
ackage on a computer. The first is to copy the manual and program
Figure 1 for creation of the directory.
Figure 1 Adding a Directory for C-Soft
Step 2:
Copy the files CSoftRuntime.exe, CSoftDesigner.exe and C-Soft Manual 25.pdf from the included CD in
the newly created directory. Also copy C6200F_Default.veg into the new directory.
Step 3:
Create a shortcut on the desktop to open the CSoftRuntime.exe, CsoftDesigner.exe, and the Adobe .PDF
formatted document file. Telex-Vega suggests that the user
A copy of the Adobe Acrobat reader is included on the CD if it doesn t already exist on the users computer.
3.2 Driver Installation
Before the CSoftRuntime.exe file can be executed from the desktop Icon created in Section 3.1, a driver to allow the
to
print out a copy of the manual for reference purposes.
8
program to access the security Dongle must be loaded.
installation of the driver.
setup wizard as it executes. A standard installation is the normal install and only a qualified IT professional should
attempt to use the manual install. The user will have to restart their computer after the installation of the Dongle
dri
ver is completed. Additional information on the driver installation can be found at
http://
www.rainbow.com
be installed. This al
the need for a licensed copy of the software. The output of the designer software is a file that is loaded by the
runtime program when it is started.
3.3 Initial P
After the successful installation of the program files, documentation, and dongle drivers, check the installation be
executing CSoftRuntime and CSoftDesigner. Each should load and run. A predefined screen will be executed by
the runtime sof
tware.
Execute file SPNComboInst1.0.5.exe included on the CD. Follow the dir
/support/eu_support.htm. The CSoftDesigner.exe program does not require the dongle to
lows the person responsible for the dispatcher s console interfaces to do screen design without
rogram Launch
3.4 CSoftruntime.exe Default Load File
By default the C6200F_Default.veg file is searched for in the same directory as the CSoftruntime.exe program. If
the file does not exist in the directory, no screen design is loaded and the console does not functi
recommended that the screen designer save designs under descriptive names and only save out the default load
filename when a design is ready to test.
Starting in version 2.52 the CSoftruntime.exe file will recognize a command line filename to lo
default name of C6200F_Default.veg. A short cut can be created to run a different screen design from the desktop
or the file type of .veg can be associated with CSofttunrime.exe so that the .veg files can be double-clicked from
anywhere
and cause the design to execute.
Make certain that no USB dongle is connected during the
ections of the
on. It is
ad instead of the
3.5 Initial Volume Control Settings
The volume control, normally resident in the tray, is used to control audio
output and input. The settings of these controls is crucial to the operation of
the software console. There are
volumes, and the other is the recording volumes. The playback volumes are
brought up by double clicking on the speaker in the system tray. Generally
the main and wave volumes are set to max as C-Soft will be used
the actual speaker levels. The other important playback setting is to mute
the microphone. Not muting the microphone will cause the microphone
audio to feedback from the speakers. The settings for playback should look
like
Figure
2.
The recording settings are accessed by going to the options menu, selecting
properties, changing the radio control to recording, and then pressing OK.
The microphone input is u
used with the microphone input. The microphone should be the Selected input
and the volume settings should be around the second tick. Figure 3 shows the
general playback settings.
two sets of settings, one is the playback
sed by C-Soft. The HB-3 alignment procedure is
to control
Figure 2 Playback volume settings
F
igure 3 Record volume settings
4 Communications System Design
Setup of the C-Soft console involves understanding your radio network and how the various radios and console are
setup within it. It is very important that a complete roadmap of the locations of the radios and consoles be
determined before configuration begins. This includes the multicast address involved as well as the port number for
each channels TX and RX communications. It is also necessary to know the base IP addresses assigned to each
console or radio on the network for administration purposes. An excerpt from the Vega IP White paper is included
here to help the user understand how the network portion of the system works.
9
4.1 White Paper Excerpt
4.1.1
Telex Vega sells a full line of tone control consoles and radio adaptors. This technology requires an analog
connection between each console and each radio. Each console that needs to control an individual radio is wired in
parallel to allow multiple op
console positions and multiple radio channels, an entire rack might be devoted to bridging audio to all interested
parties. In addition, due to loading of multiple consoles on a particular circuit, additional bridging hardware might
be required, increasing wiring and tuning of the system for acceptable performance. The Ethernet based IP network
solves many of these issues and provides for a number of other services t
4.1.2
Radio over IP, being a subset of Voice over IP will be referred to as VoIP generically throughout this document.
VoIP is a method for breaking analog audio up into packets that can be transferred over a computer data network.
Because of the packetized nature of Ethernet, the audio is generally broken up into 10-40ms chunks of audio,
compressed, and placed onto the Ethernet. The nodes of the network are then free to utilize or ignore any
combination of packets. If a particular audio stream is of interest, the stream of audio packets are captured,
uncompressed, converted back to analog, and played on available speakers.
Given the popularity of the Ethernet based network, many companies and agencies already h
or Local Area Network (LAN). Beyond that, a large number of companies exist to provide Wide Area Network
(WAN) connections between sites with significant distances between them. The WAN connections can be used to
connect offices across the street from one another, around the world, or anywhere in between. Possibly the best
thing about these connections is that they may already exist. In many cases WAN links are less expensive than a
comparable leased analog line, and they can car
The most compelling reason to consider basing the next radio control system upgrade on VoIP technology is the
simplification in wiring requirements. Instead of needing to bring a pair or more of wires, per channel, to each
console, only a single connection to the Ethernet is required. Since the Ethernet can easily handle dozens of
simultaneous connections it becomes the only pipeline required for all communications requirements.
Tone Remote Control
erator positions to monitor and control the same radio. For a large system with multiple
VoIP Radio Control
hat were not possible before.
ave an existing network
ry more conversations simultaneously.
4.1.3
The network optio
will sell many of the components for both a wired or wireless network solution. For more advanced network
applications, an in house or external network hardware source may be required. These sources of information will
be able to help with the design of the network as well as provide sources for advanced networking equipment such
as routers and hubs from Cisco and other network vendors. This section is an ove
on the top of the Ethernet network.
4.1.4
Ethernet is itself a network. It has a low level method for transferring data from one location to another. Source and
destinations are based on the MAC address which is embedded in the Ethernet interface. The MAC address is
unique for all devices in the world and cannot be changed. The IEEE controls the allocation of the MAC addresses.
The definition for Ethernet includes requirements for interoperation at speeds of 10 and 100 Mbps. Higher speeds
are available but generally have not filtered down into end user equipment. It is upon this base that higher level
protocols such as IP are based.
IP Operation Overview
ns today have essentially converged on Ethernet. A local Best Buy, Office Depot, or Radio Shack
Ethernet as Physical Layer
rview of the protocol that operates
10
4.1.5
TCP/IP is the best-known protocol for use in computer communications. It is the basis for communications on the
Internet and World Wide Web. It is a guaranteed method of transferring data between two computers. Being
guaranteed means that for every packet of information transferred from one computer to another an
acknowledgement packet is returned. Additional handshaking is utilized from the outset of the data communications
to guarantee both ends of the connection. Because of this guaranteed communications and its implementation
utilizing handshaking (no other method is available), TCP/IP adds a great deal of overhead to data communications
that is not desirable for audio traffic over a network. This is where UDP/IP finds is acceptance.
UDP/IP has existed just a long as TCP/IP as an unreliable method of data communications. The term unreliable
should not be thought of as a problem for audio communications over a network connection. UDP allows for a
computer to send a packet of data to another computer without the handshaking sequence required within TCP/IP.
Because of this, the computer that sends the packet has no confirmation that the packet arrived at its destination.
While the loss of packets can be a problem, it generally is accounted for when the UDP application is developed. In
the case of VoIP, the loss of a packet which only contains 10-40ms of audio is not a problem as the human ear
generally will ignore the loss of that small chunk of audio. In addition, programmers play tricks to make this loss of
information difficult to detect to the human ear. The largest single factor in the lost of UDP/IP packets is network
design and loading. As long as a network is well designed with capacity for all of its chartered requirements, packet
loss will not be an issue. Because of its lower ove
for VoIP development.
4.1.6
Multicast is an extension to UDP/IP. It enabled one computer to broadcast data packets that has multiple recipients.
This is an ideal model for radio communications when multiple people need to monitor the audio. A single VoIP
connected radio is setup to broadcast multicast VoIP packets when receiving audio. Since the multicast packets can
be received by any interested party, all consoles that are
playback. In addition to simplifying monitoring of audio traffic by multiple listeners, multicast also greatly cuts the
bandwidth requirement on the network. Instead of having to regenerate the received audio into a UDP/IP data
stream to each individual monitor, which would use the bandwidth times the number of monitoring consoles, a
single data stream is generated and monitored by all.
TCP/IP and UDP/IP
Multicast UDP/IP
rhead and its ability to Multicast, UDP/IP is the protocol of choice
monitoring the audio can receive and decode the packets for
Implementation of Multicast protocol requires a few things for seamless use on a network. First the clients must all
support the protocol. This is accepted as given since all Vega products utilize multicast for audio communications.
The next issue to consider is if the network infrastructure supports multicast.
Multicast packets are defined to be all packets with a destination address of between 224.0.0.0 and 239.255.255.255.
Some are commonly used for broadcast audio and are not necessarily available. When a computer opens a UDP/IP
port within this address range, it will also join the group. By joining the group a packet is sent out to all addresses
saying that it is interested in seeing the traffic on this particular multicast address. Routers that receive this
broadcast message to join a particular multicast address will then pass packets through because the router is now
aware that a listener is interested in this traffic. The routers utilized in the network must support this. The protocol
used to alert routers to parties who are interested in certain multicast address traffic is IGMP or Internet Group
Management Protocol. The Vega products support IGMPv1 as defined in RFC 1112.
In addition to the joining of multicast broadcast groups, clients on the network can also specify a packet time to live.
The time to live (TTL) is the number of routers that the packet will go through before being stopped. As an
example, the time to live for a particular broadcasting node on the network is set to 3. This means that when a
packet is transmitted, it will arrive at the first router in the network. This router will examine the TTL value in the
packet and determine if it should pass it through since it is not zero. When it passes the packet, the router will
decrement the TTL value by one to a value of 2. The next router encountered by packet will do the same reducing
the value of TTL to 1. The next router does the same and the TTL is now 0. The next router the packet reaches will
examine the TTL value, see it is zero, and the packet will not be retransmitted. Se
for packets to get from one host to another on a large network, but will also add additional bandwidth requirements
due to the larger number of packets being transferred.
tting a large TTL value may allow
11
4.1.7
As mentioned earlier, Telex Vega utilizes Multicast for all audio communications. In addition, typically only one
Multicast is used for all traffic. In addition to a valid Multicast address, a port number is required. The port is an
additional two bytes of information ranging between 1025 and 65535 that further specifies how the data traffic
should be handled. Assume for a moment that the base multicast address chosen is 225.8.11.81. Port 1054 is used
to distinguish channel 1's RX traffic. Port 1072 is used to specify channel
for RX and 1073 for TX traffic. By making each channel s TX and RX ports different and unique, full duplex audio
can be supported and many channels of traffic can be supported using only one multicast address. It is also through
this method that a single console can pick and choose the particular radio resources available on the network without
concern for what the console right next to it is utilizing.
4.1.8
TIA is the organization with
participate in this standards organization. The interface of choice for connecting infrastructure radios has become
Ethernet. This is the first standards body to address Radio control over IP. The standard is evolving and as of the
writing of the manual appears to be the only widely accepted standard for IP based radio control.
4.2 Network Requirements
4.2.1
Each VoIP channel requires 50kbit of bandwidth when active. A
50kbit of bandwidth during the transmission. When the transmission ends, the bandwidth will no longer be
required. If the conversation is a full duplex conversation, audio in each direction, then 100kbit of bandwidth with
bill required. 50kbit for each direction. Some radio systems will give go-ahead beeps when it is clear to talk, if the
dispatcher is going to hear them, it must be a full duplex conversation. The full duplex bandwidth may only be
re
of the transmission. When utilizing a PIB223 or C-6200 for a telephone connection, a full 100kbit is required since
it is a full time full
Vega Port Centric Method
1's TX traffic. Channel 2 might use 1055
P25 and Initial Radio Standards
in which the P25 radio standards have been developed. Most major radio manufacturers
Bandwidth
quired for the first few seconds of the conversation due to the brief nature of the go-ahead beeps at the beginning
duplex conversation.
transmission from a console to a radio will require
4.2.2
In general, the Telex-Vega system requires multicast to function. The network must be able to create a static
nailed-up multicast address. The multicast must be accessible at all times. It is very common for networks to
enable multicast for a period of time after an IGMP join message is sent out, and then prune off branches after a
period of time. Because of the nature of two-way radio and its intermittent usage patterns, this can create a
significant problem where the system appears to work flawlessly for a period of time and then no longer works. In
the Cisco world, ip pim dense-mode is generally recommended, sparseimplemented effectively. It is also generally a good idea to explicitly join the multicast group with a ip igmp staticjoin X.X.X.X command.
4.2.3
IGMP can be used to control where multicast is allowed to propagate to. This should generally be limited to subnets
utilizing C-Soft as the dispatch console, and only when used on an intermittent basis. That is, when C-Soft is used
for a while and then shut down. If a console is expected to be operational at all times on a subnet, then that subnet
should have multicast nailed up and active at all times.
4.2.4
The
delay added by the network. Delay does not cause issues, but variable delay (jitter) does. Jitter in a network cannot
exceed the maximum packet buffer of the individual products buffers. See each product manual for this
specification. As an example, the IP-223 can handle about 600ms of network jitter. For good audio quality, no
more than 5% of all packets transmitted should be lost. This is an absolute maximum, exceeding this value will
cause poor audio quality and system performance and in general practice packet loss should be much less than 1%.
Multicast
IGMP
Network Performance
network should perform well under all loading conditions. The default delay of the audio is 120ms, plus any
dense
-mode can also generally be
12
5 Communications Screen Design Reference
5.1 Overview
The program, CSoftDesigner, is used for the creati
sliders, text, and popup windows are dynamically placed onto the screen. These elements are then configured to
operate on particular lines. The user of the design software can place the elem
include or omit functions based on the requirements of the system and the end operator of the console.
The first step in the process of creating a user interface is to define its interactions with your IP network. This
includes knowing the RX and TX port of each radio, the multicast group(s) utilized, the number of radios to control
and the frequencies that they might be using.
on of the dispatcher screens. Various combinations of buttons,
ents in any location desired and can
5.2 Notes on Window Sizes, Locations, and Shutdown, and saving
the console state
By default, desi
system, it may not be acceptable if only a small window is to be presented for radio control on a single monitor
system, or if the dispatcher is to run the
be taken to ease the design and execution of the software in these special cases. A general procedure follows, some
experimentation may still be required.
1) When CSoftDesigner is ex
2) If the design is new, create the design. If an existing design is being edited, step 1 should be completed
gner and runtime expand to fill the entire screen. While this is fine in a single monitor dedicated
of the designer window to match that of the window that should be presented to the dispatcher for the end
design. By doing this, all of the buttons will scale to the d
executed with the design.
before loading the design to edit. For initial designs, it is recommended that th
maximize, and close buttons be left enabled.
screen design on a multi-monitor computer. Because of this some steps can
ecuted, it will expand to fill the entire screen. The first step is to change the size
esigned size when CSoftRuntime is later
e resize, minimize,
3) Once the design looks as it should on screen in the designer application, save the file into the location from
which CSoftRuntime will execute it.
4) When CSoftRuntime is executed it looks for a
is shutdown. It stores the size and position of the CSoftRuntime window when it is closed. The first time
the program is run in a new directory, the cposi.txt file will not exist. CSoftRunt
whole screen. Assuming that the controls to resize and position the window are still active, position the
CSoftRuntime window to the location where it should always run from. The buttons will not rescale to this
window and som
of the window is what is being created. Once the size and position is approximately correct, close the
CSoftRuntime program, the cposi.txt file will be updated.
In
addition to storing the position information of the window, starting in version 2.90, cposi.txt also stores
the console state at shutdown. It stores the selected channels, mute states, volumes, channel frequencies,
and the entries in the call log (without
is started up, it is likely that these line states won t match.
5) Run the CSoftRuntime program again. The window should return to its last location and size with the
buttons, sliders, VU
6) Variations on this process can be attempted to get desired results. Once a size and location is determined,
the cposi.txt file can be made read only by adjusting its properties. The user may still be able to resize
window, but each time CSoftRuntime is executed, it will return to its original location.
When C-Soft is shutdown, in addition to the size and location of the window being stored in cposi.txt, the
current console state is stored. This includes selecte
audio stored, only the entries).
e may be hidden from view by this process. This is not a problem as the size and position
Meter, and clock in correct locations.
file called cposi.txt. This file is written when CSoftRuntime
ime will expand to fill the
the IRR audio). If one console design is shut down and different one
the
d status, mute status, channel frequency, and the call list (no
13
5.3 IP Parameters Setup
Figure 4 IP Parameters Setup Screen
The first option under the Edit menu is the Setup IP Multicast List opti
dialog box shown in
The dialog box contains some data. If no file has been loaded to edit and no changes have been ma
state has Line 1 as the only line enabled with only one Frequency enabled (F1). The designer should go through and
enabled all lines that this console position will have access to as well as the frequencies allowed for each line. Many
of
the dialog boxes associated with the setup of the user interface elements depend on this setup. If a line that is
later required is not enabled from this dialog box, it will not appear as an option for setup. The same is true for
frequencies associated w
would then allow or disallow their selection in subsequent operations. Each of the columns are defined in the
following sections.
5.3.1
This setting is used
before playback, the more the console software can do to compensate for lost and delayed packets. The greater this
value, the more delay is introduced before
into a delay of 120ms before playback. (Each packets is 20ms of audio.) The speed of the PC, its sound card type,
and the operating system it is running all affect the delay be
parameter.
5.3.2
Three types of lines are currently available for control. One of them is None, in other words, no line is enabled. The
second option in the drop down dialog box is for a line type of Vega. The Vega setting is used to be compatible
with Telex
option. This option is compatible with the EF Johnson 2600 Series repeater. The forth option is
option allows the console to access a telephone line from across the network. From this option, other options are
selectively enabled or disabled.
Packet Delay
Line Type
-Vega s Radio control over IP products such as the C-
Figure 4, and is generally the first step in creating a new screen design.
ith the line. The designer can return to this dialog box at any time to make changes which
to compensate for network delays, jitter, and lost packets. The more packets that are buffered
on. Selecting this option will open the
de, the default
playback of the audio begins. A typical initial value is 6. This translates
fore playback and is beyond the control of this
6200 or the IP-223. The third option is the P25
Phone. The Phone
4
1
5.3.3 Line Number
The Line Number is the logical number of the line in the system. In most cas
dependent on the names given in the later fields, but a couple of items do refer to this logical number. No editing is
possible for this entry.
es, design of the console screen is
5.3.4
The RX and TX Multicast Addresses are used as
number must be between 224.0.0.2 and 239.255.255.255. All devices that are to interoperate on this channel must
have the same respective Multicast Address for RX and TX channels. Generally,
enabled equipment, one multicast address is used for all channels with the port number defining the TX and RX
channels.
Conversely, on some P25 types of equipment, it is common to use different Multicast addresses and sometimes
same address for each several different lines. In this case, differentiation between the two lines traffic is completed
by reviewing the NAC value.
5.3.5
These numbers must be unique, per channel, and be greater than 1024. As an example, co
Figure 4. The RX Port is 1054 and the TX Port is 1104. All consoles that wish to monitor receive audio for channel
1 must have their Base Multicast address set the same as well as the same RX Port number. The
audio. Any console on the network that wishes to transmit must set its port number to 1104 to cause the radio to
keyup.
For the EFJ P25 option, the port number should be set to 10110 at all times for both TX and RX Ports.
5.3.6
The Time to Live value represents the number of routers the multicast audio packets will go through before being
stopped. Network design will dictate this value. If audio is not reaching a particular node on the network,
increasing this value is one opt
5.3.7
The TX Monitor enable allows the user to monitor other TX traffic being sent from other console operators.
RX and TX Multicast Addresses
RX and TX Ports
TTL-Time To Live
TxMon Enable
ion that might be tried.
the broadcast address for all audio traffic. This dotted quad
when dealing with Vega VoIP
the
nsider Line 1 above in
same goes for TX
5.3.8
The Talk Group option is only available for entry when the line type is EFJ P25. This is the Talk Group value that
will be embedded into this lines transmission.
5.3.9
The NAC is the Network Access Code and is only available when the line type is EFJ P25. This will be the value of
the NAC that is sent when traffic is generated on this line. In addition, the NAC is used to route receive audio to a
unique channel based on the NAC value received from the repeater.
5.3.10
The Scanable column is used to allow a dispatcher to control the scan list of a particular radio. As of publication of
this manual, only the Kenwood x150 and x80 series support this functionality. If this box is checked, not only does
the scan button function, but the frequency buttons for this line can be right clicked and the channel be added or
deleted from the scan list. Se
Talk Group
NAC
Scanable Column
e the frequency change button description for more information on this feature.
15
5.3.11
The Autofill button allows the console designer to quickly fill
blocks of lines with information. This button can be used to
eliminate repetitious data entry by hand. The function will
automatically increment the RX and TX port numbers as it fills
in the lines selected.
Autofill.
Autofill
Figure
5 shows the dialog box used for
Figure 5 Autofill dialog box
16
10.7.100.200:1074
Echo1: RX 10.7.100.200:1054 TX 10.7.100.200:1072
Echo2: RX 10.6.100.200:1055 TX 10.6.100.200:1073
5.3.12 Echo Packets Enable
The Echo Packet function allows the system to operate on networks that do not support multicast. It requires that
the C-Soft application be running at all times to translate and transfer packets from one IP address to another. A
might be a number of radios spread throughout a network. Since multicast is not supported, the
radio adaptors (IP-223s or C-6200s) are programmed to send packets to a specific static IP address; the IP address of
the PC running C-Soft with Echo Packet en
abled.
The general functionality of Echo packets is as follows. All traffic received on the address of the RX packet, which
was typically multicast, but under this scenario is the unicast add
ress of the radio remote, is copied and output to the
RX Echo Packet address. In this scenario, the Echo Packet RX address would typically be the multicast address.
This enables the C-Soft to function as a gateway for other consoles on the same local net
work segment. The local
consoles transmit and receive the multicast address only and the C-Soft application translates and sends the packets
to the radio directly. The TX side works in a similar fashion except that packets received on either address are
echoed to the other address and when the C-Soft transmits, it sends to both ports simultaneously.
Figure 6 shows an
example Echo Packet system. The example shows three different radios connected through a WAN. The WAN is
assumed to not pass multicast. In each of the subnets, a single copy of C-Soft is used to do the communications to
the radio within its subnet. A second console is used to echo the audio traffic to other copies of C-Soft on different
subnets. C-Soft will also
added to the system by specifying the multicast address only.
5.3.13
Freqs Button per Line
Pressing the Freqs button on a particular line will open the dialog box for the
dialog is shown in
this box will turn on and off the options for this frequency
echo all traffic to a multicast address within its subnet so that additional consoles can be
settings for that particular line. The
Figure 7. The first column in the dialog box is the Enable checkbox. Checking and unchecking
within the rest of the designer software as well as options
Loading...
+ 37 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.