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

Fast Packets that are a single frame in length are not parsed as fast packets and thus use the first two bytes as PGN data #161

Closed
nmbath opened this issue Jul 29, 2021 · 5 comments

Comments

@nmbath
Copy link
Contributor

nmbath commented Jul 29, 2021

It would seem that within fromPGN.js and the _parse function the logic for processing fast packets that are a single frame and therefore less than 6 bytes in length is wrong.

Within canboat the definition for PGN127507 is incorrect, it is defined as a single, when it is ineffective a fast. Having modified pgns.json to make it a fast, candumpanalyzerjs still will not process the PGN correctly. It processes it as a single.

I have done some analysis and it seems to be within the _parse function. There are what looks like historic if statements commented out related to " pgnData.Type === 'Fast' "

canboat/canboat#243

@nmbath nmbath changed the title Fast Packets that are a single frame in length. Fast Packets that are a single frame in length are not parsed as fast packets and thus use the first two bytes as PGN data Jul 29, 2021
@nmbath
Copy link
Contributor Author

nmbath commented Jul 30, 2021

Test Can message....

can0 19F21381 [8] A0 06 71 00 08 FC FF FF

When I process PGN127507 with a correct definition:

    "PGN":127507,
    "Id":"chargerStatus",
    "Description":"Charger Status",
    "Type":"Fast",
    "Complete":true,
    "Length":6,
    "RepeatingFields":0,
    "Fields":[

I get

{"canId":435295105,"prio":6,"src":129,"dst":255,"pgn":127507,"timestamp":"2021-07-30T16:52:20.318Z","fields":{"Instance":160,"Battery Instance":6,"Operating State":"Bulk","Charge Mode":7,"Charger Enabled":"Off","Equalization Pending":"Off","Reserved1":"0","Equalization Time Remaining":64520},"description":"Charger Status"}

if I push the Length out to 9, I get a correct output...

{"canId":435295105,"prio":6,"src":129,"dst":255,"pgn":127507,"timestamp":"2021-07-30T16:48:59.722Z","input":[],"fields":{"Instance":113,"Battery Instance":0,"Operating State":"Disabled","Charge Mode":"Standalone mode","Charger Enabled":"Off"},"description":"Charger Status"}

A further example to show that there is an issue is this Actisense decode

@anhorbc
Copy link

anhorbc commented Oct 16, 2021

Any updates on this? I really wish for this to be fixed.

@sbender9
Copy link
Member

@nmbath this is fixed, right?

@nmbath
Copy link
Contributor Author

nmbath commented Feb 24, 2022

Yes I believe so. If further issues arise we can always re-open or create a new issue. Happy for it to be closed.

@sbender9
Copy link
Member

Fix published today in 1.22.0

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