ELK's RS-485 bus measures 13.2 volts for the power with my multimeter. From what I can gather, RS-485 has both full and half duplex modes. ELK uses half duplex, if they were using full duplex, there would be two more wires. The converter I have should support both half and full duplex operation. A full duplex only interface can be made to work with a half duplex one by bridging the T+ and R+ together, and doing the same for the negatives. However, you need to find a way to turn off echo on the device or it will echo commands back onto the bus, potentially causing a storm of messages that takes it down. Being that my device has labels for just A and B, it should be a dual mode converter.
I have an idea that would require me to talk/interact directly on the RS-485 data bus, so this is why I'm trying to get it working. An XSP won't work for what I want to do.
For the device you are using (without digging into the manual):
- You shouldn't need the Gnd/+12, only the A/B since it is a differential signal;
- Drivers probably need to be loaded to set it into 485 mode others the transmit lines are enabled, which will kill the bus.
If you want this converted to 232, just get the Elk MB485 and your all set (yes, they sell the adapter if you look closely)
Some input on what you are digging into ...
I did a lot of reverse engineering about 2 years ago using an Ethernut v2 development board because it needs true 9-bit data words to work. Most microcontrollers support 9-bit with a special interrupt tied to the 9th bit because it is used for addressing. Just using a PC, you need to set it for 8 bit, space parity and look for parity errors. Generating them is hard because of character timing vs parity shifting combined with some strict timing on the bus.
I got to the point that:
- Full ASCII dump of packet hex data, both Elk transmitted and responses (identified);
- Discoverable on the network (it responded to the discovery and poll messages) and could represent multiple modules;
- Decoded discovery, poll, time, relay, lighting, tstat.
- Decoded firmware download
- Respond to module-global poll with "have data" and the module-device poll with the data
Stopped just before creating a real interface for ALC with custom mapping since ALC started to go away. I have a "c" header file with comments, an example:
Code:
typedef struct {
unsigned char module;
unsigned char address;
unsigned char command;
} ELK_COMM_HEADER;
/**
* Comm Format ef - Set Outputs
*
* Type Panel Request, Broadcast
* Command ef
* Module 00 (All)
* Address 00 (All)
*
* Length 11
*
* Response/Notify: No
*
* 00 00 ef 01 02 00 02 00 6f 60 a5
* 00 00 ef 01 00 00 02 00 82 08 a5
*
**/
typedef struct {
ELK_COMM_HEADER hdr;
unsigned char baseoutput; // Base output # for command
// 1-based, multiples of 16
unsigned char status_hi; // Status of 9..15 (bits, from baseoutput)
unsigned char status_lo; // Status of 0..7 (bits, from baseoutput)
unsigned char mask_hi; // Status change mask of 9..15
unsigned char mask_lo; // Status change mask of 0..7
unsigned short cksum;
unsigned short a5;
} ELK_COMM_FMT_EF_REQ;
On this message, the module and a5 will have the 9th bit set so you have interrupts at both address and end-of-packet.
I want to get this Linux-based because there is much more detail within this bus than the 232 bus (and you know if it is a command or status!) but not sure I can because of timing and the 9th bit issues.
Drop me a line directly if you would like what I have as a starting point. The code is not anywhere near as clean as I like it, but this is an in-progress reverse engineering project that has been hacked at quite a few times as I learned things.
Jay
