To CANBUS or not to CANBUS

GoogleGroups
1

Relatively new to small platforms and Linux in general. Have a new BeagleBone Black and am thinking about monitoring/logging sensors for future projects like monitoring solar heating, power consumption, state of devices in home, etc.

I read that CANBUS is a preferred method for multiple sensors on a long wire. Would you agree?

What does the CANBUS Cape offer beyond what the BBB can already do?

Should I skip the wire and learn to work with wireless sensors first? I imagine the cost is higher, but would that be a more robust and more easily managed network?

Someone on the forums implied that the future of BBB and Angstrom is in question. Should I do my learning on Ubuntu instead, as I’m just getting started?

Thanks for your time, patience and experience as I start imagining ways forward.

2

CAN bus is mostly for automotive applications. All contemporary cars have this bus and all inner units in a car interact through this bus

For industrial applications rs485 is the most widely used bus, but it may depend on your budget. Sometimes a radio connection is better than simple wiring. 1-wire is an option too, but this bus has significant limitation on the wires length

You can also find out details about ZigBee devices.

3

Zig Bee is the right choice.
Less power, No limitation on distance.
Visit www.sena.com for details

Deepak Bodhani

4

CAN bus need a transceiver to be connected to the physical layer. This device transform the CAN Rx / Tx signals of the BBB into CAN low and CAN High.
See for example : ISO 1050 - ISOLATED CAN TRANSCEIVER

The CAN cape contains this kind of component and an EEPROM that automatically set the right ports in the CAN mode.

You could build your own cape with a different transceiver (with 2 supplies: 5 or 12v for the CAN bus side and 3.3v for the BBB side) and configure yourself the BBB with the appropriate device tree: Enable CANBus on the BeagleBone Black

5

I had someone pitch me CAN is very deterministic
beyond auto I have seen it in medical and the Boeing DreamLIner(787) breaking system

6

Hi,

I’ve done a bit of work with CAN, mainly in automotive and Freescale. CAN is used heavily in automotive because it is deterministic, as you say. That is, you can come up with a priority scheme that guarantees that higher priority messages get sent out without collisions. You can read about the scheme on Wikipedia.

I’m not sure about the CAN controller on the BBB, but one of the problems with CAN implementations is large numbers of interrupts on busy networks. CAN is essentially a pub/sub network, where the receiver (at COMPILE time) registers for the set of messages it wants to receive. Those messages are then compiled into a set of filters that get loaded into the CAN controller so that the number of hardware interrupts are reduced. I’m not sure if the interrupt issue is still a problem, but there is still a lot of FUD around the industry about that.

The Linux SocketCAN driver (developed at VW) is, I think, a vastly superior approach that uses some of the existing Linux network stack, but it doesn’t use the hardware filtering capabilities of the hardware.

For home use, I would look at Insteon (wired/wireless), Z-Wave (wireless) or Zigbee (wireless). SmartHome is a good place to look at what’s out there. If you’re going to create your own sensors, RS-485, suggested above, is probably an easier implementation than CAN. Perhaps more information on your problem would help towards picking the right technologies.

7

Mind you, I haven’t done anything like this, but if I did I’d use zigbee. I read and enjoyed the book Building Wireless Sensor Networks (second edition) by Robert Faludi. It’s specifically about zigbee. He uses the XBee radios, from Digi International; they look reasonably priced. For the computer he uses an Arduino, but it’d probably be easy to translate the concepts to the BBB.

http://goo.gl/1ClUxI

8

Michael,

You should look into using RS485 instead of CAN. The programming model is easier since it is just a UART. You can develop using RS232 and just switch transreceivers to use RS485 if noise is too much.

I read that CANBUS is a preferred method for multiple sensors on a long wire. Would you agree?

It is preferred when there are multiple masters on bus and you want good collision resolution.

What does the CANBUS Cape offer beyond what the BBB can already do?

CANBUS cape provides an optoisolated transreceiver ISO1050 data sheet, product information and support | TI.com so you can directly connect to a CAN network.

Someone on the forums implied that the future of BBB and Angstrom is in question. Should I do my learning on Ubuntu instead, as I’m just getting started?

If you are not interested in BoneScript, just install Ubuntu in a virtual machine on your PC and start coding :slight_smile:

