all | frequencies |
|
|
|
|
exhibits | applications |
---|---|---|---|---|---|---|---|
manual | photos | label |
app s | submitted / available | |||||||
---|---|---|---|---|---|---|---|---|
1 |
|
User Manual | Users Manual | 1.06 MiB | May 20 2022 | |||
1 |
|
Internal Photos | Internal Photos | 1.97 MiB | May 20 2022 | |||
1 |
|
External Photos | External Photos | 444.73 KiB | May 20 2022 | |||
1 |
|
Label and Placement Information | ID Label/Location Info | 229.69 KiB | May 20 2022 | |||
1 | Block Diagram | Block Diagram | JPEG Image | May 20 2022 | confidential | |||
1 |
|
Confidentiality Letter | Cover Letter(s) | 349.57 KiB | May 20 2022 | |||
1 |
|
Cover Letter | Cover Letter(s) | 64.91 KiB | May 20 2022 | |||
1 | Operational Description | Operational Description | May 20 2022 | confidential | ||||
1 | Schematics | Schematics | May 20 2022 | confidential | ||||
1 |
|
Test Report | Test Report | 4.65 MiB | May 20 2022 | |||
1 |
|
Test Setup Photos | Test Setup Photos | 2.46 MiB | May 20 2022 |
1 | User Manual | Users Manual | 1.06 MiB | May 20 2022 |
Remote Terminal Unit M717 User Guide Copyright Notice Neither the whole nor any part of the information contained in this publication may be reproduced in any material form except with the prior written permission of the publisher. All trademarks used throughout this document are the property of their respective owners. Mention of third-party products is for informational purpose only and constitutes neither an endorsement, nor a recommendation. Metrilog assumes no responsibility with regard to the performance or use of these products. Document rev 2.1, issued 13 May 2022. This document is based on the M717 rmware version 1.04. In order to improve the performances of the product, Metrilog may issue from time to time rmware updates. The updates may add, modify or remove certain commands and functionalities, as described in this document. Metrilog assumes no obligation to update the manual as a consequence. Metrilog Data Services GmbH, Oce Park 4, C38, Vienna Airport City, 1300 Wien-Flughafen, Austria www.metrilog.com 2018-2022 Metrilog Data Services GmbH Table Of Contents Table Of Contents Introduction 1. 1.1. Product Overview
.......................................................................................................................................1
...........................................................................................................................................3
......................................................................................................................................3 1.2. 1.3. Safety
..............................................................................................................................................................4 Information to Users in the US
..............................................................................................................4 2. Installation 2.1. Register the RTU to the M2M Gateway
..............................................................................................................................................5
..............................................................................................5 2.2. The SDI Connector
.....................................................................................................................................6 2.3. The MPI Connector
....................................................................................................................................6 2.4. The Micro USB Service Connector
.......................................................................................................6 2.5. About the Data Acquisition Subsystem
.............................................................................................7 2.6. SDI-12 Sensors
............................................................................................................................................7 2.6.1. Create a New Template From an Existing One 2.6.2. Create a New Template From Scratch Interface to a Davis Vantage Pro Console
......................................................................8
.......................................................................................9
.......................................................................................11 Interface to a Thies TDL14 or DL16 Data Logger
..........................................................................11 2.7. 2.8. 2.9. Mechanical Installation
.........................................................................................................................13 2.10. Operation
...................................................................................................................................................13 3. Conguration 3.1. The Metrilog M2M Gateway
......................................................................................................................................14
................................................................................................................14 3.2. The USB Service Port
..............................................................................................................................14 3.3. MPI as Service Port
..................................................................................................................................15 3.4. Telnet
...........................................................................................................................................................15 4. Commands 4.1. General Commands
...........................................................................................................................................16
................................................................................................................................16 4.1.1. help 4.1.2. ver 4.1.3. echo 4.1.4. ps 4.1.5. date 4.1.6. log 4.1.7. attr 4.1.8. pin 4.1.9. hwid 4.1.10. connect 4.1.11. xfer 4.1.12. fwupdate 4.1.13. reboot 4.1.14. exit
.....................................................................................................................................................16
.......................................................................................................................................................16
....................................................................................................................................................17
.........................................................................................................................................................17
.....................................................................................................................................................17
.......................................................................................................................................................18
.......................................................................................................................................................19
.......................................................................................................................................................19
....................................................................................................................................................20
.............................................................................................................................................20
......................................................................................................................................................20
..........................................................................................................................................21
................................................................................................................................................21
......................................................................................................................................................22
..............................................................................................................22 4.2. Data Acquisition Commands 1 4.2.1. dacq 4.2.2. dacq info 4.2.3. dacq sample 4.2.4. dacq retrieve 4.2.5. dacq abort 4.2.6. dacq date 4.2.7. dacq interval 4.2.8. dacq direct 4.2.9. dacq t 4.2.10. hist 4.2.11. hist info 4.2.12. hist stat 4.2.13. hist map 4.2.14. hist purge
....................................................................................................................................................22
...........................................................................................................................................22
....................................................................................................................................23
...................................................................................................................................23
........................................................................................................................................23
..........................................................................................................................................24
...................................................................................................................................24
.......................................................................................................................................24
.................................................................................................................................................25
......................................................................................................................................................25
.............................................................................................................................................26
..............................................................................................................................................26
............................................................................................................................................26
.........................................................................................................................................27
...............................................................................................27 4.3. Data Acquisition Legacy Commands 4.3.1. 4.3.2. 4.3.3. sdi t thi t thi direct
.....................................................................................................................................................28
......................................................................................................................................................28
............................................................................................................................................28
...............................................................................................................29 4.4. Communication Commands 4.4.1. net 4.4.2. net get 4.4.3. net up 4.4.4. net down 4.4.5. net session 4.4.6. modem 4.4.7. modem direct 4.4.8. modem pwrdown 4.4.9. modem pwrup 4.4.10. modem reset 4.4.11. modem mode
.......................................................................................................................................................29
...............................................................................................................................................29
................................................................................................................................................30
..........................................................................................................................................30
.......................................................................................................................................30
..............................................................................................................................................30
.................................................................................................................................31
.........................................................................................................................31
...............................................................................................................................31
...................................................................................................................................32
.................................................................................................................................32
.........................................................................................................................32 File System Commands 4.5. ls cd cp 4.5.1. 4.5.2. mkdir 4.5.3. 4.5.4. 4.5.5. pwd 4.5.6. 4.5.7. ..........................................................................................................................................................32
..................................................................................................................................................33
.........................................................................................................................................................33
.........................................................................................................................................................33
.....................................................................................................................................................34
........................................................................................................................................................34
........................................................................................................................................................34
.......................................................................................35 rm cat 4.6. Command Line Interface Error Messages 5. Attributes 5.1. RTU Attributes
..............................................................................................................................................36
..........................................................................................................................................36 5.2. Sensor Attributes
.....................................................................................................................................38 5.3. Tag Attributes
...........................................................................................................................................39 6. Technical Specications ..................................................................................................................42 2 1. Introduction 1.1. Product Overview The Remote Terminal Unit (RTU) model M717 is a low power GSM/GPRS/UMTS/LTE based communication device, that includes exible bus/serial interfaces and a data-logging unit. The M717 RTU supports following protocols and Input/Output (I/O) interfaces (see gure below):
SDI, can be switched under software control between SDI-12 native, RS-485 or CAN;
MPI, or Multi Protocol Interface; can be switched under software control between RS-232, RS-422 and RS-485;
USB micro AB. The M717 RTU can operate with multiple data sources, even simultaneous on both interfaces (e.g., several SDI-12 sensors on SDI and a Thies DL16 data logger on MPI). The M717 RTU supports a maximum of 50 sensors with a total of max. 128 sampled values (tags) per data record. The SDI-12 implementation also supports output tags by using specially designed, custom X commands (e.g., for switching valves). The Davis and Thies implementations support one sensor (the data logger) with a total of max. 128 sampled values (tags) per data record. The internal data logging memory (FIFOFirst In, First Out) can store up to half a million individual values, the older values being overwritten when the memory lls up. The SDI-12 implementation conforms to the SDI-12 specication version 1.3. For additional information on the SDI-12 bus, please consult the following document: SDI-12, A Serial-Digital Interface Standard for Microprocessor-Based Sensors, Version 1.3. The document can be found on the SDI-12 Support Groups web site at http://www.sdi-12.org. 3 1.2. Safety Please observe the following instructions:
Do not open the unit, except if so instructed by the Metrilog technical personnel!
Should it be necessary to open the unit (e.g., to replace the SIM card), the operation must be executed only in a moisture free environment. You will need a Philips screwdriver size PH2. Note that the screws remain attached to the lid, there is no need to remove them. Remove the lid slowly and carefully, because an antenna is xed on its back. The antenna cable goes to a connector on the electronics board and it can be easily damaged. Before mounting the lid back, make sure the gasket is properly seated! If the gasket is damaged, contact Metrilog for a replacement. A defective gasket will lead to moisture entering the housing, thus permanently damage the unit. Please make sure that all the cables and connectors are properly fasten to avoid moisture entering the unit and/or the connectors. USB connector (see picture above). During normal use outdoors, the dust cover attached to the unit must always be inserted into the If either the MPI or the SDI connector is not used, it must be covered with the attached protection cap. The unit can be powered on all three connectors, even simultaneously, in which case the power source with the highest voltage will take precedence. The minimum voltage is 6 Volt for the SDI and MPI connectors and 4.7 Volt for the USB connector;
the maximum voltage is 30 Volt for the SDI and MPI connectors and 5.3 Volt for the USB connector. Under no circumstances should the maximum voltage be exceeded!
Improper commands issued through the USB port or over telnet, in particular commands modifying certain attributes, may compromise the functionality of the RTU and may render it inoperable. 1.3. Information to Users in the US This device is granted permission to be operated in the US under the FCC ID 2A6UM-M717D. Any changes or modications not expressly approved by the party responsible for compliance could void the user's authority to operate the equipment. FCC RF Exposure statement: This device contains a RF Transmitter that complies with FCC RF radiation exposure limits set forth for an uncontrolled environment. This transmitter must be installed to provide a minimum separation distance of at least 20 cm from all persons and must not be co-located or operating in conjunction with any other antenna or transmitter, except in accordance with FCC multi-transmitter product procedures. This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. 4 2. Installation This section describes the installation of a new unit. It is recommended rst to set-up the new RTU on the Metrilog M2M Gateway and then to proceed with the hardware installation. 2.1. Register the RTU to the M2M Gateway The M717 RTU has been designed to operate in conjunction with the Metrilog M2M Gateway and Metrilog M2M Services. Before installing a M717 RTU in the eld, it should be registered on the Metrilog M2M Gateway. Proceed as follows (you need administrator rights to add an RTU):
Log-in on to the Metrilog M2M Gateway at https://www.metrilog.net;
If you have sub-realms or sub-areas, navigate to the realm or area where you want to add the new RTU;
Select the realm or area in the left pane of the Web interface and select New Remote Unit on the right pane;
is installed at;
on one side of the M717 RTU;
Fill in the relevant information; you will nd the RTUs Serial Number on the metallic label axed Choose a suitable name for the RTU Name, usually a name representative for the location the RTU The Login Name and Login Password are used later by the RTU to authenticate to the M2M Gateway; you can enter whatever name and password you deem appropriate, however it is recommended to use a name similar to the RTU name (max. 10 characters);
Select the appropriate RTU template (e.g. M717);
Click OK to nish. Note: While you can use any character for the "RTU Name" eld, do not use special characters as , , , etc., for the "Login Name" and "Login Password" elds. Although it is not required for the proper operation of the RTU, you will need to congure sensors and tags to the RTU, depending on what sensors you plan to install in the eld. A large variety of existing 5 templates are available on the M2M Gateway, while new sensors/templates can be easily dened by the user. 2 3 2.2. The SDI Connector The pin-out of the SDI-12/RS-485 connector is shown below. Brown + Vin (6 to 30 Volt) 2 White
- Vin and SDI-12 GND 1 4 1 3 4 Blue RS-485 A/CAN-L (unused in native SDI-12 mode) Black SDI-12/RS-485 B/CAN-H Note: The colours given in the last column are valid for the standard Metrilog M12 cable (option). Pin 3 is not used in native SDI-12 mode. 2.3. The MPI Connector The pin-out of the Multi Protocol Interface (MPI) is given below. 3 2 4 8 5 1 6 7 1 2 3 4 5 6 7 8 White
- Vin and GND Brown
+ Vin (6 to 30 Volt) Green RS-232 RxD/RS-485 A Yellow RS-232 TxD/RS-422 Z Grey Pink Blue Red RS-485 B RS-232 GND RS-422 Y GND/Shield Note: The colours given in the last column are valid for the standard Metrilog M12 cable (option). 2.4. The Micro USB Service Connector The USB connector is used for maintenance and service. You should not have to deal with this connector unless indicated so by the Metrilog support personnel. For additional information on the use of this connector, check also the Commands section of this manual. 6 2.5. About the Data Acquisition Subsystem Depending on the interface to the input/output devices (sensors), the M717 RTU supports the following sensors and data loggers:
Sensors based on the SDI-12 protocol, version 1.3. It has various operating modes and can be congured to accept a large variety of sensors both in native SDI-12 hardware interface and the RS-485 balanced interface. The RS-485 interface allows for longer cables, but unfortunately not many sensor manufacturers implement SDI-12 over RS-485. Davis Instruments, Inc. Vantage Pro weather stations with the WeatherLink interface (also from Davis Instruments). The communication is done through an RS-232 link over the MPI connector. A series of data loggers manufactured by Adolf Thies GmbH & Co. KG. (e.g., models TDL14 and TDL16). The RS-232, RS-422 and RS-485 interfaces over the MPI connector are supported. Specic functions of the Data Acquisition subsystem are congured by means of attributes. The subsystem is hierarchically structured, and it can have a number of sensors, each of them in turn having a number of tags. A tag in this sense represents a specic value that can be read from e.g., a temperature, or written to e.g., a coil or a valve. In other words, there are input and output tags. Note: Currently, only the SDI-12 protocol supports output tags (by means of SDI-12 X commands); the Davis and Thies data loggers support only input tags. Although there are some common attributes, depending on the attached sensors and/or data logger, specic attributes are used to dene the functionality of the sensors and tags. For instance, acquisitionMode and acquisitionSchedule are common attributes for all kind of sensors; however, sdiMethod is specic to the SDI-12 sensors, while archiveInterval is specic to the Davis data logger. The Data Acquisition Subsystem includes a First-In, First-Out (FIFO) ring storage. The data provided by the sensors is stored in the FIFO until delivered by the communication subsystem via the Internet. The physical memory consists of a serial ash chip, therefore the data is stored persistently and is not lost while the RTU is powered down. 2.6. SDI-12 Sensors The M717 RTU uses a four-wire cable carrying the SDI-12 bus signals and the bus power supply (typically 12 Volt). Alternatively the bus can be switched to RS-485 levels, but this is allowed only if all devices on the bus support it. You cannot mix SDI-12 and RS-485 sensors on the same bus. The switch from SDI-12 (default) to RS-485 is done automatically depending on the wiring of the sensor: if the blue wire (pin 3) is used, then the bus is operating in RS-485 mode. For SDI-12 native sensors, only the pins 1, 2 and 4 of the connector must be used (the brown, white and black wires of the cable), while pin 3
(blue wire) must be left open. Note: CAN mode is not supported by the current rmware, but may be by a future update. Depending on the sensor, a template may already be available on the M2M Gateway. To add a new sensor to an RTU follow the steps below:
7 Log in to the M2M Gateway and in the left pane select the RTU you want to add a new sensor to. In the right pane, click the New Sensor button. Name your sensor, then from the drop down select the template corresponding to the sensor you want to add. Click the "OK" button. The sensor will be added to the RTU. After the sensor has been added, select it in the left pane and click Attributes to complete or change some attributes. Verify if the sdiAddress is empty or incorrect, it must be identical to the SDI-12 address of your sensor. Verify also that the sdiMethod suits the one you want to use with your sensor, as it can be either M, MC, C, CC, or a Rx variant (for more details, consult the SDI-12 specication, as well as the sensors User Manual). The nal step is to verify/update the tags attributes, in this case only the sdiIndex. If the attribute had a value given during the template generation, then it should be OK. However, if it is missing, or your SDI-12 sensor has a dierent conguration, you must set it here. Essentially, the sdiIndex is the position of the sensors value in the SDI-12 Dx response string. Note that the index numbering starts with 0. If there is no template for your sensor already, you must create one by yourself. There are two methods:
either you use an existing template and modify it to suit the new sensor (recommended, as it is easier), or you create one from scratch. Both methods are described in the following sections. 2.6.1. Create a New Template From an Existing One This method is the easier one. Do the following:
8 Log in to the M2M Gateway and in the left pane click and expand the Admin entry, then click the Templates entry. Select an existing sensor template which is as much as possible close to the one you want to create. In the right pane, click the Save as Template button. In the following dialog box, enter the name of the new template and select the destination area
(where the template will be saved on the server). Check the Include children checkbox if you want to take over the tags of the original template
(recommended). Click "OK". Select the new template and verify/modify its attributes according to the parameters of the sensor. Examine the children tags and delete the ones you dont need, or add new tags according to the hardware conguration of your sensor. Verify and modify accordingly the attributes of all the tags of the new sensor. In a similar fashion you can create new tag templates, based on existing templates (use the Save as Template button). 2.6.2. Create a New Template From Scratch This method requires more work. Proceed as follows:
Log in to the M2M Gateway and in the left pane click and expand the Admin entry, then click the Templates entry. On the right pane, click the New Template button. Name the new template; use a name that can easily identify the new sensor, usually the manufacturer and the type of the sensor. Select from the Template Class sensor and click "OK". The new template will be generated, however it will be empty. Select the newly generated template and click the Attributes tab. You will now add several attributes. Click the New button; in the dialog box that appears you must dene the attribute. For a proper operation of the RTU, a list with the minimum of attributes required and their parameters follows:
acquisitionMode, type: int, ags: r/w,RTU=x, Size: , Value: 2 acquisitionSchedule, type: string, ags: r/w,RTU=x, Size: 100, Value: */10 iconName, type: string, ags: a/a, Size: 20, Value: COMBO sdiAddress, type string, ags: a/a,RTU=x, Size: 1, Value:
sdiInfo, type: string, ags: r/-, Size: 40, Value:
sdiMethod, type:string, ags: a/a,RTU=x, Size: 3, Value:
9 Note: The attribute names, as well as all the parameters must be entered exactly as written; where no value is given, the eld should be left empty. However, you may enter default values for the sdiAddress and sdiMethod (consult the sensors specications). After all the sensors attributes have been entered, you need to dene and add the sensors tags. Select the sensor and click the New Tag button. Enter the name of the new sensor (e.g., Temperature), then select the appropriate sensor template from the drop-down. Finally click the "OK" button. As with the sensors, if you cant nd a template already dened for your tag, you must dene one by yourself. This is similar to the creation of a sensor template, except that the attributes are dierent. Proceed as follows:
Log in to the M2M Gateway and in the left pane click and expand the Admin entry, then click the Templates entry. On the right pane, click the New Template button. Name the new template; use a name that can easily identify the new tag, e.g., Temperature. Select from the Template Class tag and click "OK". The new template will be generated, however it will be empty. attributes. Select the newly generated template and click the Attributes tab. You will now add several Click the New button; in the dialog box that appears you must dene the attribute. For a proper operation of the RTU, a list with the minimum of attributes required and their parameters follows:
addUPItemplate, type: string, R/-, Size: 30, Value: addUPI_ANALOG_TAG_V1_0 EUID, type: int, ags: r/-, Size: , Value: <see note below>
iconName, type: string, ags: a/a, Size: 20, Value: <see note below>
maxValue, type: double, ags: r/-, Size: , Value: <see note below>
minValue, type: double, ags: r/-, Size: , Value: <see note below>
sdiIndex, type: int, ags: a/a,RTU=x, Size: , Value:
Note: The addUPItemplate is not required by the RTU, but it is used by certain application software as e.g. Instruments. It must be entered exactly as shown. The EUID (Engineering Unit ID) is a conventional rule that associates measurement units (e.g., meter, second, gram, etc.) to an ID (a number). The RTU doesnt need it, but it is helpful for application software, as well as for the M2M Gateway, to associate the proper measurement unit to a tag. The iconName is not required by the RTU; it is a reference to an icon that will be displayed by the M2M Gateway user interface. Both the proper EUID and the iconName can be found clicking on the Info button on the main menu bar (see picture below). The maxValue and minValue are not required by the RTU, but are used by the application software, for instance when setting the limits of a graph. These values must reect the maximum and minimum values that can be delivered by the Note: The sdiIndex is the position of the sensors value in the SDI-12 Dx response string; the index numbering sensor. starts with 0. 10 2.7. Interface to a Davis Vantage Pro Console The following instructions are valid when the M717 RTU is connected to a Vantage Pro weather station
(manufactured by Davis Instruments). The M717 RTU can be installed both indoors and outdoors. Note: The M905 Connexion Box, the Davis Console, as well as the mains adapter are not intended for outdoors installation!
To connect the M717 RTU to the Vantage Pro Console, a WeatherLink data cable from Davis Instruments is required. Note that for this conguration the data collected by the Davis Console is already logged into the WeatherLink data logger, thus the data passes through two levels of storage: one oered by the Davis System and a second by the M717 RTU. The following diagram depicts the connections between the M717 RTU, the M905 connexion box and the mains adapter. The conguration of the Davis Console on the M2M Gateway is done as for the SDI-12 sensors, but it is considerably simplied as a suitable template is already available. 2.8. Interface to a Thies TDL14 or DL16 Data Logger The Thies data loggers implement a proprietary serial protocol. The TDL14 logger supports the RS-232 and RS-485 full duplex modes, while the DL16 logger additionally supports the RS-485 half-duplex mode. The communication with the logger is done using a 10 m cable attached to the MPI connector. Before proceeding with the actual installation in the eld, it is recommended to verify, and possibly modify the specic attributes that dene the MPI functionality. Proceed as follows (you need administrator rights to add an RTU):
Log-in on to the Metrilog M2M Gateway at https://www.metrilog.net. Navigate to the RTU that must be veried/modied and select it. On the right pane, select the tab Attributes. The attribute mpiBaudRate determines the baud rate of the MPI interface: set it to t the baud rate of the data logger (default 9600 Baud; the DL16 supports also higher baud rates). 11 The attribute mpiMode determines the operation mode of the MPI interface: set to one of RS-232, RS-422 or RS-485, depending on the conguration of the data logger. The attribute mpiTermination is eective only in the RS-422 and RS-485 modes: if required, 120 termination resistors can be activated on the M717 RTU side of the bus. After all attributes are properly set, click the Save button. To connect the 10 m M12 cable, you must open the Thies data logger and insert it through a free cable gland. Attach the cable wires to the corresponding screw posts as shown in to the table below, depending on the selected serial mode (RS-232, RS-422 or RS-485) and the logger type. Note:
If you are performing the operations while the Thies data-logger is powered, make sure the other end of the cable is not connected to the M717!
M717 Pin-out TDL14 DL16 RS-232 RS-422 RS-232 RS-422 RS-485 3 2 4 8 5 1 6 7 1 White 6 (GND) 6 (GND) 1 (GND) 1 (GND) 1 (GND) 2 Brown 5 (+12V) 5 (+12V) 7 (+12V) 7 (+12V) 7 (+12V) 3 Green 11 (TxD) 12 (TxD+) 6 (TxD) 5 (TxD+) 4 Yellow 9 (RxD) 10 (RxD-) 2 (RxD) 3 (RxD-) 5 Grey 11 (TxD) 14 (TxD-) N.C. 6 (TxD-) 6 7 8 Pink Blue Red 13 (GND) 13 (GND) 4 (GND) 4 (GND) 4 (GND) N.C. N.C. 8 (RxD+) N.C. N.C. N.C. 2 (RxD+) N.C. Shield Connect to metal housing N.C. 6 (B) N.C. 5 (A) N.C. Note: The wires marked in the table as N.C. must be left unconnected and insulated from other wires and/or metallic parts. After all the wires have been properly connected, you may now attach the other end of the cable to the M717 unit. Please observe the following:
Before connecting the M717 cable wires to the screw posts, make sure there are no other wires already connected! The M717 cannot be operated in parallel to another device/modem. The cable shielding must be connected to the metallic housing of the logger. If the cable gland does not provide a ground connection to the cables shield, a separate wire should be used to connect it to the ground. The conguration of the Thies Data Logger on the M2M Gateway is done similarly to the SDI-12 sensors, but it is considerably simplied as suitable templates for standard congurations of TDL14 and DL16 are already available. Additional tags may be dened and added according to the actual logger conguration. 12 2.9. Mechanical Installation The M717 unit should be preferably mounted outdoors on a 40 mm diameter mast or support by means of an (optional) metallic mounting xture and a hose clamp. In this case fasten rst mounting xture to the M717 enclosure using two M6 screws and spacers (see the gure below). If the unit is not installed outdoors, rather placed on a table or in a cabinet, the metallic xture may not be required. It is recommended to place the top of the unit (where the internal antennas reside), not too close to metallic objects, especially to the mast itself. Ideally the unit should be mounted at the top of the mast. Use tie wraps to fasten the cables to the mast after the mechanical installation is completed. If the unit is kept indoors, try to place it close to a window if the cellular signal is weak. 2.10. Operation After being powered up, an uninitialised RTU will rst check the SIM card and extract the provider specic information (APN, Name, Password) from it. This information, together with the initial address of the Metrilog M2M Gateway is stored in a table in the RTUs rmware. Note: The RTU must be already registered on the Metrilog M2M Gateway as described at the beginning of this section. In addition, the SIM card must be active. If not sure, please contact Metrilog. At this point, the RTU is able to connect via the cellular network to the M2M Gateway. If the connection succeeds, the RTU retrieves its conguration, including its account data and the attached sensors. The account data is based on the credentials oered by information contained in the SIM card, the IMEI, and/
or the serial number of the device. If the SIM card is not known to the M2M Gateway, the RTU will not be able to log in and retrieve conguration and account data. The error messages in the log le document such situations, as well as other similar potential issues. You can see the log les, if you have direct access to the unit, by connecting it to a PC using the USB connector. For more details see the Commands section. 13 3. Conguration The M717 RTU is automatically congured by the Metrilog M2M Gateway, therefore in most cases no user intervention is necessary. However, the operation of the RTU and the sensors can be customised to a certain extent. The preferred method is via the M2M Gateway, but for advanced users, and when the units are accessible via USB or telnet, a Command Line Interface (CLI) is available, as described in the following sections. 3.1. The Metrilog M2M Gateway An important service oered by the M2M Gateway is the handling of the conguration of RTUs. The complete behaviour of an RTU is dened on the Gateway. The RTU parameters can be dened and/or modied at any time on the M2M Gateway after which they are retrieved by the RTU as soon as a connection is made. A connection can only be initiated by the RTU and not the other way round. That means polling of the RTU is not possible. In order to overcome this issue, the M717 RTU implements a exible scheduler that species when and how often the RTU should initiate a connection to the M2M Gateway. As with many other parameters on the RTU, the scheduler is remotely congurable through the M2M Gateway. By changing a parameter on the Gateway, a task will be generated on the server and added to a queue for that particular RTU. When the RTU connects, the task will be passed along and the RTU will execute and acknowledge it. The functionality of an RTU is dened by a collection of attributes. A list with a partial description of the M717 RTUs attributes is given in the Attributes section of this document. The Web based User Interface of the M2M Gateway oers an easy and intuitive method to add/modify/delete attributes. However, standard devices (e.g., the M717 RTU family, as well as a large collection of sensors), are already predened through templates, so you should not need to add/change attributes. Note:
Improper manipulation of the attributes can lead to malfunction of the RTUs. You must rst understand what function a certain attribute performs before attempting to change its value. 3.2. The USB Service Port The use of the service port is recommended only in special cases during an installation operation where there is no Internet access, or the RTU does not manage to contact the M2M Gateway. Note:
Improper commands issued through the service port may compromise the functionality of the RTU. To communicate with the RTU through the service port, an USB-A to USB micro-AB cable and a PC with a terminal program is required (e.g., Hyperterminal, minicom, etc.). Depending on the operating system running on your PC, you might need to install an USB-CDC driver. On most modern operating systems this driver is already installed. 14 Connect a micro-USB to A cable to a PC and use the new virtual serial port (COM or tty) registered in your system with the terminal program. You should see in your terminal program the RTU name followed by a login prompt: enter the RTU password (as set on the M2M Gateway, see also "Register an RTU" section) then the : prompt should appear. 3.3. MPI as Service Port An alternative to the USB Service port is the MPI Connector. A Command Line Interface (CLI) is available on this port too, but it requires a special adapter: M12 to DB9 RS-232 connector. The serial port conguration is as follows:
The signalling is RS-232, 8N1, no hardware, nor software protocol. The Baud rate is dened by the mpiBaudRate attribute. Only the pins 3 (to the TxD of the host), 4 (to the RxD of the host) and 1 (GND) are used. The attribute mpiMode must be set to RS-232, otherwise the CLI wont be enabled on the MPI. After connecting the unit to the PC, in a terminal windows press any key several times until the unit wakes up; then you should see the password request prompt. Note: After about 40 seconds, the RTU reverts back to sleep mode and the CLI will be terminated. 3.4. Telnet prerequisites:
The M717 RTU has also a built-in telnet server. However, to access the CLI over telnet, there are several The telnet server is by default not active, therefore it must be activated through the cliOverIP attribute. This is done through the M2M Gateway Interface. After the next successful session, the telnet server will remain active for 5 minutes (default value). The telnet server will not be activated if the RTU cant connect to the Internet. Currently only units using the Global SIM cards provided by Telekom Austria can be reached via telnet. For security reasons, all the units using the Telekom Austria SIM cards are part of a private network that cant be accessed directly from the Internet. To reach these units you need a special cellular router using also a SIM card from Telekom Austria (please contact Metrilog in case you need one). The modem must be properly congured, integrated in your network, or at least connected over IP to your computer. To reach the unit over telnet, after the session has been concluded, use a telnet client to connect to the IP address indicated by the attribute assignedIP, as shown by the M2M Gateway. 15 4. Commands The information in this chapter is intended for well trained technicians to pinpoint errors or other device malfunctions, to customise the functionality if the communication to the M2M Gateway is not possible, or for developers that wish to implement special software in conjunction with the M717 RTU. Before using any command described in this chapter, make sure you have a good understanding of what the command does. Improper use may render the RTU inoperable. The M717 RTU commands are grouped in several categories:
General: address internals of the RTU, or allow attributes manipulation. Data Acquisition: operate on the data acquisition and historians. Communication: view/modify network and cellular communication parameters. File System operations: list, copy and delete les on the RTU internal le system. Once the CLI is reached using one of the methods described earlier (USB, MPI or telnet), and after entering the correct password, a : (colon) prompt will be displayed on the terminal. The commands can be typed in lower or upper case. Note: An exception to this is when typing attribute names and values, they are case sensitive. 4.1. General Commands 4.1.1. help Description 4.1.2. ver Description Lists all the available commands with a short description. It is a useful command if you dont remember the syntax of a command: for further information on a specic command, type <command> -h, this will show the subcommands and/or the parameters accepted by a command. Returns the versions of the application and boot loader of the unit, as well as general information about the hardware. Example
: ver Model M717, rev. C M717-app, ver. 1.04 (build 1220), Sep 16 2020, 11:55 M717-boot, ver. 0.94 (build 172), Jun 15 2020, 14:22 Core clock 96 MHz, core temperature 27 deg.C, Vdd 2.92 Volt External power supply 12.1 Volt, backup battery 3.08 Volt
(c) 2018-2020 Metrilog Data Services GmbH 16 Enables/disables echoing the typed characters. Issued without a parameter, it returns the current state. Default for echo is ON. Shows the RTOS threads, their state, CPU load and memory available. This command is informative. 4.1.3. echo Description Examples
: echo Echo is on
: echo off 4.1.4. ps Description 4.1.5. date Description Usage Remarks Usage ps Example
: ps Thread Name State Prio %CPU Stack
db-buffer Wait 96 < 1% 1068 cli-manager Wait 96 < 1% 1088 cli-cdc1 Run 96 < 1% 2424 comm-worker Wait 96 1% 1360 mpi-worker Wait 96 < 1% 2812 sdi-worker Wait 96 < 1% 1116 cron Wait 96 < 1% 1124 main Wait 32 < 1% 1752 idle Ready 16 97% 536 Heap: 182KB free out of 247KB available Uptime: 12d, 3h, 45m Shows/sets the system date. date {[-u] | [ hh:mm:ss [ dd/mm/yy ]]}
date -c [ +/-ppm ] to show/set the RTC calibration factor date -tz to show the system time zone date -r to show the RTC's reference frequency (in Hz) If the option -u is used, the date will be displayed as UTC. Using the -c option, a calibration factor can be entered to increase the clock precision. The parameter can take values from -511 to +511 and represents ppm
(parts per million). The frequency displayed when using the -r option is only indicative, as it is measured using the microcontrollers reference crystal. The crystal has an error marge of 50 ppm, which is actually lower than that of the RTC (20 ppm). Examples
: date Local time: Mon Apr 2 16:50:48 2020
: date 11:30:0 30/05/2020
-> set date and time
: date 11:30:00
-> set only time
: date -c Calibration register 0 17
: date -c -30
-> the clock will run slower with -30 ppm of a second
: date -tz CET-1CEST-2,M3.5.0/02:00:00,M10.5.0/03:00:00"
: date -r RTC's reference frequency 1.000058 Hz 4.1.6. log Description Usage Remarks Shows log entries and log statistics. log [ dd/mm/yy [ hh:mm:ss ]] to show the log entries log stat to show the log system information log clear [ -y ] to clear the log The date/time parameter must be specied only once, the system will display the next 20 lines after the date given (if no, or less than 20 entries are available, there will be no, or only the available entries displayed). To continue with the next log entries, enter only the log command, without parameters, until all entries are displayed. The -y option is used to override the conrmation question, the log will be immediately cleared. Examples
: log 02/08/2020 02/08/2020 09:59:09 [ 4] cli_over_ip_manager(): console started on /dev/ptty0 02/08/2020 10:00:10 [ 4] cli_over_ip_manager(): console on /dev/ptty0 terminated by the user 02/08/2020 10:12:26 [ 1] reset_handler(): system halted 02/08/2020 10:12:29 [ 1] reset_handler(): bootloader started after software reset 02/08/2020 10:12:29 [ 64] init_block_devices(): file system successfully mounted 02/08/2020 10:12:29 [ 2048] update(): update pack found at /flash/firmware/m717_1_04.pack 02/08/2020 10:12:31 [ 2048] update(): M717-app update succeeded 02/08/2020 10:12:32 [ 1] reset_handler(): system halted 02/08/2020 10:12:34 [ 1] reset_handler(): system started after software reset 02/08/2020 10:12:34 [ 1] init_block_devices(): database opened in 94.39 ms 02/08/2020 10:12:34 [ 64] init_block_devices(): file system successfully mounted 02/08/2020 10:12:34 [ 1024] init_config(): invalid configuration, attempting flash restore 02/08/2020 10:12:34 [ 64] rpc_config_struct_load(): configuration loaded 02/08/2020 10:12:34 [ 1024] init_config(): flash restore succeeded, configuration OK 02/08/2020 10:22:29 [ 1] reset_handler(): system halted 02/08/2020 10:22:32 [ 1] reset_handler(): bootloader started after software reset 02/08/2020 10:22:32 [ 64] init_block_devices(): file system successfully mounted 02/08/2020 10:22:32 [ 2048] update(): update pack found at /flash/firmware/m717_1_04.pack 02/08/2020 10:22:35 [ 2048] update(): M717-app update succeeded 02/08/2020 10:22:35 [ 1] reset_handler(): system halted
: log 02/08/2020 10:22:37 [ 1] reset_handler(): system started after software reset 02/08/2020 10:22:37 [ 1] init_block_devices(): database opened in 94.40 ms 02/08/2020 10:22:37 [ 64] init_block_devices(): file system successfully mounted 02/08/2020 10:22:37 [ 1024] init_config(): configuration OK
: log stat The write pointer is at block 8 Oldest: Wed Jul 22 23:25:55 2020 Newest: Tue Aug 4 10:49:05 2020
: log clear All log entries will be erased. Proceed? (y/n) n Logs not erased 18 4.1.7. attr Description Usage Remarks Used to show/modify attributes. attr [ -a | -s | -t | -h | -v ] to show attributes, -a for all, -s for all sensors, -t for all tags attr [ nodeid ] attrib_name [ attrib_value ] to show or modify a specic attribute;
if nodeid is not specied, the rtu node is assumed; if an attrib_value is specied, the attribute with attrib_name from the respective node_id will get the new value, otherwise the current value will be shown. The -v option appends a CRC on the attribute value; this option is not for interactive use, rather for test programs operating on the RTU. The -h option shows a short help text. Note that only the read/write attributes can be modied, while the volatile attributes (e.g., assignedIP, telemetry, etc.) and read-only attributes (gsmCCID, swVersion, etc.) cannot. An attribute successfully modied over the command line will be also updated on the M2M Gateway at the rst successfully connection. Examples
: attr gsmAllowRoaming true
: attr gsmAllowRoaming false
: attr -s
*** sensor ID (index): 79630 (0) type: Intern acquisitionMode: 2 acquisitionSchedule: 0 info: M717 rev. C Internal Sensor lastDate: Mon Jun 29 15:00:00 2020 putdataDate: Mon Jun 29 15:00:00 2020
*** sensor ID (index): 77178 (1) type: SDI-12 acquisitionMode: 2 acquisitionSchedule: */10 sdiAddress: 0 sdiMethod: CC sdiPostmethod:
sdiDebug: false sdiInfo: 13 CSL CS215 2.0 lastDate: Mon Jun 29 15:30:00 2020 putdataDate: Thu Jan 1 01:00:00 1970
: attr 77178 sdiMethod CC
: attr 77178 sdiMethod MC
: attr 77178 sdiMethod MC 4.1.8. pin Description Usage Remarks Manage the PIN on the RTU. pin [ -v ] [ PIN [ PUK ]] to set the PIN (and PUK) pin clear to clear both the PIN and the PUK A SIM card is protected by a PIN (Personal Identication Number). This PIN must be known to the RTU, so that it can enable the SIM card after every start-up. This 19 command is entered only once, normally in the factory, but may be necessary after e.g. a SIM card has been replaced. The -v option attaches a CRC to the command string and should only be used during communication with computers (e.g., during manufacturing). Description Shows the hardware ID of the RTU. hwID [ ID ], where ID is the ID to set The ID can be set only once; this is done during manufacturing. The ID can be also shown using the attr command (attr hwID). Directly connect to a character device. connect <device> [ baudrate [ nr_bits [ parity ]]], where <device> is the devices path to connect to. Currently following devices are available:
/dev/modem the cellular modem port
/dev/pcui the cellular modem secondary port
/dev/mpi the MPI serial port (normally used for sensor/data logger interfaces)
/dev/sdi the SDI serial port For the /dev/mpi and /dev/sdi devices, optionally the baud rate, the number of bits and the parity may be specied. This command is interactive, to exit the command type <ctrl-X>. Remarks This command is restricted when connected over telnet: the /dev/pcui port cannot be accessed. Example
: pin PIN is set PUK is set 4.1.9. hwid Usage Remarks Example
: hwid hwID is 5010 4.1.10. connect Description Usage Example
: connect /dev/modem Type <CTRL-X> to exit
^SYSSTART 4.1.11. xfer Description Usage Remarks Transfer les to/from the RTU using the x-modem protocol. xfer { -r | -s } <lename> where <lename> is the name of the le to be transferred. The -r option is used to transfer les from the PC to the RTU, while the -s option to send les from the RTU to the PC. This command is restricted to the USB and MPI ports; it doesnt work over telnet. After issuing the command, switch your program to X-modem send, or transmit mode (depending on the option used). 20 Examples
: xfer -r m717_1_04.pack CCC
: xfer -s test.json 4.1.12. fwupdate Description Initiate a rmware update. Usage Remarks fwupdate <lename> where <lename> is the name of the package le containing the rmware fwupdate -a to update to the latest ocial rmware version distributed by Metrilog. The RTU automatically searches and retrieves the package le over the Internet. When updating from a local le, it is essential that the package le has a .pack extension, and is located in the rmware/ directory on the local le system. The le can be brought on the le system either using the xfer command (x-modem protocol) or by downloading it from the Internet using the net get command. Before the update starts, the le is checked for validity and the user is prompted for a nal conrmation. If you are connected over USB, during the update the virtual serial port will disconnect and you might need to unplug and re-plug the USB cable. Examples
: fwupdate firmware/m717_1_04.pack Package is ok M717-boot, 0.94, M717-app, 1.04, force Proceed with the firmware update? (y/n): y Please stand by, the system will be updated. It will take several seconds. During this time, don't switch the power off!
: fwupdate -a New firmware found, loading file... Update under way, don't switch the power off!
: fwupdate -a The firmware is up to date 4.1.13. reboot Description Usage This command reboots the RTU. reboot [ -c | -cc ]
Without parameters, the system will reboot. With the -c parameter, the system reboots, but immediately after start-up the internal conguration will be erased. With the -cc parameter, the system reboots, but immediately after start-up both the internal conguration, as well as all the historians will be erased. WARNING: after using the option -cc, all data in the RTU will be lost!
Remark This operation must be done whenever an RTU is relocated to another site with a dierent sensor conguration. 21 Examples
: reboot Are you sure? (y/n) y Please don't disconnect the power while the modem is shut down... Done. System will now restart
'Wagram' password:
: reboot -c Are you sure? The configuration will be cleared (y/n): y Please don't disconnect the power while the modem is shut down... Done. System will now restart, the configuration has been cleared Type "help" for the list of available commands
Exits the CLI. This command is particularly important when connected over telnet, to close the connection. It has no special meaning when connected over USB or the MPI connector. However, in all cases the connection to the CLI will be lost, and for USB specically, the USB cable must be unplugged and plugged again to reconnect. Commands operating on the Data Acquisition subsystem. dacq [ -h | subcommand ] with the -h parameter (or without parameters), the list of all data acquisition commands will be shown. The subcommands are described in the following sections. Get the sensor/logger information or version. dacq info <sensor_IX> where <sensor_IX> is the ID of the sensor to inquire. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. 4.2. Data Acquisition Commands 4.1.14. exit Description Example
: exit Exiting 4.2.1. dacq Description Usage 4.2.2. dacq info Description Usage Remarks Examples
: dacq info 0 13MetrilogM512rD1.5.7439#000000
: dacq info 1 13 CSL CS215 2.0 22 Used to sample and show sensor/logger data. dacq sample <sensor_IX> [ date [ time ]] where <sensor_IX> is the ID of the sensor to sample, while the optional date and time parameters can be used to specify a point in time after which the data should be returned. Obviously, this is valid only for loggers, i.e., devices having storage possibilities (e.g., Thies loggers or Vantage Pro consoles); for SDI-12 sensors, these parameters are ignored. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. The values in parenthesis represent the status bits: if 0, all is OK while status 1 means missing data. Certain sensors may need longer time to return data, just be patient. Used to sample and store sensor/logger data. dacq retrieve <sensor_IX> [ date [ time ]] where <sensor_IX> is the ID of the sensor to sample, while the date and time parameters can be used to specify a point in time after which the data should be returned, or in case of simple sensors (e.g. SDI-12), the date/time stamp which will be associated to the retrieved values when they are stored in the RTUs memory. If no date is provided, the current date and time will be used; for data loggers, the date of the last datapoint in the local memory will be used for the request and the returned data points date will be used as timestamp. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Note that this command, in contrast to the dacq sample command, stores the retrieved data to the internal data base of the RTU. This data will then be pushed on the M2M Gateway during the next session. Certain sensors may need longer time to return data, just be patient. 4.2.3. dacq sample Description Usage Remarks Example
: dacq sample 1
Mon Aug 3 18:27:45 2020 26.025999[0] 60.115002[0]
4.2.4. dacq retrieve Description Usage Remarks Example
: dacq retrieve 0 4.2.5. dacq abort Description Usage Aborts a running dacq sample or dacq retrieve transaction. dacq abort <sensor_IX> where <sensor_IX> is the ID of the sensor to abort a running transaction. Remarks Not all sensors support an abort operation. 23 Example
: dacq abort 0 4.2.6. dacq date Description Usage Remarks 4.2.7. dacq interval Example
: dacq date 0 Description Usage Remarks Example
: dacq interval 0 600 4.2.8. dacq direct Description Usage Remarks The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Use to set/synchronise the date/time of a sensor/logger. dacq date <sensor_IX> where <sensor_IX> is the ID of the sensor to synchronise. Not all sensors support a date command, in particular it is not supported in a standard way by the SDI-12 sensors. Thies and Davis loggers support this command. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Used to set the sampling interval of a sensor/logger. dacq interval <sensor_IX> <interval> where <sensor_IX> is the ID of the sensor to set the sampling interval to and <interval> is the new sampling interval, in seconds. Not all sensors support an interval command, in particular it is not supported in a standard way by the SDI-12 sensors. Thies and Davis loggers support this command. The command determines the sampling and storage interval in the logger themselves. Do not confuse this setting with the interval dened by a sensors acquisitionSchedule attribute; for SDI-12 sensors, this attribute denes the storage interval in the RTUs memory. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Used to directly connect to a sensor. dacq direct <sensor_IX> where <sensor_IX> is the ID of the sensor to connect to. This command is interactive, to exit the command type <ctrl-X>. While this command allows connection to any sensor, not all sensors support an interactive conversation. In particular SDI-12 sensors cannot be reached in this way. Moreover, the sensor/logger commands must be known. Thies loggers and 24 Example
: dacq direct 0 Type <CTRL-X> to exit 4.2.9. dacq t Description Usage Remarks Example
: dacq t 0 0I!
013 CSL CS215 2.0 4.2.10. hist Description Usage Davis consoles have their own proprietary protocols, for more details consult their respective user manuals. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Used to send a command transparently to a sensor. dacq t <sensor_IX> <cmd> where <sensor_IX> is the ID of the sensor to send a command to and <cmd> is the command to be sent. Not all sensors support the transparent command. For SDI-12 <cmd> is a standard SDI-12 command, including the exclamation point (!); for Davis consoles <cmd> is a Davis command as described in the Vantage Pro Serial Communication Reference Manual (see Davis Instruments web site http://www.davisnet.com); for Thies <cmd> is a Thies command as described in the Thies TDL14 or DL16 User Guide. The ID of a specic sensor can be found using the attr -s command, under the section sensor ID (index), it is the value given in parenthesis. If there is only one sensor congured in the RTU, then the ID is always 0. Historians command and subcommands, used to inspect the sensor data stored in the local memory (data base). hist [ -h | <cmd> ] with the -h parameter, the list of all subcommands will be shown. hist <hist#> <date> [<time>] Display the rst 20 values stored for the historian
<hist#> starting with <date> and <time>. Without a parameter, the next 20 values
(or less if not so many are available) for the previously selected historian will be displayed. The <time> parameter may be left out, in which case the time will be automatically set to 0:00 for the specied day. The hist subcommands are described in the following sections. To look-up the historian ID corresponding to a certain tag, use the hist map command (see below). Remarks Example
: hist 5 1/10/20 5: 01/10/2020 00:00:00 23.540001[0]
5: 01/10/2020 00:10:00 23.540001[0]
5: 01/10/2020 00:20:00 23.570000[0]
5: 01/10/2020 03:00:00 23.500000[0]
25 5: 01/10/2020 03:10:00 23.490000[0]
: hist 5: 01/10/2020 03:20:00 23.510000[0]
5: 01/10/2020 03:30:00 23.480000[0]
5: 01/10/2020 03:40:00 23.510000[0]
5: 01/10/2020 06:20:00 23.410000[0]
5: 01/10/2020 06:30:00 23.450001[0]
4.2.11. hist info Description Usage Remarks Example Show the data interval stored for a specic tag. hist info <hist#> where hist# is the historian for which to display the dates of the oldest and the newest record. To look-up the historian ID corresponding to a certain tag, use the hist map command (see below). Depending on the number of records and the number of tags in the data base, the response to this command may take up to 20 seconds.
: hist info 5 Oldest: Sat May 23 19:20:00 2020 Newest: Mon Dec 14 16:50:00 2020 4.2.12. hist stat Description Used to display historian statistics. Usage Remarks hist stat. A table will be displayed with several columns. The following information is of relevance for the Metrilog support technicians, therefore it is not important to understand exactly what it means (refer to the example below):
Sensor: is the sensor index as stored in the RTU. ID: is the sensor ID as retrieved from the M2M Gateway. Type: is the sensor type (SDI-12, Thies, Davis, etc.). Stream: is an internal index associating a historian with a sensor. Block: a logical block in the storage (there are currently 768 blocks allocated to the historians). First: date of the oldest record for the sensor. Last: date the newest record for the sensor. Example
: hist stat Sensor ID Type Stream Block First Last
0 78473 SDI-12 1 727 23/05/2020 19:20:00 14/12/2020 16:50:00 1 77178 SDI-12 0 725 23/05/2020 19:20:00 14/12/2020 16:50:00 2 79630 Intern 4 724 23/05/2020 19:20:00 14/12/2020 16:00:00 4.2.13. hist map Description Usage Used to display the historians map. hist map. 26 Remarks The command will display a table with the mapping of the historians to the sensor IDs, as well as their status (active/deleted). The stream to which a historian belongs will be also shown. A "deleted" historian is one that is no more active, it will be "recycled" when new sensor will be added after all historians have been used (currently 128). Note that deleted historians do not belong to any stream. To look-up the historian for a certain tag, rst use the attr -t command to identify the ID of a tag (or from the M2M Gateway: select the sensor, click the Info tab there you will nd the Public Node ID); using the ID, look-up the historian in the table shown by the hist map command. Example
: hist map Hist. Tag ID Stream Status
0 77180 0 active 1 77179 0 active 2 78482 1 active 3 78481 1 active 4 78480 1 active 5 78479 1 active 6 78478 1 active 7 78477 1 active
11 79625 - deleted 12 79624 - deleted 13 79623 - deleted
17 79631 4 active 18 79632 4 active 19 79633 4 active 20 79955 4 active Usage Remarks Example 4.2.14. hist purge Description Used to purge (delete) the historians. hist purge [-y]. Purge all historians. If the -y option is used, then the historians will be purge without asking for a conrmation, otherwise the user will be prompted for a conrmation. The command takes about 20 seconds to complete. WARNING: all sensor data stored in the local data base will be lost!
: hist purge All stored data will be lost. Proceed? (y/n) y Please wait, it will take some time... Historian data purged 4.3. Data Acquisition Legacy Commands The commands in this group are maintained to assure compatibility with legacy systems. Their use is not recommended for new implementations; use a variant of the dacq command instead. The main dierence between the equivalent dacq commands and the legacy commands is that for the former a valid conguration is required to access the sensors, whereas for the later it is not. 27 Used to issue a command in transparent mode to an SDI-12 sensor. sdi t <command> where <command> is a standard SDI-12 command, including the sensors address and the exclamation point (!). The command implements the standard SDI-12 timing. Used to issue a command in transparent mode to a Thies data logger. thi t <command> where <command> is a Thies command as described in the Thies TDL14 or DL16 User Guide. The command appends the SOT and EOT characters required by the Thies serial protocol, therefore the user must not add them.
: sdi t AI!
A13MetrilogM512rC1.4.1055#000000
: sdi t AM!
A0048
: sdi t AD0!
A+25.17+31.71+0+0+1+0+1+12.03 4.3.1. sdi t Description Usage Remarks Examples 4.3.2. thi t Description Usage Remarks Examples
: thi t XX 3.30
: thi t ZZ 17:20:12
: thi t DD 04.08.20 Examples
: thi direct Type <CTRL-X> to exit Momentane Messwerte:
Datum / Zeit: 04.08.20 17:18:56 Windrichtung :293 Grad
: thi t mm 17.3425 260 2.8 20.6 48.3 9.3 20.7 1009.6 0.0 0 249 1 502.1 25.2 0 0.0 04.08.20 17:20:33 4.3.3. thi direct Description Usage Remarks thi direct Used to directly connect to a sensor attached to the MPI connector. This command is essentially equivalent to the connect /dev/mpi command. To exit the command, enter <ctrl-X>. To be able to use the direct command, the sensor/
logger commands must be known. Thies loggers and Davis consoles have their own proprietary protocols, for more details consult their user manuals. 28 Windges. (75): 2.2 m/s Temperatur 2m: 20.6 Grad C Rel. Feuchte : 49.0 %
Taupunkt : 9.5 Grad C Temperatur5cm: 20.5 Grad C Luftdruck (a):1009.6 hPa Niederschlag : 0.0 mm Nied.-Melder :0 Gl-Strahlung : 99 W/qm Sonne ja/nein:1 Sonnen.-Dauer: 500.5 min/d Temperatur(w): 24.7 Grad C Batteriesp. :13.4 V Luefterstrom :125 mA Heizungsstrom: 0.0 A SYNOP 1min : 0 SYNOP Niedersch.LNM: 0.0 mm ENDE
: thi direct Type <CTRL-X> to exit OK Jun 3 2013 OK 3.15 Note:
In the examples above, the user input is not visible, as nor the Thies logger, neither the Davis console echo the user input. In the rst example the command <ctrl-B>mm<ctrl-C> was sent to a Thies DL16 logger, while in the second example the commands VER and NVER were sent to a Davis Vantage Pro 4.4. Communication Commands console. 4.4.1. net Description Usage Used to show the network status, download les or initiate a session to communicate with the M2M Gateway. net [ -h ] to show the current network status; use the -h option to show the command usage. net get <url> <path> to download a le from <url> and save it on the local le system to <path> (see below). net { up | down | session } are subcommands and are described below. Remark The net subcommands are not available over telnet. Examples
: net Network status: down, ssl disabled
: net up
: net Network status: up, ssl enabled IP address: 10.96.184.76 DNS1: 213.33.99.70 DNS2: 80.120.17.70 4.4.2. net get Description Used to download a le from a http server and save it on the local le system. 29 Usage Remark net get <url> <path>
Only http und https protocols are currently supported. Example
: net get https://update.metrilog.com/m717_update_102.pack firmware/
File transfer started, it may take some time...
File transfer succeeded, 336108 bytes downloaded
: ls firmware
-rw 336108 Jun 29 2020 17:00 - m717_update_102.pack Capacity: 0.01 GB (12288 KB), available: 0.01 GB (11600 KB). Starts up the IP network (connect to the Internet). net up 4.4.3. net up Description Usage Example
: net up 4.4.4. net down Description Usage Example
: net down Description Usage Remarks 4.4.5. net session Example
: net session 4.4.6. modem Description Usage Remarks Example Shuts down the network connection (disconnect from the Internet). net down Executes a session with the M2M Gateway. net session A complete session is executed; normally the sessions are automatically executed by the RTU, as specied by the connectSchedule attribute. This command allows the execution of an outstanding session, or if the connectMode attribute is set to 1, manually. Used to show or control the state of the built-in cellular modem. modem { direct | pwrup [hard] | pwrdown | reset | mode | -h }
Without a subcommand, the current modem state will be shown. The information provided may help debug cellular connection problems. The -h option lists all the subcommands; each subcommand is separately described in the following sections. Some modem subcommands are not available over telnet. 30 4.4.7. modem direct Description Usage Remarks Examples
: modem direct Type <CTRL-X> to exit OK at+creg?
+CREG: 2,1,"426C","00094901",7 OK 4.4.8. modem pwrdown at+cpin?
+CPIN: READY OK Description Usage Remarks Example
: modem pwrdown 4.4.9. modem pwrup
: modem Modem status:
Operator: 23201 (automatic) Registered, home Network: LTE, LAC/CI: 426c/94901 (17004/608513) RSSI: -65dBm (23) Service: LTE (valid) Service setting: auto SIM card: present SIM CCID: 89430103317024015403 Modem model: ME909s-120 Modem version: 11.617.24.00.00 IMEI: 867377020122424 Opens a direct connection to the cellular modem. modem direct Used to issue AT commands to the GSM modem when debugging SIM card problems or general GSM registration issues. The command can be used only over the USB and MPI ports; it is not available over telnet. To exit the command, type
<ctrl-X>. See also the connect command. Shuts down the modem (default state is on). modem pwrdown In power down mode, the modem deregisters itself from the cellular network; the power consumption in this state is very low, but it can't receive SMS or calls. Description Starts up the modem (default state). Usage Remarks modem pwrup [hard]
This is the default state after the RTU is powered up, unless the low power mode is active (see the lowPowerMode attribute description). With the hard option, the modem will be hardware reset before being soft started and initialised. This option should be used only if the normal (soft) power-up fails. 31 Examples
: modem pwrup
: modem pwrup hard 4.4.10. modem reset 4.4.11. modem mode Example
: modem reset Description Usage Remarks Example
: modem mode Modem sleeps Description Hard resets the cellular modem. Usage Remarks modem reset Avoid issuing this command, use it only when the modem is not responsive. Use the modem pwrdown/modem pwrup commands instead, and if the modem still does not react, try the modem pwrup hard command (see above). Shows if the modem is in sleep mode or not. modem mode Most of the time the cellular modem is in sleep mode, only when it communicates with the M2M Gateway or handles an SMS does it get out of sleep mode. 4.5. File System Commands specic conguration data les. and *) are not supported. The M717 RTU has a built-in FAT le system based on a ash memory; the le system capacity is rather small by today standards (12 Mbytes), but enough to full the required functions: rmware update and A reduced set of commands is provided to inspect and manipulate the le system. Note that wildcards (?
4.5.1. ls Usage Remarks Example Description Lists the les in the current directory. ls [path], where the optional path is the path to a directory to be listed. The list displays for each le:
type ag, can be either d (directory) or (le) size (in bytes) date of creation name
: ls drw 0 Jun 26 2020 17:49 - firmware 32
-rw 337408 Jun 29 2020 16:54 - m717_1_03.pack
-rw 330199 Jun 29 2020 17:00 - m717_1_02.pack
-rw 4194304 Aug 8 2020 17:15 - speedtest.bin Capacity: 0.01 GB (12288 KB), available: 0.01 GB (7504 KB). Description Creates a new directory. mkdir <path-to-dir>, where <path-to-dir> is the path to the directory to be created.
: mkdir new-directory
: ls drw 0 Jun 26 2020 17:49 - firmware
-rw 337408 Jun 29 2020 16:54 - m717_1_03.pack
-rw 330199 Jun 29 2020 17:00 - m717_1_02.pack
-rw 4194304 Aug 8 2020 17:15 - speedtest.bin drw 0 Aug 8 2020 19:09 - new-directory Capacity: 0.01 GB (12288 KB), available: 0.01 GB (7500 KB). Used to change the current path to a new directory. cd [path], where path is the path to the directory to change to. If no path parameter is given, then the current path will be changed to the home directory. In this context, the home directory is the root of the block device, currently named /ash/. 4.5.2. mkdir Usage Examples 4.5.3. cd Description Usage Remarks Examples
: cd firmware
: pwd
/flash/firmware
: cd
: pwd
/flash/
4.5.4. cp Usage Remarks Examples Description Used to copy a le. cp <source_le> <target_le>, where <source_le> and <target_le> are the path to the source and target les respectively. Multiple les, as well as directory copy is not possible.
: cp m717_1_02.pack new-directory
: cp m717_1_03.pack new-directory
: ls new-directory
-rw 330199 Aug 8 2020 20:12 - m717_1_02.pack 33
-rw 337408 Aug 8 2020 20:12 - m717_1_03.pack Capacity: 0.01 GB (12288 KB), available: 0.01 GB (6844 KB). Prints the working (current) directory. pwd. 4.5.5. pwd Description Usage Examples
: pwd
/flash/
: cd new-directory
: pwd
/flash/new-directory
: cd ../firmware
: pwd
/flash/firmware
: cd
: pwd
/flash/
4.5.6. rm Usage Remarks Examples 4.5.7. cat Description Usage Remarks Example
: rm new-directory
: rm m717_1_02.pack Description Used to remove a le or a directory. rm <path>, where <path> is the path to the le/directory to be deleted. It is not possible to delete multiple les using wildcards. However, if a directory containing more than a le is deleted, all the les in the directory will be deleted. Dumps the content of a le. To the console cat <path>, where <path> is the path to the le to be dumped. The command does not check if the le contains text or binary data. Beware of long les, as there is no possibility to interrupt this command.
: cat sdi-sensors.json
"fileVersion": 2,
"sdiSensors": [
"name": "Campbell CS215",
"sdiID": CS215",
"setToAddress": "0"
"name": "Metrilog M512",
"sdiID": "MetrilogM512",
"setToAddress": "*"
"name": "Lambrecht ARCO Wind Speed",
"sdiID": "LMGmbH1514582S", 34
"setToAddress": "5"
"name": "Lambrecht ARCO Wind Direction",
"sdiID": "LMGmbH1514582D",
"setToAddress": "6"
"name": "Tekbox Rain Gauge",
"sdiID": "TEKBOXVNTBSRG",
"setToAddress": "7",
"configCommands": [
"7XSBV,+0.20!",
"7M!",
"#2",
"7D0!"
4.6. Command Line Interface Error Messages The following list describes the error numbers the CLI may return and their meaning:
CMD_NOT_FOUND INVALID_PARAM NOT_ALLOWED NO_SUCH_DEVICE MALLOC_ERROR FILE_SYSTEM_ERROR SERIAL_SETATTRIB_ERR USR_TIMEOUT WRONG_PASSWORD UNEXPECTED_ANSWER SMS_FAILURE FACTORY_TEST_FAILED FLASH_ERROR BAD_CRC_ON_PIN_PUK PIN_ENABLE_DISABLE_FAILED EXITCOMMAND 1 5 6 7 8 9 10 11 12 13 14 20 31 33 34 99 Invalid command Invalid parameter Command not allowed from this port The requested character device does not exist Error allocating memory (out of memory) Generic file system error Serial port error User timeout (no keys pressed for a defined time) Invalid password Unexpected answer (e.g. from a sensor) Failed to send and/or receive SMS The factory test could not be completed Error writing to/reading from the flash memory CRC error when sending PIN & PUK (-v option) Failed to enable or disable the PIN request User requested exit from CLI 35 5. Attributes This section details the attributes used to dene the RTU functionality. It is important rst to understand the function of a certain attribute before attempting to change its value, as improper manipulation of the attributes can lead to malfunction. Attributes values may be changed either through the M2M Gateway User Interface, or using the command attr in the CLI (see the attr command). It is not possible to directly add or delete attributes to/from an existing node. This may be done only by applying a dierent template to the respective node (use the Apply Template tab on the M2M Gateway). If the required template does not exist, you can:
Create a new template e.g. by using the Save as Template tab on the existing node. Add or delete attributes to/from the newly saved template. Use the Apply Template tab on the initial node. There are three levels of attributes: RTU, sensor and tag. Note: The type in the table below refers to read/write operations on attributes performed over the RTUs CLI:
r means read-only, while r/w means the attribute is both readable and writable. Certain attributes may require multiple parameters; a multi-parameter attribute can be issued over the CLI by quoting it, e.g., attr commandSchedule 0 5 */2. The description below takes as reference the attributes view on the M2M Gateway, but explains also the RTU internal attributes. Which attributes are displayed on the M2M Gateway largely depends on the user's rights. However, on the CLI the user rights are not enforced (except that the read-only attributes cannot be written). Note: Not all attributes are described in this manual, rather only those available to realm administrators on the M2M Gateway. When using the CLI, many more attributes are visible, but it is strongly recommended to not change them! The functionality of the RTU may be aected, even rendered inoperable!
5.1. RTU Attributes Attribute Type Description assignedIP r connection is up. With the appropriate equipment it can be used to The IP address assigned by the cellular provider while the IP cliOverIP r/w telnet into the RTU (see also the cliOverIP attribute). If true, at the next IP session a listening telnet server on the port dened by the cliPort attribute will be started; if no client connect to the server after a number of seconds dened by the listenTimeout attribute, the server will shut down. This attribute defaults to false and will automatically be set to false after a session ends or the server times out. 36 Attribute cliPort Type r Description The port number on which the telnet server will listen (default 22). connectSchedule can be set is therefore one minute. However, for practical reasons connectSpread connectSchedule (default 30). If 0, no connection randomising will r r r r r r r r r r r/w r/w r/w r/w Denes the connection schedule of the RTU. It uses a cron syntax, ex: */10 means that the RTU should connect every ten minutes, starting with minute 0. A complete cron string may specify minutes, hours, days, months and the day of the week. The smallest unit that related to cellular communication specics, the minimum recommended interval is ve minutes. For additional details on conguring cron, consult the unix man pages for crontab (5)
(https://man.openbsd.org/crontab.5). The value of this attribute is specied in seconds. A random value in the interval 0 ... connectSpread will be added to the computed be used. This is used to distribute the load on the server when many RTUs initiate a connection at the same time. Time stamp of the last successful update on the server; it represents the time stamp for all volatile attributes. CCID of the SIM card. IMEI of the cellular modem. r/w Own number (MSISDN) allocated to the RTU (i.e., SIM card). The cellular modem type. The rmware version of the cellular modem. Serial ID of the RTU. RTU type. RTU manufacturers name. Baud). RS-232 RS-422 RS-485 Baud). SDI-12 RS-485 CAN For the wiring of the MPI connector see also the section Installation. If true, it activates an 150 terminating resistor (valid only in RS-422 and RS-485 modes; default false). The baud rate used by the SDI (the 4-pin connector, default 1200 The operation mode of the SDI (default SDI-12); it can be:
For the wiring of the SDI connector see also the section Installation. 37 date gsmCCID gsmIMEI gsmNumber gsmType gsmVersion hwID hwType manufacturer mpiMode mpiTermination sdiBaudRate sdiMode mpiBaudRate r/w The baud rate used by the MPI (the 8-pin connector, default 19200 The operation mode of the MPI (default RS-232); it can be:
Attribute Type Description sdiMsg r/w spaces between commands are optional, they improve readability. Send SDI command(s) in pseudo-transparent mode to an SDI sensor. The attribute is intended to be updated through the M2M Gateway. More than one command can be sent in one string; while If a delay is required between commands, it can be specied as \n, where n species the delay in seconds. Example: 0M! \5 0D0! The results returned by the sensor(s) are piped to the log. If true, it activates an 150 terminating resistor (valid only in RS-485 and CAN modes; default false). The version of the RTUs bootloader. The version of the RTUs rmware. A list of telemetry values reecting various RTU conditions (power supply, microcontrollers temperature, RSSI, etc.). The ISO denition of the time zone where the RTU operates (default UTC). The timeZoneOset attribute is derived form this attribute. Time since the last RTUs reboot. sdiTermination r/w swBootVersion swVersion telemetry timeZone uptime r r r r r/w 5.2. Sensor Attributes Attribute Type Description Denes how the sensor will be sampled (default 2). Following modes acquisitionMode r/w 0 no sampling, sensor is disabled. 2 automatic mode, dened by the sensor's aquisitionSchedule Denes the sensor sampling schedule. It uses a cron syntax, ex: */10 means that the sensor should be sampled every ten minutes starting with minute 0. A complete cron string may specify minutes, hours, acquisitionSchedule r/w days, months and the day of the week. The smallest unit that can be set is therefore one minute. For additional details on conguring cron, consult the unix man pages for crontab (5) (https://man.openbsd.org/
archiveInterval r/w WeatherLink logger/interface. This attribute is valid for Davis loggers Species the archiving interval in minutes (default 10) on a Davis davisVersion r Returns the software version of the Davis WeatherLink logger/
interface. This attribute is valid for Davis loggers only. are dened:
1 not used. attribute. crontab.5). only. 38 Attribute Type Description The icon graphic that will be used to display the sensor on the M2M Gateway (default COMBO); the graphic must already exist on the iconName server (on the UI of the M2M Gateway, click the Info button, then Icons). Note: this attribute is used only by the M2M Gateway and it does not exist in the RTU. lastDate The date the sensor was sampled last time. sdiAddress r/w The SDI sensor address. This attribute is valid for SDI-12 sensors only. The date of the sensors last values pushed unto the server (M2M Gateway). Normally the equivalent RTU attribute is used, unless a sensor has a dierent schedule. This is an RTU internal attribute, it does not exist on the server. Returns the result of the "I" (Info) command to an SDI-12 sensor. This attribute is valid for SDI-12 sensors only. The acquisition method used; as per the SDI-12 specication, this can putdataDate sdiInfo sdiMethod r/w be M, C, R, MC, CC, RC and V. This attribute is valid for SDI-12 sensors sdiPostmethod r/w thiesInfo An (optional) SDI-12 command sent after sampling the sensor. Usually this is an SDI-12 X command. The address and the SDI-12 terminator (!) should be skipped (the address is dened by the sdiAddress attribute). This attribute is valid for SDI-12 sensors only. Returns the software version of the Thies data logger. This attribute is valid for Thies TDL14 and DL16 data loggers only. Denes the request sent to the Thies data-logger. Currently it can only thiesMethod r/w be ds. This attribute is valid for Thies TDL14 and DL16 data loggers only. only. r r r r r 5.3. Tag Attributes Attribute Type EUID r/w iconName r/w Description Engineering Unit Identication. Each tag has a value type (e.g., mm, C, km/h, etc.), which in turn has an ID assigned. The EUID can be read by a data retrieving client (e.g., over the addUPI protocol) and display the tag values with the proper type. A list of all dened EUIDs can be reached over the M2M Gateway UI: click the Info button, then the Engineering Units tab. This attribute does not exist on the RTU. The icon graphic that will be used to display the sensor on the M2M Gateway; the graphic must already exist on the server (on the UI of the M2M Gateway, click the Info button, then Icons). Note: this attribute is used only by the M2M Gateway and it does not exist in the RTU. 39 Attribute Type Description Denes how commands dened by the sdiCommand attribute will be issued to output tags (default 2). Following modes are dened:
0 no commands, tag is disabled. commandMode r/w 1 not used. conversionParams r/w formula Celsius = 0,5555*Fahrenheit - 17,7778 (generic: y = a*x + b) 2 commands will be sent in automatic mode, dened by the commandSchedule attribute. This attribute is valid for SDI-12 actuators only. Denes the schedule to send commands dened by the sdiCommand attribute to an output tag. It uses a cron syntax, ex: 0 1-5 means that the command will be sent between one and 5 AM, every hour at minute 0. A complete cron string may specify minutes, hours, days, months and the day of the week. The smallest unit is therefore one minute. For additional details on conguring cron, consult the unix man pages for crontab (5) (https://man.openbsd.org/crontab.5). This attribute is valid for SDI-12 actuators only. A string representing a rst or second degree polynomial that is used by the RTU to convert the input value; the converted value will be stored in the internal memory. This feature can be used to convert e.g. Fahrenheit degrees to Celsius, or vice-versa. As an example, the translates to the string 0.5555 -17.7777. For second degree polynomials, three parameters are required, and their order is always from left to right (ex.: a, or a b, or a b c). This attribute is valid for Davis loggers only. Value returned by the Davis WeatherLink that represents an invalid tag value. When a tag returns a value equal to the dashValue attribute, a status 1 (missing data) is generated for this value. This attribute is valid for Davis loggers only. Denes the position of the tags value in the string returned by a the string. This attribute is valid for Davis loggers only. Denes the values length (in bytes) in the string returned by the DMPAFT command. This attribute is valid for Davis loggers only. The last value returned by the tag. On the server this attribute does not exist, its values are stored in the historians. The date of the sensors last values pushed unto the server (M2M Gateway). Normally the equivalent RTU or sensor attribute is used, commandSchedule r/w dashValue r/w davisSize r/w lastValue r r davisIndex r/w DMPAFT command. The davisIndex starts with 0, for the rst position in putdataDate unless a tag has a dierent schedule, or if the data ow to the server was interrupted. This is an RTU internal attribute, it does not exist on the server. 40 Attribute Type Description sdiCommand r/w The string representing the command to be sent to an output tag;
usually it is an X command (or a manufacturer custom command). The address and the SDI-12 terminator (!) should be skipped (the address is dened by the sdiAddress attribute). This attribute is valid for SDI-12 actuators only. See also the commandSchedule and commandMode attributes. sdiIndex r/w Rn command. The sdiIndex starts from 0, for the rst position in the Denes the position of the tags value in the string returned by a Dn or status signify errors (e.g., 01 missing data). On the server this attribute does string. This attribute is valid for SDI-12 sensors only. The status of the tag after being sampled. 00 means OK, other values not exist, its values are stored in the historians. Denes the position of the tags value in the string returned by a Thies datalogger ds command. The thiesIndex starts from 0, for the rst position in the string. This attribute is valid for Thies TDL14 and DL16 thiesIndex r/w value data loggers only. Not used. r r 41 6. Technical Specications Parameter Value Cellular modem Interfaces GPRS/EDGE/WCDMA/LTE Cat 4 RS-232, RS-422, RS-485, CAN, SDI-12, USB 2.0 Supported protocols TCP/IP, HTTP, HTTPS Internal storage 16 Mbytes, non-volatile Sensor sampling interval Programmable (minutes, hours, days, weeks) Communication interval Programmable (minutes, hours, days, weeks) Power supply External 6 to 30 Volt (M12 connectors); 5 Volt (USB) Power consumption Standby, receive enabled: typ. 2.8 mA (at 12 V) Standby, receive disabled: typ 0.8 mA (at 12 V) Transmit: max. 300 mA (at 12 V), max. 600 mA (at 6 V) Operating temperature Dimensions Weight Environmental protection class
-30C to +60C 110/75/55 mm 400 g IP66 42
1 | Label and Placement Information | ID Label/Location Info | 229.69 KiB | May 20 2022 |
Metrilog Data Services GmbH www.metrilog.com Remote Terminal Unit Model M717 Power: 6-30 VDC/5 W (max.) IP66 06000 Serial no:
Made in Austria FCC-ID: 2A6UM-M717D Contains FCC-ID: 2AJYU-8PYA007 Metrilog Data Services GmbH www.metrilog.com Remote Terminal Unit Model M717 Power: 6-30 VDC/5 W (max.) IP66 Serial no:
06000 FCC-ID: 2A6UM-M717D Contains FCC-ID: 2AJYU-8PYA007 This device complies with part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) This device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. Made in Austria
1 | Confidentiality Letter | Cover Letter(s) | 349.57 KiB | May 20 2022 |
fa metrilog May 16, 2022 TO WHOM IT MAY CONCERN Pursuant to Paragraphs 0.457 and 0.459 of the Commission's Rules (47 C.F.R) and Section 552(b)(4) of the Freedom of Information Act, Metrilog Data Services GmbH requests confi-
dentiality for the following product:
FCC ID: 2A6UM-M717D, M717 Remote Terminal Unit For the product stated above, we request that the following information be held confidential:
1; Circuit diagrams, BOM, and PCBs submitted as Equipment Authorization Electronic Filing attachment: schematics. 2. Block diagram submitted as Equipment Authorization Electronic Filing attachment:
blockdiagram. 3: Operational description submitted as Equipment Authorization Electronic Filing attachment: "operational description. The above exhibits contain Metrilog Data Services trade secrets and proprietary information that could be of benefit to our competitors regarding the design of our RTU. This material is not customarily available to the general public and we request that it be withheld from pub-
lic inspection. If you have any questions, please feel free to contact me at the address shown below. Sincerely, Britta Hubert n, Austria Tel.5+-43-1-8901236-0, Fax: +43-1-8901236-21 office@metrilog.com Metrilog Data Services GmbH Metrilog Data Services GmbH, Office Park 4 C/38, 1300 Wien-Flughafen, Osterreich Tel: +43-1-8901236-0, Faxc +43-1-8901 236-21, UID Nr. : ATU 61434406, info@metrilog.com Sparkasse Obersterreich, BIC: ASPKAT2L, IBAN: AT 32 2032 0250 0000 9042 Firmenbuch Nr: 254 978 v, Landesaericht Korneuburg; http://www.metrilog.com
1 | Cover Letter | Cover Letter(s) | 64.91 KiB | May 20 2022 |
Coverletter:
Metrilog Data Services GmbH wants to get FCC-Certification for the following product:
Remote Terminal Unit M717. The device contains the FCC certified module 2AJYU-8PYA007 and is otherwise an unintentional radiator. The unit will get the following FCC-ID: 2A6UM-M717D List of documents:
File label_and_placement.pdf
photos_external.pdf blockdiagramm.jpg test_report_small.pdf photos_setup.pdf M717_UserGuide.pdf photos_internal.pdf
M717_RevD_TechReference.pdf Thema Exhibit Label and placement Exhibit 01 Not needed Exhibit 02 Exhibit 03 External Photos
* Exhibit 04 Block Diagrams
* Exhibit 05 Schematic Diagrams Schematics.pdf Exhibit 06 Exhibit 07 Exhibit 08 Exhibit 09 Exhibit 10 Exhibit 11
* Exhibit 12 Operational Description Cover letter Request for confidentiality Testreport Test Set-up Photos User Manual Internal Photos Informations RF exposure Exhibit 13 This file M717_FCC_confidentiality_letter.pdf For the Exhibits marked with * Metrilog requested Long-Term Confidentiality according to 47 CFR 0.457 and 0.459 of the FCC rules because these are sensitive parts owned by this company and include much of Know-How or sensitive data, it will not be provided to the public. The labelling on some photos may be not the actual status. The correct labelling is shown on the label photo in Exhibit 1.
frequency | equipment class | purpose | ||
---|---|---|---|---|
1 | 2022-05-20 | JAB - Part 15 Class B Digital Device | Original Equipment |
app s | Applicant Information | |||||
---|---|---|---|---|---|---|
1 | Effective |
2022-05-20
|
||||
1 | Applicant's complete, legal business name |
Metrilog Data Services GmbH
|
||||
1 | FCC Registration Number (FRN) |
0032393670
|
||||
1 | Physical Address |
Office Park 4 C38
|
||||
1 |
Vienna, N/A
|
|||||
1 |
Austria
|
|||||
app s | TCB Information | |||||
1 | TCB Application Email Address |
g******@tuv.at
|
||||
1 | TCB Scope |
A1: Low Power Transmitters below 1 GHz (except Spread Spectrum), Unintentional Radiators, EAS (Part 11) & Consumer ISM devices
|
||||
app s | FCC ID | |||||
1 | Grantee Code |
2A6UM
|
||||
1 | Equipment Product Code |
M717D
|
||||
app s | Person at the applicant's address to receive grant or for contact | |||||
1 | Name |
B**** H****
|
||||
1 | Telephone Number |
+4369********
|
||||
1 | Fax Number |
+4318********
|
||||
1 |
b******@metrilog.com
|
|||||
app s | Technical Contact | |||||
n/a | ||||||
app s | Non Technical Contact | |||||
n/a | ||||||
app s | Confidentiality (long or short term) | |||||
1 | Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | Yes | ||||
1 | Long-Term Confidentiality Does this application include a request for confidentiality for any portion(s) of the data contained in this application pursuant to 47 CFR § 0.459 of the Commission Rules?: | No | ||||
if no date is supplied, the release date will be set to 45 calendar days past the date of grant. | ||||||
app s | Cognitive Radio & Software Defined Radio, Class, etc | |||||
1 | Is this application for software defined/cognitive radio authorization? | No | ||||
1 | Equipment Class | JAB - Part 15 Class B Digital Device | ||||
1 | Description of product as it is marketed: (NOTE: This text will appear below the equipment class on the grant) | Remote Terminal Unit M717 | ||||
1 | Related OET KnowledgeDataBase Inquiry: Is there a KDB inquiry associated with this application? | No | ||||
1 | Modular Equipment Type | Does not apply | ||||
1 | Purpose / Application is for | Original Equipment | ||||
1 | Composite Equipment: Is the equipment in this application a composite device subject to an additional equipment authorization? | No | ||||
1 | Related Equipment: Is the equipment in this application part of a system that operates with, or is marketed with, another device that requires an equipment authorization? | No | ||||
1 | Grant Comments | Contains FCC ID: 2AJYU-8PYA007 This device must be installed to provide a minimum separation distance of at least 20 cm from all persons and must not be co-located or operating in conjunction with any other antenna or transmitter, except in accordance with FCC multi-transmitter product procedures. | ||||
1 | Is there an equipment authorization waiver associated with this application? | No | ||||
1 | If there is an equipment authorization waiver associated with this application, has the associated waiver been approved and all information uploaded? | No | ||||
app s | Test Firm Name and Contact Information | |||||
1 | Firm Name |
TUV AUSTRIA SERVICES GMBH
|
||||
1 | Name |
W**** S******
|
||||
1 | Telephone Number |
43-1-********
|
||||
1 | Fax Number |
43-1-********
|
||||
1 |
e******@tuv.at
|
|||||
Equipment Specifications | |||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Line | Rule Parts | Grant Notes | Lower Frequency | Upper Frequency | Power Output | Tolerance | Emission Designator | Microprocessor Number | |||||||||||||||||||||||||||||||||
1 | 1 | 15B |
some individual PII (Personally Identifiable Information) available on the public forms may be redacted, original source may include additional details
This product uses the FCC Data API but is not endorsed or certified by the FCC