Transmission Control Protocol (Tcp)

Author: Mangesh A. Dahale

Transmission Control Protocol (TCP)

Today, the majority of application protocols use the Internet's reliable Transmission Control Protocol (TCP). The functionality of TCP is designed to be adequate not only for Internet applications but also for the variety of underlying networks.

The protocol aims at providing a reliable service with the following features:

1. Fairness to other flows that potentially share a channel's bandwidth

2. Dynamic discovery of current availability of bandwidth

• 1. Mechanisms for congestion avoidance and control and for optimization of the error recovery process.

Error control mechanisms are the central component of reliable protocols. They affect a protocol's performance with respect to goodput, energy expenditure, and overhead. Error control is usually a two-step process: error detection, followed by error recovery . TCP assumes a relatively reliable underlying network where most packet losses are due to congestion . TCP error control is centered on congestion losses and ignores the possibility of transient random errors or temporary blackouts due to handoffs and extended burst errors that are typical in wireless networks. TCP detects errors by monitoring the sequence of data segments acknowledged (received). When timeouts are correctly configured, a missing segment is taken to indicate an error, namely that the segment is lost due to congestion (i.e. buffer overflow). Reliable protocols usually implement an error recovery strategy based on two techniques: retransmission of lost segments; and downward adjustment of the sender's window size and readjustment of the timeout period. When using TCP over wireless links results in congestion control measure being invoked at the source.

The Additive Increase Multiplicative Decrease (AIMD) algorithm is used to implement TCP window adjustments; based on the analysis the algorithm achieves stability and converges to fairness in situations where the demand (of competing flows) exceeds the channel's bandwidth .

In a wireless network, however packet looses will occur more often due to unreliable wireless links than due to congestion. It is shown that the performance of TCP is sensitive to the packet size, and that significant performance improvements are obtained if a ‘good' packet size is used. Packets on the internet may get lost either due to congestion, or due to corruption by the underlying physical medium. Given the low error rates of wired links, almost all losses are related to congestion. TCP's reaction to looses is based on this very observation. Losses are detected either by timeouts at the source or by multiple duplicate acknowledgements ( dupacks ) from the receiver. TCP assumes that each packet loss is solely due to congestion. However, in a wireless network, TCP will encounter packet looses that may be unrelated to congestion. Nonetheless, these losses trigger congestion control measures at the source and severely degrade performance.

TCP was designed and carefully calibrated to overcome the problems like as follows:

• 1. Stability.
• 2. Heterogeneous ( receiver buffers, network bandwidth and delay ).
• 3. Fairness in bandwidth consumption of competing flows.
• 4. Efficiency in utilization.
• 5. Congestion control ( that effectively avoids situations of congestive collapse ).

Transmission Control Protocol (TCP) is a means for building a reliable communications stream on top of the unreliable packet Internet Protocol (IP). TCP is the protocol that supports nearly all Internet applications. The combination of TCP and IP is referred to as TCP/IP and many people imagine, incorrectly, that TCP/IP is a single protocol.

Performance Metrics of TCP :

Goodput :

This is the measure of how efficiently a connection utilizes the network. It is determined as the ratio of useful data received at the destination and the total amount of data transmitted by the source. If a connection requires a lot of extra packets to traverse the network due to retransmission, its goodput is low. It is desirable that each connection have as high a goodput as possible. Clearly, this metric is of great significance for efficient operation of a network.

Throughput :

This is the measure of how soon an end user is able to receive data. It is determined as the ratio of the total data received by the end user and the connection time. A higher throughput will directly impact the user's perception of the quality of service.

About the Author:

Article Source: Transmission Control Protocol (Tcp)

What is Unified Communications?

Author: Derek Rogers

A common question these days is, �What is unified communications?� Unified communications, or UC, is a way for businesses to simplify and integrate all forms of communications. It is a real-time delivery of communications based on a user�s preferred method or medium. In most cases a software program is used to achieve unified communications as well as to improve the infrastructure. Unified communications allow for messages to be sent using one medium and received using another.

