Section Control On Esp32

[SpiceFormDune]

Hello, I’m trying to implement the SC features on my generic ESP32 board. The VT and TC connect to the server (on my tractor) correctly. SC even starts working because I can see that my tractor sends PGN messages through the UART debug, and I can observe the setpoint value when I enter a zone where the sections should be off.

However, I don’t receive any messages when the sections should be on. I even performed a CAN trace, identified the ID that sends the DDI commands, and verified the correct message when the sections should be off. But when the sections should be on, it’s not working.

What could be the issue? Could it be something related to the DDOP settings during the TC setup?

I used the Seeder And TC client example from stack just a little changes for ESP32

[ad3154]

Can you please include a CAN trace? We'll need to see the DDOP upload and the subsequent commands to get a full picture of what's happening.

It's probably something simple, like the section control or prescription control state being 0....

[SpiceFormDune]

First of all, thank you so much for taking the time to respond, especially during the New Year. You've done an excellent job with this stack—it’s truly impressive!

I included the file containing the CAN trace and checked the ID where the DDIs appear, which is 0x0CCB80F7. After starting the trace, I initiate the task and enter and exit the area where the sections are supposed to run twice.

When checking the Setpoint DDI ID, I noticed that the Setpoint DDI only comes when exiting the area, but no value is observed upon entering. I debugged this using a printf statement I added to the value callback, and the value output in the terminal is -65536. This indicates that the desired value for 8 sections (the target count) has its bits zeroed out when converted to binary. As I mentioned, I only get this value when the sections are supposed to be off.

case static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SetpointCondensedWorkState241_256):
{
   std::uint16_t sectionIndexOffset = NUMBER_SECTIONS_PER_CONDENSED_MESSAGE * (DDI - static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SetpointCondensedWorkState1_16));
   printf("PROCESS VAL : %ld\n", processVariableValue);
   for (std::uint_fast8_t i = 0; i < NUMBER_SECTIONS_PER_CONDENSED_MESSAGE; i++)
   {
       sim->set_section_state(sectionIndexOffset + i, (0x01 == (processVariableValue >> (2 * i) & 0x03)));
   }
}

---

Additionally, I also checked the SectionControl DDI, and its value is as expected: 1.

The issue I suspect, though I’m not completely sure, is that the TC server might always consider the unit states to be on, and it only sends the command when they go off. However, I can’t get any request commands to report this to TC. It might be something missing during the initialization of DDOP or TC. I used the example code provided with the stack, but could this be related to the ESP32?

I also tried another Seeder example and faced issues with std::vector<> variables returning incorrect sizes. For instance, no matter which unit count I set, it always returned 16. I'm not entirely sure if this is related to the issue.
canout.txt

[SpiceFormDune]

I am still having the same problem. Has anyone successfully gotten the section control feature to work in the field?

[GwnDaan]

Hi there, I have been able to successfully use section control with the stack last summer in the field.

But I think your suspicion is correct. I also see your TC only sending the SetpointCondensedWorkState1_16 with 8 sections to off. I'm wondering whether #486 fixes your issue. Note that there is still one comment open.

Are you able to provide more information about your setup? I.e. which tractor are you using and which version TC does it have? Also exact codebase you're running on the ESP32 would be useful to have. And lastly the logs that the canstack outputs to CANStackLogger tells a lot

[SpiceFormDune]

Hi,

My tractor is NH T7.300, and it can use both TC versions. I tested the SC feature on both versions and I have been using SC machines from other manufacturers without error , but now with ESP32 the issue remains the same.

Additionally, I followed your recommendation and switched to the specified branch using PlatformIO:

lib_deps = https://github.com/Open-Agriculture/AgIsoStack-plus-plus.git#adrian/tc-default-process-data

However, the problem still persists.

This is how I initialize the TC. The create_ddop function here is identical to the one in the stack example:

void init_tc_client(std::shared_ptr<isobus::InternalControlFunction> InternalECU, std::shared_ptr<isobus::PartneredControlFunction> PartnerVT){

		const isobus::NAMEFilter filterTaskController(isobus::NAME::NAMEParameters::FunctionCode, static_cast<std::uint8_t>(isobus::NAME::Function::TaskController));
		const isobus::NAMEFilter filterTaskControllerInstance(isobus::NAME::NAMEParameters::FunctionInstance, 0);
		const isobus::NAMEFilter filterTaskControllerIndustryGroup(isobus::NAME::NAMEParameters::IndustryGroup, static_cast<std::uint8_t>(isobus::NAME::IndustryGroup::AgriculturalAndForestryEquipment));
		const isobus::NAMEFilter filterTaskControllerDeviceClass(isobus::NAME::NAMEParameters::DeviceClass, static_cast<std::uint8_t>(isobus::NAME::DeviceClass::NonSpecific));
		const std::vector<isobus::NAMEFilter> tcNameFilters = { filterTaskController,
													  filterTaskControllerInstance,
													  filterTaskControllerIndustryGroup,
													  filterTaskControllerDeviceClass };

		auto PartnerTC = isobus::CANNetworkManager::CANNetwork.create_partnered_control_function(0, tcNameFilters);

		TCClientInterface = std::make_shared<isobus::TaskControllerClient>(PartnerTC, InternalECU, PartnerVT);
		
		ddop = std::make_shared<isobus::DeviceDescriptorObjectPool>(3);

		mySC = std::make_shared<SectionControl>();

		uint8_t sectionCount = 8;

		mySC->set_number_of_sections(sectionCount);

		tractorSpeedMessages = std::make_shared<SpeedMessagesInterface>(InternalECU, false, false, false, false);

		tractorSpeedMessages->initialize();
		tractorSpeedMessages->get_machine_selected_speed_data_event_publisher().add_listener(handle_machine_selected_speed);
		tractorSpeedMessages->get_ground_based_machine_speed_data_event_publisher().add_listener(handle_ground_selected_speed);
		tractorSpeedMessages->get_wheel_based_machine_speed_data_event_publisher().add_listener(handle_wheel_selected_speed);

		if (mySC->create_ddop(ddop, TCClientInterface->get_internal_control_function()->get_NAME()))
		{
				TCClientInterface->configure(ddop, 1, sectionCount, 1, true, false, true, false, true);
				TCClientInterface->add_request_value_callback(SectionControl::request_value_command_callback, &mySC);
				TCClientInterface->add_default_process_data_requested_callback(SectionControl::default_process_data_request_callback, &mySC);
				TCClientInterface->add_value_command_callback(SectionControl::value_command_callback, &mySC);
				TCClientInterface->initialize(true);
		}
		else
		{
				printf("Failed generating DDOP. TC functionality will not work until the DDOP structure is fixed.\n");
		}
}

I also tried both DDOP functions from the seeder and TC client examples, but the issue persists.

Here are the logs:

W (353181) AgIsoStack: [Warn][PR]: NACK-ing PGN request for PGN 64834 because no callback could handle it.
I (353261) AgIsoStack: [Info][NM]: Control function with address 240 and NAME a000860078a0007b is now offline on channel 0.
I (353621) AgIsoStack: [Info][NM]: External CF 'a000860078a0007b' is evicted from address '254' on channel '0', as their address is probably stolen.
I (353991) AgIsoStack: [Info][NM]: External control function with name a000860078a0007b has claimed address 240 on channel 0.
I (354081) AgIsoStack: [Info][VT]: VT Server has a matching label for dks2   . It will be loaded and upload will be skipped.
I (354121) AgIsoStack: [Info][VT]: Loaded object pool version from VT non-volatile memory with no errors.
I (359871) AgIsoStack: [Info][TC]: Task controller structure labels do not match. DDOP will be deleted and reuploaded.
I (360311) AgIsoStack: [Info][TC]: DDOP Activated without error.
W (364731) AgIsoStack: [Warn][TC]: TC sent us a PDNACK
P VAL = -65536

The P VAL is just my printf debug to see changes on point state but its still giving me only off signals
I hope these helps!

[SpiceFormDune]

Hello,

I recently had the opportunity to test the ESP-based device on another TC device. This device was an autosteering system with TC-SC and UT functionality (Not an original tractor ISOBUS). My ESP-based device worked perfectly with this system, which was very exciting for me.

Afterward, I back to my own tractor (New Holland) to test it there. As before, the device didn’t work.

---

Here’s the issue I noticed:
The TC correctly receives all the equipment-related data (e.g., implement and section lengths), and the sections are in auto mode and open (the first message it sends is on). However, the tractor does not paint the map while moving, even though the equipment is attached and operating.

Interestingly, this tractor has previously worked with an existing SC device available on the market. While using that SC device, the tractor successfully painted the map while in motion. However, I couldn’t make the ESP-based device achieve the same functionality and now im thinking this is the couse of the problem. I also checked the tractor’s settings thoroughly, and everything seems normal, so the issue doesn’t appear to originate from the tractor itself.

Another observation:
I traced my tractor's TC with esp32uart, I see the following message exactly once:
AgIsoStack: [Warn][TC]: TC sent us a PDNACK

But when I traced the auto-steering device (which doesn’t seem to be a fully mature product yet), I receive this message periodically, approximately once per second.

I’m not sure if this is related to the issue, but I wanted to update the problem description in case it helps.

---

Additionally, I tested a popular SC device on my tractor and observed that it worked properly. When I checked the settings via the device’s diagnostics and DDI tree, all the properties seem almost identical to those of my ESP-based device.

[GwnDaan]

Hey @SpiceFormDune, sorry for the delay. Reading through the details you provided, I'm still not sure what the issue can be.

One thing that you can try is adding the following line to your ddop creator:

AgIsoStack-plus-plus/examples/seeder_example/section_control_implement_sim.cpp

Line 188 in 89bf4ab

sprayer->add_reference_to_child_object(static_cast<std::uint16_t>(ImplementDDOPObjectIDs::SetpointWorkState));

That line I think is missing from the seeder example, and I'm addressing it in: #535

Hope this helps... Otherwise it would be helpful if you can share the create_ddop function as that is where most of the magic happens.

EDIT: perhaps there is something in this document that might provide a clue? ISO11783-11-DDI-290-SetpointWorkState-v1.pdf

[Flodu81]

@SpiceFormDune Hello, I would like to make an ISOBUS system with an ESP32. Would you be willing to share your work? Thank you.