RE: Event triggered Sensor Nodes

Hi Chuck
Nice  to hear that your railway is doing well.  Your explanation is dead on.  

Colin,
There are a number of ways to identify each node on a CAN bus (or any party line network).  

1. Easiest and cheapest way is to just program a unique node ID into each node.  Where that goes wrong is when you move a few nodes around for service or you need to replace one because of failure.  Since each node counts the location of that node is very important.  Maintaining a method of programming a node ID two years later can be problematic.

2. I normally use the DS1822 one wire device that has both a unique serial # and a temperature sensor.  It requires only one pin on the processor.  Using that unique ID you can assign a node ID.  I used that approach on the 2010 rings.  A replacement light serial number was entered into the PC application and a messages was broadcast to all nodes from the master.  Each node looks at the data part of the message and verifies if the serial # matches.  If it does one other field in the data holds the new Node # used for normal communications.   So even if you accidentally set all 50 nodes to #78, you can change them back one at a time using the set node with serial # message.

3. A slightly more expensive method is to use something like a DB-25 instead of a DB-9 connector for your node.  Assign 8 of the pins to be the binary address of that DB-9.  The processor can read the 7 bits as a binary value directly or if you don't have enough pins use a parallel to serial TTL or CMOS device.  That requires three pins on the processor, clk , ld, and data.  You can of course use jumpers on the node itself or a dip switch but the cost is higher and accidental incorrect settings can be difficult to find. 

4. Alternatively one that I will try this summer uses two processor pins and is patterned after the GE-35 RGB Christmas Lights.  But for CAN it may be more expensive compared to the DS1822 due to cable costs.  It's a novel idea though 
  a)  Each node has, in addition to the CAN pins has an IN and OUT.  
  b) The OUT is Open Collector and on power up is logic high.  
  c) The IN on power up looks at the OUT from the unit in front of it.  
  d) So all nodes on the bus form a daisy chain of OUT to IN.  
  e) The System Master starts things off by setting its OUT to a logic low and then sends a SET NODE to #01. 
  f) All nodes get this message but only one node has its IN set low so it accepts the new node ID and then asserts its OUT low.
  g) The system master now sends another SET NODE to #02.  Although the first node in the string has it's IN low, it's also set the OUT low and has an initialized node # so it doesn't do anything.  
  h) The next node sees the IN low, hasn't been initialized yet so it's OUT is high so it saves the Node ID #02 and then sets its OUT low.
  i)  and so on for the number of nodes on the bus.  
  j) Because the cabling and physical location of the nodes is fixed you only need two extra connections on each connector and only one wire in the cable.
  k) If the master sets his OUT high and sends a RESET message all nodes pull their outputs high and then go silent waiting for a new node allocation.  
  l)  Now a replacement node is easy to incorporate into the network.

For my garden I will probably run an independent power supply to all the various path lights, and garden features.  So a CAN cable with 4 conductors can serve as GND, CAN_L, CAN_H and SIGNAL all nicely shielded.  Power to the nodes can come in on a separate connector either from an AC adaptor or a standard 12V/24V garden light bus.  Since the CAN GND signal doesn't carry power I won't see a large common mode voltage drop like we saw on the Olympic Rings when the lights went from Off to On.

John Dammeyer


From: [email protected] [mailto:[email protected]] On Behalf Of Chuck Hackett
Sent: April-02-15 7:06 PM
To: [email protected]
Subject: RE: [CANLIST] Event triggered Sensor Nodes

Hi Colin,

To my knowledge (see below) you MUST ensure that two different nodes NEVER send the same arbitration field.  If they happen to send at the same instant (most likely after the ‘quite’ period after a transmission by another node) they will not detect that they collided (no arbitration error) but will get a CRC error on their data area (i.e.: data differences will cause recessive bits to be destroyed by dominant bits from the other sender).  In this case the two (or more) CAN Controllers will keep trying to send their (different) messages and the controller will eventually report a message/bus transmit error.

Easiest way might be to embed a unique ‘node number’ in the arbitration field of the messages.

I only have experience with CAN in my application (ride-on railroad signal system, 1,000’s of feet of bus buried outdoors) using nodes that I designed and build but I’m sure someone here will correct/clarify the above if I’m wrong.

I have gained 90% of my ‘non-datasheet’ CAN info from this list and I am grateful to all who have helped me …

BTW: To all: My application is now running MUCH better after the guidance from the list.  My typical bus ‘failures’ are now only due to lightning strikes but that too has been beaten down to an acceptable level (the application can’t financially support “NASA” protection but I think I have found a good cost-benefit balance ☺).
 
Cheers,

Chuck Hackett
"Good judgment comes from experience, experience comes from bad judgment"
7.5" gauge Union Pacific Northern (4-8-4) 844 http://www.whitetrout.net/Chuck



From: [email protected] [mailto:[email protected]] On Behalf Of Colin Watson
Sent: Monday, January 19, 2015 7:31 PM
To: [email protected]
Subject: [CANLIST] Event triggered Sensor Nodes

Hi,

Upon reading the MCP2510 data sheet, I am not sure how to set up a data logging node to accept messages from about 100 
sensor nodes being animal feed bin weighers triggered by animals entering and leaving individual feed gates.

The feed fence nodes will transmit data to be read by a single node so I am considering setting the arbitration field of all the
fence nodes to a common I.D. say 999 and to set the filters in the data logging node to accept this I.D. as the entry to the
receiving buffer. The animal/feeder assignment can be part of the 8 byte data frame to ensure animal feed consumptions
are recorded correctly.

Alternatively I could build a transmit code individual to every sensor node but include a common bit segment to be selected
by the buffer mask.

The animal entry into feeders will of course be random and collisions will be rare because of the fast CAN bus baud rate when 
when compared to the randon animal behaviour - however collisions will happen and I expect a queue until all coincident
data has been passed.

If the transmit I.D.s all have the same I.D. will bus arbitration work. I think it should since the process simply  waits for a
quiet bus.

My question is:

WHAT ARE THE BEST OPTIONS FOR SETTING UP A MULTI-SENSOR NODE COMMUNICATION WITH A CENTRAL
DATA LOGGING NODE WHERE THE SYSTEM IS EVENT DRIVEN BY SENSOR DATA BECOMING AVAILABLE ?

My experience with CAN bus is nil but it seems a good option for this application.

An experienced comment would be immensely helpful.

Colin Watson.  Edinburgh



--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>