I need someone to clarify my doubt from a practical point of view regarding the number of messages needed for the given requirements.

(hypothesis) In a vehicle, headlights can be turned on or off using buttons, and the temperature and humidity values will be displayed on a display installed in the car.

System consists of 4 nodes:

1. First Node: Here, there are 2 switch buttons to control two headlights.
2. Second Node: There are 4 switch buttons to open/close the 4 doors of the vehicle.
3. Third Node: This node monitors the temperature and humidity inside the vehicle.
4. Fourth Node: This node displays the temperature and humidity data.

Question : How many messages are required for the entire system ?

1. First Node:
   • It requires two messages to control the headlights (one to turn on and another to turn off).
   • So, two messages are needed for the first node.
2. Second Node:
   • It receives commands to control the doors but doesn't need to transmit any messages.
   • No messages are needed for the second node.
3. Third Node:
   • It requires one message to transmit the temperature and humidity data.
   • So, one message is needed for the third node.
4. Fourth Node:
   1. It receives the temperature and humidity data from the third node, so it doesn't need to send any messages.

Therefore, a total of three messages are required for the entire system to fulfill the given requirements

Thank you for your help! @Papabravo

You made no provision for a node to transmit messages to control the doors.
You can use a single message for the first node. There is no reason to use two.
This simplistic method of architecting a system would have to be redone each time a new set of requirements comes along. This approach is deeply flawed. You should study how existing systems put together an adaptable general framework that is suited to multiple unique systems. This might include methods for nodes to document themselves.

I think you should consider the proposition that you need to study more and talk less.

 

No, I understand the concept of multi-master configuration.

OK… well your “confusion” is very confusing…

But I'm struggling to understand what "multi-master" really means. Does it mean that many nodes can talk to each other, but not at the same time? Or is there something else to it?

 

You made no provision for a node to transmit messages to control the doors.
You can use a single message for the first node. There is no reason to use two.
This simplistic method of architecting a system would have to be redone each time a new set of requirements comes along. This approach is deeply flawed. You should study how existing systems put together an adaptable general framework that is suited to multiple unique systems. This might include methods for nodes to document themselves.

I think you should consider the proposition that you need to study more and talk less.

Perhaps my approach may be wrong, but I felt that it might be better to tackle a small problem by first finding a solution to a smaller problem. That's why I created a hypothetical situation and provided a solution that I believed would be correct, and sought feedback.

You made no provision for a node to transmit messages to control the doors.
You can use a single message for the first node. There is no reason to use two.

You're correct; my apologize

In the single message for controlling the headlights from the first node, we could include information about the state of both headlights.

Here's format for the message:

Message ID: Unique identifier for the message (e.g., 0x100)
Data length: 1 byte (as only two headlights need to be controlled)
Data:
Bit 0: State of the first headlight (0 for off, 1 for on)
Bit 1: State of the second headlight (0 for off, 1 for on)

With this format, each bit in the data field represents the state of one headlight.

For example:

• To turn on both headlights, the message data could be: 0b00000011
• To turn off both headlights, the message data could be: 0b00000000
• To turn on the first headlight and keep the second one off, the message data could be: 0b00000001

This format allows us to control both headlights using a single message from the first node.

 

In the specifications, I see that there are different types of message frames such as Data frame, Remote frame, and Error frame. The use of a Data frame is clear to me as it is used to transmit data from one node to another. However, I am not understanding the use of other frames like Remote frame and Error frame because even a Data frame itself contains a CRC field which can detect errors. Why use error frame?

Is the use of a Remote frame done when a node needs to receive data from another node?

So, I am confused about when and why the other frames, Remote frame and Error frame, are used?

@Papabravo

 

In the specifications, I see that there are different types of message frames such as Data frame, Remote frame, and Error frame. The use of a Data frame is clear to me as it is used to transmit data from one node to another. However, I am not understanding the use of other frames like Remote frame and Error frame because even a Data frame itself contains a CRC field which can detect errors. Why use error frame?

Is the use of a Remote frame done when a node needs to receive data from another node?

So, I am confused about when and why the other frames, Remote frame and Error frame, are used?

@Papabravo

If you had bothered to read what I wrote in earlier posts and the specification you would understand that an ERROR frame is used by EVERY node on the network whenever any error is detected. It consists of 7 dominant bits. That's it, full stop. After every node has thrown it's ERROR frame, the bus returns to the recessive state ready for the next transmission attempt. It may be the node that caused the error or any other node.

