Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decoding returns wrong value. #45

Closed
tylerbucher opened this issue Jan 25, 2023 · 5 comments
Closed

Decoding returns wrong value. #45

tylerbucher opened this issue Jan 25, 2023 · 5 comments

Comments

@tylerbucher
Copy link
Contributor

Describe the bug
When decoding a dbc signal like SG_ Service M : 11|4@0+ (1,0) [0|15] "" Vector__XXX and data like this payload: [3, 65, 13, 55, 255, 255, 255, 255] the expected output should be 1 not 8.

Additional context
@bit-dream BitUtils#extractBitRange when in big endian mode this function seems to move the start and end bit ranges. Not really sure whats up with that.

@tylerbucher
Copy link
Contributor Author

tylerbucher commented Jan 25, 2023

Might have an issue with dbc so triple checking first. Between SavvyCan this and my dbc file I have no clue which is doing this correct. Could definitely use a second set of eyes or insight on this.

@bit-dream
Copy link
Owner

bit-dream commented Jan 25, 2023

@agent6262 Can you possibly provide me the DBC file you are using so I can look into this? Also, could you let me know which version of the library you are using? There was a bug in the decoding function at one point, but that (should of) been fixed at this point.

When I call the extractValFromPayload function directly, with the signal parameter you have above, I get an answer of 1:

// Input parameters, in order: payload, start bit, signal length, endian, signed
let val = can.extractValFromPayload([3, 65, 13, 55, 255, 255, 255, 255],8,4,'Motorola',false)
console.log(val)

returns val = 1

extractValFromPayload makes calls to extractBitRange, and a new start bit needs to be accounted for due to the difference in the endian of the message and the fact that there is a 'sawtooth' pattern that happens between the bytes because of the bit order of LSB to MSB. extractValFromPayload is called when using the decode method.

Do you have a code snippet that I could potentially run that would reproduce the error? I have a feeling there might be something going on upstream of the extractValFromPayload function since it returns 1 for the example you gave me.

@tylerbucher
Copy link
Contributor Author

I apologize for the poor wite-up on my part was (3am my time 😅). when I run the test on my dbc file extractValFromPayload gets called like this can.extractValFromPayload([3, 65, 13, 55, 255, 255, 255, 255],11,4,'Motorola',false) not can.extractValFromPayload([3, 65, 13, 55, 255, 255, 255, 255],8,4,'Motorola',false). I am curious where / how you got to startbit 8 from 11?

I am on version 2.1.0 according to the package.json.

My DBC file (line 44)

VERSION ""


NS_ :
	NS_DESC_
	CM_
	BA_DEF_
	BA_
	VAL_
	CAT_DEF_
	CAT_
	FILTER
	BA_DEF_DEF_
	EV_DATA_
	ENVVAR_DATA_
	SGTYPE_
	SGTYPE_VAL_
	BA_DEF_SGTYPE_
	BA_SGTYPE_
	SIG_TYPE_REF_
	VAL_TABLE_
	SIG_GROUP_
	SIG_VALTYPE_
	SIGTYPE_VALTYPE_
	BO_TX_BU_
	BA_DEF_REL_
	BA_REL_
	BA_DEF_DEF_REL_
	BU_SG_REL_
	BU_EV_REL_
	BU_BO_REL_
	SG_MUL_VAL_

BS_:

BU_:

BO_ 2024 OBD2: 8 Vector__XXX
 SG_ S6base : 2|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S5base : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S1_PID_0D_VehicleSpeed m13 : 31|8@0+ (1,0) [0|255] "km/h" Vector__XXX
 SG_ S1_PID_11_ThrottlePosition m17 : 31|8@0+ (0.39216,0) [0|100] "%" Vector__XXX
 SG_ SS1 m1M : 23|8@0+ (1,0) [0|255] "" Vector__XXX
 SG_ Service M : 11|4@0+ (1,0) [0|15] "" Vector__XXX

SG_MUL_VAL_ 2024 S1_PID_0D_VehicleSpeed SS1 13-13;
SG_MUL_VAL_ 2024 S1_PID_11_ThrottlePosition SS1 17-17;
SG_MUL_VAL_ 2024 SS1 Service 1-1;

BO_ 2348875518 ExtendedMultiplexMessage: 8 Vector__XXX
 SG_ S6base : 2|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S5base : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S4base : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S6 m2 : 2|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S5 m6 : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S4 m5 : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S3 m4 : 18|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S2 m4 : 10|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S1 m0M : 2|4@1+ (1,0) [0|0] "" Vector__XXX
 SG_ S0 M : 0|2@1+ (1,0) [0|0] "" Vector__XXX



