Shop OBEX P1 Docs P2 Docs Learn Events
CANBus, RS485, Ethernet? — Parallax Forums

CANBus, RS485, Ethernet?

James NewmanJames Newman Posts: 133
edited 2010-07-18 21:39 in Propeller 1
I think I've made a post about this before... but I'm still working on it.

I've wanted to do alot of home automation for a while. I'd like to have several props doing things here and there around the house, and have them all able to communicate. Preferably to each other individually or broadcast. I also plan on having the computer communicate to them. The ideal solution would be ethernet, because I could use network switches and hubs, while not running too many extra wires through the walls. This also makes communication with the pc easier, if I can just send udp/tcp packets directly to the props.

So my question is what would be easiest to get off the ground as far as available objects for the prop? What would be most cost effective? Is the price to get ethernet going on the prop so much that it might be cheaper if I had just a few ethernet props that relay messages to non-ethernet props around them via serial? Are there any non-prop solutions that would be cheaper as far as the networking?

I was hoping 'Unicom' would be finished soon. Prebuilt communications objects is a plus for me, as I would really like to just get to the implementation.

So, help me out guys.
Thanks,
James

Comments

  • T ChapT Chap Posts: 4,223
    edited 2010-07-18 02:01
    RS485 is very simple and cheap to implement, many chips allow 127 devices and a master on a pair and you can get long wire runs with it as well with cheap cable. Set each Prop with its own ID, then set up your protocol for addressing any or all Props from the master.

    Here is a protocol I use for overseeing a number of Prop based devices. The protocol is much larger than what is posted but this should give you the idea. I have not posted an object for this, as my system is proprietary to a particular product, but the basics I could show you at some point if you wanted.

    A packet is comprised of the following components:

    • 1F: This preamble is present at the beginning of all packets. This allows a slave node to recognize the beginning of a new packet. As the name suggests, the value is 0x1F.
    • SRC: This is the ID of the node sending the packet.
    • DEST: This is the ID of the node to which the packet is addressed.
    • LEN: This is the length field of the packet. Its value is the combined length of the OP/ACK and DATA fields. LEN is one byte and can have values from 0x00 to 0xFF.
    • OP/ACK: This field is used for the OP (Operator) code for packets sent from the master to the slave, and for the ACK (Acknowledge) code for packets sent from the slave to the master.
    • DATA: If data is to be sent, it done is via the DATA field of the packet. The DATA field can contain 0 to 254 bytes. If any portions of the DATA are multi-byte values (e.g. UInt16 numbers), they are sent in little endian byte order.
    • CHKSUM: The last field of the packet contains the check sum. The check sum is calculated by adding the bytes of all the fields (from 1F to DATA), keeping the lower 8 bits of the sum, and inverting them.

    Example 1: The following example, the master sends an OP_PING command to the slave with ID 0x2F, and the slave responds with and ACK_SUCCESS code. The packet bytes are shown in hexadecimal format:

    1F 00 2F 01 00 4E
    • SRC: 0x00 (master)
    • DEST: 0x2F (Slave ID 0x2F)
    • LEN: 0x01 (1 Byte)
    • OP: 0x00 (1: ping)
    • CHKSUM: 0x4F

    Response sent by slave: 1F 2F 00 01 FF 4F
    • SRC: 0x2F (Slave ID 0x2F)
    • DEST: 0x00 (Master)
    • LEN: 0x01 (1 Byte)
    • ACK: 0xFF (255: PING)
    • CHKSUM: 0x4E
    484 x 110 - 11K
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2010-07-18 03:36
    I'm working on a similar project.

    RS232 is great for A to B but when you want 10 nodes, you need a hub and these are rare nowadays (read - expensive. Though of course do-able with a propeller if you wanted to!)

    Single wire with a single pull down resistor (10k) and nodes connected by 914 diodes is a cheap and cheerful solution used by many in the Picaxe community.

    RS485 is a more formal implementation of the single wire solution. Like the single wire solution, characters echo back to the sender (unless you go for a 4 wire RS485 solution, or RS232).

    If your house is already cabled with cat5, you could use the 4 unused wires in the cat 5 cable (ethernet only uses 4 of the 8)

    Or you can go for wireless - and after many experiments with many modules, I have settled on these cgi.ebay.com/2xWireless-RF-Transceiver-431-478MHz-GFSK-Data-Transfer_W0QQitemZ380244647229QQcategoryZ4660QQcmdZViewItemQQ_trksidZp4340.m263QQ_trkparmsZalgo%3DSIC%26its%3DI%252BC%26itu%3DUCI%252BIA%252BUA%252BFICS%252BUFI%252BDDSIC%26otn%3D20%26pmod%3D350373470669%26ps%3D63%26clkid%3D7045555477243540450

    They are a true drop in replacement for a RS232 link.

    Like T Chap, I'm using packets - and due to the nature of packets the protocols end up rather similar, viz:

    start byte = ascii 02 'start of text'
    number of bytes = 1 byte
    source = 4 bytes (eg 192.168.0.1 type of format)
    destination = 4 bytes
    packet number = 2 bytes (either a random number or incremented for each new packet)
    packet type = 1 byte (eg data, or Ping, or Who etc)
    data = up to 131 bytes (could go up to 255-15=240, but 131 is an xmodem packet size)
    checksum = 1 byte
    end byte = ascii 03 'end of text'


    This sort of thing can end up quite complicated. I started with a picaxe with 256 bytes of memory, and it has kind of grown to a MP/M emulation running on a propeller.

    It depends a bit on what you want to do. If you want to just turn things on and off it can be done with code mainly on the obex - eg serial drivers.

    I'm building a mainly RS485 network but I want to hybridise it with radio for the nodes that are more remote.

    Debugging this sort of thing can be complicated - attached is a screen shot showing all the packetised data going back and forth to a propeller board. One advantage of MP/M is you can have an intelligent conversation with a board - ask it what files it has, send new files, send new programs, run them, update the software via the network itself. Possibly more convenient than reprogramming 20 propeller chips if you decide down the track to change something.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.smarthome.viviti.com/propeller
    1024 x 768 - 188K
  • T ChapT Chap Posts: 4,223
    edited 2010-07-18 04:15
    Somebody said...
    Debugging this sort of thing can be complicated - attached is a screen shot showing all the packetised data going back and forth to a propeller board. One advantage of MP/M is you can have an intelligent conversation with a board - ask it what files it has, send new files, send new programs, run them, update the software via the network itself. Possibly more convenient than reprogramming 20 propeller chips if you decide down the track to change something.

    Exactly. Update the RAM or EEPROM on any number of Props with the single push of a button.

    Running to each Prop with a laptop to update it's program would get old fast. Set up an OPcode for data transfer of the .eeprom file, send it in chunks
    and overwrite the old.
  • James NewmanJames Newman Posts: 133
    edited 2010-07-18 04:34
    Ahh yes, didn't think of reprogramming, but I definitely do need to be able to reprogram the props via the network.

    Looking into the rs485 atm. Knew it was a bus type serial thing, but never looked it up.

    Woah! what is that program you've got going there? It looks configurable...
  • waltcwaltc Posts: 158
    edited 2010-07-18 05:23
    Home automation has been done, google X-10.

    If you want to roll your own Cyrpress has its own line of power line communication IC's.
    They have a whole line of IC's for this. CY8CPLC10, CY8CPLC20, CY8CLED16P01.

    Circuit Cellar Ink's current July issue covers both BTW.
  • Bill HenningBill Henning Posts: 6,445
    edited 2010-07-18 14:40
    For my products, I've standardized on RS485.

    For other people's products and projects ... <grin> ... I will be sellling 485Plug - a nice small board, with easy daisy chaining, that only requires two propeller pins, +3.3V and GND [noparse]:)[/noparse]

    It happens to perfectly fit the HCOMM connector on my boards (basically, propplug+3.3v on the far end from GND) and provides either RJ45 connectors or three wire screw terminals.

    I should have them tested by the end of this week coming up - I was distracted from my products by a large new consulting project.
    James Newman said...
    I think I've made a post about this before... but I'm still working on it.

    I've wanted to do alot of home automation for a while. I'd like to have several props doing things here and there around the house, and have them all able to communicate. Preferably to each other individually or broadcast. I also plan on having the computer communicate to them. The ideal solution would be ethernet, because I could use network switches and hubs, while not running too many extra wires through the walls. This also makes communication with the pc easier, if I can just send udp/tcp packets directly to the props.

    So my question is what would be easiest to get off the ground as far as available objects for the prop? What would be most cost effective? Is the price to get ethernet going on the prop so much that it might be cheaper if I had just a few ethernet props that relay messages to non-ethernet props around them via serial? Are there any non-prop solutions that would be cheaper as far as the networking?

    I was hoping 'Unicom' would be finished soon. Prebuilt communications objects is a plus for me, as I would really like to just get to the implementation.

    So, help me out guys.
    Thanks,
    James
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
    My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
    and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
    Las - Large model assembler Largos - upcoming nano operating system
  • James NewmanJames Newman Posts: 133
    edited 2010-07-18 21:39
    Thanks,
    The LTC1487CN8 looks like a nice fit.

    The chip is cheap, and has quite a few nice features. I particularly like the hot-swap idea, and the high number of nodes.

    Just out of curiosity though, how well would strait prop pins for transmitting, and maybe an opamp dif amp for receiving work for this? Seems like the main factor to the amount of nodes is their load. WIth the props super high impedance, how many could we get on a line? What do you all think? Ofcourse the opamps with resistors aren't that much cheaper than the LTC1487CN8...

    Edit: Ohh, and are you all using the standard obex serial objects?

    Post Edited (James Newman) : 7/18/2010 9:47:44 PM GMT
Sign In or Register to comment.