Introduction
One of the main benefits of Wamster is the possibility of using unreliable GPRS/UMTS networks as the communication channel. There are several system features which work cooperatively to make this feasible:
- PMU devices are equipped with non-volatile (flash) memory capable of storing 4 months of data locally while communication is offline.
- Device is powered with rechargeable batteries, allowing up to 4 hours of autonomy during power outages. Modem is also supplied through the device, allowing the communication to work during blackouts.
- Each PMU device always stores data locally at full resolution for the specified grid frequency (50 or 60 fps). However, transmitted frame resolution can be adjusted to meet user needs and current GPRS network conditions, as requested by the server or a user.
- If one of more frames is dropped during communication, Wamster communication protocol allows the server to negotiate resolution and request those frames from the device’s local memory. The same principle is used to fill missing data if the default reporting speed is lower.
- Full resolution frames are also automatically requested whenever an event is detected, in order to speed up the analysis process.
Communication cycle
Communication cycle starts with the device connecting to the configured TCP socket on the Wamster server.
On the top of the Wamster communication module sits the TCP/IP layer, which handles incoming connections from all PMU devices. Whenever a device is connected, it immediately transmits its settings and handshake information, including its ID, firmware version, selected grid frequency, current GPS location and various internal log messages. This data allows server to determine device status, prepare the processing pipeline, or discard the connection if needed.
During this connection phase, Wamster server queries the database about any missing (not received) synchrophasor frames for the last 24 hours (by default), and prepares data parsers for the specified protocol type and version. After several received frames (in order to determine actual network throughput), Wamster will request missing frames from the device at the resolution configured by the user for the specified device.
Whenever a connection is dropped, device will continue measuring and storing data locally. As soon as the connection is reestablished, server will request all frames that weren’t received during the network outage.
Adapting to network conditions
Wamster automatically adapts the default reporting speed for historical or real-time frames in three cases:
- Whenever an event is detected, Wamster requests the device to resend frames for the pre- and post-trigger time range at full resolution, and notifies the user about the event.
- User can compare full resolution measurements for two PMU devices through the web interface. Wamster will send a request to both devices to increase their reporting speed to 50/60 fps while the analysis is active.
- If network conditions don’t permit the device to transmit synchrophasors at the user configured transmit resolution for a longer period of time, Wamster will automatically gradually decrease real-time reporting speed until conditions improve or it reaches the minimum speed (1 fps). When network conditions improve, Wamster will again recollect all frames stored with lower resolution to meet the user specified speed.
For high-speed Ethernet connections, default reporting resolution can be set to nominal grid frequency (50 or 60 fps), in which case detailed synchrophasor data will be available immediately.
Remote firmware upgrade
Wamster communication protocol also allows device firmware to be upgraded remotely, over the GPRS network.
This is especially important for customers who want custom protocols added to their devices, as it allows central upgrade of all devices in the field, without the need for physical access to devices. It typically takes less than a minute to transmit the firmware over a GPRS connection and reinitialize the device.