CasaDelGato Systems

From a posting by Lee Hart on the EVDL:

CANbus is a complete standard that specifies (in excruciating detail)
how the hardware and software all works. It's been used by the auto
companies in production vehicles for over 10 years. Since they are big
companies with thousands of engineers, it's become a very complex
standard. This makes it difficult to use unless you're willing to buy
the necessary development hardware, software, and learn how to use it.

Technically, CANbus is a derivitive of the RS-485 standard. Here's a rough descriptions:

Hardware:
- 2 wires (+data and -data)
- non-isolated; all devices connected to the same ground (i.e. a third common ground wire connecting them all is assumed)
- differential data; the voltage difference between the two wires carries the data.
a "1" is represented by the +Data wire being 0.3v to 5v more positive than the -Data wire
a "0" is represented by the -Data wire being 0.3v to 5v more negative than the +Data wire
- moderate noise immunity; better than RS-232 or USB, worse than EviBus
- relatively high operating current (20-60 ma)
- modest speed (typically 100 KHz to 1 MHz)
- moderate cost (a few dollars per node)
Software:
- master/slave setup: a central master requests data, and controls when each slave can respond
- binary data: requires computers to interpret messages
- interpreting the data packets is partly public (OBD-2) and partly proprietary secrets (unique to each car manufacturer)

> > I would just much rather use a simple, open data format than
> > purchase the official car manufacturer standards and try to make
> > sense of them.

This is where EvilBus (or I prefer EviBus) came in. I wanted something
that was cheaper, simpler, isolated, had higher noise immunity, and was
easier to use.

Hardware:
- 2 wires (+data and -data)
- isolated; uses optocouplers at all nodes. No common ground between nodes.
- differential data; the voltage difference between the two wires carries the data.
+Data wire has a 150 ohm pullup to + of a 5v to +15v supply; -Data wire has 150 ohm pulldown to - of this supply.
a "1" is represented by an open between the +Data and -Data wires.
a "0" is represented by shorting the +Data and -Data wires.
- high noise immunity; the best I could devise for the price. For example, it still works with the data wire bundled with cables from a 300v 2000a Zilla controller or PFC charger.
- low operating current (about 1 ma per node)
- low speed (9600 baud max)
- low cost (about $1 per node)
Software:
- peer-to-peer network; each node sends what it knows, and listens for what it needs.
- no central master; nodes work independently.
- ASCII human-readable data; can be interpreted without a computer
- open standard

Unfortunately, EviBus is an amateur effort, with no power to coerce
anyone to follow. As a result, every implementation has taken a
different approach, according to the implementors wishes. The hardware
layer is pretty much standard, but there are no standard software layers.

> > Each device has a manual describing the different packets that
> > device sends or receives and the exact meaning of the payload
> > bytes. In addition, the device includes a number of DIP switches
> > that define other bits of the packet identifier.

This is a great concept, but nobody wants to write documentation. So, I
take the view that the data format should be human readable ASCII, and
self-documenting. I.e. you should be able to read the data, and figure
out what it means even without a manual. One format we hashed out sends
messages like this:

B1=12.0v
B2=12.1v
B=10a

meaning "battery number 1 is at 12.0 volts, battery number 2 is at 12.1
volts, battery pack current is 10 amps," etc.