Alta Ethernet Gateway - Firmware Update Release Notes

V1.0.8.3
3/29/2022
Issues known or discovered with previous version (V1.0.8.0):

  • GATEWAY – Configuration or control commands from the server always take
    two to three heartbeats to be processed. It is expected that one heartbeat should
    be sufficient to transfer these commands.
  • HTTP – snmp.htm calculates if the Inbound Poll “start” and “end” IP ranges are
    valid. This calculation works inside a single byte subnet. However, a larger
    subnet can break the IP range math. The result is the page returns an “out of
    range” error and will not save.
  • ALTA Sensor OTA Suite – ALTA Over-the-Air customer sensor update tool
    permits the general updating of all sensor types on a network. However, during
    extended testing, it was discovered that the “update campaign” was not robust and
    could fail to update sensors. Additional execution of the OTA Suite is required
    to confirm everything updates successfully.

New features / Improvements (V1.0.8.3):

  • ALTA Sensor OTA Suite – Official customer launch supported by this firmware.
  • Enterprise Secure-OTA – Both gateway and sensor upgrade tools have been
    enhanced to support encrypted image transfers. New versions of iMonnit
    Enterprise will support upgrading gateways and sensors using standard gateway
    update tools and Sensor OTA Suite tools.
    Fixes / Resolutions (V1.0.8.3):
  • GATEWAY – All server commands are queued in one gateway heartbeat and the
    wireless device always collects configurations on the first attempt.
  • HTTP – snmp.htm Inbound Poll “start” and “end” IP range calculation now
    accounts for any size of IP ranges without error.
  • ALTA OTA Suite – Sensor update tools are now more robust and large networks
    can be updated in one campaign with high confidence of success.

V1.0.8.0
9/1/2021
Issues known or discovered with previous version (V1.0.7.2):

  • ETHERNET – PHY chip partial reset can occur when the gateway is near noise
    sources. Current code does not recover from this partial reset state and only a full
    power cycle is required to recover the gateway.
  • GATEWAY – Sensor configuration lockup potential identified when sensors are
    added to a gateway’s network and the gateway is already active. Also, small
    potential for the ALTA network to go offline until a Network List Refresh report
    is sent to the server (default: 12 hours).
  • MONNIT SERVER – Server application could stall in the presence of ETH-PHY
    faults. Additionally, after a successful self-recovery, the gateway may attempt to
    communicate with a zeroed gateway ID, or talk after 48 hours. All of these faults
    cause this interface to stall.

New features / Improvements (V1.0.8.0):

  • ALTA OTA Suite – ALTA Over-the-Air customer update tools, released in
    V1.0.7.2, have been improved to use “update campaign” feature allowing more
    than one sensor of the same type to be updated. Official release of the software
    tool suite to customers is still pending.
    Fixes / Resolutions (V1.0.8.0):
  • ETHERNET – PHY chip partial reset is now detected and the PHY fully reset.
    The recovery behavior now matches the standard the auto “cable out/in” recover
    behaviors and timing.
  • GATEWAY – Fixed Sensor configuration lockup potential. Added code to
    monitor the ALTA network status and to recover if the network becomes disabled
    during standard operation.
  • MONNIT SERVER – Server application code hardened to recover from ETHPHY faults. Additionally, fixed “zeroed gateway ID” issue, and added code to
    monitor the server communication link for stall or dropped messages and to
    recover the server connection when this occurs.

V1.0.7.1 - 1.0.7.2
12/23/2020
Issues known or discovered with previous version (V1.0.6.6):

  • ETHERNET – DHCP renew requests were found to not always include MAC
    Address. This causes some DHCP servers to reject the Renew Request.
  • DATA MANAGEMENT – Sensor data received by the gateway but not reported
    to the default server before the gateway shutdown or rebooted was not delivered
    to the default server.
  • DATA MANAGEMENT – Sensor command queue stops delivering commands
    to sensors after many configurations. A FLASH memory operation was missing
    from the queue’s initialization. A reform operation is required to reset the sensor
    command queue and restore sensor command operations.
  • HTTP LOCAL INTERFACE – Occasionally, the saving of configurations in this
    interface can erroneously save the current page parameters.
  • HTTP LOCAL INTERFACE – The “wsn.htm” page feature to download the
    wireless network list broke after 22 sensors on the network.
  • SNMP/MODBUS TCP – RSSI report was incorrectly formatted. The value
    presented ended up being 100-Value = True RSSI. Additionally, RSSI is difficult
    to correlate to customer needs in the field.

New features / Improvements:

  • HTTP – All web pages rearchitected and presented with a new look. Additionally, added floating point for form entries and added remove sensor operations to wsn.htm page. Additionally, changed the HTTP Timeout to modify permissions for read only status and not to disable the interface in general.
  • Enterprise Configurations – The EGW4 will now process a “Point” command by saving a copy of the configurations into a separate memory space. Now the “5-second Reset” on the gateway will restore the gateway to the Enterprise Configurations and not to the factory defaults. The “15-second Reset” is required to restore the gateway to factory defaults.
  • ALTA OTA Suite – New ALTA Over-the-Air customer update tools are now supported by this gateway. Official release of the software tool suite to customers is still pending.

Fixes / Resolutions:

  • ETHERNET – DHCP renew requests will always include the gateway’s MAC Address.
  • DATA MANAGEMENT – Sensor data is correctly recovered from memory post boot and will always be delivered to the default server. Additionally, on update to this version, any undelivered memory in the gateway will be recovered and sent to the default server.
  • DATA MANAGEMENT – Sensor command queue issues fixed.
  • HTTP LOCAL INTERFACE – All “save” options for pages have been tested for robust transaction completion.
  • HTTP LOCAL INTERFACE – The “wsn.htm” page option to download a network list will now work for a maximumly sized network (256 devices)
  • SNMP/MODBUS TCP – Signal Strength (0-100%) is now reported in place of RSSI.

V1.0.6.7

  • Memory Update: It was possible for some data messages not translated prior to a reboot to never be sent to the server. Fixed this.

  • HTTP pages updated

  • Adjusted page content

  • Added floating point support for Modbus timeout and Gateway Heartbeat.

V1.0.6.6
Issues known or discovered with previous version (V1.0.6.6):

  • ETHERNET – DHCP renew requests were found to not always include MAC Address. This causes some DHCP servers to reject the Renew Request. DATA MANAGEMENT – Sensor data received by the gateway but not reported to the default server before the gateway shutdown or rebooted was not delivered to the default server. DATA MANAGEMENT – Sensor command queue stops delivering commands to sensors after many configurations. A FLASH memory operation was missing from the queue’s initialization. A reform operation is required to reset the sensor command queue and restore sensor command operations.
  • HTTP LOCAL INTERFACE – Occasionally, the saving of configurations in this interface can erroneously save the current page parameters.
  • HTTP LOCAL INTERFACE – The “wsn.htm” page feature to download the wireless network list broke after 22 sensors on the network.
  • SNMP/MODBUS TCP – RSSI report was incorrectly formatted. The value presented ended up being 100-Value = True RSSI. Additionally, RSSI is difficult to correlate to customer needs in the field.

V1.0.6.5
5/20/2020
Issues known or discovered with previous version (V1.0.5.8):

  • SNMP – RSSI and BATTERY data from sensors persisted even when the rest of the sensor data became invalid.
  • GATEWAY – BSN fault management does not recover from BSN faults reliably. Situations observed where wireless network was offline for up to 12 hours.
  • GATEWAY – BSN start up code can erroneously signal a reform. This causes the gateway to lose its network list if not connected to iMonnit.
  • ETHERNET – if DHCP fails, there is no recovery method on that network. User cannot adjust settings to attempt fixing.
  • DATA MANAGEMENT – Modbus and SNMP interface could present logged data. Not always current data.
  • DATA MANAGEMENT – Sticky sensor command queue. The command queue occasionally holds on to sensor configuration commands. A Wireless Network Reform or Gateway Reset is required to un-stick the command queue.
  • HTTP – saving forms can cause extraneous characters to be saved with the configurations. This can cause unintended behaviors

New features / Improvements (V1.0.6.5):

  • DATA MANAGEMENT – All data is tagged with Gateway UTC time. Non-data messages did not have timestamp and support users use that data for diagnostic.
  • HTTP – web pages restricted and polished for full release
  • HTTP – find.xml now available for IP search tool. See support to request this.

