In the past, electronic devices in vehicles are connected via point to point wiring systems. Automotive manufacturers started using more and more electronics in vehicle, which resulted in bulky wire harnesses that were heavier and expensive too. Then they introduced a specialized internal communication network called vehicle bus that interconnects electronic devices inside a vehicle. Vehicle bus reduced the wiring cost, weight and complexity.

At present there are several types of network types and protocols used in vehicles by various manufacturers. Most common vehicle bus protocols includes,

  1. CAN
  2. LIN
  3. FlexRay
  4. MOST
  5. DC-BUS
  6. IEBUS
  7. J1850
  8. ISO 9141-1/-2
  9. D2B – Domestic Digital Bus
  10. VAN

Among the various bus protocols, CAN emerged as the standard in-vehicle network and it became the international standard known as ISO 11898. Bosch originally developed the Controlled Area Network (CAN) and it has been adopted by the automotive industry. Several higher level protocols have been standardized on CAN such as CANopen and DeviceNet which are commonly used for industrial communications. CAN is also adopted specifically for classes of vehicles such as J1939 for commercial vehicles and ISO11783 for agricultural vehicles.

In this blog, we will describe in detail about the CAN protocol as an in-vehicle network.

CAN Bus – Basics

CAN bus is an inexpensive, robust vehicle bus standard designed for multiple CAN device communications with one another without a host computer. CAN is also called as multi-master serial bus and the CAN devices on bus are referred to as nodes. Two or more nodes are required on the CAN network to communicate. All nodes are connected to each other via a two wire bus (CAN H and CAN L) and the wires are 120ohms nominal twisted pairs. Termination resistor commonly 120 ohms is must in each node in order to suppress the reflections as well as return the bus to its recessive or idle state.

Following is the block diagram of the CAN bus architecture,

CAN bus architecture

Architecture of CAN bus

Each node in the CAN bus requires the following

  1. Transceiver – It converts the data from the CAN controller to CAN bus levels and also converts the data from CAN bus levels to suitable level that the CAN controller uses.
  2. CAN controller – They are often an integral part of the microcontroller that handles framing, CRC etc.
  3. Microcontroller – It decides what the received messages mean and what messages it wants to transmit.

The transceiver drives or detects the dominant and recessive bits by the voltage difference between the CAN H and CAN L lines. The nominal dominant differential voltage is between 1.5V to 3V and recessive differential voltage is always 0V. CAN transceiver actively drives to the logical 0 (dominant bits) voltage level and the logical 1 (recessive bits) are passively returned to 0V by the termination resistor.  The idle state will always be in the recessive level (logical 1).

Individually, CAN H will always be driven towards supply voltage (VCC) and the CAN L towards 0V when transmitting a dominant (0). But in practical case, supply voltage (VCC) or 0V cannot be reached due to transceiver’s internal diode drop. CAN H/L will not be driven when transmitting a recessive (1) where the voltage will be maintained at VCC/2.

The following figure depicts the block diagram and real time capture of the CAN signals.

Voltage level of CAN bus lines

CAN Bus – Voltage Levels


Capture of CAN bus signals using DSO

Real time capture of CAN bus signals

CAN Physical Layers – Types

CAN has different physical layers which classifies the certain aspects of the CAN network such as signaling scheme, cable impedance, maximum data rates, electrical levels, etc. Following are the most commonly used physical layers,

1. High Speed CAN

High speed CAN is implemented with two wires and allows communication at data rate up to 1Mbits/s. It is also named as ISO 11898-2. Antilock brake system, engine control modules, emission systems uses high speed CAN.


CAN with Flexible Data rate is the next generation of high speed CAN communication with improved standards for higher data rates. CAN FD overcome the bandwidth limitation problems by allowing data rates higher than 1Mbits/s while also increasing the support of payloads up to 64 bytes in a single message.

3. Low speed/fault-tolerant CAN

