+11
Completed

JFIN multi-packet for PGN:s with > 8 bytes of data

Gustav Widén (System support) 2 years ago in IQANdesign updated 4 months ago 5

In IQAN, we have had the feature for reading of DM1 for ages, and DM2 reading since version 3, but reading other PGN:s that are sent as J1939 multi-packet is more tricky.

I come across more and more applications with requests for reading other PGN:s with > 8 bytes.


With a bit of knowlege and time, it is possible for an IQANdesign user to implement reading of BAM and TP.DT using JFIN channels, but it comes at the expense of overriding the DM1/DM2 reading features. 


With a more integrated feature for J1939 multi packet, using e.g. a JFIN with length > 8 byte, requests such as these could be solved more easily:
https://forum.iqan.se/communities/1/topics/102-jfin-longer-than-8-bytes
https://forum.iqan.se/communities/1/topics/1120-engine-serial-number
https://forum.iqan.se/communities/1/topics/1257-j1939-data-length



With version 5.02  we added two features for outgoing multi-packet (DM1 and text), now might be a good time to develop incoming multi-packet further?  

 

I would also suggest supporting GFIN channels with > 8 bytes.  I have a situation where i need to combine 11-bit and J1939 identifiers on the same bus, and therefore, i need to have all my J1939 messages set up as generic CAN messages.  In addition, i have another application where the source address of the J1939 device is dynamic, and therefore i have defined it as a Generic CAN device and the full 29-bit identifier is calculated so that the correct source address is used.

I can only foresee this kind of feature would have to be J1939 specific; implementing a more general way of handling J1939 TP.CM and TP.DT behind the scenes, and providing the PGN and parameters on the application level. 


With GFIN:s, one would be stuck with existing way of reading multi-packet by building it all up in the application, too much work for most applications. 


For the cases you write about, I think that a different feature ideas would be more interesting, like this about mixing generic and J1939, and this relatively new one about dynamic source address.

+1

Yes I have a J1939 use case for this : PGN 64920. This CAN packet contains historical engine aftertreatment information and can be up to 40 bytes long.