Tunnel – Sending digital and analog input value telemetry by 2G/3G/4G according to an event (not periodically) using ultra low power modem. Sending to MQTT broker

Scenario details:

• Some digital and analog inputs need to be remotely monitored via GPRS
• MTX-65-ULP is powered by external batteries and remains in Low Power Mode (2 uA) until the level of digital inputs change (tamper)
• When there is a change in tamper digital input level, the modem wakes up and changes to normal operation mode to read the digital and analog inputs. Those levels are sent to a server using GPRS via a TCP/IP socket
• After the information has been sent, the modem goes back into ultra low power mode again 

Solution: MTX-Tunnel firmware + MTX-Java-IoT

Config.txt configuration file:

Configuration

Observations

GPRS_apn: movistar.es GPRS_login: MOVISTAR GPRS_password: MOVISTAR GPRS_DNS: 8.8.8.8 GPRS_timeout: 0 MTX_model: 199801454 MTX_mode: none ULP_enabled: on ULP_sleepMode: minutes ULP_minutesOff: 0 ULP_secondsOn: 60 MQTT_enabled: on MQTT_server: tcp://test.mosquitto.org:1883 MQTT_id: [IMEI] MQTT_attopic1: [IMEI]/AT1 MQTT_qos: 1 MQTT_keepalive: 300 MQTT_persistent: off DNS_enabled: on DNS_mode: mqtt DNS_mqttTopic: [IMEI]/dns DNS_extended: on DNS_period: 120

GPRS APN from your network operator GPRS Login GPRS Password Google DNS. Must be used if TCP_IP is set to DNS Connected data while ULP is awake MTX terminal modem model used We don’t use gateways Modem ULP service activated Modem will be awake Indefinitely asleep until tamper input changes Awake during 1 minutes MQTT service in the modem activated Broker IP/DNS, including port Identifier MTX-Tunnel subscribes to this topic for commands Service quality Keep alive MQTT connection (300 seconds) We don’t need persistence Sending status data activated MQTT sending mode Topic where status data will be sent Sending extended data (E/S, ADCs, etc.) Every 120 seconds data is sent

Details:

• The data string will have the following format:
  

  {„IMEI“:“354033091483894″,“TYPE“:“DNS“,“TS“:“2020-05-26T15:46:50Z“,“P“:““,“IP“:“95.126.81.105″,“CSQ“:12,“TECH“:“4g“,“VER“:“11.07″,“AUX“:““,“MOD“:“199802407″,“VCC“:12000,“CID“:“214;07;21E0;13B6D0A;405″,“IO0″:1,“IO1″:1,“IO2″:1,“IO3″:1,“IO4″:1,“IO5″:0,“IO6″:0,“IO7″:0,“IO8″:0,“AD0″:0,“ADM0″:“voltage“,“AD1″:0,“ADM1″:“voltage“,“POW“:1}

  
  Where
  IMEI: the unique identification number of the modem
  TYPE: JSON type (IOS in this case)
  TS: TimeStamp (modem time when the event happened)
  IP: modem IP address
  CSQ: modem coverage (0 … 31)
  TECH: technology used in that moment (2G/3G/4G)
  VER: MTX-Tunnel firmware version
  MOD: MTX model (field MTX_model)
  VCC: MTX supply voltage (in millivolts)
  IOx: digital input x value
  AD1: analog input 1 value
  AD2: analog input 2 value
  CO1: pulse counter 1 value
  CO2: pulse counter 2 value
  CO3: pulse counter 3 value
  CID: cell ID of the telephone station used
• The ULP_minutesOff parameter is the amount of time that MTX-Tunnel is in low power mode (sleep) starting just after the modems go back into low power mode
• You can finish the ULP session at any time (without waiting 2 minutes). To do that you can send the model (to the topic [IMEI]/AT1) the command AT^MTXTUNNEL=SETULPSECONDS,0
• Modem sends JSON witg time. There isn’t time synch, so the time received can be innacurate. Since data is sent in real time, it can take the time from its own data reception server