To complete the product offering in the Neon Remote Logger range we have added a further model, the 3004MC.
This model is housed inside a polycarbonate enclosure, similar to our Lora equipped 3004ML. It has a form factor designed to allow easy transition from a Neon Remote Module / Neon Metering Module for customers wishing to upgrade to the higher capacity Neon Remote Logger architecture without disturbing existing wiring harnesses. The 3004MC has provision for a standard cell phone modem, but this can be changed to incorporate an Ethernet interface as ab option and also there are microsatellite modem options in development, which will be released over the next few months. The analogue inputs are the full 24 bit resolution capacity, same as the higher end models. We also have a display option in development, which will also be released over the next few months. Providing models to ease transition from the Neon Remote Modules to the newer Neon Remote Loggers has been a key design criterion for our design team. As this form factor is designed for lower numbers of sensors, we have added a 4-20 ma power supply option, making it very convenient for this product to be used with a single 4-20 ma sensor which can be powered from the small internal lithium battery.
Andrew Gregory is a senior software engineer here at Unidata, with a specialisation in embedded systems.
Andrew is a very long term Unidata person, longer than most of us, working with Unidata for more than 20 years. He has been the main software / firmware architect for several of Unidata’s logger products. His recent work has been the development of the software for the Neon Remote Logger Range, and we call that software firmware, because it is embedded software inside the microprocessor. Andrew is a very careful and precise programmer as well as a diligent documenter. He has a wiki with all the Neon Remote Logger software documentation which runs close to 1000 pages, that’s scary. He also has two screens, so he must have twice the productivity of people with only one screen.
Andrew is a keen bike rider and bushwalker. He is also a property owner and landlord as well and has been a joint owner of an apartment in Richmond with his sister. We did have hopes that an apartment in Richmond may encourage Andrew to adopt a footy team because he was so close to the MCG but sadly that has not happened.
In a disaster recovery situation, if there is a failure of the server for any reason, there is the potential for a restored Neon Server System to no longer be synchronised with Neon units in the field. There could also be loss of data. This may occur when the Neon system is restored from database backups that are out of date.
Whilst there is no automatic way to automatically re-create meta-data that has been entered into the Neon systems, such as new nodes or uploaded schemes, between the last backup and the disaster there is the scope to retrieve previously transmitted log data from the logger units in the field.
This allows a Neon system to backfill the log data gaps that will have occurred after being restored from older database backups. This feature has been recently added to the Neon Application software, we hope we will never need to use it, but it is there and we can use it to recover from a disaster. There is a logger specific and system wide mechanisms for setting up a replay of data from the Neon Field units to the Neon Server which will then allow this backfill to occur.
Other recently added features include Neon Support for Multi-buffering, RESTful API Provisioning Data Archiving System, Message based protocols, Aquarius Authentication and support for Inmarsat BGAN Kerlink Gateway LoRa Data from Actility.