Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/08/2021 in all areas

  1. Are Italian LV developers more prone to producing spaghetti code? 🤨
    1 point
  2. Hi Shaun I would have been interested but have only just seen your post. Albert Lederer developed a dll wrapper suite that is available from this link: https://forums.ni.com/t5/Example-Code/Using-RTL-SDR-with-Labview-Chapter-1-Labview-on-Windows/ta-p/3538774?profile.language=en Works very well and I have developed an FM radio using his code and the Nooelec NESDR Mini device. Hope this is useful to you. Best regards Deon
    1 point
  3. Something is surely off here: You say that the checksum is in the 7th byte and the count in the 8th. But aside that it is pretty stupid to add the count of the message at the end (very hard to parse a binary message if you don't know the length, but you only know that length if you read exactly the right amount of data), those 70 71, 73 and so on bytes definitely have nothing to do with the count of bytes in your message. Besides what checksum are you really dealing with? A typical CAN frame uses a 15 bit CRC checksum. This is what the SAE_J1850 fills in on its own and you can't even modify when using that chip. It would seem that what you are dealing with is a very device specific encoding. There could be a CRC in there of course, but that is totally independent of the normal CAN CRC. As far as the pure CAN protocol is concerned, your 8 bytes of the message are the pure data load, and there is some extra CAN framing around those 8 bytes, that you usually never will see on the application level. As such adding an 8 bit CRC to the data message is likely a misjudgement from the device manufacturer. It adds basically nothing to the already performed 15 bit CRC checking that the CAN protocol does itself one protocol layer lower.
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.