The RTR message is used in some protocols that sit on top of CAN and ignored in others. From what I have gathered it is used with a zero length data field to request data from a node which is only a producer. That does not make a great deal of sense to me because you can do the same thing with a regular data frame. But hey, I had no hand in writing the original specification; I just took it and ran with it.

Our decision in DeviceNet to ignore the use of REMOTE frames was consistent with the position that, by design, the set of message identifiers that nodes were allowed to transmit must be DISJOINT. In other words, each node must have a unique set of identifiers that it can use to transmit. This will prevent multiple nodes from attempting to transmit the same identifier. This is designed to prevent arbitration clashes.

 

it is used with a zero length data field to request data from a node which is only a producer

So my understanding of the remote frame was correct: When one node sends a Remote Transmission Request (RTR) message to another node, it's like sending a message saying, "Hey, can you please send me some data?" The node receiving this request is expected to respond by sending the requested data back to the sender. So, when we say "the receiving node is expected to respond with the requested data," it means that node should send the data that was asked for in the RTR message.

 

So my understanding of the remote frame was correct: When one node sends a Remote Transmission Request (RTR) message to another node, it's like sending a message saying, "Hey, can you please send me some data?" The node receiving this request is expected to respond by sending the requested data back to the sender. So, when we say "the receiving node is expected to respond with the requested data," it means that node should send the data that was asked for in the RTR message.

Almost. The key feature of the RTR message is that the receiving device MUST use the same identical identifier that was used by the transmitting device for the response, but with the RTR bit turned off. The RTR bit is part of the arbitration field which means that when the RTR bit is dominant, that message will have higher priority. We deemed the benefit of this feature to be so limited that it was not worth worrying about. Looking at transactions on the bus with an analyzer it is helpful to have the source address in the identifier field.

 

If you had bothered to read what I wrote in earlier posts and the specification you would understand that an ERROR frame is used by EVERY node on the network whenever any error is detected. It consists of 7 dominant bits. That's it, full stop. After every node has thrown it's ERROR frame, the bus returns to the recessive state ready for the next transmission attempt. It may be the node that caused the error or any other node.

Thank you, understood In the CAN protocol, any node on the network can detect an error during communication, including the sender node, receiver node. When an error is detected, the node that identified the error sends out an ERROR frame to notify all other nodes on the network about the issue.

The purpose of the ERROR frame is to notify all other nodes on the network that an error occurred and to take appropriate action, such as ignoring the corrupted message.

 

Thank you, understood In the CAN protocol, any node on the network can detect an error during communication, including the sender node, receiver node. When an error is detected, the node that identified the error sends out an ERROR frame to notify all other nodes on the network about the issue.

The purpose of the ERROR frame is to notify all other nodes on the network that an error occurred and to take appropriate action, such as ignoring the corrupted message.

The ERROR frame itself will trigger a response from all the other nodes on the network because 7 consecutive dominant bits is a STUFFING Error The protocol allows only 5 consecutive bits of the same value before a stuff bit of the opposite polarity must be inserted and removed by ALL other nodes on the network.

 

The protocol allows only 5 consecutive bits of the same value before a stuff bit of the opposite polarity must be inserted and removed by ALL other nodes on the network

I'd like to verify my understanding of the different message frames in CAN protocol and ensure I've presented the correct information.

Below are examples of standard, extended, and remote frames:

Standard Frame:

SOF | Identifier | RTR | IDE | Reserved (r0) | DLC | Data | CRC | ACK | DEL | EOF
-----------------------------------------------------------------------------------
 0  | 0011001100 |  0  |  0  |         0     |  4  | 1A2B | CRC |  0  |  0  |  1

Extended Frame:

SOF | Extended Identifier | RTR | IDE | Reserved (r0) | DLC | Data | CRC | ACK | DEL | EOF
-------------------------------------------------------------------------------------------
 0  | 1111111111111111110 |  0  |  1  |         0     |  8  | 1A2B3C4D | CRC |  0  |  0  |  1

Remote Frame:

SOF | Identifier | RTR | IDE | Reserved (r0) | DLC | ACK | DEL | EOF
--------------------------------------------------------------------
 0  | 0011001100 |  1  |  0  |         0     |  4  |  0  |  0  |  1