The most frequent use of unified communications is probably receiving a voicemail and then reading it via email. However, voicemail and email are not the only two types of communications that can be unified. This communications leverage can apply to a variety of communications including chat, telephone, fax, and presence services.

In most cases, a unified communications software program will join the preferred communications mediums so that they may be easily transferred from one to another. A successful unified communications system will integrate and automate all forms of human communication into a streamlined and efficient experience. Using such a technological phenomenon can optimise a business, reduce latency and eliminate media and device dependencies.

The success or failure of any business is usually dependent upon that business� efficiency and speed, which is why one of the main focuses of unified communications is to reduce, or eliminate altogether, the element of latency. Obviously there will always be the requirement of time to make a decision, but the delay in receiving a message or communication can mean the loss of a sale or business deal. The main goal of unified communications is to remove any unnecessary delay through a streamlined and integrated set of communication technologies.

It is possible for a business to design specific Internet Protocol communications based on its particular needs and requirements. The first step in designing such a program is to establish the existing network�s suitability to support various media including text, voice and video services. Any areas that cannot support the unified communications system needs will be enhanced.

During the implementation of the unified communications system, there are some key service aspects that will be evaluated in addition to the ability of the existing network to support such services. Professionals will not only verify the existing system�s ability but will provide unbiased feedback, solution suggestions, detailed quotes and pricing as well as installation.

Because unified communications is such a sophisticated communications solution, it can only benefit any business that takes full advantage of the technology. Aside from the obvious benefits of staying connected and eliminating unnecessary delays, it allows all users within the network to know the location and status of each other. Furthermore, the technology allows users to see what medium is preferred by other users in order to streamline communications even more and personalise it where possible.

Unified communications is a way for businesses to seamlessly combine various forms of media and participate in real-time communications and collaborations with other users. Integrating and implementing a unified communications system will only help the bottom line by streamlining the development and production elements of any business.

About the Author:
Derek Rogers is a freelance writer who writes for a number of UK businesses. For information on Unified Communications, he recommends Network 24.

Article Source: What is Unified Communications?

Internet Protocol Communications in a Medical Practice

Author: Ray Torres

Did you know that good-old traditional business phone system switch is quickly becoming replaced by software base IP PBX systems? In fact, sales of new IP-PBX systems surpassed traditional PBX switches in 2005, and IP Telephony products sales will represent 90% of the new phone sales by 2010 -- only a few years away.

So how does a medical practitioner know if their office has a traditional PBX system? Here are a few clues:

• Calls are being made to the phone system vendor to make simple adds, moves, and changes.

• Staff is busy and is oftentimes placing the patients on hold, and patients are having to wait too long.

• Important voice messages are not getting to the practitioner because the message is buried in a lengthy voice mail box or the hand-written note is inaccurate.
• Patients are complaining about getting lost in the phone system.

• There is a separate phone system at each remote office, thus costing more for phone lines at each of these locations.

A software base IP PBX business system can provide the features and flexibility of customizing it to address a specific medical Practice. Just imagine these few benefits:

• Staff can spend less time trying to answer and route calls.

• System provides the flexibility to route and manage calls from referring or other physicians directly to the right service provider.

• Voicemail messages appear just like email messages and can be shared among several staff members for quick, easy retrieval and response.

• If a Practice prefers, their voicemail box can be forwarded to an email box for a single unified message platform.

• Staff can record and store voice messages or live conversations, and create personalized, targeted voice and broadcast messages that save time and enhance communication.

• Customized announcements and system prompts, such as for Spanish, can be accomplished easily and quickly.

• With a point-and-click interface, staff can easily take advantage of everything the system has to offer.

• Reduce or even eliminate answering service fees.

Now suppose a Practice has these functionalities available on their IP-PBX system, and the medical practitioner is either opening a new office or already has a multi-facility Practice. At this juncture, the Practice could consider Voice over Internet Protocol (VoIP) as another effective communications application.

Simply said, the Practice can setup/use their existing data Wide Area Network to transfer voice and data over the same high-speed connection. The implication of this connectivity, besides real telecom cost savings? In three words: better call management. Examples of better call management include:

• All users, regardless of location, can dial by extension.

• Key functions, like scheduling, can be easily centralized. Since the phone system is software based, with standard Windows based reports, the administrator will know quickly which periods of the day are high volume calls and what the calling trends are at each office.

• Non-official phone use gets eliminated almost immediately since call logs can be easily viewed by the administrator right at their PC.

• These offices are not stand alone any more, but are now connected to the central office.

With intra-office communications capability, the practice administrator will become more effective in many operational areas including staffing and handling of patient calls.

In every aspect of business, whether it’s a medical doctor or other licensed professional, patient/client satisfaction is a goal. By using proven communications technology wisely one can accomplish that aim. I know that a single communications configuration does not apply equally to all medical Practices, so upfront consultation is the first smart move toward IP communications. Waiting on the side lines to implement a software base IP PBX system may not be an option. Just around the corner are the obsolescence of the traditional PBX systems and the lack of product and service support.

About the Author:
As a senior manager and executive whose diverse business background, includes IP Telephony, Point-of-Sale Kiosk, Web Enabled Systems, Systems Integration, Information Technology Networks and Technology Staffing, Mr. Torres offers growth, operational and productivity solutions as a consultant.

Mr. Torres has held board of director and business advisory board positions with small-to-medium size, privately-held companies.

He earned his Master in Business Administration from Pepperdine University and a Bachelor of Science from Arizona State University. He is also a Stanford University Executive Development program graduate.

Article Source: Internet Protocol Communications in a Medical Practice

Know more Knowledge about Bluetooth

Author: bettytxzt

Technically bluetooth is an open wireless protocol for interchanging the datas in shorter areas for the creation of personal area networks with the help of fixed moblie devices. Bluetooth earlier consider as wireless option which act as an option of rs232 data cables. The bluetooth has the ability of connecting with several devices avoiding difficulties in synchronization. Historically the word bluetooth is named after anglicised version of old norse blatand which is falling on the name of the tenth century king named harald I of two countries like denmark and norway. The good part of bluetooth is that it does the same operations with communication protocols by keeping them in a single universal standard.

Bluetooth have certain specific functions such as wireless control and communicaiton in different mobile phone and hands free headset, having wierless networking in a limited space in the pc systems with the help of short bandwidth, wierless communication in pc input and output devices coming in mouse, keyboard and printer, transferring the files, contact details, calendar appointments, acting as reminders in several devices with obex, forwarding short advertisement fromt bluetooth enabled advertising hoardings to varied sources, in several infrared usage act as a controller etc. The bluetooth now showing its prescence with shorter bandwidth applications in comparison to largest one. And also those areas where cable fee connection is needed.

Bluetooth earlier consider as wireless option which act as an option of rs232 data cables. The bluetooth has the ability of connecting with several devices avoiding difficulties in synchronization. Historically the word bluetooth is named after anglicised version of old norse blatand which is falling on the name of the tenth century king named harald I of two countries like denmark and norway. The good part of bluetooth is that it does the same operations with communication protocols by keeping them in a single universal standard.

Also bluetooth act as wireless bridge among two industrial ethernet networks coming in the market. Bluetooth aids in replacing traditional usage of serial communication in varied test equipments, gps receivers, medical equipments, bar code scanners, and also in different traffic control devices. The biggest benefit of bluetooth consumers sees in two seventh generation game consoles such as nintendo's wii and sony's playstation3 in many wireless controllers. Prsently bluetooth has shown in several official purposes, homes, and travelling across the globe. It aids in setting up of networks, printing, forwarding presentations and files with pdas into the pc systems. Now bluetooth is having many specific features for this users have to collect information about bluetooth for making best usage of it in elctrical industry.

About the Author:

To read about bluetooth headset and other information, visit the bluetooth headphonessite.

Article Source: ArticlesBase.com - Know more Knowledge about Bluetooth

Interaction with FTDI chip

Author: Apriorit Inc.

What is FTDI chip?

