RipEX is a best-in-class radio modem, not only in terms of data speed. This
Software Defined Radio with Linux OS is a native IP device which has been designed with
attention to detail, performance and quality. All relevant state-of-the-art concepts have
been carefully implemented.
RipEX provides 24/7 reliable service for mission-critical applications like
SCADA & Telemetry for Utilities, SmartGrid power networks or Transaction networks
connecting Lottery terminals or POS or ATMs.
Every unit can serve as the central master, a repeater, a remote terminal,
or all of these simultaneously. Anti-collision protocol on Radio channel allows
whatever traffic: master or even multi master-slave polling and report by exception
from remotes concurrently.
Thanks to the web interface anybody with basic IP knowledge is capable of
starting up RipEX within a few minutes and can maintain the network quite easily.
Take the opportunity to remotely access and test a live RipEX network. Contact us for access details.
Bridge mode - Packets received on any interface are broadcast to the respective
interfaces on all units. Packets received on COM are broadcast to both
COM1 and COM2 at remote sites, allowing you to connect 2 RTU's to each remote unit.
Router mode - RipEX works as a standard IP Router with 2 interfaces
(Radio and Ethernet) and 2 COM port devices without any compromise. There is
a sophisticated anti-collision protocol on Radio channel, where every single
packet is acknowledged. Moreover each unit can simultaneously work as a store-and-forward repeater.
Each packet is transferred as an acknowledged unicast
Sophisticated anti-collision protocol on Radio channel => simultaneous report by exception from remotes and multi-master polling
IP specialities
Terminal server
- 5 independent sessions
- encapsulates serial protocol to TCP(UDP) and vice versa
- eliminates a transfer of TCP overhead over Radio channel
- suitable for IP and serial RTU’s combination within one network
TCP proxy
- converts TCP into UDP
- TCP run only locally between connected device and RipEX on LAN
- only payload (user) data are transferred over Radio channel
- i.e. lower traffic on Radio channel, no more problems with TCP timeouts
Subnets
- unlimited number of virtual Ethernet interfaces
- IP aliases - more IP addresses on Ethernet interface
VLAN
- unlimited number of VLANs assigned to Subnets
- RipEX management can be done over VLAN
ARP proxy
- RipEX can simulate any IP address (typically RTU behind Radio channel)
- suitable for RTU’s without routing capabilities within the same subnet
Easy to configure
Basic IP knowledge is sufficient
Web interface
Service access via ETH or USB interfaces independently. (X5 - ETH/USB adapter with DHCP is used for USB interface)
Wizards - fast and simple setup
All configuration parameters within one page
Fast remote access - only the effective data from remote unit are transferred over the air, html page downloaded from the local unit.
Automatic Firmware and SW keys upgrade from flash disc
CLI via SSH
SW feature keys
SW authorization keys allow to use or to add advance features only when and where needed
Watched values (Can be broadcast to neighbouring units. Received info displayed in Neighbours table)
Device – Ucc, Temp, PWR, VSWR, *HW Alarm Input.
Radio channel – *RSScom, *DQcom, TXLost[%]
User interfaces – ETH[Rx/Tx], COM1[Rx/Tx], COM2[Rx/Tx]
* not broadcast
Statistics
For Rx/Tx Packets on User interfaces (ETH, COM1, COM2) and for User data and Radio protocol (Repeates, Lost, ACK etc.) on Radio channel
Graphs
For Watched values and Statistics
History (Statistics, Neighbours, Graphs)
20 periods (configurable, e.g. days)
SNMP
SNMPv1, SNMPv2
Trap alarms generation for Watched values
Monitoring
Real time/Save to file analysis of all physical interfaces (RADIO, ETH, COM1, COM2) and some internal interfaces between software modules (e.g. Terminal servers, Modus TCP server etc.)
Use our calculations for a simplistic overview of RipEX network performance. RipEX settings are common for both independent parts – Payload bitrate and Netwok performance. Payload bitrate gives you a quick and easy idea of the possible bitrate in the RipEX network. Network performance is the more robust and detailed option. See the details in respective helps.
Payload bitrate
Based on this calculation, one can see the effect packet length has on the resulting bitrate. Since the RipEX radio protocol overhead per packet is fixed, the longer the user data are, the higher the payload bitrate.
Average message size
bytes
User data size without any headers (IP, TCP, UDP, …).
Payload bitrate
kbps
The payload bitrate in kbps. Since RipEX uses customized IP packet on the Radio channel, payload bitrate includes 28 bytes of IP packet overhead – 20B IP header and 8B UDP header. This calculation assumes using the UDP as the Layer 4 protocol. If you are using TCP, the resulting bitrate would be lower due to higher TCP overhead – you can use our TCP proxy functionality to optimize the communication (see the Manual).
One-hop forwarding time
msec
The average time in milliseconds to transmit a single packet between two RipEX units.
Network performance
Network performance calculation is intended to give you a quick performance overview based on several basic parameters.
Total Number of sites
Number of RipEX units in the network. The minimum number of RipEX units is three (including the local unit). The calculations work with collision probabilities in the report-by-exception type of networks and are mainly intended for networks with many (> 5) units.
Average hops per path to remote
Average hop count to the remote sites. E.g. 9 remote stations directly connected to the center (one radio hop) and one remote station over one repeater (two radio hops) results in 1.1.
Average message size
User data size without any headers (IP, TCP, UDP, …).
center => remote
bytes
remote => center
bytes
Interface speed
Ethernet interface speed or the baud rate [bps] for the serial (COM) interface. Using TCP instead of UDP lowers the total network capacity due to the higher TCP overhead (ETH – UDP/IP and serial options are equal.
center
remote
Processing time
Time for the RTUs / SCADA devices to process queries.
center
msec
remote
msec
Polling Cycle (Single master)
Average RTT per remote
msec
Round Trip Time (RTT) is the time required for a packet to travel from the source (SCADA center) to the destination (remote RTU) and back again.
Total polling cycle
sec
The time required for the master (SCADA center) to poll all slaves (remote RTUs) one by one and to receive their responses.
Mesh mode
In mesh type networks, all radio modems can access each other randomly and spontaneously. Mesh networks can also host polling or report-by-exception applications, even in several instances.
Total IP network capacity
bytes/sec
Total network capacity in bytes per second (includes IP packet overhead). The resulting number refers to the maximum number in the optimally designed RipEX network. The more hops per path, the less overlap, and consequently more capacity left for simultaneous transmissions from different remotes. That is the reason for a higher capacity with more hops in the network. Nevertheless, that figure can be fully used only when there is a significant portion of communication load among the remotes themselves, or from remotes to e.g. local concentrators. When all messages have eventually to reach the single master station over the same radio channel, any calculation of total network capacity loses its sense, for obvious reasons. Certainly such a "central radio bottleneck" can (and should) be eliminated by e.g. adding extra channels or wire connections to dominant repeaters or bypass dominant repeaters using more radio hops. Generally, every network employing narrowband radios requires "capacity-aware design".
Note: Total network capacity assumes that all radios in the network operate on the same RF channel.
Total application network capacity
bytes/sec
Total network capacity in bytes per second, but no IP packet overhead is included.
Average message delivery time
msec
Average time required for a message to be successfully delivered within the RipEX network in the report-by-exception mode (i.e. from the center to the remote unit).