Low speed/fault tolerant CAN networks are also implemented with two wires and can communicate at a data rate of up to 125Kbits/s with fault tolerant capabilities. They are also named as ISO 11898-3 and found in devices where wires that have to pass through the doors of the vehicle which have light stress that is inherent to opening and closing a door.

4. Single wire CAN

Single wire CAN interface have lower data rate up to 33.3Kbits/s and also named as SAE-J2411. The devices that do not require high performance like seat and mirror adjuster use Single wire CAN interface.

Transceivers are available for each type of CAN physical layer and it is one of the important criteria while choosing the transceiver. Many semiconductor manufacturers provide CAN transceivers including NXP semiconductors, Texas instruments, STMicroelectronics, Maxim Integrated, Infineon Technologies and Linear Technology.

Apart from generic CAN transceivers, there are special purpose transceivers such as galvanically isolated transceivers that are used for providing the isolated interface between a CAN protocol controller and the CAN bus. For galvanic isolated design, there is a need for isolated power supply and hence the design becomes more complex and costlier.

Transceivers with option for direct interface with the microcontroller are also available which reduces the requirement of external buffer ICs for voltage compatibility.

CAN terminologies

Following are some CAN bus terminologies that are useful to understand how CAN bus communication works. 

1. CAN Frame and fields descriptions

Devices in CAN network send data in packets called frames. Following image depicts frame format,

CAN Protocol frame format

Frame Format of CAN protocol

SoF – Start of Frame bit – indicates the beginning of a message with a dominant (logic 0) bit

Arbitration ID – identifies the message and indicates the message’s priority. Frames come in two formats — standard, which use an 11-bit arbitration ID, and extended, which uses a 29-bit arbitration ID

IDE – Identifier Extension bit – This bit allows differentiation between standard and extended frames

RTR – Remote Transmission Request bit – This bit is used to differentiate a remote frame from a data frame. A logic 0 (dominant bit) indicates a data frame. A logic 1 (recessive bit) indicates a remote frame

DLC – Data length code – It indicates the number of bytes the data field contains

Data Field – contains 0 to 8 bytes of data and up to 64 bytes of data for CAN-FD (Flexible Data rate)

CRC – Cyclic Redundancy Check – The CRC field is used for error detection. It contains 15-bit cyclic redundancy check code and a recessive delimiter bit.

ACK – Acknowledgement slot – any CAN controller that correctly receives the message sends an ACK bit at the end of the message. The transmitting node checks for the presence of the ACK bit on the bus and reattempts transmission if no acknowledge is detected

2. Bus Arbitration

Arbitration is the process in which two or more CAN controller agrees on who is to use the bus. It is of very important for the really available bandwidth for data transmission and this is the base for CAN bus communication. Arbitration process is performed over the arbitration ID.

3. Bit stuffing

Bit stuffing is a practice used to guarantee enough edges in the NRZ (Non-Return to Zero) bit stream to maintain synchronization. After five identical and consecutive bit levels have been transmitted, the transmitter will automatically inject (stuff) a bit of the opposite polarity into the bit stream. Receivers of the message will automatically delete (destuff) such bits. If any node detects six consecutive bits of the same level, a stuff error will be flagged.

How CAN communication works?

As mentioned early, CAN is a Peer-to-Peer network in which there is no master that controls the transmission between nodes. When any CAN node is ready to transmit data, it should undergo a process called message arbitration. In this process, CAN node will check to see if the bus is idle and starts the transmission once it is idle. This will also trigger other CAN nodes in the bus and hence results in two or more nodes starting a message at a same time which results in a conflict. The conflict is resolved in the following methods,

  1. The transmitting node monitors the bus while they are sending data
  2. If any node detects a dominant level (logical 0) while sending a recessive level itself, it will fail in the arbitration process and quits immediately will start acting as a receiver.
  3. This arbitration process is performed while sending the arbitration ID field of the CAN frame and at the end, only one transmitter is left on the bus i.e. the node with the highest priority (lowest arbitration ID) will pass the arbitration.
  4. Then the node which has won the arbitration will continue message transmission as if nothing had happened.
  5. Other receiving node can decide if a message is relevant or if it should be filtered using a combination of hardware and software filters.
  6. This process is continuous and other nodes will transmit their messages when the bus has become available.
