The CIGORN Commercial Gateway is an opensource Linux device for connecting many base stations to a network. It can be used on a private network or used as an IoT gateway to connect base stations and RTUs to cloud servers or private servers.
Using a commercial gateway is always recommended systems where you do not have developers in your organization. If you prefer a black box approach where a vendor will implement and support a gateway between your system and remote devices, then using a commercial gateway like Cigorn is the right choice.
Gateways like CIGORN make systems secure, flexible, easy to communicate with unlimited numbers of devices. Gateways make managing networks and communications very flexible and reliable, and it records activity to help managers ensure the system is operating as expected.
CIGORN supports many SCADA and Telemetry protocols, such as MODBUS, DNP3, and IEC 60870. Internally, there is a protocol translator, and a router that can direct messages based on the ID of the Remote Terminal Unit.
If you are managing a large network of remote devices, SCADA devices, telemetry devices, or GPS tracking, a CIGORN gateway makes your system reliable and flexable. If you want a secure system, and don’t want to put your data in the Internet, CIGORN can be run on a private network to connect your devices as if they were on cloud servers.
Cigorn gateway can be used for Private secure networks, or for connectivity through the Internet for the IoT.
Wireless Network Addressing (WNAT). WNAT gives each radio in the system a unique IP/Port number. To communicate to a particular radio modem, simply connect a TCP/IP telnet or socket connection to its particular port.
Multiple Base Station Support. The Cigorn Gateway can be configured with any number of radio modems assigned to any number of base stations. The Cigorn Gateway will keep track of which base station a particular radio is supposed to communicate on.
Multiple Routes. Cigorn’s powerful message routing software allows messages to be routed to/from any number of radios and IP addresses. A single message may even be routed to multiple destinations.
Web interface. To monitor the system, Cigorn’s Web interface provides a rich set of operational statistics in real time.
Hot Standby. The Cigorn Gateway supports synchronization and failure detection using a second gateway. A backup gateway will keep it’s configuration continuously matched to a primary gateway. If it ever detects a failure, it will automatically take over to ensure the system always works.
IoT Gateway Solution
Cigorn is a very flexible IoT Gateway. An internal SQL database contains all routing plans. System mangers can redirect the routing plans by editing the data in the database. The Cigorn router can route to-from Ethernet servers, networks, serial ports, IoT servers, and also to-from simple RS232, RS422, and RS485 serial devices. Most any kind of SCADA device can be communicated to with the data to-from the Cigorn router.
The Message Router is very flexible, and can make sure all data goes to-from the Thing that needs to communicate.
Cigorn Gateway Hardware Platform
A primary goal of the Cigorn gateway project is to be able to run the Cigorn Gateway software on any POSIX Linux platform that has Ethernet and Serial port capabilities. The Cigorn software program does not require any human intervention, video monitor, keyboard, or mouse.Although we expect the software to be able to run on most any Linux machine, the target we envision is an Mini ITX motherboard with an Celeron processor. A complete Cigorn system can be built using standard off-the-shelf miniature fan-less PC for less than $300. Power consumption is typically less than 20 watts.
Cigorn Open Source
Open Source is software created by a community of people who are dedicated to working together in a highly collaborative and revolutionary way. This project was started by Raveon, with the desire is to bring together a community of developers to mold Cigorn into a powerful backbone technology for wireless data networking. For users of software who have the skills to download and install software, open source means choice and freedom. The freedom comes from the fact that the source code is available. If you want to change something, then you can, if you have the right skills.
The Open Source License under which the Cigorn source code may be used requires no payment to Raveon. Abide by the terms of the License, and you may use or resell products that use this program without having to pay Raveon anything.
This is a technical product, and is provided to the Open Source developer community AS IS. We hope that enough parties are interested in developing Cigorn that the blog will be a valuable source of technical assistance. Raveon will offer technical assistance on a per-hour consulting basis.
For companies or people who would like to purchase a Cigorn Gateway pre-configured and ready to use, Raveon will sell complete Cigorn Wireless Gateways with full technical support.
Cigorn stress tested to track 60,000 vehicles/minute
Here’s the test script, in the 1000Hz data configuration:
SLEEP_TIME=".001"echo "Beginning stream with $NUM_FEEDS ports starting at $START_PORT"
pkill -f "ncat localhost 6"
pkill -f "tail -f pravepipe"for i in `seq 1 $NUM_FEEDS`;
# Make named pipes and set up a tail to an ncat session.
# Ignore error if pipe exists
mkfifo "pravepipe$i" > /dev/null
ncat -k -l `expr $START_PORT + $i` --broker &
nohup tail -f "pravepipe$i" | ncat localhost `expr $START_PORT + $i` &
while read line;
# Send this $PRAVE message through prave pipe number "i"
echo -ne "$line\r\n" > "pravepipe$i";
# Increment i and then check if we need to go back to 1
i=`expr $i + 1`
test "$i" -gt "$NUM_FEEDS" && i=1
done < praveout
How does it work?
The script above creates a number of (in this case, 20) named pipes. In addition it creates the same number of brokered ncat sessions, listening on incrementing port numbers. Each named pipe is tailed to its corresponding ncat session, creating pipes that, when written to, send data to anyone who connects to a certain port. Data is then simply read from the “praveout” file and send, round robin, to each of the input feeds with a data point written every millisecond.For our particular test, Cigorn was configured to connect to all of the streaming ports and then direct all incoming traffic to two data sinks. This particular configuration mocks up the aforementioned bus tracking solution…excepting the much higher message volume!
Configuring Linux TCP Keepalive
In certain circumstances, it is important that Cigorn Gateways using TCP/IP socket communications periodically send TCP messages even if they have nothing to say. These null messages called “keepalive” packets can help inform networking infrastructure that the endpoints are still there, connected, and expect the TCP/IP socket to stay connected even though at the moment, they don’t have any data to exchange.By default, most Linux computers disable keepalive packets because they do add some additional loading to the network. The network load is very minimal, and this article describes how to enable keepalive packets, and how to configure Cigorn to use keepalive packets on a case-by-case basis.
These are the steps to enable keepalive packets on a Cigorn Gateway:
- Configure the keepalive parameters within Linux in sysctl.conf
- Configure the various device designators to use, or not use, keepalive packets
- Reboot Linux for your new settings to take place.
Configuring Linux Keepalive Settings
$ sudo nano /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 5
net.ipv4.tcp_keepalive_probes = 6
The above settings will cause keepalive packets to be sent every minute. If a response it not receive it will resend the keepalive packet every 5 seconds. After 30 seconds, it will reset the socket connection if 6 keepalives fail to get through. This allows a cable to be disconnected and reconnected for up to 30 seconds without dropping the connection, but it will also re-connect in less than 2 minutes if a device reboots or shuts down without properly closing the TCP/IP socket.
From the console on the local machine, or from a remote login SSH session, issue the following Linux command to shut down the Linux machine, and restart it:
$ shutdown -r now
Your new keepalive settings will be loaded, and Cigorn will restart.To view the current keepalive settings, use the “config” command from the Cigorn command-line interface.
Cigorn Hot standby
The Cigorn Gateway now has the ability to act in pairs as a fault tolerant system. In this configuration, a designated gateway runs in Standby Mode. The gateway will not make any connections or route any messages. Instead it will keep its settings synchronized with the primary gateway and monitor its health.If at any point the standby gateway detects (via non-responsiveness) that the primary gateway is not online, it will enter normal operation mode and begin to route messages.
While in Takeover Mode, the standby gateway continuously attempts to notify the primary gateway of the takeover. If the primary comes back online, a clean takeover will be negotiated and the primary and standby return to their normal operation state. These transactions (Takeover, Primary Mute, Hand-back) have been designed to minimize data loss in a hardware failure situation.
This feature has been tested extensively and is already in use in one of the Cigorn appliance installations!
Making an IP Addressable Data Radio System
Cellular Radio Modems The Easy Solution
Data Radio Modems with Cigorn The Better Solution
There are many reasons that a narrow-band radio system built with a Cigorn Gateway will be a better communication solution for you. Some of the reasons are:
- Individual IP address/port for each radio on your system.
- No monthly fees.
- Low latency. Messages will transfer within milliseconds.
- You can easily add additional base stations to cover remote areas.
- Works in areas where there is no cellular coverage.
- You determine your system redundancy and emergency operations, not a common carrier.
- Cellular radio modems go obsolete in short time periods compared to conventional radio modems.
- A cellular data carrier can at any time change billing, hardware requirements, and coverage without your permission.
How to Make an IP Radio Network
At the heart of the system is a Cigorn Gateway. The primary gateway keeps track of all radios, and knows where in the system each radio is located, and how to talk to it. Your application need only communicate to the Cigorn Gateway via TCP/IP.A Cigorn Gateway can communicate with thousands of radio modems, giving them each a unique IP address. Your application software does not need to know anything about how the radios are addressed or over-the-air protocols. Any application that can use IP addressing can be used to communicate to data radio modems via a Cigorn Gateway. A unique port number on the gateway is assigned to each radio in the network.
The Cigorn gateway can be configured to route data to/from radios in the field to/from specific IP addresses. Additionally, it can keep track of which base station in the field a particular radio is within communication range, and ensure that messages are sent to the correct base station for a particular radio modem.
For more information on creating a large IP addressable narrow-band radio modem system, contact Raveon sales at email@example.com.
Cigorn’s data router engine is a very flexible component of the Cigorn Gateway. It is user-configurable via entries in the SQL data table routes. The router engine performs the following functions:
- Pass datagrams between Wireless devices, other Cigorn Gateways, and End-User systems.
- Fitler routed datagrams based upon protocol type, NAP, and destination Wireless Dvice ID.
To simplify entries in the router engines route table, the input/output interface on the Cigorn Gateway are given a uniq name. When user assigns a name to an interface, they also assign a device to the interface. The name they assign is referred to as a Device Designator. Each bound pair of device&interface is referred to by a unique Device Designator. The Device Designator is assigned to the pair with the Device Binding entry in the .ini file. For example a radio modem setup on frequency 1 that is connected to serial port ttyS3 could be called “RFP1”. In the routing table, the user refers to this as combination as RFP1 the router engines know knows what serial port to use and what protocols are supported.