Fixes / Resolutions (V1.0.6.5)

  • SNMP – RSSI and BATTERY data now cleared with other sensor data clear events.
  • GATEWAY – BSN fault management system upgraded to always restart wireless network within 20 seconds after fault.
  • GATEWAY – BSN start code fixed to only reform network when BSN does not know previous network settings. Network list will not randomly disappear now.
  • ETHERNET – Implemented APIPA (Auto IP) behaviors. Gateway now looks for DHCP for 30 seconds, then flash lights indicating that we are using 169.254.100.1 if it fails. The gateway will hold this IP for 2 minutes and then retry DHCP. If the HTTP pages are called by a browser, then the AutoIP settings will hold for 15 min. User can use the HTTP pages to configure gateway.
  • DATA MANAGEMENT – Modbus and SNMP interface are now only presented with current data. Future and historical messages ignored.
    • DATA MANAGEMENT – Sensor command queue repaired. Enhanced to support hundreds of sensor updates at one time.

V1.0.5.8
1/15/2020
Issues known or discovered with previous version (V1.0.5.0):

  • DNS – this module could lock up if asked to resolve a bad IP address
  • DNS – timeout found inaccurate. Could freeze iMonnit interactions until reboot
  • MODBUS – Socket timeout functionality and reconnect after TCP fault broken
  • SNMP – The SNMP code could illegally call DNS for “0.0.0.0”
  • SNMP – Scaler OIDs missing “x.0” notation.
  • SNMP – sysObjectID OID did not reference the correct OID.
  • SNMP – All sensor OIDs fields for all 256 sensors possible are only dynamically populated and will not be visible until a sensor is actively communicating. Some
  • SNMP tools require that OIDs always be present.

New features / Improvements (V1.0.5.8):

  • GW – Updated Bootloader to leave Network List (ID and Type and Nonvolatile configurations) through the update process. Now updates will leave the network list alone to better support ModbusTCP and SNMP.
  • Configuring all but heartbeat will cause the gateway to reboot.
  • SNMP/MODBUS – Added support for sensors types 53
  • Time servers are now not required to start the gateway (full offline support)

Fixes / Resolutions (V1.0.5.8):

  • DNS – If presented with a bad URL to resolve, the gateway will attempt and fail gracefully (System lock up is avoided)
  • DNS – Timeout code fixed
  • MODBUS – Socket timeout functionality and reconnect after TCP fault fixed
  • SNMP – The SNMP code only calls DNS when required.
  • SNMP – Scaler OIDs now report with correct “x.0” notation.
  • SNMP – sysObjectID OID addresses the correct OID.
  • SNMP – All sensor OIDs fields for all 256 sensors possible are now statically populated for “sensorInfoIntByIndexEntry” table. Other tables continue to be dynamic.

V1.0.5.6

  • SNMP interface modified to present Scaler values with a “x.0” interface. More complient with SNMP Specification. Also Fixed sysObjectID to pull the correct OID

V1.0.5.5

  • a TIME server (Monnit default server or SNTP) is no longer a requirement for the gateway. Default Time in this case is started at 1/1/2015 00:00:00

V1.0.5.4

  • SNMP interface requests DNS for “0.0.0.0” Stopped this
  • DNS Engine can handle/ignore a “0.0.0.0” or “255.255.255.255” call.
  • DNS fault and recovery fixed. Can get stuck doing DNS prior to now.

V1.0.5.3

  • When doing a STACK reset, it is required to also do a full reset

V1.0.5.2

  • MODBUS – Interface restored after remote link loss and timeout expiration.

V1.0.5.1
9/23/2019
Issues known or discovered with previous version (V1.0.4.3):

  • GW – Memory manager can irreparably fail after WSN empty packet.
  • WSN – data from wireless network can present an empty packet to the gateway and is handled like a full/valid packet. This rare occurrence can corrupt the internal memory storage.
  • MSVR – Startup message did not update the MSAPI SYNC counter after successful message. This causes the connecting server to always reject second message in dialog. If second message is data, this will drop data.
  • MSVR – Connection stability at higher than default HB can cause communications with server to become unpredictive. Gateway’s experience 20 to 120 min of offline time.
  • SNMP – issue identified (this version) where the SNMP interface would not work reliably.
  • MODBUS – If Ethernet Link goes down, then later is restored, the Modbus interface does not recover.
  • HTTP – If Ethernet Link goes down, then later is restored, the Modbus interface does not recover.

