In the last blog, we have covered the basics of CAN communication. Now, we will see about some of the advanced concepts involved such as Bit Stuffing, frame types, error types, Synchronization etc. We will also look into some of the non-standard extensions available in modern CAN controllers.

Generally, all CAN modules support the classical CAN protocol. It can receive and transmit both CAN base and the CAN extended frames. The transmission and reception of CAN FD frames is optional. Classical CAN Implementation do not support 29-bit identifiers. CAN 2.0B passive nodes were compliant with ISO 11898-1:2003, but it used very rarely. In this context, let us explore some of other concepts in detail.

Bit Stuffing

Bit Stuffing is used to ensure the synchronization of all nodes even when transmitting consecutive information with same value either 1 or 0.
During the transmission of message, a maximum of five consecutive bits may have the same polarity. In this case, the transmitter will insert the one additional bit of opposite polarity into the bit stream before transmitting the further bits. This will ensure that there is always some activity in the bus with in 6-bit intervals and hence avoid DC Voltage build up as well as being in sync with the transmitter.

Stuffing and De-stuffing

On the receiving end, similarly the receiver also checks the number of bits of same polarity and removes the stuffed bits again from the bit stream in a process called de-stuffing.

CAN Frame Types

There are 5 types of frames in CAN protocol;

Data Frame (DF):

Carries Data from transmitting node to receiving node.

Remote Frame (RF):

Some times, a node might want to request some data from another which is made possible by Remote frame.
There are two differences between data and Remote frames.
RTR field of a data frame is dominant and RTR field of remote frame is recessive.
In data frame format data field is present, whereas in Remote frame format data field is absent.

The receiver will understand that transmitter is requesting some date and then prepares and sends the Data frame based on the protocol.

Error Frame (EF):

This type of frame is transmitted by any node to signal error.
The error frame consists of two different fields in CAN.
superposition of ERROR FLAGS (6–12 dominant/recessive bits)
ERROR DELIMITER (8 recessive bits).
There are two types of error flags:

Active Error Flag

When the Transmitting node transmitted six dominant bits, the error will be detected in network and the error sate called active error flag.

Passive Error Flag

When the Transmitting node transmitted six recessive bits, the error will be detected in network and the error sate called passive error flag.

Now let us see, how the CAN manages error states. In every CAN node, there are 2 error counters – Transmit Error Counter (TEC) and Receive Error Counter (REC). When the transmitter detects an error in the transmitted frame, it increments the TEC by 8. A receiver detecting an error will increment its REC by 1. On successful transmission/reception the error counters are reduced by 1.
Based on the error counts, the node behavior varies.

  • By default, the Active Error frame will be transmitted on the bus, when TEC and REC < 128. Thus, it will invalidate the frame globally.
  • But when 127 < TEC \ REC > 255, the passive Error frame will be transmitted on the bus, without affecting the bus traffic.
  • Finally, the node enters into the Bus off state, when TEC > 255. If node enters into the bus off state then no frames will be transmitted.

In any case, both transmitter and receiver reject the erroneous frames completely and do not process it any further.

Overload Frame (OF):

Overload frame contains two fields such as Overload flag and Overload Delimiter.
The over load frame will be generated, when the receiving node is overloaded – i.e. it is not able to detect and receive the incoming messages. The format is very similar to Error Frame but without the error counters incrementing. An Overload frame indicates that its transmitter require delay before receiving next data or remote frame and is mostly not used in modern CAN controllers.

Inter Frame Space (IFS):

Data frames and remote frames are separated from preceding frames and succeeding frame by a bit field called interframe space. It consists of three consecutive recessive bits. Following that, if a dominant bit is detected, it will be regarded as the “Start of frame” bit of the next frame.

Frame on CAN BUS

Error Types

There are 5 types of error in CAN protocol.

Bit error:

Every node reads back, bit by bit from the bus during transmitting the message and then compares the transmitted bit value with received bit value. If bit received does not match with bit sent, then Bit error is said to be occurred.

Stuff error:

Set when more than five consecutive bits of same polarity are received in receiving node.

