Well, it's RS485 for a start. It runs as 9600 baud, 8 bits, no parity, 1 stop bit, so pretty default. The last bit in each packet appears to be a checksum, and the first bit is always the device address being addressed.
| Filename | Description |
|---|---|
| galaxy 9600 3.sr | Sigrok capture, apply a uart filter at 10000 baud(lolsamplerate),8bits no parity. |
| GalaxyAddresses.png | Screenshot from Galaxy manual showing their RS485 "addresses" |
| dump.py | Python script to dump data from the RS485 bus, used in figuring out what happens. We used a MAX485 and FT232R together to get data. |
The Galaxy Addr is a weird one - it looks like the actual RS485 address, but truncated.
| RS485 Addr | Galaxy Addr | Function |
|---|---|---|
| 10 | "0" | Keypad (beeps if you address a door open command to "Max 0" addr?) |
| 11 | ??? | Appears to be the alarm panel itself/it's cpu/whatever. |
| 25 | ??? | ??? |
| 4b | "B" | Ethernet Module |
| 90 | MAX 0 | MAX4 Reader (not actually present but the panel thinks it is? maybe because keyprox keypad at addr10 also uses this?) |
| 91 | MAX 1 | MAX4 Reader |
The galaxy manual is not hugely useful regarding how the addresses lay out - they don't show the full address...
??!?Workshop?21:34 FRI 12 MAY?v
| Byte | Value | Function |
|---|---|---|
| 00 | 10 | RS485 Address of device being addressed, keypad at addr10 |
| 01 | 07 | BEL |
| 02 | 21 | ASCII ! |
| 03 | 17 | ETB End Transmission Block |
| 04 | 57 | W |
| 05 | 6f | o |
| 06 | 72 | r |
| 07 | 6b | k |
| 08 | 73 | s |
| 09 | 68 | h |
| 0a | 6f | o |
| 0b | 70 | p |
| 0c | 02 | STX Start of Text (Used here to go to new line?) |
| 0d | 32 | 2 |
| 0e | 31 | 1 |
| 0f | 3A | : |
| 10 | 33 | 3 |
| 11 | 34 | 4 |
| 12 | 20 | SPACE |
| 13 | 46 | F |
| 14 | 52 | R |
| 15 | 49 | I |
| 16 | 20 | SPACE |
| 17 | 31 | 1 |
| 18 | 32 | 2 |
| 19 | 20 | SPACE |
| 1a | 43 | M |
| 1b | 41 | A |
| 1c | 59 | Y |
| 1d | 07 | BEL |
| 1e | 76 | v (this appears to be a parity byte) |
Drawing three asterisks (2Ah) to the display:
1007b3172ab6 100721172a2a4e 1007b3172a2a2a0b
This is from addr10 (doesn't seem to send source addr tho), to addr10 (the panel).
| Byte | Value | Function |
|---|---|---|
| 00 | 11 | Message to RS485 Addr 11, the panel |
| 01 | f4 | ??? |
| 02 | 01 | Button "1" on keypad |
| 03 | b1 | Checksum |
11f401b1
If you press button 2 (02h), the checksum seems to increment by 1, so B2h. Perhaps a simple sum or something.
Also observed on the bus during a display update:
000000a0 -- -- -- -- -- -- -- 10 07 a1 17 20 45 4e 47 49 |-------....-ENGI|This one seems to be some kind of poll periodically sent to the panel from the reader. Not sure of it's function but it's quite frequently present on the bus.
| Byte | Value | Function |
|---|---|---|
| 00 | 11 | RS485 adress of the panel |
| 01 | ED | |
| 02 | FA | |
| 03 | 03 | ETX End of Text |
| 04 | E8 | |
| 05 | XX | A nonce, incremented on each poll |
| 06 | 00 | |
| 07 | XX | Checksum |
11edfa03e8XX00XX
| Byte | Value | Function |
|---|---|---|
| 00 | 11 | RS485 address of the panel, so data TO the panel |
| 01 | F4 | ?? door open command? |
| 02 | 01 | 0 is padding, 1 is first number of fob number |
| 03 | 23 | 2 and 3 from fob number |
| 04 | 45 | 4 and 5 from fob number |
| 05 | 67 | 6 and 7 from fob number |
| 06 | 89 | 8 and 9 from fob number |
| 07 | 3b | Likely a checksum |
11f401234567893b
11 F4 20 D0 - Request to open door
91 0c 03 81 cc - ACK?
91 0c 0c 02 - ACK go ahead and open.
(system set)
11 F4 30 E0 - Request to open door
91 0c 03 81 cc - ACK
Note the lack of ACK with go ahead returned now we're armed.
Further packets to request to open the door had the 3rd byte as 30 instead of 20 even after the system was disarmed. Not sure what's up with that either.