New features / Improvements (V1.0.5.0):

  • GW – Ultra Long Presses (15+ seconds) on the utility button will cause the gateway to clear all memory in an attempt to restore the device to factory conditions. - GW – Non-volatile configurations now persisted through gateway update. Future updates will not lose configurations after update.
  • GW – Non-volatile memory changes now detects what is changed and the gateway will perform the necessary level of reset required by the change.
  • GW – Added sensor type 129,132,132 to sensor translation table.
  • MSVR – Default server interface no longer forces the server to talk using encryption. The connecting server will dictate if encryption is required.
  • MSVR – Failure connections now proceed in 5sec, 5sec, 1min, 2min, 5min, 10min, 15min, then random 20-40 minutes.

New features / Improvements (V1.0.5.1):

  • GW – Added sensor type 53 to sensor translation table Fixes / Resolutions (V1.0.5.0):
  • GW – Memory manager patched for more robust recovery methods during fault situations bad memory sectors.
  • WSN – Empty packets are identified and rejected. - MSVR – Fixed start up message SYNC counter issue.
  • MSVR – Fixed connection stability errors. - MODBUS – Interface restored after direct link loss.
  • HTTP – Interface restored after direct link loss.

Fixes / Resolutions (V1.0.5.1):

  • MODBUS – Interface restored after remote link loss and timeout expiration. Known Issues and Workaround:
  • Some Enterprise servers send incorrect TCP packets back to this gateway type. This causes the gateway to never complete operational setup.
    -Workaround: None – additional testing ongoing.

V1.0.4.3
7/29/2019
Issues known or discovered with previous version (V1.0.3.3):

  • GW – HTTP interface content updated to use standard product name “Ethernet
    Gateway 4”.
  • MSVR - In iMine, it is common to lose gateway database context. This causes
    the gateway to lockup in security renegotiation.
  • MSVR - Security handshake contained test filter to force a bad key rejection
    recovery event. This causes extra effort required to get a valid key set up.
  • MSVR – On error, the message sent to server is dropped and rebuilt without
    updated protocol sequence number. If sensors are communication at high rate,
    the buffering would loose data appended to the message on fault.
  • WSN - ALTA sensor OTA would not work due to gateway-BSN timing
    parameters
  • WSN - Local Alert will not correctly download alarm messages.
  • WSN - On battery power, the wireless network data was dropped.
  • WSN - Network list downloads are not complete. Occasionally, sensors would
    not connect to the gateway without reform/reset operations by user/support.
  • WSN – Sensor data with bad time can happen and can cause sensor data to be
    dropped.

New features / Improvements: CCE – Platform expanding to support the following:

  • Internal nonvolatile memory upgrade
    o New structure to support up to 52,000 messages instead of 15,000
    messages currently supported.
  • Device Watchdog enabled in code
  • Added a reset feature after ten seconds of holding the button once boot completes
    Fixes / Resolutions:
  • GW – HTTP interface content updated to use standard product name “Ethernet
    Gateway 4”.
  • MSVR - Additional support information available to the iMonnit server backend
  • MSVR – Security keys processed once per parent message requirement and not
    every time the key is needed (1 second per key limits excess processing)
  • MSVR – Security key filter updated to not force a bad key recovery event
  • MSVR – Double buffered scheme implemented to ensure no data loss on error
  • WSN - ALTA OTA operational in platform
  • WSN - Local Alert code support functional
  • WSN – network functions correctly on battery backup
  • WSN – wireless mode timing and handshaking recoded to ensure correct network
    list management.
  • WSN – bad times on sensor data fixed if found to be incorrect
    Known Issues and Workaround:
  • iMonnit Server connection can stall if there a double urgent communication
    comes in. Sensor data is still stored and delivered after the stall is resolved).
    o Workaround: Set the “Force Transmit on Aware” option to off.
  • Some Enterprise servers send incorrect TCP packets back to this gateway type.
    This causes the gateway to never complete operational setup.
    o Workaround: None – additional testing ongoing.


×

Call today for live expert advice & save 10% on your first order!

 801.561.5555

Or enter your phone number or email and we'll contact you.