Bit Wise Arbitration process

CAN protocol – Bit Wise Arbitration

With this blog, we have covered all the basics of CAN communication including the physical layers, Data link as well as arbitration mechanisms. In the upcoming blog, we will explain more on software perspective about configuring a CAN controller for operation and handling message flow.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Embien has successfully executed many projects like Android based Auto infotainment system, GUI for TFT based instrument clusters, vehicle tracking devices, etc. Embien also offers a set of solutions such automotive grade BLE module (eStorm-B1), CAN to BLE gateway, CAN to RS232/RS485 gateway, LIN to BLE gateway, Sparklet GUI library that can be used to shorten automotive product development costs and time significantly.

Earlier, in a series of blogs on eStorm-B1 BLE module, we have discussed about few applications of the module such as smart metering, as a Bluetooth to serial adapter along with a demo of the same. Further to a very positive response to the module, Embien has come up with an Evaluation Kit for the same. Incorporating various features targeting different market segments, we have designed the EVK as a ready to use product. This blog will introduce the reader to the kit for eStorm-B1 BLE module and in detail its application as a BLE to RS232 MODBUS converter

RS232 Modbus serial interface 

RS232 serial interface is still one of the most used wired communication standards. Introduced in 1960, it has survived and still surviving onslaught from many advanced standards because of its reliability and simplicity. They are intended to operate over a distance up to 15 meters and the maximum data rate is around 160 Kbits per second. They are often being used in many applications such as data acquisition systems, PLCs etc. While the underlying logical layer can be handled by UART interface, there are many possible application layer protocols that can be run on it. One of the most popular industrial protocol standards is called Modbus.

Modbus is a serial communication protocol developed for transmitting information over serial lines between electronic devices. The Modbus network can have one Master device and up to 247 slave devices. The master device can request or write the information to the slave and the slave device will supply the information. Registers are allocated for each data in the slave device and the master will write or read data to and from a slave device’s register.

It is an open protocol, where the manufacturer can build into their equipment without any royalties. The protocol has multiple versions such as Modbus RTU, Modbus ASCII for serial communication and Modbus TCP for Ethernet. Modbus has become the standard communication protocol in industry and it is a commonly available means of connecting industrial electronic devices.

Need for Wireless Communication 

Day by day, the communication interfaces and protocols are being updated to handle large data more reliably and over a longer distance. Of late, due to the advent of Industry 4.0 and IIoT, the need for wireless communication becomes inevitable. Industry 4.0 brings smartness in automation and data exchange in manufacturing technologies. It includes IoT, cloud computing, etc which calls for seamless data communication. Existing infrastructure can enable them with minimal changes using wireless technologies. This necessitates a suitable gateway for converting the wired serial interfaces to wireless.

Embien, following the current industry trends has launched a wireless module “eStorm-B1” under its eStorm series of solutions. The BLE module can support wireless serial communication with the available UART interface and can readily be used as a BLE to UART converter bridge. In addition to the COTS BLE module, Embien has also launched an evaluation kit “eStorm-B1 EVK”. This evaluation kit can support quick evaluation of eStorm-B1 module features.

Following are the features of eStorm-B1 EVK,

  1. 1X RS232 or RS485 serial interface
  2. 1X CAN interface
  3. 1X LIN interface
  4. One analog input and one isolated digital input for external sensor interface
  5. One digital output for external load control
  6. Onboard EEPROM
  7. Onboard Accelerometer
  8. Battery operated with inbuilt battery charger
  9. Compact dimension with mounting holes
  10. Screw type PCB connectors for serial and CAN interface enabling rigid connection to external devices
Evaluation kit for eStorm-B1 BLE module

Evaluation Kit for eStorm-B1 BLE Module

eStorm-B1 EVK as Wireless Modbus gateway