CRC error:

A transmitted always transmits the CRC value in the CRC field of CAN frame. The receiving node also calculates the CRC value using same formula and compares with received CRC value. If receiving node detects mismatch between calculated CRC values and received CRC value then it is called CRC error.

ACK error:

Occurs when no acknowledgment is sent by receiving node or no acknowledgment received in transmitting node.

Form error:

Set when fixed format fields in receive frame is violated. No dominant bits are allowed in CRC delimiter, ACK delimiter, EOF and IFS.

Synchronization and Re-synchronization

As there is no separate clock signal on the CAN bus, the node itself need to synchronize on the bus. For that reason, the underlying transmission format is NRZ-5 coding.
When the transmitting node sends CAN frame it consists the first bit of SOF (start of frame). All the receivers align themselves to this falling edge (recessive to dominant) after the period of bus idle. This mechanism is called hard synchronization.
After subsequent falling edges on the CAN frame are used to re-synchronize the nodes on bus and it is called soft synchronization. This resynchronization happens continuously at every falling edge (recessive to dominant transition) to ensure transmitting and receiving nodes stay in sync.

Additional functions

Some CAN protocol implementations offer optional functions that may or may not be a part of CAN specification. These include, for example, the single-shot transmission of data frames. This means that the automatic re-transmission in case of detected errors is disabled. This is useful for TTCAN add-ons and some tool applications.
Another option generally available is the bus-monitoring mode. The node can receive data and remote frames, but doesn’t acknowledge them and also doesn’t send error and overload flags. Nevertheless, these dominant bits are communicated internally in the CAN module.
In another optional restricted operation mode, the CAN module behaves equally, but it acknowledges received data and remote frames. The error counters are not incremented and decremented in this mode. If a node is the TTCAN time master, it must be able to transmit the time-reference message; other frames must not be transmitted.
For some applications, message time stamping is required. ISO 11898-1:2015 specifies that the optional time-stamp function features resolutions of 8-bit, 16-bit, or 32-bit. The time-base value is captured at the reference point of each data frame and it is readable after EOF (end-of-frame). Other (not standardized) optional functions include readable error counters, configurable warning limits, interrupt request generation, and arbitration lost capture.
If the CAN implementation allows changing the configuration of a node by software, the configuration data (e.g. bit-time configuration or operating mode) needs to be locked against changes while CAN communication is ongoing.

Armed with details of CAN communication, we will now attempt to understand general configuration of a CAN node for transmission and reception with examples from a real controller.

About Embien

Embien Technologies is a leading provider of product engineering services for the Automotive, Semi-conductor, Industrial, Consumer and Health Care segments. Working with OEMs in Industrial segments, we have developed numerous gateways, sensory modes on top of CAN network and protocols such as DeviceNet, CANOpen etc. Our Automotive experience enabled us develop Telematic units and In-vehicle Infotainment systems, Instrument clusters with CAN interfaces.

Saravana Pandian Annamalai
17. October 2018 · Write a comment · Categories: Android · Tags: ,

Android offers few emulators for development purposes. As a part of standard AOSP (Android Open Source Project), these emulators come in handy for development such as customization, debugging, middleware development, app development etc. But for underlying hardware access most of the other higher-level developments can be done over these emulators. There are quiet a few variants of emulators such as for general Phone/Tablet emulation or for automotive purposes – Car Emulator. This blog will focus primarily on building Android car emulator and running it in the system. We will also touch up on compiling the kernel from the source and running them as well.

Downloading AOSP source for emulation

First thing to start building car emulator is to finalize on the release version we want to build against. The list of supported variants is available in the Codenames, Tags, and Build Numbers page from the android web site. Based on the requirements, identify the version – in this case let us assume we want to build for OPM6.171019.030.B1. Note the build version it corresponds to android-8.1.0_r33.

Now we will have to download the source code for the same. Android source code is in fact a collection of git repositories. Each of the major directories in the AOSP corresponds to a separate repository. Since it is difficult to manage such a large code base individually one by one, Google has created a tool called repo that helps in this process. Install this tool with the following steps

