The First Dutch ISOBlue!


That’s a good question!

In Can we legally publish code implementing ISO-11783? I’m trying to dissect the reason for the lack of a public/open parameter transformation list as we believe that the only scalable way of proceeding with this is to have people collaborate on the translation/transformation work.

It seems that everybody who is working with machine data has a list of parameter transformations. I wonder what the reason is for the absence of a public one: is it legal or are people reluctant to share out of worry to lose the tremendous amount of time in creating the list (which is as good a reason to not share as any).


@wang701 It will also/already be useful to know how you go about decoding the messages. What does your proces look like?


Hello Simeon and derk,

I mostly use our Excel sheet and create parsers in python manually. It is quite tedious and not automated. One place you can take a look to get you started is our group’s isobus-parser-js. It is different from the parsers I am using now but it provides a decent code structure to get started if you have the PGN definitions.

Another place you can look is pysobus. It has some PGN definitions but from my experience they are not really accurate and then the library didn’t work last time I installed the library.


Hi Auke,
we use a different brand of tractor, Massey Ferguson. I would be very interested finding out if that works too!
Very welcome to our Farm. ( close to Derk)


For inspecting the data, try using a linux editor ( LF in stead of CR/LF)
A good one is Notepad++


Hi Yang,

Thanks for explaining your process!

In thinking about what would be the best move forward to “decoding” some of the usefull PGN’s, some questions came to mind. Mostly, what would be the right standard part to buy to start off.

First, what are we looking for? During the hackaton these came up as the most relevant:

  • Motor RPM
  • Hitchresistance
  • Fuel usage (this one is likely proprietary?)
  • Hitch angle/height
  • Speed (can also be done by gps?)

The sheet you pointed to (J1939 Digital Annex) actually seems to be automotive oriented, as you probably know. I have read somewhere that quite a few of the common PGN’s were copied to the ISO 11783 standard as each engine has a RPM etc. From your comments I understand that this file contains at least a few of the definitions we need to convert the messages. Is this correct? (from your own experiences of working with the sheet?) Would we be better of buying this sheet instead of one of the ISO 11783 parts?

Regarding the ISO 11783, you pointed to part 3.
Am I correct to understand that this part also contains definitions like you have in the J1939 sheet?
Or is that a different part, perhaps part 7 or 8?

In studying what PGN’s and SPN’s are, another question came up.
On the ISOBUS Website I found a data dictionary.
I noticed there are definitions for the same PGN with a different SPN. Does that mean we need both the PGN and SPN to match a similar signal to its previous occurence?

Wikipedia seems to suggest something similar: PGN’s and SPN’s


Perhaps this coud be interesting?:

“ISOAgLib contains the full amount of standard functions related to electronic communication in mobile machinery according to the norm ISO 11783”.

They (from OSB engineering & IT) also offer services to parties who want to work with ISOBus data:


Hi All,

For the latest progress on the data-decoding, please see the TrekkerHack 2018 thread (Dutch)

Challenge 4: Trekkerdata over bodemverdichting

Hi all, just a quick update! Next stop in the development phase is our participation in the National Soil Hack. Going into the hackathon: data we logged with @derk and @Pieter last week. What will come out is a surprise, we still have 16 hrs to go untill jury time :man_technologist::man_dancing:

The hackathon team is working hard on data visualisation. They are looking at visualisation of moving tractor, playing datapoints one after other, and include layers of height, NDVI, fuel. Some hickups with matching different time stamps.

Team: Madhu Srinivasa, Justin Steenhuis, @Auke, @Roel, Mark de Leeuw en Thijs Adegeest (ASR) & Martijn Richtering (ASR)

And a sneak preview under the hood:


Succes daar. Ik zie dat er daadwerkelijk data uit de Case trekker is gekomen. Hebben jullie ook data uit de MF van Pieter gekregen?
groeten, Derk Gesink


Here’s a short demo of what we came up with


@derk Here’s a plot of the hitch resistance that @auke and @roel shared in another topic [1].

As you can see the resistance has a value of -150 kN at rest. Do you (or @Pieter) know why this is the case? Is it a measurement/decoding error, faulty standard implementation or does it actually make sense?

[1] Challenge 4: Trekkerdata over bodemverdichting


Hi everybody,

concerning the negative value of Draft : it can be very well possible that, as well positive, as negative values exist.
This can be explained as draft in the reverse direction of the vehicle ( negative draft) and in the forward direction of the vehicle ( positive) . This is possible by the design of the 3 point hitch, in wich the upper-link and the lower links can take forces in both pull and push direction, this resulting in negative and positive forces in the lower links, in wich the draft-sensors are mounted.
As a example, imagine a long implement ( e.g. a plow), this will give in the lifted position a pull force in the uppper link and a push force in the lower links.

Have a nice day, and like Derk, very curious for the data of the Massey Ferguson.



Hoi Derk en Pieter,

Goede vraag, ik ging er ondertussen vanuit dat er geen data uit de Massey Ferguson was gekomen omdat ik nog niks was tegen gekomen na het decoden. Zojuist de ruwe data aandachtiger bekeken en er is wel degelijk informatie uit gekomen. De volgende PGN’s staan erin:

  • 60160 Transport Protocol - Data Transfer
  • 60416 Transport Protocol - Connection Mgmt
  • 65408 Proprietary B
  • 65520 Proprietary B
  • 65521 Proprietary B
  • 65522 Proprietary B
  • 65523 Proprietary B

Niet iets waar wij wat mee kunnen op dit moment helaas en daardoor ook niet opgevallen, deze waarden decoderen wij niet…


Thanks @Pieter for the great explanation. I had a hunch that negative values might be correct, it’s good to know that that is the case.


Daar zit ém nu net de uitdaging om deze codes te reverse-engineren !
En misschien voor nog meer merken /types.

De meeste aandacht gaat natuurlijk naar hef-weerstand , brandstof verbruik enz…
die PGN’s zou je eerst moeten vinden en decoderen!

Misschien zitten de standaard motor-codes in een ander CAN netwerk op de trekker ( dat van de motor) ?


Interesting article about tractor can data.
There is a really interesting subset of data available on almost all !! tractors.


Hi all! check out this start up: - received some serious funding money!


But also! Check out this amazing video by @Marijn - we totally :blue_heart: it! Looking forward to 2019, we have some serious plans! more soon



Bij nader inzicht/overleg met Aaron Ault lijkt het er wel op dat er iets te doen moet zijn met PGN 60160, hiervan zijn ook standaards beschikbaar. Het is wel zo dat de communicatie in deze PGN als het goed is onderlinge communicatie betreft tussen de systemen op de trekker (het zijn geen status updates) Dus het is even de vraag hoeveel zinnige informatie (voor analyse) er in die specifieke PGN zit. Momenteel ligt de focus even op de “Open PGN’s”.