 $Id: mge-ellipse.txt,v 1.2 2002/02/15 23:11:01 phil Exp phil $


Desc: MGE Pulsar Ellipse protocol
File: mge-ellipse.txt
Date: 11 February 2002
Auth: Philippe Marzouk <philm@users.sourceforge.net>

MGE has made available the spec of their protocol so people interesting in
getting information on the protocol used should take a look at the protocol
information which are available at http://www.mgeups.com/techinfo/techdoc
or at at http://www.exploits.org/nut/library/protocols/mge/.



This document describes what I've found about the protocol used in MGE Pulsar
Ellipse, serial models.
This document was written by Philippe Marzouk <philm@users.sourceforge.net>

I Only tested with a MGE Pulsar Ellipse 800S.

All the information in this document was obtained by reverse engineering means
so it reflects only my limited understading of the protocol.

Comm parameter : 2400 8N1
RTS must be on, DTR must be off

The data indicated by the Linux software :
    - autonomy
    - battery charge level
    - UPS load
    - Output Voltage
    - On battery

To start communicating with the UPS, the computer sends 0x16 and waits for 
the UPS to respond by sending 0x16.

Messages are acknowledged by 0x06 (ACK) and not ackowledged by 0x15 (NACK).


Requests for status are 12 bytes long : 
  - byte 1 is the ACK for the previous command
  - byte 2 is the command type (0x81 for status)
  - byte 6 is the request type (0x01, 0x02, 0x11, 0x16)
  - The last byte is the CRC (I don't know how to calculate it yet )
  - The meaning of the other bytes is unknown.

Response have various lengths :
  - byte 1 is the ACK for the request
  - byte 2 is the type of response (0x84 for response to 0x81)
  - byte 3 is the length of the data excluding the CRC byte 
       (0x22 for 2, 0x33 for 3, 0x44 for 4 bytes, etc.)
  - The 4th byte indicate the request type this packet answers
  - The last byte is the CRC. 

1/ unknown command
06 81 88 A1 01 01 03 00 00 20 00 82
response:
06 84 22 01 00 01

2/ Utility power status
06 81 88 A1 01 02 03 00 20 00 81
Response packet : 
  if online :     06 84 33 02 23 00 21
  if on battery : 06 84 33 02 24 00 26
  if on line and low battery : 06 84 33 02 2B 00 29
  if on battery and low battery : 06 84 33 02 2C 00 2E
  unknown :	  06 84 33 02 6C 00 6E

3/ Battery status
06 81 88 A1 01 16 03 00 00 20 00 95
Example of response packet :
06 84 44 16 5A 08 06 42

byte 5 is the battery charge level : 0x5A = 90%
bytes 6-7 is the autonomy in seconds (in network order) :  0608 = 1544


4/ UPS Load Level
06 81 88 A1 01 0E 03 00 00 00 18 B5
Example of response packet :
06 84 33 0E E6 17 FF

byte 5 *may* be the output voltage : 0xE6 = 230
byte 6 is the load : 0x17 = 23%
The load does not seem very reliable, I got 5 on line and 20 on battery with 
the same equipment connected!
The load is not reported by the windows software but it is in Linux.

5/ Automatic restart of UPS
In default mode, the UPS does not restart automatically after a shutdown.
The dialog is a little different than status request :
send     : 06 01 88 21 09 11 03 00 00 04 00 3E
receive  : 06
send     : 81 44 11 0D 00 00 1C
receive  : 06
send     : 81 88 A1 01 11 03 00 00 20 00 92
receive  : 06 84 44 11 0C 00 00 1D

5/ Shutdown of UPS
envoi : 06 01 88 21 09 0F 03 00 00 04 00 20
reu  : 06
envoi : 81 44 0F 78 00 00 77
reu  : 06
envoi : 06 81 88 A1 01 0F 03 00 00 20 00 8C
reu  : 06 84 44 0F 77 00 00 78

In the second packet sent, byte 4 is 0x78 (120 in decimal), I think this is
the delay in seconds before the shutdown. It should be possible to change 
this value if the CRC could be calculated.
In the response from the UPS, byte 5 should be the delay before shutdown
(0x77 = 119).