Of various interfaces, one that interests us for this blog is the presence of a RS232 interface. eStorm-B1 EVK based BLE to RS232 Modbus converter is suited for wireless Modbus gateway applications discussed earlier. eStorm-B1 EVK supports three wire RS232 serial communication via null modem cable and is exposed via a screw type PCB Terminal connector. Designed for rugged industrial environments, the EVK can operate in 5V DC input and RS232 receiver can accept up to +/- 30V input withstanding surges up to 15-kV (HBM) in the RS232 lines. Optional enclosure is also available.

On the protocol front, it includes a fully tested Modbus Client stack. It can query Modbus slaves present in the line. Android application is also available that can be used to configure the device and acquire data. Some of the features supported by the eStorm-B1 EVK based Wireless Modbus Gateway are,

  • Configuration of baud rate, Stop and data bits.
  • Modbus RTC/ASCII support
  • Continuous data acquisition
  • Notification based on change of value
  • Customizable buttons in the App for simple configuration of Modbus slaves

Thus eStorm-B1 as a wireless Modbus gateway can be used to interface with multiple devices for applications such as wireless data acquisition via existing data acquisition device, controlling the machines via PLCs for various industrial automation application, etc.

About Embien

Embien Technologies is a leading provider of embedded design services for the industrial automation. We have done various types of Data acquisition Systems, Industrial Human Machine interfaces, BLE based pH Meters, precision measuring instruments etc. We are currently working on enabling the industry 4.0 initiatives to make them smarter and greener.

In a series of blogs on BLE, we have discussed in detail about the Bluetooth technology, its classifications, its popular variant BLE and various hardware design considerations such as SoC selection, RF layout and Antenna selection. These posts were primarily in perspective of hardware design.  Bringing up the software functionality is mostly straight forward as the stack is provided by the silicon vendor and will run with little or no modifications. But improving and optimizing the performance is a different story altogether. In this series of blog, we will discuss about various parameters related to BLE operations and important considerations while working with BLE devices.

To begin with, some of the important aspects of Bluetooth low energy communication are as follows,

  1. Advertisement interval
  2. Connection interval
  3. Slave latency
  4. Connection supervision timeout
  5. Data throughput

Understanding the above aspects will help any developer to lower the device power consumption, increase the speed of connection and improve the reliability of data transmission and reception.

In the following sections of this blog, we will discuss in detail about the BLE Advertisement process along with a practical example based on Embien’s eStorm-B1 Bluetooth Low Energy module by capturing the Advertisement packets using the nRF sniffer.

BLE Physical Layer

It is important to know about the BLE physical layer, such that we understand the BLE communication better, because physical layer includes the actual RF radio and is in charge of sending the signals over the air.

Bluetooth Low Energy is similar to classic Bluetooth where both of them use 2.4GHz spectrum but differ from each other with different modulation index. Classic Bluetooth uses 79 channels whereas BLE uses only 40 channels and are the channels of both are spaced differently. Due to this, the BLE and classic Bluetooth cannot communicate. But there are modules that can support both BLE and classic Bluetooth which operates by switching its modulation parameters and the channels.

The 2.4GHz spectrum of BLE is divided into 40 channels (0 to 39) which extend from 2402MHz to 2480 MHz with 2MHz spacing. Among the 40 channels, BLE advertisement takes place in 3 channels (37, 38 and 39) and data exchange takes place in remaining 37 channels.

The following image illustrates the channel layout of BLE with 3 advertising and 37 data channels.

Channel Layouts of BLE

BLE – Channel Layout

BLE Communication

BLE communication takes place between a “central device” (for example Android Smartphone or iPhone) and a “peripheral device” (for example eStorm-B1 BLE module). Any BLE communication can happen only with the following two modes,

  1. Advertisement mode
  2. Connection mode

BLE advertisement mode by default is uni-directional and will be initiated only by the peripheral device through sending advertisement packets. The peripheral device will broadcast advertisement to every device around it.

