AlphaMon Logs: Reading and Understanding Log Streams

The AlphaMon Platform generates various log messages to provide real-time insights into its operation and the status of connected devices. These logs are very useful for monitoring system health, diagnosing issues, and understanding the flow of data within the AlphaMon ecosystem.

Log messages originate from various sources, including LoRa wireless communication, local device operations (such as time synchronization via WiFi), and other internal processes. Understanding the format and content of these log messages is important for effectively using and troubleshooting the AlphaMon platform.

You can connect to and display an AlphaMon’s log messages using either a wired USB-C cable and suitable terminal emulation software or remotely over your WiFi LAN using UDP packet monitoring software such as UDP Monitor.

AlphaMon’s log messages follow this general format:

• Timestamp: The date and time the event occurred (in local time). Note: Timestamps are optional on the UDP Mobile port (4211).
• Context: The subsystem or module that generated the message (e.g., “TmZone,” “LoRaRx,” “MqttTx”). This indicates the general source of the message.
• Message: A description of the event, data, or error. The format of the message itself can vary depending on the context and may contain sub-formatting.

Log messages can be broadly categorized into several types, including Status Messages, Device Information and Data Messages (such as those related to Modbus registers). The following sections will detail the structure and interpretation of these different log message types.

Understanding Status Messages

Status messages provide real-time updates on the operational state of the AlphaMon platform. They indicate important events, successful connections, errors, and other relevant occurrences. These messages are useful for diagnosing issues, monitoring system health, and understanding the sequence of operations.

Status messages generally follow the same general format. Here are some examples of common status messages:

• Time Zone Synchronization:

25-02-15 14:55:38 TmZone: Found API local time offset: [11] (39600 secs)

This message indicates that the AlphaMon device has successfully determined the local time offset. Accurate timekeeping is essential for logging events correctly and ensuring data consistency.
The AlphaMon device uses an API (Application Programming Interface) to retrieve this information, from a network time server. The value in brackets [11] represents the time offset in hours, and the value in parentheses (39600 secs) is the offset in seconds.

In this example, the device’s local time is 11 hours ahead of UTC (Coordinated Universal Time). This message confirms that the time synchronization process was successful.

• LoRa CRC Error:

25-02-15 14:56:33 LoRaRx: CRC Verify Error Rx=[B2C:2:MAC:64E833676B2C:AFE25]

This message indicates a Cyclic Redundancy Check (CRC) error during LoRa communication. CRC is a method of error detection used to ensure data integrity. When a LoRa packet is received, the AlphaMon device calculates a CRC checksum based on the received data and compares it to the CRC checksum included in the packet.

If the two checksums don’t match, it indicates that the packet may have been corrupted during transmission. The message includes details about the received packet, which can be helpful for troubleshooting network issues. A high rate of CRC errors suggests potential problems with the LoRa network, such as interference, weak signal strength, or faulty hardware.

• MQTT Connection Status:

25-02-15 14:55:38 MqttTx: mqtt.solargy.com.au CONNECTED

This message confirms a successful connection to the MQTT (Message Queuing Telemetry Transport) broker at mqtt.solargy.com.au.

MQTT is a lightweight messaging protocol used by AlphaMon to publish data to a central server or subscribe to data from other devices. This message indicates that the AlphaMon device has successfully established a connection with the MQTT broker, enabling it to send and receive data. If this connection fails, the AlphaMon device will be unable to communicate with remote users of MQTT client apps logged into this server.

• MQTT Topic Paths:

25-02-15 14:55:38 MqttTx: Path_1 [Solargy:AlphaMon:Demo/]
25-02-15 14:55:38 MqttTx: Path_2 [Solargy:AlphaMon:Demo/demo_entity_1/]

These messages show the MQTT topic paths that the AlphaMon device is publishing or subscribing to. MQTT uses a topic-based system for message routing. Devices publish messages to specific topics, and other devices can subscribe to those topics to receive the messages. These log messages list the topic paths that the AlphaMon device is configured to use. They are essential for understanding the data flow within the MQTT system.

