Neon System and IP Product Range

The Neon system collects measurements from Neon Remote Loggers (NRL) connected to field instruments and sensors and transmits these measurements to a central Neon Web based system for data storage, analysis, data presentation, graphical analysis and reporting and data transfer to other external systems.

The Neon system also provides facilities for remote management of Neon remote loggers via the Neon Web interface to allow for remote reconfiguration, sensor input changes and local program changes thereby minimising trips to site and reducing cost.
The communication protocol between Neon remote loggers and the central Neon Server is Internet Protocol / TCPIP and LoRa LPWAN technology protocol.

The communications method between Neon remote loggers and the central Neon Server can be any method which utilises TCPIP, and we support Cell Phone. Wi Fi, Direct Ethernet, Inmarsat BGAN M2M Satellite, Globalstar Satellite, Iridium Satellite and LoRa LPWAN across public and private networks.

The Starlog 4 software is a desktop application which assists with the setup of Neon remote logger configuration. This software allows for a point and click setup of Neon remote logger internal programs, called schemes. Schemes are downloaded to the loggers via a serial interface direct to the logger or uploaded to the Neon Web interface to be downloaded to a logger in the field via the Neon network.

The Neon system is offered to customers based on two options:
1. A customer owned server model, where the customer purchases a Neon Application Software licence from Unidata and runs that software on their own servers, or
2. A hosted application service model where Unidata provides access to run the system on Unidata secure servers on a fee for service basis.

There are a range of different Neon remote loggers available. While the models may be different, and the interfaces available in various models are different, the basic operation of all Neon remote loggers is the same.

Typical Neon Measurement System

The figure on the right is an example of a Neon installation showing an NRL connected to a Modbus sensor.
Every day the NRL will send, via the Inmarsat satellite network, to the Neon server a “packet” of information containing the data in raw format. The Neon Server then extracts the raw data from the packet. The data is then stored on a secure server until the client accesses the data using a standard Web Browser.

The Neon Server receives, processes, displays, stores and reports collected data in many ways. On top of that The Neon Server also can issue control commands based on pre-set algorithms and issue alarms and notifications via several mediums.

Alarm set points can be set up on the NRL units as well as the Neon Server further alarm notifications can be sent via several methods including email and SMS text messages. Alarm triggers can initiate physical actions in the field such as turning pumps on and off or activating other control functions based on the internal program within the NRL.

The Neon system has fully bi-directional communications between the NRL and the Neon Server. This allows for remote diagnosis, remote programming and remote firmware updating for operation of the remote equipment and thereby reducing costly site visits.

NRL units can be configured to read sensors, log data internally to local memory and push data to the central Neon server at user settable intervals such as once a minute, every few minutes, every hour, or once a day. Data can be viewed on the Neon Web interface in near real time from any browser and the comprehensive reporting engine within Neon allows for reporting out to other systems using email, ftp, and web services, either dynamically, every minute, or on a daily, monthly, quarterly or annual basis.

The NRL Internal architecture is shown below.

It contains two discrete sections:
1. A LOGGER section where the terminal connects to the field transducers and the logging scheme, scan rates and diagnostics are managed.
The StarlogV4 support software allows a user to generate a logger program (called a scheme) which defines transducer information, logging scan rates, logger interval etc and various engineering unit definitions. These files are called, for example the LDR and KBD files.
2. A COMMUNICATOR section which deals with communications to the server. This section contains, for example, a scheduler component and the modem component, either a Cellular Network modem or a Satellite Network modem. The communicator manages functions such as the reporting interval, the number of communications attempts per communications session, etc.
The StarlogV4 support software allows a user to generate a configuration file for the Communicator section, called an FPO file in which the user sets the required communications parameters.