BA_DEF_ BO_  "SingleFrame" INT 0 1;
BA_DEF_ SG_  "DDI" INT 0 65535;
BA_DEF_ SG_  "SigType" ENUM  "Default","Range","RangeSigned","ASCII","Discrete","Control","ReferencePGN","DTC","StringDelimiter","StringLength","StringLengthControl";
BA_DEF_ SG_  "GenSigEVName" STRING ;
BA_DEF_ SG_  "GenSigILSupport" ENUM  "No","Yes";
BA_DEF_ SG_  "GenSigSendType" ENUM  "Cyclic","OnWrite","OnWriteWithRepetition","OnChange","OnChangeWithRepetition","IfActive","IfActiveWithRepetition","NoSigSendType";
BA_DEF_ BO_  "GenMsgFastOnStart" INT 0 100000;
BA_DEF_ SG_  "GenSigInactiveValue" INT 0 0;
BA_DEF_ BO_  "GenMsgCycleTimeFast" INT 0 3600000;
BA_DEF_ BO_  "GenMsgNrOfRepetition" INT 0 1000000;
BA_DEF_ SG_  "GenSigStartValue" INT 0 10000;
BA_DEF_ BO_  "GenMsgDelayTime" INT 0 1000;
BA_DEF_ BO_  "GenMsgILSupport" ENUM  "No","Yes";
BA_DEF_ BO_  "GenMsgStartDelayTime" INT 0 100000;
BA_DEF_ BU_  "NodeLayerModules" STRING ;
BA_DEF_ BU_  "ECU" STRING ;
BA_DEF_ BU_  "NmJ1939SystemInstance" INT 0 15;
BA_DEF_ BU_  "NmJ1939System" INT 0 127;
BA_DEF_ BU_  "NmJ1939ManufacturerCode" INT 0 2047;
BA_DEF_ BU_  "NmJ1939IndustryGroup" INT 0 7;
BA_DEF_ BU_  "NmJ1939IdentityNumber" INT 0 2097151;
BA_DEF_ BU_  "NmJ1939FunctionInstance" INT 0 7;
BA_DEF_ BU_  "NmJ1939Function" INT 0 255;
BA_DEF_ BU_  "NmJ1939ECUInstance" INT 0 3;
BA_DEF_ BU_  "NmJ1939AAC" INT 0 1;
BA_DEF_ BU_  "NmStationAddress" INT 0 255;
BA_DEF_ BO_  "GenMsgSendType" ENUM  "cyclic","NotUsed","IfActive","NotUsed","NotUsed","NotUsed","NotUsed","NotUsed","noMsgSendType";
BA_DEF_ BO_  "GenMsgRequestable" INT 0 1;
BA_DEF_ BO_  "GenMsgCycleTime" INT 0 3600000;
BA_DEF_ SG_  "SPN" INT 0 524287;
BA_DEF_  "DBName" STRING ;
BA_DEF_  "BusType" STRING ;
BA_DEF_  "ProtocolType" STRING ;
BA_DEF_ BO_  "VFrameFormat" ENUM  "StandardCAN","ExtendedCAN","reserved","J1939PG";
BA_DEF_DEF_  "SingleFrame" 1;
BA_DEF_DEF_  "DDI" 0;
BA_DEF_DEF_  "SigType" "Default";
BA_DEF_DEF_  "GenSigEVName" "Env@Nodename_@Signame";
BA_DEF_DEF_  "GenSigILSupport" "Yes";
BA_DEF_DEF_  "GenSigSendType" "NoSigSendType";
BA_DEF_DEF_  "GenMsgFastOnStart" 0;
BA_DEF_DEF_  "GenSigInactiveValue" 0;
BA_DEF_DEF_  "GenMsgCycleTimeFast" 0;
BA_DEF_DEF_  "GenMsgNrOfRepetition" 0;
BA_DEF_DEF_  "GenSigStartValue" 0;
BA_DEF_DEF_  "GenMsgDelayTime" 0;
BA_DEF_DEF_  "GenMsgILSupport" "Yes";
BA_DEF_DEF_  "GenMsgStartDelayTime" 0;
BA_DEF_DEF_  "NodeLayerModules" "";
BA_DEF_DEF_  "ECU" "";
BA_DEF_DEF_  "NmJ1939SystemInstance" 0;
BA_DEF_DEF_  "NmJ1939System" 0;
BA_DEF_DEF_  "NmJ1939ManufacturerCode" 0;
BA_DEF_DEF_  "NmJ1939IndustryGroup" 0;
BA_DEF_DEF_  "NmJ1939IdentityNumber" 0;
BA_DEF_DEF_  "NmJ1939FunctionInstance" 0;
BA_DEF_DEF_  "NmJ1939Function" 0;
BA_DEF_DEF_  "NmJ1939ECUInstance" 0;
BA_DEF_DEF_  "NmJ1939AAC" 0;
BA_DEF_DEF_  "NmStationAddress" 254;
BA_DEF_DEF_  "GenMsgSendType" "noMsgSendType";
BA_DEF_DEF_  "GenMsgRequestable" 1;
BA_DEF_DEF_  "GenMsgCycleTime" 0;
BA_DEF_DEF_  "SPN" 0;
BA_DEF_DEF_  "DBName" "";
BA_DEF_DEF_  "BusType" "CAN";
BA_DEF_DEF_  "ProtocolType" "ISO11783";
BA_DEF_DEF_  "VFrameFormat" "J1939PG";
BA_ "DBName" "ExtendedMultiplexDbc";
BA_ "VFrameFormat" BO_ 2348875518 3;

SG_MUL_VAL_ 2348875518 S6 S0 2-2;
SG_MUL_VAL_ 2348875518 S5 S1 6-6;
SG_MUL_VAL_ 2348875518 S4 S1 5-5;
SG_MUL_VAL_ 2348875518 S3 S1 4-4;
SG_MUL_VAL_ 2348875518 S2 S1 4-4;
SG_MUL_VAL_ 2348875518 S1 S0 0-0, 1-1;

My test

test('DBC_SigMulVal.dbc: Decode Multiplex signal', (done) => {
  const dbc = new Dbc();
  const fileContent = dbcReader('src/__tests__/testFiles/DBC_SigMulVal.dbc');
  const data = dbc.load(fileContent);
  const can = new Can();
  can.database = data;
  const frame = can.createFrame(2024, [3, 65, 13, 55, 255, 255, 255, 255]);
  const bndMsg = can.decode(frame);
});

@mi-hol
Copy link

mi-hol commented Oct 29, 2023

@tylerbucher did the fix work, so this issue could be closed?

@tylerbucher
Copy link
Contributor Author

The changes to fix the issue I was seeing was rolled back and not included in the PR. At this time I will close this issue, but I am unsure if this issue was actually resolved or not.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants