How to control sections of physical seeder

[oleszczyk]

Hello,

First of all - great project! This is exactly what I have been looking for since some time!

Now to the point: I am working on the simple project of GNSS+RTK device used for agriculture. So far it was just visualizing on UI current vehicle position and cultivation state. I would like to integrate it with real hardware. For example when my app senses seeder section is above already cultivated area it turns this section off.

I know a little bit about ISOBUS, I have read all your tutorials and Read The Docs pages but still have some doubts:

1. What kind of device (function) in the network should be my device? Should it be a Task Controller server or maybe there is some other more suitable function for it?
2. I read your tutorials how to send/receive messages but actually still do not understand what should I send to make my seeder (Horsch manufacturer) to disable particular section (or reduce its seeding rate). I browse www.isobus.net pages looking for some specification for that but couldn't find anything. I understand that I need to create a name filter for Seed Rate Control (industry group 2, vehicle system 4, function name 128), but to which PGN should I send a message? What should be a payload? Let's say I want to reduce section 4th to 30k seeds/ha.
3. What about any other type of messages: is there any open documentation describing particular message payload format or those details are proprietary for each manufacturer and not widely published?
4. Is there any way to "discovery" what machines are connected to the network? What should I do to detect which exactly seeder is connected: Horsch, Gaspardo, none at all?

Thank you in advance for your help!

[ad3154]

What kind of device (function) in the network should be my device? Should it be a Task Controller server or maybe there is some other more suitable function for it?

If you want to actually control the sections of an implement or change target rates, and the implement is not something you've designed yourself (such as using a Horsch implement like you mentioned), then yes, you'd have to implement a Task Controller Server, and as such the "Task Controller" function would be best.

still do not understand what should I send to make my seeder (Horsch manufacturer) to disable particular section

This is a really quite complicated topic, so our tutorials don't really cover it yet. You'll have to have a very good understanding of how DDOPs work as well. It's definitely on my to-do list to write some directions for it though... If you're implementing a task controller, then you don't actually need any filters or anything. Instead, you'd have to write a class that inherits from TaskControllerServer and implements its virtual functions. Then, based on the content of the implement's DDOP, you'd send value commands to the implement telling it to change a section's setpoint work state, or setpoint volume per area, etc. Taking a look at that TaskControllerServer would be a good start. If you implement this interface, you don't even need to know the format of the messages, as it will do almost everything for you. The example shows a super basic skeleton of how to do this.

What about any other type of messages: is there any open documentation describing particular message payload format or those details are proprietary for each manufacturer and not widely published?

This is why making a task controller would be the best way, so that all messages required are defined in the standard (and the stack can abstract the message format away). OEMs are not likely to share proprietary interfaces for these kinds of things.

Is there any way to "discovery" what machines are connected to the network? What should I do to detect which exactly seeder is connected: Horsch, Gaspardo, none at all?

Yeah, there's a few ways. The nicest way I can think of would be: after address claiming is complete (so, when your internal control function is valid), you could call get_control_functions on the CANNetworkManager to get a list of all control functions on the bus. Then, get their NAME's, and check the function, industry group, device class, and manufacturer code, to know what it does. You'd probably be most interested in these ones, which are the devices that control your seeder, sprayers, etc.

If you do implement a task controller server, you'll also need to disable the TC in whatever display you are using, and/or set its TC number to be > 1

[oleszczyk]

Thanks @ad3154 for you quick response!

Let me check if I understood you right.
So, being a TaskController is the best way of communicating with any real machinery because then we can use DDOP abstraction to control it in general (especially some rates of seeding, spraying, etc), is that right?
On the other hand using directly PGN calls with payload sent to e.g. Seed Rate Control control function is not advised because it would require some OEMs proprietary knowledge, correct?

As I understand I could use bool TaskControllerServer::send_set_value(...) function with appropriate ControlFunction and DataDescriptionIndex to do so (e.g. DataDescriptionIndex::SetpointVolumePerAreaApplicationRate).

I believe my TaskController implementation will be notified dynamically about ControlFunction's supported by connected machinery by firing its callback function TaskController::activate_object_pool(...). The question is how I will be able to get a list of supported DataDescriptionIndex'es by those ControlFunction?

If you do implement a task controller server, you'll also need to disable the TC in whatever display you are using, and/or set its TC number to be > 1

Yeah... that was another question I forgot to asked previously: what about concurrency in ISOBUS? What if there will be few TC in the bus? Would do they race or fight between each other to control connected machinery? Why setting serial number for another TC > 1 would help here?

[ad3154]

So, being a TaskController is the best way of communicating with any real machinery because then we can use DDOP abstraction to control it in general (especially some rates of seeding, spraying, etc), is that right? On the other hand using directly PGN calls with payload sent to e.g. Seed Rate Control control function is not advised because it would require some OEMs proprietary knowledge, correct?

Yeah, correct

As I understand I could use TaskControllerServer::send_set_value(...) function with appropriate ControlFunction and DataDescriptionIndex

Yes, that's right. The tricky part is that you can only set a DDI that the client included in its DDOP, and since it can have multiple instances of each DDI, the last parameter in send_set_value, the elementNumber is very important. We have the DeviceDescriptorObjectPoolHelper class to help with this. It will tell you what DDIs and elements are in the DDOP in a friendly way.

I believe my TaskController implementation will be notified dynamically about ControlFunction's supported by connected machinery by firing its callback function

Yes

The question is how I will be able to get a list of supported DataDescriptionIndex'es by those ControlFunction?

Yeah, as I mentioned above here, I suggest to use the DeviceDescriptorObjectPoolHelper to help with this once the client activates its pool. Check out this function which returns a vector of booms the implement advertises, which includes each boom's geometry and rate DDIs.

What if there will be few TC in the bus? Would do they race or fight between each other to control connected machinery? Why setting serial number for another TC > 1 would help here?

Ah it's not the serial number. The way that TCs coexist on the ISOBUS is via their "TC Number", which is the function instance of the TC. Clients will usually prefer to connect to TCs with the lowest TC Number/ function instance. There's no worry about fighting - a client will choose either one, or the other. Some clients also choose to prefer TCs with their own manufacturer number, so if changing the TC number of the other TC on the bus doesn't work, you may need to disable it. Most terminals should provide some way to do both of these things.

[oleszczyk]

OK, thanks - now I have great starting point for my work!

Please forgive my poor understanding of ISOBUS in general but I have one more question: for testing my own TC implementation with some machinery do I actually need a real tractor network (with all other components, ECUs being in the network) or I just can connect those only two nodes (my TC and seeder) to CAN? In other words: do there have to be connected any "ISOBUS manager" or "master" sitting in tractor (for managing addresses and stuff)?

You said:

Clients will usually prefer to connect to TCs with the lowest TC Number/ function instance.

How it is done in practice? I mean: do "hot-plugging" my TC do existing (running) network fires some actions immediately or my TC should be connected at the first place and just then CAN bus should be started (and all other nodes powered up)?

Also: is there in the internet published any deeper open source knowledge about ISOBUS or the only source are paid ISO standard sheets?

Thanks for your big help! If I do anything useful for sure come back to contribute to that project (maybe I could write some tutorial for something similar to what I am doing).

[ad3154]

Please forgive my poor understanding of ISOBUS in general but I have one more question: for testing my own TC implementation with some machinery do I actually need a real tractor network (with all other components, ECUs being in the network) or I just can connect those only two nodes (my TC and seeder) to CAN? In other words: do there have to be connected any "ISOBUS manager" or "master" sitting in tractor (for managing addresses and stuff)?

Some TC clients also require a VT to be online to talk to a TC, but not all of them. So it might work with just the two nodes as long as the CAN bus is "good". Some nodes have internal termination in them, so be careful, as unplugging some nodes may break the whole network if you're unlucky. If that happens, you may need to keep those devices with termination plugged in, or replace them with a terminator. So, if having just the two of them on a bus doesn't work, it could be one of those things. There's no "ISOBUS manager" or anything like that. On an ISOBUS each devices independently and deterministically constructs their own copies of the address table.

How it is done in practice? I mean: do "hot-plugging" my TC do existing (running) network fires some actions immediately or my TC should be connected at the first place and just then CAN bus should be started (and all other nodes powered up)?

You can hot-plug whatever you want generally. Connections between TCs and clients tolerate things coming online or going offline. Though, if the client is already talking to the other TC, it probably won't automatically go choose the other without disconnecting it and reconnecting it, or a key-cycle or something, assuming you changed the TC number of the other TC etc. One thing to keep in mind is that there is some delay between when a client disappears and when the TC thinks it's gone for good, so rapid unplugging and re-plugging of devices can be a bit chaotic. Good to wait a few seconds after unplugging something before plugging it or another device back in.

Also: is there in the internet published any deeper open source knowledge about ISOBUS or the only source are paid ISO standard sheets?

Well, unfortunately the ISO docs state that, except within the context of their implementation (like in our CAN Stack here), that no part of the standard may be reproduced or utilized in any way or posted on the internet without their permission. So, there's lots of stuff in our stack that comes from those docs, but presenting any of it in a way that isn't "how to use our CAN stack" isn't allowed - so I have to point you at the official paid docs if you want all the deepest details. If you really want to know all the TC stuff, you may be able to get away with only buying 11783-10, so maybe that's not too bad. Our hope with the stack has been to abstract most of the actual standard document away, so that most people don't need to worry about it.

Thanks for your big help!

You bet!

[oleszczyk]

Hello @ad3154,

I have implemented my simple Task Controller Server and connected it to the other board flashed with task_controller_client example. I have parsed received DDOP and used helper class to receive implement geometry. I have logged full received structure (see below).

Comparing with DDOP from client example code I can tell that not all DDI are included in received geometry structure. For example whole bin/tank section is missing or a part with DDI for setting Actual/Setpoint Work State 1-16 (DDI 0x00A1 and 0x0122).

Hence without looking at client code I would not be able to guess what are proper DDI to set work state (or read actual state).

My questions: Is that behavior intended? What should I do (how to parse DDOP using helper class) to receive all necessary DDIs to control implement in sufficient way? Is there any designed strategy for that or I should write such parser from scratch?

Parsed implement geometry:

[Info][main] Implement booms count: 1
[Info][main]      [Boom number: 0]
[Info][main]        Sections:  16
[Info][main]        SubBooms:  0
[Info][main]        Rates:     1
[Info][main]        X offset:  0
[Info][main]        Y offset:  0
[Info][main]        Z offset:  0
[Info][main]        Element Number: 2
[Info][main]          [Section number: 0]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -17145
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 4
[Info][main]          [Section number: 1]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -14859
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 5
[Info][main]          [Section number: 2]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -12573
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 6
[Info][main]          [Section number: 3]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -10287
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 7
[Info][main]          [Section number: 4]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -8001
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 8
[Info][main]          [Section number: 5]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -5715
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 9
[Info][main]          [Section number: 6]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -3429
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 10
[Info][main]          [Section number: 7]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  -1143
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 11
[Info][main]          [Section number: 8]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  1143
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 12
[Info][main]          [Section number: 9]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  3429
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 13
[Info][main]          [Section number: 10]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  5715
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 14
[Info][main]          [Section number: 11]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  8001
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 15
[Info][main]          [Section number: 12]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  10287
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 16
[Info][main]          [Section number: 13]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  12573
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 17
[Info][main]          [Section number: 14]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  14859
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 18
[Info][main]          [Section number: 15]
[Info][main]            Rates:     0
[Info][main]            X offset:  -20
[Info][main]            Y offset:  17145
[Info][main]            Z offset:  0
[Info][main]            Width:     2286
[Info][main]            Element Number: 19
[Info][main]          [Rate number: 0]
[Info][main]            Set Point: 1
[Info][main]            Actual:    2
[Info][main]            Default:   65535
[Info][main]            Minimum:   65535
[Info][main]            Maximum:   65535
[Info][main]            Element Number: 3

[ad3154]

Well, that helper class is just a helper. It's not meant to return literally everything in the DDOP, since you know, you already have the whole DDOP. You could iterate over the DDOP as-is to discover these DPDs for condensed work states.

But, the point of it is to make things easier for like 90% of what people want to do, so if you think the helper should provide information about condensed/actual work states, we could potentially add that! I don't think it would be hard to include those.

[oleszczyk]

Hi @ad3154

I have connected original Gaspardo corn seeder ISOBUS control unit to my Task Controller implementation. It looks like communication has been established right away without any issues!

But... I was trying to download DDOP (to see what kind of DDIs this seeder implements) and it failed printing error:
[Error][DDOP]: Binary device object with version 4 contains invalid extended structure label length..
Unfortunately I do not have deep knowledge about all details of ISOBUS in general so this kind of error does not tell me much.

Question: do you maybe have any clue what does it mean to me and how to make it work? When I connect the same control unit to tractor everything is working as expected. So is that probable that this Gaspardo unit is not fully following ISOBUS standard (which is implemented in AgIsoStack-plus-plus)?

Maybe full log will tell you more:

[Debug][AC]: Internal control function a0008200afe00014 has arbitrarily claimed address 128 on channel 0
[Warn][PR]: NACK-ing PGN request for PGN 60928 because no callback could handle it.
[Debug][NM]: A control function claimed address 129 on channel 0
[Debug][TC Server]: Client reports that its version is 3
[Info][TC Server]:Client 0x81 structure label(s) did not match. Sending 0xFFs as the structure label.
[Info][TC Server]: Client 0x81 requests object pool transfer of 2431 bytes
[Debug][ETP]: New rx session for 0x0CB00. Source: 129, destination: 128
[Debug][ETP]: Session Closed
[Debug][ETP]: Completed rx session for 0x0CB00 from 129
[Info][main] stored bytes: 2430
[Info][TC Server]: Stored DDOP segment for client 0x81
[Info][TC Server]: Client 0x81 requests activation of object pool
[Debug][DDOP]: Attempting to deserialize a binary object pool with size 2430.
[Error][DDOP]: Binary device object with version 4 contains invalid extended structure label length.
[Error][DDOP]: Not enough binary DDOP data left to parse device object. DDOP schema is not valid
[Error][DDOP]: Binary DDOP deserialization aborted.
[Error][TC Server]: Failed to activate object pool for client 0x81. Error code: 0, Faulty object: 0, Parent of faulty object: 0
[Error][TC Server]: Client 0x81 sent an acknowledge command but the object pool is not active.
[Error][TC Server]: Client 0x81 sent an acknowledge command but the object pool is not active.

I also include the log from next try as a print-screen from VSCode terminal (to keep logs coloring):

[oleszczyk]

OK sure, I will do it on Monday morning. Thanks in advance!

[oleszczyk]

@ad3154 I am attaching a zip package containing Wireshark .pcapng logs and text log from terminal where DDOP is printed as a HEX stream. Also extracted pure DDOP in separated file. The weird thing is that one log is saying:

[Info][TC Server]: Client 0x81 requests object pool transfer of 2431 bytes       

But then total count written to my DDOP vector is 2430 (you can see that in the text log).

[ad3154]

So, the issue here is just that when you are parsing the DDOP, you are doing it as version 4 instead of version 3.
When you create the DDOP, you can specify the version like this for example, to make a version 3 DDOP:

DeviceDescriptorObjectPool ddop(3);
ddop.deserialize_binary_object_pool(testDDOP, sizeof(testDDOP));

I think in order to help with this, the CAN stack should probably pass the version of the DDOP to you via the store and activate callbacks... 🤔 that way you know how to deserialize it... or I could add a helper function that looks at a DDOP and deduces which version it is. Or both.

So in the short term, yeah, try dealing with it as a version 3 DDOP instead.

Also, the reason for that 1 byte difference is because the transfer does actually have one extra byte - the multiplexer byte, which we remove later so you only have the actual DDOP data 😀

[oleszczyk]

This DDOP version 3 is the same (logically) version logged here:

[Debug][TC Server]: Client reports that its version is 3

or this is just a coincidence and DDOP version is not related to general supported ISOBUS version notified by this log?

In other words can I retrieve this interesting for me version from TechnicalDataCommandParameters::ParameterVersion response or should I search for version somewhere inside received DDOP itself?

Assuming this client version is identical to DDOP version then maybe it would be wise to keep this version in class ActiveClient as another field, so TaskControllerServer can always retrieve it using

get_active_client(clientControlFunction)->clientVersion

for example in activate_object_pool() callback. What do you think?

[oleszczyk]

Anyway - I have created PR with proposed change. Merge it if you like.

[oleszczyk]

@ad3154 OK - I have properly parsed received DDOP and put some extra logs (for each found DeviceProcessData I logged: Designator, DDI, Triggers, Properties, Element number) to understand what I am dealing with.

[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 1 DDI: 67, Triggers: 8, Properties: 0, Element number: 1
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 1 DDI: 135, Triggers: 8, Properties: 0, Element number: 1
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 2 DDI: 67, Triggers: 8, Properties: 0, Element number: 2
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 2 DDI: 135, Triggers: 8, Properties: 0, Element number: 2
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 3 DDI: 67, Triggers: 8, Properties: 0, Element number: 3
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 3 DDI: 135, Triggers: 8, Properties: 0, Element number: 3
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 4 DDI: 67, Triggers: 8, Properties: 0, Element number: 4
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 4 DDI: 135, Triggers: 8, Properties: 0, Element number: 4
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 5 DDI: 67, Triggers: 8, Properties: 0, Element number: 5
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 5 DDI: 135, Triggers: 8, Properties: 0, Element number: 5
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Width 6 DDI: 67, Triggers: 8, Properties: 0, Element number: 6
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset 6 DDI: 135, Triggers: 8, Properties: 0, Element number: 6
[Debug][DDOP parse_element] DeviceProcessData. Designator: Target rate spacing DDI: 16, Triggers: 9, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual rate spacing DDI: 17, Triggers: 9, Properties: 1, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Target rate count DDI: 11, Triggers: 9, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual rate count DDI: 12, Triggers: 9, Properties: 1, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Total amount DDI: 82, Triggers: 25, Properties: 3, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Total area DDI: 116, Triggers: 25, Properties: 3, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Total distance DDI: 117, Triggers: 25, Properties: 3, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Total time DDI: 119, Triggers: 25, Properties: 3, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Setpoint Work State DDI: 289, Triggers: 0, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual Work State DDI: 141, Triggers: 9, Properties: 1, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Section Control State DDI: 160, Triggers: 8, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Setpoint Condensed Work State DDI: 290, Triggers: 8, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual Condensed Work State 1-16 DDI: 161, Triggers: 9, Properties: 1, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Default data DDI: 57343, Triggers: 31, Properties: 0, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Prescription Control State DDI: 158, Triggers: 9, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: SC Turn On Time DDI: 205, Triggers: 9, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: SC Turn Off Time DDI: 206, Triggers: 9, Properties: 2, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Sec Offset X boom DDI: 134, Triggers: 8, Properties: 0, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual Working Width DDI: 67, Triggers: 9, Properties: 0, Element number: 80
[Debug][DDOP parse_element] DeviceProcessData. Designator: Actual Cultural Practice DDI: 179, Triggers: 8, Properties: 1, Element number: 80

The ISOBUS unit I am testing is from 6-sections Gaspardo corn seeder, where each section is controlled by single electrovalve (simple ON/OFF switch) - not by stepper motor. The unit is sitting on my desk (not connected to any real equipment...)

My goal is to be able to turn ON/OFF given seeder section from my TC. I have triggered send_time_interval_measurement_command(...)` for the most interesting parameters:

• DataDescriptionIndex::ActualCountPerAreaApplicationRate,
• DataDescriptionIndex::ActualSpacingApplicationRate,
• DataDescriptionIndex::ActualWorkState,
• DataDescriptionIndex::ActualCondensedWorkState1_16,
• and also I am reading DataDescriptionIndex::SectionControlState form time to time.

This is what I periodically receive:

[Debug][TC Server]: Client 0x81 value command for element 80 DDI 17 and value 0 OK.
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 12 and value 0 OK.
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 141 and value 1 OK.
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 161 and value fffff000 OK.
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 160 and value 0 OK.

This is understandable because this ISOBUS control unit is not connected to anything. From this description I understand that ActualCondensedWorkState1_16 is coded as each 2-bits code single section: 0b00 - off, 0b01 - on, 0b10 - error, 0b11 - not changed. Same coding is used for settings sections by DDI DataDescriptionIndex::SetpointCondensedWorkState1_16.

So I called:
send_set_value_and_acknowledge(controlFunction, static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SetpointCondensedWorkState1_16), 80, 0xFFFFF555); to turn ON first 6 sections and keep the rest not changed as it is described here.

I have tried above but no significant change could be noticed - still I received:

[...]
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 161 and value fffff000 OK.

Then I have read here that maybe TC should request for Auto mode enable. So I triggered:

send_set_value_and_acknowledge(controlFunction, static_cast<std::uint16_t>(isobus::DataDescriptionIndex::SectionControlState), 80, 1);

But it does not change anything - still I get:

[...]
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 161 and value fffff000 OK.
[Debug][TC Server]: Client 0x81 value command for element 80 DDI 160 and value 0 OK.

Looks like this client does not accept my Auto mode request. In Details for DDEntity "160 - Section Control State" comment I can read:

Use case "Auto request from TC":
1. The implement receives an ‘auto’ request from TC.
3. The implement shall check whether all setup conditions are fulfilled to allow section control.
4. 3. If this check is ok: The implement may respond with ‘auto mode’ and set its internal SCS client to ‘auto mode’.
5. 4. If this check not ok: The implement shall respond with ‘manual mode’. The internal state is still in manual mode. 

So what I am expecting maybe there are some special conditions which have to be fulfilled to allow section control by my TC.

And finally the questions: do you maybe know what can be a reason why I cannot control seeder sections via DataDescriptionIndex::SetpointCondensedWorkState1_16? Are my assumption correct about a need of setting Auto mode (by DataDescriptionIndex::SectionControlState) first? Do you maybe know based on your great ISOBUS knowledge and experience how to solve that? Maybe the issue is that this seeder unit is not connected to any physical equipment and it is simply not possible to test "on desk" as I am trying to do?

Thank you very much for all help you gave me already, without your support I would not be able to get so far!