I had to clean 10 years worth of cement and soil off my 936 one to see it as the tractor had been owned by a ground stabilisation company! 
Finally had time to test it yersterday. Works like expected.
PGN 0xEF00 is manufacturer specific. Can anybody provide information/documentation about the command and status packets?
Iām guessing there may be messages referring to the autosteer on and off button on the V-Bus as well as the K-BUS given its steer related.
What are people using for can message sniffing? Arduino and adapter or something direct to a laptop with Busmaster or something?
Dont think so, afaik there is only a button pressed/released message on KBUS. Wasnt able to find anything on VBUS either.
Linux with cantact/canable clone and wireshark or python-scripts.
Hello, I found this information from f4f (forum4farming) site. For MF 7480 and 7485, I have MF 5455 and they use the same socket, can I use the can-bus outputs and steer like you? (Iām using google translate sorry)
1 - 12V
2 - ground
8 - implement working position
14 - CAN-H
16 - CAN-L
No ground speed though.!
On the 7485 youād have:
1 - 12V
2 - ground
4
8 - implement working position
9 - engine / Radar programmable frequency output
10 - PTO / forward speed programmable frequency output
12
13
14 - CAN-H
16 - CAN-L
No information / documentation here, the factory programmers are too cool to talk to us.
All i know is the tractor computers are just a men at a desk with draws full of notes, we will never know what is on those notes. Over years of experience maybe reading the odd book here and there we can guess what those notes say.
All I know because one day I seen the steering controller man get that message and he turned the wheels, so we have to make up what we think the message means and reverse engineer it building practical documents as we go.
So in the world of Fendt and the curve command message, my best total guess so far is:
- 0xEF00 is PGN manufacturer specific (so they make there own rules up)
- 2C is a ID of a navigation controller (maybe it dosnāt have to be 2C tho?)
- F0 is the ID of the main tractor ECU (this has a gateway to every CAN network in the tractor)
- The steering controller man is sitting inside the main tractor ECU
- So the note ID: 0xEFF02C broken down is
EF - Make your own rules
F0 - Note for Main ECU / steering man
2C - Note from navigation man
Data [0] - 0x05 = Message is curve command
Data [1] - 0x09 = Message is curve command
Data [2] - 00000010,BIN = not intended to steer. 00000011,BIN = intended to steer.
Data [3] - 0x0A = ? To be worked out
Data [4] - Set curve range -127 to +127, DEC
Data [5] - Im sure this can be anything and used by navigation man to sum check I think.
I have got a heap more ideas to try and share, more BNOās and GPS parts have arrived so ill set AgOpen up for some real field testing.
7 Likes
You need steering switch in cab like this
Unfortunately there is no such switch in the cabin. 
I guess I wonāt be able to take advantage of the can-bus output. Thank you for your interest.
Hello, I have the switch in the cabin, and this connector where you can place a Topcon x25 or higher (x30), which are the CanBus pins, since there are 2 green and 2 yellow.
Someone would have the pinout, I canāt find anything in the tractor manual.
I leave a photo.
WAS= 1-white,2-Red, 3-Black
Valve= 1-Green,2-Black/Red, 3-Black, 4-Yellow
When your CAN shields arrive you can get it working for sure. Not sure if the correct CAN wires are in that plug but we can test it by just looking what CAN messages are there on each set of wires. There will be more plugs under the covers.
Your Danfoss wires are direct from the Danfoss book:
White = WAS Signal, Red = WAS 5volt, Black = WAS GND.
Green = CAN-L, Black/Red = +12volt from steering switch, Black = GND, Yellow = CAN-H.
2 Likes
Hello,
Very nice topic and projet. I started reading it late, lot of stuff to to catch up and learn, but very nice topic, build with a progressiv way. Congratulation for you job @CommonRail !
I also discover that you use my BNO08x INO, itās always a pleasure to see that his work is useful to others.
I know CAN bus, but not SAEJ1930 standart and ISO 11783 (ISOBUS) protocol standard. So I read a lot of document in the same time I read the post to understand the protocol and what is done here.
So I share documentation I use, it will perhaps help other beginner like me:
Danfoss PVED-CL documentation, page 33 a description of PGN44288:
I also make a representation of a CAN Extanded trame to uderstand how the data are organized and how is implemented PGN in the CAN arbitration field (32bits) and with PGN4432 of the project one in exemple:
Iāhavenāt finish to read all the post, but I have a first question.
According to CAN2.0B standart and SAEJ1930, CAN Identification field is 29bits (identifier 1 + identifier 2). So max value of ID field would be 1FFF FFFF (hex).
But when I look on ID field of pictures or video of @CommonRail, the ID value are using more than 29bits.
By example, picture of serial monitor of projet 1, ID is 98AC131C (hex): so 32 bitsā¦ Donāt understand ?
I also found this āCAN ID to J1939 PGN converterā, and itāseems like they also consider in some case a CAN ID field with 32 bits:
By exemple, ligne 16 of the sheet, they use a CAN ID of 98FEF4FE (hex), so also 32 bits. And from this CAN ID, the converter said:
- BCD āCAN IDā Ext. ID (3 bits) = 4 ā donāt know what is this field ?
- Priority (3 bits) = 6
- PGN (18 bits) = 65268
- Source adress (8 bits) = 254
So if I convert 98FEF4FE (hex) into bits, and place it into my previous table, I found this:
98FE F4FE (hex) = 1001 1000 1111 1110 1111 0100 1111 1110 (bin)
Itās look like if SRE, IDE and RTR bits of the Arbitration field are used as MSB (in which order ?) as extender bits to extand the 29 bits CAN ID field into a 32 bits CAN ID field ? Perhaps itās explain the designation āBCD CAN ID Ext IDā of 3 bits.
With this hypothesis, I found exactly the same value than the converter for Priority, PGN and Source adresse.
But I found any documentation that explain it ? Or Am I completely wrong ? Someone can confirm ? And if yes, it mean that MPC2515 read the Arbitration Field like this ?
If Iām wrong, how in capture / video the ID could have a value of 98AC131C (hex), that required 32 bits ?
Thank for your answer, Iām going to finish to read this very interesting topic !
Math
1 Like
Hereās the decode function I use in my own CAN arduino code:
void j1939Decode(long ID, unsigned long* PGN, byte* priority, byte* src_addr, byte *dest_addr)
{
/* decode j1939 fields from 29-bit CAN id */
*src_addr = 255;
*dest_addr = 255;
*priority = (int)((ID & 0x1C000000) >> 26);
*PGN = ID & 0x00FFFF00;
*PGN = *PGN >> 8;
ID = ID & 0x000000FF;
*src_addr = (int)ID;
/* decode dest_addr if a peer to peer message */
if( (*PGN > 0 && *PGN <= 0xEFFF) ||
(*PGN > 0x10000 && *PGN <= 0x1EFFF) ) {
*dest_addr = (int)(*PGN & 0xFF);
*PGN = *PGN & 0x01FF00;
}
}
Iāve never worried about the top 3 bits. The CAN libraries just give back a 32-bit number for the id, of which only the least significant 29 bits mean anything useful. In general I donāt worry about the wire protocol either. Thatās for the CAN chipset and network to figure out. Itās likely those top 3 bits are filled by the transceiver based on the wire protocol representation of the data. And since the higher level code ignores those bits anyway it wouldnāt need to worry about masking them out. Different chipsets may do it differently. I guess my point its, it probably is the arbitration field, but thatās just an implementation detail of the chipset.
By the way, the spreadsheet does not show the destination address thatās part of the PGN. A destination of 255 signifies a broadcast, as opposed to a message aimed at a specific j1939 address. Most j1939 messages Iāve seen are broadcasts.
1 Like
Hi, that is very interesting i think it explains where the 32 bits come from nicely. I have never tried to work that out. I did notice when you send a message you donāt have any control / cant change any of those 3 bits at the start.
@Math you are in the category of people that like to understandā¦ Me too!
Can in latest version (2) is using 29 bit identifier
(11 (as original V1 + 18) packeted in a Word of 32 bit
(Cannot be different: digital works in 8, 16, 32, 64 bit)
So 3 bit extra one of them should be to tell if we are using extended 29 bit identifierā¦
Dont think we should count SOF Start of Fileā¦
(Seems your are doing so in your second drawing?
True @torriem it is the job for MCP2515
But Digital is really fascinating!
Hello,
Yes I like to understand too !
Agree CAN 2.0B has an arbitration field compose of
- 29 bit for CAN ID (subdivided on 3 bits of priority bit, 18 bits of PGN and 8 bits of source adress)
- 1 SSR bit
- 1 IDE bit
- 1 RTR bit
So as CAN ID is 29 bits, max value of CAN ID should be 1FFF FFFF. But on CommonRail picture / video we see ID with lenght of 32 bits (like 0x98AC131C in picture of projet one).
So what are this 3 additionnal bits in CAN ID ?
No in my second picture, I didnāt count SOF. I just make hypothesis that SSR, IDE and RTR bits are used as MSB for extand CAN ID to 32 bits.
But I think Iām totaly wrong, considering what I read here:
āThe RTR bit (remote request bit) is always set to zero in J1939.ā
āSRR, and IDE bits are defined by the CAN standard and will be ignored here.ā
And on wiki about CAN BUS extanded frame:
"SRR = Must be recessive (1) "
āIDE = Must be recessive (1) for extended frame format with 29-bit identifiersā
So SSR, IDE and RTR bit are define and canāt be used for extanded CAN ID.
But @torriem and you point something interesting: 29bits CAN ID is probably transmited by MPC2515 to the host via a 32bits word. So the additionnal 3 MSB are perhaps completed by MPC2515 by befaut bits values. And when this 32bits data is received, these 3 MSB shall just be scrapt.
Certainly more information on MPC2515 datasheet, but havenāt read it for now: https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf
Math
1 Like
Ok, back to the working Fendt setups @Alan.Webb and the other Fendt fans. I have been thinking / testing a few ideas and think it should be like this picture:
Job descriptions of each man:
Navigation Man
- Say hello when you first wake up on both V-Bus and ISO-Bus.
- After hello, always talk to steering man. Tell him where you want the wheels and if you intend to steer or not.
Steering Man
- Keep the wheels where navigation man wants them, unless the encoder moves then stop steering wait for navigation man to send at least one note not intended to steer before restarting.
Switch Man
- Watch the arm rest buttons, if something moves tell someone in that department.
- For steering enable switch - if pressed organise the pilot pressure for steering man so he can turn wheels.
- For steering GO switch - if pressed tell the navigation controller (Only if he is home) that the operator wants auto steering engaged.
AGO Machine Controller
- Copy the armrest and tell switch man to organise whatever you want
Here is two examples to try on the Fendt:
K-Bus Steering switchs on the Armrest. You can easily read the switchās as Sven & Thomas have worked out for us. But this is only a button telling the switch man to do something. You can also copy those messages and tell switch man to do the same thing as @Tooki57 has worked out. So I think the K-Bus should be for the machine control Arduino and headland managment side of things.
S4_K-Bus_SteerSwitchs.ino (1.6 KB)
K-Bus Video Here
ISO-Bus Engage Steering as you will see from the above video, using K-Bus is only going to pick up the press of a physical button, not a software man generated message. So in this example we use that software man generated message to get the steering engaged and this can be from the physical button or from the Teach-In recorded program.
Fendt_ISOBUS_EngageTest.ino (2.5 KB)
ISO-Bus Video Here
3 Likes
From what i could find this might be a legacy interface related to Agco Topdock Auto-Guide.
Quick test restuls i did yesterday: (724 SCR, latest Software, VarioGuide installed)
SA needs to be 0x2C, wont connect otherwise.
didnt notice any effect with data[3] and data[5] changed to different values
will throw error when disconnected
Yea thatās about all I can work out too. Data[3] is constant (I didnāt try change it), data[4] is random / always changing so I just picked a number. I know it works on the latest Gen6 series too.
So maybe Fendt only accepts 2C navigation controller? Have you worked out what all that address claiming stuff means? That seems to be important in the Fendt world.
The error is just saying itās lost steering commands, automatically resets when you start sending them again tho. So once you start with the steer commands you canāt stop for a rest lol.
1 Like
So nav controller having two can adaptors in this setup?
Is the ISO bus connection just to allow teach in enable?
Iām hoping to test a few configurations now my BNO085ās have turned up and the 724 isnāt out. Might try direct steer point sending again, now roll will be compensated for. Just to see what happens.
My friend with the topcon setup has enable / disable issuesā¦ Watching the V-bus on that will be interesting.
Yep exactly, 2nd ISO-Bus is only for the Teach-In enable (can be separate and use relay or direct wire to steer switch too)