If you decide to stick with CAN you may want to look at https://gitorious.org/linux-can/linux-can-next/ for better support of hardware.

Regards,
Suraj

9

Michael, here some thoughts from my side.

You should look into using RS485 instead of CAN. The programming model is easier since it is just a UART. You can develop using RS232 and just switch transreceivers to use RS485 if noise is too much.

First of all, RS485 requires BUS arbitration in firm/software, and that’s why such networks nearly always conform to a master-slave-architecture. Years ago, I developed a collision-detection framework for RS485 using PIC’s and HC11’s, and it was pain in the end. Second, programming a CAN controller chip is as simple as doing the UART; nowadays you have code samples lying around for a mass of chips. (BTW: switching from RS232 to RS485 will lead you into troubles: RS485 is uni-, whereas RS232 is bi-directional)

I read that CANBUS is a preferred method for multiple sensors on a long wire. Would you agree?

It is preferred when there are multiple masters on bus and you want good collision resolution.

Right. CAN is a collision-avoidance system. This means, the chip cares about the right moment to put data onto the BUS WITHOUT destroying other frames, it re-tries, and in the end it gives you a ‘Sorry, not possible’ flag/interrupt to handle the problem from application level.

Years ago at some conveying company, we developed a distributed control system with Geode-SBC’s/Linux 2.4 at the front end and Motorola HC12’s at the field side. They were connected by CAN cables, and:

  1. they worked over distances of up to 200 m at bit rates of 250kb/s
  2. were real-time compliant
  3. robust & reliable
  4. kernel modules implementation took about 2 weeks (for one chip, an SJA1000)
  5. HC12 CAN firmware stack was done in 1 month
    Sure, you have to invest some brain energy in a BUS and protocol design:
  • what speed, what BUS length? See can_cabling - CAN Wiki
  • paket priorization and thus frame header usage
  • if in a stochastic, event driven network - which is what CAN is made for - what’s the worst case load, and
  • what is the real-time parameter one want’s to have guaranteed
    Currently, I’m working on a home-automation system with devices connected per CAN 2.0. The BUS speed is about 100kb/s, I’m having 4 devices that random-cyclically produce paket streams of up to 150 bytes of user data and one device that sucks those bits, does its PID - or what-ever - calculation and puts out the control values to the BUS. Besides that there are button boxes producing broadcast events and actor prints turning on/off lights from these broadcasts.

Once a day, the host computer (which will soon be a BBB, I hope :wink: polls the devices for communication statistics and keeps them on disk. Within the last two years, these statistics show about one average problem per 2 months, where most of them where one-time, corrected by the chip. A few others were based on surveillance and plugging in the right device at the wrong place - BUS physics are critical, but simple.

So, my ‘Yes to CAN’ :wink:
HTH
.M

10

Realizing this is a very old post but thought this group might have some current thoughts on CAN and the BBB and sources for more information. We are developing a system that must communicate with other agricultural equipment, and CAN is typically used on those products. So we need to get smart about CAN so we can communicate. We write our code in C on the BeagleBone Black Wireless and need to know what hardware we need to use CAN, libraries for C or other approaches, examples, and what connections we need to make. Any and all help will be greatly appreciated. Links to resources would help. Most of what I find about CAN is about the lower layers. We could use some links with examples of using it with C.

11

You will need a CAN cape to provide the CAN transceiver. The BBB has 2 CAN interfaces although the 2nd CAN interface shares pins with something. I can’t remember what exactly, might be HDMI.

Beyond that, the CAN interface appears as a network device, so you would use the normal C networking API to access the CAN. It is pretty easy to get going.

You will find plenty of examples. You can look at the source code for candump.

12

Thanks! I also found a little information in Molloy’s book on CANbus and will give that a try to learn more. Thanks!

13

As has been pointed out, you need a CAN transciever chip. I think the only available CAN cape nowadays is the BeagleBone Comms Cape.

However, you mentioned agricultural. That likely means ISOBUS, no? I think Wireshark can decode ISOBUS packets from a CAN interface.

However, I don’t know of any communication stack on Linux that could actively generate or receive ISOBUS packets (as opposed to Wireshark passively monitoring packets).

You probably want to generate a new thread on this rather than resurrecting something this old and non-specific.

1 Like