Does J1939 standard require ECU to transmit binary one's for unused signals in a J1939 message?

[jani12]

Does J1939 standard require that sending node transmit binary one's for unused signals in a J1939 message?

For example, please consider following 8-byte external steering request (XSR) message broadcasted by camera ECU. This message is detailed in J1939 Digital Annex (DA).

Some system doesn't use the yellow highlighted signal above. Therefore, this signal is omitted from the definition of XSR message in the CAN Database (DBC file).
Does J1939 standard state that yellow highlighted signal is to transmitted as ones? If yes, which standard states that?

 

[Papabravo]

If the message is broadcast by the camera ECU and there is no node on the network that implements that XSR message then I would not expect ANY response from any "sending node". I certainly would not expect a "meaningless message" of all 1's. That would be of no use whatsoever.

 

[jani12]

Steering ECU implements the XSR message. Please assume that Torque Request signal is completely omitted from the DBC files. Does J1939 standard specify value to be transmitted for unused Torque Request signal by the camera ECU?

 

[rjenkinsgb]

The OP does not mean the whole message, just one field in it that has no data source, so is unused.

I'd expect it to be all zeros? Most unused diagnostic values are zero, if anything is returned.

 

[jani12]

>> I'd expect it to be all zeros?
OK. This means there is no SAE J1939 requirement that unused data is to be transmitted with a certain value, like all binary one's.

 

[Papabravo]

>> I'd expect it to be all zeros?
OK. This means there is no SAE J1939 requirement that unused data is to be transmitted with a certain value, like all binary one's.

I don't think that conclusion can be drawn from what rjenkinsgb said. An expectation just means that as far as any of us know the J1939 and related documents do not have an explicit position on the matter. I am not aware of anything that speaks to your issue and the J1939 standard is voluminous. You might better ask the manufacturers of the devices how thy deal with data fields that are not implemented.

If it is possible to instrument an actual installation that might be a good way of establishing an anecdotal answer. It may not be the complete story, but it would be a data point. At least it would represent someone who has taken a position on the matter.

ETA: If anyone finds a definitive answer, I'd be interested in hearing about it.

 

[Diver300]

On passenger car CAN signals, the default is all zeros if there is no signal in that part of the message.

While the content of the unused part of the frame is largely irrelevant, the choice of all zeros seems to be the worst in two ways, although neither is significant.

Firstly, 0 is dominant, so it's take more power to transmit. I know it's not much, as an 8-byte frame full of zeros transmitted at 500 kbaud and repeated every 20 ms is only about 0.5 mW, but it could be avoided.

Secondly, the CAN stuffing bits mean that if all the bits are the same, the data part has one stuffing bit for each 5 data bits, making the data part of the CAN frame take longer to transmit by about 16% compared to data that keeps changing.

 

[jani12]

Unused signals in our J1939 modules are sent as all 1s, so if a signal is not supported and is 8 bits it is expected to be 0xFF. I'm trying to find out if this is specified in SAE J1939 standard or not.

 

[Papabravo]

Some observations:

1. J1939 is a standard used primarily for trucks and busses. I'm not sure of its usage level in passenger cars; I've been out of the business for a decade plus.
2. All 1's has the same problem with stuff bits, so that is just as bad as all 0's.
3. Power consumption of a transceiver is flyspecks in the pepper considering that there are no nodes that are transmitting continuously on CAN networks, and there is almost certainly some amount of deadtime on any practical CAN network.
4. It is too bad the developers did not reserve some encoding for "invalid data" or "data not available". This would be analogous to NaN for floating point numbers.

NaN - Wikipedia

en.wikipedia.org

 

[Papabravo]

Unused signals in our J1939 modules are sent as all 1s, so if a signal is not supported and is 8 bits it is expected to be 0xFF. I'm trying to find out if this is specified in SAE J1939 standard or not.

Is it possible to identify the individual who made that decision originally. He must have had a reason for that choice. It would be good to know that.

Question: What would be the difference between "signal not supported" and data with a value of "-1", aka 0xFFFF? Maybe this data item can only assume positive values. That would work.

 

[rjenkinsgb]

If an invalid number value was needed for signed values, 0x8000 could be used; -32768

The highest positive value in a 16 bit signed variable is 32767, so it still allows the maximum symmetrical range.

 

[Papabravo]

If an invalid number value was needed for signed values, 0x8000 could be used; -32768

The highest positive value in a 16 bit signed variable is 32767, so it still allows the maximum symmetrical range.

Certainly not an unreasonable proposition.

 

[Diver300]

In a lot of vehicle CAN signals, negative numbers are handled using a scale factor and an offset. This means that the hexadecimal numbers representing a physical value of zero are often in the middle of the range.

For example, acceleration, scaled to read +/- 40.96 m/s2 with a 16 bit number would have a scale of .00125 m/s2 and an offset of -40.96 m/s2

Mid range is 0x8000 which is 32768. Apply the scale factor to get 40.96 m/s2 and add the offset of -40.96 m/s2 to get zero acceleration.

 

[Papabravo]

This happens whenever a committee gets together to hash out a specification or standard. There is something about every proposal that somebody does not like. We used to call it the "Ugly Baby Proposal Syndrome". A guy would stand up tell us why his baby was the most beautiful baby ever. Another guy would then say: "Sit down and be quiet, because your baby is butt ugly". That's why it takes forever to do some things.

 

[NoobyMarty]

This happens whenever a committee gets together

Sorry to be off topic....My Dad used to say to me as a kid " a Camel Is just a Horse that was drawn by a committee".
sorry for the interruption, it's just your comment brought back memories from long long ago

 

[jani12]

The answer to question in OP is as follows:
Yes it’s the presentation layer convention in SAE J1939-71