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

J

jani12

Member
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?
 
Sort by date Sort by votes
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.
 
Upvote 0 Downvote
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?
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
>> 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.
 
Upvote 0 Downvote
jani12 said:
>> 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.
Click to expand...
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.
 
Last edited:
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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
 
Upvote 0 Downvote
jani12 said:
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.
Click to expand...
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.
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
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.
 
Upvote 0 Downvote
You must log in or register to reply here.

Similar threads

J
  • Question
Why External Steering Request (XSR) J1939 message has checksum message within the 8-byte Data Field?
Replies
1
Views
3K
Diver300
D
J
  • Question
Please explain AIR1 J1939 message.
Replies
2
Views
3K
rjenkinsgb
J
  • Question
How to find out RAM usage in Embedded Electronic Control Unit (ECU) ?
Replies
8
Views
3K
Nigel Goodwin
J
  • Question
Why message cannot be found in CAN database (.dbc text file) ?
Replies
3
Views
4K
jani12
J
  • Question
using a RTC in SF basic
10 11 12
Replies
223
Views
23K
MrDEB
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…