I would appreciate it if you could verify my understanding and let me know if there are any inaccuracies.

@Papabravo

Thank you for your help!

 

Your extended frame is wrong. It shows a single 19-bit identifier field. In the actual protocol the 29-bit identifier is split into two parts of 11-bits and 18-bits. Like this from Part B, p.44:

 

Your extended frame is wrong. It shows a single 19-bit identifier field. In the actual protocol the 29-bit identifier is split into two parts of 11-bits and 18-bits. Like this from Part B, p.44:

Thank you for pointing out the error.

Here's the corrected extended frame:

SOF | Identifier (A) | RTR | IDE | Identifier (B) | Reserved (r1, r0) | DLC | Data | CRC | ACK | DEL | EOF
---------------------------------------------------------------------------------------------------------------
 0  | 11111111111    |  0  |  1  |  111111111111111111      |    00    |  8  | 1A2B3C4D | CRC |  0  |  0  |  1

In this corrected frame:

• Extended Identifier (A) represents the first 11 bits of the extended identifier.
• Extended Identifier (B) represents the remaining 18 bits of the extended identifier.
• The least significant bit is ID-18, transmitted first, and the most significant bit is ID-28.
• The reserved bits (r0 and r1) are set to 0.
• Other fields remain consistent with the CAN frame structure.

Thank you for your guidance

 

Thank you for pointing out the error.

Here's the corrected extended frame:

SOF | Identifier (A) | RTR | IDE | Identifier (B) | Reserved (r1, r0) | DLC | Data | CRC | ACK | DEL | EOF
---------------------------------------------------------------------------------------------------------------
0  | 11111111111    |  0  |  1  |  111111111111111111      |    00    |  8  | 1A2B3C4D | CRC |  0  |  0  |  1

In this corrected frame:

• Extended Identifier (A) represents the first 11 bits of the extended identifier.
• Extended Identifier (B) represents the remaining 18 bits of the extended identifier.
• The least significant bit is ID-18, transmitted first, and the most significant bit is ID-28.
• The reserved bits (r0 and r1) are set to 0.
• Other fields remain consistent with the CAN frame structure.

Thank you for your guidance

It is still wrong. In the Extended frame the bit following the 11-bit identifier field is SRR. The description from the specification is:

The actual RTR bit in the extended frame follows the 18-bit part of the identifier and precedes the two recessive reserved bits.

When it comes to specifications you seem to have a problem accurately assimilating what they actually say. You might want to start rereading them multiple times as a double or triple check on your understanding.

 

When it comes to specifications you seem to have a problem accurately assimilating what they actually say. You might want to start rereading them multiple times as a double or triple check on your understanding.

Thank you for your patience

SOF | Extended Identifier (A) | SRR | IDE | Extended Identifier (B) | RTR | Reserved (r1, r0) | DLC | Data | CRC | ACK | DEL | EOF
----------------------------------------------------------------------------------------------------------------------------------
 0  |       11111111111       |  0  |  1  |    111111111111111111   |  0  |        00         |  8  | 1A2B3C4D | CRC |  0  |  0  |  1

 

When it comes to specifications you seem to have a problem accurately assimilating what they actually say. You might want to start rereading them multiple times as a double or triple check on your understanding.

I've looked the J1939 frame format multiple time , but I'm struggling to grasp the concept of its 29-bit extended CAN identifier, PGN (18 bits), and the Source Address (8 bits).

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial#what-is-j1939

 

Thank you for your patience

SOF | Extended Identifier (A) | SRR | IDE | Extended Identifier (B) | RTR | Reserved (r1, r0) | DLC | Data | CRC | ACK | DEL | EOF
----------------------------------------------------------------------------------------------------------------------------------
0  |       11111111111       |  0  |  1  |    111111111111111111   |  0  |        00         |  8  | 1A2B3C4D | CRC |  0  |  0  |  1

That looks better

I've looked the J1939 frame format multiple time , but I'm struggling to grasp the concept of its 29-bit extended CAN identifier, PGN (18 bits), and the Source Address (8 bits).

https://www.csselectronics.com/pages/j1939-explained-simple-intro-tutorial#what-is-j1939

OK. I don't know why you might be struggling. CAN does NOT specify how the bits in a frame are supposed to be used. J1939 does specify this by showing how to map one set of bits onto another. In particular it says:

Specifically, the 29 bit CAN ID comprises the Priority (3 bits), the J1939 PGN (18 bits) and the Source Address (8 bits). In turn, the PGN can be split into the Reserved Bit (1 bit), Data Page (1 bit), PDU format (8 bit) and PDU Specific (8 bit).​

​

Please tell me that you can read and understand that sentence. If not, there is very little hope for you to make further progress.

The upper three bits are under control of the producer of the message. This allows the producer to raise the priority of a message by setting all 3 bits to 0's which go on the bus as dominant bits. The source address will be a fixed number assigned to the device at power up by some unspecified method. The address could com from DIP switches or be programmed into non-volatile memory. J1939 does not care how this is done.

Double checking: 3+18+8 = 29 bits, so the entire identifier is accounted for.

 

Please tell me that you can read and understand that sentence. If not, there is very little hope for you to make further progress.

I understand that the 29-bit extended ID structure in J1939 contains Priority (3 bits), Parameter Group Number (PGN) (18 bits), and Source Address (SA) (8 bits).

The PGN can be further divided into the Reserved Bit (1 bit), Data Page (1 bit), PDU Format (8 bits), and PDU Specific (8 bits).

Priority levels, ranging from 0 to 7, signify the urgency or importance of messages. Lower values denote higher priority; for instance, a priority of 0 represents the highest urgency, while 7 indicates the lowest.

However, I'm unclear about how the source address of the sender is determined. Is it typically a fixed, predefined address assigned to a specific node, or can it be assigned dynamically or configured based ?

 

I understand that the 29-bit extended ID structure in J1939 contains Priority (3 bits), Parameter Group Number (PGN) (18 bits), and Source Address (SA) (8 bits).

The PGN can be further divided into the Reserved Bit (1 bit), Data Page (1 bit), PDU Format (8 bits), and PDU Specific (8 bits).

Priority levels, ranging from 0 to 7, signify the urgency or importance of messages. Lower values denote higher priority; for instance, a priority of 0 represents the highest urgency, while 7 indicates the lowest.

However, I'm unclear about how the source address of the sender is determined. Is it typically a fixed, predefined address assigned to a specific node, or can it be assigned dynamically or configured based ?

I addressed the source address issue in my previous post:

The source address will be a fixed number assigned to the device at power up by some unspecified method. The address could come from DIP switches or be programmed into non-volatile memory. J1939 does not care how this is done.​

​

Since J1939 does not care how it is done you are free to implement any method your heart desires. Whatever plan you have I recommend you follow the principle that prevents multiple nodes from transmitting identical identifiers. I'm not aware of any network that allows for the possibility of duplicate source addresses. That would be madness. I further recommend that duplicate source address detection be part of your implementation.

 

Could you please explain how bit stuffing works in the context of CAN?

I understand that it involves inserting extra bits into the data stream, but I'm not entirely clear on why this is necessary and how it helps ensure reliable data transmission.

Could you provide some clarification on this concept, perhaps with a hypothetical example to illustrate its application in practice?

For instance, imagine we have a CAN frame with an identifier of 0x123 and data to transmit. How would bit stuffing be applied to this frame, and how does it contribute to maintaining synchronization, error detection, and overall data integrity? @Papabravo

 

CAN, as you are no doubt aware, is a synchronous protocol without an explicit clock signal from the transmitter that the receiver can use. The transmitter and the receiver must use independent clocks that are not synchronized. In order for this to work the clocks must be close to each other in frequency so that over a sequence of bits the accumulating difference between the transmit clock and the receive clock does not get large enough to move the sample point in each bit cell into the next bit. One thing that makes this process more difficult is long strings of one bits or zero bits. To avoid long strings of bits with a single polarity the stuff bit is inserted to allow the receiver to determine where the bit boundaries are so that it can correct the location of the sample point.

The same thing would happen on an RS-232 link where the characters are transmitted at the synchronous limit. In other words, the START bit of the next character occurs at the end of the STOP bit for the proceeding character. It is not an accident that the START and STOP bits have opposite polarities or that odd parity with a 7-bit character would limit the maximum run length to 7 bits. I don't know if you have ever tried to RUN an RS-232 link at speed over 250 K bits per second, but it can be a challenge. Just for reference, the sample point for UARTS is normally in the middle of a bit cell and most UARTS don't have the SJW mechanism that is a part of CAN.