Connection can be initiated only by the central device (within the communication range of the peripheral device) to receive more information. Only in connection mode, both the peripheral and central device can send packets.

Connection cannot be done between two devices without using advertisements and central device cannot send any packets to peripheral device without a connection. 

BLE advertisement Interval

BLE peripheral device in advertisement mode will send advertisement packets periodically on each advertising channels (channel 37, channel 38 and channel 39) at a user defined interval called “Advertisement interval”. Setting advertising interval is the first and foremost task for any developer, since the value has great impact on the connection speed and power consumption. The advertising interval can be as short as 20 milliseconds or as long as 10.24 seconds.

In practical case, the time interval between the advertisement packets will have a fixed interval set by the user and a random interval between 0 millisecond to 10milliseconds. This random interval will be added automatically in order to avoid collision between advertisements of different devices.

Interval between BLE Advertising events

BLE Advertisement Interval

A short advertisement interval will enhance the central device to find the peripheral device quickly. On the other hand, due to frequent radio operation the power consumption becomes higher. So the developer should set a value balancing the speed and power consumption.

eStorm-B1 module – UART to BLE setup for capturing advertisement packets and interval

In this example, eStorm-B1 BLE module and PC communication is established via UART. UART interface is available in the module in TTL level and a UART to USB Bridge is used to connect the module with the PC via USB port. A windows console application “UART_BLE” is developed to simply the process of communications such as,

  1. Starting and stopping advertisements
  2. Transmit and receive data’s
  3. Set and get BLE RF parameters such as
    1. Transmit power
    2. Advertisement interval and
    3. Connection interval
  4. Enabling interrupts
  5. Get interrupt status

nRF Sniffer, a windows application from Nordic Semiconductor, together with Wireshark, is used for viewing the Bluetooth Low Energy communication between two devices using BLE. In this example, BLE advertisement packets sent from eStorm-B1 and the interval between two advertisements are sniffed.

The following images are the screen shots that depicts the advertisement interval of 5 seconds being set in eStorm-B1 BLE module via “UART_BLE”, a windows console application and the Wireshark capture done via nRF sniffer application for observing the advertising packets and interval.

UARTBLE Console application

Embien’s UARTBLE-Console application for eStorm-B1


Nordic Sniffer application for BLE

nRF BLE Sniffer Application


Wireshark capture of BLE Advertisement interval

BLE Advertisement interval – Wireshark Capture


BLE Tags and BLE Beacons

 BLE advertisements in general are of two types such as connectable advertisement or non-connectable advertisement. Connectable advertisement type is most common. It is not directed and it is connectable, which means a central device can connect to the peripheral that is advertising and it is not directed towards a particular central device. Non-connectable advertisement is a type used when the peripheral does not wants to accept connections and broadcast only the data in the form of advertisement.

BLE Advertisement is more popular due to its significance of broadcasting data along with the advertisement. The advertisement packets itself has suitable bytes dedicated for custom data which can be used by a developer to broad cast data. The typical application of the non-connectable advertisement is the BLE tags and beacons.

BLE tags are mainly used for asset tracking were the advertisement data broadcasted will help to track each device to which they are connected.

Beacons evolved with the introduction of Apple’s iBeacon, targeted for proximity market such as shopping malls, retail showrooms, etc. Also we have Google’s Eddystone as an alternative for iBeacon for Android platforms. In both these technologies the device will transmit very small bits of data via BLE advertisement.

Application of BLE Beacons

BLE Beacon – Applications

In this blog we have briefly discussed about the BLE communication, BLE advertisement and advertisement interval. In the fore coming series of blogs, we will discuss in detail about the BLE connection parameters such as connection interval, slave latency, etc.

About Embien

Embien Technologies is a leading provider of embedded design services for the Semi-conductor, Industrial, Consumer and Health Care segments. Embien has successfully executed many projects like based on IoT such as healthcare Wearables, Gateways, and Data Analytics etc. Embien also offers a set of wearable design collections complete with electronics, firmware and Cloud that can be used to shorten product development costs and time significantly.