I believe we used the same to check the messages on the bus. So reading it to a windows pc is possible. But you also have to send can messages to the bus if you want to make a proper VT screen.
I never did something like this, but if someone wants to try, I would really like to help ofcourse.
It is possible to send the messages with it as well
1 Like
Hey there, Iām the main developer on Isobus++, and wanted to provide an alternate link to our getting started + tutorial pages (Overview ā ISO 11783 CAN Stack 1.0.0 documentation) since my home internet where I host the main site can be kind of unreliable. Our library is very new, and is definitely a work in progress, but if you have specific examples that youād like to see added to our VT client functionality, Iād be happy to prioritize those to help others more easily create VT enabled ISOBUS programs! I write VT enabled ISOBUS applications as my every day job, so it is easy for me to miss things that might help others do the same, but I want to make it as easy as possible if I can.
17 Likes
Hello, I have been watching the developement of the isobus++, it is a very interesting project.
My questions are:
- What hardware we can use for communication with CAN?
- Is there a working example of isobus VT?
- What is the future of the library?
- Are you interested in creating a fully functional VT with us?
Thank you for your response on this topic.
Best Regards, Marko.
Good questions.
Currently the library supports the following hardware (with more on the way):
- Most Linux compatible CAN hardware (via SocketCAN)
- Peak PCAN devices on Linux, Windows, and MacOS
- Innomaker USB2CAN and USB2CANx2 devices on Windows
- ESP32ās Two-Wire Automotive Interface (TWAI)
- SPI-based MCP2515 CAN Controllers
- (Coming Soon) Rusoku TouCAN
Hardware not covered by these can be fairly easily added as long as thereās a C or C++ sdk or api for it, and as long as the license or EULA is favorable.
There is a working VT client example in the examples folder in the library. It is pretty basic, but it can always be expanded to demonstrate more functionality. If there are any specific features people would like added to it, we can certainly get those added.
The future of the library is quite a broad question, but here are my thoughts.
- Iād like the library to fully implement all ISOBUS client functionality. (This is sort of my number one priority right now as I am polishing up the Task Controller client)
- Iād like the library to fully implement specifically the CAN interface portions of the server portions of the ISOBUS standard (so, VT, TC, File server) to provide a good base for GUI-based VT and TC programs.
- Iād like to make additional comprehensive examples that include more advanced features, such as a complete rate controller simulator with all protocols used.
- Some day Iād like to bring the library and itās examples to the AEF plugfest if I can find some way to do it financially.
- Iād like to run the AEF conformance tests on the library + examples at some point if I can get access to a tester. It seems like the barrier to entry financially to be part of AEF is very high for an individual or open source project, but you never know, maybe someday it will happen.
- Iād love to create a derivative of the library in Rust at some point also.
- Iād like to create a ROS2 wrapper for the library to make it easier to use in robotics.
My real hope is that we can make the library the go-to library for ISOBUS, at least for C++ some day.
As far as creating a VT goes, I would absolutely love to see a fully functional open source software-based VT become reality. I would participate in something like that if I can, at least at the CAN layer, object parsing, etc, but would probably need to rely others for the graphics side of things, as that is not something I really have experience with.
4 Likes
Thank you for the great response to my questions.
Currently, I am a little busy with my work and some other stuff going on in my life.
In the near future, I can do the graphics part of the VT. If someone else is interested and has some ideas feel free to write them down.
Is it possible to do the virtual terminal in other languages or only in c++?
And one final question that was always bothering me. How does the tool send information to VT on what to show on screen?
Ex: Amazone seeder communicating with Fendt. How does it know the āpicturesā and the rest needed?
āHow does the tool send information to VT on what to show on screen?ā This really encapsulates the āmagicā of ISOBUS. It is a very simple, very reasonable question with a very complicated answer. I will try to explain as best I can.
The short version is, the Amazone seeder literally sends the pictures, fonts, text, buttons, and other things to the Fendt display in your example in a giant pool of data called an āobject poolā. Inside the Amazone seederās controller, there is a bunch of binary data stored somewhere that represents all these things that get displayed. When the VT client hand-shakes with the VT, it transfers this pool in chunks to the VT until the terminal has a complete copy of everything the client wants to display, including bitmaps, font sizes, text, buttons, numbers, and other things. Then, the client can do things with those objects to make it look like a working GUI, such as hide things, change numbers, change strings, and move objects.
To break it down further, letās look at the Isobus++ example for the VT client, we provide one of these object pools as an example in the form of an .iop file. This iop file is just a binary file full of those objects.
If you were to run that example, youād see something like this appear on the VT:
So, whatās going on here? Well, that IOP file has this information in it:
Basically, the object pool is a hierarchy of different, small, basic components that all form the resemblance of a GUI. So, how does the VT know to draw that little yellow warning triangle? Easy! The object pool tells it to draw a soft key mask, draw one soft key inside that mask, then draw the yellow triangle bitmap (which I previously uploaded to the VT) on top of that soft key. Likewise, it knows how to organize all these objects because the object pool data I uploaded told the VT which objects to draw inside the data mask area, along with their sizes, x/y locations, colors, and values (like text). Some commercial controllers on the market have tens of thousands of such objects.
Does that make sense?
Usually then the next question is, āOkay, but, how do I make one of these object pools?ā and that is very tricky, as there are not really a lot of good, non-commercial options out there to make these. One such program though is Jetter ISO-Designer if you get the free trial, which lets you make up to 100 objects I think. That is not very many objects though unfortunately and can run out very fast. This is another great space where I hope someone can provide an open source solution some day that is free for everyone, or at least individuals and students.
This is also a bit of a simplified answer, as there are other components from ISOBUS involved to make it all work of course, like the Extended Transport Protocol which transfers the object pool to the VT, so let me know if anyone has more questions!
8 Likes
This mostly just depends on how you want to do it. I donāt see why it couldnāt be another language, but the language choice may determine how much extra work you will or wonāt have to do.
For example, hypothetically, if you did it in C++, you could use Isobus++ and automatically have things like the Extended Transport Protocol working. But if you did it in C# (again, just as an example), you would not be able to use Isobus++, which is totally fine, but you might need to write that functionality yourself, find a library in C# that does it already, or somehow bind another languageās library to that one.
Of course I would love everyone to use my C++ library, haha, but if another language has more benefits or a better use-case, then that should really be explored too. Ultimately, if we all had a cool, open source VT in any language I think Iād be very happy 
6 Likes
VT works a bit like the old X11 protocol where the widgets were all drawn server-side. Makes for very low-bandwidth capabilities but also youāre stuck with 20 year old screen resolutions. Of course the VT implementation could upscale them and Iām sure the latest monitors all do that.
2 Likes
Thank you for the answer. I had a rough idea of how it works, and now it all falls into place.
I want to use the ISOBUS++, it is good to have it working. Now that we understand how it works it is possible to get the data and based on them create a grid and display the items on the grid.
When I have more free time I will look into some of the code and how to make it look good. Maybe using some c++ GUI library.
1 Like
So thereās no description anywhere (other than the expensive ISO documents) on the format of the data in the IOP file? No way to create the pool objects programmatically? Seems like you need the equivalent of the Microsoft resource compiler.
Also, can ISOBUS++ build and run on the Teensy 4 microcontroller? Thatās got no less than three CAN ports, including a CAN HD port, and has quite a bit of processing power behind it.
So thereās no description anywhere (other than the expensive ISO documents) on the format of the data in the IOP file? No way to create the pool objects programmatically? Seems like you need the equivalent of the Microsoft resource compiler.
As far as I know, the actual description and format of those objects (and the IOP file structure) does fall under the ISOās copyright, which is a bummer for sure, and they are very strict about that kind of thing. Not very āopenā despite it being an international standard when you have to hand over that much cash to read it in my opinion.
Anyways, VT object pools could be created programmatically, but could be challenging without tooling to preview what it will look like, plus time consuming to iterate on without that visual feedback.
I have considered adding at least the ability to serialize and de-serialize these objects to and from IOP files to Isobus++, but I havenāt had the time to get it done fully yet. I do have a draft of that functionality saved somewhere though, so I think you could expect that to get added to our library at some point in the future! Though, to be clear, a full object pool designer is out of scope for our library as itās just a CAN library. This would be another great opportunity for the open source community to really solve a cool problem for the ISOBUS community, by creating an open source, free object pool designer of some kind. I hope something like that happens. I do know of this project which tried to do that some time ago, but it seems to be a bit flaky, and written in Java.
Also, can ISOBUS++ build and run on the Teensy 4 microcontroller? Thatās got no less than three CAN ports, including a CAN HD port, and has quite a bit of processing power behind it.
The Teensy is a very neat micro controller that I have looked at before. I would like it to be compatible, but I do not have a teensy to test on right now. I will see if I can order a Teensy 4.1 and get it working (this may take some time. I will add an issue on our GitHub so it doesnāt get forgotten). If you are developing with the Arduino IDE, I can say it probably will not work in itās current state at this time of writing without some effort, as the library isnāt packaged up to be an Arduino library.
4 Likes
Good morning,
do you think we could make an isobus task controller?
Maybe you can just use the GPS Signal from AgOpenGPS and use the task controller of the VT device as described here:
I have to politely disagree given the audience here; wasnāt that long ago when it was ācommon knowledgeā that open source autosteer and section control was considered to be unachievable 
Look where we are todayā¦
4 Likes
Hello InterFan, I am Rumi. I am doing a masterās degree in Electrical Engineering. I want to work on ISOBUS. Can you help me too? I would also like to do a project with you. If your answer is yes, you can give me the contact address you want. I can also give you my contact information. Mail, whatsapp, telegram etc.
I am waiting for good news from you.
Iām just coming back to this thread to note that our library does now run on Teensy 4 and 4.1 using the Arduino IDE 
5 Likes
The virtual terminal client library is indeed neat, but Iām still hoping to see an open-source virtual server terminal implementation. And a task controller. So far havenāt seen any. Iād actually even be interested in a non-open source implementation for windows or android.
1 Like
This is the only one open-source VT as I currently know ofā¦ not really well documented, but seems like lots of things implemented from the standards, someone with isobus development knowledge can easily tell whatās missing.
It was built for the M5Stack module (esp32 based, with 320x240 display, no touch). Weird choice but it can be ported to other hardware with bigger touchscreen. Maybe with some fiddling, it can already control sprayer/spreader sections.
6 Likes
Thanks for posting that. Very interesting.