mkdir -p ~/bin
wget ‘https://storage.googleapis.com/git-repo-downloads/repo’ -P ~/bin
chmod +x ~/bin/repo

Now that the tool is downloaded, set up your git configuration using the following commands

git config –global user.name “your name”
git config –global user.email “your_email@your_domain.com”

Assuming you are running Ubuntu 16.04, to prepare the environment, execute the following

sudo apt-get update

Install the dependencies:

sudo apt-get install openjdk-8-jdk android-tools-adb bc bison build-essential curl flex g++-multilib gcc-multilib gnupg gperf imagemagick lib32ncurses5-dev lib32readline-dev lib32z1-dev libesd0-dev liblz4-tool libncurses5-dev libsdl1.2-dev libssl-dev libwxgtk3.0-dev libxml2 libxml2-utils lzop pngcrush rsync schedtool squashfs-tools xsltproc yasm zip zlib1g-dev

Identify the working directory and create it if necessary.

mkdir -p ~/aosp

Switch to the directory

cd ~/aosp

As mentioned earlier, we need the manifest file to being with. This initial file can be set up using the following commands.

The above command will download an XML file called “manifest.xml” that contains information about all the git repositories that constitute the AOSP.

Since the above command will download a large set of objects including previous versions, if you want to limit the download size, you can set the downloaded version depth to 1.

repo init -u https://android.googlesource.com/platform/manifest -b android-8.1.0_r33 –depth=1

With everything set, being the download using the following command.

repo sync

This command will perform the actual download operation all the necessary repositories and prepare the directory for further building.

Building Car Emulator

We can now start building Android car emulator. Once again being a large project, it is better to set up a compiler cache so that the incremental builds are quite faster.

export USE_CCACHE=1
prebuilts/misc/linux-x86/ccache/ccache -M 15G

Below output confirms that the command executed successfully.

Output

Set cache size limit to 15.0 Gbytes

Powered by the Soong build system, the AOSP employs a variety of tools to build the source and create the images. Jack compiler used employs a server mechanism where by a single process running in the system compiles files. To configure the same, execute the below commands such that the Java based tool uses the configured amount of RAM for the JVM. In this example, it is limited to 6GB.

export ANDROID_JACK_VM_ARGS=”-Xmx6g -Dfile.encoding=UTF-8 -XX:+TieredCompilation”

With every thing set up now for building the source, now configure the environment variables used by the Android build system using

source build/envsetup.sh

The source command simply executes the given script in the same shell so that its environment variables are affected. Below output is shown

root@aosp:/home/user1/aosp/ # source build/envsetup.sh
including device/asus/fugu/vendorsetup.sh
including device/generic/car/vendorsetup.sh
including device/generic/mini-emulator-arm64/vendorsetup.sh
including device/generic/mini-emulator-armv7-a-neon/vendorsetup.sh
including device/generic/mini-emulator-mips64/vendorsetup.sh
including device/generic/mini-emulator-mips/vendorsetup.sh
including device/generic/mini-emulator-x86_64/vendorsetup.sh
including device/generic/mini-emulator-x86/vendorsetup.sh
including device/generic/uml/vendorsetup.sh
including device/google/dragon/vendorsetup.sh
including device/google/marlin/vendorsetup.sh
including device/google/muskie/vendorsetup.sh
including device/google/taimen/vendorsetup.sh
including device/huawei/angler/vendorsetup.sh
including device/lge/bullhead/vendorsetup.sh
including device/linaro/hikey/vendorsetup.sh
including sdk/bash_completion/adb.bash

Now choose the platform you want to build. For example, we can either build the car emulator for 32-bit X86 system or 64-bit x86 system.

For building for 32-bit, use the below command.

lunch aosp_x86_car_emulator

For 64-bit use,

lunch aosp_x86_car_emulator

Typically, you will see the below output.

