Replies: 4 comments 5 replies
-
|
There are known issues (which are caused on Deere's end) with how they deal with the two transport protocols. They incorrectly handle their clear to send message for some reason. One thing you can try is setting the number of packets per EDPO message to the maximum that Deere supports, and the max number of frames per CTS.
You would need to set these very early in the program, before you start the CAN stack. In old versions of the stack we always set those to 255, but that's against the suggestions in ISO 11783, so we don't do it by default any more. |
Beta Was this translation helpful? Give feedback.
-
Hello Adrian, I've got a couple of ISOBUS implements from different manufacturers but only Deere terminals to connect them to... I can record some CAN traces if that helps... |
Beta Was this translation helpful? Give feedback.
-
|
Since we can see the sequence fails at the Like so (line 166 in version3_object_pool example): - virtualTerminalClient->set_object_pool(0, testPool.data(), testPool.size(), objectPoolHash);
+ virtualTerminalClient->set_object_pool(0, testPool.data(), testPool.size());That should stop it trying to store the pool on the terminal. If that doesn't make a difference, it would really help to get a candump/canlog capturing this issue :) |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I managed to solve the problem; I’m implementing it on an ESP32 using the PlatformIO example. First, I added the following lines before loading the driver: isobus::CANNetworkManager::CANNetwork.get_configuration().set_number_of_packets_per_dpo_message(255); Then, I replaced the line: virtualTerminalClient->set_object_pool(0, testPool, (object_pool_end - object_pool_start) - 1, "ais1"); with: virtualTerminalClient->set_object_pool(0, testPool, (object_pool_end - object_pool_start) - 1) |
Beta Was this translation helpful? Give feedback.
-
|
I'm curious which of the two steps are necessary. Can you remove one and have it still work? We'd like to narrow it down so we can try to fix the underlying issue. Thanks in advance |
Beta Was this translation helpful? Give feedback.
-
|
You must add all the lines, add the first two and change the next line. |
Beta Was this translation helpful? Give feedback.
-
|
It would still be nice to see why they are refusing to save the object pool... if at some point you are able to get a CAN trace of it, that could help us and others using the project. If you don't have the means to capture that I understand as well. |
Beta Was this translation helpful? Give feedback.
-
|
I have to build an Arduino that I have to capture packets and the responses can be observed. |
Beta Was this translation helpful? Give feedback.
-
Here's a can trace recorded using Please let me know if I can help with further information. |
Beta Was this translation helpful? Give feedback.
-
I tried to run the version3_object_pool and the seeder example (and others) against some of my Deere terminals (GS 2630, 4600 Command Center) and found that more recent revisions of AgIsoStack++, like 6de17ef (from November 24), appear to have problems uploading the object pool, whereas an older revision, like c0e392e (from August 23), works fine.
Here's some debug output of the more recent VT3 example program failing:
Seeder:
As compared to the old VT3 example (that works just fine):
Or the seeder example from last year, which also works (apart from the DDOP issue, which is due to an invalid reference and doesn't matter here):
The code has changed a lot since last year, so I'm hoping for your help to find the exact change that leads to that problem.
I've tried this on Linux (amd64 and aarch64) with gcc 12.2.0 and different CAN-Adapters (USBtin and MCP2518fd via SPI on a Raspberry PI 4b).
Beta Was this translation helpful? Give feedback.
All reactions