Home automation on Cat5e again: is this a reasonable multidrop protocol?

Previously I have asked about running I2C over CAN PHY over Cat5e cables for my home automation project. Now after a round of money saving and experimenting, it seem to me that abusing RS485 chip MAX1487 may be a cheaper idea than I2C-over-CAN. Now I need a protocol to allow the host device (with Ethernet) and satellite nodes talk with each other.

Environment

The environment is the same: Cat5e in very hostile alien crosstalk environment, cable already have RJ45 crimped on in TIA/EIA-568-B pinout, and budget is very tight. So is this a suitable pinout that carries both power and signal to the target device:

1. N/C
2. N/C
3. D+
4. +5V
5. +5V
6. D-
7. GND
8. GND

Also an extra constraint: all chips used here MUST be available in DIP package. Preferred MCU for me is ATtiny85 for the satellite nodes and ATmega328P for the node with Ethernet access.

Physical layer

And since all devices in the system have some kind of MCU in it, I can make the bus talk peer to peer. However I do need to avoid collision. Will this physical protocol and collision avoidance scheme work:

1. Talk using RS485 physical layer chip MAX1487 at UART baud rate 9600bps and 8/N/1.
2. Resistive bias/termination network makes the line float at 1. Drive the bus only when sending 0 (since MAX1487 can tri-state its drivers.)
3. Talk when the bus is idle, a.k.a read as 1, for at least 5 bit of time.
4. Read every sent bit back immediately after transmitting, as well as before transmitting the next bit. Whenever a mismatch is found, abort transmission and back off for a pseudo-random amount of time before retransmitting.
5. First transmission of every node that just come online have to be delayed use the same pseudorandom backoff time as collision backoff.

Talk here means drive the bus. I chose the MAX1487 chip that can have its transmitter turned off when not used. Normal bias network:

simulate this circuit – Schematic created using CircuitLab

And since it is multidrop, some kind of addressing have to be used, which leads to this framed protocol:

Frame format (using C structure syntax):

struct frame {
uint16_t magic;          // = 0x55aa
uint16_t checksum;       // CRC16 of entire frame before this frame
}


Source and target addresses are hard coded into the chip, either during programming, or use some chip-specific value during manufacturing like the AVR's RC calibration value. Target address 0xffff means broadcasted frame.

Questions

1. Will this protocol be good enough as a home automation controlling protocol?
2. Will this protocol be able to be extended into carrying IPv4 or IPv6?
• Your edit still doesn't make clear that what you're planning on doing - I think - is to use "driven" as 1 and "idle" as 0, which isn't really RS485. What was wrong with CAN PHY, which is specifically designed for collision detection? – Nick Johnson Apr 26 '15 at 19:00
• @NickJohnson I think the bias network is very clear - when the line is idle it reads 1, and since MAX1487 can have its driver turned off only 0 is sent by driving the line (and a floating line means 1) CAN PHY chips can be a bit expensive here (US$1/each, but MAX1487 costs US$0.05/each) – Maxthon Chan Apr 26 '15 at 19:03
• The bias network is clear, yes, but RS485 drives both high and low, not just low; see en.wikipedia.org/wiki/RS-485#Waveform_example for an example. What you're proposing is not RS485, it's a variant. – Nick Johnson Apr 26 '15 at 19:18
• I2C allows multipoint in part because there is one master which addresses each slave. You could do a similar thing with the MAX1487. Have your master send out a packet on the bus addressing a particular slave, giving it permission to start broadcasting. Then as soon as it is finished it must stop sending anything and switch back into receive mode. That way you can never have any contention as long as every slave has a unique address. The master can poll each device in a loop. If the slave has nothing to say it can send a NOP packet or something. – Tom Carpenter Apr 26 '15 at 19:19
• @NickJohnson I just edited the post to make it clear that I am not exactly using RS485, but abusing a RS485 chip into talking like CAN. What I am doing is to make MCU's talk peer to peer over one twist pair of Cat5e under harsh alien crosstalk. – Maxthon Chan Apr 26 '15 at 19:20

• I have considered ethernet but W5100 is too expensive while ENC28J60 does not work well with ATtiny85 which is a real small MCU. In my protocol "talk" means drive the bus - the drive chip I chose, MAX1487, can have its driver turned off. By default, D+ is pulled high and D- pulled low, with 100Ω impedance across lines. – Maxthon Chan Apr 26 '15 at 18:51
• Not ATTiny in general, ATtiny85 in particular. It is just too small to drive ENC28J60 which needs 4 I/O lines (and all ATtiny85 have is 5) I have also edited my question to make it clear that all chips used must be in DIP packages and obviously ENC28J60 is not. – Maxthon Chan Apr 26 '15 at 18:56