============================================

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=8.1.0
TARGET_PRODUCT=aosp_car_x86
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_PLATFORM_VERSION=OPM1
TARGET_BUILD_APPS=
TARGET_ARCH=x86
TARGET_ARCH_VARIANT=x86
TARGET_CPU_VARIANT=
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-4.4.0-137-generic-x86_64-with-Ubuntu-16.04-xenial
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=OPM6.171019.030.B1
OUT_DIR=out
AUX_OS_VARIANT_LIST=

Initiate the build now with make command. To leverage the multiple CPU cores, present in your host machine, specify a number corresponding to it.

make -j8

It will take about 1 hour to 3 hours for the build to complete depending on the host system configuration.

Creating filesystem with parameters:
Size: 2684354560
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 10240
Label: system
Blocks: 655360
Block groups: 20
Reserved block group size: 159
Created filesystem with 2219/163840 inodes and 219060/655360 blocks
[ 99% 64341/64342] Install system fs image: out/target/product/generic_x86/system.img
out/target/product/generic_x86/system.img+ maxsize=2740556544 blocksize=2112 total=2684354560 reserve=27684096
[100% 64342/64342] Create system-qemu.img
1+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00427205 s, 245 MB/s
2560+0 records in
2560+0 records out
2684354560 bytes (2.7 GB, 2.5 GiB) copied, 3.17107 s, 847 MB/s
1048576+0 records in
1048576+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 1.86999 s, 561 kB/s
Creating new GPT entries.
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
Setting name!
partNum is 0
REALLY setting name!
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot.
The operation has completed successfully.
#### build completed successfully (01:26:36 (hh:mm:ss)) ####

Running the Car Emulator

Once the build is completed, the images will be created inside the out/target/< product >/directory. The emulator can now be invoked using

emulator

Typically, you will see the emulator running as below.

Now you can connect to it over ADB and perform various operations such as installing a new App, debugging it, modifying the AOSP source and testing it etc.

Compiling the kernel

The emulator can be launched to show the kernel output and console by using the show kernel option as below.

emulator –show-kernel
generic_x86:/ $

In the login, we can check the kernel version using uname command.

We can see, this emulator runs kernel version 3.18.74+. Looking for the source, it can be found that it is available in the repository as commit c57e557. Download the same using the below commands:

Get goldfish branch c57e55706abeffafbc52d28155297650dae6e2c0

Build the same using the following commands:

git clone https://android.googlesource.com/kernel/goldfish/ -b android-goldfish-3.18
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9
cd goldfish
export CROSS_COMPILE=x86_64-linux-android-
export ARCH=x86_64
export PATH=$PATH:/path/to/x86_64-linux-android-4.9/bin
make x86_64_ranchu_defconfig
make menuconfig # enable overlayfs and namespaces support here
make -j8

The output kernel will now be available at arch/boot/x86/bzImage

This image can be used for the emulator when launching as follows:

emulator -kernel <Path to kernel directory>/ arch/boot/x86/bzImage

By giving uname now, it can be seen that the build time/machine reflects

Building Android Car Emulator and running it in the system helps to accelerate various platform/application developments. It is possible to complete some part of underlying driver/HAL development using this kernel in this approach.

About Embien: Embien Technologies is a leading service provider for the Android technologies including Android porting, HAL development, HIDL developments, custom system services, deployment, App development etc. Our team extensively uses emulator for speeding up the developments even before the underlying hardware is available. Apart for developing Auto-infotainment systems, customized tablets, Home Automation consoles, rugged handhelds, Industrial HMI’s, our SMEs offers corporate training covering topics such as Android Platform development, Android for Automotive and Linux Device Drivers.

Dhananjayan
31. May 2018 · Write a comment · Categories: Embedded Hardware · Tags: , , , ,

This blog is the sequel of the previous blog on Geo positioning system technologies. Here we will discuss more in detail about the important terms related to GPS receivers and guidelines for selecting suitable GPS receiver module for embedded system design.

GPS Receiver

Connection diagram for GPS module

GPS Module – Connection Diagram

The above picture depicts the typical connection diagram of GPS module with any host controller. There are multiple interface options available for a host controller to receive the NMEA data where UART, SPI and USB are most common. PPS signal is an output from GPS and it is discussed in detail in the upcoming sections. Most of the GPS modules have internal patch antenna but also supports external active antenna connection.