FTDI chips are the chips which are developed by Future Technology Devices International (http://www.ftdichip.com/ ).

FTDI chips are used in USB adapters to connect to RS232 and parallel FIFO hardware interfaces. The most frequent usage is USB-2-COM interface.

They are used in:

1. Mobile phone cables.
   The mobile phones have RS232 or UART output, and PC may have USB only, the chip converts RS232 into USB. And the driver installed on PC creates the virtual device (usually, virtual COM port), which is used for communication.
2. Service Boxes
   These are service tools used by Phone repair centers and Car repair service. These are the devices which are connected to PC via USB, and - on the other side - to the various hardware.
3. Hardware Debuggers (JTAG)
4. Any other device that needs to be USB-connected to PC, and has the RS232 port on the other side.

How to find out if the device is FTDI-based?

Well, you may disassemble it and read the labels on the chips, but it’s not the way you want it. There’s more humane method.

There are original drivers on FTDI site. If you look at the files which are included into the driver package there will be such set of files:

So if your device has any of these files in the driver list it’s FTDI-based.

To see the drivers for the device:

1. Go to Device Manager
2. Select the device
3. Open context menu and select Properties
4. Switch to Driver and click Driver Details button.

For example:

This device has FTD2XX.dll in the driver files list. And the provided name is FTDI. This device is FTDI-based. Some manufacturers may rename the driver (.sys), but the copyright information will reveal the real driver manufacturer.

How to interact with it?

Fortunately, FTDI provides the API. There’s a generic API set which can be used with all FTDI chips.

API is provided via FTD2XX.dll. It’s a DLL which interacts with FTD2XX.SYS driver.

There’s a header file and library file within FTDI driver package: ftd2xx.h and ftd2xx.lib files.

The .lib file is COFF format, so it can be used in Visual Studio without any problem.

FTDI API usage

The API set has two interfaces “classical” (functions with “FT_” prefix) and “Win32 API” (functions with “FT_W32_” prefix).

“Classical” is cross-platform interface.

“Win32 API” is a set of Windows-only functions. It’s much alike Windows API, which is used to work with serial ports. So porting the code to FTDI functions is quite simple.

The main functions are:

FT_W32_CreateFile() / FT_OpenEx()
Opens the handle to the specified FTDI chip connection

FT_W32_WriteFile() / FT_Write()
Sends data over virtual COM port.

FT_W32_ReadFile() / FT_Read()
Reads data from virtual COM port

FT_W32_CloseHandle() / FT_Close()
Closes connection handle.

There are functions that allow to set up the port:

FT_SetBaudRate()
Sets the baud rate for the connection

FT_SetDataCharacteristics()
Sets the number of bits in the byte, parity, etc

FT_ClrDtr()
Clears DTR signal on the virtual COM port

FT_SetDtr()
Sets DTR signal on the virtual COM port

FT_ClrRts()
Clears RTS signal on the virtual COM port

FT_SetRts()
Sets RTS signal on the virtual COM port

etc.

For Windows there’s no limitation about using the functions of Classical and Win32 API interfaces together. So you may combine it.

Opening the virtual serial port

There are multiple ways to open FTDI device: by index, by description, by serial number, by location. These types of information may be used to open the device via FT_W32_CreateFile();.

To obtain the information about the connected devices FT_ListDevices() should be used.

Example:

ftStatus = FT_ListDevices(0, Buf, FT_LIST_BY_INDEX FT_OPEN_BY_SERIAL_NUMBER);
if (ftStatus!=FT_OK) //Get first device serial number
{
printf("Couldn't get FTDI device name");
return 0;
}

ftHandle = FT_W32_CreateFile(Buf,
GENERIC_READGENERIC_WRITE,
0,
0,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL FILE_FLAG_OVERLAPPED FT_OPEN_BY_SERIAL_NUMBER,
0); // Open device by serial number

There are several functions, which can provide the additional information about the connected devices:

FT_GetDeviceInfoList(),FT_CreateDeviceInfoList(), FT_GetDeviceInfoDetail(), etc.

Setting up the port

The code for setting the typical serial port settings to 115200 Bps, 8 bit per byte, 1 stop bit and no parity will look like this:

ftStatus=FT_SetBaudRate(ftHandle, FT_BAUD_115200);

ftStatus=FT_SetDataCharacteristics(ftHandle,
FT_BITS_8,
FT_STOP_BITS_1,
FT_PARITY_NONE);

ftStatus=FT_ClrDtr(ftHandle);
ftStatus=FT_SetDtr(ftHandle);

Also there are functions to setup the port in Windows style:

FT_W32_GetCommState(),FT_W32_SetCommState(),FT_W32_SetupComm(), etc.

Reading and Writing

Usage of FT_W32_WriteFile() and FT_W32_ReadFile() functions is similar to WriteFile() and ReadFile(). If the handle is opened in OVERLAPPED mode, the functions are asynchronous, otherwise they are synchronous. So reading and writing can be made in standard way:

DWORD Written=0;
unsigned char cmd[]={'A','T','\r','\n'};
ftStatus=FT_W32_WriteFile(ftHandle,cmd,sizeof(cmd),&Written,&Ovl);
if (WaitForSingleObject(Ovl.hEvent,INFINITE)!=WAIT_OBJECT_0)
throw std::exception("Error waiting write to complete");
unsigned char Buf[250];
ftStatus=FT_W32_ReadFile(ftHandle,Buf,sizeof(Buf),&TotalRead,&Ovl);
if (WaitForSingleObject(Ovl.hEvent,1000)!=WAIT_OBJECT_0)
throw std::exception("Error waiting read operation");

EEPROM programming

There are also APIs that allow to program FTDI chip. FTDI chip has EEPROM within it. EEPROM contains the chip settings block and the user area block. It’s possible to read and write both of these blocks.

Warning! Programming EEPROM is dangerous operation. Writing the invalid data may cause improper work of the device. You are doing it at your own risk.

APIs

The APIs to manage user area block:

FT_EE_UASize()
Gets the size of User Area.

FT_EE_UAWrite()
Write data to User Area.

FT_EE_UARead()
Read User Area Data

Reading the area is quite simple:

DWORD UASize=0;
FT_EE_UASize(ftHandle,&UASize);

UCHAR * pUAData=new UCHAR[UASize];
DWORD SizeRead=0;
ftStatus=FT_EE_UARead(ftHandle,pUAData,UASize,&SizeRead);

The APIs to manage whole EEPROM:

FT_EE_Program()
Writes to EEPROM special structure (FT_PROGRAM_DATA), which contains chip settings

FT_EE_ProgramEx()
Writes to EEPROM special structure (FT_PROGRAM_DATA), which contains chip settings, but the USB String descriptors are passed separately from FT_PROGRAM_DATA structure

FT_WriteEE()
Writes data to EEPROM directly.

FT_EE_Read()
Reads FT_PROGRAM_DATA structure from EEPROM data.

FT_EE_ReadEx()
Reads FT_PROGRAM_DATA structure from EEPROM data and USB String descriptors are passed separately

FT_ReadEE()
Reads EEPROM data directly

FT_EraseEE()
Erases EEPROM contents

Dumping EEPROM

Dumping EEPROM is a bit tricky, because some chips have the internal EEPROM, and some may have external one.

Quote:

The FT2232C supports 93C46 (64 x 16 bit), 93C56 (128 x 16 bit), and 93C66 (256 x 16 bit) EEPROMs.

So there can be various sizes.

Here’s the example of EEPROM dumping for 64 x 16 bit:

WORD EEPromData[0x40]={0};
DWORD Offset=0;
while (Offset < (sizeof(EEPromData) / sizeof (WORD)) )
{
WORD DataChunk=0;
ftStatus=FT_ReadEE(ftHandle,Offset,&EEPromData[Offset]);
if (ftStatus!=FT_OK)
break;
Offset++;
}

Here’s a second trick. If you look at the function declaration for FT_ReadEE:

FTD2XX_API
FT_STATUS WINAPI FT_ReadEE(
FT_HANDLE ftHandle,
DWORD dwWordOffset,
LPWORD lpwValue
);

dwWordOffset argument is actually index of the word value in EEPROM, not the offset in the meaning of “data offset”.

Data in the settings block

The settings block contains VID and PID of USB device, so if it’s changed, the device will be treated like some other device. Default values of VID and PID for FTDI chip are 0x0403 and 0x6001 accordingly, but these values are overwritten by the device manufacturers.

The settings block contains the product description strings (USB String descriptors): Manufacturer, Manufacturer ID and Description. Also there’s device serial number, which can be changed by EEPROM programming.

Warning one more time! Changing the EEPROM setting may also cause the software failures if the invalid data is written to EEPROM.

Download sample source code for FTDI interaction.

Links

The information about FTDI chips can be found in Data Sheets part of FTDI official site:
http://www.ftdichip.com/Documents/DataSheets.htm

Additional information about API can be found in FTD2XX Programming Manual:
http://www.ftdichip.com/Documents/ProgramGuides/D2XXPG34.pdf

Driver Package:
http://www.ftdichip.com/Drivers/D2XX.htm

About the Author:

Apriorit is an Ukrainian software development company.

Apriorit develops its own products as well as provide offshore development and QA services in the areas of advanced system programming, driver development, software for devices.

One of the key values of Apriorit's specialists is knowledge generation and sharing of experience.

Learn more about Apriorit and its experience at Apriorit Official site

Article Source: ArticlesBase.com - Interaction with FTDI chip

7 Steps to Make RS232 ExpressCard Download Flash to 218X

Author: jackdrogba

Step One: Install CCS2.2 and check your RS232 Interface

To ensure that your source code can be compiled to Download Source: xxx.out file.

Step two: Install Serial Programming Algorithm project file: sdf28xx_v3_0_serial more information, please read the included: SDFlash_Serial_RefGuide_v3_0.pdf and Expresscard RS232.pdf files.

Step Three: In the algorithm set up the project file, the corresponding clock frequency, and generates. 1 SDFLASH 1.63 download, serial download support. 2 SDFLASH algorithm libraries

(1) In the CC file to import F2812SerialFlash.pjt

File directory: C: \ CCStudio_v3.1 \ specdig \ sdflash \ mydrivers \ DSP281x_v3_0 \ DSP281x_serial \ build \ F28xxSerialFlash

(2) set up your target board clock frequency of the corresponding

The Flash280x_API_Config.h the corresponding PLL clock, I use the 20M crystal Chun chose: define CPU_RATE 10.000L / / for a 100MHz CPU clock speed (SYSCLKOUT) (3) Save and compile the project file, generate F2812SerialFlash.out file stored in: C: \ CCStudio_v3.1 \ specdig \ sdflash \ mydrivers \ DSP281x_v3_0 \ DSP281x_serial \ bin

Note: Make sure your flash program space defined in paragraph (in the CMD file changes). IF there is no RS232 Inteface,just install a RS232 Expresscard serial port adapter.

Step four: Install SdFlashV1.60 or later

Fifth Step: Edit sdopts.cfg file that is stored in your installation of windows of the System32 directory

(1) Use Notepad to open the way sdopts.cfg.

(2) "# End of sdopts.cfg" before adding the following text:

[EmulatorId = C1]

EmuPortAddr = 0xC1

EmuPortMode = RS232

EmuProductName = SERIAL_FLASH

[EmulatorId = C2]

EmuPortAddr = 0xC2

EmuPortMode = RS232

EmuProductName = SERIAL_FLASH

[EmulatorId = C3]

EmuPortAddr = 0xC3

EmuPortMode = RS232

EmuProductName = SERIAL_FLASH

[EmulatorId = C4]

EmuPortAddr = 0xC4

EmuPortMode = RS232

EmuProductName = SERIAL_FLASH

Step six: Open SDFlash, according to the methods provided by SDFlash_Serial_RefGuide_v3_0.pdf specify a file path algorithm

In the Project settings, if you chose to use the PC emulator of COM1 for the C1, COM2 select the C2

Seventh Step: The DSP-SCI_A and PC-RS232 port/Expresscard RS232 connection. Will be as follows DSP-foot tube set to the corresponding level, and then reset

Reset time: GPIOF4 = 0 GPIOF12 = 0 GPIOF3 = 1 GPIOF2 = 1

Note: GPIOf4 for SCI_A TXD terminal, reset should be restored after the completion of the original DSP is able to carry the signal state

Step seven: Click SdFlash menu Flash items --- "Click Start, you can!!!. Check your RS232 or Expresscard 34 RS232 Serial Port can work normally!

About the Author:

jackdrogba is interested in computer technology..

Article Source: ArticlesBase.com - 7 Steps to Make RS232 ExpressCard Download Flash to 218X

CAN BUS MESSAGE FRAMES - Overload Frame,Interframe Space

An overload frame, shown in Figure 2-5, has the same
format as an active error frame. An overload frame,
however, can only be generated during an interframe
space. In this way, an overload frame can be differentiated
from an error frame (an error frame is sent during
the transmission of a message). The overload frame
consists of two fields: an overload flag followed by an
overload delimiter. The overload flag consists of six
dominant bits followed by overload flags generated by
other nodes (and, as for an active error flag, giving a
maximum of twelve dominant bits). The overload
delimiter consists of eight recessive bits. An overload
frame can be generated by a node as a result of two
conditions:
1. The node detects a dominant bit during the
interframe space, an illegal condition.
Exception: The dominant bit is detected during
the third bit of IFS. In this case, the receivers will
interpret this as a SOF.
2. Due to internal conditions, the node is not yet
able to begin reception of the next message. A
node may generate a maximum of two
sequential overload frames to delay the start of
the next message.

CAN BUS MESSAGE FRAMES - Interframe Space

The interframe space separates a preceding frame (of
any type) from a subsequent data or remote frame.
The interframe space is composed of at least three
recessive bits called the Intermission. This allows
nodes time for internal processing before the start of
the next message frame. After the intermission, the
bus line remains in the recessive state (bus idle) until
the next transmission starts.

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

CAN BUS MESSAGE FRAMES - Error Frame

An error frame is generated by any node that detects a
bus error. An error frame, shown in Figure 2-4, consists
of two fields: an error flag field followed by an error
delimiter field. There are two types of error flag fields.
The type of error flag field sent depends upon the error
status of the node that detects and generates the error
flag field.

2.4.1 ACTIVE ERRORS
If an error-active node detects a bus error, the node
interrupts transmission of the current message by
generating an active error flag. The active error flag is
composed of six consecutive dominant bits. This bit
sequence actively violates the bit-stuffing rule. All other
stations recognize the resulting bit-stuffing error and, in
turn, generate error frames themselves, called error
echo flags.

The error flag field, therefore, consists of between six
and twelve consecutive dominant bits (generated by
one or more nodes). The error delimiter field (eight
recessive bits) completes the error frame. Upon
completion of the error frame, bus activity returns to
normal and the interrupted node attempts to resend the
aborted message.

2.4.2 PASSIVE ERRORS
If an error-passive node detects a bus error, the node
transmits an error-passive flag followed by the error
delimiter field. The error-passive flag consists of six
consecutive recessive bits. The error frame for an errorpassive
node consists of 14 recessive bits. From this it
follows that, unless the bus error is detected by an erroractive
node or the transmitting node, the message will
continue transmission because the error-passive flag
does not interfere with the bus.

If the transmitting node generates an error-passive flag,
it will cause other nodes to generate error frames due
to the resulting bit-stuffing violation. After transmission
of an error frame, an error-passive node must wait for
six consecutive recessive bits on the bus before
attempting to rejoin bus communications.
The error delimiter consists of eight recessive bits and
allows the bus nodes to restart bus communications
cleanly after an error has occurred.

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

CAN BUS MESSAGE FRAMES - Remote Frame

Normally, data transmission is performed on an
autonomous basis by the data source node (e.g., a
sensor sending out a data frame). It is possible,
however, for a destination node to request data from
the source. To accomplish this, the destination node
sends a remote frame with an identifier that matches
the identifier of the required data frame. The
appropriate data source node will then send a data
frame in response to the remote frame request.
There are two differences between a remote frame
(shown in Figure 2-3) and a data frame. First, the RTR
bit is at the recessive state and, second, there is no
data field. In the event of a data frame and a remote
frame with the same identifier being transmitted at the
same time, the data frame wins arbitration due to the
dominant RTR bit following the identifier. In this way,
the node that transmitted the remote frame receives
the desired data immediately.

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

CAN BUS MESSAGE FRAMES - Extended Data Frame

In the extended CAN data frame, shown in Figure 2-2,
the SOF bit is followed by the arbitration field, which
consists of 32 bits. The first 11 bits are the Most
Significant bits (MSb) (Base-lD) of the 29-bit identifier.
These 11 bits are followed by the Substitute Remote
Request (SRR) bit, which is defined to be recessive.
The SRR bit is followed by the lDE bit, which is
recessive to denote an extended CAN frame.
It should be noted that if arbitration remains unresolved
after transmission of the first 11 bits of the identifier,
and one of the nodes involved in the arbitration is
sending a standard CAN frame (11-bit identifier), the
standard CAN frame will win arbitration due to the
assertion of a dominant lDE bit. Also, the SRR bit in an
extended CAN frame must be recessive to allow the
assertion of a dominant RTR bit by a node that is
sending a standard CAN remote frame.
The SRR and lDE bits are followed by the remaining
18 bits of the identifier (Extended lD) and the remote
transmission request bit.
To enable standard and extended frames to be sent
across a shared network, the 29-bit extended message
identifier is split into 11-bit (most significant) and 18-bit
(least significant) sections. This split ensures that the
lDE bit can remain at the same bit position in both the
standard and extended frames.
Following the arbitration field is the six-bit control field.
The first two bits of this field are reserved and must be
dominant. The remaining four bits of the control field
are the DLC, which specifies the number of data bytes
contained in the message.
The remaining portion of the frame (data field, CRC
field, acknowledge field, end-of-frame and intermission)
is constructed in the same way as a standard data
frame

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf

CAN BUS MESSAGE FRAMES - Standard Data Frame

Standard Data Frame


The CAN standard data frame is shown in Figure 2-1.
As with all other frames, the frame begins with a Start-
Of-Frame (SOF) bit, which is of the dominant state and
allows hard synchronization of all nodes.
The SOF is followed by the arbitration field, consisting
of 12 bits: the 11-bit identifier and the Remote
Transmission Request (RTR) bit. The RTR bit is used
to distinguish a data frame (RTR bit dominant) from a
remote frame (RTR bit recessive).
Following the arbitration field is the control field,
consisting of six bits. The first bit of this field is the
Identifier Extension (IDE) bit, which must be dominant
to specify a standard frame. The following bit, Reserved
Bit Zero (RB0), is reserved and is defined as a dominant
bit by the CAN protocol. The remaining four bits of the
control field are the Data Length Code (DLC), which
specifies the number of bytes of data (0 – 8 bytes)
contained in the message.
After the control field is the data field, which contains
any data bytes that are being sent, and is of the length
defined by the DLC (0 – 8 bytes).
The Cyclic Redundancy Check (CRC) field follows the
data field and is used to detect transmission errors. The
CRC field consists of a 15-bit CRC sequence, followed
by the recessive CRC Delimiter bit.
The final field is the two-bit Acknowledge (ACK) field.
During the ACK Slot bit, the transmitting node sends
out a recessive bit. Any node that has received an
error-free frame acknowledges the correct reception of
the frame by sending back a dominant bit (regardless
of whether the node is configured to accept that
specific message or not). The recessive acknowledge
delimiter completes the acknowledge field and may not
be overwritten by a dominant bit.

http://ww1.microchip.com/downloads/en/DeviceDoc/21801d.pdf