The paths are hierarchical, similar to file paths, and provide context for the published data. For example, Solargy:AlphaMon:Demo/ might be the base path for all data related to a specific AlphaMon demo system.

Decoding LoRa Received Data (Rx) Packets

AlphaMon uses LoRa wireless technology to receive data from various connected devices. The received data is encapsulated in LoRa packets, which are then logged by the AlphaMon device. Understanding the structure of these packets is essential for interpreting the received information.

A LoRa received data packet log entry typically consists of two lines: an Rx line representing the raw received packet and an Ex line showing the extracted or decoded information, as shown in the following examples.

25-02-15 14:57:22 LoRaRx: Rx=[6B2C:c:f:0:6C77] RSSI=-100.00dBm SNR=8.50dB
25-02-15 14:57:22 LoRaRx: Ex=[ID=AlphaESS, MAC=*6B2C, Idx=15, Addr=0x0021, Value=0, REG_GRID_METER_R_TOTAL_ACTIVE_POWER_1]

25-02-15 14:57:34 LoRaRx: Rx=[6B2C:2:IP:10.1.0.181:3567] RSSI=-102.00dBm SNR=7.50dB
25-02-15 14:57:34 LoRaRx: Ex=[ID=AlphaMon, MAC=*6B2C, IP=10.1.0.181]

25-02-15 14:57:36 LoRaRx: Rx=[6B2C:2:MAC:64E833676B2C:AFE2] RSSI=-102.00dBm SNR=7.75dB
25-02-15 14:57:36 LoRaRx: Ex=[ID=AlphaMon, MAC=64E833676B2C]

25-02-15 14:57:39 LoRaRx: Rx=[6B2C:3:SN:AL7011022090572:F5D1] RSSI=-101.00dBm SNR=8.75dB
25-02-15 14:57:39 LoRaRx: Ex=[ID=AlphaESS, MAC=*6B2C, SN=AL7011022090572]

Let’s break down the components:

• Rx=[...]: This line represents the raw received LoRa packet. The format varies depending on the packet type. Here’s a breakdown of the common elements:
  1. 6B2C (or similar): The first four characters represent the last four characters of the sending AlphaMon device’s MAC address. This is a partial identifier due to bandwidth constraints of LoRa transmissions.
  2. c, 2, 3 (or similar): This field represents the packet type, expressed in hexadecimal. It indicates the kind of data contained in the packet (e.g., Modbus register data, device information or status message).
  3. Variable Data: The remaining characters in the Rx line contain the actual data payload, which varies depending on the packet type. This might include register indexes, data values, IP addresses, serial numbers, or other information.
  4. CRC Checksum: The last 4 characters of the Rx line are the 16-bit CRC-16-CCITT checksum, used for data integrity verification.
• Ex=[...]: This line shows the extracted or decoded information. The format and content of this line depend on the packet type.
  1. ID=...: The identifier of the connected device or the AlphaMon device itself (e.g., AlphaESS, AlphaMon).
  2. MAC=...: The MAC address of the sending AlphaMon device. The way this is presented varies by packet type:
     • Only the last four characters (prefixed by an asterisk * as a wildcard) are available due to bandwidth restrictions.
     • In other packet types, such as those containing device information, the full MAC address may be included.
  3. Other Data: The Ex line will contain other extracted information relevant to the packet type. This can include IP addresses (IP=...), serial numbers (SN=...), register addresses (Addr=...), data values (Value=...), register names (REG_...), and other relevant information.

By examining both the Rx and Ex lines, you can gain a comprehensive understanding of the data transmitted over the LoRa network. The Rx line provides the raw packet data, while the Ex line presents the decoded and more user-friendly information. The variations in how the MAC address and other data are presented highlight the importance of understanding the different packet types.