NMEA Data

 NMEA (National Marine Electronics Association) data is the detailed output from any GPS receiver that includes the current location data of the receiver such as Latitude, longitude, altitude etc. This data is provided in a standard format to the user for compatibility with various manufacturers much like ASCII standard for digital computer characters.

Following is the example of a NMEA message from a GPS receiver,

$GPGGA,181908.00,3004.6040718,N,07040.3900269,W,4,13,1.00,408.135,M,29.200,M,0.10,0000*40

All the NMEA message starts with a $ character where each field is separated by a comma.

“GP” in GPGGA – represent that it is a GPS position. For GLONASS, it will be GL instead of GP.

GPGGA is a basic GPS NMEA message and many other NMEA messages are also available providing similar or additional information beside GPS coordinates. There are 19 different NMEA messages and they are listed below,

  1. $GPBOD – Bearing, origin to destination
  2. $GPBWC – Bearing and distance to waypoint, great circle
  3. $GPGGA – Global Positioning System Fix Data
  4. $GPGLL – Geographic position, latitude / longitude
  5. $GPGSA – GPS DOP and active satellites
  6. $GPGSV – GPS Satellites in view
  7. $GPHDT – Heading, True
  8. $GPR00 – List of waypoints in currently active route
  9. $GPRMA – Recommended minimum specific Loran-C data
  10. $GPRMB – Recommended minimum navigation info
  11. $GPRMC – Recommended minimum specific GPS/Transit data
  12. $GPRTE – Routes
  13. $GPTRF – Transit Fix Data
  14. $GPSTN – Multiple Data ID
  15. $GPVBW – Dual Ground / Water Speed
  16. $GPVTG – Track made good and ground speed
  17. $GPWPL – Waypoint location
  18. $GPXTE – Cross-track error, Measured
  19. $GPZDA – Date & Time

181908.00 UTC Time stamp in hours, minutes and seconds.

3004.6040718 Latitude in DDMM.MMMMM format. Decimal places are variable.

N North latitude

07040.3900269 Longitude in DDMM.MMMMM format. Decimal places are variable.

W West Longitude

4 Quality Indicator. Other options are as follows,

0 = Fix not valid

1 = Uncorrected coordinate

2 = Differentially correct coordinate (e.g., WAAS, DGPS)

4 = RTK Fix coordinate (centimeter precision)

5 = RTK Float (decimeter precision)

13 Number of satellites used in the coordinate

1.00 denotes the HDOP (horizontal dilution of precision).

408.135 Altitude of the antenna

M unit of altitude (e.g. Meter or Feet)

29.200 geoidal separation. Subtracting this from the altitude of the antenna will provide the Height Above Ellipsoid (HAE)

M Unit of geoidal separation

0.10 age of correction

0000 correction station ID

*40 checksum

Time-To-First-Fix (TTFF)

 Another most important deciding feature of GPS receiver is the TTFF. TTFF of a receiver only decides how fast it can provide a valid NMEA data to the user. So the user must be very careful on the TTFF values while choosing the receiver. The TTFF values will be provided in the datasheet in seconds.

Any receiver can boot up in any one of the following three modes:

  1. Hot start
  2. Warm start
  3. Cold Start

The Time-To-First-Fix (TTFF) depends on the startup mode, with cold starts giving the longest TTFF. Following are the factoring affecting boot mode,

  1. Non availability of valid almanac and ephemeris data
  2. Level of incoming signals
  3. The unit is within 60 miles (100 Km) of location of previous fix
  4. Length of time since previous fix

Cold Start Mode

: Any receiver start in this mode when,

  1. Receiver has not been used for long time
  2. Moved several hundred kilometers
  3. Incoming signals are low or marginal. i.e. the predicted satellites are overhead of the receiver but cannot receive signals due to tall buildings, foliage etc.

Any of the above situation will make the receiver cannot predict which satellites are overhead. Then the receiver works with an internal list of satellites and tries to acquire each one in turn. This allows the receiver to discover the satellite which are in view and eventually establish a position. Normally the TTFF on cold start takes 2 to 4 minutes.

Warm Start Mode

: Any receiver start in this mode when,

  1. It has valid almanac data
  2. The current location of receiver is within hundred kilometers of the last fix location
  3. Receiver has been active in last three days and current time is known
  4. Ephemeris data that has not been stored or it has become stale
  5. Good signal strength and 4 or more satellites are visible

In this mode the receiver can predict which satellites are overhead but it needs to download the current Ephemeris data. TTFF for warm start mode is typically 45 seconds.

Hot Start Mode:

The receiver starts in this mode when the warm start conditions are met and,

  1. A fix has been established within the last 2 hours
  2. The receiver has stored valid ephemeris data for atleast 5 satellites

Receiver tracks the overhead satellites and needs to download minimum data to establish a position. TTFF for a hot start is typically 22 seconds. 

A-GPS

We have come across many startup modes for any receiver, but wonder how smartphone GPS units get a fix almost immediately?

They use Assisted-GPS (A-GPS) as a procedure of improving the TTFF or even allowing a fix in conditions where receiver might not be able to function.

A-GPS device will use a data connection available on the smartphone to contact an assistance server. This server will supply almanac and ephemeris data instead of waiting to receive them from the satellites. The server can also provide approximate location derived from the cell phone towers facilitating immediate fix.

PPS Signal

Most GPS receiver modules have an output called Pulse Per Second abbreviated as PPS. It is a digital output signal with much lower jitter than anything a MCU can do. PPS signal can be used          to time things very accurately at a precision in nanoseconds.

They are most commonly used to wake the MCU from deep sleep mode periodically at an interval of one second. In some applications, they are used to synchronize the system time and rectify the time drift due to the temperature effects of the RTC crystals. 

Selection guide for receiver

There is lot of options available while selecting a receiver module. Some of the main factors to be considered while selecting the receiver are as follows,

  1. Multi system support – Receiver module can be GNSS or GPS only. GNSS module provides simultaneous support to GPS, GLONASS, BeiDuo and Galileo systems. GNSS modules are better than GPS only modules and the cost of the GNSS module will be bit more comparative to the other.
  2. Size – Most important deciding factor for size constraint devices. Nowadays modules are getting very small but in general the antenna will also shrink to fit the module which will reflect in the lock time and accuracy.
  3. Number of channels – At a given time, there are so many satellites available in view but the number of channels a receiver module can track/acquire will affect the TTFF. The more a module can track/acquire many satellites, the faster it will find a fix.
  4. Update Rate – It is the time interval that how often a receiver module can recalculate and reports its position. The standard rate of a module is 1Hz (one report per second). Fast update rate means that there are more NMEA sentences coming out of the receiver module by which any microprocessor will be quickly overwhelmed trying to parse that much data.
  5. Power consumption – Another important factor that decides the success of a battery powered devices. There are many factors deciding the power consumption of a receiver module and in any case the typical power consumption should be low in few tenses of mA ranging between 25 to 30mA. Most of the receivers have various power saving modes which can be used during idle conditions.
  6. Antenna – Antenna defines the quality of the receiver module and it must be finely trimmed good enough to pick up the frequencies. Receiver modules available with a small patch antenna on top of it. It is made of ceramic. Some modules will also have dedicated antenna pin for connecting external active antenna. Receivers used in cars require external antenna support since the receiver module has to be placed inside the vehicle mostly connected to the OBD port which will be placed beneath the dashboard where a patch antenna will struggle to receive the signals.
  7. Accuracy – Varies between modules. Most modules can get it down to +/- 3m and sub meter or centimeter accuracy are also available but bit expensive.

About Embien

Embien Technologies is a product engineering service provider with handsome experience on automotive product developments. Embien has various solutions for time to market developments for automotive domain including Sparklet Embedded GUI library for 2D or 2.5D or 3D Instrument clusters, Flint IDE for GUI prototyping and eStorm-B1 – Automotive grade BLE Module.